Fire one prompt and walk away. No hands on the wheel between plan, build, audit, and sign-off: /develop hands back a branch that already cleared your gates. Here's the machinery, and how to stand up your own.
This page is the concept: what orchestrated /develop is and why. To run it on your own project, head to Use the plugin.
Build it by hand and you're on the wheel the whole time: re-prompting at every handoff, eyeballing "done," looping back each time CI rejects. Hand the same spec to an orchestrator and you kick it off and walk away: it walks a durable plan, clears mechanical gates, resumes itself if it crashes, and hands back an audited branch.
We didn't land here by taste. Each generation closed a specific gap in the last. Vanilla, plus three generations of the skill (ad-hoc, dynamic workflow, and today's plan-walking orchestrator): four generations of the approach, with representative token and agent counts from a real project's runs (anonymized).
These are effective tokens per run: the raw total down-weighted by how each token actually bills. Raw totals look alarming (the current method's is ~570M) but cache reads are ~95% of that volume and bill at ~1/10 the input rate, so counting them at face value over-states real spend by roughly 5-6× (more for single-context methods, less for ones that fan out fresh agents). Weighted for that, a run is closer to ~75-125M effective tokens, still large but the honest figure. (Output is under 1% of the raw total, which is why an earlier output-only ~3M number looked absurd against a real run.) These are representative figures from a real project's runs (anonymized). Effective medians sit close: Skill Only ~75M · Mechanical ~110M · Dynamic Workflow ~120M · Vanilla ~125M. The spread is the story: Dynamic Workflow's fan-out gives it the worst tail (~310M effective on one run), Skill Only the widest range, Vanilla the heaviest steady median. Spend isn't what separates these methods; reliability and predictability are.
Click a phase: what it does, which skills / agents / tools it draws on, and how it nests, forks, or gates. The dots mark each node's mechanics.
The walk is a tree, not a line. Control runs left → right along the phases, dipping down into each phase's agents and back up before the next: the "back and forth," without crossing wires. Pick a size; the tree grows real nesting, forking, and phases as scope rises. All of it mirrors what /develop does: lean by default, with forks and ladder-climbs only where they fire.
Most pipelines run at flat quality. This one compounds: every run's leftovers book new controls at the right layer (a hook, gate, rule, agent, or plan), the pipeline strengthens, and audit/tidy load amortises toward an irreducible floor. The wheel is that loop: watch the controls accrue and preventable escapes run to zero.
Strip the project specifics and this is a handful of reusable parts. Start small (one generalist executor, a plan file, real controls), then add specialists, forks, and feedback where the pain shows.
You don't have to hand-roll it. The develop plugin's /develop:init discovers your repo's real gates and scaffolds exactly this shape, fitted to your stack, not transplanted. The parts below are what it builds, so you can understand it, own it, and grow it. Use the plugin on your project →
Everything here is one of three things. Learn the trio; the rest is composition.
A reusable procedure: what runs, in what order. Called by name (/develop, /plan-work, /tidy). It directs; it rarely lifts.
A desk with its own fresh context and a narrow remit. Hand it a brief, it does one job, returns a short result. One desk filling its context never touches the next.
The thin loop that walks the plan and dispatches the desks. It holds only phase status, never the heavy reading, so it clears dozens of agents without filling up.
How one orchestrator becomes dozens of coordinated desks without filling its own context. Nesting buys depth; forking buys breadth.
Seven portable moves: each a principle the pipeline leans on, most mapping straight to Anthropic's Building Effective Agents (tagged ≈). The takeaway on each is the part that travels to any stack.
The moving parts of /develop. Click a card for what it does and the exact file you'd write.
The real shape of each file type, frontmatter and all. Switch tabs to compare.
The develop plugin stands up this exact shape on your codebase by discovering your real gates, not copying someone else's. Three commands: scaffold once, run per feature, tune periodically.
It's only as good as the checks you give it. The flow can only verify what's mechanically checkable: strong rules, real CI gates, and hooks are what let it (and the flywheel) actually compound. The guide covers how to set that up.