When building is fast, the unit of planning shrinks to match. A bolt is a thin, shippable slice reviewed and integrated the same day.

The product manager decides the cadence. The architect decides the cut. Getting the second one wrong is what makes the first one fail.

This is the delivery loop, shared between the two of them. It is the same ground as Ship in the engineering lead's journey, told as a procedure rather than as a role.

_{▸ Open the picture full size}

Before the first bolt, while the team is still planning in fortnights.

The agent builds a story in hours, then sits idle while the team waits for the sprint review. Meanwhile leadership wants to see something every day.

Same ten days. The difference is where the risk sits.

Cadence is a product decision because it is a promise about evidence: how often it arrives, and what counts. The answer that makes the rest of this page work is something merged, not something demonstrated. A demo can be assembled from branches; a merge cannot.

Put both in one pair of hands and you get a plan that is optimistic about order and pessimistic about pace, which is the combination that produces a demo on day fourteen.

1. Decide how often evidence arrives, and write down what counts. Merged to main and green on its slice is evidence. Working on my branch is a status update wearing the same clothes.
2. Fix the integration deadline, not the start time. A team that agrees "merged by four" has a cadence. A team that agrees "we start at nine" has a habit.
3. Do not promise ten bolts because there are ten days. The cut decides how many there are; the cadence decides the rhythm they arrive in. Confusing the two is how a cut gets padded to fit.
4. Name a standing time for raising a bad cut. Nine in the morning, in the standup, before the day is spent. Move 6 is the procedure; this is the slot it happens in.
5. Publish the day's bolt and its one unknown where leadership can read it. Daily evidence is exactly what the cadence is being bought with, and an unread log is not evidence.
6. Agree what happens on a day that fails. One bolt, one unknown, one reason — so a failed day produces a finding rather than a recovery plan. Say that out loud before the first one.

# Cadence · <feature> · agreed <date>
PM <name> owns this document. The architect owns the cut it points at.

## The promise
| | |
|---|---|
| Evidence arrives | <daily> |
| What counts as evidence | <merged to main, green on its slice in the harness> |
| What does not count | <a branch, a demo assembled by hand, a screenshot> |
| Integration deadline | <16:00 local, every working day> |
| Where it is published | <the bolt log, link> |

## The day
| Time | What | Who |
|------|------|-----|
| <09:00> | <standup: did yesterday's bolt integrate? what is today's one unknown?> | <team> |
| <09:15> | <re-cut raised here, if the bolt cannot be built alone> | <engineer -> architect> |
| <by 16:00> | <merged, reviewed by band> | <engineer + reviewer> |
| <16:30> | <daily note to leadership, three lines, from what merged> | <PM> |

## When a day fails
<One bolt, one unknown, one reason. A failed day produces a named finding by 16:00 and
the next day's bolt is unchanged unless the architect re-cuts.>

## What the PM will NOT do
- <decide the order of the bolts>
- <approve a pull request they cannot evaluate>
- <add a bolt to fill a day>

Done when — evidence arrives daily, it is something merged, and the integration deadline is a time of day rather than an intention.

Once the cadence exists, and before anyone starts day one.

A bolt must be buildable and testable alone. That constraint sets the order, and it is not the order the backlog is in.

_{▸ Open the live, interactive version}

The ordering rules, in priority order:

1. The walking skeleton first. The thinnest end-to-end path, with no model in it. It proves the pieces connect, which is the assumption everything else rests on.
2. Pure exact code early. It is unit-testable in isolation, so it never blocks and never waits.
3. Checkers after the steps they check. Obvious, and still mis-ordered often.
4. The plug before any gated write that needs it. This is the classic failure: the rebook bolt is scheduled for day four and the MCP server it needs for day six.
5. The proof last. The harness needs something to run against.

One unknown per bolt. Then a day can fail for exactly one reason, and you know which.

Tool: Sprint-to-bolt planner

The five rules are not preferences; each one removes a specific failure that costs a day:

