/implement

name: implement
description: "Smart code implementation with full pipeline and batch modes"
argument-hint: "<feature> | --batch <file> | --issues <nums> | --resume <id>"
allowed-tools: [Agent, Read, Write, Edit, Bash, Grep, Glob, WebSearch, WebFetch]
user-invocable: true
user_facing: true

/implement — Thin Coordinator (Issue #444)

> The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119).

**You (Claude) are the coordinator.** Delegate specialist work to agents via the Agent tool. Each agent runs in isolated context — pass outputs from prior stages explicitly.

| Mode | Flag | Description | |------|------|-------------| | **Full Pipeline** | (default) | Acceptance-first: Research → Plan → Acceptance Tests → Implement + Unit Tests → Review → Security → Docs | | **Light** | `--light` | Fast pipeline: Align → Plan → Implement → Test → Docs → CI Analysis (4 agents, no research/security) | | **TDD-First** | `--tdd-first` | Research → Plan → Unit Tests → Implement → Review → Security → Docs | | **Fix** | `--fix` | Minimal pipeline: Align → Test Context → Implement Fix → Review + Docs → CI Analysis (4 agents minimum) | | **Batch File** | `--batch <file>` | Process features from file with auto-worktree | | **Batch Issues** | `--issues <nums>` | Process GitHub issues with auto-worktree | | **Resume** | `--resume <id>` | Resume interrupted batch from checkpoint |

**Same-Session Planning Note**: When running `/plan` followed by `/implement` in the same session, pass `--no-issues` to `/plan` to avoid the `/drain-queue` autonomous drainer picking up your issues mid-session. This is expected behavior — the drainer continuously processes new `auto-improvement`-labelled issues and has no visibility into your active session's intent. See #1373.

Implementation

**COORDINATOR FORBIDDEN LIST** — You MUST NOT do any of the following (violations = pipeline failure):

Agent Management (you are a dispatcher, not a substitute)

• ❌ You MUST NOT skip any STEP (even under context pressure or time constraints)
• ❌ You MUST NOT write implementation code yourself instead of delegating to agents
• ❌ You MUST NOT contain detailed agent instructions inline — those belong in agents/*.md
• ❌ You MUST NOT do an agent's work yourself when the agent crashes — RETRY the agent once with the same prompt. If retry also crashes, BLOCK and report to user. This applies to ALL specialist agents (implementer, test-master, researcher, planner, reviewer, security-auditor, doc-master). The coordinator is a dispatcher, never a substitute.
• ❌ You MUST NOT summarize agent output instead of passing full results to next agent

Pipeline Integrity — Step Ordering and Gates

• ❌ You MUST NOT declare "good enough" on failing tests (STEP 8 HARD GATE is absolute)
• ❌ You MUST NOT run STEP 10 before STEP 8 test gate passes
• ❌ You MUST NOT parallelize agents from different pipeline phases (e.g., implementer + reviewer) — within-phase parallel validation in STEP 10 is permitted for low-risk changesets per STEP 10 routing rules
• ❌ You MUST NOT treat STEP 13 as the final step (STEP 14 and STEP 15 are mandatory; STEP 12.5 CIA must dispatch before STEP 13 commit; you MUST NOT clean up pipeline state before STEP 15 launches) — Issue #1211
• ❌ You MUST NOT start STEP 1 before STEP 0a Pre-Flight Reconnaissance completes — issue state, merge-status, and pre-validated plan detection are mandatory checks (#936); and you MUST NOT perform pre-STEP-1 file exploration, code grepping, or source inspection — pre-flight is limited to issue/git state, alignment read, and pipeline state, with investigation delegated to STEP 4 researchers (#1129)

Pipeline Integrity — Output Fidelity and Isolation

• ❌ You MUST NOT paraphrase, summarize, or condense agent output when passing it to the next stage. Pass the FULL agent output text verbatim. If output exceeds context limits, pass the first 2000 words plus the final summary/conclusion section — never your own restatement. The anti-pattern: "The implementer changed X, Y, Z" instead of the implementer's actual output. STEP 10 agents (reviewer, security-auditor) need the real output to do real reviews.
• ❌ You MUST NOT skip validation agents (reviewer, security-auditor, doc-master) under context pressure — BLOCK the pipeline instead and suggest `/clear` then `/implement --resume $RUN_ID`. You MUST NOT pass fewer than 50% of the implementer's output words to the reviewer — if you must truncate, include the first 3000 words plus the full summary/conclusion. Log the word counts: "Implementer output: N words → Reviewer input: M words (ratio: M/N)"
• ❌ You MUST NOT leak implementer output, code diffs, reviewer feedback, research findings, or planner rationale to the spec-validator agent (STEP 8.5 context boundary violation)
• ❌ You MUST NOT pass only feedback to revision/remediation re-invocations — always combine baseline context with feedback via `construct_revision_prompt()` (`from prompt_integrity import construct_revision_prompt`). Reason: prompt-integrity hook detects shrinkage and BLOCKS the re-invocation (Issue #1116). Applies to STEP 5.5b plan-critic REVISE and STEP 11 reviewer/security-auditor BLOCKING remediation.

Pipeline Progress Protocol

**You MUST output structured progress to the user at each pipeline milestone.** This keeps the user informed of what's happening, which agents are running, and how long each step takes.

**Timing**: Capture `STEP_START=$(date +%s)` before each step. After each step, calculate elapsed: `STEP_ELAPSED=$(( $(date +%s) - STEP_START ))`. Format: `Xs` if under 60s, `M:SS` if 60s+.

**Step Banner** — output before each step begins:

========================================
STEP N/TOTAL — Step Name
Agent: agent-name (Model) [or "Agents: a, b (Model)" for parallel]
========================================

For non-agent steps (gates, checks), omit t