---
name: feature-build
description: Recon → plan → implement → parallel review → synthesize. Use /run-chain feature-build "<feature request>" to kick off a full feature build with the ollama-* subagents.
---

# Feature build (Ollama Cloud)

A four-stage chain for shipping a small-to-medium feature end-to-end with Ollama Cloud subagents. Each stage is async; the parent continues working between stages.

## Stages

1. **scout** — `subagent scout` with `output: context.md`, `context: fresh`, `async: true`. Map the relevant code, list the files to touch, capture conventions.
2. **ollama-planner** — reads `context.md`, writes `plan.md`. `context: fork`, `async: true`.
3. **ollama-coder** — reads `plan.md`, implements, runs validation. `context: fork`, `async: true`, `defaultContext: fork`.
4. **parallel review** — three `ollama-reviewer` instances with distinct angles (correctness, tests/validation, simplicity/security). `context: fresh`, `concurrency: 3`, `async: true`.
5. **synthesize** — parent reads the three reviews, applies `worth fixing now` items via one more `ollama-coder` run (or manually), then summarizes for the user.

## When to use

- A new feature spanning 2+ files.
- A non-trivial bug fix touching multiple components.
- A refactor with a clear target shape.

## When NOT to use

- Single-line fixes → just edit directly.
- Pure research questions → use `research-brief` instead.
- Changes that need user clarification first → ask the user, then start the chain.

## Inputs

The chain task should include: the feature request, the target repo path, any constraints (must keep API stable, must not touch X, must add tests), and any attached screenshots.

## Validation contract (set before launching)

Before stage 3, write down in the task prompt:
- expected behavior after the change
- tests or commands the coder must run
- evidence the coder must return (changed files, command output, screenshots)

## Stop rules

- If `scout` finds the task is out of scope or the codebase is in an unexpected state, stop and ask the user.
- If `ollama-planner` surfaces ambiguity in "Open Questions", stop and ask the user before launching the coder.
- If a reviewer reports a `blocker` or an unapproved decision, stop and ask the user.
- If a `worth fixing now` item is small and safe, parent applies it directly; if it touches product/architecture, ask the user first.