mcpField
S
subagents

subagents

github.com/dobroslavradosavljevicエージェントワークフロー362 回インストール3 日前に更新
リポジトリ

subagents について

Subagents は、オーケストレーターと複数のエージェントによる独立した作業の連携を支援するスキルです。委任の判断から、担当範囲の設定、競合管理、統合、検証までを案内します。

主な機能

  1. 01委任の適切性を判断
  2. 02作業を独立した担当範囲に分割
  3. 03範囲を限定した指示の作成
  4. 04調査結果の追跡と競合の解消
  5. 05結果の統合と検証

活用シーン

  1. 01別々の API やドキュメントの調査
  2. 02セキュリティやテストなどの個別レビュー
  3. 03独立したモジュールやテスト用データの実装
  4. 04複数の障害の並行調査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/dobroslavradosavljevic/skills --skill subagents

インストール後、Claude Code で/subagentsを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

サブエージェント

概要

1 人のオーケストレーターと 1 人以上のサブエージェント間で作業を調整します。オーケストレーターが分解、競合管理、統合、検証、最終判断を担いながら、独立した作業レーンの調査や実行にサブエージェントを活用します。

基本ルール

作業の安全性、速度、または徹底度を高められる場合にのみ、サブエージェントを使用してください。

割り当てる前に、作業を明確に分離できるレーンがあるか判断してください。作業が小規模で、密接に関連している、またはファイルの競合が起きそうな場合は、サブエージェントを使わず、その理由を伝えてください。ハーネスがサブエージェントに対応していない場合は、単一のエージェントとして続行し、その制約を明記してください。

オーケストレーターの責務

  • ユーザーの依頼を理解し、安全に作業を分割するために十分なコンテキストを調査します。
  • ファイルの所有範囲、サブシステム、質問、成果物、またはレビュー対象ごとに、独立したレーンを特定します。
  • 複数のサブエージェントに重複する編集を割り当てないようにします。
  • 範囲、対象となるファイルや領域、期待する成果、制約を含む、範囲を限定したプロンプトを各サブエージェントに渡します。
  • シークレット、認証情報、非公開の推論、無関係なユーザーの変更をサブエージェントへのプロンプトに含めないようにします。
  • 各サブエージェントの状況、調査結果、成果物、リスクを追跡します。
  • サブエージェントに相反する最終判断をさせず、中央で結果を統合します。
  • 最終検証を実施し、最終回答を作成します。

適切なサブエージェントの作業レーン

次のようなレーンには、サブエージェントを割り当てます。

  • 個別のライブラリ、API、ドキュメント、または製品案を調査する。
  • 正確性、セキュリティ、UX、パフォーマンス、ドキュメント、テストなど、異なる観点を監査する。
  • 同じファイルを同時に編集する必要のない、異なるコード領域を調査する。
  • 範囲が明確に分かれた独立したモジュール、テスト、フィクスチャ、ドキュメント、または例を実装する。
  • 独立した障害を再現する、または別々のシステムからログを収集する。

意味のあるレーンごとに、サブエージェントを 1 人割り当てるのが望ましいです。並列で作業しているように見せるためだけに、エージェントを増やさないでください。

不適切なサブエージェントの作業レーン

次の場合は、サブエージェントを割り当てないでください。

  • 作業が単純で、調整の手間が作業量を上回る場合。
  • 1 人の編集者による一貫した設計判断が必要な場合。
  • 複数のエージェントが、同じファイルや密接に関連するコードを同時に編集する必要がある場合。
  • リポジトリに未整理の変更があり、並行編集によってユーザーの作業を上書きするリスクがある場合。
  • 利用可能なサブエージェントの仕組みでは、安全に検証・統合するのに十分な詳細が得られない場合。
  • ユーザーが委任なしの直接実装を求めており、作業範囲が狭い場合。

割り当て用プロンプトのチェックリスト

各サブエージェントへのプロンプトには、次の内容を含めてください。

  • ユーザーの目的。
  • サブエージェントに割り当てる、正確な作業レーン。
  • 調査対象のファイル、ディレクトリ、システム、または情報源。
  • 編集が許可されている場合に、編集してもよいファイルや領域。
  • 触れてはいけないファイルや領域。
  • 期待する成果物:調査結果、パッチの概要、テスト結果、推奨事項、または成果物。
  • そのレーンにおける検証要件。
  • 障害や不確実な点を明示して報告するよう求めること。

調査やレビューの場合は、一般的な意見ではなく、根拠と実行可能な指摘を求めてください。

統合ワークフロー

  1. 短い作業分解計画を作成します。
  2. サブエージェントが有用かつ安全かを判断します。
  3. 有用な場合は、ハーネスが対応していれば、範囲を限定した作業レーンを並行して割り当てます。
  4. 各サブエージェントの結果を確認してから、その内容を信頼します。
  5. 矛盾、重複、範囲逸脱を解消します。
  6. 関連のないユーザーの作業を保ちながら、受け入れた変更を中央で適用または統合します。
  7. 統合後の成果を対象とする検証を実施します。
  8. どのサブエージェントを使用したか、それぞれが何を担当したか、何が変更されたか、どの検証に合格したかをまとめます。

競合の制御

  • オーケストレーターを唯一の最終統合担当として扱います。
  • 広範で制御されていない編集よりも、調査結果や対象を絞ったパッチを作成するサブエージェントを優先します。
  • 2つの作業レーンが予期せず重複した場合は、その重複部分の並行編集を停止し、手動で統合します。
  • 別のエージェントが近くのコードに手を加えた可能性がある場合は、作業の適用や統合の前にファイルを読み直します。
  • ユーザーの変更や別のエージェントの作業を、確認せずに上書きしてはいけません。

最終回答

次の内容を報告します。

  • サブエージェントを使用したかどうか。
  • 使用した場合は、割り当てた作業レーンと、それぞれから返された内容。
  • 使用しなかった場合は、その理由。
  • 最終的に統合した変更または結論。
  • 実施した検証と、残っているリスク。

コメント