To Issues: Claude Code skill to split a plan into tasks

To Issues is a Claude Code skill, adapted by AR Labs from Matt Pocock's to-issues, that turns a plan into tasks AI coding agents can pick up one at a time. It is for anyone handing a large plan to coding agents. It reads a planning document and breaks the work into vertical slices, each a thin piece of functionality that runs end to end through every layer of the system. Each slice is classified as needing a human in the loop or safe to run unattended, and the slices are linked by the dependencies that decide their order. In our coding pipeline, the route every code change takes (spec, test-first build, second-model review, a person's merge), it is the one mechanism for fanning work out, used at the top of a large piece of work and again wherever a task turns out to be several tasks.

The original is Pocock's to-issues skill in his public skills repository, which upstream has since been merged into a skill called to-tickets. The core method is his: tracer-bullet vertical slices, the split between HITL (human in the loop) and AFK (away from keyboard) slices, and showing the breakdown to the user for approval before anything is created. We added the parts that fit our own pipeline: tasks created as beads with their goal fields filled in, fan-out at any depth of the task tree, a scenario coverage check, and a recorded check that the fan-out finished.

A bead is one tracked task in Beads, Steve Yegge's open-source issue tracker for coding agents, which we use for all durable work. A campaign is work planned in one PRP (product requirement prompt: a plan agents build from, in Rasmus Widing's format as we adapted it) and split into a tree of beads; a bead that holds other beads is a container.

How it works

The input depends on where the container sits. At the root of a campaign it is the campaign's PRP. Below the root it is the spec of a task that the spec stage found to be compound. Nothing else changes with depth: a container three levels down is fanned out exactly as the campaign was.

Vertical slices, not layers. The first slice is always a tracer bullet, the thinnest end-to-end path that proves the architecture works. Each later slice adds one capability end to end. A slice that touches only one layer, such as "build the database schema", is flagged; horizontal concerns such as authentication setup or CI are allowed, but labelled as such with a reason.

Human in the loop or away from keyboard. A slice is HITL when it needs a judgement nobody has made yet, or carries risk an unattended agent should not take: an unresolved architecture decision, security- or privacy-critical code, setup in an external dashboard, deployment with secrets, and the tracer bullet itself, which must be checked by hand. A slice that widens a pattern the tracer bullet already proved is AFK. When in doubt the skill chooses HITL, because over-classifying costs less than an autonomous mistake. If fewer than about 60% of slices come out AFK, the plan probably needs more detail.

The plan's owner approves before anything is created. The breakdown is shown as a numbered list with dependencies and classifications, and the skill iterates until the owner approves. It then writes a breakdown summary with the dependency graph and the reason for each classification, because the tracker's fields lose that bird's-eye view.

Coverage adds up exactly. The parent owns a set of acceptance scenarios, written in Gherkin (Given/When/Then). Each child claims the scenarios its slice covers, and a check passes only when the children's claims add up to exactly the parent's set: nothing dropped, nothing invented. Below the root, a container may not quietly shrink the set it was given.

The fan-out is recorded as finished. As its last act the skill runs a check that every child has its goal fields, exactly one HITL or AFK label, at least one scenario, and no dependency cycles, and records on the parent that the fan-out completed. Without that record, the pipeline would treat the new children as the leftovers of an interrupted run.

The judgement it encodes

Decomposition is not pull-request count. Each slice lands as one pull request that closes its bead. Wanting finer tracking inside a slice is never a reason to split it; the slice's bead may carry ordinary child beads for tracking instead.

A container is never closed by a pull request. A pull request attached to a container would close the whole subtree on merge, before its children are built. Shared groundwork that must land first gets its own foundation task.

The task graph is a hypothesis. It is a best guess from the planning document. The spec stage, which studies the actual code, may add dependencies, adjust scope, or find that a child is itself a container and send it back here.

Extract what, not how. The skill moves goals, acceptance criteria and boundaries from the document into the tasks. It does no deep codebase research and writes no implementation specs; each child learns what it is from its own spec pass.

The plan is decomposed, not consumed. After fan-out the PRP still holds research that cannot be re-derived from the code: known pitfalls, external references, validation procedures. Spec writers keep reading it until every child has a spec.

Point, do not photocopy. Shared design context in a parent spec is referenced from each child rather than copied into it.

Testing produces more issues. After each round of implementation, problems found in testing become new beads with a link to where they were found, are classified in turn, and feed back into the loop.

What exists today

The skill runs in every campaign in our coding pipeline and at every container below the root. It follows Grill Me, whose design brief feeds the PRP, and the task graph it creates is what Taskgraph maps.

Example

Illustrative example. One slice from a fan-out of a notifications feature:

## Issue 1: User sees a new-comment notification appear live
 
Type: vertical-slice
Classification: HITL (tracer bullet: verified by hand)
Blocked by: none
Parallelisable with: none
 
### What the User Sees
User A comments on a document -> server pushes an event -> User B
sees a badge appear without refreshing.
 
### Layers Touched
- Frontend: notification badge, socket client
- API: comment-created hook
- Service: notification fan-out (deep module)
 
### Acceptance Criteria
Scenario: Live notification on new comment (from the PRP)
 
### Test Boundary
The fan-out module: given a comment event, exactly one message is
queued per subscriber.