review-pr

アカウント名義で投稿する、高精度な自律型 PR レビューです。網羅性よりも精度を重視し、自分の名前を付けて公開できるレビューを目指します。

入力。 引数の pr-url、または現在のブランチの upstream PR を使用します。--manifest <path> を指定すると、スキルはマニフェストモードに切り替わります。このモードでは汎用レビュアーフリートをスキップし、マニフェストの契約のみを検証します。作成者の意図をフリートに反映するだけではありません。このモードでのみ、検証方法を確認するため references/MANIFEST_MODE.md を読み込みます。--manifest を指定しない場合、このリファレンスは読み込まれず、汎用の review-code フリートでレビューを実行します。このスキルは、フォルダーの慣例からマニフェストを自動検出しません。--bundle <urls> と、PR の説明に記載されたリンク付き PR の解析（Depends on #N、Stack:、Co-changes:、GitHub PR URL）により、連動する変更のコンテキストを取得できます。実施内容を決める前に、PR、現在の head SHA、自分が過去に投稿した GitHub レビュー／コメント／返信、未解決のレビュー スレッド、作成者のコミット、PR の説明、およびリンク付き PR のコンテキストを確認してください。

レビューの進め方。 必要な調査はこのセッション内で実施するか、有用であれば別のコンテキストに委任してください。関連する作業は同じコンテキストで行ってもかまいません。別のコンテキストは、独立した判断、切り分け可能な作業、大量の読み込みに役立つ場合があります。その機能がない場合は、インラインで作業してください。作業をどこで行うかによって、各スレッド、観点、ゲートに必要なレビュー範囲、スキルの基準、結果が変わることはありません。独立したレビューを明示的に求められた場合はそれに従い、実際に使用したコンテキストを報告してください。独立性がなかったのに、作成者から独立していると主張してはいけません。

自動投稿の識別。 自分のアカウント名義で投稿すると、人間のレビュアーも同じアカウントを使うため、投稿者名だけでは自動コメントと人間のコメントを区別できません。このスキルが投稿するすべての本文（新しい指摘コメント、スレッドへの返信、概要ヘッダー、承認本文、マニフェストモードの PASS／FAIL）には、末尾に非表示マーカー を付けてください。これは固定のリテラル文字列であり、review-pr の実行環境が異なってもバイト単位で同一でなければなりません（配布先ごとに名前空間を書き換えてはいけません。そうすると、あるホストが投稿したコメントを別のホストが照合できなくなります）。GitHub のレンダリング済みコメントではこのマーカーは非表示になりますが、API 経由では取得できます。アカウント名義ではなく、このマーカーによってコメントが自動生成された review-pr のコメントだと判別します。このスキルで「自分が作成または返信したスレッド／コメント」（または「過去に自分が投稿した」レビュー／コメント）と記載されている場合は、すべてこのマーカーが付いたものを指します。マーカーのない自分のアカウントのコメントは人間のコメントとして扱い、変更しないでください。マニフェストモードでは、マーカーに基準 ID を追加します（`references/MANIFEST_MODE.md`）。判断パスの指摘には `judgment` トークンを追加し、 とします。これにより、どちらのモードでも過去の判断パスの指摘を通常の review-pr コメントと区別できます（PR ごとに一度だけ通過できるゲートは、このトークンを基準にします）。

ワンショットパス

--loop を指定しない場合も含め、呼び出しのたびに PR の状態を一度完全に進めます。

1. 既存のスレッドを進めます。 自分が作成または返信した未解決スレッドごとに、以下のスレッド単位の検証を実行します。必要なスレッド返信を投稿し、終了したスレッドを解決し、実際に保留中のスレッドは開いたままにします。
2. 変更を検証します。 マニフェストモード（--manifest）：references/MANIFEST_MODE.md を読み込み、その手順に従って PR のヘッドに対するマニフェストの契約を検証します。汎用レビュアーフリートは完全にスキップされます。マニフェストなしモード： レビュー範囲に対して汎用レビュアーフリートを実行します。レビュー範囲は永続的な GitHub の状態から決定します。この PR で過去にレビューしており、その後ヘッドが移動している場合は、そのレビューのコミット／ヘッド SHA を下限として、last-reviewed-by-us..current-head をレビューします。それ以外の場合は、PR の差分全体をレビューします。後続の --loop の起動では、references/LOOP.md に従い、その呼び出しのチェックポイントを使用します。どちらのモードでも、1 PR あたりの生成ルールで許可される場合は、判断パス（以下）を含めます。
3. 結果を投稿します。 新たに残った指摘は、decision が comment の GitHub レビューとしてまとめて送信します。スレッドへの返信は新しいレビューコメントではなく、既存のスレッドに投稿します。最後に、以下のサイクル概要を記載します。

