Properties
category: reference
tags: [process, agents, workflow]
last_updated: 2026-03-16
confidence: high

Implementation Workflow

How Claude Code orchestrates implementation tasks on robot.wtf using Sonnet subagents.

Principles

  • Opus orchestrates, Sonnet implements. No Opus manager layer. The orchestrator (main Claude Code session) dispatches Sonnet agents directly.
  • Background everything. ALL subagents run in background (run_in_background: true), no exceptions — research, implementation, review, verification. The orchestrator must stay responsive to the user at all times.
  • Task list tracks the pipeline. Each implementation task gets 5-6 task list items with dependencies. The orchestrator dispatches agents as blockers clear.
  • Rule of Two. No subagent output is merged without independent verification by a second agent.
  • No VPS mutations outside Ansible. Read-only SSH diagnostics only. All changes go through Ansible playbooks.

Pipeline per task

When the user and orchestrator agree on an implementation task:

0. Setup (orchestrator, before any agents)

  • Read memories and this workflow page. Critical constraints (worktree scoping, repo paths) live in memory and are easy to forget.
  • Create the full task list with dependencies (Plan → Implement → Reviews → Fix → Re-reviews → Verify) before dispatching the first agent. The task list is the source of truth for pipeline state.
  • cd into the target git repo before launching worktree-isolated agents. The parent dir (/Users/sderle/code/otterwiki/) is not a git repo — worktrees fail there.

1. Plan (Sonnet Plan agent)

  • Reads relevant code
  • Produces implementation plan with specific file changes
  • Orchestrator reviews plan with user if non-trivial
  • Dispatch: immediately

2. Implement (Sonnet agent, worktree isolation)

  • Gets the plan output + file paths
  • Writes code, writes tests, commits to feature branch
  • Dispatch: when Plan completes
  • Always use isolation: "worktree"

3. Chico review (Sonnet agent)

  • Code quality, correctness, edge cases
  • Rates issues: critical / important / minor
  • Dispatch: when Implement completes (parallel with Zeppo)

4. Zeppo review (Sonnet agent)

  • Security, infrastructure, deployment concerns
  • Same rating scale
  • Dispatch: when Implement completes (parallel with Chico)

5. Fix (Sonnet agent, same worktree)

  • Gets review output + code
  • Fixes critical and important issues
  • Recommits to same branch
  • Dispatch: when both reviews complete
  • Skip if: no critical or important issues found

6. Re-review (Sonnet agents, mandatory if Fix made changes)

  • Chico and Zeppo re-review the Fix diff only (not full implementation)
  • Same rating scale; focus on whether fixes are correct and whether new issues were introduced
  • Dispatch: when Fix completes (parallel, same as initial review)
  • Skip if: Fix was skipped (no changes needed)
  • Rule of Two: moving fast is a false economy; re-review catches issues Fix introduces

7. Verify (Sonnet agent)

  • Final backstop: reads the full diff, runs tests, confirms changes match the spec
  • Reports pass/fail
  • Dispatch: when re-review completes (or after Implement if no Fix/re-review needed)

8. Report

  • Orchestrator summarizes results and any concerns to the user
  • User approves
  • Orchestrator merges and deploys via Ansible

Task list structure

For a task "Foo", create these items:

- [ ] Foo: Plan
- [ ] Foo: Implement (blocked by Plan)
- [ ] Foo: Chico review (blocked by Implement)
- [ ] Foo: Zeppo review (blocked by Implement)
- [ ] Foo: Fix (blocked by Chico + Zeppo)
- [ ] Foo: Chico re-review (blocked by Fix)
- [ ] Foo: Zeppo re-review (blocked by Fix)
- [ ] Foo: Verify (blocked by re-reviews)

Mark each in_progress when the agent launches, completed when it returns.

Agent prompts

Keep prompts short and specific:

  • "Read X, change Y, commit to branch Z"
  • Include the Plan output for implementers
  • Include the diff for reviewers
  • Include review findings for fixers
  • All agents: "Do NOT use git add -A. ALWAYS commit before reporting back. Do NOT push or merge."

What NOT to do

  • Don't launch Opus managers that delegate to Sonnet workers (they do the work themselves at Opus cost)
  • Don't merge without verification
  • Don't debug VPS issues via SSH mutations
  • Don't ask the user if they're done