First-party only — a session id and where you arrived from, so we can tell which pages are worth writing more of. No advertising, no third-party trackers, nothing that follows you off this site.
The prompt arsenal for the unglamorous half: review, debug, refactor, backfill.
Writing new code is the easy half. This pack is the other half — the passes you run on code that already exists, whether an agent wrote it or you did. Each prompt is scoped to find one class of problem well rather than everything badly.
One-time. Yours permanently, including every future update.
You’ll enter your email first — a purchase has to be attached to an account so it does not get lost. It takes about fifteen seconds and brings you straight back here.
Nothing is hidden until after you pay. This is the complete contents. Files marked readable can be opened in full right now, without an account.
Why single-purpose passes beat one big review, and which ones to run for a given change.
Eleven single-purpose passes. Each looks for one class of problem and demands a concrete failing scenario for every finding.
Undocumented decisions, off-by-one, null/empty, conversions, logic inversion, state.
Swallowed errors, lost context, cleanup on the error path, partial state, timeouts.
Read-modify-write, check-then-act, lock discipline, async ordering, idempotency.
N+1, unbounded results, missing indexes, transaction boundaries, injection.
Object-level checks, client-supplied identity, new surface, enumeration, mass assignment.
Boundary parsing, missing limits, coercion, allow lists, injection sinks, encoding.
Breaking changes including the silent ones, versioning, and the compatibility window.
Lock analysis, rolling-deploy safety, reversibility, batched backfills.
The four states, races, stale data, source of truth, navigation, accessibility.
Is it needed, what came with it, maintenance risk, lockfile drift, advisory triage.
The 3am test, silent failures, log content and volume, metrics, alerting.
Reproduce before diagnose. The habit that stops confident wrong theories from becoming commits.
Four stages: reproduce, locate with citations, fix minimally, confirm it was the cause.
Finding the commit, why the introducing commit is often not the cause, and when bisect will not work.
Changes with an explicit boundary, and the proof that nothing else moved.
The pre-flight list, stepwise execution, and why a refactor that changes a test is not a refactor.
Dynamic construction, names that cross a boundary, and the verification sweep.
Backfill that targets behaviour, and an audit that finds the tests which would not catch a bug.
Rank before writing, the six rules, and the break-it-on-purpose step that makes tests real.
Six audit questions plus manual mutation testing when you have no tool.
A library upgrade across hundreds of call sites, done in reviewable batches.
Inventory first, batch commits, the skipped sites, and sweeping for what compiles and is wrong.
What is in the pack, and the table of which passes a given change needs. This is the actual file, not an excerpt.
# Review & Repair
The prompt arsenal for the unglamorous half.
Writing new code is the easy half. This pack is the other half — the passes
you run on code that already exists, whether an agent wrote it or you did.
## Why single-purpose passes
Asking for "a code review" gets you a list that is 60% style opinions, 30%
things you already knew, and 10% real — and you cannot tell which is which,
so you read all of it.
Each prompt here looks for **one class of problem**. Run three of them and
you get three focused lists instead of one long ambiguous one. You also get
to choose: a UI change does not need the concurrency pass.
## What is here
review/ Eleven single-purpose review passes
debug/ A protocol that reproduces before it diagnoses
refactor/ Changes with an explicit blast radius
tests/ Backfill that targets behaviour, not coverage
migration/ Library upgrades across a large codebase, file by file
## The rule that applies to all of them
**Run the review in a context that did not write the code.**
Self-review inside the implementing session is close to worthless — the
model has just spent an hour establishing that the implementation is right.
Fresh session, paste the diff, no history.
## Which passes to run
| Change | Passes |
|---|---|
| Any change | correctness, error-handling |
| Touches a database | data-access, migrations |
| Touches auth or user input | auth-boundaries, input-validation |
| Public API or client-facing | api-contract |
| Anything concurrent or async | concurrency |
| Frontend | frontend-state |
| Adds or upgrades a package | dependencies |
| Anything going to production | observability |
Two or three passes is normal. Running all eleven on a small change wastes
your attention, which is the scarce resource.
## Licence
Yours to use in any project, personal or commercial. Do not resell or
republish the files themselves.14-day refund, no explanation needed. If it does not earn its price, say so and we send the money back.