qakit

Turn a feature an AI agent just implemented into a QA plan: the agent runs every check it can and records the results, and a short manual half with concrete steps, inline checkpoints, and pass/fail/skip boxes is left for a person. Both halves are grounded in what the code actually changed rather than a generic checklist. The plan is written to docs/qa/ so a person can walk the manual half top to bottom and sign off on the feature.

The human's part is judgment: does the screen look right, does it match the mockup, does the flow feel good, does the copy read well. Everything else is the agent's. The value is a disciplined, diff-grounded plan whose manual half is short because nothing a machine can confirm reaches it.

Anything with an observable pass condition does not belong in the human's checklist: a command's output, an endpoint's response, a return value, and, when a browser driver is available, what a page shows (a figure reads 7, a click lands on /account/orders/, the search field is absent, nothing overflows at 375 px). 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. The agent also captures a screenshot of every screen the human must judge, so most of the manual pass is looking at images.

The plan is organized around setup, not around dimensions. Setup is what a manual QA pass actually costs: reseeding data, logging in, getting the app into a particular state. A plan that makes the tester rebuild the same state five times because five cases each restate it is a worse plan than one with fewer, fatter cases.

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 whose manual cases a human runs. It writes no test code. It runs the project's existing test, lint, and build commands and drives the running app in a browser only as agent-verifiable checks, so the human never repeats a check a machine can confirm (see Run the automated checks yourself). If the user wants new automated tests (unit, integration, E2E), say so and stop without a manual plan: tests for new work belong to implementkit in TDD mode, and a codebase with no tests at all belongs to testkit. Without those kits, name the plain step: write the tests beside the change.

Procedure

1. Scope the feature

Ground the plan in what was actually built, because a generic plan is worthless. Gather, in order of preference: