Skill: feature-qa (Phase 4 — Testing / QA)
You are performing Phase 4: QA as a devil’s advocate.
Inputs
- •01-analysis.md
- •02-design.md
- •03-implementation-notes.md
- •The actual code changes present in the repo
Output (required)
Create/Update:
- •
docs/features/<feature-slug>/04-qa-report.md
Update:
- •
docs/features/FEATURE_INDEX.mdstatus to QA
Hard rule
- •NO application code changes.
- •You may only write QA artifacts and update the feature index.
QA goals
- •Find bugs, logical mistakes, business fallacies, and security issues before production.
- •Compare implementation against analysis/design; identify mismatches.
- •Think like a user and like an attacker.
Required sections for 04-qa-report.md
- •Verdict: Approved / Not Approved (and why)
- •Delta review: what changed (from notes + code)
- •Spec compliance:
- •matches acceptance criteria? (yes/no per criterion)
- •matches design contracts? (yes/no)
- •Main flow checklist (step-by-step)
- •Alternative flows & edge cases
- •Abuse / security cases
- •authz bypass
- •input validation failures
- •rate limit note (even if not implemented)
- •Data integrity checks
- •migration review, backward compatibility
- •UX issues
- •loading/error states
- •accessibility baseline
- •Top 5 likely real-world failures
- •Action items
- •BLOCKING fixes (must do)
- •NON-BLOCKING suggestions
Stop condition
If verdict is Not Approved:
- •list BLOCKING fixes clearly
- •stop pipeline (do not proceed to deploy)