test-plan
Test Plan
Write a test strategy that answers two questions clearly: what deserves testing and how much testing is enough. Everything else is execution detail.
Step 1: Understand What's Being Tested
Before planning any tests, nail down what you're working with. Read the code or requirements. If the user hasn't provided enough context, ask.
| Input | Question | Watch out for |
|---|---|---|
| Code / Feature | What does this do? What are the inputs and outputs? | Planning tests for code you haven't read |
| Critical paths | Which flows would break the product if they failed? | Treating all code paths as equally important |
| Dependencies | What external systems, APIs, or services does it touch? | Ignoring side effects and integrations |
| Edge cases | What unusual inputs or states could occur? | Only testing the happy path |
If existing tests, specs, or prior conversations exist, pull from them. Don't invent context.
Step 2: Apply the Testing Pyramid
More from kazdenc/builder-skills
design-brief
One-time setup that gathers design context for your project and saves it to your config file. Run once to establish persistent design guidelines.
30prd
Write a product requirements document from context. Covers problem statement, goals, scope, user stories, success criteria, and edge cases. Use when user says "write a PRD", "product requirements", "requirements doc", "spec this feature", "document requirements", or needs to define what to build and why.
17critique
Evaluate design effectiveness from a UX perspective. Use when user says "critique this design", "review the UX", "give design feedback", "is this good design", "design review", "evaluate this layout", or wants expert evaluative feedback on visual hierarchy, information architecture, and emotional resonance.
14security-scan
Check code for OWASP top 10 vulnerabilities including injection, XSS, auth issues, and secrets exposure. Use when user says "security audit", "check for vulnerabilities", "security scan", "is this secure", "OWASP check", "find security issues", or needs to verify code security before shipping.
13polish
Final quality pass before shipping. Fixes alignment, spacing, consistency, and detail issues. Use when user says "polish this", "final pass", "ready to ship", "fix the details", "pixel-perfect", "almost done", or when a feature is functionally complete but needs refinement.
13api-design
RESTful API design conventions covering URL structure, HTTP methods, error formats, pagination, versioning, and authentication patterns. Use when designing, reviewing, or implementing APIs. Triggers on API design, endpoint structure, REST conventions, or backend architecture tasks.
12