/dr-do

Overview

/dr-do is the execution stage. The Developer agent resolves the target task, takes the implementation plan from tasks.md, and builds it using strict TDD: write a test, watch it fail, write the code, watch it pass. Every method stays under 50 lines, every scope under 7-9 objects. When the agent encounters unknowns (import failures, unexpected API behavior), Gap Discovery (Step 7.5) automatically spawns a researcher agent to investigate without leaving the implementation flow.

Usage

/dr-do

What It Does

1. Task Resolution — applies the Task Resolution Rule to determine which task to implement (from argument or disambiguation when multiple tasks are active).
2. Load Quality Rules — reads ai-quality.md and applies rules for TDD, stubbing, cognitive load limits, and code simplicity.
3. Read Plan — loads the implementation plan from datarim/tasks.md for the resolved task.
4. Pre-flight Check (L3-L4 only) — verifies the plan document is complete, design documents exist if required, dependencies are available, and the project builds in its current state.
5. TDD Loop — for each planned change: write a failing test, implement the minimum code to pass, refactor if needed. One stub or method at a time.
6. Follow Patterns — adheres to datarim/patterns.md and datarim/style-guide.md for consistency with existing code.
7. Gap Discovery (Step 7.5) — when an unknown is encountered (import failure, unexpected API behavior, documentation mismatch), a researcher agent is spawned to investigate the specific gap. Findings are appended to datarim/insights/INSIGHTS-{task-id}.md. Fundamental gaps (wrong technology, impossible requirement) halt implementation and recommend returning to /dr-prd.
8. Update Progress — records implementation details in datarim/progress.md.

Review-Feedback Handling

When an automated code review or human review returns findings, each finding is classified and acted on:

• Critical / blocking — fixed in the current MR before merge. Non-negotiable.
• Warning / suggestion that is cheap and strictly better (1-5 lines, no new abstractions, no scope change) — fixed inline in the current MR. Examples: tighten a string match, remove a blocking alert(), rename a typo, add a null-guard.
• Warning / suggestion that needs design or spans files — deferred to a new backlog item with a concrete trigger (e.g. "after 14 days post-deploy" or "when a second consumer appears").
• Reject — only with technical grounds, rationale recorded in the MR thread.

The disposition (fix / defer / reject) of every finding is logged in the MR thread so reviewers can see their feedback was processed.

Arguments

None. Operates on the currently active task (resolved via Task Resolution).

Output

Code changes in the project. Updates: datarim/progress.md. May update: datarim/backlog.md (deferred review findings).

Quality Rules

• Maximum 50 lines per method
• Maximum 7-9 objects in scope at once
• Tests before code (TDD)
• One stub/method at a time
• No regressions — verify existing tests still pass

Transition Checkpoint

Before moving forward:

• All planned changes implemented
• Tests written and passing
• progress.md updated with implementation details
• No known regressions introduced

Example Session

> /dr-do

Task Resolution: AUTH-0001 (Level 3)

Pre-flight check...
  Plan document: OK
  Design docs: OK (creative-AUTH-0001-architecture.md)
  Dependencies: OK (express, jsonwebtoken, bcrypt)
  Project builds: OK

Step 1/8: Auth middleware
  Writing test: auth.middleware.test.ts
  Test fails (expected)
  Implementing: auth.middleware.ts
  Test passes

Step 2/8: User model
  Writing test: user.model.test.ts
  ...

Progress: 8/8 steps complete
All 14 tests passing
Updated datarim/progress.md

Next step: /dr-qa (L3 task)

Related Commands

• /dr-plan — previous stage: planning
• /dr-design — previous stage: design (L3-4)
• /dr-qa — next stage for L3-4
• /dr-archive — next stage for L1-2 (reflection runs as Step 0.5)