---
name: sb-implement
description: Implement or resume one roadmap item, including continuation through returned review or diagnosis. Do not use for a diagnosis-only request.
argument-hint: "<item> [tasks] [--review required|inline|off] [--recovery bounded|progress]"
---

# Implement one item

## Apply project language style

Before authoring any artifact or user-facing prose, read:

```sh
specbind rule read language-style --for consume
```

Apply returned policy only to natural-language prose. `NO_CHANGE RULE_ABSENT`
means no additional project preference; any `ERROR` line stops the workflow.

**One roadmap item per run.** `sb-drive` owns milestone-wide orchestration;
this Skill completes the selected item's implementation workflow and returns
to its caller. Dependency waves constrain eligibility, not the scope of this run.

Keep the owning turn active until every started internal role has returned and
the selected item's workflow has reached its stopping point. Prefer foreground
dispatch; if the host runs a role in the background, wait for its terminal
result in this turn and continue the cycle. A progress message such as "waiting
for the implementer" is not a final response. Do not ask the caller or user to
send "continue" merely to collect a running role's result. A real host failure,
unavailable required input, or exhausted retry bound may still stop the workflow;
report the reason, exact partial paths, and any receiver still running.

The user's request must match a pending Spec-backed or Direct item in the active
Roadmap. A bare change request is not a Direct item, even when it names the exact
source file and tells you to edit it. If no active Roadmap or matching pending
item exists, stop before reading or changing implementation and route the
request through `sb-discovery`.

## 1. Find out which kind of item this is

```sh
specbind milestone status
```

The kind decides the whole run:

- **Spec-backed** — there is an approved task plan, and it is the work.
- **Direct** — there is no plan, no requirements, no design, no Spec Contract. A declared shared Contract change uses the
  prepared, reviewed project agreement. The
  item's summary and the repository are the work.

Resolve review mode here, before loading the procedure. An explicit `--review`
value wins; otherwise the default is `required` for Spec-backed work and
`inline` for Direct work. “Selected mode” in either procedure means this resolved
value, not a setting to search for elsewhere.

Resolve `--recovery bounded|progress` for Spec-backed Tasks. `bounded` is the
default for a new execution or user-authorized resumption; `progress` removes
the Task cycle cap only while independent assessment proves progress. An
explicit request to continue without a cycle limit while progress is verified
also selects `progress`; generic "continue" does not. These are Skill arguments,
not `specbind` CLI flags or project settings. Clarify invalid/conflicting modes.
For an ongoing handoff, retain the evidenced mode, selection scope and ledger;
omitting the flag in a receiver does not start a new run or reset the mode.
Read [Task recovery](references/recovery.md) for selection and stop conditions.
The option does not change Direct-only bounds or authorize read-only work to
mutate. Report the selected mode when recovery starts.

**Never create Spec canonical artifacts for a Direct item.** If the work turns out to
need Spec requirements, design, or a Spec contract, the premise that made it Direct has
failed. Stop and report that it needs rerouting through discovery.

For either kind, `milestone status` must show this item's implementation-phase
predecessors complete. If not, stop and say so. Route to the owning phase.

## 2. Load only the item's procedure

Read the directly applicable reference completely before changing anything:

- For a Spec-backed item, read [Spec-backed implementation](references/spec-backed.md).
  It owns the approved-plan prerequisite, Task selection, sequential per-Task
  cycles, progress, notes, completed-Task checkpoints, and stopping point. Do not
  load the Direct procedure.
- For a Direct item, read [Direct implementation](references/direct.md). It owns
  implementation and review against the Roadmap summary, its checkpoint, and
  the Direct completion handshake. Do not load the Spec-backed Task cycle.

## 3. When something fails

For a **Spec-backed Task**, read [Task recovery](references/recovery.md)
completely at the first failure or recovery continuation. It replaces separate
diagnosis and review-repair counters with one shared allowance per Task:
three cycles in `bounded`, or no numerical cap in explicit `progress` mode.
Both require independent progress after each cycle. It owns recognition of a
later explicit resumption, including ordinary contextual "continue" wording,
and preservation of the prior ledger; other continuations cannot renew it.
Do not apply the Direct-only bounds below to a Spec-backed Task.

For a **Direct item**, retain the following failure route and bounds:

`BLOCKED`, unresolved `NEEDS_CONTEXT`, `CANNOT_REVIEW`, and a rejection surviving
two rounds all go to the same place: **a fresh dispatch that receives the
failure and the inputs, and not the failed attempts.**

Use the registered `specbind-debugger` role when available, with an ordinary
fresh subagent as the fallback. Never substitute the implementer or reviewer
role: fresh diagnostic judgment is the reason this dispatch exists.

```sh
specbind protocol read debug
```

Identify the subject as a Direct item in the diagnostic brief. Supply the exact
Roadmap item and summary, observable done condition, applicable checks and their
results, actual diff, current Steering, and any applicable shared Contract.
There are no Spec Requirements, Design, Tasks, or Spec Contract to fetch. Apply
the protocol's Direct input branch; missing Spec artifacts are not a defect.

Withholding the attempt history is the mechanism, not an oversight. A retry that
inherits the reasoning that just failed reproduces it.

**At most two diagnosis rounds.** Route by the category the diagnosis returns:

- **implementation defect** → fresh implementer with the fix plan
- **plan, design, or requirements defect** → **leave the run.** Report it to the
  invoking owner, or the user when standalone. Under Drive replan authority,
  return a `REROUTABLE` finding with affected artifacts, exact partial-change
  paths and diff, and recorded Task progress. This ends this implementation
  dispatch, not Drive: the planning owner repairs Design/Contract/Tasks and
  Drive resumes implementation. Requirements changes still need the user.
  No amount of implementation effort repairs an artifact that specifies
  something unworkable.
- **environment or dependency** → usually outside the change; report it
- **undetermined** → gather the named evidence when it is safely available;
  otherwise report what remains open rather than assigning it to an owner

When the Direct rounds are spent, leave the item pending and report what remains
unresolved. Do not create a Spec Task record for a Direct item.

## 4. Never rescue the worktree

A blocked task stops this Spec's run. It is not an eligible completed-Task
checkpoint, and partial source changes are never committed as a workaround.

**Never `git reset`, stash, revert, or create a WIP commit to get out of that
state.** Those destroy work the user has not seen, and what they leave behind is
indistinguishable from work that was never done. Report the partial change and
stop.

Removing only disposable outputs known to have been created by this task's own
verification is part of producing the clean handoff required by the
task-implementation protocol; it is not permission to rescue pre-existing or
unrelated work.

Committing remains the project's call — the completed-task checkpoint step reads
and follows that policy inside each cycle.

## Boundaries

- Implement and record progress. Author no requirements, design, contract, or
  `tasks.yaml`; approve and invalidate no gate.
- Write execution state only through `tasks complete|block|reopen`.
- Run no Spec completion handshake, and accept no contract review.
- One item per run.
- Report in the project's language: which tasks were completed, which were
  blocked and why, what was reviewed and its verdict, any notes written, whether
  the work was committed, and what runs next.