k1nak0/task-splitter
Splits an epic into PR-sized tasks and registers them as a GitHub Map Issue plus per-task Issues. In design mode it interviews the user, writes a behavior-only design doc with an ADR for each decision that doc states as a fact, and ships those docs as their own PR. In split mode it reads a design doc that already exists and goes straight to the breakdown.
Turn 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.md.
Decompose 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 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.
Main 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 skill to start splitting a new epic into tasks, or to split an epic whose design is already written.
Establish 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. Writes a machine-readable requirements-report.md either way. Use this at the start of every task-splitter run.