metalicjames/teamwork

Teamwork マルチエージェントオーケストレーション (/teamwork)

Teamwork は、専門化された新鮮なコンテキストを持つサブエージェントの協調チームを調整し、大規模ソフトウェアエンジニアリングプロジェクト、マルチファイル移行、システムシミュレーション、厳格なドキュメント批評、数学的証明を提供します。

単一の会話コンテキストに過負荷をかけたり、実装エージェントが不完全な作業を自己承認することを許可する代わりに、Teamwork はすべての実行を厳格な2つのフェーズに分割します。

1. フェーズ 1: タスクスコーピングと仕様策定 (スコーピング面接) — スコープを明確化し、観測可能な要件 (何を、ではなくどのように ではない) を定義し、独立したプログラムベースまたはルーブリックベースの検証を確立し、ショートカット制限を Integrity Mode (development、demo、benchmark) にマッピングし、プロジェクト作業ディレクトリを設定し、ユーザーの明示的な承認を必要とするレビュー可能なプロンプト成果物 (prompt_draft.md) を生成します。
2. フェーズ 2: 自律実行 (構造化ハンドオフと敵対的ゲート) — 承認後、Project Sentinel が ORIGINAL_REQUEST.md を記録し、実行前依存関係チェックを実行し、選択された実行パスに応じて専門の Orchestrator にルーティングし、排他的ファイル所有権とエージェントごとのスクラッチ分離を持つ並列の Explorer と Worker を調整し、すべてのマイルストーンで独立した検証ゲート (Critic、Challenger、Auditor) を強制し、エンドツーエンドの Victory Auditor (VICTORY CONFIRMED) による最終完了をブロックします。

---

クロスハーネス委任とツールマッピング

Teamwork はハーネスに依存しません。以下の各抽象アクションを、現在のエージェントハーネスで利用可能なネイティブツールにマッピングしてください (詳細は references/harness-delegation.md を参照)。

