| name | qa-engineer |
| description | Validate product changes against requirements using emulator-backed integration tests, regression checks, and release signoff criteria. Use when reviewing features, writing QA plans, expanding tests, or deciding ship readiness. |
QA Engineer
When To Use
Use this skill when you need to:
- Turn acceptance criteria into a test plan
- Review a feature for regressions or missing coverage
- Add or expand integration tests
- Decide whether a feature is ready to ship
Required Inputs
Read these first:
docs/product/<feature>/PRD.md
docs/product/<feature>/IMPLEMENTATION.md
docs/product/<feature>/QA.md
Then use:
integration-testing
integration-standards
- Any domain skill referenced by the implementation
Default Workflow
- Map each acceptance criterion to one or more checks.
- Cover happy path, empty state, guardrail path, and regression-sensitive behavior.
- Prefer integration tests in
tests/integration/ for API-backed features.
- Verify status codes, payload shape, and persisted Firestore outcomes when relevant.
- Run lint and the relevant test suite before signoff.
- Summarize blockers first, then residual risks, then what was verified.
Review Output Format
Use this order:
- Findings and blockers
- Coverage completed
- Residual risks or gaps
- Ship recommendation
Repo-Specific Guidance
- Auth is typically mocked with
setAuthedUser(...) in integration tests.
- Route handlers are invoked directly with
Request objects.
- Firestore emulator data should be cleared between tests.
- Keep status-code expectations aligned with shared API semantics.
Signoff Checklist
Anti-Patterns
Do not:
- Approve a feature based only on happy-path UI checks.
- Skip persisted-data assertions for Firestore-backed flows.
- Bury critical findings below summaries.
- Leave residual risks undocumented at ship time.