Decompose To Issues

Use decomposition as context control, not project-management ceremony.

Workflow

Identify the user-visible or operational outcome.
Split by vertical slices that can be implemented, reviewed, and verified independently.
Put shared setup before dependent slices only when it unlocks multiple issues.
Mark dependencies explicitly. Check dependencies between issues: are they real, or are they artifacts of thinking horizontally?
- Real dependency: Issue B cannot be compiled, tested, or deployed without Issue A's code or schema in the target branch (e.g. Issue B consumes an API contract introduced in Issue A).
- Horizontal artifact: Dividing tasks by technical layer (e.g. Issue A for database migration, Issue B for API controller, Issue C for UI). Collapse these into vertical slices that deliver testable end-to-end functionality.
Target 3-7 issues for a typical plan. Fewer than 3 usually means slices are too fat; more than 7 usually means you are decomposing tasks instead of value. If a project genuinely requires more than 7 vertical slices, organize the work into milestone phases of 3-7 issues each, completing Phase 1 before decomposing Phase 2.
Keep each issue small enough for a fresh agent to complete in one focused pass when possible.

Each issue should include: