What makes an implementation plan useful?
“Build login, dashboard, database, and settings” is a feature list. A plan explains which complete user outcome comes first, which responsibilities support it, what it depends on, and how to verify it. A screen can be finished while its data disappears after refresh; the outcome is still incomplete.
Start from a product brief and architecture, or identify the missing decisions before committing to a sequence. Keep the plan adaptable: repository inspection can reveal different files or dependencies, while changing a confirmed product rule still needs a deliberate decision.
Copy the implementation plan template
Use one milestone block per complete outcome. Include only meaningful dependencies and checks. Let the agent inspect actual code locations; do not fill the plan with invented paths or a rigid list of every edit.
Editable implementation plan
# Implementation plan: [app name / next change] ## Starting point Product brief and architecture: [links + current versions] Repository/baseline: [exact version; unknown if not inspected] Run instructions and safe test data: [how to verify the baseline] Verified behavior: [what currently works and how it was checked] Preserve: [journeys, records, interfaces, and product rules] ## First complete outcome [One user starts from X, completes Y, and can verify Z.] Scope includes its UI, saved state, access rules, and important failure path. ## Milestone [number]: [observable outcome] Depends on: [necessary preceding outcomes] Affected boundaries: [architecture responsibilities] Code locations: [inspect and identify; do not invent paths] Work: [connected implementation steps] Acceptance: - Given [state], when [action], then [observable result]. - Reopen and verify [saved/delivered state]. - As [other role], verify [allowed/denied action]. - On [conflict/retry/failure], verify [safe user-visible behavior]. Evidence: [version, environment, commands/journey, observed result] Done when: [all acceptance checks pass; limitations are recorded] ## Remaining milestones and dependencies [Outcome | depends on | preservation duties | acceptance evidence] Use complete outcomes rather than a list of screens or files. ## Decision and change boundaries Implementer may decide: [routine technical/design choices] Builder must resolve: [consequential product rules and commitments] If inspection changes the plan: [finding, affected outcome, revised work] Preserve confirmed intent; update the plan when implementation reality changes. ## Release gate [Real-environment persistence, access, conflicts, service failures, migrations, deployment, recovery, and remaining operating duties] Owner: [who verifies and releases] ## Progress and evidence [Milestone | not started/in progress/verified | evidence | remaining limits] Files changed or model confidence alone do not prove completion.
Filled example: plan the same room-booking app
This illustrative plan uses the room-booking requirements and architecture linked below. Members must reserve a room and find the same booking after reopening; overlapping active bookings cannot both succeed. Members cancel their own bookings, and managers manage all bookings. It is an example plan, not a claim that this app has been built or tested.
Sequence complete outcomes and their dependencies
The overlap rule belongs in the first working booking milestone. Deferring it would produce a demo that already violates the app’s promise. Manager controls can follow once the member journey and its ownership checks are credible.
| Milestone | Depends on | Done when |
|---|---|---|
| 0. Demonstrated starting point | Confirmed first-release rules and available project/environment. | The agent can run the baseline, identify the auth/storage approach, and record what is present or missing. |
| 1. Member reserves and reopens a room booking | Baseline; member identity; authoritative booking operation. | The end-to-end UI/write/read journey works, an overlapping request is rejected, a repeated request does not duplicate the booking, and saved state survives reopening. |
| 2. Member finds and cancels owned bookings | Verified reservation and ownership boundaries. | My bookings shows owned records; cancelling frees the slot; another member cannot cancel that record. |
| 3. Manager manages all bookings | Verified shared booking operations and explicit manager authorization. | A manager can perform the agreed controls; a member cannot obtain those privileges by changing a client request. |
| 4. Verified first-release environment | The complete member/manager journeys and required configuration. | The real deployment passes persistence, access, conflict, and important failure checks; recovery steps and remaining operating duties are recorded. |
Write one milestone in enough detail to execute
The first milestone connects interface, server rules, and authoritative records. Its finish condition is an observed booking journey rather than a number of files created.
Example milestone 1
Outcome: a signed-in member reserves Room A and can reopen the app to find the same confirmed booking. Depends on: runnable baseline; member identity; agreed booking rules. Affected boundaries: availability/review/result UI, authorized booking operation, authoritative booking records, and the saved-booking read. Code locations: identify from the actual project before editing. Work: - Implement the connected read, authorized write, and result flow. - Make overlap rejection part of the authoritative write. - Define repeat-request behavior and a useful conflict/error response. - Reflect the committed result in the interface and saved-booking view. Acceptance: - A permitted member books an available interval and sees confirmation. - After signing out and reopening, the same record is present. - Two overlapping requests cannot both create active bookings. - Retrying the same intended request does not create a duplicate. - An unauthorized request is denied at the server boundary. - A failed/conflicting save is explained without false confirmation. Evidence: tested version/environment, journey steps, conflict and permission results, and any unverified operating conditions.
For an existing app, make preservation explicit
Before adding the next feature, record the working journeys and valuable data that must survive. Name relevant integrations and interfaces. Then have the agent inspect the affected boundaries. A cleanup task is not permission to remove customer records, replace authentication, or redefine the product.
If the baseline cannot be reproduced, investigate that before estimating the whole change. If inspection exposes a contradiction in a product rule, resolve that rule and update the affected architecture and plan. An unexpected compile error or ordinary implementation repair usually belongs to the agent’s execution work.
Measure progress with verified outcomes
Mark a milestone verified when its acceptance checks pass in the stated environment. Keep incomplete or untested work visible. “Five files changed” and “the agent says it is done” do not establish that a user can finish the promised task.
- Record the exact version and environment used for each check.
- Use another session or role for persistence and access checks.
- Exercise a meaningful conflict, retry, or failure rather than only the happy path.
- Recheck affected working behavior after the change.
- Update dependencies and remaining work when inspection changes the plan.
Start the coding session with a bounded outcome
Give the agent the product brief, architecture, and current plan together. It should verify the starting point, identify the next milestone, implement the connected change, and return evidence.
Implementation-session prompt
Read the current product brief, architecture, and implementation plan. Inspect the actual project and verify the starting state. Identify the next complete milestone and its preservation duties. Recommend routine engineering/UI choices. Surface an unresolved product decision before implementing that decision. Implement the milestone, absorb ordinary engineering friction, and verify its acceptance checks in the running app. Return the version/environment, observed results, remaining limits, and an updated plan reflecting what you actually learned.
Where Driftbreak fits in implementation planning
Use the free plan directly when the product direction is clear. Driftbreak helps resolve consequential direction and connect it to architecture, a technical blueprint, and an implementation campaign. Its package gives the implementing agent or developer a coherent starting point; it does not perform their repository-specific implementation or prove a release is production-ready.