Blame
|
1 | --- |
||||||
| 2 | category: reference |
|||||||
| 3 | tags: [process, agents] |
|||||||
| 4 | last_updated: 2026-03-13 |
|||||||
| 5 | confidence: high |
|||||||
| 6 | --- |
|||||||
| 7 | ||||||||
| 8 | # Agent Workflow |
|||||||
| 9 | ||||||||
| 10 | How Claude Code orchestrates work on wikibot.io using delegated subagents. |
|||||||
| 11 | ||||||||
| 12 | ## Roles |
|||||||
| 13 | ||||||||
| 14 | **Orchestrator** (the main Claude Code session) — reads task specs, tracks progress, coordinates across tasks, relays concerns to the human, commits/pushes code, updates the wiki. Does NOT write implementation code directly. |
|||||||
| 15 | ||||||||
|
16 | **Manager** (general-purpose subagent, **Opus**, one per task) — coordinates the proceed workflow for a single task. Dispatches workers for implementation, testing, review, and documentation. Does NOT write code directly — delegates to workers. |
||||||
|
17 | |||||||
|
18 | **Workers** (subagents dispatched by the manager): |
||||||
| 19 | - **Groucho** (Plan subagent) — reviews the manager's proposed approach before implementation. Flags issues, suggests alternatives, answers architectural questions. |
|||||||
| 20 | - **Implementer** (general-purpose, **Sonnet**) — writes code per the plan. Given specific file paths, patterns, and acceptance criteria. |
|||||||
| 21 | - **Test runner** (general-purpose, **Sonnet**) — runs tests, evaluates results, reports failures with context. |
|||||||
| 22 | - **Chico** (general-purpose, **Sonnet**) — code review after implementation. Rates issues as critical, important, or minor. |
|||||||
| 23 | - **Zeppo** (general-purpose, **Sonnet**) — security and infrastructure review after implementation. Same rating scale. |
|||||||
| 24 | - **Fixer** (general-purpose, **Sonnet**) — fixes issues flagged by reviewers or test failures. Given the relevant code and error context. |
|||||||
| 25 | - **Documenter** (general-purpose, **Haiku**) — writes status summary to the dev wiki. |
|||||||
|
26 | |||||||
| 27 | ## Proceed Workflow (per task) |
|||||||
| 28 | ||||||||
| 29 | Each manager follows this sequence: |
|||||||
| 30 | ||||||||
| 31 | 1. **Plan with Groucho.** Describe the proposed approach. Groucho reviews and flags issues. |
|||||||
|
32 | 2. **Implement.** Dispatch implementer with the plan, file context, and acceptance criteria. |
||||||
| 33 | 3. **Test.** Dispatch test runner to execute tests and report results. If failures, dispatch fixer with error context, then re-test. (Sequential: implement → test → fix → re-test.) |
|||||||
| 34 | 4. **Review with Chico and Zeppo** (in parallel). If critical/important issues, dispatch fixer, then re-review. |
|||||||
| 35 | 5. **Document.** Dispatch documenter to write results to the dev wiki. |
|||||||
| 36 | 6. **Report back** to the orchestrator with results, concerns, and any questions for the human. |
|||||||
| 37 | ||||||||
| 38 | ## Parallelization Guide for Managers |
|||||||
| 39 | ||||||||
| 40 | Within a single task, some steps can overlap: |
|||||||
| 41 | ||||||||
| 42 | - **Sequential (must wait):** Plan → Implement → Test → Fix (each depends on the previous) |
|||||||
| 43 | - **Parallel (independent):** Chico + Zeppo run simultaneously during review |
|||||||
| 44 | - **Parallel (after tests pass):** Documentation can start while review is in progress |
|||||||
| 45 | - **Loop:** Test failures trigger fix → re-test cycles. Limit to 3 attempts before reporting back with the failure. |
|||||||
| 46 | ||||||||
| 47 | When a task has multiple independent deliverables (e.g., separate modules with separate tests), the manager MAY dispatch multiple implementers in parallel, each for a different module. Merge results before running integration tests. |
|||||||
|
48 | |||||||
| 49 | ## Orchestrator Responsibilities |
|||||||
| 50 | ||||||||
| 51 | 1. Read task specs from the wiki. |
|||||||
| 52 | 2. For each task, launch a general-purpose manager agent with: |
|||||||
| 53 | - Full task spec (deliverables, acceptance criteria) |
|||||||
| 54 | - Context about existing infrastructure (resource IDs, file paths, patterns) |
|||||||
| 55 | - Instructions to follow the proceed workflow |
|||||||
| 56 | - Use `isolation: "worktree"` for code changes |
|||||||
| 57 | 3. Use `run_in_background` for independent tasks so they run in parallel. |
|||||||
| 58 | 4. When a manager returns with a question for the human: |
|||||||
| 59 | - Relay the question to the human |
|||||||
| 60 | - Get the answer |
|||||||
| 61 | - Resume the manager agent with `resume: <agentId>` (preserves full context) |
|||||||
| 62 | 5. When a manager completes: |
|||||||
| 63 | - Review its output |
|||||||
| 64 | - Commit and push the code |
|||||||
| 65 | - Update the wiki |
|||||||
| 66 | ||||||||
| 67 | ## Question Relay Protocol |
|||||||
| 68 | ||||||||
| 69 | When a manager agent encounters a decision that needs human input: |
|||||||
| 70 | ||||||||
| 71 | 1. Manager stops and returns with the question clearly stated. |
|||||||
| 72 | 2. Orchestrator relays the question to the human (via text or AskUserQuestion). |
|||||||
| 73 | 3. Human answers. |
|||||||
| 74 | 4. Orchestrator resumes the manager with the answer. |
|||||||
| 75 | 5. Manager continues from where it left off. |
|||||||
| 76 | ||||||||
| 77 | Other managers running in parallel are not blocked. |
|||||||
| 78 | ||||||||
|
79 | ## Manager Prompt Template |
||||||
| 80 | ||||||||
| 81 | When launching a manager, the orchestrator's prompt should include all of the following: |
|||||||
| 82 | ||||||||
| 83 | ``` |
|||||||
|
84 | You are a phase manager (Opus) for the wikibot.io project. You coordinate |
||||||
| 85 | workers — you do NOT write code directly. Follow the /proceed workflow: |
|||||||
| 86 | plan with Groucho, dispatch implementer, run tests, review with Chico |
|||||||
| 87 | and Zeppo, fix issues, document, report back. |
|||||||
|
88 | |||||||
| 89 | ## Task: {task_id} — {task_title} |
|||||||
| 90 | ||||||||
| 91 | **Target:** {repo} at {path} |
|||||||
|
92 | **Branch:** Create `{branch_name}` from `{base_branch}` |
||||||
|
93 | |||||||
| 94 | **Context — existing infrastructure:** |
|||||||
| 95 | {bullet list of relevant infra: deployed resources, file paths, URLs, |
|||||||
| 96 | Pulumi config, related repos} |
|||||||
| 97 | ||||||||
| 98 | **Description:** |
|||||||
| 99 | {from task spec} |
|||||||
| 100 | ||||||||
| 101 | **Deliverables:** |
|||||||
| 102 | {from task spec} |
|||||||
| 103 | ||||||||
| 104 | **Acceptance criteria:** |
|||||||
| 105 | {from task spec} |
|||||||
| 106 | ||||||||
| 107 | **Important notes:** |
|||||||
| 108 | {task-specific guidance, gotchas, references to other code} |
|||||||
| 109 | - Do NOT use `git add -A` — stage specific files only |
|||||||
|
110 | - ALWAYS commit your work to the feature branch before reporting back. |
||||||
| 111 | The orchestrator merges branches, not loose files. If you don't commit, |
|||||||
| 112 | your work will be lost when the worktree is cleaned up. |
|||||||
| 113 | - Do NOT push. Do NOT merge to main or the base branch. Report back with results. |
|||||||
|
114 | |||||||
|
115 | ## Worker Dispatch Guide |
||||||
| 116 | ||||||||
| 117 | Use the Task tool with these model settings: |
|||||||
| 118 | ||||||||
| 119 | | Worker | subagent_type | model | When | |
|||||||
| 120 | |--------|--------------|-------|------| |
|||||||
| 121 | | Groucho (plan) | Plan | (default) | Step 1 | |
|||||||
| 122 | | Implementer | general-purpose | sonnet | Step 2 | |
|||||||
| 123 | | Test runner | general-purpose | sonnet | Step 3 | |
|||||||
| 124 | | Chico (review) | general-purpose | sonnet | Step 4 (parallel) | |
|||||||
| 125 | | Zeppo (review) | general-purpose | sonnet | Step 4 (parallel) | |
|||||||
| 126 | | Fixer | general-purpose | sonnet | After test/review failures | |
|||||||
| 127 | | Documenter | general-purpose | haiku | Step 5 | |
|||||||
| 128 | ||||||||
| 129 | When dispatching workers: |
|||||||
| 130 | - Give implementers the FULL plan output from Groucho, plus file paths |
|||||||
| 131 | and code patterns they'll need |
|||||||
| 132 | - Give test runners the specific test commands and what to look for |
|||||||
| 133 | - Give fixers the failing test output AND the relevant source files |
|||||||
| 134 | - Give the documenter a structured summary to write to |
|||||||
| 135 | `Dev/{task_id} Summary` via `mcp__dev-wiki-container__write_note` |
|||||||
| 136 | - Parallelize where possible (Chico + Zeppo; docs + review) |
|||||||
| 137 | - Limit fix→retest loops to 3 attempts before reporting failure |
|||||||
|
138 | ``` |
||||||
| 139 | ||||||||
| 140 | Key elements the orchestrator must not forget: |
|||||||
| 141 | - **Infrastructure context** — resource IDs, URLs, file paths the manager will need |
|||||||
| 142 | - **Coordination notes** — what other managers are running in parallel, which files to avoid |
|||||||
|
143 | - **Model selection** — manager runs as Opus (`model: "opus"`), workers as Sonnet/Haiku per table above |
||||||
|
144 | |||||||
|
145 | ## Invoking the Workflow |
||||||
| 146 | ||||||||
| 147 | The orchestrator uses the `/proceed` skill to load the workflow instructions, then follows the delegation model above. The key rule: **the orchestrator coordinates, managers implement.** |
|||||||