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:

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