Systematic workflow for responding to PR review feedback. Use when addressing reviewer comments with fixes and replies.
PR（プルリクエスト）レビューフィードバックに体系的に対応するワークフロー — 分析から修正実装、レビュアーへの返信、再レビュー依頼、人間へのマージ引き継ぎまで。
Option A の標準ルート: implementation -> github-pr-workflow -> 実際のレビューシグナル待ち -> github-pr-review-response -> 人間のマージ判断/引き継ぎ。このスキルは強調したレビュー応答フェーズでのみ開始します。
レビュー対応: PRレビューコメントを読み、分類し、修正し、返信する構造化されたプロセス。
以下の状況で活用してください：
スコープ: このスキルはレビューコメントのトリアージから再レビュー依頼までを扱います。マージ判断は人間が行い、CIゲートとマージ後同期は別のフォローアップ対象です。
PRが開いているだけでは、このワークフローに入りません。実際に対応が必要なレビューシグナルが来たときだけ開始します。
| シグナル | このスキルに入る？ | アクション | |---|---|---| | 新しいレビューが送信された | はい | Step 1 を1回開始 | | 自分に review request が来た | はい | Step 1 を1回開始 | | ユーザーが新規レビュー到着を共有した | はい | 確認して Step 1 を開始 | | PRは開いているが変化なし | いいえ | 待機継続 | | CIステータスだけ変わった | 場合による | 本当にレビュー対応が必要か確認 |
低消費で待つルール:
PRがクローズ・マージ済み、または対応すべきレビューがなくなったら待機を終了します。
再レビュー依頼ルール: 新しいコミットや実質的な返信がそろったときだけ再レビューを依頼します。変化がない状態でレビュアーを再度 ping しません。
github-pr-workflow — PR作成・Issue連携・シグナル駆動のレビュー待機（上流ワークフロー）session-issue-autopilot — セッション全体を包み、PR作成/待機を github-pr-workflow、レビュー対応をこのスキルへ委譲する上位ラッパーgit-commit-practices — コミット形式と原子的コミット（Step 5から委譲）github-issue-intake — 保留レビュー項目のフォローアップIssue作成gh) — gh auth status で事前確認レビューコメントの分類方法と正しいアクション：
| コメント種類 | アクション | 優先度 | 例 | |---|---|---|---| | バグ/セキュリティ | マージ前に必ず修正 | 最重要 | 「SQLインジェクションの脆弱性がある」 | | ロジックエラー | マージ前に必ず修正 | 最重要 | 「この条件が反転している」 | | 機能不足 | 修正またはフォローアップIssue作成 | 高 | 「エラーハンドリングがない」 | | 改善提案 | 簡単なら修正 | 中 | 「ガード句の使用を検討して」 | | スタイル/フォーマット | チーム合意がなければ修正 | 低 | 「インデントが不統一」 | | 質問/確認 | 説明を返信 | 低 | 「なぜこのアプローチを選んだの？」 |
Step 1でこのテーブルを使い、コードを書く前に各コメントを分類してください。
| フェーズ | エージェントの責務 | 人間の責務 | |---|---|---| | レビューシグナル受付 | 新規レビューを1回だけ確認し、コメントをトリアージする | そのシグナルで優先順位が変わるか判断する | | 修正と返信 | 修正を実装し、根拠付きで返信して追跡性を保つ | 返信内容がチーム期待に合うか判断する | | 再レビュー依頼 | 行動可能な更新が push / 投稿された後だけ再レビューを依頼する | 追加レビュアーが必要か判断する | | マージ判断 | 準備完了を要約するだけ | GitHub上でマージするか、いつするか決める |
このスキルがどこで止まるかを説明するときに使います。
Values: ニュートラル / 余白の設計
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: 温故知新 / 基礎と型
plan.mdに分析結果を文書化します。問題テーブル、修正戦略、タスクリストを含めます。「なぜ」：場当たり的な修正を防ぎ、漏れをなくすため。
# PRレビュー対応計画
## 問題テーブル
| # | コメント | カテゴリ | 修正戦略 | 見積もり |
|---|---------|---------|---------|---------|
| 1 | クエリのSQLインジェクション | 最重要/バグ | パラメータ化クエリを使用 | 15分 |
| 2 | ガード句の提案 | 中/改善 | 早期リターンにリファクタ | 5分 |
| 3 | エラーハンドリング不足 | 高/機能不足 | try-catchとログ追加 | 10分 |
## タスク順序
1. #1を修正 — 最重要バグ（SQLインジェクション）
2. #3を修正 — 高優先度（エラーハンドリング）
3. #2を修正 — 中程度の改善（ガード句）
## スコープ外（フォローアップIssueを作成）
- レビューで提案されたパフォーマンス最適化（マージをブロックしない）
複数のレビューコメントの調整が必要で競合を避けたいときに使用します。
Values: 基礎と型 / 余白の設計
最重要の問題から順に対応します。各修正は焦点を絞った原子的な変更にします。
# 最重要の問題から修正 — 一度に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: 基礎と型 / 成長の複利
リンター、テスト、バリデーションスクリプトを実行して修正が既存の品質を低下させないことを確認します。検証なしでプッシュしないでください。
# プロジェクトテストを実行してリグレッションがないことを確認
# なぜ：レビュー修正はテストなしでは新たなバグを生む可能性がある
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: 継続は力 / 基礎と型
Conventional Commits形式を使用します。将来の開発者が変更理由を理解できるよう、コミット本文にレビューコンテキストを参照します。
# 変更内容に基づいて正しいコミットタイプを選択
# fix: レビューからのバグ修正またはセキュリティ修正
# refactor: レビューで提案されたコード改善
# docs: レビューからのドキュメント修正
# style: レビューからのフォーマット修正
git commit -m "fix: ユーザーメールの入力バリデーションを追加
レビューフィードバック：登録フォームのメールフィールドの
バリデーション不足をレビュアーが指摘。
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>"
| コミットタイプ | 使用場面 |
|---|---|
| fix: | レビューからのバグ修正またはセキュリティ問題 |
| refactor: | レビューからのコード構造改善 |
| docs: | レビューからのドキュメント修正 |
| style: | レビューからのフォーマット修正 |
各修正が完了しテストが通り、コミットの準備ができたときに使用します。
Values: 成長の複利 / 継続は力
すべての修正コミットをプッシュし、各レビューコメントに何をしたか、なぜそうしたかを説明して返信します。
# 修正コミットを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: ニュートラル / 成長の複利
すべてのコメントに対応しプッシュが完了したら、元のレビュアーに再レビューを依頼します。実際の更新と結びつけ、変化があるときだけ通知します。
# レビュアーに再レビューを依頼
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"
再レビュー判断テーブル:
| 状況 | 再レビュー依頼する？ | 理由 | |---|---|---| | 新しいコミットまたは実質的な返信がそろった | はい | レビュアーの確認が行動可能な状態になったため | | あいさつや受領だけで、実質更新がない | いいえ | 不要な reviewer ping を避けるため | | 以前の再レビュー依頼後にさらに新しいレビューが来た | まず Step 1 に戻る | 依頼を常に最新の作業に紐付けるため |
すべてのレビューコメントに修正コミットまたは返信があり、テストが通った状態で使用します。
Values: 成長の複利 / ニュートラル
再レビュー依頼が完了したら、次の実際のレビューシグナルを待つか、人間のマージ判断へ引き継いで止まります。必要なら準備完了状況を要約しますが、PRを自分でマージしてはいけません。
人間のマージ判断に引き渡せる状態:
- レビューコメント対応済み
- 検証を再実行しグリーン
- 再レビュー依頼済み
- 次のレビューシグナル待ち、または人間のマージ判断へ引き渡し可能
後でPRがマージされ、ユーザーがローカル後処理を明示依頼した場合のみ、リポジトリのマージ後同期または後処理手順に従い、先に worktree が clean か確認します。
レビュー対応が完了し、次のアクションがマージ判断になるときに使います。
Values: ニュートラル / 余白の設計
fix: や refactor: のコミットタイプを使用するgh pr review --comment を使用する--body-file を優先するすべてを1つの大きなコミットで修正する 修正方法: 原子的コミットを使う — 明確なコード履歴のため1コミット1レビューコメント。
低優先度のコメントに返信せず無視する 修正方法: すべてのコメントに返信する。認識したうえでフォローアップIssueに延期する場合も。
テスト実行なしで修正をプッシュする 修正方法: プッシュ前に必ずテストスイートとリンターを完全実行する（Step 4の手法）。
コンテキストなしで「修正済み」と返信する 修正方法: コミットハッシュを参照し、返信で修正アプローチを説明する。
新しいシグナルがないのにレビュー対応フローを開く 修正方法: 新規レビュー・review request・ユーザー共有が来るまで待機を続ける。
バッククォートやシェル文字を含む返信本文が壊れる
修正方法: クォート付きHEREDOCで返信本文を作り、--body-file で送る。
| ステップ | アクション | 確認事項 | |---------|----------|---------| | 1 | すべてのレビューコメントを読み分類 | 判断テーブル適用済み | | 2 | plan.mdに対応計画を作成 | 全コメント追跡済み | | 3 | 修正を実装（最重要 → 低） | 1コミット1修正 | | 4 | テストとリンターを実行 | 全チェック通過 | | 5 | Conventional形式でコミット | 本文にレビューコンテキスト | | 6 | プッシュして各コメントに返信 | 全コメントに回答済み | | 7 | 再レビューを依頼 | レビュアーに通知済み |
コミット `<ハッシュ>` で修正済み。
**変更内容**: <修正の簡潔な説明>
**このアプローチの理由**: <選択した解決策の理由>
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: いいえ。マージは人間の判断です。このスキルは返信・検証・再レビュー依頼までで終了します。
npx skills add RyoMurakami1983/github-pr-review-response下载完整 Skill 目录，包含 SKILL.md 及所有相关文件
Search for places (restaurants, cafes, etc.) via Google Places API proxy on localhost.
Interact with GitHub using the `gh` CLI. Use `gh issue`, `gh pr`, `gh run`, and `gh api` for issues, PRs, CI runs, and advanced queries.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Start voice calls via the OpenClaw voice-call plugin.
Notion API for creating and managing pages, databases, and blocks.
Gemini CLI for one-shot Q&A, summaries, and generation.
Category:developer