A code review that teaches instead of nitpicks
Reviews a diff at three altitudes — design, correctness, style — and explains the reasoning behind each note so the author learns something instead of just applying a patch.
Reads a function and enumerates the boundaries, empty states, and concurrency cases you didn't think of — then writes only the tests that could actually fail.
Find the cases I have not thought about. CODE: {{CODE}} STACK: {{STACK}} TESTS THAT ALREADY EXIST: {{EXISTING}} **1. Enumerate the input space.** For each parameter: the boundary values, the empty or zero case, the maximum, the malformed case, and anything nullable. Then the combinations that interact. **2. Beyond inputs.** Ordering and concurrency, partial failure, repeated calls (is this idempotent?), timezone and locale, and what happens if a dependency is slow rather than down. **3. Rank by "could this actually happen and would it hurt?"** Drop anything that is theoretically possible but harmless — say you dropped it and why. **4. Write the top tests** for {{STACK}}. Each test name states the behaviour, not the method name. Include the assertion that would fail today if the bug were present. Rules: - Do not write tests that restate the implementation. If a test would pass for any implementation of this signature, it is worthless — skip it. - Do not duplicate what already exists. - Do not mock the thing under test. - If a case cannot be tested without changing the code's shape, say so and say what change would make it testable.
Tools for this prompt
Where the input below comes from. The ones marked needed change the output a lot — fallbacks for each are further down.
This prompt is only as good as what you feed it. Web search covers anything public — these are the inputs it can't reach.
The function under test and the tests that already exist, so it doesn't duplicate them.
Don't have it: Ask the user to paste the diff or file directly.
Only tools that web search cannot replace are listed. Anything public — reviews, job ads, papers, salary data — an agent can already fetch, so it is not listed here. No paid placements or affiliate links; if that changes, this line will say so.
A prompt is a skill with the serial numbers filed off. Install it once and your agent reaches for it on its own.
Paste this into ChatGPT, Claude Code, Codex, Cursor, or whatever you use:
Install the the-test-you-would-have-forgotten skill globally from https://promptsbuddy.com/prompts/the-test-you-would-have-forgotten/skill.md.claude/skills/the-test-you-would-have-forgotten/SKILL.md
---
name: the-test-you-would-have-forgotten
description: "Reads a function and enumerates the boundaries, empty states, and concurrency cases you didn't think of — then writes only the tests that could actually fail. Use when the user asks for help with engineering tasks like testing, engineering, quality."
license: CC-BY-4.0
metadata:
source: https://promptsbuddy.com/prompts/the-test-you-would-have-forgotten
author: "Meghna"
version: "1.0"
---
# The test case you would have forgotten
Reads a function and enumerates the boundaries, empty states, and concurrency cases you didn't think of — then writes only the tests that could actually fail.
## Inputs to collect first
Ask the user for anything below that they have not already given you. Do not
invent values for these.
- `CODE` — The function or module under test, plus its types. (e.g. Paste the source.)
- `STACK` — Language and test framework, so the output is runnable. (e.g. TypeScript, Vitest, no mocking library.)
- `EXISTING` — Tests that already exist, so it doesn't duplicate them. 'None' is fine. (e.g. One happy-path test for the basic case.)
## Tools this works with
Do not require any of these. If one is unavailable, use the stated fallback and
say which input is missing rather than inventing it.
- **GitHub** (needed) — The function under test and the tests that already exist, so it doesn't duplicate them. If its MCP server is connected, fetch this yourself.
- Without it: Ask the user to paste the diff or file directly.
- https://github.com/
## Instructions
Find the cases I have not thought about.
CODE:
{{CODE}}
STACK: {{STACK}}
TESTS THAT ALREADY EXIST: {{EXISTING}}
**1. Enumerate the input space.** For each parameter: the boundary values, the
empty or zero case, the maximum, the malformed case, and anything nullable.
Then the combinations that interact.
**2. Beyond inputs.** Ordering and concurrency, partial failure, repeated calls
(is this idempotent?), timezone and locale, and what happens if a dependency is
slow rather than down.
**3. Rank by "could this actually happen and would it hurt?"** Drop anything
that is theoretically possible but harmless — say you dropped it and why.
**4. Write the top tests** for {{STACK}}. Each test name states the behaviour,
not the method name. Include the assertion that would fail today if the bug
were present.
Rules:
- Do not write tests that restate the implementation. If a test would pass for
any implementation of this signature, it is worthless — skip it.
- Do not duplicate what already exists.
- Do not mock the thing under test.
- If a case cannot be tested without changing the code's shape, say so and say
what change would make it testable.
## Notes from people who use this
- Section 1 is worth reading even if you write the tests yourself — the enumeration is the part humans skip.
- The 'would fail today' requirement filters out tests that assert nothing.
- Ask about idempotency explicitly for anything that touches money, email, or external APIs.
---
The test case you would have forgotten · by Meghna · v1.0
From PromptsBuddy — https://promptsbuddy.com/prompts/the-test-you-would-have-forgotten
Licensed CC BY 4.0.
Every prompt is also available at /prompts/the-test-you-would-have-forgotten/skill.md — see all install options.
Engineers skip boundary enumeration not because it is hard but because it is tedious, and tedium is exactly what to hand over. The model will list the empty array, the single-element array, the duplicate keys, and the timezone case without getting bored on case eleven.
The instruction that earns its place is "include the assertion that would fail today if the bug were present." Without it you get coverage-shaped tests that assert the code does what the code does, which is how suites end up green, enormous, and worthless.
Reviews a diff at three altitudes — design, correctness, style — and explains the reasoning behind each note so the author learns something instead of just applying a patch.
Forces the model to separate what the trace proves from what it's inferring, rank hypotheses by testability, and give you the cheapest experiment that discriminates between them.