Skip to content
Back to skills

Debugging

ASecurity

Structured debugging protocol. Use when investigating a bug, failing test, regression, unexpected behavior, or any scenario where code is not doing what it should. Trigger phrases include "broken", "not working", "bug", "error", "it worked before", "still broken", "why is this failing", "trace", or "/trace".

  • 2 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added May 27, 2026
data-aigodebugginggit

Security analysis

A100/100

Scanned May 27, 2026

npx -y skills add stuartshields/claude-setup --skill debugging --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Debugging?

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

Security grade badge for Debugging
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/stuartshields-debugging/badge)](https://www.skillsdirectory.com/skills/stuartshields-debugging)

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
---
name: debugging
description: Structured debugging protocol. Use when investigating a bug, failing test, regression, unexpected behavior, or any scenario where code is not doing what it should. Trigger phrases include "broken", "not working", "bug", "error", "it worked before", "still broken", "why is this failing", "trace", or "/trace".
---
<!-- Last updated: 2026-04-08T00:00+11:00 -->

# Debugging & Investigation

## 4-Step Framework: Reproduce → Isolate → Fix → Validate
- **Never skip to Fix.** Most wrong fixes come from jumping straight to code changes.
- **Reproduce:** Run the faulty scenario. Note the exact error and conditions.
- **Isolate:** Narrow down the failing component. 80% of bugs live in recently modified code — start there. **Compare against working code.** Find similar functionality that works and diff against the broken code.
- **Validate:** Run the full test suite. Confirm the error is gone AND no regressions introduced.

## Validate Before Fixing
- **Confirm root cause before proposing code changes.** One hypothesis at a time — test the most likely first.
- **Explain root cause in writing** (file path, line number, actual vs expected behavior) before proposing code changes.
- **Test means run code, not reason in your head.** Execute a command, write a failing test, or check real output.
- **Read the user's evidence first.** Study screenshots/errors before forming hypotheses. The answer is usually visible.
- **Add `console.error` to trace actual behavior** when reasoning about what code "should" do isn't working. Reading code is not observing behavior.
- **Red flag phrases.** Catch yourself saying "This should work", "Let me just try...", or "Quick fix for now" — stop and re-evaluate. You're guessing.

## Anti-Loop Protocol
- **Each attempt MUST use a different diagnosis.** If attempt 1 failed, don't vary the fix — vary the diagnosis. Two attempts targeting the same component with the same assumption count as one diagnosis, even if the code changes differ.
- **After 2 failed fix attempts, STOP.** State what you tried, what each ruled out, and ask the user for context. If the user says "still broken" twice, you've failed twice.
- **Clear polluted context.** After hitting the limit, recommend `/clear` — failed attempts in context actively degrade subsequent reasoning.
- **Watch for oscillation.** Fixing A breaks B and vice versa = contradictory constraints. Stop and surface the conflict.
- **Revert as escape hatch.** When debugging spirals, revert to last known good commit rather than stacking fixes on failed attempts.

## Regression Shortcut
- **"It worked before" → `git bisect` first.** Don't read code to find regressions — bisect to the breaking commit, then read that diff.

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…