openclaw-small-bugfix-sweep

OpenClaw の軽微なバグ修正一括処理

貼り付けられた OpenClaw の issue／PR 参照をまとめて処理するワークフローです。ユーザーとの最上位の会話はオーケストレーションのみを担う親であり、その配下の範囲を限定された協力サブエージェントが実作業を担当します。親はサブエージェントを調整し、検証済みの結果を報告します。作業者は許可された場合に限り、公開または取り込みを行います。

必須のコーディネーター／作業者間の境界

• 親は、issue／PR の担当者と独立した検証作業者の割り当て、共有チェックアウト／ファイルの所有権と変更枠の調整、証拠と許可ゲートの追跡、真に必要な担当者判断への対応、および結果の報告のみを行います。
• 親は、対象項目の発見や調査、影響を受けるソース、依存関係、または兄弟ディレクトリの ../codex の読み取り、診断、編集、再現、テスト、Git／GitHub 操作、コメント、クローズ、コミット、プッシュ、CI の監視、準備、取り込みを直接行いません。運用上の手順はすべて協力サブエージェントに委任します。
• 各項目または重複／根本原因のまとまりごとに、範囲を限定した作業者を 1 人割り当てます。独立したクローズ／取り込み検証には別の作業者を割り当て、必要に応じて、発見、ソース履歴、依存関係の契約、兄弟ディレクトリのパス、回帰の証明、CI のフォローアップにも別の作業者を割り当てます。項目担当者がヘルパーを起動できるのは、ルートがその特定のヘルパーを明示的に許可し、その範囲、所有権、作業能力、完了状況を追跡する場合に限ります。項目担当者は実作業を継続し、重大な判断に関わる証拠を自ら確認してから行動します。
• 各作業者への割り当てでは、実行／検証上の役割、担当項目、ファイル／チェックアウトの所有権、変更権限、報告義務を明示します。このスキルを読み込んだ委任先の作業者は、割り当てられた作業を自ら実行します。自分をオーケストレーションのみを担う親と誤認したり、割り当て全体を再委任したりしてはいけません。
• 並行実装の前に、書き込み可能なファイル／チェックアウトが重複しないよう割り当てます。共有チェックアウト／ref／ブランチの変更、ファイルへの重複した書き込み、コミット、プッシュ、GitHub への変更、取り込みは直列化します。他の作業者のテスト実行中は、共有チェックアウトを編集しません。ユーザーから明示的な許可を得ずに、新しい worktree を作成してはいけません。全権限を明示的に委任する無人実行または取り込みの依頼がある場合は、リポジトリ管理下の PR 用 worktree と、必要な分離されたタスク所有の worktree の作成が許可されます。無関係な未コミット変更をステージ、stash、破棄、上書きしてはいけません。
• 親を含め、利用可能なエージェント枠とホスト／証明能力に応じて、作業者の同時実行数を制限します。失敗または中断した作業者を交代させる前に、その作業者が担当していた項目、パッチ、チェックアウトの所有権、証拠を保全し、未完了作業を重複させたり破棄したりせず、1 人の後任に明示的に引き継ぎます。
• 実行前にソースの信頼性を分類します。信頼できないコントリビューターのコード、スクリプト、設定、フック、テスト、ラッパーをローカルで実行してはいけません。リポジトリのサニタイズ済みリモート証明経路を使用します。重い信頼済みの証明作業は、文書化された信頼済みバックエンドのフォールバックが適用されない限り、選択したリモートボックスに回します。
• Codex を利用した動作について、技術的な判定を行う、または関連する操作を行うすべての作業者は、まず兄弟ディレクトリにある正確な ../codex ソースを自ら確認し、確認したファイル／行を引用しなければなりません。親は作業者の調査結果を伝えてもかまいませんが、別のエージェントによる調査を自分自身の判定として示してはいけません。
• 再現、修正、独立検証、正確な HEAD に対する CI、許可されたクローズ／取り込み、検証済みの最終状態まで、作業者の担当を継続させます。チェックが保留中、または変更を送信済みであることは完了を意味しません。フォローアップを委任します。

これは openclaw-autonomous-issue-sweep が使用する協力サブエージェントのモデルであり、ユーザー所有の Codex アプリタスクを作成したり、親との会話で一括処理を実行したりするよう促すものではありません。

範囲と認可ゲート

