qa-prd

name

qa-prd

description

Independently QA an implemented PRD against its issue spec before sign-off — verify acceptance criteria, required tests, user-story coverage, and out-of-scope guarantees against the real merged code, then post a sign-off comment. Use when the user wants a QA pass on delivered work, an acceptance review of a PRD or spec, or a sign-off before closing a PRD. Distinct from /review (per-PR diff) and /verify (runs the app) — this checks a whole spec against the codebase.

QA a Delivered PRD

Independently confirm that a PRD (or spec) was implemented correctly on the integration branch — verifying against the spec, not against the PRs' own claims. Verify only; do not implement, push, or merge. Do not rubber-stamp: if an acceptance criterion is unmet, say so plainly.

This sits at a different altitude from the per-change skills:

• /review checks one PR's diff. /verify runs the app to confirm a change behaves. /qa-prd checks a whole spec against the merged codebase — acceptance criteria, required tests, user stories, and out-of-scope guarantees.

Process

1. Set up a clean verification checkout

• Fetch and check out the integration branch (the merged state to verify), ideally in an isolated worktree.
• Install dependencies.

2. Read the spec and orient on the delivery

• Read the PRD in full: problem statement, solution, user stories, implementation decisions, testing decisions, out-of-scope.
• Note the PRs/issues that delivered it for orientation — but verify against the actual code, not the PR descriptions. The PRs are claims; the code is the evidence.

3. Verify against the real codebase

For each implementation decision / acceptance criterion, confirm it in the code and cite the evidence (file path or grep result). In particular:

• The promised modules/seams exist with the agreed interfaces.
• Duplication that was meant to be removed is actually gone — grep for stale imports and deleted paths.
• The testing decisions are honoured: the modules the PRD required tests for have meaningful tests with real branch coverage (not placeholder tests).
• The out-of-scope guarantees were respected — nothing forbidden was changed (e.g. no schema/migration where none was intended; relevant ADRs preserved; dead/forbidden states not introduced). Where a change looks suspicious, diff it against history (git show/git log) to confirm it was a faithful move, not new behaviour.
• Each user story maps to where it is satisfied in the code — flag any gaps.

4. Run the quality gates

Run the repo's lint, typecheck, and full test suite on the integration branch, in the prescribed order. Report exact pass/fail and the test counts. A green suite is necessary but not sufficient — it does not replace the criterion-by-criterion check above.

5. Deliver the sign-off

Produce a structured QA report:

• Overall verdict: PASS / PASS WITH NOTES / FAIL.
• A per-criterion checklist with PASS/FAIL and brief evidence.
• Test / lint / typecheck results with counts.
• Confirmation that out-of-scope items were respected.
• Any defects, gaps, or unmet criteria, called out explicitly.

Post the report as a comment on the PRD issue, clearly labelled as a QA sign-off (via the GitHub MCP tools). Return the verdict and a concise summary.

The verdict is a real gate

Only sign off PASS if the spec is actually met. If you find a defect or an unmet criterion, report FAIL with specifics — the value of this pass is that it is independent and honest, not that it closes the ticket. The EM closes the PRD only on PASS; on FAIL the work re-enters the implementation lifecycle.