with one click
split-in-tasks
// Split a spec into small, ordered, deliverable tasks with requirement traceability
// Split a spec into small, ordered, deliverable tasks with requirement traceability
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | split-in-tasks |
| description | Split a spec into small, ordered, deliverable tasks with requirement traceability |
| argument-hint | <TICKET_ID or folder name> [--force] |
| user-invocable | true |
| allowed-tools | Task, Bash, Read, Grep, Glob |
Split a technical specification into small, ordered, dependency-aware tasks. Each task is tied back to specific requirements so the implementing agent never loses track of what needs to be built.
/split-in-tasks PROJ-123 # Split spec for ticket
/split-in-tasks "add-user-dashboard" # Split spec from a named folder
/split-in-tasks # Auto-detect from current branch
/split-in-tasks PROJ-123 --force # Overwrite existing tasks.md without prompting
Resolve the tasks folder:
PROJ-123, #42): sanitize it for use as folder name (e.g., #42 โ GH-42) to match how other workflow commands resolve task pathsgit branch --show-current | grep -oE '[A-Z]+-[0-9]+'Resolve the tasks base directory using the workflow config module (same as /brief and /spec):
PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT}"
node -e "const c = require('$PLUGIN_ROOT/workflows/lib/config'); console.log(JSON.stringify({ TASKS_BASE: c.TASKS_BASE }))"
Set TASKS_DIR="${TASKS_BASE}/${FOLDER_NAME}".
Read files from ${TASKS_DIR}/:
brief.md (required) โ Contains the requirements, user stories, and acceptance criteriaspec.md (required) โ Contains the technical specification, architecture, and implementation detailsgherkin.feature (optional) โ Contains the gherkin test scenarios. If present, each task must reference which scenario(s) it covers.If brief.md is missing: Stop with error: "No brief.md found at ${TASKS_DIR}/brief.md. Run /brief ${FOLDER_NAME} first."
If spec.md is missing: Stop with error: "No spec.md found at ${TASKS_DIR}/spec.md. Run /spec ${FOLDER_NAME} first."
If ${TASKS_DIR}/tasks.md already exists:
--force flag was passed: proceed (overwrite silently)You are the decomposer. Read both brief.md and spec.md in full, then follow steps 4.0 through 4.3 in order.
Before creating any tasks:
This list is the source of truth for requirement coverage. Every task you create MUST reference IDs from this list. Keep this list in working memory โ you will need it for coverage validation in Step 4.3.
Using the extracted requirement list as your guide, decompose the spec into tasks following ALL of these rules:
Rule 1 โ Atomicity: Each task must modify ONE logical component (e.g., one service, one UI module, one infrastructure unit) and produce ONE verifiable outcome (e.g., an API endpoint works, an agent classifies correctly, a DB table is created). If a task spans multiple components or produces multiple unrelated outcomes, split it.
Rule 2 โ Requirement Coverage:
Every requirement from your Step 4.0 list must appear in at least one task's Requirements Covered section. Orphan requirements (in spec but not in any task) and orphan tasks (no requirement mapping) must be resolved in Step 4.3 before proceeding โ add missing mappings or create/merge tasks until coverage is complete.
Rule 3 โ Independent Testability: Every task must be testable in isolation. If you can't write a test for it, it's not a task โ it's part of another task.
Rule 4 โ No Overlap: No two tasks should deliver the same code or satisfy the same requirement. If a requirement needs work across multiple tasks, split the requirement's concerns explicitly so each task owns a distinct piece.
Rule 5 โ Logical Ordering: Tasks are ordered by dependency. Foundational/infrastructure tasks first, then core logic, then integration/UI, then validation/checkpoints.
Rule 6 โ Separation Preference: Prefer separating: backend vs frontend, infrastructure vs application logic, data layer vs business logic, core vs integration. Clear ownership boundaries per task.
Rule 7 โ Task Count: Target 5โ15 tasks for a typical spec. Fewer than 5 means tasks are too coarse (agent will forget mid-task). More than 15 means tasks are too granular (overhead exceeds value).
Rule 8 โ Checkpoints: Insert a checkpoint task (no implementation โ just "run all tests, verify integration"):
Rule 9 โ Parallelization:
A task can be marked Parallel: Yes ONLY if ALL of these are true:
Parallel: No or Parallel: Partial with explanation.Rule 10 โ TDD Ordering:
Standard implementation tasks MUST order deliverables following the TDD cycle: RED (write failing tests) -> GREEN (implement to pass) -> REFACTOR (clean up). Each deliverable gets a bold phase prefix: **RED:**, **GREEN:**, **REFACTOR:**. When a task covers multiple behaviors, each behavior gets its own RED/GREEN/REFACTOR triplet.
Checkpoint tasks and config-only infrastructure tasks are exempt from the RED/GREEN/REFACTOR deliverables requirement. For those exempt tasks, use a non-phase deliverables list that describes the concrete verifiable work in execution order, for example: - Update config, - Validate config, - Document rollout/usage as applicable.
Anti-patterns โ DO NOT generate tasks like these:
Anti-patterns are enforced by workflows/lib/hooks/policies/task-description-quality.js โ the canonical blocked-pattern list. The following patterns will cause tasks.md writes to be blocked:
**RED:** are exempt.)If ${TASKS_DIR}/gherkin.feature exists:
After generating all tasks, verify coverage:
Requirements Covered sectionRequirement Coverage table (see output format below)Review all generated tasks and check:
No that could be Yes?)gherkin.feature is referenced by at least one task (if gherkin.feature exists)Refactor tasks if any issues are found. Re-validate coverage after any refactoring.
Write the generated content to ${TASKS_DIR}/tasks.md.
After saving, output:
/work ${FOLDER_NAME} to start implementation."## Task N โ <title>
### Type
<infrastructure | backend | frontend | integration | test | checkpoint>
### Description
<1-3 sentence summary of what this task delivers>
### Requirements Covered
- <requirement ID from Step 4.0>
- <requirement ID from Step 4.0>
### Deliverables
- [ ] N.1 <subtask description>
- Test: <acceptance criterion>
- [ ] N.1.1 **RED:** Write failing tests for <behavior>
- Test: Tests fail โ <expected behavior> is not yet implemented
- [ ] N.1.2 **GREEN:** Implement <behavior> to pass tests
- Test: All tests from N.1.1 pass
- [ ] N.1.3 **REFACTOR:** Refactor <component> for clarity
- Test: All tests still pass after refactoring
- _Requirements: <requirement ID> (<context>), <requirement ID> (<context>)_
- [ ] N.2 <subtask description>
- Test: <acceptance criterion>
- [ ] N.2.1 **RED:** Write failing tests for <behavior>
- Test: Tests fail โ <expected behavior> is not yet implemented
- [ ] N.2.2 **GREEN:** Implement <behavior> to pass tests
- Test: All tests from N.2.1 pass
- [ ] N.2.3 **REFACTOR:** Refactor <component> for clarity
- Test: All tests still pass after refactoring
- _Requirements: <requirement ID> (<context>), <requirement ID> (<context>)_
### Acceptance Criteria
- <criterion 1>
- <criterion 2>
### Dependencies
- None | Task N (reason)
### Parallel
- Yes | No | Partial (reason)
### Suggested Scope (optional โ include when file paths are inferable from the spec)
- `<path/to/likely/file.ts>`
- `<path/to/another/file.ts>`
---
## Task N โ Checkpoint: <what to verify>
### Type
checkpoint
### Description
Verify all prior tasks are correctly implemented and integrated.
### Acceptance Criteria
- All tests pass
- <specific integration verification>
### Dependencies
- Task N-1, Task N-2, ...
---
# Tasks
_Generated from: brief.md, spec.md_
_Ticket: <TICKET_ID>_
_TDD Protocol: Every non-exempt implementation task follows RED -> GREEN -> REFACTOR ordering in deliverables._
## Extracted Requirements
<The numbered requirement list from Step 4.0>
---
## Task 1 โ ...
...
## Task N โ Checkpoint: ...
...
## Requirement Coverage
| Requirement | Covered By |
|-------------|------------|
| R1 | Task 1 |
| R2 | Task 3 |
| ... | ... |
Test: line (acceptance criterion). Each subtask ends with a _Requirements:_ line with context annotations (e.g., _Requirements: R1 (validation logic), R3 (error handling)_)**RED:**, **GREEN:**, **REFACTOR:** nested within each subtask โ each subtask gets its own small TDD cycle. Checkpoint tasks and config-only infrastructure tasks are exempt (see Rule 10).# Tasks, metadata, and the extracted requirements listRule 11 โ Documentation Task:
If the spec references user-facing behavior changes, API changes, configuration changes, or existing .md documentation files are related to the changes, add a task of type checkpoint titled "Documentation Review" that verifies:
.md files are updated (README, architecture docs, API docs)