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
- PeanutGT/NutsSkillstheir own version, first seen Nov 8, 2026
- jskswamy/skillstheir own version, first seen Nov 8, 2026
- Firzus/agent-skillstheir own version, first seen Nov 8, 2026
- domengabrovsek/agent-configtheir own version, first seen Nov 8, 2026
- domengabrovsek/claudetheir own version, first seen Nov 8, 2026
- microsoft/veronatheir own version, first seen Nov 8, 2026
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.
MicrosoftSkilladd-discord
Add Discord bot channel integration via Chat SDK.
Also in 11 projects that use this
MicrosoftSkilladd-slack
Add Slack channel integration via Chat SDK.
Also in 11 projects that use this
- +10 more from microsoft
Other versions192 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 192
- Yeachan-Heo/oh-my-claude-sisyphus★ 41ksame name
- Yeachan-Heo/oh-my-claudecode★ 41ksame name
- anthropics/knowledge-work-plugins★ 35ksame name
- gavrielc/nanoclaw★ 31ksame name
- nanocoai/nanoclaw★ 31ksame name
- qwibitai/nanoclaw★ 31ksame name
- openai/symphony★ 27ksame name
- FalkorDB/FalkorDB★ 10ksame name
- NVIDIA/TensorRT-Model-Optimizer★ 5.6ksame name
- NVIDIA/Model-Optimizer★ 5.6ksame name
182 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository30 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- llms.txtllms.txt
- app-devSkill
- architectureSkill
- buildSkill
- checkpointSkill
- context-mgmtSkill
- dreamSkill
- evalSkill
- experimentSkill
- forgeSkill
- frontendSkill
- governance-syncSkill
- handoffSkill
- helpSkill
- human-passSkill
- ingestSkill
- initSkill
- knowledge-graphSkill
- landing-pageSkill
- marketing-siteSkill
- metricsSkill
- orchestrationSkill
- qualitySkill
- retrospectiveSkill
- reviewSkill
- shipSkill
- simplifySkill
- tearitapartSkill
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
- Distinctive: line 17
Not random changes. Not guessing.
- Distinctive: line 34
Document: exact input, expected output, actual output (full stack trace), environment, frequency.
- Distinctive: line 42
Read ALL error output first (anchoring bias mitigation).
- Distinctive: line 43
Write each hypothesis to AgentDB.
- Distinctive: line 47
Code: call chain A→B→C→D→E fails → check midpoint C → recurse into failing half.
- Distinctive: line 60
Ask: what assumption was violated?
- Distinctive: line 61
If you can't explain WHY it broke, you haven't found root cause.
- Distinctive: line 67
Write regression test that fails before fix, passes after.
- Distinctive: line 68
Run: original failing case + edge cases + full regression suite.
- Distinctive: line 69
Commit fix + test together.
- Very specific: line 76
MAP: every file/module touching the target.
- Distinctive: line 88
When the run ends at a diagnosis rather than a fix, emit this and stop:
“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.
Files
<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)- 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)
- 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 bisectbetween 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)
- 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)
- 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.
- 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. - TRACE DEPS: per file, who calls it, who depends on it, what breaks if it changes.
- MEASURE COUPLING: cross-module reference counts, circular dependencies, the
per-function CCN from
scripts/complexity.sh. - RISKS: current edge cases, what is tested, what is not, invariants to preserve.
- 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>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
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.

