maintainer-orchestrator

メンテナーオーケストレーター

複数の独立したイシュー、プルリクエスト、またはリポジトリにまたがる実際のメンテナーキューを調整します。これはコントロールプレーンスキルであり、通常のリポジトリ作業におけるデフォルトの方法ではありません。

有効化ゲート — 厳守ルール

ワーカー、ハートビート、台帳、またはキュースキャンを作成する前に、依頼を分類してください。

直接対応する単一項目の作業

依頼が、複数のファイル、フェーズ、テスト、CI、または密接に連携したリポジトリにまたがる場合でも、1つのイシュー、1つのPR、1つのバグ、1つの機能、1つのリリース、または1つの一貫した実装を指定または示唆している場合は、単一項目です。

単一項目の作業では、次のことを行わないでください。

• タスクが複雑だからという理由だけで、プロジェクトワーカーを作成しないでください。
• ハートビート、ポートフォリオ台帳、キューの補充、依存関係の一括調査、リリース提案、または広範なリポジトリスキャンを作成しないでください。
• 現在のセッションで、リポジトリの通常のスキルとワークフロー（codex-first、メンテナー／レビュー／テスト／リリースのスキル、および該当するリポジトリの指示）を使って続行してください。
• 通常の対象を絞ったサブエージェントやCodexへの委任は、引き続き通常のスキルに従います。このオーケストレーターによって追加のワーカー要件が生じることはありません。
• このスキルが単一項目に誤って呼び出された場合は、オーケストレーションモードは不要であることを伝え、直接作業を続けてください。このスキルの要件を満たすためだけに、有用な進行中の作業を決して中断しないでください。

直接対応のままとなる例：

• 1つのイシューを修正してマージする。
• 1人のコントリビューターのPRを修正する。
• アプリケーションとその依存関係にまたがって1つの障害を追跡する。
• 1つのリリースを行う。
• 2つのリポジトリにまたがる一貫したリファクタリングを実装する。

範囲を限定したオーケストレーション

次のいずれかに該当する場合に限り、オーケストレーションモードを使用してください。

• ユーザーが複数の独立したイシューまたはPRへの対応を求めている。
• ユーザーが複数のリポジトリまたは並行するワークストリームの調整を求めている。
• ユーザーがキュー、一括調査、バッチ、ポートフォリオ、メンテナー対応、または継続的なトリアージを求めている。
• 独立した項目を並行して担当し、調整することで大きな効果が得られる。

番号付きのタスクリストがあっても、自動的にオーケストレーションキューになるわけではありません。1つの成果に向けて連携するステップは、引き続き単一項目の作業です。

継続的なポートフォリオ監視

ハートビート、定期的な監視、自動キュー補充、広範なオーナースキャン、依存関係のバックフィル、および永続的なオーケストレーターログは、ユーザーが継続的／自律的なメンテナンス、監視、ポートフォリオの一括調査、または維持管理されるキューを明示的に求めた場合に限り有効になります。このスキルが呼び出されたというだけで作成してはなりません。

スコープ契約

有効化時に、明示的なキューを書き留めてください。

• 指定されたリポジトリ。
• 指定されたイシュー／PR、またはユーザーが求めた探索範囲。
• その対象セット以外で項目を発見してよいかどうか。
• 監視が一回限りか、継続的か。
• 許可されている公開アクション。

ユーザーが継続的なキュー管理を求めている場合、または明示的に対象を追加した場合を除き、指定されたバッチを無関係なリポジトリ、依存関係の更新、リリース、またはバックログの整理に拡大しないでください。

広範なポートフォリオの探索に限り、次のルールを適用します。

• steipete と openclaw、およびPeterがマージを除く主な作成者であるリポジトリをスキャンしてください。
• 明示的に指定されていない限り、アーカイブ済みのリポジトリと references/non-majority-repositories.md に記載されたリポジトリを除外してください。
• 要請されていないポートフォリオの補充対象から openclaw/openclaw と openclaw/clawhub を除外してください。
• 所有者が不確かな場合は、リポジトリ名ではなく、デフォルトブランチのコントリビューション履歴で確認してください。

ワーカーモデル

オーケストレーションモードでは、作業量に応じてワーカーを使用します。

