What this prompt does
This prompt turns the model into a senior engineer who pairs with QA, translating a product [user_story] into precise, testable behavior plus real test stubs in [test_framework]. You supply the story, the framework, the [roles] in play, and the known [rules], and it returns numbered Given/When/Then acceptance criteria followed by a copy-ready test skeleton.
What makes it useful is the breadth it forces. Beyond the happy path, it demands permission edge cases per role, validation-failure scenarios for each business rule, at least one concurrency scenario where two actors collide, and one negative test per rule. The [roles] variable drives the permission scenarios and [rules] drives the validation and negative tests, so the coverage scales with the real complexity of your feature rather than the obvious cases.
The value of doing this before estimating is that it makes "done" concrete. A story stays contested until the criteria are written down, and the scenarios that catch real bugs are the permission and concurrency ones people forget to spec. By generating the test skeleton in the same pass, the prompt closes the gap between agreeing on behavior and verifying it, so the criteria are not just documentation but a structure your implementation has to satisfy. The instruction to return real stubs rather than a description of testing is deliberate, since prose about coverage rarely survives contact with the codebase.
When to use it
- "Done" for a feature is contested until the criteria are written down.
- You want acceptance criteria before estimating, not after a bug report.
- A feature has multiple
[roles]whose permissions need explicit scenarios. - Business
[rules]like limits or uniqueness need validation and negative tests. - Concurrency matters and you want a collision scenario specced upfront.
- You want test stubs in
[test_framework]ready to fill, not a prose description.
Example output
Expect two blocks. First, numbered Given/When/Then acceptance criteria: the happy path, then per-role permission scenarios from [roles], validation failures for each of the [rules], a concurrency collision, and negative tests. Second, a test file skeleton in [test_framework] with descriptive test names, empty bodies, and the intended assertions described in comments, ready to drop into the project and implement.
Pro tips
- Write the
[user_story]in real product language; vague stories yield vague criteria. - List every relevant role in
[roles], since each one becomes its own permission scenario and missing roles mean missing coverage. - State all enforceable
[rules]explicitly so validation and negative tests get generated for each. - Match
[test_framework]to your actual stack so the skeleton is copy-ready, not pseudo-code you must port. - Implement the negative and concurrency tests first; they expose assumptions hiding in the happy path.
- Use the comments in the stubs as a spec, filling assertions before adding implementation.
