task-decomposition
npx machina-cli add skill a5c-ai/babysitter/task-decomposition --openclawTask Decomposition
Overview
Decompose a technical plan into actionable development tasks. Each task is atomic, has clear acceptance criteria traceable to specification requirements, and includes dependency information for optimal execution ordering.
When to Use
- After technical plan is approved, before implementation
- When breaking down a large feature into implementable units
- When identifying parallelization opportunities in a task set
- When estimating effort and critical path for a feature
Key Principle
Every task must trace back to at least one specification requirement. Tasks must be atomic enough for a single development session. Dependency graphs must be acyclic.
Process
- Decompose components - Break architecture components into implementable tasks
- Define tasks - Each with id, title, description, acceptance criteria, dependencies, effort
- Build dependency graph - Show task ordering constraints
- Identify parallel groups - Tasks with no mutual dependencies
- Determine critical path - Longest dependency chain
- Generate test tasks - Testing tasks alongside implementation
- Map to requirements - Traceability from tasks to specification
- Human review - Approve task list before implementation
Tool Use
Invoke via babysitter process: methodologies/spec-kit/spec-kit-planning (task decomposition phase)
Full pipeline: methodologies/spec-kit/spec-kit-orchestrator
Source
git clone https://github.com/a5c-ai/babysitter/blob/main/plugins/babysitter/skills/babysit/process/methodologies/spec-kit/skills/task-decomposition/SKILL.mdView on GitHub Overview
Task Decomposition breaks a technical plan into actionable development tasks. Each task is atomic, has clear acceptance criteria traceable to specification requirements, and includes dependencies for optimal execution ordering.
How This Skill Works
Decompose components into tasks with id, title, description, acceptance criteria, dependencies, and effort. Build a dependency graph to enforce acyclic ordering, identify parallel groups, and determine the critical path. Generate test tasks alongside implementation and map every task back to a specification requirement.
When to Use It
- After a technical plan is approved and before implementation
- When breaking down a large feature into implementable units
- When identifying parallelization opportunities across tasks
- When estimating effort and calculating the feature's critical path
- When ensuring traceability from tasks to requirements
Quick Start
- Step 1: Decompose components of the plan into atomic tasks
- Step 2: Define each task with id, title, description, acceptance criteria, dependencies, and effort
- Step 3: Build the dependency graph, identify parallel groups, determine the critical path, generate test tasks, map to requirements, and perform a human review
Best Practices
- Trace every task to at least one specification requirement
- Keep tasks atomic so one development session can complete a task
- Ensure dependency graphs are acyclic to avoid loops
- Explicitly capture acceptance criteria and effort estimates for each task
- Obtain human review and approval of the task list before starting implementation
Example Use Cases
- Onboarding flow: split into backend API, frontend screens, and QA tests with dependencies
- Data pipeline upgrade: separate extraction, transformation, loading, and validation tasks
- Platform migration: decompose into schema changes, migration scripts, validation, and rollback tasks
- Performance optimization: measure, implement targeted code changes, and run regression tests
- Security hardening: audit, fixes, and verification tasks with traceability
