DEV Community

Seb
Seb

Posted on

The Claude Prompt Pattern That Kills Debugging Spirals

#claude #debugging #ai #productivity

You know the feeling. You've been staring at a bug for 45 minutes. You've console.log'd everything. You've Googled the error message. You're starting to question reality.

Then you paste the error into Claude and get: "It looks like there might be an issue with your variable scope. Try checking if the variable is defined before use."

Useless.

Here's why that happens — and a prompt pattern that fixes it.

The problem: Claude defaults to solution mode

When you drop a raw error into Claude, it pattern-matches to the most common fix for that error shape. It's not thinking about your system. It's retrieving a generic answer.

What you actually need is a structured diagnostic — not a guess. You need Claude to reason through the problem the way a senior engineer would: gathering information, forming hypotheses, ranking them by likelihood, and telling you how to verify each one before touching any code.

The fix is shifting Claude from answer mode into hypothesis mode.

The prompt 

<debugging_session>
  <error>
    [Paste the full error message and stack trace]
  </error>

  <context>
    [What were you doing when this broke? Recent changes?]
    [What's the component/system involved?]
    [What have you already tried?]
  </context>

  <code>
    [Paste the relevant code — function, component, or module]
  </code>
</debugging_session>

Generate 3-5 hypotheses for what's causing this bug. For each:
- State the hypothesis clearly
- Explain the reasoning (why this would produce this error)
- Give me a specific verification step BEFORE any code change
- Rate likelihood: High / Medium / Low

Do not suggest fixes yet. I want to understand the problem first.
Enter fullscreen mode Exit fullscreen mode

The last line is the key instruction. It forces Claude to slow down and think instead of reaching for a solution.

What you get back

Instead of a generic fix, you get something like:

Hypothesis 1 (High): The userId claim is being read from the JWT before the token has been verified. If middleware order changed recently, the route handler might be executing before auth validation completes...
Verify: Log req.user at the top of the handler and check if it's undefined on first request.

Hypothesis 2 (Medium): Race condition between session creation and the database write. The session object exists in memory but the DB commit hasn't resolved...
Verify: Add a 200ms artificial delay after login and see if the error disappears.

Now you're debugging with a map instead of a metal detector.

Why XML structure matters here

Claude handles XML-tagged input differently than plain text. When you wrap context in <error>, <context>, and <code> tags, Claude treats each section as a distinct input — it doesn't conflate your error message with your code or your code with your description of what you tried.

With plain prose, Claude often fixates on whichever detail appears most prominent. With tagged input, it reasons across all of them.

Adding your CLAUDE.md context

If you've set up a CLAUDE.md file at your project root (the persistent context file Claude reads at the start of every session), your system context is already loaded. That means Claude knows your stack, your auth setup, your conventions — and the hypotheses it generates will be specific to your codebase, not a generic Node.js app.

When your CLAUDE.md includes something like:

## Auth
JWT via jose library. Tokens validated in middleware/auth.ts before routes.
Session stored in Redis with 24h TTL.
Enter fullscreen mode Exit fullscreen mode

...Claude's first hypothesis won't be "maybe you forgot to validate the token." It already knows your auth layer. It'll reason at a higher level.

The discipline: verify before you fix

The other thing this prompt enforces is the one habit that separates senior engineers from junior ones: verify your hypothesis before touching code.

Every time you add the instruction "do not suggest fixes yet", you're forcing yourself into that discipline too. You run the verification step. You confirm which hypothesis is correct. Then you ask Claude to help you fix that specific thing — with full context — instead of shotgunning random solutions.

It's slower for the first five minutes. It's faster for the next hour.

I put this prompt (with a few more variations — the flaky test fixer, the log analyzer, the incident responder) into a kit I built for my own workflow. If you want the full set: 50 Claude Prompts for Developers — 50 XML-structured prompts + a 20-page guide on using Claude as a daily engineering partner.

But the prompt above works on its own. Try it on the next bug you hit.

Top comments (0)