菜单
Fable 5's debugging discipline: reproduce first, read reality not memory, one falsifiable hypothesis at a time, explain the mechanism before shipping the fix. Load when chasing any bug, test failure, or behavior you can't explain — especially after your first fix attempt didn't work.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
What Fable-quality code looks like and how to produce it: altitude, naming, comments, idiom-matching, error handling, tests, dependencies. Load before writing or changing any code that another human or agent will later read — which is all code. Complements fable-method (process) with the artifact-level standard.
How Fable 5 wrote to the user: lead with the outcome, selectivity over compression, honest verification status, recommendations instead of menus. Load before writing any report, summary, answer, or status the user will read — the final message of a work turn especially.
How Fable 5 ran multi-agent work as lead: what to delegate vs write yourself, spec discipline, file ownership, warm resumes, review gates. Load when a task will involve spawning coder/engineer/explorer/reviewer workers, or whenever you're deciding whether it should. Pairs with fable-review for the acceptance gate and fable-taste for the calls no worker may make.
Fable 5's working method, distilled for Opus: how to decompose a hard task, verify your own work, and pick the next action. Load at the START of any nontrivial task — ambiguous ask, >2 files, unfamiliar territory, anything irreversible, or any task where the first-draft plan might be wrong. Skip for trivial mechanical edits. This is method, not orchestration: it governs how YOU think, whichever agents you do or don't spawn.
How Fable 5 reviewed a diff — its own, a worker's, or a PR: reading order, what to personally verify vs delegate, refutation stance, severity honesty. Load before accepting any diff you didn't just watch yourself write, and before shipping any diff you did.
How Fable 5 made judgment calls when no rule covered the situation — design forks, tradeoffs, quality bars, "which way is right" questions. Load whenever you notice yourself weighing options, hedging between two designs, or about to ask the user something you could decide. Taste is the layer above method: method tells you how to execute a decision, this tells you how to make one.
| name | fable-debugging |
| description | Fable 5's debugging discipline: reproduce first, read reality not memory, one falsifiable hypothesis at a time, explain the mechanism before shipping the fix. Load when chasing any bug, test failure, or behavior you can't explain — especially after your first fix attempt didn't work. |
Debugging is epistemics under time pressure. Every rule here exists because the natural failure mode — guess, patch, rerun, repeat — feels like progress while destroying information.
Reproduce before you theorize. A bug you can't trigger on demand is a rumor, and a fix for a rumor is a superstition. Getting a reliable reproduction IS the first task; everything before that is setup. If it only reproduces sometimes, the conditions of "sometimes" are your first clue, not an excuse to proceed without one.
Read the whole error. The answer is disproportionately in the part people scroll past — the second exception in the chain, the line number of the caller, the "caused by," the warning three lines up. Read every line of the actual output before forming any theory. Truncated-error debugging is guessing with extra steps.
Reality beats memory, every time. When behavior contradicts your expectation, the next read is the library's actual source, the actual bytes on disk, the actual response body, the actual env var — never your recollection of how it "should" work. You are debugging precisely because your model diverged from reality; consulting the model again is asking the suspect to alibi himself.
One falsifiable hypothesis, one variable per run. State what you believe ("the config isn't being read") and design the probe whose outcome can prove you WRONG, not just consistent-with. Change one thing per run — two simultaneous changes produce zero information regardless of the result. Log the intermediate value; don't infer it.
Two failed fixes on one theory means the theory is dead. Do not try variant three. Your model of the mechanism is wrong somewhere upstream — go widen: re-read the reproduction, question an assumption you marked "obviously fine," check the environment class below.
Check the boring liars first. A huge share of "impossible" bugs are environment lies: stale cache, wrong file edited (check the path!), old process still running, wrong branch, wrong database, unsaved buffer, dependency version mismatch. Thirty seconds ruling these out beats two hours of brilliant reasoning about code that isn't even executing.
Shrink the world. Cut the reproduction down — one function, one request, one row — until the bug either persists in a context small enough to fully understand, or vanishes, in which case the cause is in what you removed; binary-search it back in.
Keep a written ledger of ruled-out causes. Past three hypotheses, memory fails and you re-test candidates you already cleared. One line each: what you tested, what you saw, what it eliminates. Loops in debugging are almost always ledger failures.
No mechanism, no fix. When the bug stops reproducing, you're not done until you can state WHY it happened — which line, which input, which interaction. A fix without a mechanism is a coincidence you're about to redeploy; half the time you perturbed timing or state and the bug is in the mail. Then: make the fix's test fail without the fix, pass with it.
