Github Pr Review Response

GitHub PR Review Response

PR（プルリクエスト）レビューフィードバックに体系的に対応するワークフロー — 分析から修正実装、レビュアーへの返信、再レビュー依頼、人間へのマージ引き継ぎまで。

Option A の標準ルート: implementation -> github-pr-workflow -> 実際のレビューシグナル待ち -> github-pr-review-response -> 人間のマージ判断/引き継ぎ。このスキルは強調したレビュー応答フェーズでのみ開始します。

レビュー対応: PRレビューコメントを読み、分類し、修正し、返信する構造化されたプロセス。

こんなときに使う

以下の状況で活用してください：

• PRにレビューコメントが付き、コード修正や返信が必要なとき
• レビューフィードバックを重要度別に分類して修正順を決めたいとき
• コードレビューで発見された重大なバグやセキュリティ問題を修正するとき
• 単一PRに対する複数のレビューコメントへの構造化された対応計画を作成するとき
• レビュアーの質問に対して設計理由を明確に説明して返信するとき
• すべてのレビューコメントへの対応が完了し、再レビューを依頼するとき

スコープ: このスキルはレビューコメントのトリアージから再レビュー依頼までを扱います。マージ判断は人間が行い、CIゲートとマージ後同期は別のフォローアップ対象です。

レビュー待機戦略

PRが開いているだけでは、このワークフローに入りません。実際に対応が必要なレビューシグナルが来たときだけ開始します。

低消費で待つルール:

• 手動ポーリングより、通知・ユーザー共有・イベントシグナルを優先する
• 手動確認が必要でも、自然な区切りで全PRをまとめて1回確認する
• 対応すべき新しいシグナルがなければ確認を止める

PRがクローズ・マージ済み、または対応すべきレビューがなくなったら待機を終了します。

再レビュー依頼ルール: 新しいコミットや実質的な返信がそろったときだけ再レビューを依頼します。変化がない状態でレビュアーを再度 ping しません。

関連スキル

• github-pr-workflow — PR作成・Issue連携・シグナル駆動のレビュー待機（上流ワークフロー）
• session-issue-autopilot — セッション全体を包み、PR作成/待機を github-pr-workflow、レビュー対応をこのスキルへ委譲する上位ラッパー
• git-commit-practices — コミット形式と原子的コミット（Step 5から委譲）
• github-issue-intake — 保留レビュー項目のフォローアップIssue作成

依存関係

• Git 2.30+
• GitHub CLI (gh) — gh auth status で事前確認
• GitHubリポジトリへのpush権限
• 対応すべきレビューコメントがあるオープンPR

コア原則

1. 行動優先 (基礎と型) — レビューコメントには言葉だけでなくコードで対応する。「なぜ」：言葉だけの返信では問題は解決しない
2. 追跡性 (成長の複利) — すべての修正はそれを引き起こしたレビューコメントにリンクする。「なぜ」：将来の開発者が変更理由を学べるように
3. 品質維持 (継続は力) — 修正が既存の品質を低下させたりテストを壊してはならない。「なぜ」：レビュー対応で新たなバグを生むのは本末転倒
4. 敬意ある対話 (ニュートラル) — 反対意見でも理由を添えてすべてのコメントに返信する。「なぜ」：無視はチームの信頼を損なう
5. 体系的トリアージ (温故知新) — 行動する前に分類する。「なぜ」：低優先度の項目を先に修正する無駄を防ぐ

判断テーブル

レビューコメントの分類方法と正しいアクション：

Step 1でこのテーブルを使い、コードを書く前に各コメントを分類してください。

責務境界

このスキルがどこで止まるかを説明するときに使います。

Values: ニュートラル / 余白の設計

ワークフロー: PRレビュー対応

Step 1: レビューコメントの受信と分類

PRのすべてのレビューコメントを読みます。上記の判断テーブルを使って各コメントを分類します。

# PRのレビューコメントを取得
gh pr view --json reviews,reviewRequests --jq '.reviews'

# レビュースレッドの解決状況を確認
gh pr view --json reviewThreads --jq '.reviewThreads[] | {path: .path, body: .comments[0].body, isResolved: .isResolved}'

# PowerShell: レビューコメントを一覧
gh pr view --json reviews,reviewRequests --jq '.reviews'

分類リストを作成します：