The cut comes from the paper design: the exact steps are already tagged, the tools are already banded, and the gated writes are already named. If the cut is hard to produce, the usual cause is that the map does not exist yet.

1. Start from the map, not from the backlog. Every exact step is a candidate bolt that stands alone; every consequential tool is a bolt with a plug in front of it.
2. Write a depends-on column before writing a day column. The order falls out of the dependencies; choosing days first means bending dependencies to fit them.
3. Give every bolt exactly one unknown, and name it in words. Can it beat the desk? is an unknown. Build the ranker is a task.
4. Split any bolt with two unknowns. A two-unknown day cannot fail informatively: the standup produces a discussion, and the discussion takes the next morning too.
5. Check the plugs explicitly, in one pass. Walk every gated write and confirm the thing it calls is already merged. This single pass removes the most common ordering error there is.
6. Assign a band per bolt from the most dangerous tool it touches. The band comes from the path, never from the author, and it decides the review before the review is needed.

# Bolt cut · <feature> · <n> bolts · architect <name> · <date>

## The order, and the rule that produced it
| Day | Bolt | Depends on | The ONE unknown | Band | Rule |
|-----|------|-----------|-----------------|------|------|
| 1 | <walking skeleton — read a booking, show it. NO MODEL> | — | <do the pieces connect?> | R1 | skeleton first |
| 2 | <fare_difference(), exact, unit-tested> | 1 | <the rounding rule> | R1 | exact early |
| 3 | <visa and codeshare eligibility, exact> | 1 | <where the partner rules live> | R1 | exact early |
| 4 | <rank_alternatives(), best-guess, measured> | 2 | <can it beat the desk?> | R2 | |
| 5 | <independent checker after ranking> | 4 | <which model judges> | R2 | checker after |
| 6 | <MCP server, reads open> | 1 | <auth to the booking system> | R2 | plug before consumer |
| 7 | <rebook() gated write> | 6 | <idempotency> | R3 | |
| 8 | <issue_refund(max 400) + confirmation token> | 7 | <who mints the token> | R4 | |
| 9 | <shadow path behind a flag> | 5, 8 | <flag plumbing> | R2 | |
| 10 | <golden set and harness in CI> | 9 | <slice tagging> | R1 | proof last |

## Plug check — walked <date> by <name>
| Gated write | The plug it needs | Plug day | Consumer day | OK? |
|-------------|-------------------|----------|--------------|-----|
| <rebook()> | <MCP server> | <6> | <7> | yes |

## Bolts that were split, and why
| Original | Two unknowns | Became |
|----------|--------------|--------|
| <"rank and price the options"> | <the ranking quality AND the rounding rule> | <bolts 2 and 4> |

## Not in this cut
<what was deliberately left out, and which later cut it belongs to>

Here are the bolts for <feature>, each with a one-line description and a depends-on
column: <paste>.

Produce a day-by-day order in which every bolt's dependencies come strictly before it.

RULES, applied in this priority order:
1. The walking skeleton first — the thinnest end-to-end path with NO model in it.
2. Pure exact code early. It is testable alone, so it never blocks anyone.
3. Checkers after the steps they check.
4. Any plug (MCP server, connector, adapter) BEFORE the gated write that needs it.
5. The proof — golden set and harness — last.

Then report, separately and BEFORE the plan:
- any CYCLE, where two bolts wait on each other. A cycle is always a mis-cut and means
  one of them is really two bolts. Name which one.
- any plug scheduled after its consumer in the order I gave you
- any bolt with NO dependencies that I had scheduled late
- any bolt carrying more than ONE unknown, and how you would split it

If there is no walking skeleton in my list, add one and say what it would cover.
Do not add anything else. A plan with a bolt I did not ask for is worse than a short one.

Done when — every bolt can be built on its scheduled day without waiting for anything, and the plug check has been walked row by row.

On the first day of the new cadence, not gradually.

The standup question is the load-bearing change. Two questions, both answerable in a sentence, both producing a fact rather than a narrative. A status round produces "I'm continuing with the ranker", which is true, unfalsifiable and worth nothing.

