Verified against Claude Code · 2026-07-30
Lock Claude Code to the minimal fix and stop the drive-by refactor
A constraint block for a bug report that pins Claude Code to exactly the acceptance criteria stated, with an explicit list of what counts as scope creep even when the extra change looks like an improvement.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are fixing exactly one bug, nothing else. You are not refactoring, renaming, reformatting, or adding an abstraction anywhere in this file or repository, even if you notice something else nearby that looks wrong while you are in there — name it separately instead of touching it. BUG Clicking Export CSV on the reports page throws a TypeError reading toFixed of undefined whenever a report has zero matching rows. ACCEPTANCE CRITERIA 1. Exporting a zero-row report downloads a CSV with headers only, no error thrown. 2. Exporting a report with rows is completely unchanged. 3. No new console errors or warnings appear in either case. EXPECTED BLAST RADIUS lib/reports/export.ts and, if a test needs to be added, tests/reports/export.spec.ts — nothing else should need to change. RELEVANT HISTORY This exact function had a similar off-by-one bug fixed three months ago; check whether this is a regression of that fix rather than a new bug. CONSTRAINTS - Change only what is required to satisfy every item in the acceptance criteria above, and nothing else. If satisfying a criterion genuinely requires touching a file outside the expected blast radius above, stop and explain why before making that change, rather than making it and explaining afterward. - Do not rename variables, extract functions, reformat unrelated lines, upgrade a pattern to a newer idiom, or add speculative error handling, logging, or validation for a case that is not in the bug report, even where doing so would objectively be an improvement — this pass has one job. - Do not add a new dependency, new config, or new file unless the bug is provably unfixable without one; if so, stop and state why before writing any code. - If the acceptance criteria conflict with each other, or with something already true elsewhere in the codebase, say so and stop rather than silently picking whichever interpretation is easier to implement. - Before writing the fix, check This exact function had a similar off-by-one bug fixed three months ago; check whether this is a regression of that fix rather than a new bug. for whether this exact defect has appeared before; if it has, the fix must also explain why the earlier fix did not hold, not just apply a second patch on top without accounting for why the first one was incomplete. OUTPUT FORMAT 1. One-sentence root cause, stated as a mechanism, not a symptom restatement — the actual defective logic, not just a restatement of what a user observed. 2. The diff, and only the diff. 3. A line mapping each changed line to the specific acceptance criterion it satisfies. Any changed line that does not map to a criterion is, by definition, out of scope and should not exist in the diff. 4. A closing line: either 'No other changes were made.' or a named exception with the specific reason it was unavoidable, not a vague 'also cleaned up a few things.' If, while diagnosing this bug, you notice a second, unrelated issue nearby, note it in one sentence at the very end under a heading 'Noted but not fixed' rather than fixing it silently or omitting it entirely — a bug you saw and chose not to touch should be visible, not invisible.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Agentic coding assistants with real Edit access are documented to expand scope opportunistically — once a model is already inside a file, it tends to clean up adjacent code unless explicitly told not to, because the same helpfulness training that makes it useful also makes it reason about 'is this a good change' rather than strictly 'is this the change that was asked for', and almost any tidy-up passes the first test even when it should have failed the second. Naming the negative space directly — do not rename, do not reformat, do not add an abstraction — closes exactly the loopholes a vaguer 'just fix the bug' leaves open, since Claude follows explicit, direct constraints far more reliably than it infers a scope boundary from context alone. The line-to-criterion mapping requirement converts a subjective 'good enough' into a checkable exit condition: the model verifies its own diff against a list rather than deciding on its own when it is done, which is precisely the moment scope creep otherwise starts, because 'done' and 'also improved a few things nearby' feel identical from inside a single editing session. The 'noted but not fixed' section matters because it gives a legitimate, sanctioned outlet for the observation instinct instead of demanding its total suppression, which is more likely to actually hold under pressure than a bare prohibition — the model still gets to demonstrate it noticed something worth attention, just without acting on it unilaterally, and a human reviewing the fix gets a heads-up about a second issue instead of neither a fix nor a mention of it. Checking regression history before writing the fix matters for a distinct reason: a model with no memory of this codebase's past incidents will treat every bug as freshly discovered, and a second patch stacked on a defect that already has one failed fix behind it, without asking why the first one did not hold, tends to repeat the same incomplete reasoning rather than actually closing the gap the earlier fix missed.
What you get back
1. Root cause: the average-rows calculation divides row count by a total that can be zero, producing NaN, and NaN.toFixed throws. 2. Diff: - const avg = (rows.length / total).toFixed(1) + const avg = total === 0 ? '0.0' : (rows.length / total).toFixed(1) 3. This line satisfies criterion 1 (zero-row export no longer throws) and criterion 2 (non-zero path unchanged). 4. No other changes were made. Noted but not fixed: the same file has an unrelated console.log left in from debugging on line 58 — flagging it, not removing it in this pass.
Verified against
Claude Code Sonnet 4.6 · 2026-07-30
Changelog
- 2026-07-30 — Initial publish, verified against Claude Code (Sonnet 4.6).
Building this for real?
This is a free starting point. If you'd rather have custom software built and running for your business, that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
