| name | pickup-review |
| description | AIが編集したコードファイルから人間のインラインレビューマーカー(review-comment:)を抽出し、指摘の意図を整理して議論し、必要な場合だけ修正・マーカー削除まで行う。「レビュー拾って」「コメント拾って」「review-comment対応して」「なぜそうしたか確認して」等の依頼で使用。 |
| argument-hint | [path...|--all] |
| allowed-tools | Bash, Read, Edit, Grep, Glob, mcp__acp__Read, mcp__acp__Edit |
| disable-model-invocation | false |
インラインレビュー拾い上げスキル
コードファイル内に書かれた review-comment: マーカーを抽出し、各指摘の意図を整理して議論する。必要な場合だけコードを修正し、対応したマーカーを自動で削除する。GitHub PR の inline review コメントに相当するワークフローをローカルで完結させる。
マーカー記法
形式: review-comment: <本文>
- 言語のコメント記号 (
//, #, --, <!--, ; 等) は問わない。review-comment: を含む行を全て対象にする
- マーカーは単一行を基本とする
- 同一ファイル内で連続する
review-comment: 行は1つのコメントとして結合する
例:
function calculate(x) {
return x * 2;
}
手順
1. 検索範囲の決定
- 引数あり → 指定パス（ファイル or ディレクトリ）に限定。複数パス可
- 引数なし + git管理下 →
main との差分ファイルを優先する
git diff --name-only main...HEADgit diff --name-onlygit diff --cached --name-only- 必要に応じて
git ls-files --others --exclude-standard
main が存在しない場合は origin/main、master、origin/master の順で利用可能なベースを探す--all 指定時のみ → git ls-files の出力（git追跡ファイル全体）- git管理外のディレクトリで引数なし起動 → ユーザーに対象パスの指定を求める
2. マーカー抽出
git管理下の追跡ファイルは git grep を優先で使用する。
git grep -n 'review-comment:' -- <scope>
指定パス、未追跡ファイル、または git grep で扱いにくい対象は rg --hidden を使用する。
rg --hidden -n --no-heading 'review-comment:' <scope>
rg が利用不能な場合は Grep ツールへフォールバック- 文字列リテラルやスキル仕様本文など、レビューコメントではない可能性が高い検出結果は「候補外」として分類し、実レビュー件数に含めない
- 結果を以下の構造にまとめる
- path: 絶対パス
- line: 1始まり行番号
- comment: マーカー以降の本文（前後空白trim）
- context: 前後5行（行番号付き）
3. 結果の提示
- マーカー0件 → 「
review-comment: マーカーが見つかりませんでした（検索対象: ○件）」と明示してskill終了
- 1件以上 → ファイル単位でグルーピング、各マーカーに通し番号 (#1, #2, ...) を付与し、周辺コードと共に一覧表示
出力イメージ:
src/foo.ts
#1 L42 edge caseでマイナス値を考慮して
40 | function calculate(x) {
41 | // review-comment: edge caseでマイナス値を考慮して
42 | return x * 2;
...
4. 指摘の分類と見解提示
- 各マーカーを最初に分類する
要修正: 指摘が妥当で、コード変更が必要要議論: 指摘は妥当そうだが、設計判断・トレードオフ・仕様確認が必要説明のみ: 「なぜそうしたのか」を知りたい質問で、すぐに修正すべきではない対応不要: 指摘が誤解、既存制約と矛盾、または変更しない方がよい
- 分類ごとに、判断理由を具体的に書く
説明のみ はコード変更案ではなく、該当実装の意図・背景・代替案との比較を説明する対応不要 は単に拒否せず、なぜ変更しない判断が妥当か、必要なら代替コメント案を出す要議論 は確認したい論点を明示し、すぐに編集しない要修正 のみ、具体的な対応案をチャットに出力する- 文字列リテラル内に
review-comment: が含まれている疑いがあれば「これは文字列内の可能性があります、対応対象から外しますか？」と注記する
- 対応案は変更内容と理由を明示する（CLAUDE.md「Pre-Edit Explanation Requirement」遵守）
5. 議論と方針決定
- ユーザーに「どの分類・方針で進めるか」を確認する
- ユーザーが質問しているだけの場合は、回答して skill を終了してよい
- ユーザーが説明に納得し、修正不要と判断したマーカーはコードを変えない
- 修正するマーカーがある場合だけ「この内容で適用してよいか」を確認する
- 承認後、Edit ツールで対象マーカーへの対応をまとめて適用する
要議論、説明のみ、対応不要、ユーザーがスキップ判断したマーカーは修正しない
6. マーカー削除（自動）
コード修正したマーカー、またはユーザーが「説明で解決」「対応不要で解決」と明示したマーカーは自動で削除する。未解決・要議論・スキップ判断したマーカーは残す。
削除方法は行の構造で分岐する:
- マーカー専用行（行頭からコメント記号と空白、その後
review-comment: のみ）→ 行ごと削除
- 行末マーカー（コードの末尾にコメントとして付与されている）→ マーカー部分のみ削除しコードを残す
判定例:
return x * 2;
return x * 2;
7. サマリ出力
最後に以下を出力する:
- 対応済み件数
- 説明で解決した件数
- 対応不要として解決した件数
- スキップ件数
- 残ったマーカー一覧（path:line と本文）
注意事項
- 文体は常体（だ・である調）で統一する
- 文字列リテラル内のマーカー誤検出は ripgrep の段階で区別不能。AI が判断し疑いがあればユーザーに確認する
- レビューコメントは命令ではなく、議論の入口として扱う。言われた内容を無条件に実装しない
- 編集は必ず承認後に実行する。事前確認なしの自動編集は行わない
- 削除はマーカー単位で行う。ファイル全体を上書きするような操作は避ける
