設計・アーキテクチャ策定を担当するteammate。実装方針の決定、ファイル構成の設計、技術的な判断が必要な場面で起用する。 <example> Context: 新機能の実装タスクで、どのファイルをどう変更すべきか設計が必要 user: "認証機能を追加したい" assistant: "architectに設計方針の策定を依頼します。" <commentary> 新機能の実装前に、アーキテクチャレベルの設計判断が必要なためarchitectを起用。 </commentary> </example> <example> Context: 既存コードのリファクタリングで影響範囲の分析が必要 user: "このモジュールをリファクタリングしたい" assistant: "architectに影響範囲の分析と設計方針を依頼します。" <commentary> リファクタリングの影響を正確に把握するためarchitectを起用。 </commentary> </example>
ドキュメント作成・更新を担当するteammate。実装された機能のドキュメント、API仕様書、READMEの更新などを行う。ドキュメント更新が必要な場面で起用する。 <example> Context: 新しいAPIエンドポイントが追加された user: "APIドキュメントを更新してほしい" assistant: "docs-writerにドキュメント更新を依頼します。" <commentary> API追加に伴うドキュメント更新のためdocs-writerを起用。 </commentary> </example> <example> Context: 新機能の実装が完了し、READMEの更新が必要 user: "READMEにこの機能の説明を追加して" assistant: "docs-writerにREADME更新を依頼します。" <commentary> 新機能のドキュメント化のためdocs-writerを起用。 </commentary> </example>
コード実装を担当するteammate。architectの設計方針に基づいてコードを書く、既存コードを修正する、新しいファイルを作成するなどの実装作業を行う。ほぼ全てのタスクで起用される中核メンバー。 <example> Context: architectが設計方針を策定済みで、実装フェーズに入る user: "設計が決まったので実装を始めてほしい" assistant: "implementerに実装を依頼します。" <commentary> 設計方針が確定した後の実装フェーズでimplementerを起用。 </commentary> </example> <example> Context: 小さなバグ修正でarchitectの設計が不要な場合 user: "このバグを直してほしい" assistant: "implementerにバグ修正を依頼します。" <commentary> 単純なバグ修正ではarchitect不要、implementerに直接依頼。 </commentary> </example>
コードレビューを担当するteammate。実装されたコードの品質チェック、バグ検出、プロジェクト規約への準拠確認を行う。implementerの実装完了後に起用する。 <example> Context: implementerが実装を完了し、レビューが必要 user: "実装が終わったのでレビューしてほしい" assistant: "reviewerにコードレビューを依頼します。" <commentary> 実装完了後の品質保証のためreviewerを起用。 </commentary> </example> <example> Context: PR作成前に品質チェックが必要 user: "PRを出す前にコードをチェックして" assistant: "reviewerにPR前のコードレビューを依頼します。" <commentary> PR作成前の最終チェックとしてreviewerを起用。 </commentary> </example>
テスト作成・実行を担当するteammate。実装に対するユニットテスト、統合テストの作成と実行を行う。テストが必要な機能が追加・変更された場面で起用する。 <example> Context: 新機能が実装され、テストが必要 user: "この機能のテストを書いてほしい" assistant: "testerにテスト作成を依頼します。" <commentary> 新機能にテストが必要なためtesterを起用。 </commentary> </example> <example> Context: バグ修正後にリグレッションテストが必要 user: "バグを直したので、テストを追加して再発防止したい" assistant: "testerにリグレッションテスト作成を依頼します。" <commentary> バグ修正の再発防止のためtesterを起用。 </commentary> </example>
Subagent(Agent tool)ではなく、Agent Team(TeamCreate + SendMessage)を使用してチームベースの開発を行う。
確認なしでgitコミットを作成する。
確認なしでGitHub Draft PRを作成する。
確認なしでgit pushを実行する。
プロジェクトルートの `.worktrees/` にworktreeを作成・管理する。
Uses power tools
Uses Bash, Write, or Edit tools
Runs pre-commands
Contains inline bash commands via ! syntax
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
npx claudepluginhub nanopx/nanopx-plugins --plugin agent-team-devOrchestrate multi-agent teams for parallel code review, hypothesis-driven debugging, and coordinated feature development using Claude Code's Agent Teams
AI team role and worker manager for multi-agent development workflows.
Agent Teams スキルを設計・構築するためのベストプラクティスガイド。サブエージェント定義、SendMessage 通信プロトコル、タスク依存管理、PostToolUse Hook ログ、MCP ツール統合、コンテキストファイル設計を網羅。7つの実績あるチームスキルから抽出したパターン集
Multi-agent orchestration for Claude Code. 12 specialized agents working in parallel — planning, building, reviewing, debugging. Plus a Hub for always-alive multi-project sessions controllable from Telegram or Slack.
Persistent memory, shared standards, and structured workflows for AI coding agents. Detects project setup and injects agent context automatically.
Intelligently compose and deploy Claude Code Agent Teams. Auto-selects optimal team composition from 24+ agents and 83+ skills across 5 scopes, generates task dependency graphs, and orchestrates multi-agent workflows with a single command.