Commit 799da8
2026-03-16 04:40:01 Abolish ICE 🐦⬛: Agent Workflow deleted.| Design/Agent_Workflow.md .. /dev/null | |
| @@ 1,147 0,0 @@ | |
| - | --- |
| - | category: reference |
| - | tags: [process, agents] |
| - | last_updated: 2026-03-13 |
| - | confidence: high |
| - | --- |
| - | |
| - | # Agent Workflow |
| - | |
| - | How Claude Code orchestrates work on wikibot.io using delegated subagents. |
| - | |
| - | ## Roles |
| - | |
| - | **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. |
| - | |
| - | **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. |
| - | |
| - | **Workers** (subagents dispatched by the manager): |
| - | - **Groucho** (Plan subagent) — reviews the manager's proposed approach before implementation. Flags issues, suggests alternatives, answers architectural questions. |
| - | - **Implementer** (general-purpose, **Sonnet**) — writes code per the plan. Given specific file paths, patterns, and acceptance criteria. |
| - | - **Test runner** (general-purpose, **Sonnet**) — runs tests, evaluates results, reports failures with context. |
| - | - **Chico** (general-purpose, **Sonnet**) — code review after implementation. Rates issues as critical, important, or minor. |
| - | - **Zeppo** (general-purpose, **Sonnet**) — security and infrastructure review after implementation. Same rating scale. |
| - | - **Fixer** (general-purpose, **Sonnet**) — fixes issues flagged by reviewers or test failures. Given the relevant code and error context. |
| - | - **Documenter** (general-purpose, **Haiku**) — writes status summary to the dev wiki. |
| - | |
| - | ## Proceed Workflow (per task) |
| - | |
| - | Each manager follows this sequence: |
| - | |
| - | 1. **Plan with Groucho.** Describe the proposed approach. Groucho reviews and flags issues. |
| - | 2. **Implement.** Dispatch implementer with the plan, file context, and acceptance criteria. |
| - | 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.) |
| - | 4. **Review with Chico and Zeppo** (in parallel). If critical/important issues, dispatch fixer, then re-review. |
| - | 5. **Document.** Dispatch documenter to write results to the dev wiki. |
| - | 6. **Report back** to the orchestrator with results, concerns, and any questions for the human. |
| - | |
| - | ## Parallelization Guide for Managers |
| - | |
| - | Within a single task, some steps can overlap: |
| - | |
| - | - **Sequential (must wait):** Plan → Implement → Test → Fix (each depends on the previous) |
| - | - **Parallel (independent):** Chico + Zeppo run simultaneously during review |
| - | - **Parallel (after tests pass):** Documentation can start while review is in progress |
| - | - **Loop:** Test failures trigger fix → re-test cycles. Limit to 3 attempts before reporting back with the failure. |
| - | |
| - | 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. |
| - | |
| - | ## Orchestrator Responsibilities |
| - | |
| - | 1. Read task specs from the wiki. |
| - | 2. For each task, launch a general-purpose manager agent with: |
| - | - Full task spec (deliverables, acceptance criteria) |
| - | - Context about existing infrastructure (resource IDs, file paths, patterns) |
| - | - Instructions to follow the proceed workflow |
| - | - Use `isolation: "worktree"` for code changes |
| - | 3. Use `run_in_background` for independent tasks so they run in parallel. |
| - | 4. When a manager returns with a question for the human: |
| - | - Relay the question to the human |
| - | - Get the answer |
| - | - Resume the manager agent with `resume: <agentId>` (preserves full context) |
| - | 5. When a manager completes: |
| - | - Review its output |
| - | - Commit and push the code |
| - | - Update the wiki |
| - | |
| - | ## Question Relay Protocol |
| - | |
| - | When a manager agent encounters a decision that needs human input: |
| - | |
| - | 1. Manager stops and returns with the question clearly stated. |
| - | 2. Orchestrator relays the question to the human (via text or AskUserQuestion). |
| - | 3. Human answers. |
| - | 4. Orchestrator resumes the manager with the answer. |
| - | 5. Manager continues from where it left off. |
| - | |
| - | Other managers running in parallel are not blocked. |
| - | |
| - | ## Manager Prompt Template |
| - | |
| - | When launching a manager, the orchestrator's prompt should include all of the following: |
| - | |
| - | ``` |
| - | You are a phase manager (Opus) for the wikibot.io project. You coordinate |
| - | workers — you do NOT write code directly. Follow the /proceed workflow: |
| - | plan with Groucho, dispatch implementer, run tests, review with Chico |
| - | and Zeppo, fix issues, document, report back. |
| - | |
| - | ## Task: {task_id} — {task_title} |
| - | |
| - | **Target:** {repo} at {path} |
| - | **Branch:** Create `{branch_name}` from `{base_branch}` |
| - | |
| - | **Context — existing infrastructure:** |
| - | {bullet list of relevant infra: deployed resources, file paths, URLs, |
| - | Pulumi config, related repos} |
| - | |
| - | **Description:** |
| - | {from task spec} |
| - | |
| - | **Deliverables:** |
| - | {from task spec} |
| - | |
| - | **Acceptance criteria:** |
| - | {from task spec} |
| - | |
| - | **Important notes:** |
| - | {task-specific guidance, gotchas, references to other code} |
| - | - Do NOT use `git add -A` — stage specific files only |
| - | - ALWAYS commit your work to the feature branch before reporting back. |
| - | The orchestrator merges branches, not loose files. If you don't commit, |
| - | your work will be lost when the worktree is cleaned up. |
| - | - Do NOT push. Do NOT merge to main or the base branch. Report back with results. |
| - | |
| - | ## Worker Dispatch Guide |
| - | |
| - | Use the Task tool with these model settings: |
| - | |
| - | | Worker | subagent_type | model | When | |
| - | |--------|--------------|-------|------| |
| - | | Groucho (plan) | Plan | (default) | Step 1 | |
| - | | Implementer | general-purpose | sonnet | Step 2 | |
| - | | Test runner | general-purpose | sonnet | Step 3 | |
| - | | Chico (review) | general-purpose | sonnet | Step 4 (parallel) | |
| - | | Zeppo (review) | general-purpose | sonnet | Step 4 (parallel) | |
| - | | Fixer | general-purpose | sonnet | After test/review failures | |
| - | | Documenter | general-purpose | haiku | Step 5 | |
| - | |
| - | When dispatching workers: |
| - | - Give implementers the FULL plan output from Groucho, plus file paths |
| - | and code patterns they'll need |
| - | - Give test runners the specific test commands and what to look for |
| - | - Give fixers the failing test output AND the relevant source files |
| - | - Give the documenter a structured summary to write to |
| - | `Dev/{task_id} Summary` via `mcp__dev-wiki-container__write_note` |
| - | - Parallelize where possible (Chico + Zeppo; docs + review) |
| - | - Limit fix→retest loops to 3 attempts before reporting failure |
| - | ``` |
| - | |
| - | Key elements the orchestrator must not forget: |
| - | - **Infrastructure context** — resource IDs, URLs, file paths the manager will need |
| - | - **Coordination notes** — what other managers are running in parallel, which files to avoid |
| - | - **Model selection** — manager runs as Opus (`model: "opus"`), workers as Sonnet/Haiku per table above |
| - | |
| - | ## Invoking the Workflow |
| - | |
| - | 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.** |