| name | slicing-into-tracer-bullets |
| description | Use when about to start building from a build-ready spec that is bigger than a single slice, or when the plan is organized by horizontal layer ("first all the schema, then all the API"). Triggers: "break this into issues/tasks", "what do we build first", "slice this spec", "plan the build order". |
Slicing into tracer bullets
Stage contract
- Stage: 4. Breakdown · Kind: method
- Inputs: the canonical spec (stage 2) + the module boundaries (stage 3).
- Outputs: an ordered list of vertical slices, each with acceptance criteria,
scope boundaries, and
Blocked by: links — one slice = one build-loop run.
- Entry gate: the spec is build-ready and it is bigger than one slice. A
single-slice job skips this stage — build it directly.
- Done when: every slice is end-to-end (touches all layers it needs),
demoable/verifiable alone, and its dependencies are stated. No horizontal-only
("schema-only", "API-only") items remain.
- Next: two engines. Sequential (default): the
converging-and-polishing skill —
run the build loop once per slice, each in its own fresh session seeded from the
spec + that one slice. Fleet (gate G3F: parallelizable across independent nodes AND
budget for a worker fleet): the delivering-mvp-fleet skill — it builds its own
board from the spec + slices.
- Maintains: —
Why vertical, not horizontal
A tracer bullet is a thin slice that cuts through all the layers it touches —
schema, backend, adapter, UI, tests — and delivers one small end-to-end behavior
that you can actually run and see. It is the opposite of a horizontal layer
("build the whole DB schema", then "build the whole API"), which produces nothing
demoable until the last layer lands and hides integration risk until the end.
Why it matters for an agent build: each vertical slice is small enough to build,
review, and converge in one focused session without the context filling up. The
integration seams — the places things actually break — get exercised on slice #1,
not discovered at the end. And each slice merges independently.
What makes a good slice
- End-to-end. It reaches every layer its behavior needs. If a slice can't be
demoed or verified without a future slice, it isn't a slice yet — it's a layer.
- Demoable / verifiable alone. There's a concrete way to see it work: a request
that returns the right thing, a screen that renders, a test that passes.
- Small. Sized to one build-loop run. If it won't converge in one session, split it.
- Scoped. State what it explicitly does NOT cover (goes to a later slice), so the
builder doesn't gold-plate.
- Behavioral, not procedural. Describe what the slice must do (interfaces,
contracts, acceptance criteria) — not how to code it, and not by pointing at file
paths/line numbers that will have drifted by the time it's built.
Ordering
- Dependency-first. A slice that another needs comes earlier; record it as
Blocked by: <slice>. The first slice should be the thinnest complete path through
the system (the "walking skeleton") — it proves the seams end to end.
- Value-and-risk next. After the skeleton, order by what de-risks or delivers most.
- One slice per build session. Each
converging-and-polishing run starts fresh,
seeded with the spec + exactly one slice — not the whole conversation. Keeping the
design→spec→breakdown work unbroken in one context window, then handing each slice
to a clean session, is the context hygiene that keeps every build sharp.
Slice template
### Slice <n>: <short behavioral title>
- **Delivers:** <the one end-to-end behavior, in user/behavior terms>
- **Layers touched:** <schema · API · adapter · UI · tests — only what it needs>
- **Acceptance criteria:** <concrete, testable, independently verifiable>
- **Out of scope:** <what a later slice covers — do not build here>
- **Blocked by:** <earlier slice(s), or "none">
Smells — you sliced it wrong if…
- A slice is named after a layer (
schema.md, "the API work") → horizontal; re-slice
by behavior.
- A slice can't be demoed until a later slice lands → it's a layer, not a tracer bullet.
- Slice #1 doesn't touch the UI or the outermost adapter → the walking skeleton doesn't
actually walk; the integration seams stay unproven.
- The list has no
Blocked by: anywhere on a multi-slice build → dependencies are hidden
and the build order is guesswork.
- A single slice clearly won't converge in one session → split it before building.
Source: Serge Shima (@aostrikov_agents_chat), Breakdown into slices.