各呼び出しは GitHub の状態と現在のチェックアウトを基に開始します。

呼び出しのたびに、必ず変更を検証します。 再度 review-pr を実行するかどうかはオペレーターの判断です。多くの場合、リスクのある変更を別のモデルで再確認する価値があります。そのため、すでにレビュー済みで、その後変更がない場合でも、新しい呼び出しではヘッドをレビューします。その場合、レビュー範囲は PR の差分全体です。以下のプルーニングにより、今回新たに追加できる内容だけに絞られます。単に同意するだけの再レビューでは、何も投稿されません。

変更のないヘッドをスキップするのは、--loop の初回パス後の起動だけです（references/LOOP.md）。この場合、誰も判断をやり直しておらず、起動のたびに 1 コミットを再レビューする煩わしさを防ぐために、このチェックが設けられています。

スレッド単位の検証

自分が作成または返信した未解決スレッドごとに、review-pr-thread-verify スキルを呼び出します。そのスレッドの根拠を渡してください。

• 元の指摘：アンカー、本文、レビュー時のコミット／ヘッド SHA、具体的な懸念点。
• 自分が最後にメッセージを送って以降の、このスレッドにおける投稿者からの返信すべてと、自分がこのスレッドに以前投稿した返信すべて。
• アンカー位置の現在のコードとその周辺のコンテキスト、および元のレビュー以降に該当範囲に触れたコミット。
• PR の全履歴：すべてのコメント、レビュースレッド、コミットメッセージ、現在の PR の説明、自分が以前投稿したレビュー／コメントの本文。
• 関連付けられた PR ごとのコンテキスト（最大 5 件）：差分、説明、トップレベルの会話。
• 返信案を作成する場合は、以下のボイスプロファイル。

返される内容は、判定が 1 つ、短い理由、そして判定で必要な場合は返信案のみです。その内容に従って対応します。addressed-by-fix → スレッドを解決し、返信案が作成されている場合に限り返信を投稿します。addressed-by-valid-reply → 譲歩を投稿してから解決します。false-positive-or-stale → 訂正を投稿してから解決します。needs-our-pushback → 既存のスレッドに返信を投稿し、保留状態のままにします。still-pending → スレッドを開いたままにし、何も投稿しません。 レビューフリート。 マニフェストなしモードのみ。マニフェストモードでは完全にスキップします（references/MANIFEST_MODE.md）。レビュー対象範囲に対して、必要な各観点ごとに review-code スキルを有効化します。レビューが同じコンテキストを共有していても、各観点の指摘と判定はそれぞれ保持します。常時適用する観点：change-intent、code-bugs、code-design、code-maintainability、code-simplicity、context-file-adherence。差分が該当する場合は追加します：型付きコードでは type-safety、ソースコードでは test-quality と code-testability、API サーフェスでは contracts、CI／インフラ／環境／マイグレーション／ワーカー／キュー／シークレットでは operational-readiness、文章では docs と prose-value、レビュー対象範囲が不具合を修正する場合は defect-class。これは修正による保護と影響箇所の網羅性を評価するため、何も修正しない変更には適用しません。それに該当するかどうかは、あなたが判断します。PR の説明、コミット、リンクされたイシューを使って、不具合が修正されるかを確認してください。プロンプト／スキル／エージェントの場合は、同じ方法で review-prompt スキルを有効化する実行も追加します。

根拠と範囲。 各観点は、それぞれ固有の基準に集中させます。拘束力のある要件、明示的な除外事項、権限の制限を使って範囲を判断し、許可された修正を評価できるよう、それらを defect-class に伝えてください。作者の実装上の好みは、そのような制限には該当しません。コードと関連する根拠を確認してください。作者の説明や成功報告だけでは、動作が正しいとは証明できません。前提を評価するには、判断パスで、明示された問題点と PR 全体のコンテキストも確認する必要があります。

全体整合性の確認。 必要なすべての検査が完了した後、それぞれの指摘を集めます（defect-class の指摘を除き、Low の重大度は除外します。観点と重大度は保持します）。review-pr-holistic スキルを呼び出します。根拠または権限が不足している BLOCKED 判定は、その不足内容とともにサイクルの要約に残してください。統合によって、不完全な評価を問題なしの結果に変えることはできません。保持した指摘に加え、次の情報を渡してください。

