47 lines
2.4 KiB
Markdown
47 lines
2.4 KiB
Markdown
---
|
|
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.
|