The review change is the one that fails quietly. Same-day integration only works if review capacity is available the same day, and that means routing by band rather than reviewing everything twice — see How to Review by Risk Band.

1. Replace the status round with the two questions, and hold the line for a fortnight. People revert to narrative under pressure, and the first failed bolt is the pressure.
2. Demo from what merged, with nothing prepared. If the demo needs preparation it is not evidence of the cadence, it is evidence of a good preparer.
3. Move review to the same day and route it by band. R1 goes to the harness and one look at the end; R4 gets two named approvers, every time.
4. Make "integrated" part of done, out loud. A bolt that meets its story and sits on a branch has not happened, and saying that once in week one saves saying it five times in week three.
5. Keep planning to tomorrow only. Planning further ahead re-creates the sprint, because a two-week plan makes today's finding expensive to act on.
6. Put the one unknown on the board, not in someone's head. It is the only thing that makes the next morning's standup answerable in a sentence.

# Bolt day · <date> · <feature>

## Standup, <09:00>, <n> minutes
| Engineer | Did yesterday's bolt integrate? | Today's ONE unknown |
|----------|--------------------------------|---------------------|
| <name> | <yes, 15:40, harness green on <slice>> | <can the ranker beat the desk on same-day?> |
| <name> | <no — see the re-cut note> | <blocked, raised to the architect at 09:05> |

Nothing else is discussed here. Anything longer than a sentence moves to a named
conversation with two names and a time on it.

## Today's bolt
| | |
|---|---|
| Bolt | <n · title> |
| Story file | <path> |
| Band | <R2, from the path rule> |
| Reviewer | <name, assigned now, not at 16:00> |
| Integration deadline | <16:00> |

## Demo, from what merged
| Merged | Slice | Harness | Shown as |
|--------|-------|---------|----------|
| <bolt n> | <codeshare> | <82% against a bar of 80%> | <the actual run, not a slide> |

## Done, for today
- [ ] Meets the story
- [ ] Passes its slice in the harness
- [ ] **Integrated to main**

Done when — standup asks the two questions and nothing else, and the demo is whatever merged.

The evening before the bolt, or the morning of it — never during.

A bolt that needs a chat thread was cut wrong, or its file is incomplete. Six parts, one file, versioned next to the code:

# Bolt 7 · rebook() gated write

## Context      (by reference, never pasted)
  /context/shared/standards.md · /context/domain/booking-model.md
  /context/product/architecture.md · ADR-004, ADR-007

## Spec         (EARS)
  WHEN the passenger accepts a proposed alternative
   AND the fare difference has been computed
  THE SYSTEM SHALL rebook the segment within 10 seconds.
  BOUNDARY  Never rebook without a computed fare difference.

## Tools        rebook(pnr, segment, fare_delta, confirmation) → R3

## Tests        golden slice: "rebook" (40 cases, bar 85%)
                unit: rebook_requires_fare_delta, rebook_is_idempotent

## Done when    harness green on the rebook slice, integrated to main, trace row written

## Cost         ~1,900 tokens/call, mid tier

It is BMAD's story and spec-driven development's unit at once. Because it is a file, it is reviewable as a diff and versioned alongside the code it produces.

The six parts each answer a question the builder would otherwise ask, and the order is deliberate:

Context by reference is the part teams get wrong most often. A path is read at build time and is always current; a paste is a copy that was true once.

1. Write the file before the day starts, and never during it. A file written mid-build is a transcript of what happened, not a brief, and it cannot be reviewed.
2. Reference context by path, never paste it. Paths stay current, cost nothing to keep current, and make the story file reviewable as a short diff.
3. Copy the spec from the agent PRD rather than rewriting it. Two versions of an EARS clause is two specifications, and the build follows the one in front of it.
4. Name the tools with their bands and their required parameters. rebook(pnr, segment, fare_delta, confirmation) says more about the design than a paragraph would.
5. Write the tests before the implementation exists, and require them to be seen failing. A test that has never failed has not been shown to test anything.
6. Treat every question the builder has to ask as a defect in the file. Log it, fix the template tonight, and the next bolt is cheaper. That loop is the actual product of this move.

