Say "fable-mode" (or "operate carefully," or "high-judgment mode" or "think like fable") in a Claude Code or Codex session, and one line buried in the skill file does most of the work: "Never promote 'plausible' to 'confirmed' in your summary." That single rule is the whole philosophy in miniature — don't let something that merely looks right pass as something that was checked.
Fable-mode is not a tool, a model swap, or a set of new commands. It's a behavioral overlay — a skill file at ~/.claude/skills/fable-mode/SKILL.md or ~/.codex/skills/fable-mode/SKILL.md or any other agent you use, that gets loaded into the turn and changes how the agent scopes work, verifies its own claims, and reports results. Nothing about what Agents can do changes. What changes is the discipline around using it.
What actually changes
The skill is organized into seven blocks, and each one targets a specific failure mode that shows up in normal agent use:
Judgment before action. The first move is classification: is this a question, a problem description, or a change request? For the first two, the deliverable is an assessment — investigate and stop, don't start editing files nobody asked you to edit. Irreversible actions (deletes, pushes, overwrites) require a stop-and-confirm, and specifically: "before deleting or overwriting anything, actually look at the target."
Verification as the non-negotiable core. This is the section that does the heavy lifting. Every "done" claim needs evidence produced after the last edit — a test run before your final change proves nothing about your final change. Claims get graded on a three-tier scale: Confirmed (you ran it and saw the result), Plausible (the code reads right but you haven't executed it), Assumed (inherited from the user's description). The rule is that you report the grade you actually earned, not the one that sounds better.
Reasoning habits. Hold two hypotheses before committing to a diagnosis. Treat your memory of a library's API as a prior, not a fact, and check the installed version when correctness depends on it. When a result contradicts what you expected, that's flagged as "the most information-dense moment of the task" — chase it instead of smoothing over it.
Anti-patterns as hard stops. Eight explicit bans, including "declare success without a post-change verification run," "fix a bug you can't explain," and "hedge a known failure ('should work now') — either you verified it or you report it as unverified."
The skill closes with a five-item checklist the agent is meant to run before ending any turn — essentially a self-audit against the rules above.
Advantages
Verification stops being optional. The "read before you write" and "check you didn't break the neighbors" rules mean the agent greps for other callers of a function it just changed instead of assuming the diff is self-contained.
Reports get honest, not optimistic. The Confirmed/Plausible/Assumed grading forces a specific kind of intellectual honesty that's easy to skip under normal operation, where "should work" and "verified working" tend to blur together in the final summary.
Scope stays tight. "Prefer the smallest change that fully solves the problem" combined with "expand scope without flagging it" being a hard stop means less unrequested refactoring riding along with a bug fix.
Root-cause bias. The rule that a fix needs a one-sentence causal explanation before it's applied catches the class of fix that happens to make a symptom disappear without addressing why it occurred.
Effort matches stakes. "A one-line fix does not need a design document. A schema migration does not get done on vibes" — the skill explicitly scales its own overhead down for trivial tasks, so it isn't uniformly slower.
Disadvantages
It's a self-reported discipline, not an enforced one. There's no external checker validating that the agent actually ran the test it claims to have run — the whole system depends on the model correctly following its own instructions and honestly grading itself. A model that misjudges "confirmed" vs. "plausible" produces the same failure mode fable-mode was meant to prevent, just with more confident-sounding labels attached.
More tool calls per task. Verifiable increments, post-change re-runs, and neighbor-checking all mean more intermediate steps than an agent optimizing purely for speed. On tasks where the user genuinely wants a fast, rough pass, this overhead is friction, not value.
No built-in tool selection guidance. The skill is explicit that it "governs how work is scoped, verified, and reported — not what tools to use." It won't tell the agent which agent, MCP, or command to reach for; that judgment still comes from elsewhere.
Depends on activation. It's opt-in per session via trigger phrase. A user who forgets to say "fable-mode" on a high-stakes task gets none of it — there's no persistent always-on variant described in the file.
Checklist compliance can become theater. A five-item checklist run by the same agent that did the work is a weaker guarantee than an independent review pass; it catches self-aware gaps, not blind spots the agent doesn't know it has.
What to actually expect
Turn fable-mode on for the tasks where being wrong is expensive: schema migrations, auth changes, anything touching shared code, or a bug you don't yet understand. Expect the final report to distinguish what was actually tested from what merely compiles, expect fewer "while I was in there, I also…" surprises in the diff, and expect the agent to stop and ask before anything destructive rather than assuming consent. Don't expect it to make trivial tasks faster — for a one-line CSS fix, the skill's own "match depth to stakes" rule means it should behave close to normal anyway. The gain isn't speed; it's a report you can trust at face value, on the tasks where that trust is worth paying the extra verification steps for.
Skill File to download
Feel free to contribute
SOCIAL SHARE CARD GENERATOR