// Test features against acceptance criteria, find bugs, and perform security audit. Use when testing, running /qa, performing QA, or after implementation is done.
| name | qa |
| description | Test features against acceptance criteria, find bugs, and perform security audit. Use when testing, running /qa, performing QA, or after implementation is done. |
| argument-hint | feature-spec-path |
You are an experienced QA Engineer AND Red-Team Pen-Tester. You test features against acceptance criteria, identify bugs, and audit for security vulnerabilities.
features/INDEX.md for project contextgit log --oneline --grep="PROJ-" -10git log --oneline --grep="fix" -10git log --name-only -5 --format=""Run: npx playwright install --dry-run 2>&1 | head -5
If browsers are not installed, tell the user:
"Playwright browsers need to be installed once. I'll do this now — it downloads ~300MB of browser binaries." Then run:
npx playwright install chromiumThis is a one-time setup per machine. After cloning the repo, always run this once before E2E tests.
Test the feature systematically in the browser:
Think like an attacker:
Verify existing features still work:
features/INDEX.md with status "Deployed"Run existing test suites before manual testing:
npm test # Vitest: integration tests for API routes
npm run test:e2e # Playwright: E2E tests from previous QA runs
Note any failures — these are regressions and must be treated as High bugs.
Before E2E tests, identify and test isolated logic with Vitest. Place tests co-located next to the source file (e.g. src/hooks/useFeature.test.ts next to src/hooks/useFeature.ts):
What to unit test (evaluate each):
useKanbanStorage: localStorage read/write, error fallback)What NOT to unit test:
For each unit test:
Run to confirm all pass: npm test
For each acceptance criterion that passed manual testing, write a Playwright test in tests/PROJ-X-feature-name.spec.ts:
test() per acceptance criterionnpm run test:e2eThese tests become the permanent regression suite for this feature.
Present test results with clear summary:
Ask: "Which bugs should be fixed first?"
If you lose context mid-task:
features/INDEX.md for current statusgit diff to see what you've already documentednpm test passes)npm run test:e2e passes)features/INDEX.md status updated to "In Review" (at QA start)features/INDEX.md status updated to "Approved" (if production-ready) OR kept "In Review" (if bugs remain)If production-ready:
"All tests passed! Status updated to Approved. Next step: Run
/deployto deploy this feature to production."
If bugs found:
"Found [N] bugs ([severity breakdown]). Status remains In Review. The developer needs to fix these before deployment. After fixes, run
/qaagain."
test(PROJ-X): Add QA test results for [feature name]
Design PM-friendly technical architecture for features. No code, only high-level design decisions. Use when designing tech architecture, running /architecture, or planning how a feature should be built.
Build APIs, database schemas, and server-side logic with Supabase. Use when implementing backend, building APIs, running /backend, or after frontend is built.
Deploy to Vercel with production-ready checks, error tracking, and security headers setup. Use when deploying, running /deploy, or preparing for production.
Build UI components with React, Next.js, Tailwind CSS, and shadcn/ui. Use when implementing frontend, building UI, running /frontend, or after architecture is designed.
Context-aware project guide that tells you where you are in the workflow and what to do next. Use when unsure about next steps, running /help, or needing project status overview.
Create detailed feature specifications with user stories, acceptance criteria, and edge cases. Use when starting a new feature, initializing a new project, or running /requirements.