Coding Planner: Claude Code skill for spec-driven development

Coding Planner is the Claude Code skill, built at AR Labs, at the entry point to our spec-driven coding pipeline: the fixed route every non-trivial code change takes, from a spec through a test-first build and a second-model review to a person's merge. Before any code is written, the skill answers one question: is this one coherent piece of work, or work that fans out into several pieces that each deserve to be tracked? It then hands the work to the right first stage and keeps the run moving. The pipeline as a whole is described in the coding pipeline, and the wider Coding Planner tooling it runs on in the Coding Planner project; this page covers the routing skill that sits at its door.

A few terms recur below. A bead is one tracked task in Beads, Steve Yegge's open-source issue tracker for coding agents; we record all durable work as beads, linked by dependencies. A PRP (product requirement prompt) is a plan agents build from: the goal, the reasons, the acceptance criteria and the implementation slices. The PRP format comes from Rasmus Widing's PRPs-agentic-eng, adapted into our own template; we built the routing skill itself. A gate is a point work cannot pass until a condition is met; here, a stage's result needs approval before the next stage starts, and the driver is the process that moves each bead from stage to stage.

How it works

Work enters the pipeline in one of two shapes, and both carry a bead.

• A lone task is a single bead. It walks the standard route: a spec (a written specification for the task: what to build and how each criterion is proved) grounded in the current code, a test-first implementation, an independent review, and delivery.
• A campaign is work that decomposes. Its root goes through a design interview and a PRP, the PRP is fanned out into child beads, and each child then walks the same route as a lone task.

The skill itself routes and records; it does not research or plan. Each destination is a separate command (spec generation, PRP creation, implementation, review), and the skill invokes the one the route calls for.

The judgement it encodes

One routing decision, and it does not need to be clairvoyant. The only question is whether the work decomposes into pieces worth their own beads. When in doubt, the work enters as a lone task. The spec stage includes a complexity assessment, and if it finds the bead is really several pieces, it hands the bead to the fan-out skill. That escalation is recorded as an explicit ruling on the bead rather than happening silently.

There is no third shape. Work too small for a bead, such as a comment fix or a single obvious correction, does not enter the pipeline at all. It is simply done. If the only reason to track a change would be to waive every check on it, the change did not belong in the pipeline.

Rigour does not depend on the route. A lone task passes the same gates as a leaf inside a campaign. What scales is the evidence demanded at completion, and that is calibrated per slice by risk, not by how the work was routed.

Provenance, not appearance. When work arrives as an existing bead, the skill checks which stages have actually run from the bead's recorded history. A hand-written bead with a rich description can look exactly like one the pipeline produced, so shape is never treated as proof.

An autonomy dial. Each run carries a level that says which gates the driver may pass without a person: hold waits for a person at every gate and never moves on its own; hitl (human in the loop) asks first, and advances only after a silence window of four hours, recording that it did so; wave, the default for a lone task, passes the spec and implementation gates; deep also passes fan-out and integration. Every automated check still runs at every level, so the dial removes a person's approval, never a check. Some steps wait for a person whatever the dial says: writing the design record, approving the PRP and merging to main.

Keep going. When a decision belongs to a person, the session asks it with a recommended answer, records the question on the bead, and carries on with other work. If the decision is reversible and blocks the next step, the session takes its own recommendation, records that it did, and lets the later answer override it. Work discovered mid-run becomes a new bead straight away, linked to the bead that found it. When the current work rests, the session picks the next runnable bead itself.

What exists today

We use the skill to build our own software. An earlier version, which sorted work into three tiers of complexity rather than the task-or-campaign binary described here, is public on GitHub under the MIT licence. The current version, which replaced the tiers with the binary, is not released separately. The project behind it is described in Coding Planner.

Example

The skill carries three worked routing examples. Abridged, they read:

Request: "Fix button styling on the login page"
One file, one obvious correction; other buttons show the pattern.
Route: none. Below the bead threshold, so it does not enter the
pipeline. Do it directly.
 
Request: "Add error handling to all API calls"
Three service files and an existing error-handler pattern to follow.
One coherent piece of work; no new patterns, no schema changes.
Route: lone task. Create one bead, then generate its spec.
 
Request: "Implement a real-time notifications system"
Fans out: notification service, WebSocket manager, UI, state
management, API. New patterns and a new external integration.
Several independently reviewable deliverables.
Route: campaign. Offer the design interview, then create the PRP.