review-fix

name	review-fix
description	This skill should be used when the user asks to "fix review comments", "address PR feedback", "fix CodeRabbit issues", or mentions "レビュー修正", "レビュー指摘修正", "PRレビュー対応", "review-fix". Auto-fetches CodeRabbit/Copilot review comments from GitHub PRs, analyzes, and executes fix, test, commit, and push. Takes optional argument: /review-fix <PR-number>
argument-hint	<PR番号>
allowed-tools	Read, Glob, Grep, Edit, Write, Bash(git *), Bash(gh *), Agent, WebSearch, WebFetch
context	main

Review Fix

GitHub PR に付いた CodeRabbit / GitHub Copilot のレビューコメントを自動取得し、 指摘を分析・分類した上で、修正→テスト→コミット＆プッシュまでを一気に実行するスキル。

人間がレビューコメントを一つずつ読んで手作業で直す手間をゼロにすることが目的。 レビュアーの意図を正確に汲み取り、プロジェクトの品質基準（CLAUDE.md）に従って修正する。

基本姿勢

• レビュアーの指摘を正確に理解し、その意図に沿った修正をする
• 指摘されていない箇所は変更しない（スコープを厳守）
• 過剰な修正をしない（指摘への対応に必要な最小限の変更）
• 既存テストを壊さない
• 修正済みの指摘を二重に対応しない（現在のコードとの照合を必ず行う）

使い方

/review-fix          # 現在のブランチのPRを自動検出
/review-fix 37       # PR #37 を指定

他スキルとの連携

前工程	本スキル	後工程
/code-review /security-scan（レビュー指摘が PR に投稿された後）	/review-fix	/code-review（再レビューで指摘解消を確認）

前提条件

要件	詳細
gh CLI	GitHub CLI がインストール済みで認証済みであること
ブランチ	PR に対応するブランチにチェックアウト済みであること
テストコマンド	docs/project.md に定義されたテストコマンドが利用可能であること

ワークフロー

Phase 1: レビューコメント取得

PR番号が省略された場合、現在のブランチから自動検出する:

gh pr view --json number --jq '.number'

以下の2つのAPIで全レビューコメントを取得する:

# インラインコメント（ファイルの特定行への指摘）
gh api repos/{owner}/{repo}/pulls/{pr}/comments \
  --jq '.[] | .user.login + " | " + .path + ":" + (.line | tostring) + " | " + (.body | split("\n")[0])'

# レビューサマリー
gh api repos/{owner}/{repo}/pulls/{pr}/reviews \
  --jq '.[] | .user.login + " | " + .state + " | " + (.body | length | tostring)'

コメント本文が長い場合は全文を取得して分析に使う:

gh api repos/{owner}/{repo}/pulls/{pr}/comments \
  --jq '.[] | select(.user.login == "coderabbitai[bot]" or .user.login == "copilot-pull-request-reviewer[bot]" or .user.login == "Copilot") | "📄 " + .path + ":" + (.line | tostring) + "\n" + .body + "\n---"'

Phase 2: フィルタリング・照合・分類

この Phase は3ステップで構成される。CodeRabbit は修正 push 後も古いコメントを残すため、 現在のコードとの照合が不可欠。照合を飛ばすと修正済みの指摘を二重に対応してしまう。

Step 1: 重複・解決済みコメントのフィルタリング

CodeRabbit は修正済みコメントに「✅ Addressed in commit XXXXXXX」を追記する。 これを含むコメントは自動的にフィルタリングする。

また、同一PRで複数回レビューが走ると、古いコメントと新しいコメントが混在する。 最新のレビューサイクルのコメントのみを対象にする（created_at でフィルタ）。

Step 2: 現在のコードとの照合

フィルタリング後の各指摘について、指摘されたファイルの現在のコードを読み込み、 指摘内容が既に修正済みかどうかを判定する。

判定基準:

• 指摘箇所のコードが既に修正案どおりに変更されている → 修正済み
• 指摘箇所のコードが元のまま、または別の問題がある → 要修正

修正済みの指摘は「確認済み（対応不要）」としてカウントし、修正は行わない。

Step 3: カテゴリ分類

要修正と判定されたコメントを以下に分類する。

カテゴリ	基準	対応
Major	バグ、セキュリティ、データ整合性、未処理の非同期、整合性崩壊	必ず修正
Minor	エラーハンドリング不足、NaNチェック、未使用コード、ステール・クロージャ	修正する
Nitpick	コーディングスタイル、命名、コメント改善	修正する
Config	設定ファイル（.coderabbit.yaml等）の修正	修正する
Skip	output/ 配下のみ、docstringカバレッジ、保護ファイル(.env等)	スキップ

分類のヒント:

