Issues is where the spec becomes a sequence of buildable pieces — and, notably, where the pipeline chooses not to have a separate planning step. There is no plan document between the spec and the work. The tickets are the plan.
That's a deliberate call. A plan doc and a set of tickets describe the same work twice, and two copies of the same thing drift apart the moment either is edited. Tickets already do everything a plan needs to do — they're claimable, orderable, and they carry their own dependencies — so a second artifact is pure overhead. The one thing plans historically bought that tickets don't is the too-big-to-see-the-whole-shape case, and that now has its own on-ramp before the pipeline even starts.
How it runs
The agent cuts the spec into tracer bullets: thin vertical slices that each go end-to-end and produce something demoable, sized to fit inside a single session's context. Wide changes that can't be one slice are sequenced expand-then-contract — add the new path, migrate onto it, remove the old — never a single sweeping rewrite.
Then the human approves the breakdown. Three things get signed off at once: how finely the work is sliced, how the tickets block one another, and — importantly — which tickets bundle into which pull request. Published tickets carry native blocking links, so at any moment the "frontier" of unblocked, ready-to-claim work is simply visible on the tracker.
What gets settled here
The granularity, the dependency graph, and the PR boundaries. That last one matters more than it looks. Pull-request size is decided here, while the slicing is visible and cheap to adjust — not accidentally, later, as a side effect of how many tickets happened to exist. Review attention is a scarce resource, and this is where its load gets set on purpose.
Built on
This step is built on Matt Pocock's to-tickets skill, with PR boundaries declared as part of the same approval so review load stays a deliberate choice rather than an accident of ticket count.