customType: subagent-slash-result

content:
Step 1: 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.

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

Step 3: 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.

Step 4: 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.

Step 5: 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)

Step 6: 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.

type: text

mode: chain

agent: Stages

status: running

agent: When to use

status: pending

agent: When NOT to use

agent: Inputs

agent: Stop rules


content:
## Subagent result

Unknown agent: Stages (step 1)

text: Unknown agent: Stages (step 1)


content:
Step 1: scout
Map the relevant code for {task}. List files to touch, capture conventions, identify risks, and write findings to {output}.

Step 2: ollama-planner
Read {reads} and create a concrete implementation plan for {task}. Write ordered tasks with file paths, acceptance criteria, and risks to {output}.

Step 3: ollama-coder
Execute the plan from {reads}. Implement the smallest correct changes, run validation, and report changed files with evidence to {output}.

Step 4: reviewer
Review the implementation against the plan. Focus on: correctness, regressions, edge cases, and whether the change does what it claims. Write findings to {output}.

Step 5: reviewer
Review test coverage and validation. Focus on: tests added/updated, do they exercise the new code, are they sufficient to catch regressions. Write findings to {output}.

Step 6: reviewer
Review for simplicity, maintainability, and security. Focus on: smallest correct change, readability, naming consistency, input validation, secrets, injection risks. Write findings to {output}.

Step 7: worker
Synthesize the three reviews from {reads}. Apply fixes worth doing now (small, safe changes). Report: what was fixed, what was deferred, and any blockers that need user decision.

agent: scout

agent: ollama-planner

agent: ollama-coder

agent: reviewer

agent: worker

chainAgents: scout ollama-planner ollama-coder reviewer reviewer reviewer worker


content:
## Subagent result

Cancelled

text: Cancelled

task: Map the relevant code for {task}. List files to touch, capture conventions, identify risks, and write findings to {output}.

status: failed

error: Cancelled

task: Read {reads} and create a concrete implementation plan for {task}. Write ordered tasks with file paths, acceptance criteria, and risks to {output}.

task: Execute the plan from {reads}. Implement the smallest correct changes, run validation, and report changed files with evidence to {output}.

task: Review the implementation against the plan. Focus on: correctness, regressions, edge cases, and whether the change does what it claims. Write findings to {output}.

task: Review test coverage and validation. Focus on: tests added/updated, do they exercise the new code, are they sufficient to catch regressions. Write findings to {output}.

task: Review for simplicity, maintainability, and security. Focus on: smallest correct change, readability, naming consistency, input validation, secrets, injection risks. Write findings to {output}.

task: Synthesize the three reviews from {reads}. Apply fixes worth doing now (small, safe changes). Report: what was fixed, what was deferred, and any blockers that need user decision.