pr-comment

GitHub PR のレビューコメント ( $ARGUMENTS ) を評価する。$ARGUMENTS はコメントの URL(例: https://github.com/<owner>/<repo>/pull/123#discussion_r456789)。空の場合はユーザーに URL を質問する。

手順

1. コメントスレッドの取得

URL から owner / repo / PR 番号 / コメント ID(discussion_r の数値部分)を抽出し、スレッド全体を取得する:

# 対象コメント本文
gh api repos/<owner>/<repo>/pulls/comments/<コメントID>
# 同スレッドの返信(in_reply_to_id で辿る)
gh api repos/<owner>/<repo>/pulls/<PR番号>/comments \
  --jq '.[] | select(.id == <コメントID> or .in_reply_to_id == <コメントID>) | {id, user: .user.login, body, path, line}'

gh pr view <PR番号> で PR の目的・関連 issue も把握する。

2. コードベースでの独立検証

コメントの主張を鵜呑みにせず、指摘対象のコード(path / line)と PR の diff を実際に読んで前提が正しいか検証する。指摘が波及先(呼び出し元・同種の他箇所)にも当てはまるかも確認する。

3. 妥当性の判定

以下を提示する:

• 判定: 妥当 / 部分的に妥当 / 対応不要(コメントが複数論点を含む場合は論点ごとに判定)
• 重大度: must / should / nit
• 根拠: コードの該当箇所(file:line)に基づく説明
• 対応方針: 複数ある場合は選択肢に推奨度(5 段階)と理由を付けて提示

4. 返信文案の作成

ユーザーの口調に合わせた返信文案を作成する:

• 丁寧だがカジュアルな文体(「〜と思ってます」「〜ですかね」「〜そうです」調)
• 文末に 🙇 :bow: :pray: などの絵文字を適度に使う
• 指摘の妥当な部分は率直に認め、対応を別 issue に分ける提案をする場合は理由(変更範囲・設計判断の大きさ)を添える

5. 次のアクションの確認

AskUserQuestion で確認する: 返信文案のみで完了 / 修正も実装する / 文案を修正する。修正実装の指示があれば対応する。

注意事項

• 返信の投稿は行わない(gh pr comment や gh api の POST は禁止)。文案の作成まで
• 判定は事実とコードの根拠に基づくこと。推測が含まれる場合は明示する
• 修正実装まで行った場合はコミットせず、1 行のコミットメッセージ案を添える