• 2つ以上の独立した項目を調整する場合は、リポジトリごとに専用の Codex アプリのプロジェクトスレッドを1つ使用することを優先します。
• そのリポジトリ内の対象範囲のキューには同じスレッドを再利用し、分離が本当に必要な場合を除き、同一リポジトリの項目は順番に処理します。
• コーディネーター自身のコントロールプレーン作業や、範囲が限定された単一の項目のためにワーカーを作成しないでください。
• ワーカーが別のワーカーを作成または管理することはありません。階層はルートコーディネーター → リポジトリワーカーで止めます。
• コラボレーション用サブエージェントは、インベントリ作成、独立した分析、CI／ステータスの確認、照合作業を支援する読み取り専用の役割です。実装、コミット、プッシュ、PR の変更、マージ、リリース、デプロイ、実環境での検証を担当することはありません。
• プロジェクトスレッドの仕組みが利用できない場合は、不要なバックグラウンドジョブでワーカー階層を模倣せず、現在のセッションで通常のリポジトリワークフローを使用します。

保護対象の作業に着手する前に、ワーカーの実際の権限を確認してください。プロンプトに記載しただけでは、ファイルシステム、ネットワーク、認証情報、公開へのアクセス権は付与されません。

リポジトリの保全

リポジトリを割り当てる、または変更する前に、次の手順を実行します。

1. git status -sb、ブランチ、アップストリーム、HEAD、ステージ済み／未ステージの状態、未追跡の状態、ahead／behind の件数を記録します。
2. 現在の参照をフェッチします。クリーンなデフォルトブランチの場合は、早送りでプルし、引き続きクリーンな状態であることを確認します。
3. オーケストレーションを開始するためだけに、変更のある作業やデフォルトブランチ以外の作業を切り替え、スタッシュ、リベース、リセット、クリーン、削除、上書きしないでください。
4. 固有のローカル作業、それに関連する PR、およびすでに取り込まれているか、別の作業に置き換えられているかを確認し、保全して分類します。
5. 固有の作業を安全に保全または調整できない場合に限り、オーナーの判断を仰いでください。

最終的な取り込みやリリースに関する操作の前に、同期を再度行います。

キューのトリアージ

明示的に対象範囲が指定された項目ごとに、次のように分類します。

• 自律的に対応可能 — 適合性が明確で、再現可能または十分な根拠があり、実装範囲が限定され、利用可能な検証手段がある項目。
• オーナーの判断が必要 — 製品、セキュリティ、プライバシー、法務に関する重要な判断、固有の作業を破壊的に扱うこと、必要な認証情報／ハードウェアが利用できないこと、取り消せない移行、または実環境での検証に関する判断が不足している項目。
• 対応予定なし／無効 — 重複、修正済み、未対応、スパム、または依頼された製品の範囲外であることを具体的な根拠が示している項目。

コントリビューターの PR は、受け入れ済みの設計ではなく提案として扱います。症状と根本原因を突き止め、現在の動作と関連する履歴を確認し、より簡潔で範囲の限定された修正があれば書き直します。コントリビューターへの貢献クレジットは維持します。

安全な技術作業が残っている間は、オーナーに選択を求めないでください。可能な限り、実装、テスト、レビュー、CI を通して項目を準備します。

実行と公開ゲート

非公開での調査、実装、ローカルテスト、レビューは、ワーカー間で独立して進められます。

同時の変更によって曖昧さや競合が生じる場合に限り、外部に影響する操作を順番に実行します。

• 同一リポジトリまたは同じブランチ系列へのプッシュ。
• PR の作成／更新、ワークフローの承認／再実行、最終同期、マージ、リリース、公開。
• 共通の取り込みロック、または利用可能な数が限られた外部環境の使用。

別の作業レーンが後から公開ゲートに到達したことを理由に、すでに進行中の一貫した作業を中断しないでください。まず安全な区切りまで進め、その後、重複する作業が解消するまでは、新たに競合する公開操作を開始しないでください。

ユーザーの指示で許可されるのは、明示的に対象範囲が指定されたメンテナー作業と、依頼された公開手順のみです。別途依頼されていない限り、リリース、バージョンの引き上げ、タグ付け、パッケージの公開、固有の作業を破壊的に扱うこと、無関係な外部システムの変更は許可されません。

モニタリング

外部の待機ごとに担当者を 1 人割り当てます。

• リポジトリワーカーは、対象の CI／デプロイを監視する正確な仕組みを担当します。
• リポジトリ標準の監視機能を使用し、1 つの実行 ID またはヘッド SHA に対象を限定して、上限付きバックオフを適用します。
• 一貫した監視が有効な間、ルートはワーカーの状態とハーネス完了通知に依存し、ポーリングを重複させません。
• 失敗ログは 1 回だけ取得し、再利用します。
• 報告されたブロッカー、進展のない失敗の繰り返し、対象範囲またはリポジトリの誤り、破壊的または未承認の操作、セキュリティリスク、または設計の大幅な乖離がある場合にのみ介入します。
• 作業中にタスクを言い直したり、証明の基準を引き上げたりしません。

