Mikado Method: the Skill That Turns the Method into Non-Negotiable Rules
In the previous article, I showed why the Mikado method is the framework AI agents are missing on legacy code. Three failure modes (change greed, context scattering, the illusion of green) and one shared mechanism: a system trained to make progress, with no discipline to stop.
I ended on a promise: a ready-to-use skill.
Here it is: github.com/chaabani-anis/mikado-method. This article explains what it enforces on the agent, and why. The next one walks through a complete hands-on case.
Knowing the method isn’t enough
You might think it’s enough to write in the prompt: “apply the Mikado method.”
After all, the agent knows it. Ellnestam and Brolund’s book is in its training data.
In practice, it doesn’t hold. Under the pressure of the goal, the agent keeps its patches instead of reverting. It forgets to record blockers in the graph. It skips exploration to “save time.” Exactly the drifts described in the previous article: the method is known, the discipline erodes.
That’s the whole point of the skill: turning the method into non-negotiable rules, checked at every step.
What the skill enforces on the agent
Five rules structure the agent’s behavior.
Rule 1 — Three confirmation gates.
The agent stops three times to ask for your approval:
- Gate 1: before touching a single file, it restates the goal in business value. You confirm or you correct.
- Gate 2: when a failure suggests a pattern (Ports & Adapters, Strategy…), it proposes it before writing it into the graph.
- Gate 3: once the graph is stable, it asks for the delegation level before writing a single line of production code.
Rule 2 — Exploration writes no code.
During exploration, the agent attempts changes in the real files, captures the errors… then reverts everything. The only file that survives is the Mikado graph.
Rule 3 — One commit per leaf.
Each implemented node = one atomic commit containing the code, the tests, and the updated graph. The git history tells the refactoring node by node. No more 147-file PRs: each commit reviews in ten minutes.
Rule 4 — Children first.
In the graph, a child is a prerequisite of its parent. The deeper it is, the earlier it gets implemented. It’s the classic Mikado trap, and the skill locks it down.
Rule 5 — Mandatory validation.
The repo ships with validate-mikado.sh, a validator that checks the graph’s structure at every step: each node carries the commit that discovered it and the exact error that made it necessary, dependencies resolve, no cycles. If it fails, the agent stops. Period.
This last rule directly addresses context scattering: the graph isn’t a note in the prompt, it’s a versioned and verifiable artifact the agent re-reads at every iteration.
The real contribution: the delegation slider
Gate 3 deserves a closer look. Once the graph is stable and validated, the agent asks a simple question:
Exploration complete — N true leaves. Delegation level? (1 / 2 / 3)
- Level 1: you implement, the agent guides and reviews.
- Level 2: the agent implements leaf by leaf, and waits for your “ok” after each commit.
- Level 3: the agent runs through everything autonomously.
The fuzzy question “do I trust the agent?” becomes a graduated decision. And a reversible one: you can start at level 2, see that the first leaves are clean, and switch to level 3.
Installation
git clone https://github.com/chaabani-anis/mikado-method
cd mikado-method
./install.sh claude # Claude Code, current project
./install.sh claude --global # Claude Code, all projects
./install.sh opencode # opencode
./install.sh agents # Codex, Cursor, Copilot, Gemini CLI…
Then ask your agent for a cross-cutting refactoring. The skill takes over, Gate 1 first.
What’s next
The complete hands-on case I promised is published: decoupling a BillingService from its SMTP client, cycle by cycle, down to the final eight commits, with a companion repo whose git history can be replayed commit by commit.
The repo is MIT-licensed: github.com/chaabani-anis/mikado-method. Feedback and PRs are welcome.