An LLM is a text engine. Strip the branding and that's the machine — it eats text and predicts more text. So the format I hand it isn't a detail, it's the whole game, and the densest text I have is plain markdown: almost no syntax tax, structured enough that Claude and I both read it at a glance. Once that landed I stopped writing plans about the work in prose and started writing them in the format Claude already lives in.

That became a loop I run on every project now.

SPEC, then PLAN, then execute

The process I settled on with recon-gen is boring on purpose:

1. I write a SPEC.md myself — what I'm building and why, in my words, no code (first cut).
2. I hand it to Claude and tell it to poke holes — review and ask questions, DON'T touch code (what it came back with).
3. I answer every question (answered).
4. Repeat 2 and 3 until Claude runs out of questions.
5. Claude turns the settled spec into a PLAN.md — the work split into numbered phases with checkboxes (the plan).
6. We walk the plan, ticking boxes as we go.
7. Back to the top for the next chunk.

Step 4 is the one people skip, and it's where the design actually happens. Claude is a reviewer that never gets bored of "wait, what happens if..." — answering its questions in the spec is cheap, and every answer is a bug I didn't write later. (Diff those commits: the growth between them is all design, zero code.)

direction: right
spec: "SPEC.md\nwhat + why, my words"
review: "Claude pokes holes\nI answer"
plan: "PLAN.md\nnumbered phases + checkboxes"
exec: "execute\ntick the boxes"
spec -> review: hand off
review -> spec: more questions
review -> plan: no more questions
plan -> exec
exec -> spec: next chunk

Where it drifts

This holds right up until it doesn't. Left to run, Claude drifts:

• Checkboxes get missed, or never made in the first place.
• It quietly invents its OWN numbering scheme — a different one than the session before.
• And TaskCreate, a task feature baked into the tooling that you can't turn off, keeps its own list alongside mine.

Each is survivable alone. Together they mean the plan I trust and the plan Claude is actually following slowly pull apart — and a plan I can't trust is worthless. Which lands me on the question that's a recurring theme for me: how do I make the system serve the process instead of fighting it?

Meet claude-plan-bridge

claude-plan-bridge is the answer; I built it to bring determinism to the process:

• It owns the PLAN.md shape (phases, numbering and structure) so Claude can't wander into its own scheme.
• It drives TaskCreate from my plan, so the feature I couldn't disable now follows the plan instead of racing it. This also reduces context pressure too!
• Every bit of state lives in git, outside the hook config.

It's been through a LOT of evolutions, each stricter than the last. recon-gen adopted it last and was by far the hardest — a MASSIVE plan with a mountain of accrued drift to standardize.

That standardization also handed me a story. The first run that rewrote recon-gen's sprawling plan into the bridge's shape broke Claude's helpful demeanor — I genuinely spent a few minutes talking an LLM off a ledge. (It was fine.) What settled it is the same thing that makes the whole approach safe: every scrap of planning state is in git, so any change is one revert away. That's literally how I did it — I showed Claude the rewrite was reversible.

I update this tool constantly. It's the guardrail that keeps the SPEC → PLAN → execute loop from quietly coming apart.