agentleFS
ariaxhanariaxhan/kernel-claude/skills/debug/SKILL.md

debug

Skill15 starsChanged 4 months agoMITView on GitHub

Diagnosis before prescription: reproduce, hypothesize, isolate, fix root cause, add a regression test; refactor mode maps deps, coupling and blast radius. Triggers: bug, error, fix, broken, not working, crashed, stack trace, exception, refactor, restructure, coupling, dependency map.

192 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use add-discord, add-slack and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • MicrosoftSkill

    add-discord

    Add Discord bot channel integration via Chat SDK.

    Also in 11 projects that use this

  • MicrosoftSkill

    add-slack

    Add Slack channel integration via Chat SDK.

    Also in 11 projects that use this

  • +10 more from microsoft

The file

We split this skill into the rules it gives an agent

12 rules. 0 are common, 11 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 175 edited versions we read keep these.

  • 11

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Not random changes. Not guessing.

    line 17
  2. Distinctive:

    Document: exact input, expected output, actual output (full stack trace), environment, frequency.

    line 34
  3. Distinctive:

    Read ALL error output first (anchoring bias mitigation).

    line 42
  4. Distinctive:

    Write each hypothesis to AgentDB.

    line 43
  5. Distinctive:

    Code: call chain A→B→C→D→E fails → check midpoint C → recurse into failing half.

    line 47
  6. Distinctive:

    Ask: what assumption was violated?

    line 60
  7. Distinctive:

    If you can't explain WHY it broke, you haven't found root cause.

    line 61
  8. Distinctive:

    Write regression test that fails before fix, passes after.

    line 67
  9. Distinctive:

    Run: original failing case + edge cases + full regression suite.

    line 68
  10. Distinctive:

    Commit fix + test together.

    line 69
  11. Very specific:

    MAP: every file/module touching the target.

    line 76
  12. Distinctive:

    When the run ends at a diagnosis rather than a fix, emit this and stop:

    line 88

“Common” is measured: kept by at least 6 in 10 of the 175 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md
<skill id="debug"><purpose> Debugging is forming and testing a THEORY that explains the bug. Not random changes. Not guessing. Scientific method applied to code. DEFECT (in code) → INFECTION (in state) → FAILURE (visible symptom). The failure you see is NOT where the bug is. Binary search upstream. Systematic methodology beats ad-hoc guessing. The process is the multiplier.

Diagnosis comes before prescription: a surgeon cutting before the X-ray is guessing with a knife. Two modes, same discipline. bug (default) is the steps below. refactor swaps the subject from a failure to a structure, and produces a plan instead of a fix. </purpose>

<prerequisite>Run agentdb recall with the exact error text, subsystem/library, failing test, and known files/symbols. Recall again when the hypothesis changes or a new failure appears; that is a new retrieval question. Reference on demand: skills/debug/reference/debug-research.md.</prerequisite>

<steps> 1. **REPRODUCE**: get specific before touching code. - Document: exact input, expected output, actual output (full stack trace), environment, frequency. - "Sometimes fails" is not a reproduction. Get deterministic. - Sensitive or high-blast-radius bug: investigate read-only (plan mode) and settle the approach before any edit. <!-- Updated 2026-09-20: sitepoint.com / claudelog.com Claude Code debugging guides --> - (gate: can reproduce consistently, OR have added targeted logging to wait for next occurrence)
  1. HYPOTHESIZE: list 3 causes before pursuing any.
    • Read ALL error output first (anchoring bias mitigation).
    • Write each hypothesis to AgentDB. Prevents circular re-investigation.
    • (gate: 3 candidate hypotheses written; none pursued yet)
  2. ISOLATE: binary search, O(log n) not O(n).
    • Code: call chain A→B→C→D→E fails → check midpoint C → recurse into failing half.
    • Time: git bisect between known-good and known-bad commit. ~10 tests for 1000 commits.
    • Input: large failing input → split in half → recurse to minimal reproduction case.
    • Instrument at boundaries: log inputs/outputs at each layer boundary.
    • Mock external dependencies to isolate which one causes failure.
    <!-- Updated 2026-09-19: dev.to flaky-test patterns; claudelog/sfeir debugging guides -->
    • Diff working vs failing state (env, config, input, commit) before theorizing.
    • Flaky test: classify first as timing/race, shared state, unseeded randomness, or environment difference; only then propose a fix.
    • (gate: failure localized to a specific function/commit/input subset)
  3. ROOT CAUSE: the error line is the FAILURE. The DEFECT is upstream.
    • Ask: what assumption was violated? What invariant broke?
    • If you can't explain WHY it broke, you haven't found root cause.
    • Top causes by frequency: wrong input shape/type · off-by-one · missing null check · race condition · shared-state mutation · wrong comparison operator · variable scope · swallowed error · API contract mismatch · environment difference.
    • (gate: can state root cause in one sentence explaining the violated invariant)
  4. FIX: root cause, not symptom.
    • Fix the DEFECT, not the FAILURE site. (Null check at crash site = symptom fix.)
    • Write regression test that fails before fix, passes after.
    • Run: original failing case + edge cases + full regression suite.
    • Commit fix + test together.
    • (gate: regression test green; original failing case passes)</steps>