## レビューコメント分析
| # | ファイル | コメント | 種類 | 優先度 |
|---|---------|---------|------|--------|
| 1 | src/auth.py | 入力バリデーション不足 | バグ | 最重要 |
| 2 | src/utils.py | ガード句の検討 | 改善 | 中 |
| 3 | README.md | 見出しのタイポ | スタイル | 低 |

レビューフィードバックを受け取ったPRを最初に開くときに使用します。

Values: 温故知新 / 基礎と型

Step 2: 対応計画の作成

plan.mdに分析結果を文書化します。問題テーブル、修正戦略、タスクリストを含めます。「なぜ」：場当たり的な修正を防ぎ、漏れをなくすため。

# PRレビュー対応計画

## 問題テーブル
| # | コメント | カテゴリ | 修正戦略 | 見積もり |
|---|---------|---------|---------|---------|
| 1 | クエリのSQLインジェクション | 最重要/バグ | パラメータ化クエリを使用 | 15分 |
| 2 | ガード句の提案 | 中/改善 | 早期リターンにリファクタ | 5分 |
| 3 | エラーハンドリング不足 | 高/機能不足 | try-catchとログ追加 | 10分 |

## タスク順序
1. #1を修正 — 最重要バグ（SQLインジェクション）
2. #3を修正 — 高優先度（エラーハンドリング）
3. #2を修正 — 中程度の改善（ガード句）

## スコープ外（フォローアップIssueを作成）
- レビューで提案されたパフォーマンス最適化（マージをブロックしない）

複数のレビューコメントの調整が必要で競合を避けたいときに使用します。

Values: 基礎と型 / 余白の設計

Step 3: 修正の実装

最重要の問題から順に対応します。各修正は焦点を絞った原子的な変更にします。

# 最重要の問題から修正 — 一度に1つの論理的変更
# なぜ：原子的な修正はレビューしやすく、必要時に巻き戻しやすい

# 例：SQLインジェクションの修正（最重要）
git add src/auth.py
git commit -m "fix: パラメータ化クエリでSQLインジェクションを防止

src/auth.pyのデータベースクエリにおける
安全でない文字列補間に関するレビューコメントに対応。"

# PowerShell: 同じgitコマンドを使用
git add src/auth.py
git commit -m "fix: パラメータ化クエリでSQLインジェクションを防止"

✅ 推奨: 追跡性のため1つのコミットで1つの問題を修正する ❌ 非推奨: すべてのレビュー修正を1つの大きなコミットにまとめる

対応計画が準備でき、コード修正を開始するときに使用します。

Values: 基礎と型 / 成長の複利

Step 4: 品質チェックの実行

リンター、テスト、バリデーションスクリプトを実行して修正が既存の品質を低下させないことを確認します。検証なしでプッシュしないでください。

# プロジェクトテストを実行してリグレッションがないことを確認
# なぜ：レビュー修正はテストなしでは新たなバグを生む可能性がある
npm test        # または: pytest, dotnet test, go test ./...

# リンターを実行してスタイル問題を検出
npm run lint    # または: flake8, dotnet format --verify-no-changes

# スキルバリデーターがあれば実行
uv run python scripts/validate_skill.py path/to/SKILL.md

# PowerShell: テストとリンターを実行
npm test
npm run lint

チェックが失敗した場合、Step 5に進む前にリグレッションを修正してください。

すべての計画修正が実装され、正確性を検証する必要があるときに使用します。

Values: 継続は力 / 基礎と型

Step 5: Conventional形式でコミット

Conventional Commits形式を使用します。将来の開発者が変更理由を理解できるよう、コミット本文にレビューコンテキストを参照します。

# 変更内容に基づいて正しいコミットタイプを選択
# fix:      レビューからのバグ修正またはセキュリティ修正
# refactor: レビューで提案されたコード改善
# docs:     レビューからのドキュメント修正
# style:    レビューからのフォーマット修正

git commit -m "fix: ユーザーメールの入力バリデーションを追加

レビューフィードバック：登録フォームのメールフィールドの
バリデーション不足をレビュアーが指摘。

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>"

各修正が完了しテストが通り、コミットの準備ができたときに使用します。

Values: 成長の複利 / 継続は力

Step 6: プッシュとコメントへの返信

すべての修正コミットをプッシュし、各レビューコメントに何をしたか、なぜそうしたかを説明して返信します。