継続的なポートフォリオ／監視の依頼が明示されている場合に限り、定期的なハートビートを作成します。単発のバッチでは通常のタスク通知を使用し、スケジュールされた自動化は必要ありません。

ランディング基準

項目をランディングする前に、リポジトリ独自のゲートに加え、以下を必須とします。

• 症状の再現、または根本原因の特定
• 最適な修正方法と担当範囲の判断
• 対象を絞ったリグレッションテスト
• 変更対象に応じた十分な範囲のチェック
• リポジトリまたは外部との境界で必要な場合、ビルド／稼働中／E2E の証明
• 承認済みまたは対応可能な指摘がない、最新の自動レビュー
• 正確な HEAD に対する CI の成功
• レビュースレッドの解決と、既知の証明不足の明確な記載

リポジトリ標準のランディングワークフローを使用します。マージ後は、対象ブランチから到達可能であることを確認し、表示されているチェックアウトを同期し、リース／監視を停止して、クリーンな状態にします。

対象範囲のキューが完了した後、依存関係のメンテナンス、別の課題、またはリリースへ自動的に進まないでください。ユーザーが継続的なキューを明示的に依頼した場合に限り、キューを補充します。

OpenClaw キューモード

ユーザーが複数の openclaw/openclaw 項目のオーケストレーションを明示的に依頼した場合にのみ、このセクションを適用します。OpenClaw の単一の課題または PR は、リポジトリの通常のメンテナーワークフローに従って直接作業します。

• 最新の VISION.md、ルートおよび対象範囲内の AGENTS.md、関連する OpenClaw のメンテナー／テスト／レビューのスキルを読みます。
• トリアージとプロダクトに関する判断は、ルートコーディネーターが担います。
• 選定した順次処理キューには OpenClaw リポジトリワーカーを 1 つ使用し、PR ごとにワーカーを作成しないでください。
• 外部から報告された、Vision に沿う安定性、安全なデフォルト設定、セットアップ、認証、インストール、配信、範囲を限定したパフォーマンス／テスト基盤の作業を優先します。
• 一般的なキュー候補を選定する前に、コントリビューターの権限をリアルタイムで確認します。
• ランディングには scripts/pr のレビュー、成果物、準備、同期、マージのコマンドのみを使用します。
• OpenClaw の変更履歴はリリース時に生成されます。通常の課題／PR 作業では CHANGELOG.md を編集しません。
• リポジトリの症状に関する証明、ホスト型 CI／Testbox、自動レビュー、正確な HEAD のランディング証拠を必須とします。

オーナーの判断

準備済みの判断事項を一度に 1 つずつ確認します。各判断概要には、以下を含めます。

• 正式な完全 URL とタイトル
• 動作と影響を受けるユーザーの平易な説明
• 現時点で判断が必要な理由
• 完了済みの証明と現在の CI／マージ可能性
• 重大なトレードオフ、残存リスク、不足している証拠
• コーディネーターの推奨
• 選択肢とそれぞれの結果

URL だけを提示したり、曖昧な land/delete の選択肢を示したりしないでください。確認を求める直前に、項目とワーカーの状態を更新します。

リリース

キューの実行は、リリース権限を意味しません。

ユーザーがリリースを明示的に依頼した場合、または有効なリポジトリ固有のワークフローですでにリリースが許可されている場合にのみ、リリース計画／実行に進みます。リポジトリのリリーススキルと不変の候補版に関するゲートに従います。通常のキュー完了を、依頼されていないリリースプロジェクトへ発展させないでください。

報告

対象範囲が限定されたバッチでは、対象作業のみを報告してください。

• 進行中 — リポジトリ、項目の完全な URL、担当者／作業者、現在のフェーズ。
• 介入済み — 具体的なリスクと修正内容。
• 担当者が必要 — 事前に準備した判断事項またはアクセス上のブロッカー。
• 反映済み／クローズ済み — 動作、証拠、マージ／クローズ URL、ファイル数と LOC、リスク。
• 残り — 依頼されたキューに含まれる項目のみ。

継続的なポートフォリオモードでは、簡潔な台帳と ~/oss-orchestrator.md を使用できます。単発のバッチでは、そのログを作成または維持しないでください。

GitHub の URL は必ず完全な形式で記載してください。定期的な状況確認ではなく、意味のある進捗の変化を報告してください。