vlv-code/manage-meta-project

リポジトリエージェントチームオーケストレーション（メタプロジェクトチームオーケストレーション）

プロジェクトに合わせた専門エージェントチームを構成、監査、最適化するための自律スキル。 このスキルはリポジトリ構造を分析し、必要な専門分野（GitHub マネージャー、DevOps、QA、UI/UX、セキュリティ、プロダクトアナリスト、法務、合議審判など）を特定し、.agents/team/ に分離されたプロファイルを具体化し、厳格な調整プロトコル（Human-in-the-Loop、ユーザー仲介のハンドオフ、不変のノート、証拠に基づく調停）を確立します。

---

スキルを呼び出すタイミング

• ユーザーが「エージェントチームを編成」「プロジェクトにロールを割り当て」「エージェントロールを設定」「チーム活動を監査」「チームロールをレビュー」「エージェントチーム構成を更新」をリクエストした場合。
• Docker、CI/CD、モバイルUI、データベース、外部ペイメント統合など、新しい主要テクノロジーレイヤーがプロジェクトに導入され、専用のドメインガバナンスが必要になった場合。

---

実行手順

フェーズ1：高速リポジトリスキャン（マーカー検査）

ロールを定義する前に、エージェントは主要なプロジェクトマーカーを検査する必要があります。

1. ホスティングとCI基盤: .github/ ディレクトリ、ワークフロー、プルリクエストテンプレート、Issueテンプレートの存在。
2. ライセンスとオープンソースガバナンス: LICENSE、著作権、CONTRIBUTING.md、依存関係マニフェストの存在。
3. コンテナ化とオーケストレーション: Dockerfile、docker-compose*.yml、k8s/、helm/。
4. テスト基盤: tests/ ディレクトリ、pytest.ini、vitest.config.*、テストフィクスチャ。
5. セキュリティと機密データ: auth/、security/ ディレクトリ、トークン処理、セッション管理、暗号化ロジック。
6. ユーザーインターフェースとデザイン: フロントエンドモジュール、HTML/CSS、ボットキーボードレイアウト、アセット、デザイントークン。
7. 現在のプロジェクトパスポート: AGENTS.md と .agents/project_knowledge/ スライスの読み込み（既に初期化されている場合）。
8. セカンダリ/ポリグロットスタック: コンパイル済みまたは代替言語のソースファイル（例：client/、native/、core/、desktop/ 内の .cpp、.c、.h、.rs、.go、.swift）を含むサブディレクトリ。

---

フェーズ2：スケール適応型サイジングとオープンコンピテンシーマトリックス

ロールを提案する前に、エージェントはリポジトリの規模を評価し、必要最小限のチームを合成する必要があります。

1. リポジトリサイジングとロール合成

エージェントはコードベースのボリューム（LOC、フォルダの深さ、技術的多様性）を見積もります。

• マイクロ/小規模リポジトリ（1万行未満、単独開発者、1～2の主要スタック）: マトリックスからのコンピテンシーブロックを統合プロファイルにバンドルして、2～3の複合ロールを合成します。

  • 標準的なコンパクトトリオ:
    1. agent-dev-lead: インテーク分析、タスク分解、一般的なコード実装を組み合わせます（agent-intake-dispatcher + agent-general-worker）。
    2. agent-quality-guardian: パスポート/ナレッジの整合性、ユニットテストスイート、デッドコード監査を組み合わせます（agent-meta-guardian + agent-qa-engineer + agent-deep-auditor）。
    3. agent-github-steward: Git ハイジーン、Conventional Commits、Code-to-README の真実の一致、および CI/CD。

• 中規模リポジトリ（1万～5万行、小規模チーム、複数のサービス）: 主要コンポーネントに合わせた 3～5 の専用ロールを展開します。

• 大規模/エンタープライズリポジトリ（5万行超、モノレポ、マイクロサービス）: 厳格な関心の分離を持つ 6 つ以上の詳細ロールを展開します。

