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 the active GitHub issue-read tool if one is available; use the exact tool name from the active tool list.

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: Save the roadmap

Once approved, call gsd_plan_milestone with milestoneId, title, vision and slices[]. Each slice needs sliceId, title, risk, depends (slice IDs, in dependency order), demo (one sentence showing what is demoable after the slice) and goal.

Fill the rest of the tool parameters: success criteria, key risks, proof strategy, verification classes, definition of done, requirement coverage, the horizontal checklist (omit for trivial milestones), and the boundary map (S01 → S02 produces/consumes — be specific, name real APIs/types/invariants).

The tool stores the roadmap in the database and renders .gsd/milestones/<MID>/<MID>-ROADMAP.md. Do not write or edit that file — 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 the active GitHub issue-write tool if one is available; use the exact tool name from the active tool list. 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.