The /dr-plan Command — From Requirements to Implementation Steps

A PRD describes what to build. An implementation plan describes how to build it. The gap between those two artifacts is where good intentions collide with reality — missed dependencies, wrong ordering, undeclared security risks. The /dr-plan command closes that gap by translating the approved requirements into a concrete, ordered sequence of implementation steps.

The command reads the PRD produced by /dr-prd and the task entry in tasks.md, then builds the plan in three phases that correspond to the Enhanced Design Process (Phases 4 through 6). The output is a structured plan written into the task description file, organized into phases and steps with explicit dependencies between them.

What it does

Phase 4 takes the technical approach selected during PRD review and decomposes it into components. Each component gets a scope definition, an interface contract, and a list of acceptance criteria it must satisfy. Dependencies between components are made explicit — which components must exist before others can be built.

Phase 5 produces the implementation plan document. That document is structured as a thin index entry in tasks.md pointing to a dedicated plan file, and contains the implementation steps, security summary, test plan, rollback strategy, and a validation checklist as one of its sections. The checklist ties each step to a specific command, test name, or observable behavior that confirms the step is done, and those criteria feed into /dr-qa Layer 3 after implementation.

Phase 6 validates the technology stack. It verifies that all named dependencies, build tools, and environment variables actually exist in the workspace, and that every acceptance criterion verification command is runnable against the current codebase. This prevents the plan from citing a tool or flag that does not yet exist.

One concrete example

A task to add webhook delivery to a notifications service produces a plan with three phases: first, the webhook registration endpoint (no dependencies); second, the delivery worker that reads from a queue (depends on Phase 1's data model); third, the retry logic with exponential backoff (depends on Phase 2's worker). Each phase has a security note — Phase 1 checks input validation on the URL parameter; Phase 2 checks that the worker does not log webhook payloads in plain text. The validation checklist ties each phase to a specific integration test name. The developer agent follows this without guessing the order.

Where it fits in the pipeline

The plan command runs after /dr-prd for Level 2 and above tasks. For Level 3 and 4 tasks where design exploration is needed, the plan produces a signal that /dr-design should run before implementation begins. For simpler tasks that do not require design documents, the plan routes directly to /dr-do.

The plan also verifies that all paths and scripts cited in the acceptance criteria actually exist before saving. A path that does not exist yet must be marked as to-be-created, so the gate can distinguish intentional deliverables from phantom references. This prevents the plan from quietly drifting out of sync with the codebase.

Read about the broader pipeline in what Datarim is, or continue to the /dr-design command for how complex architectural decisions get explored before coding starts.