Working with Fable 5: fix the map before entering the territory

Field notes · ClaudeKit

Fable 5 is only included in subscription quota through July 7, so how do you work with it efficiently? Last night I happened to read two strong posts on X — "A Field Guide to Fable: Finding Your Unknowns" (Thariq, @trq212) and "The Most Valuable Thing You Can Do With Fable 5" (Alex Finn). Mapping those insights into my ClaudeKit system led to a 6-stage pipeline with 3 custom skills layered on top of ClaudeKit skills, a close fit with Thariq's point about finding unknowns before coding.

01 · Field Guide to Fable

Map vs Territory: that distance is unknowns

The prompt/context you gave Claude is map. The actual codebase and binding are territory. The distance between these two is called unknowns.

With Fable 5, the quality of output is limited by the ability of unknowns to clarify user — not because of model's abilities. The stronger the model, the greater the cost of a bad map, because it will confidently execute in the wrong direction instead of stopping to ask.

Matrix Rumsfeld — 4 types of unknowns when you write a prompt

🟢 Known knowns

What you have clearly written in prompt. Claude just read and follow — no guessing required.

🟡 Known unknowns

What you know yourself undecided — trade-off, variable name, strategy migration left open.

🟠 Unknown knowns

The standard is "know it when you see it" but you can't put it into words — it only shows up when output is wrong.

🔴 Unknown unknowns

Questions you didn't know you needed to ask. This is the most dangerous gap — and the main target to eliminate.

Golden rule: The sooner you find unknowns, the cheaper the repair cost — find it later merge The repair cost is many times more expensive, because at that time the territory was misshaped by the map.

02 · Three gaps of ClaudeKit

Three custom skills I wrote to cover the right three gaps

Not part of ClaudeKit core — 3 small skills built to fill the exact gap this method needs: finding unknown unknowns before coding, logging deviation at the moment it happens, and gate understanding people after coding.

· blindspot · Custom

Turn 'I don't know what I don't know' into a sharp, stick-and-go prompt.

strange area · new domain · before coding

· impl-notes · Custom

Catch each deviation the moment it happens — before it becomes a mystery.

while coding · edge case · handover notes

· quiz-gate · Custom

If you don't absolutely pass the quiz, you won't merge. It's that simple.

before merging · knowledge · review PR

Prioritizing sharing for Facebook Subscribers first

All 3 skill are currently only shared with Subscribers while still being refined. When stable, we will publish it to the public repo — subscribe to receive it soon.

Subscribe to receive early

Details of each skill

Before coding

/blindspot — blind scan before entering territory

• Scout codebase + peach git log to find unknown unknowns of users, not solving tasks for them.
• Any finding must cite evidence: specific file, commit hash, or doc — general speculation is not accepted.
• Most valuable trick: find commit who used to do a similar task (git log --grep) Already git show --stat <hash> — Its footprint file is the available checklist touchpoint, usually the highest signal artifact.

Key Deliverables: "a better prompt" — ready to paste straight in /ck:brainstorm or /ck:plan in the next step.

While coding

/impl-notes — log deviation at the moment it occurs

• File implementation-notes.md ghi Decisions / Deviations / Surprises at the time they happen — not end-of-session retrospectives like /ck:journal.
• Standing rule is right there HEADER of the file — don't rely on conversation memory, because context compaction will break the rule as the conversation gets longer. Any agent that re-reads the file automatically "re-adopt" the rule.
• Encounter edge case deviate from plan → choose option conservative (reversible smallest), log 4 lines, move forward — don't stop waiting for user with reversible decision.

Feed directly to quiz-gate (best deviations = quiz material) and /ck:journal.

After coding

/quiz-gate — people checking people

• Generate HTML explainer about changes (TL;DR, context, intuition, blast radius) with a behavioral quiz — not a variable renaming trivia.
• Gate only passes when answering 100% correct. Which sentence is wrong → explain the misunderstood concept with the correct relevant code, then re-quiz the new sentence targeting the right place, repeating until it passes.
• Important fix applied: report initially Contains questions only, answer key is written to HTML only after gate resolves (pass or abort) — if written first, the user reads the answer, then gate is meaningless.