<refactor_mode> Triggers: refactor, restructure, clean up, coupling, dependency, "what breaks if". Same rule: diagnose, then hand off. Do not start cutting inside this mode.

  1. MAP: every file/module touching the target. Grep/Glob every reference, or graphify affected <symbol> when the graph is fresh. Build the import/call map.
  2. TRACE DEPS: per file, who calls it, who depends on it, what breaks if it changes.
  3. MEASURE COUPLING: cross-module reference counts, circular dependencies, the per-function CCN from scripts/complexity.sh.
  4. RISKS: current edge cases, what is tested, what is not, invariants to preserve.
  5. PLAN: files in change order, tests that must pass before AND after, tier by reversibility x blast radius (file count is only a weak hint). Hand off to /kernel:simplify to execute, which owns the preservation contract and the gate. </refactor_mode>

<diagnosis_output> When the run ends at a diagnosis rather than a fix, emit this and stop:

## Diagnosis: <title>
Mode: bug | refactor · Confidence: high | medium | low
Root cause: <one sentence naming the violated invariant>
Affected: <file - origin> | <file - downstream> ...
Blast radius: N files. Tier 1|2|3.
Hypotheses: 1. <h> -> CONFIRMED | REJECTED (<evidence>) ...
Recommended approach: <what, not how>
Tests required: <fails before> / <passes after>
Next: /kernel:ingest to implement, /kernel:simplify to restructure.

Decide and state the recommendation. Never stop to ask which hypothesis to pursue. </diagnosis_output>

<anti_patterns> Shotgun (random changes until it works) · fix-and-pray (never re-run the original case) · symptom fixing (null check at the crash site) · printf flooding (binary search first, then targeted logging) · blame-the-framework (it's almost never the library) · unscoped "investigate" (scope narrowly or use a subagent so the file reads don't fill context). </anti_patterns>

<when_stuck> Explain the problem in writing · re-read the error message (the answer is there most of the time) · reduce to a minimal reproduction · ask "what changed?" (git log/diff, deps, env) · search the exact error message in quotes · step away, bias accumulates. Re-run the EXACT original failing case before declaring victory; "seems to work" is not evidence. </when_stuck>

<escalation> 30+ min on one hypothesis with no evidence → abandon it. 3+ hypotheses rejected → step back, re-examine assumptions. 2 failed fix attempts → invoke tearitapart; it may be a design problem. Repeated failed corrections in one session → /clear with a minimal reproduction. Bug only in production → add targeted monitoring, document, move on. For 3+ plausible causes, spawn one fresh-context agent per hypothesis (evidence_for / evidence_against / confidence); fresh context catches what a long session anchors past. </escalation><telemetry> agentdb emit command "debug" "" '{"mode":"bug|refactor","confidence":"high|medium|low","blast_radius":N,"tier":N}' </telemetry>

<on_complete> agentdb write-end '{"skill":"debug","bug":"<description>","root_cause":"<what_broke>","fix":"<what_fixed>","test":"<regression_test_name>","learned":"<pattern_for_future>"}' </on_complete>

</skill>

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.