review-respond

name	review-respond
description	PR レビューコメントへの対応ワークフロー。レビュー指摘の分析、コード修正、セルフレビュー、動作確認後の返信・push までを一貫して行う。
argument-hint	["PR番号（省略時はカレントブランチのPR）"]

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

このスキルは develop スキルで作成した PR に対するレビューコメントへの対応を行います。 指摘の妥当性分析 → コード修正 → セルフレビュー → ユーザー動作確認 → コミット・返信・push の流れで進めます。

現在のリポジトリ状態

• ブランチ: !git branch --show-current
• Git状態: !git status --short
• 直近コミット: !git log --oneline -5

フェーズ間のユーザー確認ルール

• 確認必須: Phase 1（分析・方針）、Phase 3（検証結果の提示・動作確認依頼）、Phase 4（返信内容・push）
• 自律実行可: Phase 2（コード修正）、Phase 2.5（セルフレビュー）、Phase 5（知見記録）、Phase 6（知見統合）
  • ただし問題が発生した場合や判断に迷う場合はユーザーに確認すること

ワークフロー

Phase 1: レビューコメント取得と分析 [確認必須]

1. 対象 PR を特定する

   • 引数 $ARGUMENTS に PR 番号が指定されていればそれを使う
   • 省略時はカレントブランチの PR を使う: gh pr view --json number --jq '.number'
   • PR が見つからない場合はエラーを報告して終了する

2. 未対応のレビューコメント（行コメントのみ）を取得する

   現在のユーザー(login)を取得

   CURRENT_USER=$(gh api user --jq '.login')

   PR のレビューコメント一覧を取得

   gh api repos/{owner}/{repo}/pulls/{pr_number}/comments

3. 未対応コメントごとに、対象コードを読み込み妥当性を分析する

   • コメントの位置情報（path + line / original_line、あるいは start_line / original_start_line + line / original_line、side / start_side など）から、コメントが指しているコード範囲を特定する
   • 単一行コメントだけでなく、複数行コメントの場合は開始〜終了行を含む範囲と、その前後数行を対象ファイルから Read で読み込む
   • CLAUDE.md に記載のプロジェクト品質基準に照らして分析する:
     • 指摘は正しいか？（バグ、ドキュメント不備、パフォーマンス、スタイル等）
     • 修正が必要か、説明で解決できるか
     • 修正する場合の方針

4. 分析結果を以下の形式でユーザーに提示する

   ## PR #<number> レビュー対応
   
   ### 未対応コメント: <件数>件
   
   #### 1. <ファイルパス>:<行番号> (@<reviewer>)
   > <コメント本文の要約>
   
   **分析**: <妥当性の判断と理由>
   **推奨対応**: 修正する / 返信のみ / 対応不要
   **修正方針**: <修正する場合の具体的な方針>
   
   #### 2. ...
   

5. ユーザーに各コメントへの対応方針を確認する

   • ユーザーが方針を変更した場合はそれに従う
   • 追加の指示があればメモする

重要: この段階では絶対にコードを書かないこと。Read/Grep/Glob のみ使用する。

Phase 2: コード修正と品質チェック [自律実行可]

Phase 1 で「修正する」と決まったコメントに対して:

1. コメントごとに修正を実装する

   • CLAUDE.md に記載のコーディングパターンに従う（develop スキルの Phase 3 と同じルール）
   • プロジェクトの /pj-checklist スキルが存在する場合は、その実装チェックリストも適用する
   • 関数の追加・変更があればテストも更新する
   • テスト修正時、テストの説明文が実際の検証内容と一致しているか確認する

2. 同クラスの問題を網羅的に検索する 指摘の本質を抽象化し、同パターンが他箇所にないか Grep で検索する: a. 指摘の本質を1文で言語化する（例: 「非同期コールバックが古い state を参照し続ける」） b. 該当するコード構造を特定する（例: 「state キャプチャ後に callback 登録する全箇所」） c. Grep で全箇所を列挙し、同じ問題がないか確認する d. 問題があれば指摘されていなくても修正する

   よくあるパターンと検索方法:

   • 状態参照問題: 状態キャプチャ箇所を Grep → callback 内のガード確認
   • 通知の二重化: 修正関数内 + 呼び出し先の通知呼び出しを両方 Grep
   • リソースリーク: 同種リソースの作成・解放ペアを全箇所で確認
   • ドキュメント不一致: 修正パラメータのドキュメント全言及箇所を Grep

3. 全修正完了後、CLAUDE.md に記載の品質チェックコマンドを実行する

   • 失敗時は修正して再実行（3回連続失敗でユーザーに相談）

4. 修正内容のサマリーを作成する

   • 各コメントに対してどのファイルのどの部分を修正したか
   • テストの追加・変更があればその内容

Phase 2.5: セルフレビュー [自律実行可]

Phase 2 の修正完了後、/self-review スキルを呼び出してセルフレビューを実行する。

セルフレビューの結果は Phase 3 の提示内容に含める。

Phase 3: ユーザー動作確認 [確認必須]