• ポリグロットスタック分離ルール（有害なバンドルの禁止）: 専用スキルなしで、セカンダリのコンパイル済みまたは専門スタック（C/C++、Rust、Go、ネイティブGUI）を agent-general-worker にバンドルすることを厳格に禁止します。ポリグロットスタックが検出された場合は、専用ロール（例：ネイティブコンパイラとツールチェーンを持つ agent-native-desktop）を合成するか、ネイティブディレクトリをレッドゾーンに明示的にマッピングし、強制的なハンドオフトリガーを設定します。

• 必須ディスパッチャールール（マルチロールの混乱防止）: 3 つ以上の専門ロールを展開する場合、インテークディスパッチャー（agent-intake-dispatcher または agent-dev-lead に統合されたディスパッチャー）の展開は厳格に必須です。単一のエントリポイントなしに、複数の孤立したロールのルーティングされていないバンドルをユーザーに残すことを禁止します。

2. オープンコンピテンシーカタログ（ロールマトリックス）

[!IMPORTANT] 以下の表はオープンコンピテンシーカタログであり、不変のクローズド列挙型ではありません。エージェントは、リポジトリの実際のアーキテクチャに一致する複合ロールを合成したり、カスタムのドメイン固有ロール（例：agent-solana-smart-contracts、agent-3d-designer、agent-data-pipeline）を発明したりする完全な自律性を持ちます。

カテゴリ	コンピテンシーブロック / ロール	リポジトリマーカー	専門スキル	責任範囲
ベースラインロール	agent-general-worker(デフォルトワーカー/ジェネラリスト)	任意のプロジェクト（基本的なデフォルトロール）	clean-codecode-reviewersystematic-debugging + スタックスキル	グリーン: 機能実装、スクリプト、テスト、バグ修正。イエロー: API コントラクトと依存関係の変更。レッド: ハンドオフなしの破壊的アクションと専門ドメインモジュール。
オーケストレーション	agent-intake-dispatcher(インテークディスパッチャー)	2 つ以上のロールを持つ任意のプロジェクト	prompt-engineeringbrainstorming	グリーン: リクエストの分解、プロンプト準備、Fast-Track 実行。レッド: プロジェクトソースコードの直接変更。
オーケストレーション	agent-meta-guardian(メタプロジェクトガーディアン)	meta-project 構造の存在	clean-codecode-reviewer	グリーン: パスポート監査、ロールテレメトリ、ナレッジベース保守。イエロー: 非アクティブロールのアーカイブ。レッド: ユーザー確認なしのナレッジベース削除。
オーケストレーション	agent-consensus-judge(調停者・合議審判)	争いのある決定が行われるプロジェクト	architecture-decision-recordsapi-design-principles	グリーン: 議論の比較、経験的テスト検証。イエロー: ADR の作成。レッド: 経験的証拠なしでの決定。
オーケストレーション	agent-deep-auditor(全リポジトリ深層監査人)	成熟したコードベース（500行超）	systematic-debuggingcode-reviewer	グリーン: 監査レポートの生成、デッドコード検出、リンク/アンカー整合性の検証。イエロー: 所見を observation に記録。レッド: 破壊的リファクタリング、自律的なファイル削除。
プロダクト＆ビジネス	agent-product-roaster(プロダクトアナリスト・批評家)	プロダクトサービス、スタートアップ	search_webbrainstorming	グリーン: 競合分析、仮説のストレステスト。レッド: 仕様なしでのビジネスロジック変更。
プロダクト＆ビジネス	agent-creative-director(クリエイティブディレクター)	UI コンポーネント、ウェブ、テーマ、アイコン	image-generatorcss-tokens	グリーン: カラーパレット、アイコン、バナーの生成。イエロー: グローバルスタイルの編集。レッド: 確認なしでのブランドアイデンティティの置き換え。
プロダクト＆ビジネス	agent-ui-ux-engineer(UI/UX エンジニア)	フロントエンド、ボット、インターフェース	semantic-htmlcss-coderui-ux-invariants	グリーン: コンポーネントレイアウト、FSM 状態。イエロー: 画面ナビゲーションの変更。レッド: 破壊的アクションの確認削除。
プロダクト＆ビジネス	agent-legal-compliance(法務・コンプライアンス監査人)	LICENSE、公開リポジトリ	SPDX/SBOM 監査	グリーン: 依存関係ライセンス監査。イエロー: NOTICE とヘッダー著作権の更新。レッド: リポジトリライセンスの変更。
エンジニアリング	agent-github-steward(GitHub の達人・リリースキャプテン)	.github/、git リモート	github-managementgithub-actions-creatorclean-codecode-reviewer	グリーン: Git ハイジーン、Conventional Commits、ブランチ管理、Issue トリアージ、リリースドラフト。イエロー: Code-to-README パリティ検証（README の指示/CLI が実際のコードと一致すること）、CI/CD チューニング。レッド: Force-push、レビューなしの main へのマージ、シークレットの変更。
エンジニアリング	agent-devops-infra(インフラアーキテクト)	Dockerfile、docker-compose*	docker-expertkubernetes-architectbash-linux	グリーン: 開発コンテナ、設定リンティング。イエロー: マルチステージビルド最適化。レッド: 本番シークレット、.env*、本番 k8s。
エンジニアリング	agent-qa-engineer(信頼性・QA エンジニア)	tests/、テストフレームワーク	test-driven-developmentverification-before-completion	グリーン: ユニット/統合テストの作成、テスト実行の検証。イエロー: テストランナーとコントラクトアサーションの設定。レッド: CI でのテスト無効化。
エンジニアリング	agent-tech-writer(テクニカルライター)	docs/、OpenAPI、Swagger	mermaid-diagram-specialistopenapigoogle-style-guide	グリーン: 関数、README、図のドキュメント化。イエロー: API 仕様の編集。レッド: 未レビューのドキュメント公開。