# 修正コミットをPRブランチにプッシュ
git push origin HEAD

# body-fileで全体コメントを追加
# なぜ: mktemp で衝突を避け、trap で失敗時も確実に削除できる
REVIEW_BODY="$(mktemp "${TMPDIR:-/tmp}/review_response.XXXXXX")" || {
  echo "レビュー返信用の一時ファイル作成に失敗しました" >&2
  exit 1
}
cleanup_review_body() {
  [ -n "$REVIEW_BODY" ] && rm -f "$REVIEW_BODY"
}
trap cleanup_review_body EXIT
cat > "$REVIEW_BODY" <<'EOF'
全レビューコメントに対応済みです。各コミットの詳細を参照してください。

- `build_payload()` の nullハンドリングを修正
- 失敗経路の回帰テストを追加
EOF

gh pr review --comment --body-file "$REVIEW_BODY"

# 特定のレビューコメントスレッドへの返信はGitHub Web UIを使用
# またはAPI: gh api repos/OWNER/REPO/pulls/comments/COMMENT_ID/replies -f body="abc1234で修正済み"

# PowerShell: プッシュとレビューコメント追加
git push origin HEAD

$reviewBody = @"
全レビューコメントに対応済みです。各コミットの詳細を参照してください。

- `build_payload()` の nullハンドリングを修正
- 失敗経路の回帰テストを追加
"@
[System.IO.File]::WriteAllText("$env:TEMP\review_response.md", $reviewBody, [System.Text.UTF8Encoding]::new($false))
gh pr review --comment --body-file "$env:TEMP\review_response.md"
Remove-Item "$env:TEMP\review_response.md"

返信ガイドライン：

• ✅ 推奨: コメントに対応した具体的なコミットを参照する
• ✅ 推奨: 特定の修正アプローチを選んだ理由を説明する
• ✅ 推奨: 複数行・バッククォート・シェル断片を含む返信は --body-file を使う
• ❌ 非推奨: 「修正済み」だけの返信 — 何をなぜ変更したか説明する
• ❌ 非推奨: 反対意見のコメントを無視する — 理由を添えて返信する

すべてのコミットがプッシュされ、フィードバックループを閉じる必要があるときに使用します。

Values: ニュートラル / 成長の複利

Step 7: 再レビューの依頼

すべてのコメントに対応しプッシュが完了したら、元のレビュアーに再レビューを依頼します。実際の更新と結びつけ、変化があるときだけ通知します。

# レビュアーに再レビューを依頼
gh pr edit --add-reviewer reviewer-username

# サマリーコメントを body-file で残す（任意）
REREVIEW_BODY="$(mktemp "${TMPDIR:-/tmp}/rereview_summary.XXXXXX")" || {
  echo "再レビュー要約用の一時ファイル作成に失敗しました" >&2
  exit 1
}
cleanup_rereview_body() {
  [ -n "$REREVIEW_BODY" ] && rm -f "$REREVIEW_BODY"
}
trap cleanup_rereview_body EXIT
cat > "$REREVIEW_BODY" <<'EOF'
すべてのレビューコメントに対応しました：
- SQLインジェクション修正（コミットabc1234）
- エラーハンドリング追加（コミットdef5678）
- ガード句にリファクタ（コミットghi9012）

再レビューをお願いします。フィードバックありがとうございました！
EOF

gh pr comment --body-file "$REREVIEW_BODY"

# PowerShell: 再レビュー依頼
gh pr edit --add-reviewer reviewer-username

$reReviewBody = @"
すべてのレビューコメントに対応しました：
- SQLインジェクション修正（コミットabc1234）
- エラーハンドリング追加（コミットdef5678）
- ガード句にリファクタ（コミットghi9012）

再レビューをお願いします。フィードバックありがとうございました！
"@
[System.IO.File]::WriteAllText("$env:TEMP\rereview_summary.md", $reReviewBody, [System.Text.UTF8Encoding]::new($false))
gh pr comment --body-file "$env:TEMP\rereview_summary.md"
Remove-Item "$env:TEMP\rereview_summary.md"

再レビュー判断テーブル:

すべてのレビューコメントに修正コミットまたは返信があり、テストが通った状態で使用します。

Values: 成長の複利 / ニュートラル

Step 8: 人間のマージ判断ゲートで止める

