Debug
The claude code config, tailored to myself, battle-tested (might inspires you)
npx -y skills add latuconsinafr/claude-code-config --skill debugAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when you encounter a bug, error, or unexpected behavior during a task — follows a reproduce → isolate → fix → verify cycle. Invoke this instead of guessing at a fix.
SKILL.md
3.6 KB, 784 tokens by cl100k_base, as published. Nobody here has run it
Debug
Systematically debug the problem described in $ARGUMENTS.
Do not guess. Do not fix without reproducing first.
Step 1: Understand and categorize the problem
Parse $ARGUMENTS for:
- What is the observed behavior?
- What is the expected behavior?
- Is there an error message or stack trace?
- When did this start? After what change?
If critical information is missing, ask for it before proceeding.
Categorize the issue type — the investigation strategy depends on this:
- Runtime error — exception, crash, panic, unhandled promise rejection
- Logic error — wrong output, incorrect calculation, unexpected state
- Performance — slow response, high CPU/memory, timeout
- Intermittent — flaky, race condition, timing-dependent
- Environment-specific — works locally, fails in CI/staging/production
- Build/type error — compilation failure, type mismatch, import error
Step 2: Investigate — spawn the debugger agent
Spawn the debugger agent to investigate in isolation. This keeps debug artifacts out of the main context and uses the agent's systematic root cause methodology.
Pass the following as the agent task:
Bug report: <observed behavior from Step 1>
Expected behavior: <expected behavior from Step 1>
Issue category: <category from Step 1>
Error/stack trace (if any): <paste here>
Reproduce with: <failing test command or steps>
The debugger agent will return:
- Root cause with evidence and location (
file:function:line) - Proposed minimal fix
- Class of bug — other locations in the codebase with the same assumption
- Detection gap — what would have caught this sooner
If the agent cannot reproduce the issue: do not guess. Surface the agent's findings to the user and ask for more context (environment details, additional logs, or a more specific reproduction case).
Step 3: Apply the fix
Review the root cause and proposed fix from the debugger agent.
Make the minimal change that fixes the root cause — not the symptom:
- Do not fix multiple things in one commit
- Do not refactor unrelated code while fixing
- Add a comment if the fix is non-obvious:
// Fix: <why this is necessary>
Also check the "class of bug" output — if other locations share the same flawed assumption, fix those too (or note them as follow-up).
Step 4: Write a regression test — spawn the qa agent
Spawn the qa agent to write the regression test. Pass:
Bug fixed: <one-sentence description of the root cause>
Fix location: <file:line of the fix>
Reproduce with: <the reproduction case from Step 2>
The test must:
- Fail with the bug present (verify this before the fix)
- Pass after the fix
- Document why it exists (describe the bug it prevents in the test name or comment)
A fix without a regression test is incomplete.
Step 5: Verify
# Run the regression test to confirm it passes
# Run tests covering the affected area
# Run the full suite to check for regressions
# Re-run the original reproduction case — confirm the issue is gone
Step 6: Output
Summarize:
- Root cause: what was actually wrong and why
- Fix: what was changed and the reasoning
- Regression test: what test was added and what it covers
- Verification: test output confirming the fix
- Follow-up: class-of-bug locations to check, tech debt, missing detection gaps
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most debug triage skills give in 784 tokens
Counted across 839 of the 1,149 authors here whose files we hold, read 2026-08-07
- Investigate root cause before proposing any fixin 102 of 839, across 67 files
- Read error messages completelyin 89 of 839, across 49 files
- Create a failing test case before fixingin 84 of 839, across 46 files
- Reproduce the issue consistentlyin 82 of 839, across 41 files
- Change one variable at a timein 82 of 839, across 42 files
- Check recent changesin 74 of 839, across 36 files
- Write the regression test before fixingin 74 of 839, across 40 files
- Fix the root cause not the symptomin 60 of 839, across 45 files
- Implement a single fix at a timein 59 of 839, across 20 files
- Trace data flow backward to the sourcein 50 of 839, across 20 files
- Remove all debug instrumentationin 49 of 839, across 13 files
- Form a single hypothesisin 48 of 839, across 18 files
Said here and by no other author read
- parse the bug report for missing context
- ask for missing critical information
- spawn the debugger agent to investigate
- ask for more context if reproduction fails
- add a comment if the fix is non-obvious
- spawn the qa agent to write a regression test
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.