dotfiles/pi/.pi/agent/chains/feature-build.chain.md

name, description

name	description
feature-build	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.