• PR 履歴：PR 上のすべてのコメントとスレッド（過去のレビューで私たちが投稿したものも含む）、ブランチ上で作者が最近作成したコミットのメッセージ、PR の説明。
• リンクされた各 PR の関連情報：差分、説明、トップレベルの会話。リンクされた PR のインラインレビューコメントは含めません。
• この実行でレビューした範囲 — フリートの不具合指摘が対象とするコード。
• 判断パスの指摘（下記の PR 全体の評価から）。フリートの指摘と併せて統合しますが、Low の除外とレビュー対象範囲による限定の対象外です。判断パスは PR の head 全体を確認するため、その指摘はすでに PR 全体を対象としています。
• 呼び出し元が行った切り捨てがあれば、そのすべて。
• 以下の文体プロファイル。

このスキルは、PR ですでに対応済みの指摘を除外し、レビュー担当者間で重複を排除し、同じサーフェスに関する判断上の問いの下に不具合指摘を従属させ（前提への包含）、不具合指摘をレビュー対象範囲に限定し、各指摘に根拠を示し、すべての本文を文体プロファイルに沿って書き直します。投稿するコメント（アンカーと文体に準拠した本文）、必要に応じて要約ヘッダーのテキスト、切り捨てに関する注記、主な理由を添えた却下指摘の簡潔な集計を返します。 判断パス（前提の確認）。 両方のモードで実行されます。マニフェストモードでは、references/MANIFEST_MODE.md を介して組み込まれます。統合する前に、独立した評価として review-pr-judgment スキルを有効にします。これは広いコンテキストを対象とし、PR の説明、会話、コードベースの方針、リンクされた PR のコンテキスト（差分、説明、トップレベルの会話）、およびPR ヘッドの全差分（base..head、PR 全体）を入力として受け取ります。そのため、レビュー範囲が直近の差分のみである段階的なパスやループパスでも、PR 全体を俯瞰した視点を維持できます。解決しようとしている課題に照らして変更に価値があるかという、PR 全体に関する問いを、具体的な証拠がいずれかのトリガーに該当する場合にのみ提示します。検出事項は重大度とは別のクラス（{trigger, evidence, author-facing question}）です。判断パス自体が、返す前にルートごとに質問を 1 つにまとめます（そのため、全体性パスに関係なく、両方のモードでこの動作が保たれます）。マニフェストなしモードでは、検出事項はその後、上記の全体的整合性パスに渡されます。質問は、同じ文体、自己識別マーカー、単一のまとめられた comment レビューを通じて、作成者が回答できる形で投稿されます。判断パスが処理をブロックしたり、request_changes を送信したり、自動承認したりすることはありません。

PR ごとに 1 回。 新たな判断の生成は、PR 上に以前の判断マーカー付き検出事項（``）がない場合にのみ行われます。確認には、セッションメモリではなく、永続化された GitHub の状態を使います。そのため、パスが質問を投稿した後の実行では再生成をスキップし、しつこく繰り返しません。識別トークンがあることで「以前に判断の検出事項が存在する」ことを検出できます（ベースマーカーだけでは検出できません。すべての review-pr コメントに付くためです）。これは判断パスの性質に合っています。不具合の検出は新しいコミットごとに各ラウンドで再実行しますが、前提に関する問いには人が一度回答すればよいため、毎ラウンド再投稿することは、このパスが避けようとしているしつこい催促になります。既存の判断スレッドを進めること（スレッドごとの検証による返信や解決）は、この制限の対象外です。制限されるのは新たな生成のみです。妥当な制約は 2 つあります。（1）パスが何も投稿せずに終わった場合、判断マーカーは投稿されないため、そのパスが問題なしと判断した PR では、後続ラウンドでも再実行される可能性があります。これは範囲が限られており、無害です。何も投稿しないため催促にはならず、PR 全体の確認にかかるコストも、フリートが各ラウンドですでに負担しているものと同じです。（2）質問の投稿後に追加された遅いコミットによって前提に関する懸念が生じても、再検出されません。ほとんどの前提上の問題は最初の PR から確認でき、毎ラウンド再スキャンするのはノイズになるためです。

文体。 各コメントは 1 つの考えに絞ります。問題を述べ、証拠を本文中に示し（重要な場合はファイルと行番号、短いコード抜粋）、修正方法を提案します。率直かつ具体的にし、婉曲表現は使いません。

