Developer

Overview

The Developer is the primary code-writing agent in the Datarim pipeline. It implements features following Test-Driven Development, adheres to project patterns and style guides, and maintains high code quality throughout. Strict test-first sequencing is the default; a workspace can relax the timing through the tdd-enforcement toggle, but meaningful automated tests and all quality gates stay mandatory.

When It's Used

Invoked during /dr-do — the implementation stage of the pipeline. This is where plans become working code. The Developer takes the task definition from datarim/tasks.md and executes it step by step.

Capabilities

• Feature implementation — writes production code following the implementation plan
• Test-Driven Development — writes tests first, then code to make them pass
• Code refactoring — improves existing code structure while maintaining behavior
• Pattern adherence — follows systemPatterns.md and style-guide.md
• Evidence records — writes canonical Evidence: V-AC-N — <command/test/artifact> lines into the task record and runs the advisory do-stage spec-graph check before handoff
• Tech context updates — keeps datarim/techContext.md current with new dependencies and decisions
• Editing discipline — after any replace_all edit on multi-line blocks, runs a follow-up grep to confirm zero remaining occurrences of the old pattern

How It Works

The Developer reads the active context, task definition, and system patterns before writing any code. It follows the TDD cycle: write a failing test, write the minimum code to pass it, then refactor. Stubbing rules from the ai-quality skill prevent tests from depending on external services. Every implementation step includes its rationale. When researching external libraries or APIs, it uses context7 MCP server for token-efficient documentation access.

Example

/dr-do
→ Developer reads tasks.md for implementation steps
→ Step 1: Write test for user authentication
→ Step 2: Implement auth middleware (test passes)
→ Step 3: Write test for session management
→ Step 4: Implement session handler (test passes)
→ Updates techContext.md with new dependencies

Context Loading

Before any source read or delegation it loads the security skill and applies its sensitive-source context boundary. Reads datarim/activeContext.md, datarim/tasks.md, and datarim/systemPatterns.md. Before editing it reads the frozen acceptance criteria and cases (immutability skill) and closes every response with the cta-format Next Step block. Applies ai-quality (TDD, stubbing, cognitive load) and datarim-system (file locations, documentation rules) skills on every invocation.

Skills Used

security (always, before source reads), immutability (always), ai-quality (always), datarim-system (always), cta-format (always), testing (TDD discipline).

Reporting the result

Apply Human Outcome Reporting before a human-facing update or result. Explain the user-visible outcome, the original conditions, checks and evidence, and open limitations. A stage result does not mean the entire task is complete. Keep exact protocols and technical records intact. To explain again without continuing work, use /dr-explain.