agentleFS
komlukkomluk/scaffolding/skills/systematic-debugging/SKILL.md

systematic-debugging

Skill16 starsChanged 4 days agoMITView on GitHub

Phase-based root cause investigation: reproduce, observe, hypothesize, bisect, verify. TRIGGER when: investigating a bug report, diagnosing unexpected behavior, or doing root cause analysis. SKIP: looking up a known error first (use sofa-search); writing the regression test (use testing-strategy); live-repro watcher (use watch-patterns).

190 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use chinese-code-review, chinese-commit-conventions 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.
  • Leodorareluctant259Skill

    chinese-code-review

    中文代码审查规范——在保持专业严谨的同时,用符合国内团队文化的方式给出有效反馈

    Also in 8 projects that use this

  • Leodorareluctant259Skill

    chinese-commit-conventions

    中文 Git 提交规范 — 适配国内团队的 commit message 规范和 changelog 自动化

    Also in 8 projects that use this

  • obraSkill

    diagnosing-superpowers

    Use when a superpowers session went wrong and your human partner wants to know why — repeated work, ignored plans, stumbles, poor results, a skill that didn't fire, "it took too long", "why is it so expensive", "what is it doing" — or wants to build a bug report for the superpowers maintainers, for the current session or a past one identified by id or path, on any harness.

    Also in 20 projects that use this

  • mjunaidcaSkill

    building-chatgpt-apps

    Guides creation of ChatGPT Apps with interactive widgets using OpenAI Apps SDK and MCP servers. Use when building ChatGPT custom apps with visual UI components, embedded widgets, or rich interactive experiences. Covers widget architecture, MCP server setup with FastMCP, response metadata, and Developer Mode configuration. NOT when building standard MCP servers without widgets (use building-mcp-servers skill instead).

    Also in 4 projects that use this

  • mjunaidcaSkill

    building-chat-interfaces

    Build AI chat interfaces with custom backends, authentication, and context injection. Use when integrating chat UI with AI agents, adding auth to chat, injecting user/page context, or implementing httpOnly cookie proxies. Covers ChatKitServer, useChatKit, and MCP auth patterns. NOT when building simple chatbots without persistence or custom agent integration.

    Also in 4 projects that use this

  • +2 more from Leodorareluctant259
  • +5 more from mjunaidca

The file

We split this skill into the rules it gives an agent

1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 177 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do NOT apply this skill for:

    line 25

“Common” is measured: kept by at least 6 in 10 of the 177 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

Systematic Debugging Skill

Purpose

A repeatable root cause investigation procedure. A bug is not understood until it can be reproduced on demand and the causal chain is traced back to a fixable defect. This skill encodes the phase order and the discipline (one variable at a time, bisect instead of scan, verify by reverting) that keeps an investigation from turning into guesswork.

When to Apply

Apply this skill when:

  • Investigating a reported bug or unexpected behavior
  • Diagnosing a failing test, crash, or incorrect output
  • Performing root cause analysis before recommending a fix
  • An error message, stack trace, or log output needs to be traced to its origin

Do NOT apply this skill for:

  • Writing the regression test that prevents recurrence — use testing-strategy
  • Constructing the poll/watch loop used to observe a live reproduction — use watch-patterns
  • Looking up a known/unfamiliar error before investigating from scratch — use sofa-search

Investigation Phases

Work the phases in order. Do not skip ahead to a fix before phase 6.

PhaseActionExit Criterion
1. Reproduce firstEstablish a minimal, reliable repro before forming any hypothesisBug reproduces on demand, deterministically
2. Observe before theorizingRead the actual error text, stack trace, and logs verbatimSymptom described using only observed evidence, zero assumptions
3. HypothesizeState one falsifiable hypothesis and the prediction that would confirm or refute itHypothesis has a concrete, testable prediction
4. Test one variableChange exactly one thing, run the test, compare to the predictionPrediction confirmed or refuted; refuted hypotheses are discarded, not recycled
5. Bisect the search spaceNarrow via git bisect, binary search on input, or disabling half the config — not linear code readingCandidate range halves each round
6. Trace backwardWalk the call stack from the crash site back to the original triggerTriggering call/input identified, not just the frame that crashed
7. Root cause, not proximate causeKeep asking "why" until the chain reaches something you can actually fixChain terminates at a fixable defect (bad state, wrong assumption, missing check)
8. Verify by revertingRevert the fix and confirm the symptom returns; reapply and confirm it clearsCausation proven in both directions

Bisection Techniques by Search Space

Search spaceTechnique
Regression across commitsgit bisect between known-good and known-bad revisions
Large/complex input triggers failureBinary search: halve the input, check which half still fails
Behavior depends on config/flagsDisable half the flags/config, narrow to the culprit
Unclear which layer owns the bugBisect the call stack: instrument the midpoint, check state there

Hypothesis Discipline

RuleWhy
One hypothesis at a timeMultiple simultaneous changes make it impossible to attribute the outcome
Prediction must be falsifiableAn untestable hypothesis cannot be confirmed or ruled out
Never pattern-match a remembered bug onto new symptomsConfirmation bias skips the actual evidence in phase 2
A refuted hypothesis is discarded, not adjusted and reusedAdjusting mid-test invalidates the prior result

Anti-Patterns

Anti-PatternProblemInstead
Forming a hypothesis before reproducingGuessing wastes cycles on an unconfirmed bugReproduce deterministically first
Pattern-matching to a remembered similar bugMisses the actual cause, confirmation biasRead the actual error/stack/logs fresh (phase 2)
Changing multiple things per testCannot attribute the result to any one changeChange exactly one variable per test
Reading code top-to-bottom to find the defectSlow, linear, scales poorlyBisect the search space (phase 5)
Stopping investigation at the crash siteFixes the symptom, not the defectTrace backward to the original trigger (phase 6)
Declaring root cause without reverting the fixCausation asserted, not provenRevert, confirm symptom returns, reapply (phase 8)

Quality Checklist

  • Bug reproduces reliably, and reproduction happened before any hypothesis was formed
  • Investigation cites actual error text/stack/logs, not assumptions or memory of a similar bug
  • Each hypothesis had a falsifiable prediction, and only one variable changed per test
  • The search space was bisected, not scanned linearly
  • The causal chain was traced backward from the symptom through the call stack to the trigger
  • The identified cause is a fixable root cause, not a proximate symptom
  • The fix was verified by reverting it and confirming the symptom returns

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.