The /dr-do Command — Implementation With Tests First

Planning ends when implementation begins. The /dr-do command is where Datarim's developer agent takes the plan, the design documents, and the operator brief, and turns them into working code. The core discipline is test-driven development: the test is written first, it fails, the code is written to make it pass, then the cycle repeats.

Before writing a single line, the command runs a pre-flight check for Level 3 and 4 tasks. This verifies that the implementation plan exists, that any required design documents are in place, that dependencies are available, and that the project builds cleanly in its current state. Starting implementation on a broken foundation multiplies the cost of every subsequent step.

What it does

The TDD loop at the core of the command works at the method or stub level. Each unit gets a test written before any implementation code. The test fails — confirming it actually tests something — then the implementation is written to reach green. This pattern applies regardless of the change size, because it is the pattern that catches the most bugs at the lowest cost.

Mid-implementation, the command can encounter gaps: an import that does not resolve, an API that behaves differently than documented, a missing feature in a dependency. When a gap appears, the gap discovery protocol spawns a researcher agent that looks up the specific issue and appends findings to the insights file for the task. If the gap is fundamental — a wrong stack choice or an impossible requirement — implementation stops and /dr-prd is recommended to revise the requirements. Otherwise, implementation continues with updated context.

Before every commit that touches networking configuration — such as Docker Compose port mappings, Redis or PostgreSQL configuration, or systemd socket files — the network exposure gate runs. It checks that new listeners are bound to loopback or Tailscale addresses, not public interfaces. The gate is fail-closed: a missing or malformed configuration is treated as a violation, not a pass.

One concrete example

A task to implement a background job that processes invoice generation follows this flow. Pre-flight checks confirm the queue library is installed and the database is reachable. The first test verifies that a job created in the queue appears in the database with status: pending — test fails, table does not exist yet. The migration is written, the test passes. The second test verifies that the worker picks up the job and updates its status — test fails, worker not implemented. The worker is written, the test passes. A gap appears: the email client used for delivery has a different API than the documentation showed. The researcher agent confirms the current SDK version and updates the insights file. Implementation continues with the corrected API call. The commit touches no networking configuration, so the exposure gate is skipped.

Where it fits in the pipeline

The command runs after /dr-plan and /dr-design (when applicable). When all checks in the transition checkpoint pass — implementation complete, tests passing, no known regressions, task description updated — the pipeline routes to /dr-qa for Level 3 and 4 tasks, or directly to archive for simpler ones.

The task description file is updated throughout implementation. Progress notes, design decisions made during coding, and any discovered gaps all land there. The description file is how /dr-qa understands what was built without re-reading the entire git history.

See what Datarim is for the full pipeline picture, or continue to the /dr-qa command that verifies the implementation against every artifact produced upstream.