抽象操作	ネイティブ / ツールハーネス	Claude Code / Cowork	Codex / ChatGPT Work	Cursor / omp / その他のハーネス
新しいサブエージェントを生成	invoke_subagent (TypeName、Role、Prompt を使用)	Agent (Task) ツール	spawn_agent (fork_context: false または fork_turns: "none")	ネイティブの task / サブエージェントツール (クリーンコンテキスト)
カスタムサブエージェントを定義	define_subagent (または agents/*.md)	./skills/ または agents/*.md	汎用サブエージェントが agents/*.md を読み込む	agents/*.md を読み込むか、プロンプトでペルソナファイルパスを渡す
サブエージェントにメッセージ/起床	send_message	成果物の状態で新しい Agent を再開/ディスパッチ	send_message / wait	更新された成果物の状態を新しいサブエージェントに渡す
構造化ユーザー質問	ask_question	AskUserQuestion (またはプレインチャット)	構造化質問ツール (またはプレインチャット)	構造化質問ツールまたはプレインテキスト質問
定期的な進捗確認	schedule (CronExpression)	マイルストーンディスパッチ間で確認	マイルストーンディスパッチ間で確認	マイルストーンディスパッチ間で確認

サブエージェントペルソナ解決: すべての Teamwork サブエージェントペルソナは agents/<persona-name>.md (このスキルディレクトリからの相対パス、またはプラグインルート ../../agents/<persona-name>.md) で定義されています。

• ハーネスが agents/ から名前付きサブエージェントを登録する場合、フロントマターの name (例: teamwork-sentinel、teamwork-interviewer、teamwork-orchestrator、teamwork-swe-light、teamwork-doc-orchestrator、teamwork-proof-orchestrator、teamwork-colosseum、teamwork-explorer、teamwork-worker、teamwork-critic、teamwork-challenger、teamwork-auditor、teamwork-victory-auditor、teamwork-dependency-auditor) でサブエージェントを呼び出します。
• ハーネスが名前付きサブエージェントを登録しない場合、実行時に動的に登録するか (例: define_subagent を使用)、汎用の新しいコンテキストサブエージェントを生成し、タスクを開始する前に agents/<persona-name>.md をシステムペルソナとして読み込むように指示します。
• ハーネスがサブエージェントの入れ子 (サブエージェントがサブエージェントを生成すること) をサポートできない場合、プライマリエージェントが Sentinel と Orchestrator の両方の役割を果たし、Explorer、Worker、Critic、Challenger、Auditor、および Victory Auditor をフラットな深さ1のサブエージェントとして直接ディスパッチし、すべての成果物ハンドオフと新しいコンテキスト境界を維持します。

---

実行パスとルーティングテーブル

Teamwork は、承認されたプロンプトで説明された作業に基づいて、チームアーキテクチャ、検証深度、および Orchestrator の役割を自動的に選択します (references/orchestration-patterns.md を参照)。

実行パス	Orchestrator ペルソナ	最適な用途	トリガー / オプトイン信号	実行前依存関係監査?	最終 Victory 監査
1. プロジェクトパターン (汎用分散SWE)	teamwork-orchestrator (agents/teamwork-orchestrator.md)	マルチファイルSWE、大規模リファクタリング、システムシミュレーション、グリーンフィールド開発。	デフォルト (マルチコンポーネントまたはマルチファイルタスクに自動選択)。	はい (teamwork-dependency-auditor)	teamwork-victory-auditor
2. SWE Light (逐次洗練)	teamwork-swe-light (agents/teamwork-swe-light.md)	1つの自己完結型変更 — 局所的なバグ修正、小さな機能、または限定されたリファクタリング (4つのハードルール)。	明示的なプロンプト信号 (例: "小さく保つ"、"焦点を絞る"、"1つの自己完結型変更として実行")。	はい (teamwork-dependency-auditor)	teamwork-victory-auditor
3. ドキュメントレビュー (document_review)	teamwork-doc-orchestrator (agents/teamwork-doc-orchestrator.md)	多角的な批評、RSAレビューツリー、論文、RFC、設計ドキュメントの統合。	レビューリクエスト (例: "この論文をレビュー"、"この設計ドキュメントを批評")。	いいえ	teamwork-victory-auditor (ドキュメントレビューモード)
4. 数学/証明 (proof)	teamwork-proof-orchestrator (agents/teamwork-proof-orchestrator.md)	数学的問題解決、5フェーズの補題導出、定理証明。	数学プロンプト (例: "定理Xを証明"、"数学的限界を導出して検証")。	オプション (CAS/Lean/Pythonが必要な場合)	組み込みパイプラインプルーフ検証器 + teamwork-victory-auditor
5. 数学/証明 — 大規模チーム (colosseum)	teamwork-colosseum (agents/teamwork-colosseum.md)	難しい予想のための大規模トーナメントネットワーク、反例検索、組合せ最適化。	明示的なスケール信号 (例: "非常に大規模なエージェントチームを使用")。	オプション (計算ツールが必要な場合)	teamwork-victory-auditor (証明/Colosseumモード)

---

Integrity Mode

Teamwork は、プロジェクト要件に検証の厳格さを合わせるために、3つの内部 Integrity Mode のうち1つを強制します。フェーズ1の面接中に、ユーザーにどのショートカットを禁止すべきかを尋ね (質問に内部モード名を公開せずに)、その回答をプロンプト成果物の対応するモードにマッピングします。

Integrity Mode	目的	許可されるプラクティス	運用上の境界 / 許可されないショートカット	Auditor の強制
development (デフォルト)	迅速な反復	コード再利用、サードパーティライブラリ、事前構築フレームワークを許可。	出力の捏造、ファサード/スタブ実装の返却、テスト合格のモック/フェイク。	捏造された出力、ハードコード/モックされたテスト合格、未実装のスタブをフラグ付け。
demo	再現可能なプレゼンテーション	標準ライブラリと汎用ユーティリティを許可。コアロジックは真正に実装する必要がある。	development のすべての禁止事項 に加えて: オープンソースからのコアロジックコピー、コア作業の外部ツール/バイナリへの委任、テストソース/オラクルの読み取りによる期待動作のリバースエンジニアリング。	インポート、サブプロセス呼び出し、git/ファイルアクセスを監査して、コアロジックがオリジナルであり、テストオラクルがリバースエンジニアリングされていないことを確認。
benchmark	徹底的な評価	言語標準ライブラリのみを使用した、完全に独立したゼロからの実装。	demo のすべての禁止事項 に加えて: 実装にサードパーティライブラリまたは外部フレームワークを使用すること。	最大厳格度: 非標準ライブラリ依存関係、外部委任、オラクルの覗き見をすべて拒否し、グラウンドトゥルース実行出力をバイナリ拒否権で検証。

---

フェーズ 1: タスクスコーピングと仕様策定 (スコーピング面接)

実行チームを生成する前に、何を構築するか、そしてそれがどのように独立して検証されるかについてユーザーと調整します。完全な詳細とエッジケースについては references/interview-protocol.md を参照してください。

基本原則: 内部メカニズムではなく、目標と観測可能な不変条件を定義する

ユーザーが明示的に要求しない限り、プロンプト成果物で内部クラス階層、ファイル分割、実装アルゴリズムを規定しないでください。どのように を過度に制約すると、Explorer と Worker が実際のコードベース制約に適応できなくなります。検証 を過小指定すると、エージェントが不完全な作業を自己承認できるようになります。

9ステップのスコーピングプロトコル

1. ステップ 1 — 受け入れとトリアージ:
   • ユーザーの最初の /teamwork リクエストとワークスペース内の参照ファイルを検査します。[skip-interview] パラメータをサポートし、直接フェーズ2にバイパスします。認識されない括弧パラメータは無視されたものとしてログに記録します。
   • 以下の項目について、明確なものと不足しているものを特定します: (a) スコープと目的、(b) 実行パスのオプトイン、(c) 運用上の境界 / Integrity Mode、(d) 検証と合格基準、(e) 作業ディレクトリ。
   • ユーザーの集中を尊重: 必要なすべての質問を1つの集中した質問票 (または非常に多面的なドメインでは最大2つ) にまとめることで、ユーザーの往復を最小限に抑えます。選択肢が離散的な場合は ask_question を使用し、チャットで明確な番号付き質問を使用します。
2. ステップ 2 — スコープ、目的、実行パスのオプトイン:
   • 成果物の目的を明確化: showcase / demo、production、eval / benchmark、または exploration / research。
   • 明示的なオプトイン (例: "小さく焦点を絞って保つ" や "非常に大規模なエージェントチームを使用") をプロンプト成果物の冒頭文にキャプチャします。
3. ステップ 3 — ショートカット制限と Integrity Mode マッピング:
   • オープンソースコピー、外部CLI委任、オラクル覗き見、サードパーティライブラリに関するユーザーの制約を引き出します。
   • development、demo、または benchmark にマッピングします。
4. ステップ 4 — 要件 (R1、R2、...) :
   • 観測可能な動作、入出力、不変条件、制約を説明するモジュラー要件ブロックを作成します — 成果物が何をすべきか、どのようにコーディングするかではありません。
5. ステップ 5 — 独立した検証とデュアルトラックテスト:
   • 自律ソフトウェアエージェントは、外部の実行可能な検証がない場合、時期尚早に完了を主張する傾向があります。確実に実行され、シミュレートされた合格に耐える、再現可能な自動テストに基づいた明確な合格基準を確立します。
   • 汎用パスSWEプロジェクトの場合、デュアルトラックテストアーキテクチャ が必要であり、独立したテストスイートが最小層の式を満たします: $$\text{合計最小テスト数} \ge 11N + \max\left(5, \left\lfloor \frac{N}{2} \right\rfloor\right)$$
6. ステップ 6 — 合格基準:
   • 検証チェックを、## 合格基準 の下にカテゴリ別にグループ化されたチェック可能な - [ ] アイテムに変換します。
7. ステップ 7 — インフラストラクチャ制約 (条件付き) :
   • サンドボックスまたは外部ジョブ制約を扱う場合にのみ、制御されたAPI/ファイルシステム境界を指定します。
8. ステップ 8 — プロジェクト作業ディレクトリ:
   • 既存のコードベース: 既存のディレクトリを使用します (質問しないでください)。新規プロジェクト: 質問し、デフォルトで ~/teamwork_projects/<project_name> とします。
9. ステップ 9 — 組み立て、検証、承認の要求:
   • prompt_draft.md を標準スキーマを使用して書き、全文 をチャットでユーザーに直接提示します。
   • 予想パスを提示: "マルチマイルストーンの汎用エンジニアリングパスを介した実行を予想しています。単一の軽量な変更を希望する場合はお知らせください。"
   • 停止し、フェーズ2を開始する前にユーザーの明示的な承認を待ちます。

---

フェーズ 2: 自律実行 (Sentinel と Orchestrator プロトコル)

ユーザーがプロンプト成果物を明示的に承認したら、直ちに PROJECT SENTINEL モードに移行します。references/orchestration-patterns.md、references/verification-gates.md、および references/operational-protocols.md を参照してください。

Sentinel の主要な責任

Sentinel (agents/teamwork-sentinel.md) として、あなたは恒久的なトップレベルのプロジェクト管理者です。あなたは自分自身で本番コードを書いたり、実装の詳細をデバッグしたり、低レベルの技術的決定を下したりしてはなりません — コンテキストを超軽量に保ち、プロジェクトライフサイクル全体を監督します。

責任 1: ベースライン取り込みとリクエスト永続化

1. ターゲットの Working directory が存在することを確認します (例: mkdir -p <working_dir>/.teamwork/scratch)。
2. 承認されたプロンプト成果物を そのまま <working_dir>/ORIGINAL_REQUEST.md に書き込みます (不変のグラウンドトゥルース)。
3. アクティブな実行パス、サブエージェントID、現在のマイルストーン、状態不変条件を追跡するために <working_dir>/BRIEFING.md を初期化します。

責任 2: 自律的な健全性と進捗監視

1. schedule (またはターン遷移) を介して非侵入型の定期的モニターをスケジュールし、<working_dir>/PROGRESS.md をスキャンして生存ハートビート (Last visited: [timestamp]) を追跡します。
2. 未加工のログをチャットにダンプせずに、簡潔で事実に基づいた進捗サマリーをユーザーに提供します。

責任 3: 環境監査と実行パスルーティング

1. 実行パスとルーティングテーブル から実行パスを選択します。
2. 実行前依存関係監査 (ブロッキング) :
   • ローカルツールチェーンを必要とする汎用SWE、SWE Light、またはMath実行の場合、teamwork-dependency-auditor (agents/teamwork-dependency-auditor.md) を生成します。
   • READY の場合: 指定されたパスの Orchestrator を生成します。
   • MISSING の場合

…

[翻訳のために切り詰められました]