Verdict of gate is the condition to run /ck:git or /ck:ship.

03 · End-to-end workflow

6-stage pipeline combining custom skill with ClaudeKit

Each period is an upfront cost of finding unknowns.

Phase 0 · Locate unknowns

/blindspot

Scan codebase + git history → report unknown unknowns, potholes, and a sharper prompt to carry to stage 1.

Phase 1 · Explore & design

/ck:brainstorm --html

Get prompt from blindspot → scout + interview built-in → 2-3 approach + design doc.

High risk: more /ck:predict (5 persona debate) or /ck:scenario (edge case 12-way).

Phase 2 · Plan

/ck:plan (or --tdd)

Xexport plans/<ts>-<slug>/plan.md + phase files.

High risk: + red-team (hostile reviewers tore up the plan) already + validate (verify claims vs real codebase).

Case critical (needs OpenAI sub): /codex:adversarial-review on plan — gate crossed model, run Final after red-team + validate: attack the refined plan, find a place where both Claude are blind.

Phase 3 · Implementation

/impl-notes init → /ck:cook → /impl-notes review

/impl-notes init create implementation-notes.md in plan dir before when cook. /ck:cook <plan> implement — when deviating from the plan: choose a conservative option, /impl-notes log, go ahead. End of session: /impl-notes review distill learnings for the next session.

Stage 4 · Gate understanding

/ck:code-review + /quiz-gate

Code-review checks code quality (code checker); quiz-gate tests human knowledge (people check people) — two different axes.

High risk (needs OpenAI sub): /codex:adversarial-review on code diff — gate crosses model, runs between /ck:code-review and /quiz-gate, focus text taken from the Deviations section of impl-notes.

Phase 5 · Ship

/ck:git or /ck:ship + /ck:journal

Commit/push or PR pipeline, run only after gate is in stage 4 PASSED. Journal reads impl-notes as feed to reflect.

04 · Insight is the most expensive

3 fixed gates + 2 optional cross-model gates around ck:cook

The checks are not duplicates — each gate targets a separate unknown axis, located at either end of the execution step. /quiz-gate always gate last pin: who is the stopping condition.

Gate 1 · Before cook · /ck:plan red-team · Eliminate unknown unknowns of plan

Gate 2 · Before cook · /ck:plan validate · Eliminate known unknowns of decision

Optional Gate · Before cook

/codex:adversarial-review\ on the plan

Cross gate model — case critical

Need OpenAI sub

Execution · /ck:cook

Optional Gate · After cook

/codex:adversarial-review\ on code diff

Eliminate unknown unknowns by model itself

Need OpenAI sub

Gate 3 · After cook · Latch · /quiz-gate · Eliminate unknowns your about what just shipped

Scroll horizontally to see all 6 nodes →

Gate 1 · /ck:plan red-team — agent checks agent

2-4 reviewer subagent hostile persona tore up the plan to find a failure mode that no one thought of. Which finding doesn't have evidence? file:line specifically auto-rejected — avoid vague complaints.

Gate 2 · /ck:plan validate — runs after red-team, before cook

Verification pass check "map vs territory" literally: grep codebase to see if the plan's claims (file, symbol, endpoint) really exist. Then interview 3-8 questions Friend Close the remaining open assumptions. The order red-team → validate is intended: for agent to tear up and edit the plan before finalizing it with others, to avoid finalizing on a draft that is about to be revised.

Optional gate · /codex:adversarial-review on plan — before cook, after validate (needs OpenAI sub)

Only for critical cases (migration, security, public contract). Run Final At the planning stage, after the plan has been refined by red-team + validate — attack the complete plan, looking for a place where the whole Claude family is blind.

Optional gate · /codex:adversarial-review on code diff — after cook, before quiz-gate (needs OpenAI sub)

The fixed gates are all Claudes that check Claude — same model family, same blind spots, reviewer will not catch errors that it makes itself. Cross gate model to agent other than model (GPT-5.5) in — properly eliminate the remaining unknown type: unknown unknowns by model itself. Focus text taken from the Deviations section of impl-notes. Details in section 07.

Gate 3 · /quiz-gate — human checker, gate last pin