# Bolt <n> · <title>
_Day <n> · Band <R<n>> · Architect's cut <date> · One unknown: <in words>_

## 1 · Context      (by reference — paths only, never pasted)
  <context/shared/standards.md> · <context/domain/<model>.md>
  <context/product/architecture.md> · <ADR-00n, ADR-00n>

## 2 · Spec         (EARS — copied from the agent PRD, not rewritten)
  WHEN <trigger>
   AND <precondition>
  THE SYSTEM SHALL <observable behaviour> within <n> <unit>.
  BOUNDARY  Never <forbidden action> without <the control>.

## 3 · Tools
  <tool_name(param, param, param)> -> <R<n>>
  <what it must NOT be able to do: e.g. no write while the shadow flag is on>

## 4 · Tests        (written first, and seen failing)
  golden slice: "<slice>" (<n> cases, bar <n>%)
  unit: <name_of_test>, <name_of_test>

## 5 · Done when
  <harness green on the <slice> slice, integrated to main by <16:00>, trace row written>

## 6 · Cost
  <~n tokens/call, <tier> tier> · <expected calls per case: n>

## File defects found while building this bolt
| What the builder had to ask | Fixed in the template? |
|-----------------------------|------------------------|
| <> | <> |

Write the six-part story file for this bolt.

BOLT: <one line from the cut, with its depends-on and its one unknown>
AGENT PRD: <paste, or give the path>
AVAILABLE CONTEXT PATHS: <list them>

OUTPUT SHAPE — exactly six numbered sections, in this order:
  1 Context (PATHS ONLY — never paste file contents)
  2 Spec (EARS, copied verbatim from the PRD where it exists)
  3 Tools (signature, required parameters, band)
  4 Tests (golden slice with a bar, plus named unit tests)
  5 Done when (one testable sentence, with a time in it)
  6 Cost (tokens per call and tier)

RULES:
- Anything you do not know goes in a final list headed GAPS. Do not invent a bar, a
  band, a token figure or a test name to make the file look complete.
- Do not rewrite the EARS clause. If the PRD's wording is ambiguous, quote it and add
  the ambiguity to GAPS.
- The file must be buildable with no further conversation. Read it back and ask what a
  builder would still have to ask; put each of those in GAPS too.

Build this bolt. The story file is the whole brief: <paste file>.

RULES:
- Work only inside the paths the file names. If you find a problem in an adjacent file,
  write it down at the end; do not fix it. A second fix makes the review two unknowns.
- Read context by the paths in section 1. Do not ask me to paste any of them.
- The unit tests named in section 4 are written first and must be seen failing.
- Nothing in section 3 changes: signatures, bands and confirmation parameters are fixed.
- If you need something that is not in the file, STOP and say what it is. Do not
  improvise it, and do not build around it.

OUTPUT, in this order:
1. The failing tests
2. The implementation
3. The command output showing them green
4. A list headed FILE DEFECTS — everything you needed that the story file lacked
5. A list headed OUT OF SCOPE — problems you found and deliberately did not fix

Done when — the bolt can be built with the chat window closed, and every question that still had to be asked is written down as a defect in the file.

When the cut exists and before it is agreed, as the check on the order.

A useful measure of how risky a plan is: the sum, over every day, of the unknowns still open.

exposure = Σ, over every day, of the unknowns still open

Two plans, same ten bolts:

The point of the skeleton is not that it is impressive. It is that it retires the largest unknown — "do these pieces connect at all" — on day one, for almost no cost.

Counted out, the difference is stark. Ten unknowns retired one a day gives 10+9+8+…+1 = 55 unknown-days. The same ten held open until day nine and then cleared gives 10 × 9 + 1 = 91. Same work, same people, same ten days, and two-thirds more time spent not knowing.

