Claude coding prompt pack for debugging, refactors, and architecture reviews

The four constraints that make every prompt below work

Before the prompts, the rules they all share. Adding these to any coding prompt improves the output more than changing model.

State your version. Training data skews toward whichever major version has the most written about it, which is often not the one you are on. We are on [framework] [version], [language] [version] prevents most outdated answers.

Constrain the diff. Ask for a fix and you frequently get a refactor. Change as little as possible, preserve existing structure and naming, and list every line you changed with a one line reason is the single most useful sentence in this document.

Ask for hypotheses before solutions. A model asked what is wrong gives you a guess delivered as a conclusion. A model asked for ranked causes and cheap checks gives you a debugging plan.

Require the failure mode. What could this break, and is this fixing the cause or the symptom? catches the most expensive class of AI assistance, which is a change that makes the symptom disappear while the defect stays.

Debugging

1. Ranked hypotheses

Here is the error, the relevant code, and what I have already ruled out. Do not give me a fix yet. List the four most likely causes ranked by probability, and for each the single cheapest check that would confirm or eliminate it. Error: [paste]. Code: [paste]. Already ruled out: [list]. Stack: [language, framework, versions].

2. The intermittent bug

This fails intermittently, roughly [frequency], under [conditions]. Enumerate the categories of intermittent failure that could produce this specific symptom: timing, ordering, resource exhaustion, an external dependency, state leaking between runs, clock or timezone, caching. For each, say what in the code supports or contradicts it, and exactly what I should log to distinguish them. Code: [paste].

3. It works locally

This works locally and fails in [environment]. List every category of environment difference that could cause this specific symptom: configuration, environment variables, versions, filesystem and case sensitivity, timezone and locale, network and DNS, permissions, resource limits, and build or bundling differences. Rank by likelihood given the symptom, and give me the diagnostic command for each.

4. Explain the fix before I take it

Explain why this fix works, what it does not fix, and what it could break. If the real cause is elsewhere and this is a symptom patch, say so directly.

Code review

5. Review a diff

Review this diff as a demanding reviewer. Categories in priority order: correctness bugs, security issues, unhandled failure modes, race conditions, then style. For each finding give severity, the specific line, and why it matters in this codebase rather than in general. Do not comment on formatting. If the diff is sound, say so rather than manufacturing findings. Conventions: [describe]. Diff: [paste].

6. The security pass

Review this code for security issues specifically: injection, authentication and authorisation gaps, unsafe deserialisation, secrets in code or logs, unvalidated input reaching a sensitive operation, and dependency risk. For each, give the attack path concretely rather than naming the category. State clearly what you cannot assess without seeing [deployment, auth layer, data sensitivity].

7. The failure mode audit

For each external call in this code, state what happens when it is slow, when it fails, when it returns unexpected data, and when it succeeds but partially. Which of those are currently unhandled, and which would be silent?

That last one finds more real production issues than a general review does, because it asks about the paths nobody wrote a test for.

Refactoring and architecture

8. The refactor plan

Propose a sequenced plan to refactor [description]. Constraints: the public API of [x] cannot change, we deploy continuously so every step must be independently shippable, and tests must pass after each step. For each step give the change, the risk, how to verify it, and how to roll it back. Order by risk, lowest first. Do not write the code yet.

9. Argue the other side

I am choosing [approach A] over [approach B] for [context and constraints]. Make the strongest case for B. What would have to be true about our constraints for B to be correct, and is any of it true here? Do not conclude that both are valid.

10. Understand what you inherited

Here are the main source files. Produce: the entry points, the data flow from request to response, the state that is shared and where it is mutated, external dependencies and what happens when each is unavailable, and the three areas most likely to contain bugs based on complexity and coupling. State explicitly what you cannot determine from what I provided.

That final instruction matters. Models will describe the behaviour of a file you did not paste, inferred from its name. Forcing an explicit list of unknowns tells you what to go read.

Tests

11. The tests you would not have written

Write test cases for this function, focusing on inputs I probably have not considered: boundaries, empty and null, unicode, very large values, concurrent calls, and any implicit assumption in the implementation. For each test, state the assumption it is checking. Function: [paste].

12. Test the test suite

Here is a function and its existing tests. What behaviour is not covered? Specifically: error paths, boundary values, interactions between parameters, and anything the implementation does that no test asserts. Do not rewrite the existing tests.

The second is the higher-value prompt and it is rarely run. Coverage percentages tell you which lines executed, not which behaviours are actually pinned down, and the gap between those two is where regressions live.

The second-opinion pattern

The highest-leverage habit in this whole pack, and the one that requires more than one model.

Get an answer from one model. Then switch and hand it over:

Another engineer proposed this solution to this problem. Find what is wrong with it: correctness under edge cases, concurrency, error handling, performance at [scale], or a simpler approach that was missed. If it is genuinely sound, say so plainly rather than inventing objections. Problem: [paste]. Proposed solution: [paste].

Two outcomes and both are useful. Either the second model finds a real hole, which you now know before merging, or it agrees despite being pushed to disagree, which is meaningful confirmation. Iterating with the same model gives you neither, because a model reviewing its own output mostly agrees with itself.

Use it on the decisions that would be expensive to get wrong: a schema change, a concurrency fix, anything touching auth or money. Not on routine work. See comparing models side by side, switching models mid-conversation, and write and debug code with multiple models for the whole workflow in one place.

What to watch for

Invented APIs. Confident method names, parameters, and config keys that do not exist, especially for libraries that changed recently. The signature will look right. Check the real documentation before building on anything unfamiliar.

No confidence signal. A correct fix and a subtly wrong one arrive with identical certainty. Tone tells you nothing.

Silent scope creep. This is what constraint two exists for.

Security theatre. Naming vulnerability classes in your code is a useful first pass. It is not an audit, and the model does not know your threat model, deployment, or data sensitivity.

Keep the prompts you use weekly somewhere you can paste from, and put standing constraints in a project's instructions so they apply to every chat in that project automatically.