Last gate before shipping, deactivate your own unknowns of what has just been shipped — the machine review code (or other model) has passed does not mean you fully understand the new behavior. Person is the stopping condition.

05 · pipeline is not always full

Scenario combos — pay an insurance premium commensurate with the risk

Full pipeline (stage 0→5) only for strange areas + blurred scope + high risk. More common situations require thinner combos.

Selection rules: each gate is insurance premium. Unknowns more, gate is thick, unknowns less, gate is thin. Running full pipeline for a familiar task is just as wasteful as skipping gate for a risky task.

06 · Pipeline cost tradeoffs

Where does Fable 5 fit?

Principle: the upfront cost of finding unknowns is cheap. Inferred to put the most expensive model into the process detect & decide, use cheap model for the process execute as directed — The better the plan, the better the model implementation will be.

Usage trap to remember: Claude Code's built-in Explore can inherit the model from the main conversation starting in v2.1.198. If the main session is using Fable 5, Explore can burn Fable usage too. To scout cheaply without affecting other subagents, create a custom subagent explore.md with name: Explore and pin model: haiku or model: sonnet. See the Claude Code docs on built-in subagents.

Anti-patterns to avoid: Use Fable for cook but Sonnet for plan - that means paying expensive model to make it guess that unknowns should have been eliminated before, exactly the trap of "poor map, expensive territory" that the article warns about.

07 · model cross gate

Codex — bring in a different model to review Claude

Condition\ Everything in this section needs an OpenAI subscription plan (ChatGPT Plus/Pro or API) and a logged-in Codex CLI. If not, skip it — the fixed 3-gate pipeline above is still enough.

Plugin codex-plugin-cc insert Codex/GPT-5.5 into Claude Code. The core value is not "model is stronger" but model KHÁC: every internal gate is a Claude testing Claude — with the same training, with the same systematic bias, the reviewer will not catch errors that it also makes. Codex has other blind spots → can eliminate unknown unknowns from model.

Setup

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/codex:setup

If you use Codex MCP instead of the plugin

Codex CLI can also run as an MCP server for another agent to call, but the MCP path means Claude is no longer constrained by the plugin's commands and gates. It can ask Codex during brainstorm, plan, cook, review, and phase close. This can work, but it needs explicit guardrails:

• When to ask: only ask at checkpoints with real risk — critical plans, material code diffs, security/migration/public contracts, or a debug loop after two failed directions.
• What to ask: every call needs a concrete artifact, concrete scope, concrete question, and a rule for rejecting findings without evidence.
• Maximum rounds: default to 1 round; round 2 only when round 1 caused a material change. Do not run an infinite ask → red-team → review → ask-again chain.
• Who decides: Codex should not approve the plan, close the phase, or clear the work for shipping by itself. Claude/human must adjudicate every finding: accept/reject with evidence, then apply fixes.

In a Claude Code workflow, if you use a keyword/feature like ultracode to call Codex and spawn a broader review session, treat it as review-only unless the user explicitly approves edits. Do not make it the default path: broad review sessions plus multiple rounds can cause heavy token bursts. See the OpenAI docs on Codex MCP.

Where each command sits in the pipeline

Sample prompt — adversarial review on plan

Place Codex on the 3rd review layer, after the plan has been refined — make that clear so it doesn't find what the lower layer captured:

Sample prompt — Copy & use

/codex:adversarial-review --wait Đây là implementation plan tại plans/<dir>/, chưa phải code — đã qua red-team và validate nội bộ. Đừng verify chi tiết file/symbol. Thay vào đó: (1) challenge HƯỚNG ĐI — đây có phải cách tiếp cận đúng không, có alternative đơn giản hơn không; (2) hidden assumptions mà plan đứng lên trên nhưng không nói ra; (3) tradeoffs bị đánh giá một chiều; (4) pressure-test các phase liên quan [điền risk area thật: auth/data loss/rollback/race].

Plans without commit are considered working-tree change (untracked files reviewable); if the plan is commit then add it --base <ref>.

Findings processing loop — human trigger, NOT auto

Adversarial-review locked read-only, returned output verbatim. User-controlled loop:

