Prompt library
Derive test cases from a spec
Deriving the matrix before writing code keeps coverage systematic instead of vibes-driven, and the [SPEC?] discipline routes ambiguity back to the spec author instead of baking the model's guess into your test suite as truth. Hostile-QA cases surface the gaps specs systematically miss.
Last reviewed July 17, 2026
The prompt
Derive test cases from the spec below.
Spec: {{spec}}
Test framework and level: {{framework}}
Produce:
1. A test matrix table first: behavior, input class, expected outcome, priority. Cover the happy path, each boundary named or implied by the spec, invalid inputs, state-dependent cases, and concurrency or ordering if the spec touches them.
2. Ambiguity list: every place the spec does not define an outcome. Write the test name you would want, then STOP and mark it [SPEC?]; do not pick an expected value yourself.
3. Code for the priority-1 tests in the given framework, one assertion of behavior per test, names that read as sentences.
4. The 3 nastiest cases a hostile QA would try that the spec author probably did not think about.
Do not test implementation details; test the contract.Run in idaptOpens a new chat with the prompt prefilled. Nothing sends until you press send.
Fill in the variables
| Variable | What it is | Example |
|---|---|---|
| {{spec}} | The spec, user story, or acceptance criteria | [paste the spec section] |
| {{framework}} | Framework and test level | vitest, unit level |