respond

respond

PR のレビューコメントを読み、それぞれに 0～100 のスコアを付け、スコアに基づいて対応します。明らかに価値のあるものはすぐに修正し、的外れな指摘には異議を唱え、判断が難しいものについては修正を進めながら確認します。このスキルが投稿するすべての返信には、agent on behalf of; の帰属行が含まれます。

Phase 0: PR の健全性チェック

コメントをトリアージする前に、gh CLI で PR のビルド状況とマージ状況を確認します。

gh pr checks <pr-number>            # check run conclusions
gh pr view <pr-number> --json mergeable,mergeStateStatus

ビルド失敗。 いずれかのチェックが state: FAILURE の場合、失敗したジョブのログ（gh run view <run-id> --log-failed）を取得し、レビューコメントに対応する前に根本原因を修正します。まずビルドを修正します。ビルドが壊れている場合、レビューコメントへの対応が不要になることがあります。

マージコンフリクト。 mergeable が CONFLICTING、または mergeStateStatus が DIRTY の場合、コメントに対応する前に origin/<base> を対象にリベースし、リース付きで強制プッシュします。古いコンフリクトは、それ以降のすべての作業を妨げます。

トリアージ表の先頭に、ビルド／マージ状況を記載します。

## PR #N status
- Build: passing | failing (N jobs)
- Merge: clean | conflicts (rebase needed)

どちらも問題なければ、フェーズ 1 に進みます。修正が必要だった場合は、実施した内容を記載します。

Phase 1: スレッドとレビュー本文の取得

現在の Git リモートから <owner>/<repo> を特定し、インラインレビューのスレッドと PR レベルのレビュー本文を両方取得します。

# Inline threads — comments anchored to specific diff lines
gh api repos/<owner>/<repo>/pulls/<pr>/comments

# PR-level review bodies — summaries submitted with a review
gh api repos/<owner>/<repo>/pulls/<pr>/reviews

# PR metadata + diff for context
gh pr view <pr> --json number,title,baseRefName,headRefName
gh pr diff <pr>

インラインスレッド。 未解決のスレッドのみを対象にします。ユーザーから依頼がない限り、古くなったスレッドは除外します。コメントはスレッドごとにまとめます。最初のコメントが提案で、残りはそのやり取りです。

レビュー本文。 body が空でないレビューのみを対象にします。本文が空のものはインラインコメントを格納するためのものであり、ここでは無視できます。

重複排除。 本文とインラインコメントの両方を含むレビューは、取得結果の両方に現れます。インラインコメントはスレッドとしてスコアを付けます（ファイルのコンテキストがあるためです）。レビュー本文については、インラインコメントで扱われていない提案のみをスコアリングします。pull_request_review_id を使って、インラインコメントと親レビューを関連付けます。

Phase 2: 各提案をスコアリング

未解決のスレッドまたはレビュー本文の各項目について、提案、追加のやり取り、関連する差分を確認します。そのうえで、その提案が正しく有益であるとあなたがどれほど確信しているかを示す 0～100 の信頼度スコアを付けます。

可能であれば、レビュー本文を個別の項目に分解します。箇条書き、番号付きリスト、表の行には、個別にスコアを付けてトリアージ表に記載する価値のある、複数の異なる提案が含まれていることがよくあります。「LGTM」や一般的な所見など、一貫したコメントは 1 項目のままにします。

CHANGES_REQUESTED は COMMENTED より重く扱います。レビュー担当者が問題をブロッキングとして指摘しているためです。これをスコアに反映します。提案の重要性に対する確信は高まりますが、提案そのものが正しいという確信が高まるわけではありません。

4 段階の詳しい調整基準（提案の種類、根拠の確かさ、コンテキストによる調整、境界値の再評価）は、references/scoring.md にあります。一度読んで、すべての項目を基準に照らしてスコアを付けます。

Phase 3: トリアージ表と即時対応

ユーザーが一度にすべてを確認できるよう、トリアージ表全体を提示します。

## PR #N review triage

