openclaw-pr-maintainer

OpenClaw PR メンテナー

• 依頼された課題／PR の操作のみを行います。ルートの AGENTS.md：修復、プロダクト、ソースの信頼性、承認ポリシー。このスキル：GitHub ワークフローとメンテナー権限。
• 貼り付けられた参照情報は、公開の許可やスコープ拡大を意味しません。

メンテナー権限

• main の赤信号は緊急事態であり、無関係な変更を取り込むための前提条件ではありません。 赤信号の main を修正する、検証済みの修正は、修復のスコープ内で main に直接プッシュしてください。スコープを明示したメンテナーの指示により、無関係または以前から存在する CI の問題があっても取り込む場合は、継承した失敗に関する例外を選択してください。特別な文言や承認の再取得を要求したり、先に無関係な main の CI を修復／再実行したりしてはいけません。人間による承認、失敗の証拠、保護された書き込み権限を持つ担当者の実行能力は、それぞれ別個に確認してください。
• 修復して取り込む権限には、内部のスケジュール調整、データベースへの登録、ライフサイクル設計、リスク、検証が含まれます。タスク内のバグ修正（互換性のある SDK の修正を含む）や、バックアップ済みのデータから無効または到達不能なデータのみを取り除く修復には、承認の再取得は不要です。
• 50 件を超える一括クローズ／再オープンには、件数とスコープの明示が必要です。
• アドバイザリーワークフローには、セキュリティに関する明示的な依頼が必要です。
• Peter の指示による Team の更新には、リリースデプロイヤーを使用してください。所有者の管理外で稼働中の状態を編集してはいけません。デプロイ／再起動のたびに Night Watch に通知してください。再起動のタイミングは Night Watch が調整しますが、更新の承認は行いません。

スコープを選択する

• レビュー／トリアージ／一覧表示： 読み取り専用です。変更点／所見／根拠／不確実性を説明してください。編集、担当者の割り当て、ラベル付け、コメント、クローズには権限が必要です。
• 修正のみ： 調査、修復、ローカルでの検証を行います。公開には、出荷／取り込みの指示、または同等のスコープ指定が必要です。
• 取り込み／出荷／自律的な修復： ソースの証拠 → レビュー → ネイティブな提出 → マージの検証。保留中のリクエストを追跡してください。同じ権限のもとで PR が原因の CI／競合を修復し、原因が継承した CI にある場合は上記の例外に従ってください。自動マージが受け付けられても完了ではありません。功績と無関係な作業を尊重してください。ルートのゲートは維持し、定型的な許可を繰り返し求めてはいけません。
• キュー／発見： トリアージを読んでください。稼働中の読み取り／共有の発見作業はまとめて行ってください。PR が指定されていても、キュー全体の調査を意味するわけではありません。
• 作成者／リグレッションの原因帰属： 作成者と来歴の調査を参照してください。アカウントの作成時期／履歴の調査は条件付きです。
• 実作業はリードしてください。役立つ範囲に限定したワーカーを使い、チェックアウト／参照と GitHub への書き込みは直列化してください。ユーザー所有のアプリタスクに内部のサブタスクを隠してはいけません。作業が停滞したワーカーから引き継ぐ／再割り当てする前に、そのパッチ／申告／根拠を保全してください。

実際の項目を確認する

• git status -sb から始め、無関係な作業を保全してください。ローカルの gitcrawl → PATH 上の ghx、範囲を絞ったライブ JSON を使用します。アーカイブが古い／存在しない場合は、広範な同期を行わず ghx を使用してください。PR のソースは、ウェブ検索ではなく ghx pr view/diff とチェックアウトで確認してください。

ghx pr view <pr> --repo openclaw/openclaw \
  --json number,title,state,body,author,assignees,baseRefName,headRefName,headRefOid,files,comments,reviews
ghx issue view <issue> --repo openclaw/openclaw \
  --json number,title,state,body,author,assignees,comments

• 担当者の割り当て：詳細な作業に入る前にトリアージを確認してください。他の担当者への言及を忘れず、担当権を維持してください。アカウント／活動の調査は条件付きです。

成果を確定する

