qa-plan
Purpose
Independent QA in two phases.
Source Skill purpose
When to use it
Use qa-plan for tasks of STANDARD class or above, or whenever a change needs independent checks against stated acceptance criteria. Before implementation it turns the final plan into concrete scenarios with observable inputs and expected outcomes. After implementation it runs those frozen scenarios against the real result and records a mechanical verdict. It adds adversarial cases only where the affected boundary makes them relevant, and preserves expectations when the implementation is seen.
Source Skill purpose
How it works
Source Flow - plan
Source Flow - report
- Read the criteria Read every acceptance criterion and ask for input if a criterion cannot be observed without guessing.
Source Flow - plan
- Map the surface Inspect entry points, nearby tests, run commands and behavior that the change could regress.
Source Flow - plan
- Write acceptance cases Give each criterion concrete inputs, observable outputs and an execution method.
Source Flow - plan
- Add adversarial cases Add boundary and invalid-input scenarios only where they apply, including external entry points named in the plan.
Source Flow - plan
- Record regression checks Name existing behavior that must remain and the command that checks it.
Source Flow - plan
- Validate the plan Run the plan validator against the task and frozen plan before returning the QA plan.
Source Flow - plan
- Return the plan Return the validated scenario plan for the lead to freeze with the implementation plan.
Source Flow - plan
- Verify the freeze Check the QA plan and its hash before executing any scenario after implementation.
Source Flow - report
- Run the baseline Warn about sandboxed execution once, then record the project's test baseline without modifying the tree.
Source Flow - report
- Execute in order Run each scenario in plan order and record the command, result and relevant output before the next.
Source Flow - report
- Classify results Mark observed passes and failures, blocked automation, manual checks and baseline failures by their defined rules.
Source Flow - report
- Write the report Write the mechanical verdict and a result with evidence for each planned scenario.
Source Flow - report
- Validate the report Run the report validator, which rejects a verdict inconsistent with scenario results.
Source Flow - report
- Clean evidence worktrees Remove worktrees created for probes while retaining the report and needed evidence.
Source Flow - report
Key rules
- Base the QA plan on the final plan and cite its hash, so later contract changes cannot pass unnoticed.
Source Hard rules
- Every acceptance criterion needs an input and an observable expected result rather than a vague success claim.
Source Hard rules
- Add adversarial cases only for applicable categories, while external input entry points always receive invalid-input coverage.
Source Hard rules
- Phase two requires an observed result; reading code alone does not prove that a scenario passes.
Source Hard rules
- Never relax an expectation after seeing the implementation; the report still cites the frozen plan.
Source Hard rules
Output and gate
Output
- Produce the QA plan, QA report, machine summary and evidence ledger for the run.
Source Output
- In standalone use, give the output path, verdict, scenario results, failures and manual follow-ups.
Source Output
Gate
- An automated scenario with an observed failure makes the QA verdict fail.
Source Gate rule (phase 2, mechanical)
- If no automated case fails but one cannot run, the QA verdict is blocked.
Source Gate rule (phase 2, mechanical)
- Only after automated cases pass without a block does the QA verdict pass.
Source Gate rule (phase 2, mechanical)
Source
Source Skill definition