| name | qa |
| description | Verify a feature works after implementation. Actively try to break it — edge cases, error paths, integration wiring, and real usage flows. |
QA
Planner Entry
Run /qa only when the user explicitly requests adversarial validation or an
actionable PR/CI finding needs it. Do not add QA as a pre-PR quality gate:
task-defined tests and the two PR AI reviewers are the default evidence.
Verify that a feature works as intended after implementation. Assume bugs exist and hunt for them.
Mindset: you are not confirming it works — you are discovering where it breaks.
Available skills
/tdd — Use when unit or integration coverage is missing./e2e — Use when a user-facing flow lacks browser coverage.
Before starting: create the pipeline
Create these tasks immediately (use your task/todo tracking tool if available):
- Understand the intent — Read task/PR/commits to understand what was built
- Trace the wiring — Verify the feature is actually connected end-to-end
- Test the happy path — Run the feature as a user would
- Try to break it — Boundary values, error paths, concurrency, auth
- Verify test coverage — Check for missing tests and report gaps
- Report — Summarize findings with verdict
Mark each task in_progress when you begin it and completed when you finish it.
Phase 1: Understand the intent
Mark task 1 as in_progress.
Read the task description, PR, or recent commits to understand what was built and what it should do. Identify:
- The expected behavior (happy path)
- System boundaries (user input, API endpoints, external data)
- Integration points (what calls what, data flow end-to-end)
Mark task 1 as completed.
Phase 2: Trace the wiring
Mark task 2 as in_progress.
Before testing behavior, verify the feature is actually connected:
- Exports are imported and used (not just defined)
- API routes have consumers (frontend calls them, or tests exercise them)
- Data flows end-to-end: input -> handler -> storage -> response -> display
- New config/env vars are documented and have defaults
If something is orphaned or unwired, stop and report it — no point testing disconnected code.
Mark task 2 as completed.
Phase 3: Test the happy path
Mark task 3 as in_progress.
Run the feature as a user would. For backend changes, call the API. For frontend changes, trace the UI flow. For both, follow the full path:
- Does the basic use case work?
- Does the response/output match expectations?
- Is the data persisted correctly?
Mark task 3 as completed.
Phase 4: Try to break it
Mark task 4 as in_progress.
Systematically test these categories (skip what doesn't apply):
Boundary values:
- Empty input, nil/null, zero, negative numbers, max values
- Empty arrays/maps, single element, very large collections
- Strings: empty, whitespace-only, special characters, very long
Error paths:
- What happens when dependencies fail (DB down, API timeout, invalid response)?
- Are errors surfaced clearly or silently swallowed?
- Does the system recover or get stuck in a bad state?
Concurrency:
- What happens with simultaneous requests to the same resource?
- Race conditions: create/update/delete at the same time
- Does it handle duplicate submissions?
Authorization:
- Can the feature be accessed without proper auth?
- Does it respect permission boundaries?
Mark task 4 as completed.
Phase 5: Verify test coverage
Mark task 5 as in_progress.
Check that the implementation has tests covering the behaviors you just verified:
- Are the happy path and key error paths tested?
- Are edge cases from Phase 4 covered?
- Are tests at the right level: unit for pure logic, integration for boundaries, E2E for critical browser flows?
- Do tests assert behavior/state/output rather than implementation details or mock behavior?
- If tests are missing, report the exact behavior and recommended test level so
add the focused test in the same conversation.
- Avoid snapshot tests unless the snapshot change will be deliberately reviewed.
Mark task 5 as completed.
Phase 6: Report
Mark task 6 as in_progress.
Summarize what was tested and what was found:
Verified working:
- List of behaviors confirmed working
Issues found:
- file:line - description, how to reproduce, severity (blocker/suggestion)
Missing test coverage:
- Behaviors that work but have no automated test
Verdict: Feature complete / Has issues — fix before merge
Mark task 6 as completed.