この調査は、根本原因が高い確度で特定できる小規模な修正に限定してください。一貫性のあるオーナー境界の整理やリファクタリングが適切な修正である場合、回避策で代用しないでください。その修正が明示された調査範囲を超える場合は、エスカレーションしてください。

修正が許可されている場合のデフォルトの流れ：

1. 現在の動作と根本原因を証明できるだけ十分に、各問題を詳しく調査します。
2. オーナー境界の修正が依頼された小規模な調査範囲に収まる、確度の高いバグだけを修正します。
3. 公開または取り込みの明示的な許可がない場合は、未コミット差分の概要、変更したファイル、テスト／ゲートの結果をまとめて、メンテナーの確認に回します。
4. リリースが許可されている場合は、受け入れられた修正ごとに1つのコミットを作成し、ユーザー向けのリリースノートに関する内容をPR本文またはコミットメッセージに記載します。リリース専用の CHANGELOG.md は決して編集しないでください。
5. 許可されている場合は、取り込み先に合わせて同期します。main に直接反映する場合は、マージコミットを作成せず、最新の origin/main にリベースする必要があります。PRではネイティブの取り込みゲートに従い、実際の競合、ゲート／厳密なHEADチェックの失敗、ユーザーからの明示的な依頼、または実証された重大なベースブランチの古さがある場合に限り、更新／リベースしてください。main が進んだというだけの理由では行わないでください。プッシュし、証拠を添えてコメントし、修正済み、または明示的にトリアージしてクローズすることが許可された課題だけをクローズします。

名前が指定された課題／PRの一括処理や解決、または修正して取り込むことを明示的に依頼された場合、その依頼は、担当ワーカーが対象範囲内の根本原因修正、コミット、プッシュ、PRの更新、証拠コメント、現在の main 上で修正済みであることを証拠に基づいて確認したクローズ、および指定項目を解決するために必要な厳密なHEADでの取り込みを行うことを許可します。修正のみの依頼では、ローカルでの変更と証拠の提示は許可されますが、公開や取り込みは許可されません。レビュー、トリアージ、一覧表示のみの依頼は読み取り専用です。無関係な修正を1つのコミットにまとめたり、無関係な項目を変更したり、依頼された調査範囲を超えたり、オーナー、セキュリティ、信頼、認可、証拠に関するゲートを迂回したりしてはいけません。個人的なレビューという追加ゲートを勝手に設けないでください。

明示的な全権限での無人実行許可がある場合、担当ワーカーは、タスク範囲内で証拠に基づく調査、修正、クレジットを維持したPRの書き換え／置き換え、証拠コメント、CIの診断／修正／再実行、タスク所有の公開／ワークツリー、現在の main 上であることが実証された項目のクローズ、依頼されたネイティブな取り込み、リモートでの最終確認をすべて完了できます。利用できないユーザーに確認を求めず、通常の判断は自律的に行ってください。一時的な障害やロックからは安全に復旧してください。無関係な編集、厳密なHEADで必須のCI、ソースの信頼性、作業者本人による直接のCodex調査、貢献者のクレジット、セキュリティ／オーナーのゲートを維持し、50件を超えるクローズには、正確な件数と範囲に対する個別の許可を得てください。ユーザーが利用できない任意のプロバイダー／チャネルのライブ証明を明示的に緩和した場合に限り、焦点を絞った、失敗／成功を示すオーナー境界の回帰テスト、プロデューサー／呼び出し元／同種処理／依存関係の直接的な証拠、独立したレビュー、厳密なHEADで成功したCIを代替として使用できます。その場合、ライブ証明／順位引き上げの証拠がないことを明示してください。必須の外部API、セキュリティに関わるもの、リスク上必須のもの、または依頼されたライブ証明は、決して免除しないでください。ユーザーを待たず、実際の認証情報、機能、または明示された安全性に関するブロッカーだけを報告してください。

関連スキル

まず $gitcrawl を使用し、ライブなGitHubの管理には $openclaw-pr-maintainer、ソースの追跡には $github-deep-review の方針、証拠の取得には $openclaw-testing を使用してください。

ループ

各 ref について、担当ワーカーが作業ループを実行します。親は進捗を調整し、証拠を受け取るだけです。