| # | Score | Type          | Reviewer | Location      | Summary                       | Action    |
|---|-------|---------------|----------|---------------|-------------------------------|-----------|
| 1 | 92    | BUG           | copilot  | auth.ts:42    | Missing null check on token   | FIX       |
| 2 | 78    | VALID_CONCERN | alice    | (review body) | Missing error handling in 3   | FIX       |
| 3 | 60    | STYLE         | copilot  | utils.ts:15   | Extract to shared helper      | ASK       |
| 4 | 35    | SCOPE_CREEP   | bob      | index.ts:3    | Add backward compat shim      | PUSH BACK |
| 5 | 20    | STYLE         | copilot  | (review body) | "consider adding tests"       | SKIP      |

### Legend
- FIX (>= 50): agree and implement — proceeding now
- ASK (30–49): needs your call — what do you want to do?
- PUSH BACK (< 30): draft reply below — edit or approve

各行には、ユーザーが PR を再度開かずに ASK 項目を判断できるよう、1 行の補足説明を含めます。補足説明の形式については、references/triage-examples.md を参照してください。

その後、同じターン内ですぐに次を行います。

1. ユーザーが ASK 項目と PUSH BACK 項目を確認している間に、すべての FIX 項目（>= 50）の修正を開始します。
2. スコアが 30 未満の項目について、PUSH BACK の返信を投稿します（ユーザーは対応前に方針を変更できます。待たずに進めてください）。
3. ASK 項目（30～49）についてユーザーに確認します。すぐに判断できるだけのコンテキストを含めます。

トリアージ表は参考情報であり、確信度の高い項目に対応するための承認手続きではありません。ユーザーは状況を確認し、作業を中断できます（「中止して、#2 は修正しないで」など）。ただし、既定の方針は明らかな改善点に迅速に対応することです。

フェーズ 4：実行

このフェーズで投稿するすべての返信は、scripts/post-reply.sh を経由します。このスクリプトは gh api の呼び出しをラップし、帰属表示のサフィックスを追加します（下記の帰属表示ルールを参照）。返信を投稿するために、このスキルから gh api を直接呼び出さないでください。帰属表示は一箇所で適用する必要があります。

FIX 項目（50 以上）。 ソースを読み、修正を実装してから返信します。

# Inline thread reply
./scripts/post-reply.sh --thread \
  --pr <pr-number> \
  --comment-id <comment-id> \
  --body "Fixed — <brief description of what changed>."

# Review body reply (PR conversation comment)
./scripts/post-reply.sh --issue \
  --pr <pr-number> \
  --body "Re: @<reviewer>'s review — Fixed: <brief description>."

PUSH BACK 項目（30 未満）。 単に「いいえ」と答えるのではなく、理由を説明する返信を投稿します。

./scripts/post-reply.sh --thread \
  --pr <pr-number> \
  --comment-id <comment-id> \
  --body "<pushback explanation>"

プロフェッショナルで具体的なトーンを保ちます。関連する場合は、プロジェクトの規約（AGENTS.md／CLAUDE.md／ハーネスの指示ファイル、複雑さの予算、開発初期段階であること）を引用します。

ASK 項目（30～49）。 ユーザーの返答を待ちます。ユーザーが決めたら、FIX または PUSH BACK として実行します。特定の ASK にユーザーが返答しない場合は、未解決のままにします。

すべてのアクションの後。 コードを変更した場合は、コミットとプッシュのために /plate に引き継ぎます。変更したファイル、返信したスレッド、ユーザーの判断待ちのスレッドをまとめて提示します。

帰属表示ルール

このスキルが GitHub に投稿するすべての返信（インラインのスレッド返信、レビュー本文への返信、PR の会話コメント）には、末尾に次の帰属表示サフィックスを文字どおり付ける必要があります。

---
agent on behalf of; <github-handle>

文言は正確に agent on behalf of; とします（小文字、セミコロン、ハンドルの直前に半角スペースを 1 つ）。返信の末尾に、独立した行として水平線（---）を付けて配置します。この意図は、レビュー担当者が返信を見たときに、エージェントがチームメイトに代わって投稿したことがすぐにわかるようにすることです。

