agentleFS
atuljha23atuljha23/holocron/skills/debug-playbook/SKILL.md

debug-playbook

Skill2 starsChanged 6 months agoMITView on GitHub

Hypothesis-driven debugging — reproduce, hypothesize, probe, locate, fix, guard. Use when something is broken and you don't yet know why.

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    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:

    If you can't repro, narrow: which environments?

    line 16
  2. Distinctive:

    If you have only one hypothesis, you're not thinking hard enough — or it's so obvious you should skip to step 4.

    line 27
  3. Distinctive:

    Add the cheapest probe that separates your top two hypotheses.

    line 31
  4. Distinctive:

    When observation singles out the hypothesis, point at the line.

    line 42
  5. Distinctive:

    Ask: why does this line break?

    line 44
  6. Distinctive:

    Add a test that fails without your fix and passes with it.

    line 56
  7. Distinctive:

    If you can't write this report, you haven't finished debugging.

    line 78

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “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

Debug playbook

The order of operations matters more than the tools.

1. Reproduce

Nothing else is useful until you can make the bug happen on demand.

  • Exact command / action / input that triggers it
  • Minimum conditions — strip away anything not required
  • If you can't repro, narrow: which environments? which users? which data? which times?
  • Unreproducible bugs are intermittent bugs, which are race / env / state leaks — treat them as such.

2. Hypothesize

List 2–3 concrete theories. For each:

  • What you think is happening (one sentence)
  • What observation would confirm it
  • What observation would kill it

If you have only one hypothesis, you're not thinking hard enough — or it's so obvious you should skip to step 4.

3. Probe

Add the cheapest probe that separates your top two hypotheses.

  • A targeted log line > reading the code again
  • git bisect when the timeline is wide and the test is binary
  • strace / dtrace / perf when the surface is the runtime, not the code
  • Differential execution — run on a known-good input and a known-bad input, diff the trace

Resist the urge to add logs everywhere. Add one at the pivot point.

4. Locate

When observation singles out the hypothesis, point at the line. Not the region — the line.

Ask: why does this line break? What invariant did we assume here that isn't true?

5. Fix

Minimum change that resolves the root cause. Nothing adjacent.

  • Not: "add a try/catch so we don't see the error"
  • Not: "bump the retry so it eventually succeeds"
  • Not: "rewrite this section while I'm here"

6. Guard

Add a test that fails without your fix and passes with it. The test should target the condition, not mimic the scenario.

Anti-patterns

  • Shotgun debugging — changing five things, one passed. Revert four of them and find which one.
  • Bandaid reflex — catching exceptions you don't understand. You're hiding the bug, not fixing it.
  • Upgrade cure — "upgrading the dep fixed it". Maybe. Or maybe it re-broke differently. Read the changelog.
  • "Works on my machine" — an environment bug. Find the environmental difference.
  • Adding retries — every retry hides a bug you didn't diagnose.

Writing up the diagnosis

Short report:

What happened: <observable>
Root cause: <one sentence, concrete>
Why tests missed it: <honest answer>
Fix: <the change, minimum>
Regression guard: <the test>

If you can't write this report, you haven't finished debugging.

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.

Reviews can't be read right now.

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.