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.


type: message

role: user

text:
Break the following request into a numbered plan with concrete file paths and
acceptance criteria. Do not implement until I approve.


role: assistant

type: thinking

thinking:
The user is providing a methodology/process for how they want subagents to be used. They want me to break a request into a numbered plan with concrete file paths and acceptance criteria, and not implement until they approve. However, they haven't actually provided the specific request yet. Let me check if there's something implicit here.

Looking at the conversation, the user pasted a process document about a "feature-build" chain with stages, when to use it, inputs, validation contract, stop rules. Then they provided a more detailed template. Then they said "Break the following request into a numbered plan with concrete file paths and acceptance criteria. Do not implement until I approve."

But I don't see the actual feature request/task that needs to be broken down. I should ask for the specific request/task. The user is probably expecting me to use a team/plan workflow, but I need the actual task first.

Wait - maybe the user is testing whether I'll ask for the request? Or maybe I missed it? Let me re-read carefully.

No, the "following request" isn't provided. The user gave me the methodology but not the concrete task to plan. I should ask for it.

thinkingSignature: reasoning

text:
I’m ready to break the request into a concrete, approval-ready plan, but I don’t see the actual task/feature in your message — only the process templates and stop rules.

Please provide:

1. **The feature request or bug description**
2. **Target repo/path** (or I can infer from `cwd` if it’s `/home/liph`)
3. **Constraints**: API stability, files/modules to avoid, test requirements, etc.
4. **Any attached screenshots or reference files**

Once you share the request, I’ll run the **scout** stage (or do a quick exploration directly if it’s small), then produce a numbered plan with:

- File paths to touch
- Ordered implementation steps
- Acceptance criteria
- Validation commands/tests
- Risks and open questions

No implementation until you approve.

api: openai-completions

provider: ollama

stopReason: stop