Skip to content
Back to skills

In Debug

ASecurity

Systematic debugging: 4-phase process with 3-strike architectural review

  • 26 stars
  • 0 votes
  • 0 copies
  • 4 views
  • Added May 27, 2026
researchgotestingdebugginggit

Security analysis

A100/100

Scanned May 27, 2026

npx -y skills add matthewsinclair/intent --skill in-debug --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of In Debug?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for In Debug
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/matthewsinclair-in-debug/badge)](https://www.skillsdirectory.com/skills/matthewsinclair-in-debug)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
description: "Systematic debugging: 4-phase process with 3-strike architectural review"
chains_to: ["in-verify"]
---

# Systematic Debugging

Follow this procedure when investigating any bug or unexpected behavior. Do not skip phases.

## Procedure

### Phase 1: Reproduce and gather evidence

1. Read the actual error message. Do not guess what it says.
2. Reproduce the issue. If you cannot reproduce it, you cannot fix it.
3. Check recent changes (`git log --oneline -10`, `git diff`)
4. Identify the exact file and line where the error occurs
5. Document: what was expected, what happened, exact error output

### Phase 2: Pattern analysis

1. Find working code that does something similar
2. Compare the broken code against the working code line by line
3. Check if this is a known pattern (search issues, git blame the area)
4. Look for recent changes to dependencies or config that could cause this

### Phase 3: Hypothesis testing

1. Form ONE hypothesis about the root cause
2. Test ONLY that hypothesis -- change one variable at a time
3. If the hypothesis is wrong, revert the change before trying the next one
4. Document each hypothesis and its result

NEVER change two things at once. NEVER leave a failed fix in place while trying the next one.

### Phase 4: Fix and verify

1. Write a test that reproduces the bug (if testable)
2. Implement the fix
3. Run the reproducing test -- it must pass
4. Run the broader test suite -- no regressions
5. Invoke `/in-verify` to confirm

## The 3-Strike Rule

If 3 consecutive fix attempts fail for the same issue:

1. STOP attempting fixes
2. Present the pattern of failures to the user:
   - What was tried
   - Why each attempt failed
   - What this pattern suggests
3. Ask: "Is the approach itself wrong? Should we reconsider the architecture?"
4. Do NOT attempt a 4th fix without explicit user direction

This rule prevents thrashing. Three failed fixes usually means you are solving the wrong problem.

## Red Flags

| Rationalization                      | Reality                                                         |
| ------------------------------------ | --------------------------------------------------------------- |
| "Let me just try one more thing"     | That's what you said 3 fixes ago. Stop and think.               |
| "I think I know what it is"          | Thinking is not knowing. Reproduce first.                       |
| "The fix is obvious"                 | Obvious fixes don't need 3 attempts. Something deeper is wrong. |
| "I'll clean up the debug code later" | Remove debug artifacts before committing. Now.                  |

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.