dev-implement

What this skill does

**Announce:** "I'm using dev-implement (Phase 5) to orchestrate implementation."

**Iteration topology:** serial /goal loop (agent-team parallel for 4+ independent tasks)

**Load shared enforcement:**

Auto-load all constraints matching `applies-to: dev-implement`:

!`uv run python3 ${CLAUDE_SKILL_DIR}/../../scripts/load-constraints.py dev-implement`

**You MUST have these constraints loaded before proceeding. No claiming you "remember" them.**

**Dynamic plan re-read:** Before starting work, re-read `.planning/PLAN.md` to catch any phases or tasks that were dynamically inserted by earlier phases. Do not rely on cached plan state from a prior phase.

## Where This Fits

```
Main Chat (you)                         dev-implement workflow (per level)
──────────────────────────────────────────────────────────────────────────
/goal <condition>  ← user sets once at phase entry
dev-implement (this skill)
  └─ per level: Workflow(name="dev-implement") ─→ parse PLAN table → DAG
                                                   sequential TDD implementer
                                                   per task → Verify Cmd → JS gate
  ← run FULL suite, mark [x], re-invoke next level
```

**Main chat orchestrates the level loop + the full-suite ground-truth + the `/goal`.** The workflow's implementers write the code (TDD) and the JS gate keys on real Verify Command exit codes — completion is not honor-system, and the dev-delegation-guard still forbids you from writing project code yourself.

## Contents

