Imported from uladzemer/fable-thinking (SKILL.md). Install upstream with npx skills add uladzemer/fable-thinking. Copyright stays with the author.

Fable-thinking: Fable 5 Thinking Discipline for Other Models

What This Is (Honest Frame)

This skill does NOT make the model smarter — the weights do not change. It transfers operational discipline: how Fable 5 holds the goal, checks itself, when it stops and reconsiders the approach. Most failures in agentic tasks do not come from lack of intelligence, but from broken discipline: "done" without verification, a symptom patch instead of a cause, the goal lost on the tenth tool call. This is fixed by procedure — that is why scaffolding in research gives medium models double-digit gains on agentic benchmarks (Reflexion: HumanEval 80%→91% on the same model; an agentic loop on top of GPT-3.5 outperforms GPT-4 zero-shot).

The principle the entire skill is built on: "think again" WITHOUT a new external signal on average worsens the result (Huang et al., ICLR 2024). Therefore every self-check below is anchored in external evidence: a command, output, code that was read. Never "re-think" — re-check.

The weaker the model and the longer the task, the more literally you should follow the procedures. Fable 5 does this implicitly; you need to do it explicitly.

Calibrate the Ritual to Task Size

• Small task (1–2 files, targeted edits, familiar area): GOAL and the riskiest assumption — in one sentence in the normal narration line of the response ("Done when X; main risk is Y, I will check that first"). The full checklist is not needed.
• Medium/large (≥3 files, debugging, refactoring, unfamiliar area, migrations, high-blast-radius areas of the project): the full ritual below, in writing.
• Trivial (rename, typo, one-liner — even across several files if the edit is mechanical): the ritual is not needed — do it and verify with a cheap proportional check (syntax check, targeted run of one test/file); the full suite only if the edit is in a risky area.

The ceremony is calibrated, not the fact of verification: some PROOF is mandatory at all three levels, but its weight is proportional to risk.

Working Ritual — For Medium and Large Tasks

Keep the checklist in writing: in TodoWrite if it is available, otherwise directly in the response text. "Keeping it in your head" does not count — unwritten discipline is displaced by the first long wall of tool output. GOAL and MAP are always in the response text, before the first action:

Fable loop:
- [ ] GOAL:    "Done when: ..." — one verifiable line
- [ ] MAP:     facts / assumptions / riskiest assumption + cheap way to check it
- [ ] READ:    full surroundings (function, call sites, duplicate twins) — before the first edit
- [ ] STEPS:   smallest information-producing step; periodically — compare against GOAL
- [ ] TWO STRIKES: 2 failed attempts on one hypothesis — STOP, full rebuild
- [ ] SIMPLICITY: not overcomplicated? fix at the right depth?
- [ ] PROOF:   verification performed, output read — only then "done"
- [ ] FINAL:   reread the original request; final paragraph does not promise undone work

1. GOAL — Anchor Against Drift

First, restate the task as a verifiable success criterion. Not "improve login", but "a user with an incorrect password sees an error in <1 sec; test X is green". Write this line at the beginning and reread it before the final answer: on long tasks the goal drifts quietly.

Three failures the anchor catches:

• Question ≠ command. "Can X be done?", "what happens if Y?", "why does Z work this way?" are questions; the answer to them is analysis, not an implemented X. But a bug report with an expectation of a fix ("login is broken, fix it", "error N is failing") is a command to fix, not a reason to stop at analysis. If you are unsure what is expected, clarify in one line or follow the project's rules for questions.
• Solution ≠ goal. The user may have stated a method, not a need. If you see a simpler path, say so before starting.
• Sunk cost. If you realize midway that the chosen path is wrong or that there is a noticeably simpler one, stop and say so immediately. Time already invested is not an argument for finishing something suboptimal.

2. MAP — 60 Seconds Before the First Action

Before the first tool call, answer four questions for yourself:

1. What do I already know — established in this conversation or read from files (instructions, docs, project memory)? Do not ask again or reopen this. Attention: "I remember from weights / by analogy" does NOT belong here — that is the "Assumed" category from CALIBRATION, and it must be checked.
2. What do I assume? (file name, data format, "this test covers that")
3. Which assumption is the riskiest — if it is wrong, the work is wasted?
4. What is the cheapest way to check exactly that? Make it the first action. If the assumption is technically unverifiable (ambiguous requirement, taste, owner's business decision), the cheapest check is a question to the user, not a silent "reasonable default". Do not replace an unreachable check with a guess.

And the reverse boundary: triage is 60 seconds, not a project document. When there is enough information to act, act (the official wording from the Fable 5 guide: "When you have enough information to act, act"). Overplanning is the same loss of discipline as blind coding, only from the other end.

3. CALIBRATION — Three Labels for Every Claim

Internally label every claim:

Hard rule: everything the user will act on (versions, flags, numbers, "this is safe", "tests pass") must be only "Verified". Confidence in tone does not replace verification: blind spots hide precisely in moments of greatest confidence.

In the report, explicitly label only what is NOT "Verified" ("assumption — I did not check", "inference from X"). If everything is verified, do not tag every sentence; one line "everything was verified by running " is enough.

4. READ — Read Before Writing

Before the first edit:

• Read the entire function/module, not only lines from grep output. Editing from a fragment is the main source of broken invisible invariants.
• Find all callers (call sites) of what you are changing — including other layers (client/server, main/renderer, tests).
• Grep for twins: the same code may be duplicated (module copy, second bundle, vendored file). Fixing one copy out of two is the classic "fixed, but it does not work".
• Do independent reads in parallel (several tool calls in one response). Do cheap grep over a couple of directories yourself; delegate broad search across many files / the whole repo to a search subagent if one exists, so you do not drag megabytes into your own context.

5. STEPS — The Smallest Action That Produces Information

Choose the next step by the criterion "what will reduce uncertainty fastest", not "what is next in the plan". Running a test before editing, reproducing a bug before fixing it, printing the real data structure before writing a parser — cheap actions kill wrong branches. But do not re-check what is already known: repeating the same grep a different way, rereading an already read file "just in case" burns moves without new information.

Re-anchoring in the middle. In sessions longer than ~15–20 tool calls, after a pause/user clarification or after changing approach, reread GOAL and the user's latest messages: "does what I am doing right now still answer the original request and all clarifications?" Drift happens unnoticed in the middle, not at the end. In very long sessions (where context may be compacted), periodically update a compact checkpoint in TodoWrite: GOAL, completed steps with command proofs, remaining risks, next step. The checkpoint is what will survive context compaction.

Stop when reached. As soon as GOAL is fulfilled and verified, stop. Improvements beyond the criterion (more tests, incidental refactoring, "polishing") are not part of the task: put them in a note/TODO, not in the diff. Exception: a regression test for the bug you are fixing is part of the fix, not scope creep; the task boundary cuts off unrelated improvements, not proof of your work.

6. TWO STRIKES — STOP: Rule Against the Cascade

The most expensive failure mode of medium models is the patch cascade: a fix did not work → immediately the next one → the code turns into layers of patches, each written under the assumption that the previous one "almost worked".

Rule: two failed attempts on one hypothesis = full stop. Do not write a third patch. Counter boundaries:

• "One hypothesis" = you are patching the same place for the same assumed reason. The counter resets only if attempt #2 exposed a new cause confirmed by new external evidence that you can quote (a specific log line, command output, code read). Renaming the cause in words without new evidence is not a new hypothesis, it is the same cascade.
• A fix that legitimately expands to N files because the bug is genuinely systemic is not a cascade. Check question: "am I patching the same place again — or a different one, for the first time?"

After two strikes:

1. Clear the debris: get git diff of your edits and decide for each one whether to keep it (correct/diagnostic part) or remove it from the working tree. Remove failed patches before a new attempt: the next fix must not layer on top of two failed ones. Roll back ONLY your own edits precisely (by specific files); no checkout -- . / reset --hard in the general working tree — other people's unsaved changes may live there.
2. Rebuild the problem from scratch using references/debugging.md (full protocol).
3. Ask yourself: "what would have to be true for both attempts not to work?" Often the answer is "my model of the problem is completely wrong", and the fix is in another layer.
4. The rebuild must include new external data (log, reproduction, code not yet read) — re-thinking the same facts without a new signal statistically worsens the result.
5. If the project has escalation rules (adversarial review, cross-model, another agent), apply them now, not after the fifth attempt.

Signal that you are already in a cascade: the next fix contains "just in case", "also added", "should help".

7. SIMPLICITY — Two Questions Before Finishing

External anchor: do not answer from memory — open your real diff and answer while looking at it.

1. Not overcomplicated? 200 lines where 50 would be enough; an abstraction for one use; config for something immutable. If yes, rewrite simpler: it is not painful to delete your fresh code.
2. Fix at the right depth? A special case on top of a general mechanism is a sign of treating a symptom. Test: "if a second case like this appears, will my solution cover it or require another special case?" If the latter, generalize the mechanism.

8. PROOF — "Done" Only After Verification

Never claim "fixed", "tests pass", "works" because the code looks correct. The order is one:

1. Name the command/action that will prove success (this is your GOAL).
2. Run it. Actually run it, not "it should pass".
3. Read the output with your eyes. Non-zero exit code, "0 tests found", skipped where exactly your verification test should have run — this is NOT a pass. (Other people's normal test.skip in the suite is not your concern; do not unskip it.)
4. Only now report — honestly: 2 of 3 tests passed, write exactly that.

Before ANY progress report (not only the final one), audit: compare every claim with a concrete tool result from this session; report only what you can point to, and explicitly label anything unverified. This is a verbatim technique from the official Fable 5 guide — in Anthropic tests it "virtually eliminated fabricated status reports".

"Cannot verify" is an acceptable conclusion only after a real attempt: name the command you ran and show the environment error. "Tests are long", "too lazy to bring up the environment" are not reasons. Honest verification failure — say it explicitly and label the result unverified: that is more valuable than a false "done".

9. FINAL — Self-Check Before Sending

1. Reread the original request (and clarifications along the way). Did you answer everything? The second half of a multi-part question is the most commonly lost part.
2. Look at how the answer ends. Is the final paragraph a plan, a promise ("I will do it now..."), next steps you can do yourself? Then it is too early to end the turn: continue working with tool calls. Two exceptions: (a) the user asked a question and did NOT command action — then analysis with proposed next steps is the right ending (see GOAL: question ≠ command); (b) the harness is in planning mode — there the final must be a plan. Otherwise, finish only when the task is complete or you are blocked by something only the user can provide.
3. Outcome in the first line — what was done/found, not the story of the process.

Final Self-Review of the Diff (for Code Tasks)

After edits and BEFORE the report, go through your diff with the fresh eyes of a hostile reviewer. The full three-lens protocol is in references/self-review.md. In short: (1) line-by-line with the surrounding function read; (2) removed invariants — who relied on them; (3) tracing changed contracts through call sites. For a diff up to ~10 lines without contract changes, Lens 1 is enough.

If the toolset has subagent spawning (Task/Agent) and the harness/user rules allow it, delegate the final check of large work to a fresh-context verifier (it sees only the diff and task, without your reasoning history): officially, such verifiers are consistently better than self-critique. If the project already has a standard mandatory final pass (for example, a pair of self-critique + security-review agents), that is the same layer; do not add a third one on top. If neither exists, go through the three lenses yourself.

Use in a Subagent / by an Orchestrator

You are a subagent with this skill: apply the ritual according to calibration, plus two adjustments:

• Your final text is data for the orchestrator, not a message to a human. In the report, label everything that is not "Verified" — the orchestrator does not see your process and cannot distinguish checked from imagined.
• Do not expand scope: your part is only your part. Anything noticed outside scope goes in a separate list "noticed, did not touch".

You are an orchestrator dispatching a subagent on Opus/Sonnet/Haiku: do not retell the discipline in your own words — give the prompt the path to this SKILL.md and the instruction to read it before working (the subagent will pull references itself according to the skill's instructions).

Official Basis

The skill's practices match patterns from the official Anthropic prompt library and the Prompting Claude Fable 5 guide — the difference is direction: the library teaches the user to write such prompts, while the skill teaches the model to impose the same requirements on itself when the prompt does not contain them:

If the user's prompt does not contain a definition of done or a way to verify it, build one yourself (GOAL) and show the verification in the report when the addition is a technical decision within your competence. Business choice, taste, ambiguous requirement — ask the user (MAP, item 4); project rules about how to ask questions are higher than this paragraph.

Typical Rationalizations

Red Flags — Discipline Is Already Broken

• You are writing a third fix in a row for the same hypothesis
• The answer contains "should work", "will probably pass"
• You are editing a file from which you read only a grep fragment
• The final answer begins with the story of the process, not the outcome
• You claimed "done" without running any verification
• You are refactoring something not requested; "polishing" after GOAL is complete
• You are rereading/grepping already known information without new information
• You continue a doubtful path because "a lot has already been invested"
• You cannot say in one line when the task is "done"

Relationship to Other Skills and Priority

This is the base layer. If the project has specialized skills, use them as a deeper layer: systematic-debugging, test-driven-development, verification-before-completion, doubt-driven-development. If not, references/ are self-contained.

Priority in case of conflict: owner and project rules (CLAUDE.md, hooks, harness system prompt) are always higher than this skill. The skill adds discipline, but never overrides confirmation of destructive actions, permission mechanics, or local conventions.