Feature: migrate feature-dev plugin to agent teams

Summary

The bundled feature-dev plugin currently uses plain subagents for codebase exploration (Phase 2), architecture design (Phase 4), and quality review (Phase 6). Subagents report back to the caller only — they can't communicate with each other. Implementation (Phase 5) and review fixes (Phase 6) run in the lead's context, bloating it with implementation details.

The new agent teams feature enables a significantly better workflow where teammates:

• Share discoveries with each other (explorers avoid duplicated work)
• Challenge each other's designs (architects debate trade-offs)
• Cross-reference findings (reviewers reduce false positives)
• Implement in separate contexts (lead stays focused on coordination)
• Coordinate via a shared task list instead of implicit waiting

Proposed Changes

Core Architecture

• Lead is a pure orchestrator: The lead MUST NOT read source code files, search patterns, or explore the codebase. All code reading is done by teammates. The lead works exclusively from teammate summaries received via SendMessage. This preserves the lead's context window for coordination across all 7 phases.
• Add SendMessage, TaskUpdate, TaskList, TaskGet to the tools of all four agent definitions (code-explorer, code-architect, code-reviewer, code-implementer)
• Add Team Collaboration protocol sections to each agent with instructions for task claiming, inter-agent messaging, and task completion
• Remove TodoWrite from all agents — replaced by shared task list tools

New code-implementer Agent

• Write-capable agent (Edit, Write, Bash) for implementing features from architecture blueprints within assigned file boundaries, with file ownership discipline to prevent conflicts
• Supports two assignment types: feature implementation (from blueprint) and fix application (from reviewer findings)
• The lead never implements directly — all code is written by code-implementer teammates

Phase-by-Phase Changes

• Phase 1: Creates team via TeamCreate, pre-creates all phase tasks with dependency chains (addBlockedBy), including placeholder tasks refined later
• Phase 2: Explorers share discoveries with each other; lead synthesizes from summaries only (no file reading)
• Phase 3: If lead needs more details, spawns additional explorer instead of reading files
• Phase 4: Architects start from explorer summaries (not re-exploring), challenge each other's designs; lead captures codebase conventions from architect reports for later phases; context passed verbatim
• Phase 5: Fully delegated to code-implementer teammates — single implementer for small features, multiple for parallel multi-component work; placeholder tasks refined via TaskUpdate; architect blueprints copied verbatim to spawn prompts
• Phase 6: Reviewer scope updated (task assignment in teams, git diff standalone); Bash tool added to reviewer for git diff access; review placeholders refined with actual file lists before spawning; fixes delegated to code-implementer "fixer" teammate with explicit TaskCreate; optional re-review after substantial fixes
• Phase 7: TeamDelete cleanup

Quality & Consistency

• Delegate mode (Shift+Tab) referenced in command and README for enforcing orchestrator role
• README updated with prerequisites, team-based examples, troubleshooting, and "pure orchestrator" design principle
• All cross-check inconsistencies resolved (reviewer confidence ranges, task lifecycle, context passing chain)
• Version bumped to 2.0.0

Reference Implementation

A working implementation is available at: https://github.com/tarurar/claude-code/pull/1

Key commits:

• cea0033 — Core migration: command rewrite, agent tool additions, team collaboration protocols
• 4638d41 — Agent model upgrade (sonnet → opus)
• 66cc101 — New code-implementer agent, Phase 5/6 delegation
• 4919565 — Cross-check fixes: 13 inconsistencies resolved (reviewer scope/tools, task lifecycle, context passing, TodoWrite removal, delegate mode)

Why This Matters

The current subagent approach leaves value on the table. With agent teams:

• Phase 2: Explorer A discovers the codebase uses repository pattern → messages Explorer B → Explorer B factors it in immediately instead of rediscovering it
• Phase 4: Architect proposing "clean architecture" gets challenged by the "minimal changes" architect on unnecessary complexity → the lead receives designs that have already been stress-tested
• Phase 5: Implementation happens in separate code-implementer contexts — the lead's context stays clean for coordination. For multi-component features, implementers work in parallel and coordinate on interfaces via direct messaging
• Phase 6: Reviewer finding a potential null reference gets confirmed by another reviewer who checked the same file → higher confidence, fewer false positives. Fixes are applied by a dedicated implementer, not the lead
• Context preservation: The lead never reads source files, so its context window is available for the full 7-phase workflow even on large features