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
- When done, do NOT push. 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.