1. Codex adversarial runs round 1, return findings verbatim.
2. Claude (Fable/Opus) adjudicate: Accept/Reject used to find together with evidence — If the finding is the same as the verified decision, reject with source.
3. PERSON approves Accept list — gate people, cannot be removed.
4. Claude apply Approved fixes + consistency sweep.
5. Round 2 Only when the fix is ​​applied does the material change; focus text points to the correct corrected region. Maximum 2 rounds.

Why not auto-loop: prompt of Codex is "break confidence in the change, not validate it" — reviewer designed to ALWAYS find problems will never say "perfect". Auto-loop with reviewer is thus an endless loop by design. Person is the only valid stopping condition ("the rest is nitpick, move on"). Note: --resume only in rescue; adversarial-review stateless — round 2 must carry its own context in focus text.

Review gate — why is it OFF by default?

The only auto version of the plugin is Stop hook which reviews every turn that has edit code. Three reasons to turn off:

• Timeout up to 900s per turn — each edit must wait for review to complete before continuing.
• No hard loop guard seen in the code — OpenAI itself also warns the Claude-Codex loop.
• Per-turn gating paradox: Only worth it for unattended run, but OpenAI recommends only turning it on when you're sitting on the monitor — and the person watching is already gate.

Replace: /codex:adversarial-review run once at stage 4 — same coverage, one payment, someone advertises.

08 · Drawing from the second lesson

Redesign your system — the right way

Alex Finn's article makes the same argument as Thariq but at a higher level: instead of fixing each map, upgrade map plotter — your own coding operating system. Here are 4 principles to apply immediately.

Principle 1 · Put Fable into the system layer, not the task layer

A flaw in the system layer pays the above compounding price all task — so one Fable session for the redesign coding loop will amortize over hundreds of subsequent cook sessions. Fable is the best value for money when output is reusable structure (system, skill, plan), cheapest when output is just one execution.

Sample prompt — Copy & use

Thay vì làm ngay task này, hãy thiết kế cho tôi một skill/workflow tái sử dụng để MỌI task cùng loại về sau chạy qua nó. Loại task: [mô tả]. Output cần: quy trình từng bước, file SKILL.md (nếu phù hợp), và tiêu chí đo để biết nó có đang hoạt động tốt không.

Principle 2 · Audit from real artifacts instead of brain dump

Let Fable read directly rules/, skills, and git history — real data about how you work is much more powerful than your own words. Artifacts reflect actual behavior; The narrative reflects an image of the behavior.

Sample prompt — Copy & use

Đừng hỏi tôi làm việc thế nào — lời tự kể không đáng tin. Hãy đọc: thư mục rules/, danh sách skills đang cài, và `git log --oneline -50` của repo này, rồi tự dựng lại bức tranh workflow THỰC TẾ của tôi. Chỉ ra 3 chỗ friction lớn nhất, mỗi chỗ phải cite file hoặc commit làm bằng chứng — không nhận nhận định không có dẫn chứng.

Principle 3 · Verify by running

The new System must be tested on a real task then measure output — system only reveals weak points under real load, not during discussion. Prototype first, expansion later.

Sample prompt — Copy & use

System/skill vừa thiết kế xong: chạy thử nó trên đúng MỘT task thật sau đây: [task]. So sánh với cách làm cũ theo 3 tiêu chí: thời gian, số lần phải sửa lại, chất lượng output. Nếu không hơn rõ rệt, liệt kê chỗ cần chỉnh — đừng khen.

Principle 4 · Trigger redesign with rule of three

The same type of friction appears ≥3 times In impl-notes / journal / retro, it is worth redesigning system. Loop: work → build deviations → retro reveal pattern → redesign → test run → keep or discard.

Sample prompt — Copy & use

Đọc implementation-notes.md và journal/retro gần nhất của tôi. Nhóm các deviation/friction theo loại. Loại nào xuất hiện từ 3 lần trở lên? Với MỖI loại đó, đề xuất một thay đổi system NHỎ NHẤT khử được nó. Loại nào dưới 3 lần: bỏ qua, đừng đề xuất gì.

Redesign runs using cumulative evidence — Every system repair comes from real friction and is verified by a real run.