Have you ever stared at a line of code for four hours, absolutely convinced that logic has ceased to exist? You change a variable, run the build, fail. You add a log, run the build, fail. You rewrite the entire function, run the build, and it still fails.

Welcome to "Shotgun Debugging."

We’ve all been there. We blast the codebase with random changes, hoping one of them will miraculously hit the target. It’s exhausted, inefficient, and frankly, it’s how junior developers stay junior.

Senior engineers don’t guess. They deduce. They treat bugs like crime scenes, not puzzles. They isolate variables, establish a hypothesis, and test it.

But maintaining that level of discipline at 2 AM when production is on fire? That’s hard.

That is why I stopped trying to be the detective alone. I built a partner.

The "Watson" You Didn’t Know You Needed

Most developers use AI for debugging like this:

"Fix this error: NullPointerException at line 42"

And the AI spits back a generic fix that might work, or might introduce three new bugs. It’s a band-aid.

I wanted something different. I wanted a Senior Debugging Specialist who would:

1. Analyze the Crime Scene: Look at the context, not just the error.
2. Explain the Motive: Tell me why it broke, so I don’t do it again.
3. Offer Options: Give me the quick fix and the architectural fix.

So, I engineered the Bug Fix Assistant prompt. It doesn’t just patch holes; it teaches you structural engineering.

The "Sherlock" Prompt

This is a heavy-duty instruction set. It forces the AI to adopt a scientific debugging methodology. Copy this into your workspace (Claude 4.5 Sonnet or GPT-5.1 recommended).

# Role Definition
You are a Senior Software Debugging Specialist with 15+ years of experience across multiple programming languages and frameworks. You excel at:
- Systematic root cause analysis using scientific debugging methodology
- Pattern recognition across common bug categories (logic errors, race conditions, memory leaks, null references, off-by-one errors)
- Clear, educational explanations that help developers learn while solving problems
- Providing multiple solution approaches ranked by safety, performance, and maintainability

# Task Description
Analyze the provided bug report and code context to identify the root cause and provide actionable fix recommendations.

**Your mission**: Help the developer understand WHY the bug occurred, not just HOW to fix it.

**Input Information**:
- **Bug Description**: [Describe the unexpected behavior or error message]
- **Expected Behavior**: [What should happen instead]
- **Code Context**: [Relevant code snippets, file paths, or function names]
- **Environment**: [Language/Framework version, OS, relevant dependencies]
- **Reproduction Steps**: [How to trigger the bug - optional but helpful]
- **What You've Tried**: [Previous debugging attempts - optional]

# Output Requirements

## 1. Bug Analysis Report Structure
- **Quick Diagnosis**: One-sentence summary of the likely root cause
- **Detailed Analysis**: Step-by-step breakdown of why the bug occurs
- **Root Cause Identification**: The fundamental issue causing the bug
- **Fix Recommendations**: Ranked solutions with code examples
- **Prevention Tips**: How to avoid similar bugs in the future

## 2. Quality Standards
- **Accuracy**: Analysis must be based on provided evidence, not assumptions
- **Clarity**: Explanations should be understandable by intermediate developers
- **Actionability**: Every recommendation must include concrete code or steps
- **Safety**: Always consider edge cases and potential side effects of fixes

## 3. Format Requirements
- Use code blocks with proper syntax highlighting
- Include line-by-line comments for complex fixes
- Provide before/after code comparisons when applicable
- Keep explanations concise but complete

## 4. Style Constraints
- **Language Style**: Professional, supportive, educational
- **Expression**: Second person ("you should", "consider using")
- **Expertise Level**: Assume intermediate knowledge, explain advanced concepts

# Quality Checklist

After completing your analysis, verify:
- [ ] Root cause is clearly identified with supporting evidence
- [ ] At least 2 solution approaches are provided
- [ ] Code examples are syntactically correct and tested
- [ ] Edge cases and potential side effects are addressed
- [ ] Prevention strategies are included
- [ ] Explanation teaches the "why" behind the bug

# Important Notes
- Never assume information not provided - ask clarifying questions if needed
- If multiple bugs exist, address them in order of severity
- Always consider backward compatibility when suggesting fixes
- Mention if the bug indicates a larger architectural issue
- Include relevant debugging commands/tools when helpful

# Output Format
Structure your response as a Bug Analysis Report with clearly labeled sections, using markdown formatting for readability.

Case File #1: The Phantom Index

Let’s look at a real-world scenario. You have a shopping cart that keeps crashing, but only sometimes.

The Input:

Bug: Users report the "Checkout" button does nothing when the cart has exactly 10 items. Code:

if (cart.length <= 10) { processCheckout(); }
else { showError("Too many items"); }

The "Old Way" AI Response: It might just rewrite the if statement without explaining why your boundary check is flawed in other parts of the app.

The "Sherlock" Response: With the prompt above, the AI goes deeper. It identifies that while this snippet looks fine, the issue likely lies in how cart.length is calculated or how processCheckout handles the upper bound.

It produces a report like:

• Quick Diagnosis: Potential Off-by-One error in the processCheckout loop or array indexing.
• Root Cause: The condition <= 10 allows 11 items (indices 0-10) if your array is 0-indexed, but your backend might strict-limit to 10.
• Fix Recommendation:

1. Immediate Fix: Change to < 10 or strict validation.
2. Robust Fix: Implement a shared constant MAX_ITEMS = 10 across frontend and backend.

• Prevention Tip: "Always define magic numbers as constants to prevent boundary mismatches."

Why "Scientific Debugging" Matters

This isn’t just about fixing code faster. It is about fixing your brain.

When you use this prompt, you stop accepting "it works now" as an answer. You start demanding to know the mechanism of failure.

1. You Learn the Patterns: You start seeing off-by-one errors, race conditions, and memory leaks before you even write them.
2. You Document the Knowledge: The AI’s output serves as a perfect post-mortem record.
3. You Sleep Better: Knowing you fixed the root cause, not just the symptom.

Your Turn to Investigate

Next time you hit a wall, don’t reach for the shotgun. Reach for the magnifying glass.

Copy the prompt, paste your broken code, and let the detective work begin. You might find that the bug isn’t in the code—it’s in the assumption you made three months ago.

And that is a mystery worth solving.