1natsu-vacation PR Review Handler
GitHubのPRレビューコメントを自律的に処理する。判断・修正・返信・サマリー投稿を一貫して行う。
Phase 1: PRの特定
引数があればそれを使う。なければ現在のブランチから自動検出する。
# 引数でPR番号/URLが指定された場合はそれを使う
# なければ現在のブランチのPRを取得
gh pr view --json number,url,title,headRefName,baseRefName,author
PR作成者のログイン名を控えておく（Phase 2でフィルタに使う）。
Phase 2: レビューコメントの収集
GitHub PRのコメントは複数箇所に分散している。全てのソースを確認しないと指摘を見落とす。
PR_NUMBER=<番号>
REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
PR_AUTHOR=<PR作成者のlogin>
# 1. インラインコメント（コードの特定行に紐づく指摘）
gh api repos/$REPO/pulls/$PR_NUMBER/comments \
--jq '.[] | select(.in_reply_to_id == null) | {id, path, line, body, user: .user.login}'
# 2. レビュー単位のコメント（CHANGES_REQUESTED等のレビュー本文）
# レビュー本文にnitpickや追加指摘が含まれることがある
gh api repos/$REPO/pulls/$PR_NUMBER/reviews \
--jq '.[] | select(.state != "APPROVED" and .body != "") | {id, body, state, user: .user.login}'
# 3. 特定レビューに紐づくコメント（レビュー本文内のnitpick等）
# レビューIDごとに取得
gh api repos/$REPO/pulls/$PR_NUMBER/reviews/$REVIEW_ID/comments \
--jq '.[] | {id, path, line, body, user: .user.login}'
AIレビューツール（CodeRabbit等）はレビュー本文にnitpickを折りたたんで含めることが多い。レビュー本文の<details>タグ内にも指摘がないか確認する。
スキップするコメント：
- PR作成者（
$PR_AUTHOR）自身のコメント position == null（outdated：コードが変わって対象行が消えた）- すでにresolvedになっているスレッド
- 既に返信済みのコメント（二重対応を防ぐ）
Phase 3: 各コメントの分析・判断
コメントごとにアクションを決定する。
| アクション | 判断基準 |
|---|---|
| Fix | 修正箇所と内容が明確。バグ、命名、typo、スタイル統一 |
| Skip | スコープ外、意図的な設計への反論、別PRで対応すべき内容 |
| AskUser | アーキテクチャ選択、設計方針の選択、ビジネスコンテキストが必要 |
Fix判断のポイント：
- 変更箇所が特定できる（ファイル・行がわかる）
- 既存コードのパターンや慣習と照合して判断できる
- 変更の影響範囲が局所的で副作用が読める
- コメントに
suggestionブロックがある場合は、その提案コードを参考にする
AskUser判断のポイント：
- 複数の正解がある選択肢を迫られている
- ビジネス要件や優先度の判断が必要
- 大きなリファクタリングや設計変更を伴う
Phase 4: ユーザー確認（AskUserがある場合）
AskUserと判断したコメントがある場合、ここで作業を一時停止してユーザーに確認する。
以下のコメントは判断が必要です。どう対応しますか？
1. [@reviewer] "コメント内容"
→ A: [選択肢A]
→ B: [選択肢B]
→ スキップ（今回は対応しない）
2. ...
ユーザーの指示を受けてから Phase 5 に進む。
Phase 5: コード修正
Fixと判断したコメント（＋ユーザーが指示した対応）を順番に修正する。
- 対象ファイルを読む
- コメントが指している箇所を特定する
- 修正を適用する
- 修正内容をメモしておく（後の返信・サマリーに使う）
同一ファイルへの複数コメントはまとめて修正する。
Phase 6: コミット & プッシュ
全修正が完了したらコミット・プッシュする。
git add <修正したファイル>
git commit -m "fix: address PR review comments
- [修正した指摘の簡潔な説明]
- ..."
git push
コミットメッセージは 1natsu-commit スキルのConventional Commitsルールに従う。
git add -A ではなく修正したファイルを個別に指定する。
Phase 7: コメント返信
各レビューコメントに個別に返信する。返信には変更箇所へのリンクを含める。
コミットSHAはPhase 6のプッシュ後に取得する：
COMMIT_SHA=$(git rev-parse HEAD)
Fixしたコメントへの返信（単一箇所の変更）：
対応しました。[何をどう変えたか1〜2行]
https://github.com/$REPO/blob/$COMMIT_SHA/$FILE_PATH#L$LINE
Fixしたコメントへの返信（複数箇所にまたがる変更）：
対応しました。[何をどう変えたか1〜2行]
https://github.com/$REPO/commit/$COMMIT_SHA
Skipしたコメントへの返信：
[理由]のため今回は対応を見送りました。
返信は簡潔に。詳細な説明は不要。リンクがあれば読み手が自分で確認できる。
全ての返信にフッター署名を付ける：
---
<sub>🤖 by [1natsu-pr-review-handler](https://github.com/1natsu-vacation/agent-skills) | $AI_TOOL ($MODEL_NAME)</sub>
$AI_TOOL と $MODEL_NAME は実行環境に合わせる（例: Claude Code (claude-opus-4-6)、Cursor (gpt-4o) 等）。
Phase 8: サマリーコメント投稿
PRにサマリーコメントを1つだけ投稿する。
COMMIT_SHA=$(git rev-parse HEAD)
gh pr comment $PR_NUMBER --body "$(cat <<'EOF'
## レビュー対応サマリー
### 対応済み
- **[コメントの要約]**: [対応内容] ([`$FILE_PATH#L$LINE`](https://github.com/$REPO/blob/$COMMIT_SHA/$FILE_PATH#L$LINE))
- ...
### 要確認
- **[コメントの要約]**: [理由・質問内容]
- ...
---
<sub>🤖 by [1natsu-pr-review-handler](https://github.com/1natsu-vacation/agent-skills) | $AI_TOOL ($MODEL_NAME)</sub>
EOF
)"
要確認項目がなければ「要確認」セクションは省略する。
よくある注意点
| 状況 | 対応 |
|---|---|
| outdatedコメント（position == null） | スキップ。返信もしない |
| 同じ指摘が複数レビュワーから来ている | まとめて1回修正し、各コメントに個別返信 |
| AIレビューツールのコメント | 人間と同様に処理する |
| 修正すると他の指摘と矛盾する | 優先度の高い方を採用し、もう一方の返信に理由を記載 |
| suggestionブロック付きコメント | 提案コードを参考にしつつ、プロジェクト慣習に合わせて修正 |
| レビュー本文内のnitpick | 折りたたみ内も確認し、見落とさない |