pr-triage

PR のトリアージ

年齢順やサイズ順に並べたレビューキューでは、最初に確認すべき PR を見誤ります。900 行の名前変更は無害でも、価格を 1 トークン変更するのは重大かもしれません。このスキルは、すべてのオープン PR を読み、それぞれの変更が実際にどれほど重いかを判断し、真剣な確認が必要な PR が先に来るようキューを並べ替えます。設定は不要です。

注目すべき点を示しますが、承認はしません。キューの最後にある PR も必ず読みます。判断の根拠となる行をすべて明示し、各 PR には同じデータから生成した確認ガイドへのリンクを付けるため、レビュアーはワンクリックで判断を検証できます。

スクリプトはこのファイルと同じ場所にある scripts/ にあります（Node ≥ 18、依存関係なし、gh でログイン済み）。これを HTTP 経由で取得した場合は、scripts/*.mjs と references/ 内のファイルを curl -sSL でプレーンテキストとして取得してください。

一連の手順

1. ログイン状態を確認します。 node scripts/preflight.mjs を実行すると、リポジトリごとに1行ずつ表示され、ready ではない行にはインストールリンクまたはログインコマンドが示されます。トークンを尋ねたり、ログインを実行したりせず、コマンドをユーザーに渡してください。すべての行が ready なら完了です。それ以外の場合は、表を添えて BLOCKED と報告してください。
2. 計算します。 node scripts/triage.mjs を実行します（リポジトリ外では --repo owner/name を追加）。すべてのオープン PR について、ファイル、ノイズ、FACT 項目、読解順、投稿者の言葉を含む .pr-review/tour-<n>.json を書き出します。また、PR の一覧を .pr-review/triage.json に書き出し、審査担当者向けに各 PR のヘッドを一度ずつ origin/<head> に取得し、未審査ページを生成します。モデルは関与しません。リポジトリのリストを指定すると、1つのキューが作成されます（複数のリポジトリ）。再実行すると、判定結果も含めてレポートとページが置き換えられ、クローズされた PR のものは削除されます。最後に実行してから判定してください。 オープン PR が20件を超える場合は件数を伝え、すべてを判定する前に確認してください。
3. 各 PR を個別に判定します。 tour-<n>.json ごとに、対象の PR を読みます。gh pr diff <n> で差分を確認し、ノイズはざっと確認し、PR のヘッド時点の周辺コードも読みます（git fetch origin <head> の後に git show "origin/<head>:<path>" を実行します。並行する審査担当者によって上書きされる FETCH_HEAD は決して使わないでください）。references/notes.md の形式に従い、attention ブロックも含めて .pr-review/tour-<n>.notes.json に記述します。次に node scripts/annotate.mjs .pr-review/tour-<n>.json .pr-review/tour-<n>.notes.json を実行します。チェック済みのノートが tour-<n>.json に書き込まれるので、合格するまでノートを修正してください。 可能であれば、PR ごとに新しいサブエージェントを1つ使い、並行して作業させてください。それぞれに渡すのは、以下の審査要領だけにします。他の PR を読んだ審査担当者は相対評価をしてしまいます。サブエージェントを使わない場合は、1件ずつ、それぞれ独立して判定してください。
4. キューの順序を決めます。 すべての PR の attention を読んでください。.pr-review/triage.notes.json に { "summary": "...", "order": [7, 6, ...] } を記述します。order には triage.json 内の各 PR の key（複数のリポジトリの場合は "dmoka-ticket-bay-7"）を指定し、すべてのリポジトリを通して、最も注意が必要なものから順に並べます。同じレベル内では、2つの PR の順序を分ける最初の条件が見つかった時点で止め、次の順に適用します。取り消し不能なものを取り消し可能なものより先に、まだ呼び出されていないコードより実行中のコードを先に、他の PR と競合する PR（overlaps）を競合しない PR より先に、古い PR を新しい PR より先にします。要約はキュー全体についての2～3文とし、PR 間の競合には triage.json の overlaps（複数の PR が変更するファイル）を使ってください。 node scripts/annotate.mjs .pr-review/triage.json .pr-review/triage.notes.json を実行すると、すべての PR が1回ずつ配置され、判定済みであり、より低いレベルの後に置かれていないことがチェックされます。
5. レンダリングします。 node scripts/render.mjs .pr-review/triage.json を実行すると、キューとすべてのツアーを1つのファイルにまとめた .pr-review/review.html が作成されます。ツアーごとにサイドバーがあり、#/pr/7 のように瞬時に切り替えられます。サーバーは不要で、CI アーティファクトとして安全に公開できます。報告する前にキューを確認してください。ブラウザーが使える場合はブラウザーで確認します（file:// がブロックされる場合は python3 -m http.server -d .pr-review を実行します。ブラウザーがない場合は、ヘッドレス Chrome の --dump-dom でファイルを開き、同じ内容を確認してください）。次の点をチェックします。どの PR にも「not judged」と表示されていないこと、順序がノートと一致していること、各エビデンスリンクを開くと正しい行に移動すること。
6. チャットで報告します。 まず review.html のパスを示し、次にキューを報告します。レベル、PR、何が起きたか、その理由を含めます。critical と high は詳しく説明し、それ以外はそれぞれ1行で記載してください。

Judge brief

絶対パスと HEAD_BRANCH（tour-N.json の pr.head）を記入し、各審査担当者にはこれだけを渡してください。他には何も渡さないでください。

REPO の git リポジトリで、プルリクエスト #N を審査してください（そこでコマンドを実行してください）。SKILL_DIR/references/notes.md を読み、指示に従ってください。gh pr diff N と gh pr view N で PR を読み、PR の HEAD にある周辺コードを git show "origin/HEAD_BRANCH:<path>" で読んでください。すでにフェッチ済みです。git fetch は実行しないでください。ブランチは決してチェックアウトしないでください。このチェックアウトは他の人も共有しています。ノイズはざっと確認してください。作者が何か主張している場合（「フォーマットのみ」など）は、好きなツールでその主張を確認してください。attention ブロックを含む REPO/.pr-review/tour-N.notes.json を作成し、続けて node SKILL_DIR/scripts/annotate.mjs REPO/.pr-review/tour-N.json REPO/.pr-review/tour-N.notes.json を実行してください。確認済みのノートが tour-N.json にコピーされます。検査に合格するまでノートを修正してください。GitHub や他のファイルには触れないでください。attention ブロックを返信してください。

複数のリポジトリでは、N は PR キーです。審査担当者はツアーの read.diff、read.show、read.grep（gh や origin/... ではありません）と、その intent を使って読みます。

複数のリポジトリ

• 設定： ~/.config/pr-triage/repos.jsonc（Windows： %USERPROFILE%\.config\pr-triage\repos.jsonc）、コメント付き JSON： { "repos": ["github:<owner>/<repo>", ...] }。ファイルがない場合は現在のリポジトリを使用します。--repo を指定するとこの設定は無視されます。 gitlab:／azure: の項目は「まだサポートされていません」としてスキップされます。
• ログイン確認（手順 1）、リポジトリごと：git と gh がインストールされ、ログイン済みで、リポジトリを読み取れることを確認します。トリアージされるのは ready なリポジトリのみです。ページには残りのリポジトリが先に表示されます。
• キャッシュ： ~/.cache/pr-triage/github/<owner>/<repo>。部分クローン（--filter=blob:none）で、作業ツリーはありません。実行のたびに、すべてのオープン PR の HEAD を refs/pr-triage/pr/<n> にフェッチし、デフォルトブランチを更新して、クローズされた PR の参照を削除します。チェックアウトには一切触れません。キャッシュが壊れている場合は再度クローンされます。削除するには、node scripts/triage.mjs --clean-cache [github:<owner>/<repo>] を実行してください。
• キー： ファイル名、リンク、キューの順序では、PR は <owner>-<repo>-<n>（dmoka-ticket-bay-33）で表されます。各カードにはリポジトリが表示されます。

厳守事項

• 変更内容を審査してください。規模、タイトル、作者で判断してはいけません。 判断する前に差分を読んでください。タイトルから変更内容が分からない場合は、より注意して確認する理由になります。
• 判定は禁止です。 注意度は、読む順序を示すものです。PR を「安全」「LGTM」「問題なし」「マージ準備完了」「レビューすることは何もない」と決して表現しないでください。ゲートではよくある言い回しを拒否しますが、このルールはそれ以外の表現にも適用されます。
• low より上のすべてのレベルでは、行を示してください。 ゲートが確認する、コードからの一字一句そのままの断片が必要です。行の提示がなければ、判断もできません。
• GitHub では読み取り専用です。 コメント、ラベル付け、承認、変更の要求、担当者の割り当て、マージは決して行わないでください。出力は .pr-review/ に保存します。.gitignore も .git/info/exclude もこのディレクトリを対象としていない場合は、追加を提案してください。

ランキングでは分からないこと

• コードが動作するかどうか。 誰も実行していません。審査担当者が読む一方で、テストを実行してください。
• 読み手が見落とすあらゆること。 モデルが検出するのは、注意深い人間が見つける問題の一部です。低いレベルは「読み手には特に目につくものがなかった」という意味であり、「確認済み」という意味ではありません。
• リポジトリ外の状況： 締め切り、待っている人、今週ビジネスが重視していること。順序を変える要因となる場合は、その旨を記してください。
• 安定性。 実行ごとに、同じレベル内で PR の順序が変わることがあります。レベル自体は変わらないはずです。変わる場合は、その理由を示す証拠の行を記載してください。

完了の条件

• triage.json が annotate.mjs の検査に合格し、各ツアーのノートもすべて検査に合格していること。
• review.html が存在し、キューからすべての PR のツアーを開けること。
• チャットレポートに、レベルと理由を付けたキューが、注意度の高い順に記載されていること。
• GitHub 上で何も変更されていないこと。

注意点

• キャッシュ内で git fetch を実行しないでください。triage.mjs がすでにすべてのヘッドを取得しており、 並行してフェッチすると参照が競合します。

各ツアー内の意図マップ、作成者の意図を検索する順序、 および新規セッションのルールは、Matt Pocock の code-review スキル（MIT）を参考にしています。

最終確認日：2026-09-28、Hermes v0.21.5（dmoka/ticket-bay の朝の cron ジョブ）