1. 修正内容のサマリーをユーザーに提示する

   ## 修正完了サマリー
   
   ### 修正内容
   1. <ファイルパス>:<行番号> — <修正内容の説明>
      - 対応コメント: @<reviewer> "<コメント要約>"
   2. ...
   
   ### 品質チェック結果
   - lint: pass/fail
   - format: pass/fail
   - test: pass/fail
   
   ### セルフレビュー結果
   - 検出・修正した問題（あれば）
   - 残っている懸念事項（あれば）
   
   ### 動作確認のお願い
   以下の点について動作確認をお願いします:
   - <確認してほしいポイント1>
   - <確認してほしいポイント2>
   

2. ユーザーの動作確認結果を待つ

   • 問題があれば Phase 2 に戻って修正
   • 問題なければ Phase 4 に進む

Phase 4: コミット・返信・push [確認必須]

ユーザーの承認後:

1. コミット計画をユーザーに提示する

   • 指摘ごとに分割してコミットする
   • コミットメッセージ: Conventional Commits 形式
   • コミット順序を提示する

2. ユーザーの承認後にコミットを実行する

   • 各コメントへの修正を個別にコミット
   • 「返信のみ」のコメントにはコミットは不要

3. 返信内容をユーザーに提示する

   • 各コメントへの返信文を一覧で提示
   • CLAUDE.md の PR/Commit Conventions に言語指定がある場合はそれに従う
   • 修正したコメントの返信フォーマット:

     <short-sha> で修正 — <修正内容の簡潔な説明>
     

   • 返信のみのコメントの返信フォーマット:

     <説明文>
     

   • 対応不要のコメントの返信フォーマット（ユーザーが返信を希望した場合のみ）:

     <対応しない理由の説明>
     

4. ユーザーの承認後に返信を実行する

   gh api repos/{owner}/{repo}/pulls/{pr_number}/comments \
     -f body="<sha> で修正 — <説明>" \
     -F in_reply_to=<comment_id>
   

5. push する

   git push
   

6. 完了サマリーを表示する

   ## 完了
   
   - コミット: <件数>件
   - 返信: <件数>件
   - push: done
   
   PR: <PR URL>
   

Phase 5: レビュー知見の記録 [自律実行可]

Phase 4 完了後、今回のレビュー指摘から再発防止に役立つパターンを .claude/review-lessons.md に記録する。

1. 今回の指摘を以下の観点で分類する:

   • コード品質: エラーハンドリング、命名、重複ロジック等
   • アーキテクチャ: 設計制約違反、インターフェース設計等
   • テスト: カバレッジ不足、アサーション品質等
   • ドキュメント: 実装との不整合、記載漏れ等
   • エッジケース: 境界値、異常系の考慮不足等

2. .claude/review-lessons.md を読み込み（存在しない場合は新規作成）、以下のフォーマットで追記する:

   ### <カテゴリ>: <指摘の要約> (PR #<number>, <日付>)
   - **問題**: <何が問題だったか>
   - **対策**: <今後の開発で何をチェックすべきか>
   - **該当箇所**: <ファイルパス>
   

3. 既に同様のパターンが記録されている場合は重複追記しない。既存エントリの該当箇所に追記するか、スキップする。

4. 記録が20件を超えた場合は、古い・重要度の低いエントリを統合または削除して簡潔に保つ。

Phase 6: 知見統合 [自律実行可]

Phase 5 完了後、蓄積されたレビュー知見と /pj-checklist の既存チェック体系との重複を検出し、統合する。

.claude/review-lessons.md が存在しないか、エントリが 0 件の場合は、本フェーズ全体をスキップしてよい。

1. 重複検出: .claude/review-lessons.md の各エントリを、/pj-checklist（.claude/skills/pj-checklist/SKILL.md）のチェック体系と照合する

2. 分類: 各レビュー知見を以下のいずれかに分類する:

   • 完全重複: /pj-checklist の既存チェック項目で既にカバーされている
   • 部分重複: 既存チェック項目の具体例だが、プロジェクト固有のコンテキストを含む
   • 新規知見: /pj-checklist のどのチェック項目にも該当しない

3. 統合アクション:

   • 完全重複: review-lessons.md から当該エントリを削除する
   • 部分重複: 具体的な PR 番号・ファイルパスを除去し、再利用可能な抽象ルールに書き換える
   • 新規知見: そのまま保持する

4. 統合結果の報告: 統合を実施した場合、以下をユーザーに報告する:

   ## レビュー知見の統合
   - 削除（完全重複）: <件数>件
   - 抽象化（部分重複）: <件数>件
   - 保持（新規知見）: <件数>件
   

5. harness-audit の起動提案: 統合後の .claude/review-lessons.md のエントリ（### 見出し）が 15 件を超えた、または前回の /harness-audit 実施から 3 ヶ月以上経過した場合、ユーザーに /harness-audit の起動を提案する（必須ではなく目安）。詳細は .claude/HARNESS.md の Steering Loop 節を参照

注意事項

• 破壊的な操作（force push, reset --hard, checkout ., clean -f 等）は絶対に行わないこと
• レビューコメントへの返信は gh api の REST API を使用する（gh pr review ではなくコメント単位の返信）
• 返信の際は in_reply_to を必ず指定してスレッドに返信する（新規コメントにしない）
• コミットは指摘ごとに分割する。複数の指摘が同一ファイルの同一箇所に関する場合のみまとめてよい