qakitlisted

# qakit Turn a feature an AI agent just implemented into a **manual QA plan a human can actually run** — concrete steps, expected results, and pass/fail boxes, grounded in what the code actually changed rather than a generic checklist. The plan is written to `docs/qa/` so a person can walk it top to bottom and sign off on the feature by hand. This is **manual** QA — steps that genuinely need a human to perform and judge (click through a flow, read a screen, feel out the UX), not checks a machine can do on its own. The value is a disciplined, diff-grounded plan: what to test, in what order, with what setup, and how to know it passed — focused on the things that *can't* be verified without a human eye. Anything an AI agent or script can confirm on its own — running a terminal command and reading its output, hitting an endpoint, asserting a return value — does **not** belong in the human's checklist. The agent runs those itself and reports the results in an **Automated verification** section at the end of the plan, so the human sees them confirmed without re-running them by hand. ## When this fires The user finishes building something and wants to verify it by hand: "write a QA plan", "manual test plan", "how do I test this feature", "give me a testing checklist", "/qakit", or a bare "QA this" after a coding session. qakit produces a plan a **human** runs — it never writes or runs test code. If the user wants *automated* tests (unit, integration, E2E), that's a separate con