review-respond

name	review-respond
description	PR レビューコメントへの対応ワークフロー。レビュー指摘の分析、コード修正、動作確認後の返信・push までを一貫して行う。
disable-model-invocation	false
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 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 で読み込む
   • 以下の観点で分析:
     • 指摘は正しいか？（バグ、パフォーマンス、Clean Architecture 違反、エラーハンドリング不備、スタイル等）
     • 修正が必要か、説明で解決できるか
     • 修正する場合の方針

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

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

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

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

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

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

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

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

   • 既存のコーディングパターンに従う（develop スキルの Phase 3 と同じルール）:
     • Clean Architecture の層境界を遵守する
     • エラーは fmt.Errorf("doing X: %w", err) でラップする
     • domain 層に外部パッケージを import しない
   • 関数の追加・変更があればテストも更新する（table-driven tests）

2. 全修正完了後、品質チェックを実行する

   make ci
   

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

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

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

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

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

   ## 修正完了サマリー
   
   ### 修正内容
   1. <ファイルパス>:<行番号> — <修正内容の説明>
      - 対応コメント: @<reviewer> "<コメント要約>"
   2. ...
   
   ### 品質チェック結果
   - lint: pass/fail
   - test: pass/fail
   - build: pass/fail
   
   ### 動作確認のお願い
   以下の点について動作確認をお願いします:
   - <確認してほしいポイント1>
   - <確認してほしいポイント2>
   

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

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

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

ユーザーの承認後:

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

   • 指摘ごとに分割してコミットする
   • コミットメッセージ: Conventional Commits 形式
     • 例: fix: clamp viewport offset to prevent negative values
   • コミット順序を提示する

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

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

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

   • 各コメントへの返信文を一覧で提示
   • 返信文は日本語で記述する（コード例・変数名・ファイルパスは英語のまま）
   • 修正したコメントの返信フォーマット:

     <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: develop スキルとの知見統合 [自律実行可]

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

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

これにより review-lessons.md を具体的インスタンスの羅列ではなく、対応可能な抽象度のガイドラインに保つ。

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

   • Phase 3 の実装時チェック観点（層境界違反防止、重複ロジック検索、エラーパス網羅等）
   • Phase 4 のテスト品質基準（アサーション品質、回帰テスト確認等）
   • Phase 7 の頻出チェックリスト（Clean Architecture 違反、エラーハンドリング、ポートインターフェース整合性等）

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

   • 完全重複: develop スキルの既存チェック項目で既にカバーされている（例: 「エラーを _ で無視」→ Phase 7 チェックリストに既存）
   • 部分重複: 既存チェック項目の具体例だが、プロジェクト固有のコンテキストを含む（例: 「blank import のデコーダ登録」→ テスト品質の一種だが gaze 固有）
   • 新規知見: develop スキルのどのチェック項目にも該当しない

3. 統合アクション:

   • 完全重複: review-lessons.md から当該エントリを削除する。develop スキルのチェックで防止できるため個別記録は不要
   • 部分重複: 具体的な PR 番号・ファイルパスを除去し、プロジェクト横断で再利用可能な抽象ルールに書き換える。フォーマット:

     ### <カテゴリ>: <抽象化した対策ルール>
     - **パターン**: <どのような状況で発生するか>
     - **対策**: <具体的に何をチェックすべきか>
     

   • 新規知見: そのまま保持する

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

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

注意事項

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