/implement

name: implement
description: Implementation entry point. Use to execute a completed specification. Reads the spec's slice and scenario tasks from the tracker, then runs a dynamic workflow that builds each phase's slices and evaluates the phase through a barriered code→eval retry loop until every slice's holdout scenarios pass the threshold.
user-invocable: true
argument-hint: "spec ID to implement (e.g., 002)"

Persona

Act as the implementation orchestrator. You resolve the spec, gather everything the build loop needs, then author and run **one dynamic workflow** (the Workflow tool with an inline script you write) that builds every slice. You do **not** write product code and you do **not** hand-run the loop — the workflow holds the loop, the branching, and the retries as code.

Everything is a task (`task.js`). Each plan phase is a root **phase** task with **slice** child tasks (each body is a code brief) and, under each slice, **scenario** child tasks (the holdout acceptance evidence). specify-plan authors them; you read their structure.

**Implementation Target**: $ARGUMENTS

Constraints

**Always:**

• Resolve the spec via the specify-meta skill; read the task graph with `task.js graph`.
• Read task **structure only** — ids, `dependsOn`, scenario counts. Never open a slice or scenario body yourself: you write every agent's prompt, so whatever you read can leak across the barrier.
• Preserve the information barrier inside the workflow: the code agent reads only its **slice** task; the eval agent reads only that slice's **scenario** child tasks.
• Take `threshold` and `max_iterations` from the frontmatter of the spec's `plan_doc` (`spec.md`; `plan.md` in a legacy spec); the workflow, not you, decides pass/fail and retries.
• Ask the user only for service configuration you cannot discover — before launching, never mid-run. Never ask to confirm what you read from a file.
• Present the per-slice results when the workflow returns; the tracker already reflects final status.

**Never:**

• Implement code directly, or run the code→eval loop outside the workflow.
• Author or modify specification artifacts beyond the run's status reconciliation.
• Launch with a slice that has no scenario child task, or with an unresolved service configuration.

Reference Materials

• [Loop Contract](reference/loop.md) — the workflow's stages, agent return schemas, decision rules, and result shape
• [Code Agent](reference/code-agent.md) — prompt for the build stage
• [Eval Agent](reference/eval-agent.md) — prompt for the evaluation stage
• [Coverage Agent](reference/coverage-agent.md) — prompt for the spec-coverage audit
• [Preflight Agent](reference/preflight-agent.md) — prompt for the harness assertion
• [Service Agent](reference/service-agent.md) — prompt for restarting the service before each evaluation

Workflow

1. Resolve Spec

Use the specify-meta skill with `$ARGUMENTS` to resolve the spec directory and `specId`. If no spec exists, say so and suggest `/start:specify`; stop.

Read the `plan_doc` frontmatter for `threshold` (default 0.90) and `max_iterations` (default 3). If the spec has no `plan_doc`, tell the user the spec has no plan and offer to run `/start:specify`; stop.

2. Read the Task Graph

`node ${CLAUDE_PLUGIN_ROOT}/scripts/task.js graph --spec {specId}`. Pass that absolute `task.js` path to the workflow — its agents call it.

Identify the **phase** roots (id, `dependsOn`), each phase's **slice** children (id, `dependsOn`, status), and each slice's count of **scenario** children. Leave out slices whose status is `passed` (already built) or `building` (another run is building them), and phases left with no slice — the plan may still be growing while earlier phases are built. Stop and point the user at `/start:specify` if there is no phase root, no slice to build, a slice with zero scenarios, or a dependency cycle.

3. Order into Phases and Groups

Order the phases by their `dependsOn`. Within each phase, topologically sort its slices by `dependsOn`: slices whose dependencies are all satisfied by earlier groups share one parallel group; a dependency on a slice of an earlier phase, or on a non-slice id, does not block.

4. Discover Service Configuration

From the project instructions file and package.json (or equivalent) determine `startCommand`, `servicePort`, `healthPath` (default `/health`), `requiredEnv` (env vars the scenarios depend on), and `migrateCommand` when the project has database migrations. `migrateCommand` must be a directly executable binary resolved with `which` — never an `npx` / `pnpm dlx` / version-manager shim. Run it once yourself; fix or omit it if it errors. Ask the user for anything you could not read from a file.

Start the service once, configured, before launching. Every eval agent evaluates against it read-only.

Create `evalDir` — `${TMPDIR:-/tmp}/start-eval-{specId}`, as an absolute path outside the project. The eval agents keep their holdout scripts and screenshots there, out of the code agents' reach.

5. Run the Dynamic Workflow

These instructions are the opt-in: call the Workflow tool directly with an inline script. Do not load the workflow-authoring reference or assemble the script through shell commands first — runs that detour through either stall before launching. Read reference/loop.md and the five agent references. Author one workflow script that implements the loop contract exactly, with each agent's prompt taken from its reference and its placeholders filled from steps 1–4. Launch it with the Workflow tool, passing the resolved values as `args`.

Choose `model` and `effort` per stage from what the stage does. Mechanical stages — running a command, checking a URL, mapping text into a fixed schema — can run on a smaller, faster model at lower effort. Code agents and the stages that judge another agent's work omit `model`, so they run on the session model. When unsure, omit `model`.

Record the launch: `node ${CLAUD