decompose-into-slices

Step 1: Load context

1. Read M###-CONTEXT.md for the active milestone — the brief is the source of truth for scope.
2. Read M###-ROADMAP.md if one exists — you may be refining rather than creating from scratch.
3. Read src/resources/extensions/gsd/templates/roadmap.md for the exact slice format. The parser depends on it.
4. If the plan came from a GitHub issue (user passed a URL or number), fetch it with mcp__github__issue_read.

Step 2: Explore the codebase briefly

If you haven't yet, spawn Agent(subagent_type=Explore) to map the modules the milestone touches. This is fast and prevents proposing slices that don't align with the codebase's seams.

Step 3: Draft vertical slices

Produce a draft list of slices. For each slice, capture:

• ID: S01, S02, ... — assigned in dependency order (earliest first).
• Title: short, descriptive, says what the slice delivers.
• Risk: high / medium / low — slices that retire the most uncertainty go first.
• Depends: [] or [S01] or [S01,S02] — which slices must finish first.
• Demo line: "After this: " — one sentence, concrete.
• HITL vs AFK (optional): does this slice require human interaction (architectural decision, design review), or can an agent ship it alone? Default to AFK when unsure.

Vertical-slice rules

• Each slice cuts through every relevant layer (schema, API, UI, tests, whatever applies).
• A completed slice is demoable or verifiable on its own.
• Early slices should prove the hardest thing works — build through the uncertain path.
• If a slice doesn't produce something testable end-to-end, it's probably a layer — restructure.
• If the milestone crosses runtime boundaries (daemon + API + UI; bot + subprocess + service; extension + RPC), include an explicit final integration slice that exercises the assembled system.

Step 4: Quiz the user

Present the draft as a numbered list with ID, title, risk, depends, demo line. Then ask (one round, not many):

1. Does the granularity feel right — too coarse or too fine?
2. Are the dependency relationships correct?
3. Should any slice be merged or split?
4. Any slices misclassified as AFK when they need human input?

Iterate on feedback until the user approves the breakdown. Do not proceed to Step 5 without explicit approval.

Step 5: Write the roadmap

Once approved, write or update M###-ROADMAP.md matching the template exactly. Critical format (parsers depend on it):

- [ ] **S01: Title** `risk:high` `depends:[]`
  > After this: one sentence showing what's demoable
- [ ] **S02: Title** `risk:medium` `depends:[S01]`
  > After this: one sentence showing what's demoable

Fill the rest of the template: Vision, Success Criteria, Key Risks, Proof Strategy, Verification Classes, Definition of Done, Requirement Coverage, Horizontal Checklist (omit entirely for trivial milestones), and the Boundary Map (S01 → S02 produces/consumes blocks — be specific, name real APIs/types/invariants).

Use write to the path .gsd/milestones/<MID>/<MID>-ROADMAP.md. Do not edit checkboxes by hand during normal execution — the gsd_* tools own state.

Step 6: Optionally file as GitHub issues

If the user explicitly asks (and only if — outward actions need confirmation), create one GitHub issue per slice with mcp__github__issue_write. Create in dependency order so "Blocked by" references can cite real issue numbers.

Issue body template

## Parent

#<parent-milestone-issue-number> (if applicable; otherwise omit)

## What to build

<concise description of this vertical slice — end-to-end behavior, not layer-by-layer>

## Acceptance criteria

- [ ] <criterion 1>
- [ ] <criterion 2>

## Blocked by

- Blocked by #<issue-number>
<or "None - can start immediately">

---
From milestone brief at `.gsd/milestones/<MID>/<MID>-CONTEXT.md`.

Do NOT close or modify any parent issue.