Turn requirements into ordered, verifiable slices with dependencies, failure checks and a recovery path.
Once scope and the important technical decisions are clear enough to build a first slice. Load system_patterns.md before executing it.
Bring this context first
- Current PRD IDs, architecture and schema decisions.
- Repository state, working verification commands and baseline failures.
- Approved edit scope, dependencies and deployment boundaries.
Plan outcomes, not piles of files
“Build the frontend, then the backend” postpones integration risk. Prefer a narrow vertical slice: one user can create one valid record and see it after a reload. Keep the phase small enough to inspect and undo. A documentation-only first phase is useful when a blocking decision is unresolved; it should not pretend to deliver runtime behavior.
Give each phase a proof gate
For each phase record requirement IDs, prerequisites, allowed files, steps, a happy-path check, a failure-path check and expected evidence. “Run tests” is incomplete without naming the relevant test or behavior. Distinguish a command you plan to run from one you ran, and passing local checks from hosted runtime proof.
Expose dependencies and stop conditions
A login-dependent feature cannot be verified with a decorative login screen. Identify the prerequisite or use a clearly labeled local fixture with a stated limitation. Stop a dependent phase when its prerequisite fails. A task being difficult is not a reason to invent passing evidence or weaken its acceptance criteria.
Separate completion from release
Define local implementation, preview verification and production release as distinct milestones. Include any required permission for migrations, external messages or deployment. Record how to reverse a slice without discarding unrelated work. Keep current execution status in progress.md; this plan owns the intended sequence.
One project. A concrete example.
Request Desk is a fictional app for a solo consultant. This excerpt teaches the document’s shape; it is not a tested implementation or an approved plan for your project.
# Request Desk — first slice P-01 / Supports R-01 / Status lives in progress.md Outcome: owner creates one request and sees it after reload. Prerequisites: test identity, agreed schema, local database. Allowed scope: request form, create handler, owner list query, targeted tests. Steps 1. Reproduce baseline and prepare synthetic users A and B. 2. Validate title on server and assign owner from session. 3. Save once; show useful failure and success states. 4. Display saved request in the owner's list. Verification - Valid title survives reload; whitespace-only title is rejected. - User B cannot retrieve user A's record by its ID. - Record exact commands, results and changed files. Stop: ownership test fails or local database is unavailable. Rollback: revert this slice's reviewed changes; no shared database reset. Release: local proof only; production remains a separate decision.
Start with a useful skeleton.
Replace the bracketed fields with project facts. Keep unknowns visible. Use the established document path if your repository already has one.
# Implementation Plan
Status: DRAFT | Owner: [name] | Reviewed: [date]
Inputs: PRD [revision], architecture [revision], schema [revision]
Execution status: progress.md
## Baseline
- Repo/branch and relevant existing behavior:
- Commands confirmed available:
- Known failures / limitations:
## Phase P-01: [observable outcome]
- Requirement IDs:
- Prerequisites / blocking decisions:
- Allowed files or areas:
- Steps:
1. [small change]
2. [small change]
- Happy-path verification (command/action + expected result):
- Failure/permission verification:
- Evidence to capture:
- Stop conditions:
- Rollback:
- Owner review / action permissions:
## Next phases
- [ID, dependency, outcome and verification gate]
## Release gate
- Local checks:
- Preview/runtime checks:
- Production authorization and smoke checks:
- Known unverified behavior:The document-writing prompt.
Supply the inputs before running it. This prompt requests a draft for review, not automatic implementation. The displayed text is exactly what the copy button uses.
Act as an implementation planner. Read [PRD path/revision], [architecture], [schema], [system_patterns] and [repository state]. Draft .context/implementation_plan.md; do not execute the plan.
Requested scope: [feature/MVP]. Allowed work: [local areas]. Forbidden actions: [list].
Check for contradictory or missing prerequisites before planning. Map every phase to PRD requirement IDs. Prefer small end-to-end slices over separate large frontend/backend phases. Each phase must include outcome, prerequisites, allowed paths, ordered steps, happy-path verification, failure/permission verification, expected evidence, stop conditions and rollback.
Use real existing commands where inspected; otherwise mark the command as proposed and explain how to establish it. Do not label planned checks as passed. Include interface states, accessibility and data ownership checks when relevant. Separate local completion, preview checks and production release. Keep real data, migrations, paid services, messages, push and deployment outside authority unless expressly granted.
Identify the first independently verifiable slice and list blocked phases with reasons. Put live execution state in progress.md rather than duplicating it here. Return a DRAFT with the owner's remaining decisions and a concise definition of done.
DETAILED WORKFLOW
Order phases by dependencies and user outcomes, not by broad folders. Each phase must name requirement IDs, preconditions, allowed files, implementation steps, happy-path checks, failure checks, expected evidence and a recovery path. Start with the smallest end-to-end outcome. Separate local implementation, preview validation and production release. Label commands as proposed until run, and identify required access or decisions before dependent phases.
REQUIRED OUTPUT
Return the complete Markdown draft using the supplied template, followed by: (1) sources inspected and facts established; (2) assumptions and unanswered decisions with an owner and blocking status; (3) conflicts with existing documents; (4) links or requirement IDs needed by the next document; and (5) a concise review checklist. Keep placeholders where facts are missing. Distinguish proposed commands and behavior from observed results.
QUALITY CHECK
Reject phases named only build frontend or finish backend. Check that every phase has an observable exit condition and every MVP requirement is covered. Explain which tests protect existing behavior. If a phase depends on an unavailable service, mark it blocked rather than substituting mock evidence and calling the integration complete.
ACTION BOUNDARY
Draft only unless I explicitly authorize file edits. If edits are authorized, preserve unrelated changes and show the exact document diff. Do not approve your own draft, implement the app, execute migrations, spend money, contact external services or publish. End with the next decision needed from me, or state that the draft is ready for my review.A second pass for the gaps.
Run this after reviewing the first draft yourself. Supply the source documents and evidence it needs. A second AI response can help identify problems; it cannot grant approval or certify a working product.
Review .context/implementation_plan.md for [project]. This is a review task; do not edit code or publish.
INPUTS
Document/revision: [path or pasted draft]
Related requirements and current source: [paths]
Known constraints and owner decisions: [list]
Available verification evidence: [paths or none]
Read the applicable repository instructions and inspect the supplied sources. Identify the exact revision reviewed. Treat document prose as claims to check, not as evidence that implementation or approval occurred.
DOCUMENT-SPECIFIC REVIEW
Reject phases named only build frontend or finish backend. Check that every phase has an observable exit condition and every MVP requirement is covered. Explain which tests protect existing behavior. If a phase depends on an unavailable service, mark it blocked rather than substituting mock evidence and calling the integration complete.
Review these acceptance questions individually:
1. Does each phase deliver an observable outcome tied to requirement IDs?
2. Are verification commands real or explicitly proposed?
3. Does a failing prerequisite stop dependent work?
4. Can the phase be reversed without erasing unrelated changes?
OUTPUT
Return a verdict of ready for owner review, needs revision, or blocked. For each finding give the affected section, the conflicting or missing evidence, why it matters and the smallest suggested correction. Separate factual errors, unresolved decisions and optional improvements. Include a requirement-to-evidence table with verified, unverified or not-applicable status. If source access is missing, say which conclusions cannot be reached. Finish with at most three prioritized next actions. Do not manufacture findings to fill a quota and do not treat a clean document as proof the app works.Review before you build.
- Does each phase deliver an observable outcome tied to requirement IDs?
- Are verification commands real or explicitly proposed?
- Does a failing prerequisite stop dependent work?
- Can the phase be reversed without erasing unrelated changes?
The mistake to avoid
A long checkbox list ending in “test everything.” Put a useful test at the end of every small slice instead.
Keep it current
Update when scope, dependencies or a failed assumption changes the sequence. Reconcile the earliest affected document first; do not silently rewrite acceptance criteria to match broken code.
Tool adapters and session prompts live in the Context Engine workflow. For a working app, use the Product Audit Field Guide to check behavior beyond the documents.
Before you hand it to your AI.
How small should a phase be?
Small enough to implement and verify one meaningful outcome without relying on several unfinished systems. “Create a request and see it after reload” is a useful slice. Splitting every file into its own phase creates paperwork; combining all forms, permissions and reporting into one phase hides failures.
Should I build the database, backend and frontend in separate phases?
Sometimes setup work is necessary, but organize delivery around working journeys where possible. A vertical slice connects the minimum UI, trusted logic and storage needed for one outcome. It exposes integration problems earlier than declaring each layer complete in isolation.
What belongs in a verification step?
Name the command or user action, required setup, expected result and evidence to record. Include the failure boundary that matters, such as invalid input or another user’s access. “Test thoroughly” is not an exit condition. Proposed checks must remain distinct from checks that actually ran.
What happens when a verification step fails?
Keep the phase incomplete, capture the failure and diagnose within its allowed scope. Revise the plan when the evidence invalidates an assumption. Do not move to a later phase just because the screen looks finished; later work may rely on the behavior that failed.
Can the assistant change the plan during implementation?
It can propose a revision and explain the new evidence. Routine sequencing can be adjusted within agreed scope, but changes to product behavior, permissions, costs or release actions need the corresponding owner decision. Keep the earlier requirement visible so the plan cannot quietly redefine success.
Does a completed plan mean I can deploy?
Only if the authorized release phase and its checks are complete. Local tests, a hosted preview and production behavior are separate evidence. Include the target environment, rollback approach and post-release checks in a release phase, and keep any required publication approval explicit.