Spec → Test Plan
Turn a feature spec or ticket into a structured test plan covering happy paths, edge cases, and negative cases. Use when asked to write test cases, derive QA coverage, or check whether acceptance criteria are testable.
Copy the file into your agent runtime. Cursor loads personal skills from ~/.cursor/skills/spec-to-test-plan/SKILL.md and project skills from .cursor/skills/spec-to-test-plan/SKILL.md. Claude Code looks in .claude/skills/spec-to-test-plan/SKILL.md.
Spec → Test Plan
When to use
A written spec or ticket needs a test plan before implementation starts. Triggers: write test cases for this, what should we test, are these acceptance criteria testable.
What it does
Derives testable behaviors from the spec and organizes them into happy-path, edge-case, and negative/failure cases, each with preconditions, steps, and expected result. Flags any acceptance criterion that is not observable or measurable.
Steps
- Extract every acceptance criterion; number them.
- For each, write at least one happy-path case.
- Enumerate boundaries (empty, max, min, off-by-one) as edge cases.
- Add negative cases: invalid input, unauthorized access, dependency failure.
- Map each case back to the criterion it verifies; flag uncovered criteria.
Output
A table: ID | Criterion | Type | Preconditions | Steps | Expected. Then a coverage gap list.
Guardrails
If a criterion cannot be tested as written (e.g. "should feel fast"), do not invent a threshold — flag it and request a measurable target. Coverage claims must trace to a numbered criterion.