> ## Documentation Index
> Fetch the complete documentation index at: https://smithers.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# implement

> Implement a change with validation and review.

`implement` is archived (not installed by `init`): copy it from `examples/init-pack/` with its dependency closure, or ask `create-workflow` to build an equivalent. It is the default coding workflow for a single change: a shared `ValidationLoop` implements, validates, reviews, and iterates on failures.

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
bunx smthrs workflow run implement --prompt "Add rate limiting to the API"
```

<Frame caption="The implement UI streams each stage (implementation, validation, and the reviewer panel's synthesized verdict) as the build → validate → review loop runs.">
  <img src="https://mintcdn.com/smithers/py7ertgBTLCgQQDl/images/workflow-ui/implement.png?fit=max&auto=format&n=py7ertgBTLCgQQDl&q=85&s=18ae33bd5393ddfae0a12bd92e67f9b9" alt="implement workflow UI showing implementation, validation, and review stages with an approved verdict" width="1280" height="832" data-path="images/workflow-ui/implement.png" />
</Frame>

## Inputs

| Input    | Type   | Default                             |
| -------- | ------ | ----------------------------------- |
| `prompt` | string | `"Implement the requested change."` |

## How It Runs

1. An implementation agent works from the prompt.
2. A validation agent checks the repo state.
3. A panel of reviewer agents inspects the result; a moderator synthesizes them into one verdict.
4. The orchestrator feeds failed validation output and review feedback into the next implementation pass.
5. The loop stops after validation passes and the synthesized review verdict approves, or after 3 iterations.

## Output Shape

`implement` commits changes directly to the working tree; the run log records the validation result and reviewer feedback per iteration.

## Use it when

* You already know what to build and want a build, validate, review loop enforced.
* The change is a single, focused unit, not multi-milestone.

## Use something else when

* The change needs context first: use [`research-plan-implement`](/workflows/research-plan-implement) or [`plan`](/workflows/plan).
* The work spans many independent units: split it with [`tickets-create`](/workflows/tickets-create), then run [`kanban`](/workflows/kanban).
* The scope is too broad for one loop: use [`mission`](/workflows/mission).

## Resume & retry

The run is durable: if interrupted, resume with `up --resume`; finished iterations are not repeated (see the loop's stop condition above).