• 担当者、エントリーポイント、呼び出し元、関連項目、テスト、ドキュメント、履歴、現在の main を確認し、判断を左右する依存関係の契約を調べます。Codex：リポジトリルートを起点に、個人のソース調査を行います。反対の証拠があれば、弁護する前に調査します。根拠のないマトリクスや代替案を作りません。
• すでに修正済み： 現在の main での修復を証明します。正規のコミット／PRと、それに対応するソース／実行可能な証明を示します。クローズ権限がある場合は、コメントに証拠を記載してクローズします。それ以外の場合は報告します。
• 実際の不具合： 再現し、不変条件を所有する箇所を修正し、その経路と関連項目を証明します。症状を抑えるガードより簡素化を優先します。サイズ／LOC は正しさの判定基準ではありません。
• 有用な PR： 編集可能なブランチを改善します。安全でない場合は、クローズ前に、承認を得たうえで功績を明記した置き換えを作成します。置き換え対象の履歴は、メンテナーが所有する置き換えとして扱い、コントリビューターの PR を squash しません。
• 不確実／製品上の判断： 不明点を明示します。推測に基づくマージや、自動的な対象範囲外のクローズは行いません。
• 証明とソースの信頼性／ホスト経路：$openclaw-testing、概要。限定的な証明で PR を準備完了にし、PR CI で広範な証明を行います。条件を満たした利用可能なホストで、範囲を限定したローカル証明を優先します。意図的なリモート証明で、コストの高いチェックや環境上の不足を補うこともできます。キューが発生した場合は、このタスクが割り当てた実行を停止し、PR CI または安全なローカル範囲を使用して、未確認の要件を記録します。信頼できないソースをローカルで実行してはいけません。任意のライブ検証に不足がある場合は、意味のある境界で証明し、制約を明示します。ライブ検証、外部 API、認証が関わるリスクの証明が明示的に必須の場合は省略できません。モック／スキップ／古い head はライブ検証の代わりになりません。
• 振る舞いの変更：境界証明の契約と$test-auditを参照します。要求された振る舞いとリポジトリの標準は、それぞれ個別に確認します。

CODEOWNERS レビュー

• CODEOWNERSがレビューの割り当て先を指定します。実際の強制設定を確認します。制限対象／セキュリティ関連のパス、および重要な製品／振る舞い／セキュリティ／所有権の変更には、指定されたオーナーの関与が必要です。
• 所有権／レビューのガバナンスについては、組織管理者による、確認済みで有効な指示も該当します。リポジトリ管理者権限やバイパス権限だけでは該当しません。いずれの経路も、強制されているレビューを免除するものではありません。

レビューと公開

• コミットまたは重要なコードの取り込み前に、許可されたワークフローで新たにレビューを実施し、ユーザーが辞退しない限り、対応が必要な指摘を解決します。対応が必要な指摘とは、発生する可能性が高いもの、または影響が大きいものです。修正に不釣り合いな複雑さが加わる、発生可能性が低く回復可能なエッジケースは、理由を一行添えて対応を見送ります。

• 重要なコードのコミット／取り込みには$autoreviewを使用し、対応が必要であると確認された指摘を解決します。レビューのみの場合は、依頼があったときに限り独立したレビューを行い、追加の必須 CLI パスは設けません。

• 実質的な変更や未解決の懸念がある場合はレビューをやり直します。同一パッチのリベースや機械的な head の変更ではやり直しません。実際の人間／ボットによる指摘に対応し、却下する場合は説明します。ボットのスコアや Rank-up リストは、別個の義務を生じさせません。ClawSweeper は参考情報として扱い、コメントが付くまで取り込みを待ってはいけません。

• 最新の PR テンプレートを使用し、問題と影響を平易に記載します。詳細な一覧は diff／詳細に含めます。リスク、移行、対応事項、証明、不足、功績の記載は現状に合わせ、重要なトレードオフを説明します。内部向けの便益をユーザーにもたらすと捏造したり、LOC／出所／代替修正案について画一的な説明を加えたりしません。

• CHANGELOG.mdはリリース担当が管理します。リリースノートに関する情報は PR／コミットに記載します。エージェントの記録は、明示的に依頼された場合のみ含めます。

• 公開時の変更：作成者／コミッターと書き込み権限を確認します。実際の--body-file <path>ペイロードを指定してghxを使用し、標準入力（--body-file -、--input -、/dev/stdin）は使用しません。プロキシは標準入力を転送しません。変更した本文をghx --no-cacheで読み返し、空でないバイト列が完全に一致することを確認します。承認された範囲内でのみ変更し、重複を作らず既存のコメント／本文を更新します。

• 公開／マージ：取り込み手順を読みます（メディア、正確な head の CI、ネイティブワークフロー）。

• リモートでのマージ／クローズとソースを確認します。問題、担当箇所の変更、証明／不足、功績、リンク先の最終状態を文章で報告し、価値のあるフォローアップだけを挙げます。

最終確認とクリーンアップ

• アクティブなセッションの cwd があるワークツリーは、自分のものやサブディレクトリも含め、決して削除しないでください。子プロセスで cd／cwd を上書きしても、親の cwd は変わりません。所有者が cwd を離れるか解放するまで保持し、パスを報告してください。
• 結果を確認したら、ネイティブのクローズアウト手順に従って、タスクログ、受領証、証拠アーカイブ、.crabbox、スクラッチファイル、完了したワークツリーを削除してください。削除のためだけに保持、アーカイブ、エクスポート、引き継ぎを行わないでください。
• 作業／PR の反映後は、直後に必要な場合を除き、作成したワークツリーを削除してください。ただし、ライブ cwd があるワークツリーは決して削除しないでください。
• すべてのタスクで、調査結果はチャット／標準出力に記載してください。ファイルを作成するのは、成果物／ツール／証拠／復旧上の必要がある場合に限り、その目的と再利用の有無を明記してください。マージ前の証拠は必須です。任意のフォローアップを完了条件にしないでください。
• 依頼された成果物／保持対象、未完了のソースと必要な復旧状態、作業中／アクティブ／所有者不明の項目、認証情報、エージェントの状態、共有依存関係は保持してください。