帰属表示は scripts/post-reply.sh によって適用されます。文字列 agent on behalf of; は、単一の Bash 定数（ATTRIBUTION_PREFIX）としてそこに置かれています。返信テンプレートにマジック文字列として散在させてはいけません。ハンドルは投稿時にスクリプトによって次の順序で解決されます。

1. 設定されている場合は RESPOND_GH_HANDLE 環境変数。
2. gh api user --jq .login（認証済みの gh ユーザー）。
3. 最終手段として git config user.name。

本文の長さ制限に合わせるために帰属表示を削除してはいけません。GitHub REST の issue コメントおよびレビューのスレッド返信の上限は 65,536 文字です。帰属表示サフィックスは約 40 文字で、上限に達することはありません。返信がそのような長さになる場合は、帰属表示を削除するのではなく、先に分割してください。

このルールは、今後の監査で誤ってサフィックスが削除されないようにするためのものです。このセクションを先に更新せずに、接頭辞を省略または短縮するために post-reply.sh を編集してはいけません。

ルール

• 実行前にトリアージ表を提示します。ただし、50 以上の項目については承認を待ちません。
• スレッドごとに返信は 1 つです。複数のコメントに分けて返信してはいけません。
• レビュー担当者のトーンに合わせます。人にはプロフェッショナルに、ボットには簡潔に返信します。
• PUSH BACK では具体的な点を引用します。関連する場合は、プロジェクトのエージェント指示ファイル（AGENTS.md／CLAUDE.md／GEMINI.md）、複雑さの予算、または開発初期段階であることに言及します。
• スタイルについて議論しません。純粋にスタイル上の提案でスコアが 30 未満の場合は、PUSH BACK を投稿せず、表に SKIP と記載します。30～49 のスタイル上の項目は、ユーザーが判断できるよう ASK のままにします。
• フォローアップに先送りしてはいけません。「フォローアップ PR で対応します」や「良いアイデアなので、別途対応します」と返信してはいけません。スコアが 50 以上なら今すぐ修正し、30 未満なら PUSH BACK します。唯一の有効な先送りは、ユーザーが明示的に見送る ASK 項目です。
• コミットはまとめます。スレッドごとにコミットするのではなく、修正を 1 つのコミットにまとめます。
• ユーザーはすべてを上書きできます。「#2 は修正しない」で停止し、「やはり #4 を修正して」で実行します。スコアはデフォルトであり、強制ではありません。

このスキルが決して行わないこと

• 新しいレビューを生成すること。生成する場合は /copilot-review を使用してください。
• レビュアーが依頼した具体的な修正を超えて、コードをリファクタリングすること。
• レビュアーから明示的に依頼されない限り、テストを追加すること。
• トリアージ対象のもの以外に、新しいイシューや PR を作成すること。
• レビューコメントで言及されていないファイルを変更すること。
• 返信していないスレッドを解決すること。GitHub に自動で解決させてください。
• 帰属表示のサフィックスを付けずに返信を投稿すること。詳しくは 帰属表示ルールを参照してください。

注意点

• gh api は、コメントが 50 件を超える PR でレート制限に達します。可能な場合は読み取りをまとめ、多数のリクエストよりもページネーションを使った単一の呼び出しを優先してください。
• レビュー本文の解析では、一貫性のあるコメントが断片に分割されることがあります。断片を個別に評価する前に、関連するスレッドがないか確認してください。
• GitHub Apps によっては、is_resolved が常に信頼できるとは限りません。不確かな場合は、最新のコメントを確認してスレッドの状態を検証してください。
• CHANGES_REQUESTED のボットレビュアーは、緊急性を実際より高く見せることがあります。このケースには references/scoring.md で -10 の補正が適用されます。
• インラインコメントとレビュー本文の要約の重複排除は難しい場合があります。対応する前に、pull_request_review_id の重複を確認してください。