1. gh で最新の対象を読み取ります。
2. gitcrawl で関連するスレッド、重複したスレッド、クローズ済みのスレッド、またはすでに修正済みのスレッドを確認します。
3. 必要に応じて、本文、コメント、リンクされた ref、変更ファイル、現在のコード、隣接するテスト、依存関係の契約を読み取ります。
4. 実際のランタイムパスを追跡します。
5. 現在の main ですでに報告された不具合が修正されている場合は、現在のソース／テストと正式なコミット／PRで証明します。fixed-on-main に分類し、証拠を添えてコメントし、許可されている場合にのみクローズします。
6. 未解決であることが確認できた Issue については、違反されている不変条件を、その所有者の箇所で修正します。根本原因への対処として最も適切であれば、小規模で一貫性のある整理／リファクタリングも含めます。
7. PR については、不具合、所有者境界での修正、関連する経路、正確な head に対するチェックを独立して検証します。不十分な編集可能 PR は、修正／マージが許可されている場合に書き直します。それ以外の場合は、必要な修正を報告します。
8. ローカルでの Issue 修正や PR の準備状況確認では、可能な場合、対象を絞ったリグレッションの証拠を追加します。
9. 意味のある最小限のゲートを実行します。
10. 貼り付けられたすべての ref が修正済み、解決済みの証明済み、マージ済み、または具体的なブロッカーに分類されるまで続けます。

独立したワーカーは、許可された担当者が最終変更を行う前に、提案された fixed-on-main のクローズと、重要な修正／マージの証明に異議がないか検証します。必要な合意、該当するソース／依存関係の証拠、正確な head に対する CI、信頼性に応じたルーティング、所有者の承認、または許可が不足している場合、それは具体的なブロッカーです。親が作業を引き継ぐ許可にはなりません。

対応を見送る場合

• バグではない
• 設定／ドキュメント／ワークフロー／リリース／サポート／依存関係／製品に関する作業
• 再現方法または根本原因が不確か
• 適切で一貫性のある根本原因の修正が、明示的に依頼された小規模な一括対応の範囲を超える場合。回避策をマージするのではなく、needs-human に分類するか、担当者を明記したフォローアップを記録します
• 依存関係の挙動を推測している
• 対象を絞った証明が現実的でない

簡潔な理由を添えて対応を見送ります。確度の低い修正で内容を水増ししないでください。

修正ルール

• まず所有者モジュールを修正します。汎用的な境界の修正は必要な場合に限ります
• 既存のパターン／ヘルパー／型を使います
• 所有者境界内で一貫した整理／リファクタリングを行います。無関係なついでのリファクタリングはしません
• 本番コードの LOC は現状維持または削減を優先します。テストは別に数え、有用なリグレッションカバレッジを追加します
• テストは失敗する箇所の近くに置きます
• 公開動作を変更した場合に限り、ドキュメントを更新します
• レビュー／証明のみの作業ではコミットしません
• 提出が許可されている場合、採用された修正ごとにコミットを1つ作成します。ユーザー向けリリースノートの内容は PR 本文またはコミットメッセージに記載し、CHANGELOG.md には記載しません
• その操作の許可なしに、プッシュ／PR 作成／コメント／クローズ／ラベル付け／提出／マージを行いません

PR ルール

• ready-to-merge：根本原因の修正が適切で、現在の head が検証済みで、必要な正確な head に対するチェックが成功しています。マージが許可されている場合に限り、リポジトリ標準の提出ワークフローを使います
• needs-ci：証明は妥当ですが、必要な正確な head に対するチェックが未完了または利用できません。マージの依頼が許可されている場合は、それらのチェックを監視し、成功したら提出を完了します。そうでなければ、具体的な外部ブロッカーを報告します
• needs-fixup：許可されている場合は、編集可能な PR を修正／書き直します。それ以外の場合は、必要なファイル／テストと不足している許可を具体的に列挙します
• skip：古い、推測に基づく、明示的に対象範囲外、または利用できない製品／セキュリティ／リリースの承認が必要
• 有用なソース PR が安全でない、または編集できない場合、代替 PR は明示的に許可されている場合にのみ作成します。貢献者のクレジットを保持し、代替 PR の作成後に限り元の PR をクローズします

出力形式

台帳：fixed-local、fixed-on-main、closed-fixed-on-main、ready-to-merge、needs-fixup、needs-ci、landed、skipped、needs-human。 各項目の担当ワーカー、独立した検証者、担当ファイル／チェックアウト、証拠、正確な head、許可、最終状態を記録します。 最終報告：ワーカーが検証したローカル修正または提出済みの修正、すでに修正済みであることを証明した項目、本番／テストの LOC 差分、テスト／ゲート、具体的なブロッカーまたは対応を見送った理由。