Interactive version
This piece comes with an interactive page: diagrams, scenarios and sample sessions. The link is created fresh on every click.
Quick summary: The stronger the model, the more a vague prompt costs you, because it confidently does the wrong thing instead of stopping to ask. My approach with Fable 5 is to spend the expensive model on finding unknowns and making decisions, then let cheaper models execute the plan, with a few fixed gates around the coding step. This post maps two posts on X, by Thariq and Alex Finn, onto the AgentKit workflow I use, with a table for picking gates by risk and a table for picking models by stage.
Fable 5 is expensive, so the question is not whether you can use it everywhere but where it pays for itself. Two posts on X helped me answer that: A Field Guide to Fable: Finding Your Unknowns by Thariq (@trq212) and The Most Valuable Thing You Can Do With Fable 5 by Alex Finn. I mapped their ideas onto the skill set of AgentKit (formerly ClaudeKit), added three skills of my own, and ended up with a six-stage pipeline that follows Thariq's core point: find the unknowns before you code.
Disclosure: I maintain AgentKit and have an affiliate relationship with it: the AgentKit link in this post is an affiliate link; buying through it gets you 30% off.
Commands in this post use AgentKit's ak-<name> skill names, in place since 3.0.0-beta.35 (October 21, 2026). Before that the commands read /ak:plan, and when I first built this workflow they were /ck:plan. How you call a skill depends on the runtime: /ak-plan in Claude Code, $ak-plan in Codex. The post uses the Claude Code form, so swap the prefix for your runtime. I start with the map and territory framing, then walk through the three custom skills, the pipeline, and how to pick a model for each stage.
Map and territory: the gap is the unknowns
The prompt and context you give Claude are the map. The codebase and its real constraints are the territory. The gap between the two is the unknowns.
With Fable 5, output quality is limited by how far you have clarified the unknowns, not by what the model can do. The stronger the model, the higher the price of a bad map, because it will confidently head in the wrong direction instead of stopping to ask.
Thariq uses the Rumsfeld matrix to split the unknowns in a prompt into four kinds:
| Kind | What it means | Example |
|---|---|---|
| Known knowns | What you spelled out in the prompt. Claude just reads and follows, no guessing. | The name of the endpoint to add |
| Known unknowns | What you know you have not decided yet. | A trade-off between two approaches, variable names, the data migration strategy |
| Unknown knowns | "I'll know it when I see it" standards you cannot put into words. They only surface when the output is wrong. | Tone, or naming conventions the team follows without writing down |
| Unknown unknowns | Questions you do not know you need to ask. This is the most dangerous gap and the main thing to eliminate. | Another place in the repo that must change too, which you have no idea about |
The rule that follows: the earlier you find an unknown, the cheaper the fix. Find it after the merge and the fix costs many times more, because by then the wrong map has already shaped the territory.
Three custom skills that cover three gaps
These three skills are not part of AgentKit core. I built them to fill the three gaps this method needs: finding unknown unknowns before coding, logging plan deviations the moment they happen, and checking that a human actually understands the change after coding.
All three are public: download the three skills (.zip). Each skill is a folder with a SKILL.md written to be runtime-neutral, so it works in Claude Code, Codex and other runtimes that read SKILL.md.
The zip has an outer fable5-unknowns-skills/ folder. After unzipping, copy the three skill folders inside it (keeping quiz-gate's references/ and assets/) into your runtime's skill folder, so the final path is ~/.claude/skills/blindspot/SKILL.md for Claude Code or ~/.codex/skills/blindspot/SKILL.md for Codex. They carry no ak- prefix because they are not part of the AgentKit kit. In Claude Code you call /blindspot; in Codex, $blindspot.
| Skill | Use it when | Result |
|---|---|---|
/blindspot | Before coding in unfamiliar code or a new domain | An evidence-backed report of unknown unknowns and a sharper prompt for the next step |
/impl-notes | While coding, when you hit an edge case | An implementation-notes.md file that logs decisions, deviations, and surprises as they happen |
/quiz-gate | Before merging, or when reading someone else's PR | An HTML page that explains the change with behavior questions; merge only after answering all of them correctly |
/blindspot: scan for blind spots before entering the territory
Use it when you step into unfamiliar code or a new domain, before coding.
- Reads the codebase and digs through
git logto find the user's unknown unknowns. It does not do the task for them. - Every finding must cite evidence: a specific file, a commit hash, or a doc. Vague speculation is rejected.
- The most valuable trick: find a commit that did a similar task (
git log --grep), then rungit show --stat <hash>. The list of files that commit touched is a ready-made checklist of touchpoints, and usually the strongest signal you have.
The main output is a better prompt, ready to paste into /ak-brainstorm or /ak-plan in the next step.
/impl-notes: log plan deviations as they happen
Use it while coding, when you hit edge cases or need to leave handoff notes.
- The file
implementation-notes.mdrecords three sections,Decisions,DeviationsandSurprises, at the moment they happen. It is not an end-of-session recollection like/ak-journal. - The note-taking rules live in the header of the file, not in conversation memory, because context compaction drops rules as a conversation grows. Any agent that rereads the file picks the rules up again.
- When an edge case forces a deviation from the plan, pick the conservative option (the smallest, most reversible change), log four lines, and keep going. Do not stop and wait for the user on a decision that can be reversed. The rule does not cover irreversible, security-sensitive, external or out-of-scope actions; those still need you.
This file feeds quiz-gate directly (deviations make the best quiz material) and /ak-journal.
/quiz-gate: a human checking a human
Use it before merging, or when reading someone else's PR.
- Generates an HTML explainer of the change (summary, context, intuition, blast radius) with a quiz about behavior, not trivia like renamed variables.
- The gate passes only when you answer every question about the change's behavior correctly. The skill does not block or perform merges in the repo; passing is a condition you set in your own workflow before merging. For each wrong answer, the skill explains the misunderstood concept using the exact code involved, then asks a new question aimed at that spot, until you pass.
- One important fix: while the gate is live, the report has the explainer and the questions but no answer key. The answers are written into the HTML only after the gate resolves (pass or abort). If they were written earlier, the user could read them and the gate would be pointless. The
--report-onlymode is the exception: it skips the live quiz and puts the answers in collapsed sections, for when you only want the explainer.
The quiz-gate verdict is the condition for running /ak-git or /ak-ship.
The six-stage pipeline
Each stage is an advance payment on the cost of finding unknowns, made while it is still cheap.
| Stage | Command | Main job | Add when risk is high |
|---|---|---|---|
| 0. Locate unknowns | /blindspot | Scan the codebase and git history, report unknown unknowns, "potholes", and a sharper prompt for stage 1 | |
| 1. Explore and design | /ak-brainstorm --html | Take the prompt from blindspot, read the codebase, interview you, produce two or three approaches and a design doc | /ak-predict (several personas debate) or /ak-scenario (probe edge cases along many dimensions) |
| 2. Plan | /ak-plan (or --tdd) | Write plans/<ts>-<slug>/plan.md and one file per phase | red-team (hostile agents tear the plan apart), then validate (check the plan against the real codebase). Critical cases with an OpenAI plan: add /codex:adversarial-review on the plan, run last |
| 3. Execute | /impl-notes init, /ak-cook, /impl-notes review | Create implementation-notes.md in the plan directory before cooking. /ak-cook <plan> implements; on a deviation, pick the conservative option, log it with /impl-notes log, and move on. At the end of the session, /impl-notes review distills lessons for the next one | |
| 4. Check understanding | /ak-code-review, then /quiz-gate | Code review is a machine checking code, quiz-gate is a human checking a human. Two different axes | With an OpenAI plan: insert /codex:adversarial-review on the code diff between the two, with focus text taken from the Deviations section of impl-notes |
| 5. Ship | /ak-git or /ak-ship, plus /ak-journal | Commit and push, or run the PR pipeline, only after the stage 4 gate passes. Journal reads impl-notes to reflect |
Three fixed gates and two optional cross-model gates around ak-cook
These are not duplicate checks. Each gate targets its own kind of unknown and sits on one side of the execution step. In running order:
- Gate 1, before cook:
/ak-plan red-team, removes the plan's unknown unknowns. - Gate 2, before cook:
/ak-plan validate, removes the known unknowns in your decisions. - Optional gate, before cook:
/codex:adversarial-reviewon the plan, for critical cases only, needs an OpenAI plan. - Execute:
/ak-cook. - Optional gate, after cook:
/codex:adversarial-reviewon the code diff, removes the model's own unknown unknowns, needs an OpenAI plan. - Gate 3, after cook and final:
/quiz-gate, removes your unknowns about what you are about to ship.
/quiz-gate always comes last, because the human is the stopping condition.
Gate 1: /ak-plan red-team, agents checking agents
A few reviewer subagents with hostile personas tear the plan apart looking for failure modes nobody thought of. Any finding without a specific file:line as evidence is rejected automatically, which keeps out vague complaints.
Gate 2: /ak-plan validate, after red-team and before cook
This is a literal map-versus-territory check: grep the codebase to see whether what the plan mentions (files, symbols, endpoints) really exists. Then the skill asks you a series of questions to settle the assumptions still left open. Running red-team first and validate second is deliberate: let the agents tear the plan apart and fix it before you settle things with a human, so you do not lock in decisions on a draft that is about to change.
Optional gate: /codex:adversarial-review on the plan
This gate runs before cook and after validate, and only if you have an OpenAI plan. Keep it for critical cases: data migrations, security, or a public contract (an API (Application Programming Interface) or data format other systems depend on). It runs last in the planning stage, after the plan has been hardened by red-team and validate, so it attacks the finished plan and looks for what the whole Claude model family misses.
Optional gate: /codex:adversarial-review on the code diff
This gate runs after cook and before quiz-gate, and only if you have an OpenAI plan. The fixed gates are all Claude checking Claude: same model family, same blind spots, so the reviewer struggles to catch mistakes it also makes. The cross-model gate brings in a model from another provider through Codex and removes the one remaining kind of unknown: the model's own unknown unknowns. The focus text comes from the Deviations section of impl-notes. Details are in the Codex section below.
Gate 3: /quiz-gate, a human checking a human
This is the last gate before shipping. It removes your own unknowns about what you are about to ship. Passing a machine code review (or one by another model) does not mean you understand all the new behavior.
You do not always need the full pipeline
Each gate is an insurance premium, so pay in proportion to the risk. The full pipeline, stages 0 through 5, is for work that is in unfamiliar code, vaguely scoped, and high risk all at once. More common situations call for a thinner combination.
| Situation | Combination | Skip |
|---|---|---|
| A plan exists from a previous session, now continuing | /ak-watzup to read status, read "Learnings for next session" in the old impl-notes, /impl-notes init, /ak-cook for the next phase, then /quiz-gate. No old impl-notes yet (you just added these three skills to a project that already used AgentKit)? Skip reading that section: /impl-notes init creates a new file in the active plan directory, and lessons accumulate from this session on | Stages 0 to 2, because those unknowns were paid for last session |
| Small bug fix in familiar code | /ak-fix, then commit. If you have to deviate from the plan, log one line with /impl-notes log | All gates. Quiz-gate for a ten-line fix is overkill |
| Unfamiliar code but clear scope | /blindspot <area>, then paste the better prompt straight into /ak-plan | ak-brainstorm, because there is nothing to debate once scope is settled |
| A completely new domain (not code) | /blindspot --domain (teach first, learn the vocabulary), then /ak-brainstorm --html | Scanning the codebase, because the gap is in knowledge, not in the repo |
| High risk (public contract, security, migration) | Full pipeline, plus /ak-predict or /ak-scenario in stage 1, red-team then validate in stage 2, and /codex:adversarial-review in stage 4 if you have an OpenAI plan. Quiz-gate is mandatory | Nothing |
| Claude is stuck, fixing the same thing over and over | /codex:rescue (needs an OpenAI plan) hands the task to an OpenAI model that sees it from a different angle. --resume continues the earlier thread | Changing gates will not help, because the problem is the model's blind spot and you need a different model |
| Plan done, medium risk, not worth a red-team swarm | /ak-plan validate (verify claims and settle assumptions), then /ak-cook | red-team (overkill for medium risk), /ak-predict, /ak-scenario |
| Reviewing someone else's PR | /quiz-gate --pr <n> on its own. Taking the quiz is how you read the PR closely | blindspot, impl-notes, because you did not write the code |
| Pure refactor, behavior unchanged | /ak-code-review plus the test suite | quiz-gate is optional, because there is no new behavior to misunderstand |
The rule of thumb: many unknowns, dense gates; few unknowns, light gates. Running the full pipeline on a familiar task wastes as much as skipping gates on a risky one.
Which stages should Fable 5 handle
The table follows the Claude 5 family as of this update: Fable 5.1 is the top tier, then Opus 5.5, Sonnet 5.5 and Haiku 5.5. "Fable" in the table means that tier, not version 5.0 specifically. If you run AgentKit on another runtime, keep the principle and swap in that runtime's equivalent tier.
Unknowns are cheap to pay for up front. It follows that you put the most expensive model on discovery and decisions, and cheaper models on execution that follows instructions. The better the plan, the cheaper the implementing model can be.
| Stage | Model | Why |
|---|---|---|
/blindspot | Fable 5 | The value is in interpretation: reading "potholes" out of git history and recognizing which commit is the pattern to follow. A weaker model just lists files. |
/ak-brainstorm, /ak-plan, /ak-predict | Fable 5 | These are architecture decisions. Get them wrong and no amount of cheap work later can save it. |
/quiz-gate (writing the questions) | Fable 5 or Opus | Good distractors require understanding the behavior better than the person who wrote the code. You answer; the model only writes the quiz. |
/ak-plan red-team | Fable as controller, Opus or Sonnet as reviewers | Reviewer subagents only need to find failure modes with file:line evidence, and the personas are predefined, so Opus is plenty. Adjudicating findings is where the thinking happens, in the main session. This is the clearest example in the pipeline of choosing a model per subagent. |
/ak-plan validate | Sonnet or Opus | Verification is a fairly mechanical grep against a checklist. The thinking is on the side of the person answering; the model only needs to ask in the right places. |
/ak-cook with a detailed plan | Sonnet | A good plan has already removed the unknowns, so execution is just following the map. This is where you save the most. |
/ak-code-review | Opus or Sonnet | Review against a checklist and evidence. Fable is only worth it when the change touches a public contract. |
/impl-notes log, /ak-git, /ak-ship, /ak-watzup | Haiku or Sonnet | Mechanical work: append a few lines, commit, summarize status. |
/ak-scout for raw file discovery | Haiku | Finding files with Glob and Grep is not worth burning Fable. If you use Explore or a subagent for a big scan, pin a cheap model first. Blindspot is the interpretation layer on top. |
/codex:review, /codex:adversarial-review, /codex:rescue | An OpenAI model through Codex (billed to a separate OpenAI plan) | Cross-model gates burn no Claude tokens and keep billing separate. The value is a different blind spot, not a stronger model. |
One usage trap: according to the Claude Code docs on built-in subagents, Explore inherits the main conversation's model, with one exception for Fable. On a Claude plan, an Anthropic Console account or an LLM gateway through ANTHROPIC_BASE_URL, Explore switches to Opus. Through Amazon Bedrock, Google Cloud, Microsoft Foundry or a Claude apps gateway, Explore stays on Fable and burns Fable usage. To scan cheaply without affecting other subagents, create your own explore.md subagent with name: Explore and pin model: haiku or model: sonnet.
The anti-pattern to avoid: Fable for cooking but Sonnet for planning. That means paying for the expensive model to guess unknowns that should have been removed earlier, which is exactly the bad-map, expensive-territory trap Thariq warns about.
Codex: bring a model from another provider in to check Claude
Everything in this section needs an OpenAI subscription (ChatGPT Plus, Pro, or the API) and a logged-in Codex CLI. Without one, skip the whole section; the three fixed gates above are enough. The descriptions of plugin behavior below follow the codex-plugin-cc docs and source as of when I wrote this.
The codex-plugin-cc plugin brings Codex and OpenAI models into Claude Code. Its core value is not a stronger model but a different one. Every internal gate is Claude checking Claude: same training, same systematic biases, so the reviewer struggles to catch mistakes it also makes. Codex has different blind spots, so it can remove the model's own unknown unknowns.
Setup
/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/codex:setupCalling Codex as a server instead of through the plugin
Codex CLI can also run as an MCP (Model Context Protocol) server that other agents call. Go that way and Claude is no longer limited to the plugin's commands and gates: it can ask Codex at any stage, from brainstorming and planning to cooking, reviewing, and closing a phase. That works, but it needs clear guardrails:
- When to ask: only at checkpoints with real risk, such as a critical plan, a substantial code diff, security, migrations, a public contract, or a debug loop that has tried two directions and is still stuck.
- What to ask: every call needs a specific artifact, a specific scope, a specific question, and a rule for rejecting findings without evidence.
- How many rounds: one by default. A second round only if the first led to a substantial change. No endless ask, red-team, review, ask-again chains.
- Who decides: Codex does not approve plans, close phases, or allow shipping on its own. Claude or a human adjudicates each finding, accepting or rejecting it with evidence, before anything gets fixed.
A review session with broader permissions (for example one opened through ultracode) should only review unless the user approves edits, and it should not be the default path, because many rounds burn tokens fast. See also the OpenAI docs on Codex and MCP.
Where each command sits in the pipeline
| Command | When | Role |
|---|---|---|
/codex:adversarial-review on the plan | End of stage 2, after red-team and validate | A third, cross-model check on the plan, for critical cases only (migration, security, public contract) |
/codex:adversarial-review on the code diff | Stage 4, after /ak-code-review, before /quiz-gate | The plugin's main intended use (review before shipping): challenge design choices, hidden assumptions, and trade-offs. Focus text comes from the Deviations section of impl-notes |
/codex:rescue | Any time Claude is stuck | The escape hatch. --resume keeps a separate Codex thread per session |
/codex:review | Stage 4 | A second opinion when the /ak-code-review result looks suspicious. It does not take focus text, so do not use it on plans |
Automatic review gate (/codex:setup --enable-review-gate) | Every turn that edits code | Off by default, reasons below |
Sample prompt: /codex:adversarial-review on a plan
Codex sits at the third review layer, after the plan has been hardened by the first two. Say so explicitly, so it does not go looking for what the lower layers already caught:
/codex:adversarial-review --wait This is an implementation plan in plans/<dir>/, not code yet, and it has already been through internal red-team and validate. Do not verify file or symbol details. Instead: (1) challenge the DIRECTION: is this the right approach, is there a simpler alternative; (2) hidden assumptions the plan rests on without stating them; (3) trade-offs that were judged one-sidedly; (4) pressure-test the relevant phases [fill in the real risk area: auth/data loss/rollback/race].An uncommitted plan counts as a working-tree change (untracked files can be reviewed). For a committed plan, add --base <ref>.
The findings loop: human-triggered, not automatic
/codex:adversarial-review is locked to read-only and returns its output verbatim. A human drives the loop:
- Codex runs round 1 and returns its findings verbatim.
- Claude (Fable or Opus) adjudicates: accept or reject each finding with evidence. A finding that conflicts with an already-verified decision is rejected with a citation.
- A human approves the accepted list. This is the human gate and it cannot be skipped.
- Claude applies the approved fixes and sweeps for consistency.
- Round 2 runs only if the fixes just applied were substantial, with focus text pointing at exactly the changed areas. Two rounds at most.
Why not loop automatically: the plugin's Codex prompt asks it to "break confidence in the change, not validate it". The prompt still lets Codex approve when it finds nothing, but a reviewer told to hunt for problems easily finds something new to nitpick every round. Left to loop on its own, the risk is that it keeps going with nobody deciding to stop.
So in my workflow, the human is the stopping condition, as in "the rest is nitpicking, move on". Note that --resume only exists for rescue. /codex:adversarial-review is stateless, so round 2 has to carry its own context in the focus text.
Why the automatic review gate is off by default
The plugin's only automatic piece is a Stop hook that reviews every turn that edits code. Three reasons to keep it off:
- Each turn can wait a long time: according to the plugin docs when I wrote this, the timeout is up to 900 seconds per turn, and every editing turn has to wait for the review to finish.
- I did not see a hard loop guard in the code: OpenAI itself warns about Claude and Codex looping back and forth.
- The per-turn gating paradox: it is only worth it for unattended runs, yet OpenAI recommends enabling it only while you are watching. And if a human is watching, the human is already the gate.
Instead, run /codex:adversarial-review once in stage 4: paid for once, reviewing the whole change at the end instead of every turn, with a human adjudicating. The trade-off is that problems surface later than with per-turn gating.
Lessons from Alex Finn: redesign your working system
Alex Finn's post makes the same argument as Thariq, one level up: instead of fixing each map, upgrade the machine that draws the maps, meaning your own system for working with coding agents. Here are four principles I took from it, each with a sample prompt.
Principle 1: put Fable on the system layer, not the task layer
A flaw at the system layer compounds across every task. So a Fable session spent redesigning your working loop gets amortized over hundreds of later cook sessions. Fable is worth the most when the output is reusable structure (a system, a skill, a plan) and the least when the output is a single execution.
Instead of doing this task right away, design a reusable skill or workflow so that EVERY future task of this kind runs through it. Task type: [describe]. Output: a step-by-step process, a SKILL.md file (if it fits), and criteria to tell whether it is working well.Principle 2: audit from real artifacts, not a self-description
Have Fable read your rules/ folder, your skills, and your git history directly. Real data about how you work is far more reliable than your own account of it: artifacts reflect what you actually do, while a self-description reflects what you imagine you do.
Don't ask me how I work; self-reports are unreliable. Read: the rules/ folder, the list of installed skills, and `git log --oneline -50` for this repo, then reconstruct my ACTUAL workflow. Point out the 3 biggest points of friction, each citing a file or commit as evidence. No claims without evidence.Principle 3: verify by running it
A new system has to be tried on one real task and its output measured. A system only shows its weaknesses under real load, not while you are discussing it. Prototype first, expand later.
The system or skill we just designed: run it on exactly ONE real task: [task]. Compare it with the old way on 3 criteria: time, number of rework rounds, output quality. If it is not clearly better, list what needs adjusting. Don't praise it.Principle 4: only redesign when a problem shows up three times
Only when the same kind of friction shows up three or more times in impl-notes, the journal, or a retro is that part of the system worth redesigning. The loop: work, accumulate deviations, spot the pattern in a retro, redesign, test run, then keep or drop.
Read my implementation-notes.md and my most recent journal or retro. Group the deviations and friction by type. Which types appear 3 or more times? For EACH of those, propose the SMALLEST system change that eliminates it. Types under 3 occurrences: skip them, propose nothing.Every system change should start from real friction and be verified by a real run.
What to take with you
- Find unknowns early. Fixing the map before you code is far cheaper than fixing the territory after the merge.
- Scale gates to risk. The full pipeline for unfamiliar, high-risk work; a thin combination for familiar work.
- Expensive model for decisions. Fable 5 for discovery and planning, cheaper models for executing a good plan.
Download the three skills blindspot, impl-notes and quiz-gate here: fable5-unknowns-skills.zip.
Read next: Guard rails in Claude Code and AgentKit explains the layers that block tool calls, which these gates rely on. When to use /ak-plan --deep --tdd covers the planning step in more depth. OMP Plan mode vs AgentKit ak-plan compares the two kinds of "plan". If you want the AgentKit skill set for this pipeline, that link is the affiliate link mentioned at the top.
Use this piece in your agent
Get an API keyCopy the text below and paste it into Claude Code, Codex or whichever agent you use. The agent reads the piece and checks it against the repo you have open.
Read "Fable 5 and the unknowns problem: fix the map before you code" on modernEngineer and apply it to this repo.
1. Call the content_get tool of the modernengineer MCP server with locale "en", slug "fable5-unknowns-workflow". If MCP is not connected or access is refused, read the page https://modernengineer.dev/en/library/fable5-unknowns-workflow instead.
2. Summarize the main steps of the piece and point out which apply to this repo.
3. Propose concrete changes and ask me before editing any file.Connect MCP in Claude Code (once)
claude mcp add --transport http modernengineer \
https://api.modernengineer.dev/mcp \
--header "Authorization: Bearer <API key>"This piece is open to everyone: without MCP, the agent can still read it straight from the link.
- Version
- v1.0.0
- Updated
- 04/07/2026
- Licence
- All rights reserved
- Slug
- fable5-unknowns-workflow
