Split plan into tasks

Append a task breakdown to a plan so the work lands in small increments — one task, then a review, a correction pass, a commit — instead of one sweep. Authoring only: executing the tasks is a later, separate session.

Invocation: /split-plan-tasks <plan-path>

Read the plan

Ambiguous or missing path → ask. A plan with numbered steps and an acceptance-criteria checklist splits best; any plan markdown works — reference tasks to headings when steps aren't numbered, and drop the AC line when there is no such checklist.

A plan already carrying a task section → stop and ask which the user wants: replace it, add a second one beside it, or carry the ticked tasks forward and reformulate only the remaining work.

Done when the plan is read and, where a section already existed, the user has chosen.

Work out the split

• Task — the smallest chunk that leaves the project building and its tests passing, so it can be reviewed and committed on its own. Steps that only make sense together are one task, never two — building alone isn't the test: a step that only re-runs a generator (API clients, specs, snapshots) lands with the change it regenerates, and a step whose test must fail before the fix is written lands with that fix.
• Group — one PR: independently mergeable, delivering something coherent. Order the groups and state each one's dependency on earlier groups.
• Respect the plan's ordering: a task never precedes what it depends on.
• Front-load a hands-on slice. Among dependency-legal orderings, prefer the one whose first group leaves the app exercisable by hand — a screen to click where the plan touches a UI, else a command to run or an endpoint to hit — accepting a larger first group when that's what makes the slice whole, never scaffolding the plan doesn't call for. When nothing early gets there, say so when presenting.
• Both ways: every plan step lands in exactly one task and every acceptance criterion in at least one, and no task invents work the plan doesn't call for.

Present the whole breakdown with the obvious calls already decided, and walk only the genuinely doubtful boundaries as individual questions, each carrying your recommendation, worded via explain-in-simple-language when available. One approval gate before writing anything.

Done when every step and criterion is placed, the first group is exercisable or you've said why not, and the user has approved the breakdown.

Append the section

At the end of the plan file — the only edit made:

## Tasks

### Group 1 — <what this PR delivers>

- *Depends on* nothing
- *Try it* <what to open or run to exercise the app>

- [ ] **1.1 <short imperative>** — steps 2–3
  - *Done when* <what to run or look at to confirm it landed>
  - *Satisfies* AC-1, AC-4
  - *Commit* `<subject in the repo's commit style>`

Try it goes only on the first group that leaves the app exercisable.

Done when every task from the approved breakdown is in the file.

Close

State the plan's project-relative path and the tally (tasks, groups). Then hand off as a single copy-pasteable launch command — session name and prompt combined, in the launch syntax of the agent tool in use (vendor-agnostic — claude below is only the example), naming the session execute-tasks-<slug>, <slug> being the plan filename without id prefix or extension:

claude --name execute-tasks-<slug> "/execute-plan-tasks <plan-path>"

Then offer the alternative — clearing the current session instead (vendor-agnostic — /clear is only the example):

OR /clear and run:

/execute-plan-tasks <plan-path>

Done when the path, the tally, and both commands are printed.

Boundaries

• The task section is the only edit, replaced only when the user chose so in Read the plan; never touch the plan above it, never touch source files.
• No implementation — the breakdown is the output.