Menu
PR レビューコメントへの対応ワークフロー。レビュー指摘の分析、コード修正、セルフレビュー、動作確認後の返信・push までを一貫して行う。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
fude.nvim のローカルレビューセッションを監視し、新しいレビューコメントに自動で応答する。人間が Neovim でコメントを書くと、このセッションが検知してコード修正や返信を JSONL に追記する。「レビュー待受して」「fude watch して」等で起動する。
ハーネス点検ワークフロー。直近 PR レビューから pj-checklist の発火率と review-lessons.md の健全性を評価し、harness の改善案をユーザーに提示する。
fude.nvim プロジェクト固有の実装・レビューチェックリスト。Lua/Neovim パターン、非同期処理、state 管理の注意点。
開発ワークフロー。計画から実装、テスト、ドキュメント、セルフレビュー、PR作成までを一貫して行う。
コミット分割、コミット実行、draft PR 作成を行う。
3ラウンドのセルフレビュー。プロジェクト固有チェックリスト（2ラウンド）と /review 汎用レビュー（1ラウンド）で変更品質を検証する。
| name | review-respond |
| description | PR レビューコメントへの対応ワークフロー。レビュー指摘の分析、コード修正、セルフレビュー、動作確認後の返信・push までを一貫して行う。 |
| argument-hint | ["PR番号（省略時はカレントブランチのPR）"] |
このスキルは develop スキルで作成した PR に対するレビューコメントへの対応を行います。 指摘の妥当性分析 → コード修正 → セルフレビュー → ユーザー動作確認 → コミット・返信・push の流れで進めます。
git branch --show-currentgit status --shortgit log --oneline -5対象 PR を特定する
$ARGUMENTS に PR 番号が指定されていればそれを使うgh pr view --json number --jq '.number'未対応のレビューコメント（行コメントのみ）を取得する
CURRENT_USER=$(gh api user --jq '.login')
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments
未対応コメントごとに、対象コードを読み込み妥当性を分析する
path + line / original_line、あるいは start_line / original_start_line + line / original_line、side / start_side など）から、コメントが指しているコード範囲を特定する分析結果を以下の形式でユーザーに提示する
## PR #<number> レビュー対応
### 未対応コメント: <件数>件
#### 1. <ファイルパス>:<行番号> (@<reviewer>)
> <コメント本文の要約>
**分析**: <妥当性の判断と理由>
**推奨対応**: 修正する / 返信のみ / 対応不要
**修正方針**: <修正する場合の具体的な方針>
#### 2. ...
ユーザーに各コメントへの対応方針を確認する
重要: この段階では絶対にコードを書かないこと。Read/Grep/Glob のみ使用する。
Phase 1 で「修正する」と決まったコメントに対して:
コメントごとに修正を実装する
/pj-checklist スキルが存在する場合は、その実装チェックリストも適用する同クラスの問題を網羅的に検索する 指摘の本質を抽象化し、同パターンが他箇所にないか Grep で検索する: a. 指摘の本質を1文で言語化する（例: 「非同期コールバックが古い state を参照し続ける」） b. 該当するコード構造を特定する（例: 「state キャプチャ後に callback 登録する全箇所」） c. Grep で全箇所を列挙し、同じ問題がないか確認する d. 問題があれば指摘されていなくても修正する
よくあるパターンと検索方法:
全修正完了後、CLAUDE.md に記載の品質チェックコマンドを実行する
修正内容のサマリーを作成する
Phase 2 の修正完了後、/self-review スキルを呼び出してセルフレビューを実行する。
セルフレビューの結果は Phase 3 の提示内容に含める。
修正内容のサマリーをユーザーに提示する
## 修正完了サマリー
### 修正内容
1. <ファイルパス>:<行番号> — <修正内容の説明>
- 対応コメント: @<reviewer> "<コメント要約>"
2. ...
### 品質チェック結果
- lint: pass/fail
- format: pass/fail
- test: pass/fail
### セルフレビュー結果
- 検出・修正した問題（あれば）
- 残っている懸念事項（あれば）
### 動作確認のお願い
以下の点について動作確認をお願いします:
- <確認してほしいポイント1>
- <確認してほしいポイント2>
ユーザーの動作確認結果を待つ
ユーザーの承認後:
コミット計画をユーザーに提示する
ユーザーの承認後にコミットを実行する
返信内容をユーザーに提示する
<short-sha> で修正 — <修正内容の簡潔な説明>
<説明文>
<対応しない理由の説明>
ユーザーの承認後に返信を実行する
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments \
-f body="<sha> で修正 — <説明>" \
-F in_reply_to=<comment_id>
push する
git push
完了サマリーを表示する
## 完了
- コミット: <件数>件
- 返信: <件数>件
- push: done
PR: <PR URL>
Phase 4 完了後、今回のレビュー指摘から再発防止に役立つパターンを .claude/review-lessons.md に記録する。
今回の指摘を以下の観点で分類する:
.claude/review-lessons.md を読み込み（存在しない場合は新規作成）、以下のフォーマットで追記する:
### <カテゴリ>: <指摘の要約> (PR #<number>, <日付>)
- **問題**: <何が問題だったか>
- **対策**: <今後の開発で何をチェックすべきか>
- **該当箇所**: <ファイルパス>
既に同様のパターンが記録されている場合は重複追記しない。既存エントリの該当箇所に追記するか、スキップする。
記録が20件を超えた場合は、古い・重要度の低いエントリを統合または削除して簡潔に保つ。
Phase 5 完了後、蓄積されたレビュー知見と /pj-checklist の既存チェック体系との重複を検出し、統合する。
.claude/review-lessons.md が存在しないか、エントリが 0 件の場合は、本フェーズ全体をスキップしてよい。
重複検出: .claude/review-lessons.md の各エントリを、/pj-checklist（.claude/skills/pj-checklist/SKILL.md）のチェック体系と照合する
分類: 各レビュー知見を以下のいずれかに分類する:
/pj-checklist の既存チェック項目で既にカバーされている/pj-checklist のどのチェック項目にも該当しない統合アクション:
review-lessons.md から当該エントリを削除する統合結果の報告: 統合を実施した場合、以下をユーザーに報告する:
## レビュー知見の統合
- 削除（完全重複）: <件数>件
- 抽象化（部分重複）: <件数>件
- 保持（新規知見）: <件数>件
harness-audit の起動提案: 統合後の .claude/review-lessons.md のエントリ（### 見出し）が 15 件を超えた、または前回の /harness-audit 実施から 3 ヶ月以上経過した場合、ユーザーに /harness-audit の起動を提案する（必須ではなく目安）。詳細は .claude/HARNESS.md の Steering Loop 節を参照
gh api の REST API を使用する（gh pr review ではなくコメント単位の返信）in_reply_to を必ず指定してスレッドに返信する（新規コメントにしない）