The curve is more useful than the total. A plan whose curve is flat for the first four days has its risk in the wrong place, whatever its total says, because a finding on day five costs five days of built work and a finding on day one costs half a day.

1. List the unknowns before you list the bolts. There are usually fewer than the bolt count, and two bolts sharing an unknown is a hint that one of them is not carrying its own.
2. Assign exactly one unknown to each bolt, and mark the day it is retired. Retired means answered by something merged, not by a conversation.
3. Add the column up and plot it. Ten numbers. It takes two minutes and it is the only view that shows the shape of the risk rather than its total.
4. Look at the first three days, not the total. A curve that is flat early is the failure mode, and reordering early bolts is nearly free before the plan starts.
5. Rank the unknowns by what they would cost if answered late. Do the pieces connect costs the whole plan; the rounding rule costs an hour. Retire the expensive ones first.
6. Re-plot after any re-cut. A re-cut that moves a plug also moves an unknown, and the curve is how you check the new order is not worse than the old one.

# Exposure · <feature> · plan <version> · <date>

## The unknowns, ranked by what they cost if answered late
| # | The unknown, in words | Cost if it comes back badly on day 9 | Retired by bolt |
|---|----------------------|--------------------------------------|-----------------|
| 1 | <do the pieces connect at all?> | <the whole plan> | <1> |
| 2 | <auth to the booking system> | <bolts 6-9, four days> | <6> |
| 3 | <can the ranker beat the desk?> | <the feature's value line> | <4> |
| 4 | <the rounding rule> | <an hour> | <2> |

## The curve
| Day | Bolt | Unknown retired | Still open | Running total |
|-----|------|-----------------|-----------|---------------|
| 1 | <skeleton> | <#1> | <9> | <9> |
| 2 | <fare_difference> | <#4> | <8> | <17> |
| 3 | | | | |
| ... | | | | |
| 10 | | | **0** | **<n>** |

**Exposure = <n> unknown-days.** Comparison order <B> scored <n>. Chosen: <A>, because
<the curve falls from day one rather than on day nine>.

## Shape check
| Question | Answer |
|----------|--------|
| Is the curve flat for the first <3> days? | <no> |
| Is the most expensive unknown retired first? | <yes — bolt 1> |
| Does any bolt carry two unknowns? | <no — <x> was split> |

Here is a bolt plan: one row per day, with the bolt, its dependencies and its single
unknown. <paste>

OUTPUT SHAPE:
1. A table: day | bolt | unknown retired | unknowns still open | running total.
2. The total exposure in unknown-days, with the arithmetic shown for the first three
   rows so I can check it.
3. The same computation for ONE alternative order that you propose, and the difference.
4. A SHAPE CHECK: is the curve flat for the first three days? Which unknown is the most
   expensive if answered late, and on what day is it retired?

RULES:
- exposure = the sum, over every day, of the unknowns still open at the end of that day.
- An unknown is retired only by something that merges. A conversation does not retire it;
  if a row claims one, flag it.
- Flag any bolt carrying more than one unknown, and any unknown that is really several.
  Both make the curve look better than the plan is.
- Do not reorder to minimise the total at the cost of the dependency rules. State the
  rules you preserved.

Done when — the curve falls from day one, the most expensive unknown is retired first, and no bolt carries two.

At nine in the morning, in the standup — never at two in the afternoon.

Say so before starting it, not halfway through. A bolt that cannot be built alone was cut wrong, and the fix belongs with the architect, not with the engineer who discovered it at 2pm.

The usual causes:

The information is nearly always available at nine. What is usually missing is somebody willing to say the cut was wrong before spending the day proving it, which is a cultural property rather than a technical one — and it is bought by the architect responding with a re-cut rather than a defence.

The three-question test, before opening the editor:

1. Run the three questions before opening the editor. Two minutes, every morning, and it is the whole of this move's cost.
2. Raise it in the standup, not in a message an hour later. The architect is in the room and the day has not been spent, which are the two conditions that make a re-cut cheap.
3. Say what is missing, not that you are blocked. rebook needs the MCP server, which is day six is actionable in an hour. Blocked is a status.
4. Let the architect re-cut, and do not route around it. An engineer who builds the missing half to unblock themselves has produced a two-unknown day and a review nobody can band.
5. Write the re-cut down, with the cause. Plug after consumer, cut horizontally, or two unknowns bundled — the cause is what stops the same mistake in the next cut.
6. Take the replacement bolt from the same list, not from the backlog. The plan has other bolts with no unmet dependencies; the backlog has priorities, which is what the cut was avoiding.

# Re-cut · bolt <n> · raised <date> at <09:05> — BEFORE the build started
Raised by <name> · Decided by <architect name> · Time to decide: <1 hour>

## The three questions
| Question | Answer |
|----------|--------|
| Does everything this bolt calls already exist on main? | <no — <the MCP server> is day 6> |
| Can it be tested without other unmerged work? | <yes> |
| Is there exactly one unknown? | <yes> |

## What is missing, specifically
<rebook() calls the MCP server, which is scheduled for day 6. This is a plug ordered
after its consumer.>

## Cause
<plug after consumer | cut horizontally, not vertically | two unknowns bundled>

## The re-cut
| | Before | After |
|---|--------|-------|
| <MCP server, reads open> | day <6> | day <4> |
| <rebook() gated write> | day <4> | day <6> |

Exposure re-checked: <unchanged / n unknown-days, from n>.

## Today's bolt instead
<bolt <n>, which has no unmet dependencies>

## What goes back into the next cut
<check every gated write against its plug in one pass — this is rule 4 and it was
missed on <date>>

Here is tomorrow's bolt story file: <paste>. Here is what is currently on main:
<paste the module list, tool list, or let me point you at the repository>.

Answer these three questions, in this order, with evidence:
1. Does EVERYTHING this bolt calls already exist on main? List each dependency and where
   you found it, or say it is missing.
2. Can this bolt be tested without any other unmerged work? Name the tests and what each
   one needs.
3. Is there exactly ONE thing here we do not know? If there are two, name both and
   propose the split.

Then, if any answer is no, classify the cause as exactly one of:
  PLUG AFTER CONSUMER · CUT HORIZONTALLY · TWO UNKNOWNS BUNDLED
and propose the re-cut, including which bolt should be built tomorrow instead.

RULES:
- Evidence for question 1 means a path or a symbol you actually found, not an assumption
  that it probably exists.
- Do not propose building the missing piece as part of this bolt. That is the failure
  this check exists to prevent.
- If all three answers are yes, say so in one line and stop.

Done when — the three questions were asked before the editor was opened, and any re-cut was raised in the morning with its cause written down.

The first bolt was a walking skeleton: read a booking, show it, no model anywhere in it. It shipped by four in the afternoon, and what it bought was not the feature but the answer to the question every other bolt was resting on — whether the pieces connect. The exact code went on days two and three, so review capacity was free when the ranking bolt arrived. The one re-cut came on day four and was raised at nine in the morning rather than at two: rebook() needed the MCP server scheduled for day six, a plug ordered after its consumer. Moving the plug cost an hour. Discovering it mid-build would have cost the day.

Three of the six moves are visible in that paragraph: the cut put the skeleton first and the exact code early, the ceremony gave the re-cut a nine o'clock slot, and the re-cut itself was raised as a cause rather than as a blockage. The hour it cost is the whole argument for the other five moves.

Exercise. Take your current sprint. Write each story on a line with a "depends on" column, then order them so that every item's dependencies come before it.

Exercise 2. Take the ordered list you just produced and compute its exposure: for each day, count the unknowns still open, and add the ten numbers up. Then move one bolt and compute it again.

Exercise 3. Take the story file for the next thing your team is about to build and hand it to a coding agent with the chat window closed. Count the questions it has to ask.

Next: How to Review by Risk Band · How to Prove the Bar · Role: Engineering lead · The Eight Loops