The /dr-prd Command — Requirements Before Code

A plan written without understanding the problem is a guess formatted as a document. The /dr-prd command exists to remove that gap. It runs a structured discovery process and produces a Product Requirements Document — a PRD — that specifies what needs to be built, why, and with what constraints. Every subsequent stage in the pipeline traces back to it.

The command takes the task ID assigned during /dr-init and works through three phases. Phase 1 gathers context by reading the existing project files and relevant code. Phase 2 conducts a discovery interview to surface requirements and constraints. Phase 3 generates the PRD itself, saves it, and proposes backlog items for any sub-problems identified along the way.

What it does

Context gathering in Phase 1 reads project brief files, the tech context, and system pattern files. For Level 2 and above tasks, an optional research pass runs before the interview — it spawns a researcher agent that looks up external documentation, library behavior, or prior findings relevant to the task. The results land in an insights file that the interview then draws on.

The discovery interview in Phase 2 adapts to complexity. A quick interview for simpler tasks asks focused questions about scope and constraints. A deep interview for complex tasks explores user impact, system boundaries, and integration points. The output is a structured requirements summary that feeds directly into the PRD.

Phase 3 generates at least three distinct technical approaches for the problem, each with explicit pros and cons scored against four criteria: security, alignment with existing patterns, avoidance of duplication, and testability. After presenting these to the operator for a decision, the command writes the PRD to datarim/prd/ and validates every acceptance criterion path before saving.

One concrete example

A task to add a rate-limiting layer to a public API goes through the command as follows. Phase 1 reads the existing API handler code and finds a Redis instance already in the project. Phase 2 asks about acceptable limits, error behavior, and whether limits should be per-user or per-IP. Phase 3 produces three approaches — an in-memory counter, a Redis sliding window, and a gateway rule — and scores them. The Redis sliding window wins because it reuses existing infrastructure and survives process restarts. That decision and its reasoning appear in the PRD under the Technical Approach section, with an acceptance criterion that the rate limiter returns HTTP 429 after the configured threshold.

Where it fits in the pipeline

The command runs after /dr-init for Level 3 and 4 tasks. Level 1 tasks skip it entirely; Level 2 tasks may skip it when planning is straightforward. The PRD produced here becomes the reference document for /dr-plan, which breaks the approved approach into implementation steps, and for /dr-qa, which checks the final implementation against the stated requirements.

There is also an expectations merge step. After the PRD is saved, the command appends new wishes derived from the success criteria to the expectations file created during /dr-init. This keeps the operator's intent traceable from brief to verification without rewriting anything that was already there.

See what Datarim is for the broader context, or read about the /dr-plan command that turns the PRD into an implementation plan.