Turn the Destination Into Vertical-Slice Issues and a Dependency Graph

A large feature should be decomposed into independently grabbable issues that deliver thin, integrated slices of behavior. The issues should form a dependency graph rather than a fixed sequential plan. This keeps each task within the smart zone, creates early feedback, and enables safe parallel execution.

Coding agents tend to plan horizontally. A typical horizontal plan might be:

• Phase 1: implement all database changes.
• Phase 2: implement all API changes.
• Phase 3: implement all front-end changes.

The problem is delayed feedback. The database work cannot be validated as part of a working user flow until the API and interface are also present. The agent may complete several phases before discovering that the layers do not integrate correctly.

A vertical slice crosses the layers required to produce one observable result. A first gamification slice might include:

• The minimum schema change.
• A focused service that awards points.
• The route or event integration required to trigger it.
• A minimal dashboard representation.
• Tests that exercise the meaningful behavior.

This is a tracer-bullet approach. A tracer bullet makes the path visible while work is still in progress. In software, the equivalent is a thin end-to-end path that immediately shows whether the layers connect and whether the design is viable.

The issues are placed on a Kanban-style board with explicit blocking relationships. One issue may be blocked by nothing. Two later issues may both depend on it but not on each other. A final issue may depend on both. This structure is a directed acyclic graph. The graph naturally creates execution phases without forcing every task into a single numbered list.

A sequential multi-phase plan is effectively one loop that one agent must follow. A dependency graph exposes independent work. Once an upstream issue is complete, multiple unblocked issues can be assigned to separate agents.

Vertical slices give the agent feedback on the complete path early. They also give the human something visible and testable to review before the entire feature is finished. This reduces the cost of discovering that the architecture, user experience, or data flow is wrong.

Dependency-aware issues are also the bridge between planning and autonomous work. The backlog becomes a machine-readable queue from which an agent can select the next valid task without needing the whole feature in one context.

Convert the destination document into issue files using the following method:

1. Identify the smallest observable behavior that crosses the necessary layers.
2. Include enough schema, service, integration, and interface work to make that behavior

testable.

1. Keep the issue small enough for one fresh agent session.
2. Record which issues block it and which issues it blocks.
3. Mark whether the task can be completed away from the keyboard or requires human

participation.

1. Repeat until the destination is covered.

Review the decomposition before implementation. This is a cheap, high-leverage human check. Agents may claim to produce vertical slices while still creating a service-only or schema-only first task. Correct the issue explicitly: require the first slice to produce visible behavior across the relevant layers.

Do not force all issues into a predetermined phase count. Let dependencies determine the available work. A planner can later select all currently unblocked tasks for parallel execution.

A vertical slice is not automatically small. The first integrated path may still touch several modules. Its value comes from producing feedback, not from minimizing the number of files changed.

The decomposition requires human review because agents often revert to horizontal thinking. A poorly specified dependency graph can also create unsafe parallel work or unnecessary serialization.

The backlog may still contain critical bug fixes, development infrastructure, polishing work, quick wins, and refactors. The goal is not to exclude those categories; it is to avoid planning the feature so that all integrated feedback is postponed until the end.

Break the feature into independently grabbable vertical slices with explicit blocking relationships. Use the resulting dependency graph to obtain early end-to-end feedback and to expose work that can be executed in parallel.