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.
What you have clearly written in prompt. Claude just read and follow — no guessing required.
What you know yourself undecided — trade-off, variable name, strategy migration left open.
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.
Questions you didn't know you needed to ask. This is the most dangerous gap — and the main target to eliminate.
merge The repair cost is many times more expensive, because at that time the territory was misshaped by the map.
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.
Turn 'I don't know what I don't know' into a sharp, stick-and-go prompt.
Catch each deviation the moment it happens — before it becomes a mystery.
If you don't absolutely pass the quiz, you won't merge. It's that simple.
Details of each skill
/blindspot — blind scan before entering territory
- Scout codebase + peach
git logto 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) Alreadygit show --stat <hash>— Its footprint file is the available checklist touchpoint, usually the highest signal artifact.
/ck:brainstorm or /ck:plan in the next step./impl-notes — log deviation at the moment it occurs
- File
implementation-notes.mdghi 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.
quiz-gate (best deviations = quiz material) and /ck:journal./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.
/ck:git or /ck:ship.6-stage pipeline combining custom skill with ClaudeKit
Each period is an upfront cost of finding unknowns.
/blindspotScan codebase + git history → report unknown unknowns, potholes, and a sharper prompt to carry to stage 1.
/ck:brainstorm --htmlGet 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).
/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.
/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.
/ck:code-review + /quiz-gateCode-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.
/ck:git or /ck:ship + /ck:journalCommit/push or PR pipeline, run only after gate is in stage 4 PASSED. Journal reads impl-notes as feed to reflect.
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.
on the plan
on code diff
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.
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.
| Scenario | Combo used | Skip |
|---|---|---|
| There was a plan from the previous session, now continue | /ck:watzup read status → read "Learnings for next session" in old impl-notes → /impl-notes init → /ck:cook next phase → /quiz-gate. Don't have the old impl-notes yet (just added 3 custom skills to a project that used ClaudeKit before)? Skip reading Learnings — /impl-notes init Create a new file in the active plan dir, learnings accumulate from this session. |
Phase 0-2 — unknowns paid the fee in the previous session |
| Small bug fix, familiar area | /ck:fix → commit. Loi deviation then /impl-notes log |
The entire gate — quiz-gate for fixing 10 lines is an overdose |
| Strange area but scope is clear | /blindspot <area> → Paste better-prompt straight in /ck:plan |
ck:brainstorm — there's nothing to discuss when scope is locked |
| Completely new domain (not code) | /blindspot --domain (teach-first, learn vocabulary) → /ck:brainstorm --html |
Scout codebase — the gap is in knowledge, not repo |
| High risk (public contract, security, migration) | Full pipeline + /ck:predict//ck:scenario at stage 1+ red-team → validate at stage 2+ /codex:adversarial-review in stage 4 (if there is OpenAI sub); quiz-gate obligatory |
Don't give up anything |
| Claude stuck — debug loop, fixed again and again but failed | /codex:rescue (needs OpenAI sub) — assign task to GPT-5.5 looking from another blind spot; --resume continue old thread |
Changing gate does not solve the problem — the problem is in the blind spot of model, another model is needed |
| Plan completed, moderate risk — not worth swarming red-team | /ck:plan validate — verify claims + interview final assumption → /ck:cook |
red-team (overdose for moderate risk), /ck:predict//ck:scenario |
| Review PR written by others | /quiz-gate --pr <n> used alone — quiz is a way to read PR in depth |
blindspot, impl-notes — not the code I wrote |
| Pure refactor, behavior unchanged | /ck:code-review + test suite |
quiz-gate optional — no new behavior to misinterpret |
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.
| Stage | Model | Why |
|---|---|---|
/blindspot |
Fable 5 | The value lies in the interpretation: reading git history into "pothole", realizing which commit is a pattern worth following. Weak model only lists files. |
/ck:brainstorm, /ck:plan, /ck:predict |
Fable 5 | Architectural decision - if wrong here, all subsequent steps will be meaningless. |
/quiz-gate (generate question) |
Fable 5 / Opus | A good Distractor requires a deeper understanding of behavior than the code writer. The person who answered is you, model pointed out the topic. |
/ck:plan red-team |
Fable controller + Opus/Sonnet | Reviewer subagent just needs to find the failure mode with evidence file:line (predetermined persona — Opus is more than capable). New adjudicate findings require intelligence, run in the main session. For example per-subagent is the most beautiful pipeline. |
/ck:plan validate |
Sonnet/Opus | Verification pass is mechanical grep according to tier checklist. Intelligence lies with the person answering — model just needs to ask the right question. |
/ck:cook according to detailed plan |
Sonnet | A good plan has eliminated unknowns; implementation is follow-the-map. The biggest savings place. |
/ck:code-review |
Opus/Sonnet | Review by checklist + evidence; Fable is only worth changing to public contract. |
/impl-notes log, /ck:git, /ck:ship, /ck:watzup |
Haiku/Sonnet | Mechanics: append a few lines, commit, summarize status — no brainer. |
/ck:scout raw discovery |
Haiku | Glob/Grep file discovery is not worth burning Fable usage. If you use Explore/subagents for a large scout pass, pin a cheaper model first; blindspot is the interpretation layer above that. |
/codex:review, /codex:adversarial-review, /codex:rescue |
GPT-5.5 (usage OpenAI, separate subscription) | Cross gate model — no Claude token burning, separate billing; The value is in the blind spot other not the more powerful model. |
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.
Codex — bring in a different model to review Claude
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
| Command | Time | Role |
|---|---|---|
/codex:adversarial-review above plan |
End of phase 2, AFTER red-team + validate | 3rd model cross gate on the plan — only for critical cases (migration, security, public contract) |
/codex:adversarial-review above code diff |
Stage 4, later /ck:code-review, before /quiz-gate |
Genuine use case ("review before shipping") — challenge design choices, hidden assumptions, tradeoffs; focus text taken from the Deviations section of impl-notes |
/codex:rescue |
Anytime Claude gets stuck (debug loop) | Escape hatch — --resume keep thread Codex separate per session |
/codex:review |
Stage 4 | Second opinion upon results /ck:code-review suspicious; Does not accept focus text so DO NOT use for plan |
Review gate (/codex:setup --enable-review-gate) |
Each turn has an edit code | Default OFF — see why below |
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:
/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:
- Codex adversarial runs round 1, return findings verbatim.
- 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.
- PERSON approves Accept list — gate people, cannot be removed.
- Claude apply Approved fixes + consistency sweep.
- Round 2 Only when the fix is applied does the material change; focus text points to the correct corrected region. Maximum 2 rounds.
--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.
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.
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.
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.
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.
Đừ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.
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.
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.
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.
Đọ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ì.