Dev

---
name: dev
description: Implementer - fetches a GitHub issue, builds an implementation plan, then implements using TDD. Use when: implement, build this, code this, add this feature, TDD, test first, red green refactor, pick a task, next task, dev.
---

# Implementer - TDD Engineer

**Fetches a GitHub issue, plans the implementation, then builds it with strict TDD.**

## Usage

- `/dev <issue_url>` - Fetch issue, plan, and implement
- `/dev <issue_number>` - Same, using issue number
- `/dev` - Ask user which issue to implement

## Workflow

### Phase 1: Understand

1. **Fetch the issue** using `gh issue view <number> --json title,body`
2. **Launch scout agent** for codebase exploration:
   - Use the `scout` agent to explore all source files relevant to the issue
   - Scout will trace call paths, map test coverage, find existing patterns
   - Review the Scout Report for affected files, data flow, and gaps
3. **Identify the gap** between current state and what the issue requires
4. **Challenge the PRD** if research reveals:
   - Missing requirements or overlooked edge cases
   - A better technical approach than what was suggested
   - Existing code that already partially solves the problem
   - Requirements that are infeasible or conflict with existing code

### Phase 1.5: PRD Feedback (when needed)

If Phase 1 research uncovered issues with the PRD, **argue your case before planning**:

5. **Present findings to the user** — explain what you found and what you'd change
6. **If user agrees**, invoke `/po amend <issue_number>` with a summary of the changes
7. **If user disagrees**, proceed with the PRD as-is

### Phase 2: Plan

8. **Enter plan mode** to design the implementation:
   - Summarize research findings
   - Break the issue into ordered implementation tasks (baby steps)
   - Each task = one testable behavior increment
   - Identify files to create/modify
9. **Launch plan-reviewer agent** to stress-test the plan
10. **Revise plan** based on reviewer feedback, then present to user for approval

### Phase 3: Implement (TDD)

11. **Create a feature branch**: `feat/<short-name>`
12. **For each task**, follow the RED-GREEN-REFACTOR cycle below
13. **After all tasks complete**, launch `code-reviewer` agent for self-review

## The Cycle

For each behavior increment. One test at a time. Baby steps.

### RED - Write One Failing Test

Write the smallest possible test for the next behavior:

```elixir
test "creates article with auto-generated slug" do
  {:ok, article} = Blog.create_article(%{title: "Hello World", content: "body"})
  assert article.slug == "hello-world"
end
```

Run: `mix test`

**The test MUST FAIL.** If it passes:
1. Re-examine the test — is it actually testing new behavior?
2. Adjust the assertion to target untested behavior
3. If it still passes after 3 attempts, **stop and ask the user**

### GREEN - Minimum Code to Pass

Write only enough production code to make the failing test pass. No more.

Run: `mix test`

**The test MUST PASS.** If it fails:
1. Read the error carefully
2. Fix the implementation (not the test)
3. If it still fails after 5 attempts, **stop and ask the user**

### REFACTOR - Clean the Changed Code

Once green, refactor the changed code and its immediate boundaries.

Run: `mix test` after each refactor step — **must stay green**

### REPEAT

Go back to RED for the next behavior increment.

## Iron Rules

1. **No production code without a failing test** — ever
2. **Baby steps** — one test, one behavior, one increment
3. **Run tests after every change** — `mix test`
4. **Refactor only when green** — never refactor red code
5. **One task at a time** — finish before starting the next
6. **Escalate, don't spin** — ask the user when stuck
7. **TDD is the default** — only skip if the user explicitly says so

## Pipeline

```
/po <prompt> -> GitHub issue -> /dev <issue> -> /review -> /commit -> /pr
```