Skip to content
cccskills
FreePublished on GitHub

multi-agent-orchestration

Agent tool で複数のサブエージェントを並列起動する/エージェントチームを組成する前に、編成パターン(サブエージェント vs エージェントチーム、レビュアー Teammate の要否、各役割のモデル選択)を決定するためのガイドを適用する。

トリガー:3 つ以上の Agent を並列起動する/タスク間に依存関係がある/チームメイト同士の相互通信が必要/設計や計画フェーズで複数視点が欲しい/ある成果物を別の成果物がレビュー・参照する構造になる。単発のサブエージェント呼び出しや、依存のない fire-and-forget な並列調査では発火しない。

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md6.1 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

マルチエージェント編成パターン

Agent tool で非自明な並列・チーム作業を委譲する前に、以下の 3 つの判断を済ませる。

1. サブエージェント vs エージェントチームの判定

状況採用
各タスクが独立、結果は親が統合するだけサブエージェント並列(Agent を fire-and-forget で複数起動)
タスク間に依存(A の出力が B の入力になる)エージェントチーム(TeamCreate → team_name 付き spawn)
チームメイト同士で相談・通知が発生するエージェントチーム
計画/設計フェーズで複数視点を組み合わせたいエージェントチーム

サブエージェントの限界: 親 → 子の一方向通信のみ。並列起動はできるが互いに会話できないため、依存があると「古い情報で並列実行 → 後で書き直し」になる。

エージェントチームの利点: SendMessage でチームメイト間の双方向通信が可能。TeammateIdle フックでアイドル時の振る舞いも制御できる。Plan Approval ワークフローで段階的承認も取れる。

2. レビュアー Teammate の組み込み

エージェントチームを組成する場合は、原則としてレビュアー Teammate を 1 人入れる。理由:

  • オーケストレーター(Team Lead)が「設計者かつ判定者」になるのを避ける
  • 3 冊跨ぎ・複数ファイル跨ぎの整合性は、独立した目で見たほうが取りこぼしが少ない
  • メンタリングで自分自身が教えてきた「ガードレール 3 層」「Devil's Advocate」の実践

レビュアーの設計

1 人のレビュアー Teammate に 2 フェーズ で実行させる:

  1. 整合性チェック: 既存方針(DESIGN.md / CLAUDE.md / その他規約)との齟齬、章番号・誘導リンク・命名の矛盾
  2. Devil's Advocate: 「本当にその追加が必要か」「読者像/スコープから外れていないか」「既存で代替できないか」を逆張りで問う

レビュアーを 2 人に分けると視点がブレるので、1 人 2 フェーズが推奨。

レビュアーを省略してよい場合

  • 出力が小規模(1 ファイルの単純編集など)
  • 不可逆的な影響がない(ドラフトレベル)
  • ユーザーが明示的に「レビュー不要」と言っている

3. 役割別モデル選択

役割モデル根拠
計画・設計・章立て・判断Opusトレードオフ評価、整合性判断、抽象化が必要
実装・調査・整理Sonnet速度重視、決められた手順の実行
単純な変換・抽出・コピペHaikuコスト最適化
レビュアー TeammateOpus(原則)視点を持って判定するため

model パラメータは明示する。省略すると agent definition の frontmatter or 親から継承で意図と異なるモデルになる可能性がある。

実行フロー(典型例)

依存ありのチーム作業の場合:

  1. TeamCreate でチームを作る(名前は作業内容を表す、例: book-update-team)
  2. 第 1 段の Teammate を Opus で spawn(team_name + name 付き)
  3. 第 1 段完了 → 結果を見て第 2 段の Teammate に SendMessage で前提を伝える
  4. 第 2 段の Teammate を並列 spawn(依存がない範囲で)
  5. 全成果物が出揃ったらレビュアー Teammate を spawn(2 フェーズで実行)
  6. レビュー結果を踏まえて元 Teammate に修正依頼を SendMessage
  7. 最終成果物を Team Lead が統合・書き込み

アンチパターン

  • 依存があるのにサブエージェント並列で済ませる: 後段が古い情報で動く
  • レビュアーなしでオーケストレーターが自己レビュー: 設計者バイアスで甘くなる
  • モデル省略で全部 Sonnet になる: 計画フェーズの判定が浅くなる
  • チームメイトに name を付けない: SendMessage で再開できず、毎回 Agent 新規起動になる
  • 作業中にチームを跨いで指示を出す: team_name を省略すると現在のチーム context に入る — 意図しないチームに紛れ込ませない

エフォートレベル別の適用範囲

現在のエフォートレベル: !echo ${CLAUDE_EFFORT:-high}

  • low: 編成パターンの判定のみ(レビュアーの追加は省略)
  • medium: 標準的な編成判定+レビュアーの組み込み
  • high/xhigh/max: 全ステップを完全実行(Devil's Advocate フェーズ含む)

注意事項

  • このスキルは「編成パターンの決定」だけを担う。実装の詳細(具体的な SendMessage の中身や Agent への prompt)は呼び出し側のロジックに任せる
  • CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 が有効な環境を前提とする。無効な環境ではエージェントチーム機能は使えないため、サブエージェント並列にフォールバックする
  • 判定に迷ったらユーザーに確認する。特に「レビュアーを入れるか省略するか」はコスト感が出るので相談したほうが良い場面がある

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

pr-auto-fix プラグインの監視ループを起動するトリガースキル。Hook で PR 作成が検知された後、Claude が `pr-auto-fix:auto-fix-pr` として呼び出すと Monitor (`pr-auto-fix-watcher`) がバックグラウンドで起動する。Monitor からの通知を受けて pr-auto-fixer エージェントへディスパッチする責務を持つ。ユーザーが手動で起動するスキルではなく、Hook 経由でのみ呼ばれる前提。

The English summary is being prepared. Showing the original description.

honeststack/claudecode-marketplace6Updated Jul 23, 2026

Claude Codeマーケットプレイス用のプラグインを作成する。新規プラグイン作成、コマンド・エージェント・フック・MCPサーバーの追加時に使用。

The English summary is being prepared. Showing the original description.

honeststack/claudecode-marketplace6Updated Jul 23, 2026

ユーザー本人の声で日本語のプローズを起草・推敲・レビューする際に文体ガイドを適用する。対象は Qiita/Zenn 技術記事、note 記事、Slack メッセージ下書き、ユーザーが書く PR/コードレビューコメント、その他ユーザー名義で外部に出る日本語の長文。基本トーン・句読点ルール・用語表記・禁止表現(em ダッシュ「——」、「刺さる/効く」、「リポ」略称など)・シチュエーション別温度感を読み込んだ上で文章を組み立てる。コード・ログ・コミットメッセージの定型文、および他者が書いた文章のレビュー(他人の PR コメントの校正など)には適用しない。

The English summary is being prepared. Showing the original description.

honeststack/claudecode-marketplace6Updated Jul 23, 2026

See all skills by honeststack

Report a problem with this skill