pickup-review

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) {
  // review-comment: edge caseでマイナス値を考慮して
  return x * 2;
}

手順

1. 検索範囲の決定

• 引数あり → 指定パス（ファイル or ディレクトリ）に限定。複数パス可
• 引数なし + git管理下 → main との差分ファイルを優先する
  • git diff --name-only main...HEAD
  • git diff --name-only
  • git 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: のみ）→ 行ごと削除
• 行末マーカー（コードの末尾にコメントとして付与されている）→ マーカー部分のみ削除しコードを残す

判定例:

// 行ごと削除されるパターン
  // review-comment: マイナス値を考慮して

// マーカー部分のみ削除されるパターン
  return x * 2;  // review-comment: 戻り値の型を見直して
  // ↓
  return x * 2;

7. サマリ出力

最後に以下を出力する:

• 対応済み件数
• 説明で解決した件数
• 対応不要として解決した件数
• スキップ件数
• 残ったマーカー一覧（path:line と本文）

注意事項

• 文体は常体（だ・である調）で統一する
• 文字列リテラル内のマーカー誤検出は ripgrep の段階で区別不能。AI が判断し疑いがあればユーザーに確認する
• レビューコメントは命令ではなく、議論の入口として扱う。言われた内容を無条件に実装しない
• 編集は必ず承認後に実行する。事前確認なしの自動編集は行わない
• 削除はマーカー単位で行う。ファイル全体を上書きするような操作は避ける