ashermahonin Decompose Work
Purpose
Make implementation boring in the best way. Convert a big plan into small, owned, sequenced tasks that can run without stepping on each other.
Inputs
- Confirm requirements and architecture are approved enough to decompose.
- List deliverables and affected modules.
- Identify dependencies, shared files, contracts, and migration order.
- Decide which tasks can run in parallel and which must stay serial.
Decision process
- Create epics for coherent slices of value or infrastructure.
- Break epics into stories and tasks with clear done criteria.
- Assign each task a write scope, interfaces touched, validation command, and expected docs update.
- Build the dependency graph and critical path.
- Define parallel lanes only when file ownership and contracts are disjoint.
- Write merge order, conflict policy, and fallback if a lane blocks.
Decision boundaries
- Use Context7 MCP for current library, framework, platform, API, CLI, and configuration documentation whenever the task depends on external technology behavior.
Decision record
- Epics
- Stories
- Tasks
- Dependency graph
- Parallelization plan
- Agent role matrix
Ready when
- A task without validation is not ready.
- A parallel task without ownership boundaries is not parallel-ready.
- Do not split work by agent count; split by coherent boundaries.
- Keep merge order visible.
Handoff
Hand off each implementation task with scope, files, contracts, validation, docs, dependencies, and merge order.
References
references/parallelization-policy.md: Use this before running multiple agents or parallel implementation lanes.