再レビュー依頼が完了したら、次の実際のレビューシグナルを待つか、人間のマージ判断へ引き継いで止まります。必要なら準備完了状況を要約しますが、PRを自分でマージしてはいけません。

人間のマージ判断に引き渡せる状態:
- レビューコメント対応済み
- 検証を再実行しグリーン
- 再レビュー依頼済み
- 次のレビューシグナル待ち、または人間のマージ判断へ引き渡し可能

後でPRがマージされ、ユーザーがローカル後処理を明示依頼した場合のみ、リポジトリのマージ後同期または後処理手順に従い、先に worktree が clean か確認します。

レビュー対応が完了し、次のアクションがマージ判断になるときに使います。

Values: ニュートラル / 余白の設計

ベストプラクティス

• 修正は優先度順に実装する：最重要 → 高 → 中 → 低
• 追跡性のため1つのコミットで1つのレビューコメントに対応する
• バグ修正と改善を区別するため fix: や refactor: のコミットタイプを使用する
• レビュー後のforce-pushを避ける — レビュー会話の履歴が消える
• 現在のPRのスコープ外の提案にはフォローアップIssueを作成する
• レビュースレッドに直接返信するため gh pr review --comment を使用する
• 準備完了の要約で止め、人間の代わりにマージしない
• 実際のレビューシグナルが来たときだけこのワークフローを開始する
• 新しいコミットや実質返信がそろったときだけ再レビューを依頼する
• 複数行のレビュー要約や返信では --body-file を優先する

よくある落とし穴

1. すべてを1つの大きなコミットで修正する 修正方法: 原子的コミットを使う — 明確なコード履歴のため1コミット1レビューコメント。

2. 低優先度のコメントに返信せず無視する 修正方法: すべてのコメントに返信する。認識したうえでフォローアップIssueに延期する場合も。

3. テスト実行なしで修正をプッシュする 修正方法: プッシュ前に必ずテストスイートとリンターを完全実行する（Step 4の手法）。

4. コンテキストなしで「修正済み」と返信する 修正方法: コミットハッシュを参照し、返信で修正アプローチを説明する。

5. 新しいシグナルがないのにレビュー対応フローを開く 修正方法: 新規レビュー・review request・ユーザー共有が来るまで待機を続ける。

6. バッククォートやシェル文字を含む返信本文が壊れる 修正方法: クォート付きHEREDOCで返信本文を作り、--body-file で送る。

アンチパターン

• レビュープロセスをバイパスするためmainに直接プッシュする — ブランチ優先の設計に違反
• レビュー修正に無関係な変更をバンドルする — 原子的コミット構造を壊す
• 説明なしでレビュアーのフィードバックを却下する — チームの信頼を損なう
• レビュー会話履歴を隠すためにforce-pushする — 追跡性を破壊する

クイックリファレンス

レビュー対応チェックリスト

待機モードのルール

• 新規レビューや review request に反応し、変化のない open PR には反応しない
• 手動確認はまとめて行い、繰り返しポーリングしない
• 再レビュー依頼は新しい作業がそろった後だけ行う
• 新しく対応すべきものがなければ待機モードを終了しない

返信テンプレート

コミット `<ハッシュ>` で修正済み。

**変更内容**: <修正の簡潔な説明>
**このアプローチの理由**: <選択した解決策の理由>

FAQ

Q: レビューコメントに同意できない場合は？ A: 理由を添えて返信してください。なぜ別のアプローチを選んだかを説明します。コメントを無視しないでください。

Q: レビュー修正用に新しいブランチを作るべき？ A: いいえ。同じPRブランチに修正をプッシュしてください。レビュー会話を維持するためです。

Q: 提案がスコープ外の場合は？ A: コメントを認識し、github-issue-intake でフォローアップIssueを作成し、返信にリンクしてください。

Q: このスキルは最初のPR作成を扱う？ A: いいえ。PR作成とレビュー待機には github-pr-workflow を使ってください。標準ルートは implementation -> github-pr-workflow -> レビューシグナル待ち -> このスキル -> 人間のマージ判断 です。

Q: 再レビュー後にこのスキルがPRをマージする？ A: いいえ。マージは人間の判断です。このスキルは返信・検証・再レビュー依頼までで終了します。

リソース

• https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests
• https://cli.github.com/manual/gh_pr_review
• https://www.conventionalcommits.org/