- [Prerequisites](#prerequisites)
- [Implementation Strategy: the dev-implement workflow](#implementation-strategy-the-dev-implement-workflow)
- [The Iron Law of Delegation](#the-iron-law-of-delegation)
- [The Process](#the-process) (Sequential)
- [Sub-Skills Reference](#sub-skills-reference)
- [Test Gap Validation Gate (MANDATORY)](#test-gap-validation-gate-mandatory)
- [Phase Complete](#phase-complete)

# Implementation (Orchestration)

<EXTREMELY-IMPORTANT>
## Prerequisites

**Do NOT start implementation without these:**

1. `.planning/SPEC.md` exists with final requirements
2. `.planning/PLAN.md` exists with chosen approach
3. **User explicitly approved** in /dev-design phase
4. **`.planning/PLAN.md` Testing Strategy section is COMPLETE** (all boxes checked)
5. **`.planning/PLAN_REVIEWED.md` exists with `status: APPROVED`**

If any prerequisite is missing, STOP and complete the earlier phases.

### Plan Review Gate Check (MANDATORY — CHECK FIRST)

Before anything else, verify the plan was reviewed:

```bash
# Check for plan review approval marker
head -5 .planning/PLAN_REVIEWED.md 2>/dev/null
```

**If `.planning/PLAN_REVIEWED.md` does not exist → STOP. Return to dev-design Phase Complete.**
**If `status:` is not `APPROVED` → STOP. Plan review is incomplete.**

This file is written by dev-plan-reviewer when it approves the plan. Its absence means the plan reviewer was SKIPPED — which means spec requirements may have been silently dropped from the plan.

| Thought | Reality |
|---------|---------|
| "I can see the plan looks complete" | Self-assessment is not review. The reviewer catches what you miss. |
| "Plan reviewer would have approved anyway" | Then it takes 30 seconds. Run it. |
| "User approved the plan directly" | User approves the approach. Reviewer checks spec coverage. Different gates. |
| "I'll review it myself as I implement" | You won't. You'll be focused on code. That's why the gate exists. |

**Check `.planning/PLAN.md` for:** files to modify, implementation order, testing strategy.

### Pre-Flight Testing Check (MANDATORY)

Before starting ANY task, verify `.planning/PLAN.md` Testing Strategy:

```
[ ] Framework specified (not empty, not "TBD")
[ ] Test Command specified (runnable command)
[ ] First Failing Test described (specific test name)
[ ] Test File Location specified (actual path)
```

**If ANY box is unchecked → STOP. Go back to design phase.**

This is your LAST CHANCE to catch missing test strategy before writing code.
</EXTREMELY-IMPORTANT>

## Implementation Strategy: the dev-implement workflow

You do NOT choose sequential-vs-parallel and you do NOT hand-dispatch tasks. Implementation is the **`dev-implement` ultracode workflow**, which reads the hardened PLAN.md table, builds the `Deps` DAG, and **auto-parallelizes within each dependency level** (one worktree-isolated implementer per task, all TDD). You drive the level loop: invoke the workflow per level, integrate the level's returned file contents, run the full suite, mark the rows `[x]`, advance — all under one `/goal`. See [The Process](#the-process).

<EXTREMELY-IMPORTANT>
## The Iron Law of TDD (Final Enforcement)

**YOU CANNOT WRITE IMPLEMENTATION CODE WITHOUT A FAILING TEST FIRST.**

This is not a suggestion. This is the workflow. Every task follows:

```
1. READ the test description from PLAN.md
2. WRITE the test file
3. RUN the test → SEE RED (failure)
4. ONLY THEN write implementation
5. RUN the test → SEE GREEN (pass)
```

### TDD Facts (implement-time)

- Missing test infrastructure discovered at implement time is an explore/clarify failure — the recovery is routing back and adding a Task 0 that sets up the harness, not implementing without tests.
- A SPEC.md that prescribes manual testing is a spec bug: fix SPEC.md with the user. It does not waive TDD.

**If you wrote code without a failing test first, DELETE IT and start over.** (Full TDD doctrine: dev-tdd.)
</EXTREMELY-IMPORTANT>

<EXTREMELY-IMPORTANT>
## The Iron Law of Delegation

**MAIN CHAT MUST NOT WRITE CODE. This is not negotiable.**

Main chat orchestrates. Subagents implement. If you catch yourself about to use Write or Edit on a code file, STOP.

| Allowed in Main Chat | NOT Allowed in Main Chat |
|---------------------|--------------------------|
| Spawn Task agents | Write/Edit code files |
| Review Task agent output | Direct implementation |
| Write to .planning/*.md files | "Quick fixes" |
| Run git commands | Any code editing |
| Set/clear `/goal` for the phase | Bypassing delegation |

**If you're about to edit code directly, STOP and spawn a Task agent instead.**

The full delegation doctrine — including what counts as code (ported code, config, boilerplate, setup, mechanical PLAN execution) — lives in dev-delegate's Delegation Facts.
</EXTREMELY-IMPORTANT>

### Context Monitoring

Before starting each task, check context availability:

**Thresholds:**
| Level | Remaining Context | Action |
|-------|------------------|--------|
| Normal | >35% | Proceed with task |
| Warning | 25-35% | Complete current task, then invoke dev-handoff |
| Critical | ≤25% | Invoke dev-handoff immediately — no new tasks |

**At Warning level:** After the current task completes (don't abandon mid-task), invoke:
Read `${CLAUDE_SKILL_DIR}/../../skills/dev-handoff/SKILL.md` and follow its instructions.

**At Critical level:** Stop immediately. Invoke dev-handoff before context is exhausted. A degraded handoff is better than no handoff.

**Why:** A 10-task implementation phase with 20% context remaining produces garbage for the last 5 tasks. Better to handoff cleanly and resume fresh than to push through with degraded output.

### Long-Running Task Monitoring

Use the **Monitor tool** for builds, test suites, or scripts that take >30 seconds. Monitor streams stdout events without blocking — you keep working and get notified on completion.

```
# Watch a test suite run
Monitor(
  description="test suite progress",
  timeout_ms=300000, persistent=false,
  command="npm test 2>&1 | grep --line-buffered -E '(PASS|FAIL|✓|✗|error|complete)'"
)

# Watch a build
Monitor(
  description="build progress",
  timeout_ms=300000, persistent=false,
  command="npm run build 2>&1 | grep --line-buffered -E '(error|warning|built|done|fail)'"
)
```

**When NOT to use Monitor:** For quick commands (<30s), use Bash directly. For one-shot "run and wait," use `Bash(run_in_background=true)`. Monitor is for streaming progress from longer op