• CodeRabbit のラベル（_🟠 Major_, _🟡 Minor_, _🔵 Trivial_）を参考にする
• Copilot の指摘文から重要度を判断する
• 同一ファイルへの複数指摘はまとめて対応する

Phase 3: 修正方針の提示（設計ゲート）

修正を開始する前に、以下の形式で方針を提示する:

## レビュー指摘修正方針

全 N 件中: 要修正 N件 / 確認済み N件 / スキップ N件

### Major（N件）
| # | ファイル:行 | 指摘内容 | 修正方針 |
|---|------------|---------|---------|
| 1 | bikes.ts:189 | 存在しないbikeIdへの保存が成功扱い | console.warn → throw new Error |

### Minor（N件）
| # | ファイル:行 | 指摘内容 | 修正方針 |
|---|------------|---------|---------|

### 確認済み（対応不要）（N件）
| # | ファイル:行 | 指摘内容 | 確認結果 |
|---|------------|---------|---------|
| 1 | InspectionSection.tsx:60 | error状態が未使用 | 前回修正で error 表示を追加済み |

### Skip（N件）
| # | 指摘内容 | スキップ理由 |
|---|---------|------------|

この方針はユーザーに提示するが、承認を待たずに修正を開始する（自動修正モード）。 ユーザーが途中で止めたい場合は中断できる。

Phase 4: 自動修正

/implementing-features スキルに準じたワークフローで修正を実行する。

1. 対象ファイルの読み込み: 指摘されたファイルを全て読み込む
2. 修正の実施: 指摘内容に基づいてコードを修正する
   • 関連するテストも同時に修正・追加する
   • 1ファイルの複数指摘はまとめて修正する
3. サブエージェントの活用: 独立した修正は並行してサブエージェントに委譲する

修正時の原則:

• レビュアーの指摘を正確に理解し、その意図に沿った修正をする
• 指摘されていない箇所は変更しない（スコープを守る）
• 過剰な修正をしない（指摘への対応に必要な最小限の変更）
• 既存テストを壊さない

Phase 5: 検証

修正完了後、プロジェクトの検証コマンドを実行する:

# テスト実行（docs/project.md のコマンドを使う）
pnpm run test:run

# lint 実行
pnpm run lint

# 依存方向チェック（設定されている場合）
pnpm run depcruise

全て通るまで修正を繰り返す。

Phase 6: コミット＆プッシュ

全検証が通ったら、コミットしてプッシュする。

コミットメッセージ形式:

fix: CodeRabbit/Copilotレビュー指摘を修正

- <修正内容1行サマリー>
- <修正内容1行サマリー>
- ...

Co-Authored-By: Claude Opus 4.6 (1M context) <[e-mail]>

コミット対象は修正したソースファイルのみ。untracked ファイルは含めない。

Phase 7: 結果報告

下記「出力契約」のフォーマットに従って結果を報告する。

出力契約

結果報告フォーマット

Phase 7 で以下の形式で報告する:

## 修正完了

### 修正サマリー
| カテゴリ | 件数 | 対応 |
|---------|------|------|
| Major   | N件  | N件修正, N件確認済み |
| Minor   | N件  | N件修正, N件確認済み |
| Nitpick | N件  | N件修正, N件確認済み |
| Config  | N件  | N件修正, N件スキップ |
| Skip    | N件  | スキップ |

### テスト結果
- テスト: XXXX pass / 0 fail
- lint: エラー 0件
- コミット: <hash>

### 手動対応が必要な項目
- .env.example の末尾空行追加（保護ファイルのためスキップ）

必須セクション

セクション	必須	制約
修正サマリー	✅	カテゴリ別の件数・対応状況。0件でも行は残す
テスト結果	✅	テスト・lint・コミットハッシュ
手動対応が必要な項目	条件付き	自動修正対象外の指摘がある場合のみ

PASS条件: Major/Minor指摘が全て「修正」または「確認済み(却下理由あり)」のいずれか / テスト全パス・lintエラー0件 / コミットハッシュが結果報告に記載されている。

対象外（自動修正しないもの）

以下の指摘は自動修正の対象外とし、手動対応を促す:

• output/ 配下のドキュメント（PLAN, PRD等）への markdownlint 指摘
• docstring カバレッジの警告（CodeRabbit の Pre-merge checks）
• .env, .env.example 等の保護ファイル（フックでブロックされる）
• セキュリティ上のリスクがある変更（認証・認可ロジックの大幅変更等）
• アーキテクチャレベルの設計変更を要する指摘

禁止事項

• --no-verify によるフック迂回
• --force プッシュ
• 指摘されていないファイルへの変更（波及修正は除く）
• ユーザーデータの暗黙的な削除・上書き

関連参照(必要に応じて Claude が load)

@.claude/rules/git-conventions.md @.claude/quality-gates.md @.claude/pitfalls.md