Repository navigation
Ship manager primary agent + planner/implementor/reviewer subagent roster #224
Description
Parent: #217 (delta 3 of 4). Independent of #222 / #223 / #225.
Problem
#217 references a per-project SWE manager agent and a four-agent subagent roster (`planner`, `implementor`, `reviewer`, `test-author`). None of these exist as built-ins today. Built-in roster (`packages/opencode/src/agent/agent.ts:128-320`) is: `build`, `autopilot`, `plan`, `general`, `explore`, `scout`, `compaction`, `title`, `summary`.
Permission system already supports per-agent permission overrides via `Permission.merge(defaults, user, agent)` (`config/permission.ts:24-45`), so this is config only — no engine changes.
Proposed agents
Manager (primary)
| Permission | Value | Why |
|---|---|---|
| `task` | allow | needs to spawn subagents |
| `worker_*` (when #223 lands) | allow | needs to dispatch workers |
| `read`, `glob`, `grep`, `list` | allow | reads code to plan/review |
| `edit`, `write`, `bash`, `patch` | deny | manager never edits — delegates |
| `todowrite` | allow | dashboard |
Subagents (mode: subagent)
| Agent | Allowed | Denied | Purpose |
|---|---|---|---|
| `planner` | `read`, `grep`, `glob`, `list`, `todowrite`, `webfetch`, `websearch` | `edit`, `write`, `bash`, `patch`, `task` | Produces plan only — no mutations. |
| `implementor` | `read`, `edit`, `write`, `bash`, `patch`, `glob`, `grep`, `list` | `task` | Does the work in a worktree. |
| `reviewer` | `read`, `grep`, `glob`, `list`, `bash` (read-only commands) | `edit`, `write`, `patch`, `task` | Reads diff, reports findings. |
| `test-author` | `read`, `edit`, `write`, `bash`, `grep`, `glob`, `list` | `task` | Adds tests only — narrow scope. |
System prompts and tool sets should be kept minimal — favor what's already in `explore` / `build` definitions as a starting point.
Two ship options
A. As built-ins in `agent/agent.ts`. Pro: zero-config onboarding. Con: every user gets the full roster whether they use it or not.
B. As a documented `opencode.json` example in the docs (likely `packages/web/content/docs/`). Pro: opt-in, flexible. Con: copy-paste friction.
Recommend B for v1 — let the pattern prove itself in user configs before baking it into the engine. Promote to built-ins later if adoption is broad.
Acceptance criteria
- Docs page with a complete, copy-pasteable `opencode.json` example defining the five agents.
- System prompts written for each agent (under 200 words each — keep tight).
- Example includes a recommended permission preset for the user's global config (e.g. `ask` for `edit` outside worktrees).
- At least one screenshot or transcript snippet showing the manager delegating to a subagent.
Out of scope
- Engine changes (none needed).
- Auto-spawn / auto-creation of the manager session per project (tracked separately if pursued).
Activity