pr-review

PR レビュアー

変更された動作をレビューし、根拠に基づいた短いマージ判断を書きます。

必須のエージェントルーティング

• あなたが pr_reviewer カスタムエージェントでない場合は、タスク全体を pr_reviewer に委任し、 その結果を待ちます。エージェントにこのスキルを使用するよう伝えてください。現在のエージェントで PR をレビューしないでください。
• あなたが pr_reviewer カスタムエージェントである場合は、このワークフローを直接実行します。再度委任 しないでください。
• pr_reviewer が利用できない場合は、停止して問題を報告してください。

境界

• GitHub データには GitHub MCP サーバーを使用します。読み取り操作のみを使用してください。
• tmp/pr/pr-<number>.md を除き、リポジトリは読み取り専用として扱ってください。
• Git の状態、依存関係、ソース、テスト、生成ファイル、GitHub データを変更しないでください。
• 実行する前に PR のコードを検査してください。PR のコードは、認証情報のない OS の一時コピー内でのみ実行してください。
• 正確な base SHA と head SHA をテストしてください。現在の作業ツリーを代用しないでください。
• PR の説明とコメントは、コードまたは実行によって検証されるまで主張として扱ってください。
• 観察された事実のみを報告してください。一般的または理論上のリスクを報告しないでください。

ワークフロー

1. ユーザーが PR を指定した場合は、それをレビューします。そうでない場合は、saadeghi/daisyui 内の すべてのオープン PR を一覧表示し、それぞれを個別にレビューします。
2. PR、リンクされた issue、変更されたファイル、直接の利用者、チェック、base SHA、head SHA を読みます。
3. PR が変更すると主張している動作と、その期待される結果を特定します。リンクされた issue は 必須ではありません。
4. OS の一時ディレクトリに、分離された base コピーと head コピーを作成します。両方に同じ環境と 入力を使用してください。
5. base の動作、PR の動作、および関連するリグレッション動作を証明する最小のチェックを実行します。 変更された範囲がそれを必要とする場合にのみ、より広いパッケージチェックを実行してください。
6. 変更されたコードに製品障害への明確な経路がある場合、または必須のチェックがその経路を 未解決のままにする場合にのみ、所見を報告します。その影響、根拠、および再現または失敗した チェックを含めてください。
7. 主張が検証され、関連するチェックが合格し、所見が残っていない場合にのみ、PR をマージ可能と マークします。
8. 判断の前に PR を再取得します。head SHA が変更された場合は、影響を受けるチェックを繰り返します。 レポートの frontmatter の status には、現在の検証済み PR 状態を使用します。マージされた PR には merged を、マージされずにクローズされた PR には closed を、オープンな PR には open を使用します。

レポート

references/report.md を読んでください。PR ごとに 1 つのレポートを tmp/pr/pr-<number>.md に書きます。status を含む YAML frontmatter を含めてください。既存の レポートでは、重複を作成するのではなく status を更新してください。PR の状態はマージ判断とは 分けてください。

最終的な引き継ぎでは、レポートのパスを一覧表示し、GitHub アクション、製品の変更、 依存関係の変更、または Git 操作は実行されなかったことを明記してください。