投稿する本文、ヘッダー、スレッドへの返信では、重大度ラベル（[High]、⚠️、Critical:）、あらゆる種類の絵文字、修辞的なエムダッシュ表現（「X だけでなく、Y でもある」／「A だけでなく、B も」）、婉曲表現（「私はそう思います」「おすすめします」「〜のようです」「〜をご検討ください」）、定型的な書き出し（「素晴らしい PR です！」「良い変更ですが……」）、"at the location above" / "as mentioned"（必ずファイルと行番号を本文中に明記）、AI に関する開示フッターは使いません。

構成の基本方針：提案が 1 つの場合は、箇条書きではなく文章にします。コメントが 1 つの考えである場合、Markdown の見出しや要点の太字強調は使いません。コメントが複数の異なる考えや並列項目を扱う場合は、見出しや箇条書きを使ってもかまいません。

目標とする文体："空の入力では null チェックがスキップされます。parser.ts:42 の if (input?.value) は parser.ts:47 のパースより前に短絡評価されるため、ガードなしで {} が parse() に渡されます。条件を if (input?.value != null) に変更するか、既存の分岐の中に parse() の呼び出しを移してください。"

投稿。 全体性パスが投稿用コメントを返した場合は、すべてのコメントをまとめてアトミックに送信するため、decision が comment の GitHub PR レビューを 1 件送信します。CI または非対話型の環境では、承認を待たないでください。 投稿するコメントがゼロの場合。 全体的なチェックで何も返されず、BLOCKED なしですべての必須観点を完了し、既存のスレッドがすべて最終的な処理に至っている場合は、問題なしと報告します。それ以外の場合は、未解決の評価上のブロッカーを示して未完了と報告し、独立したレビュー作業を続け、承認は提示しないでください。問題なしの場合に限り、対話型セッションでは次のように尋ねます："Looks good to me. Post as approval on the PR?"。承認する場合は、本文を Looks good to me. として決定 approve を送信します。承認しない場合は、PR に対する操作を行いません。CI または非対話型のコンテキストでは、承認操作を行いません。

サイクルの概要。 コメントを投稿したか、スレッドを解決したか、承認を尋ねたか、何もすることがなかったかにかかわらず、ワンショットの各パスでは、必ずオペレーター向けの概要を出力します。簡潔でありながら、必要な情報をすべて含めてください。

• 使用したレビューコンテキスト、レビューした範囲／ヘッド、および実施した具体的な PR 操作：新規レビューコメントの数とアンカー、スレッドへの返信、解決したスレッド、承認の確認／操作、または PR に対する操作なし。
• このパスで、すでにレビュー済みのヘッドを再レビューしたか、新しい差分をレビューしたか。再レビューの場合は、新たに見つかった指摘と、すでに対応済みとして除外した指摘の内訳。これだけが、内容に同意した二度目のレビューと、レビュー自体が行われなかったケースを区別する情報です。
• スレッドごとの検証：各スレッドについて、アンカー、処理状況、検証担当者による簡潔な理由を 1 行で記載します。
• レビュアー陣（マニフェストなしモード）：実行した各観点について、判定、対応可能な指摘の数と内容、または none を 1 行で記載します。BLOCKED の場合は、不足している証拠または権限を示します。マニフェストモードでは、代わりに references/MANIFEST_MODE.md に従って、基準ごとの検証結果を報告します。
• 全体的な整合性チェック（マニフェストなしモード）：残ったコメント、重複の除外／統合、主な理由ごとに整理した削除対象の指摘、範囲を定めた判断、サマリーヘッダーがあればその内容、切り捨てに関する注記。
• 判断パス（マニフェストなしモード）：投稿した前提に関する質問の数とその根拠、または none。マニフェストモードでは、references/MANIFEST_MODE.md に従って報告します。

サイクルの概要は、オペレーター向けのトランスクリプトまたは実行ログ専用です。PR レビュー本文、スレッドへの返信、承認文には貼り付けないでください。投稿してよい、概要に類するテキストは、全体的なチェックで返された、指定の文体に準拠したサマリーヘッダーだけです。

投稿の境界。 承認には、上記の明示的なユーザー確認済みの手順が必要です。request_changes を送信したり、削除済みの指摘を復活させたり、出力を作るために重複排除を緩めたりしてはいけません。コードレビューの範囲が空でも、既存のスレッドは進めてください。

--loop。 references/LOOP.md を読み込みます。