design-behaviorTurn a requirements report into a behavior-only design doc under docs/design/, updating docs/design/index.md and merging into docs/prd.md. Reads existing design docs to flag (not auto-resolve) conflicts. Use for Phase 2 of task-splitter, after understand-requirements has written requirements-report.
plan-tasksDecompose a design doc into PR-sized tasks with a dependency graph, acceptance criteria, verification method, and a brief implementation sketch per task. Writes task-breakdown-plan.md. Use for Phase 3 of task-splitter, after design-behavior has written the design doc.
register-tasksRegister a confirmed task breakdown as a GitHub Map Issue plus per-task Issues, using the gh CLI. Use for Phase 5 of task-splitter, after the user has confirmed the task-breakdown-plan.md produced by plan-tasks and Phase 4 has opened the design-doc PR.
task-splitterMain entry point for task-splitter. Runs in one of two modes — design, which interviews the user, writes a behavior-only design doc, splits the epic, ships the docs as a PR and registers GitHub Issues; or split, which reads a design doc that already exists and registers Issues from it. Invoke this s
understand-requirementsEstablish what a task-splitter run is building. In design mode, conduct a full structured requirements interview covering goals, features, constraints, scope boundaries, and definition of done. In split mode, read most of that out of an existing design doc and ask only what the doc cannot answer. Wr