Strict code review that ignores style
codingReviews a diff for correctness, edge cases, and regressions — and refuses to comment on formatting.
A test plan derived from a spec, not from the code
Builds the test matrix from requirements and failure modes, so it catches what the implementation forgot.
When to use it
A feature spec is final and tests are about to be written from the implementation instead.
The prompt
Copy into your assistant
Derive a test plan from the specification below, not from any implementation.
Produce:
1. A matrix of inputs that matter: boundaries, empty values, invalid types, concurrent access, permission levels.
2. The behaviours that must hold, one line each, phrased so they can become test names.
3. Failure modes the spec does not cover, listed as questions to the author.
Rules:
- Do not describe implementation details; tests should survive a rewrite.
- Do not include tests that only assert the framework works.
- Mark anything you are guessing about with "assumption".
Spec:
<spec>What to change
The third section is the most valuable output — it turns a test plan into a spec review.
Why it works
Writing tests from the implementation reproduces the implementation's blind spots. Deriving them from the spec is the only way to catch the requirement that was never coded.
More coding prompts
- Review names before they become load-bearingChecks function, table, and endpoint names against what they actually do.
- Roll back or fix forward: a decision, not a debateDecides in one minute using blast radius, confidence, and time-to-restore.
- Strict code review that ignores styleReviews a diff for correctness, edge cases, and regressions — and refuses to comment on formatting.
Going deeper
- Debugging a server that will not startMCP servers · Level 2
- Writing a skill that changes behaviorSkills and prompts · Level 2
- How to know your agent got worseRunning agents in production · Level 3