
Debugger
Run a structured debug ritual on failures, stack traces, and flaky prod behavior instead of guessing in chat.
Overview
Debugger is an agent skill most often used in Operate (also Ship, Build) that guides systematic hypothesis-driven debugging for errors, crashes, and unexpected behavior.
Install
npx skills add https://github.com/shubhamsaboo/awesome-llm-apps --skill debuggerWhat is this skill?
- Four-phase debugging process: understand problem, gather evidence, rank hypotheses, test with binary search
- Checklists for reproduction, recent changes, environment, and input data before touching code
- Guidance for stack traces, logs, crash dumps, and intermittent timing or dependency issues
- Explicit expected-vs-actual framing to avoid fix loops without a confirmed root cause
- Usable on local bugs, CI failures, and production incidents with the same workflow
- Four-step systematic debugging process (understand, gather, hypothesize, test)
Adoption & trust: 2.7k installs on skills.sh; 114k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You see an error or wrong behavior but keep patching symptoms without reproducing the issue or proving which hypothesis is actually true.
Who is it for?
Solo builders who want a consistent debug conversation when stack traces, logs, or flaky behavior show up across local, CI, or production.
Skip if: Greenfield feature work with no failure signal, or cases where you already have a verified root cause and only need mechanical refactoring—skip the full ritual then.
When should I use this skill?
Debugging errors, troubleshooting bugs, investigating crashes, analyzing stack traces, fixing broken code, or when the user mentions debugging, error, bug, crash, or "not working".
What do I get? / Deliverables
You end with a ranked root cause, evidence from logs and repro steps, and a targeted fix plan instead of speculative churn.
- Documented expected vs actual behavior and reproduction notes
- Ranked hypothesis list with evidence for/against each
- Targeted fix or next verification step tied to the confirmed cause
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Production incidents, log triage, and root-cause work map cleanly to Operate—even though the same process applies when tests fail or local code breaks. Errors is the canonical shelf for investigating crashes, intermittent failures, and “not working” behavior with systematic hypothesis testing.
Where it fits
A test suite fails after a dependency bump and you need ordered hypotheses before changing production code.
Error rates spike after deploy and you triage logs and environment drift to find the failing code path.
An API returns wrong data locally and you reproduce with specific inputs before applying a minimal fix.
A reviewer reports inconsistent behavior and you gather expected vs actual evidence before the next patch.
How it compares
Use as a structured debugging workflow, not as a substitute for automated tests or APM dashboards.
Common Questions / FAQ
Who is debugger for?
Indie and solo developers using Claude Code, Cursor, or similar agents who need disciplined help when code errors, crashes, or odd runtime behavior appear.
When should I use debugger?
Use it when investigating bugs or unexpected behavior, during Ship when tests or review uncover regressions, in Build while fixing broken integrations, and in Operate when analyzing production logs, incidents, or intermittent failures.
Is debugger safe to install?
It is procedural guidance only; review the Security Audits panel on this Prism page before installing any skill from the catalog.
SKILL.md
READMESKILL.md - Debugger
# Debugger You are an expert debugger who uses systematic approaches to identify and resolve software issues efficiently. ## When to Apply Use this skill when: - Investigating bugs or unexpected behavior - Analyzing error messages and stack traces - Troubleshooting performance issues - Debugging production incidents - Finding root causes of failures - Analyzing crash dumps or logs - Resolving intermittent issues ## Debugging Process Follow this systematic approach: ### 1. **Understand the Problem** - What is the expected behavior? - What is the actual behavior? - Can you reproduce it consistently? - When did it start happening? - What changed recently? ### 2. **Gather Information** - Error messages and stack traces - Log files and error logs - Environment details (OS, versions, config) - Input data that triggers the issue - System state before/during/after ### 3. **Form Hypotheses** - What are the most likely causes? - List hypotheses from most to least probable - Consider: logic errors, data issues, environment, timing, dependencies ### 4. **Test Hypotheses** - Use binary search to narrow down location - Add logging/print statements strategically - Use debugger breakpoints - Isolate components - Test with minimal reproduction case ### 5. **Identify Root Cause** - Don't stop at symptoms - find the real cause - Verify with evidence - Understand why it wasn't caught earlier ### 6. **Fix and Verify** - Implement fix - Test the fix thoroughly - Ensure no regressions - Add tests to prevent recurrence ## Debugging Strategies ### Binary Search ``` 1. Identify code region (start → end) 2. Check middle point 3. If bug present → search left half 4. If bug absent → search right half 5. Repeat until isolated ``` ### Rubber Duck Debugging - Explain the code line by line - Often reveals the issue through verbalization - Clarifies assumptions ### Add Strategic Logging ```python # At function entry print(f"[DEBUG] function_name called with: {args}") # At decision points print(f"[DEBUG] Condition X is {condition_result}") # Before/after state changes print(f"[DEBUG] Before: {state}, After: {new_state}") ``` ### Bisect Method (for regressions) ```bash # Find which commit introduced the bug git bisect start git bisect bad HEAD git bisect good <last-known-good-commit> # Test each revision until found ``` ## Common Bug Patterns ### Off-by-One Errors - Loop indices (`i < n` vs `i <= n`) - Array bounds (`arr[len(arr)]` instead of `arr[len(arr)-1]`) ### Null/Undefined References - Check variables before use - Verify API responses have expected fields ### Race Conditions - Async operations completing in unexpected order - Shared state without proper locking ### Type Mismatches - String vs number comparisons - Implicit type coercion issues ### Stale State - Cached values not updated - Closure capturing old variables ## Output Format Structure debugging analysis as: ```markdown ## Problem Statement [Clear description of the issue] ## Environment - [Relevant version/config info] ## Error Analysis [Error message/stack trace analysis] ## Hypotheses (Priority Order) 1. **[Most Likely]**: [Reasoning] 2. **[Second Most Likely]**: [Reasoning] 3. **[Less Likely]**: [Reasoning] ## Investigation Steps 1. [What to check first] 2. [How to verify hypothesis] 3. [Next steps based on results] ## Root Cause [Once identified, explain the underlying issue] ## Fix [Specific code changes needed] ## Prevention [How to avoid this in the future] ``` ## Example **User Report:** "My API returns 500 errors randomly" **Debugging Response:** ## Problem Statemen