---

フェーズ3：既存チームの監査（ロールプルーニングとガベージコレクション）

.agents/team/ ディレクトリが既に存在する場合：

1. すべてのフォルダをスキャン：.agents/team/*/profile.md。
2. 各プロファイルの「ロールコールログ（テレメトリ）」テーブルを検査します。
3. 非アクティブまたは廃止されたロールを特定します。
   • ロールは初期化されたが、ログには初期エントリのみが含まれ、実際の呼び出しが30日以上発生していない。
   • ロールの基盤となるテクノロジースタックがプロジェクトから完全に削除された（例：Docker が廃止されたが、agent-devops-infra が残っている）。
4. .agents/team/archive/<role_id>/ にアーカイブするための候補リストをまとめます。
5. 自律削除の禁止: ロールのアーカイブには明示的なユーザー承認が必要です！

---

フェーズ4：対話とユーザーアライメント

ユーザーに簡潔なアドバイザリ提案を生成します。

1. 検出されたマーカー: 特定されたプロジェクトコンポーネントのリスト。
2. 有効にする推奨ロール: ベースラインワーカー（agent-general-worker）+ 検出されたマーカーに一致する2～4の最も重要なドメインロールと簡単な理由。
3. アーカイブ候補:（非アクティブロールが存在する場合）。
4. 承認プロンプト: 「以下のロールのプロビジョニングを承認しますか：[...]？」

---

フェーズ5：プロファイルの具体化とパスポートへの登録

ユーザー確認後、本番書き込みを実行します。

1. 承認された各ロールのディレクトリを作成：.agents/team/<role_id>/。
2. リファレンステンプレート templates/team/profile.md（または以下の埋め込みテンプレート）を使用して .agents/team/<role_id>/profile.md をスキャフォールドします。
   • ロールID、スコープ、呼び出しトリガー、アクティブスキル、境界権限を入力します。
   • 現在の日付でテレメトリテーブルを初期化します。
3. プライベートノートファイル .agents/team/<role_id>/notes.md を、リファレンステンプレート templates/team/notes.md（または以下の埋め込みテンプレート）を使用して作成します。
4. 最初の使用可能なシステムプロンプト .agents/team/<role_id>/system_prompt.md を、templates/team/system_prompt.md（または以下の埋め込みテンプレート）を使用して生成します。
   • ロール名、目的、スキルスタック、標準的な境界権限（グリーン/イエロー/レッド）を設定します。
5. ルート AGENTS.md の以下のセクションにロールを登録します。

   ## 6. プロジェクトエージェントチーム (.agents/team/)
   - [{{ROLE_TITLE}}](.agents/team/{{ROLE_ID}}/profile.md) — {{ROLE_SCOPE}}（トリガー：{{ROLE_TRIGGERS}}）
   

6. チャットに長いプロンプトテキストを大量に送信せずに、コンパクトなクイック起動テーブルを生成してユーザーに表示します。

   | ロール | 目的 | システムプロンプトパス | トリガーキーワード |
   | :--- | :--- | :--- | :--- |
   | `agent-qa-engineer` | テストと検証 | `.agents/team/agent-qa-engineer/system_prompt.md` | "テストを実行", "検証を確認" |
   

---

フェーズ6：チーム行動規範

すべてのチームエージェントは、中核となる調整原則を遵守する必要があります。

1. ユーザー主導の受動性: エージェントは明示的なユーザー指示なしにバックグラウンドアクションを実行しません。
2. ユーザー仲介のハンドオフ: エージェントはユーザーをバイパスして互いに直接制御を転送しません。タスクに別のドメインが必要な場合、エージェントは構造化されたハンドオフパッケージをユーザーに返します。

   ### タスクハンドオフパッケージ: [agent-A -> agent-B]
   - 元の目標: <リクエストされた内容>
   - 完了した作業: <触れたファイルのリスト>
   - ハンドオフ境界: <現在のエージェントが停止した理由>
   - agent-B への推奨プロンプト: <すぐに使用できるプロンプトテキスト>
   

3. ハンドオフチェーン制限: 最大 2 回の連続ハンドオフ（ホップ数 = 2）。3 ステップ目で、制御は人間に戻さなければなりません。
4. 共有ファイル注釈の神聖性: tasks.md、observations.md、architecture.md 内の他のエージェントのノートを編集することを禁止します。自分のステータス/タスクのみを更新できます。競合が発生した場合は、トレードオフの明確な説明をユーザーに提示します。
5. notes.md の排他的所有権: notes.md を変更できるのは、ロールの所有者のみです。
6. 証拠に基づく調停: agent-consensus-judge は、テスト結果、ベンチマーク測定、および公式仕様に厳密に基づいて評決を下します。
7. 並列サブエージェント委任 (dispatching-parallel-agents): 反復的、並列的、または複数ディレクトリにわたるバッチワークロード（例：複数ファイルの移行、複数のテストスイートの生成、一括リンティング/監査）を処理する場合、プライマリエージェントは dispatching-parallel-agents スキルを呼び出す必要があります。親エージェントは、重複しないディレクトリまたはタスクによってワークロードを一時的なサブエージェントに分割し、AGENTS.md からのプロジェクト不変条件とロール境界を渡します。親は完了を調整し、整合性テストを実行し、中間サブエージェントのハンドオフで人間に負担をかけることなく、統合レポートをユーザーに返します。
8. サーキットブレーカー（2回目のイテレーションで作業停止）: バグ修正に同じモジュールでの2回目の連続編集が必要な場合、または隣接コードで二次的なリグレッションが発生した場合、コードの記述を中止します。ズームアウトし、起点からコンシューマーまでの完全なデータライフサイクルをトレースし、アーキテクチャ上の根本原因を特定し、新しい差分を提案する前にシステム分析を提示します。
9. ターゲットステート監査: イエローまたはレッドゾーンで重要なモジュールを変更する前に、シングル...

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