cursor-reviewer

name	cursor-reviewer
description	reviewerエージェントにローカルの差分・ファイルをレビューさせる。バグ・セキュリティ・パフォーマンス・保守性・命名一貫性・リグレッション・データアクセス重複などの観点でレビューし VERDICT: PASS/FAIL を返す。「reviewerに見せて」「reviewer」「ローカルの差分を見て」といった要望に使う。PR番号・リモートブランチ・gh pr 経由のレビューは /cursor-review-pr を使うこと。ユーザーが /cursor-reviewer と入力したら必ずこのスキルを使う。
argument-hint	[レビュー範囲の指定（例: ファイルパス、ブランチ名、コミット範囲。省略時は未コミットの差分）]

Reviewer — コードレビュー

reviewer エージェントにコードレビューを実行させます。このスキル本体（= メインエージェント）がオーケストレーターとなり、reviewer を Task ツールで ハイブリッド並列起動（correctness / consistency / quality / security / architecture の 5 観点から必要なものを選択して 1〜5 体）します。子 subagent からの Task 起動は Cursor では制限されるため、起動責任はスキル本体に集約されます。

レビュー範囲: $ARGUMENTS

---

ステップ 0: メモリパスと RUN_DIR の確定

以下の Bash コマンドで PROJECT_ROOT / PROJECT_MEMORY_DIR / RUN_DIR を確定し、以降のすべてのステップで使用してください:

PROJECT_ROOT="$(pwd)"
# sanitized-cwd 計算は .cursor/skills/cursor-pir2/references/sanitized-cwd.md を SSOT とする
# （Codex harness の sanitize 仕様変更時はこの SSOT のみを更新し、9 ファイルに横展開）
sanitized_cwd="$(pwd | sed 's|[^a-zA-Z0-9]|-|g')"
PROJECT_MEMORY_DIR="${HOME}/.cursor/projects/${sanitized_cwd}/memory"
run_ts="$(date +%Y%m%d-%H%M%S)"
run_feature="$(printf '%s' "$ARGUMENTS" | tr -c 'a-zA-Z0-9' '-' | sed -E 's/-+/-/g; s/^-//; s/-$//' | cut -c1-40)"
[ -z "$run_feature" ] && run_feature="task"
RUN_DIR="${HOME}/.ai-pir-runs/${sanitized_cwd}/${run_ts}-${run_feature}"
mkdir -p "$RUN_DIR"
echo "PROJECT_ROOT=$PROJECT_ROOT"
echo "PROJECT_MEMORY_DIR=$PROJECT_MEMORY_DIR"
echo "RUN_DIR=$RUN_DIR"

/cursor-reviewer は handoff 連携を行わないため、HANDOFF_PATH / RESUME_MODE は不要です。

---

ステップ 1: レビュー対象の特定

まず $ARGUMENTS から --reviewers=<roles> と --all-reviewers フラグを抽出して除去し、残りをレビュー範囲指定として扱う。次に残り部分に応じてレビュー対象を決定する:

• 指定なし: git diff --name-only HEAD で未コミットの差分を取得
• ファイルパス: 指定されたファイルをそのまま対象とする
• ブランチ名: git diff --name-only <branch>...HEAD でブランチとの差分を取得
• コミット範囲（例: HEAD~3..HEAD）: git diff --name-only <range> で差分を取得

対象ファイルが0件の場合はユーザーに報告して終了する。

---

ステップ 2: レビュー実行 (coding ハイブリッド並列)

2-1: REVIEWER_SET 決定（非 planner 系：自動選定がデフォルト）

REVIEWER_SET を決定する:

1. ユーザーフラグ: ステップ 1 で抽出した --reviewers=<roles> があればカンマ区切りを観点集合として採用（未知 role は無視）。--all-reviewers があれば全 5 観点。両方指定時は --reviewers= を優先
2. フラグ未指定時の自動選定（以下を上から評価）:
   1. correctness は常に含める
   2. 対象ファイル一覧にコード拡張子が含まれる（ドキュメント・設定のみでない） → consistency を追加
   3. レビュー範囲指定テキストまたは差分テキスト（git diff <range> の出力）にセキュリティ関連語句（認証 / 認可 / auth / token / secret / password / credential / SQL / XSS / CSRF / シリアライズ / 外部API / ユーザー入力 / validate / sanitize / 権限 / 暗号 / crypto / 脆弱性）が含まれる → security を追加
   4. 差分に新規ファイル追加 (git diff --diff-filter=A) または複数モジュール/レイヤー跨ぎ（対象ファイルが 2 つ以上の異なるトップレベルディレクトリにまたがる） → architecture を追加
   5. 差分に新規関数・メソッド・クラスの追加、または差分行数 > 20 行 → quality を追加
   6. 判断に迷う（差分が取得できない・範囲が曖昧・上記ルールで 1 体しか選ばれないが自信なし） → 全 5 観点にフォールバック
3. 決定した REVIEWER_SET をユーザー提示に含める

2-2A: 起動宣言（Fan-Out Gate — 並列発火の直前に必ず書く）

reviewer 並列起動メッセージを送信する 直前のターン本文中 に、以下のテンプレートを必ず生成すること。このテンプレートが本文に出現していないターンで Agent 起動を発火させた場合は、ステップ完了判定を取り消して 2-2A からやり直す。

Fan-Out Gate（reviewer）

• REVIEWER_SET = [<観点をカンマ区切りで全列挙>]
• 起動体数 = （= len(REVIEWER_SET)、必ず一致）
• 同一 function_calls ブロックに 個の Agent 起動を並べる
• 1 体ずつ起動・後追い起動・観点削減はいずれも違反

このブロックは「起動直前の自己コミットメント」であり、自分の手癖（1 体ずつ逐次起動する癖）を止めるためのフェンスとして機能する。

2-2B: 並列発火（同一メッセージ内）

直前ターンで宣言した REVIEWER_SET の各観点について、同一の <function_calls> ブロック内に Task subagent呼び出しを N 個 並べて 1 メッセージで同時送信する。各体は REVIEWER_ROLE を変えて担当観点を分割する。

詳細仕様（観点マッピング / 違反パターンと検出 / 違反検出時のリカバリ / reviewer 起動パラメータ）: .cursor/skills/cursor-pir2/references/fan-out-gate.md を参照。

違反パターン（次のいずれかが発生したら違反として検出し 2-2A からやり直す）:

• function_calls ブロックが 2 ターン以上に分かれる
• 並んだ Agent 起動の数が宣言した N より少ない
• 観点を独自判断で減らした
• 直前ターンの宣言テンプレートが省略された

各体の起動パラメータ:

• model: role=coding
• プロンプト（共通。REVIEWER_ROLE のみ変える）:
  • PROJECT_MEMORY_DIR=[ステップ0で取得したパス]
  • RUN_DIR=[ステップ0で取得したパス]
  • REVIEW_INDEX=01（起動する全体で同じ番号を共有する）
  • REVIEWER_ROLE=[correctness|consistency|quality|security|architecture]（体ごとに変える。REVIEWER_SET に含まれる観点のみ）
  • レビュー対象のファイル一覧
  • 差分の取得コマンド（ステップ1で使用したものと同じ git diff コマンド。--name-only を外したもの）
  • 「plan.md / implementation-*.md は存在しません。上記の差分コマンドで変更内容を確認し、変更されたファイルを Read してレビューしてください。レビューレポート本体は {RUN_DIR}/review-{REVIEW_INDEX}-{REVIEWER_ROLE}.md に書き出し、チャットには VERDICT + 要約のみ返してください」

---

ステップ 3: 結果の統合・提示

起動した reviewer の VERDICT と書き出したレポートをユーザーに提示する:

VERDICT 集約

• 全体 VERDICT = PASS: 起動した全員が VERDICT: PASS
• 全体 VERDICT = FAIL: 1体でも VERDICT: FAIL

ユーザーへの提示フォーマット

## レビュー完了

### 全体 VERDICT
[PASS|FAIL]

### REVIEWER_SET
[起動した観点のカンマ区切り、例: correctness,consistency,security]

### 観点別 VERDICT
（REVIEWER_SET に含まれる観点のみ。例）
- correctness: [PASS|FAIL] — {RUN_DIR}/review-01-correctness.md
- consistency: [PASS|FAIL] — {RUN_DIR}/review-01-consistency.md
- security: [PASS|FAIL] — {RUN_DIR}/review-01-security.md

### 主な指摘事項（Critical / High のみ）
- [深刻度] `ファイル:行` — [問題の要約]（出典: [ROLE]）

各 reviewer が書き出した {RUN_DIR}/review-01-{ROLE}.md を Read して、Critical / High の問題一覧を統合してユーザーに提示する。Medium / Low は件数サマリーのみに留める（詳細はファイル参照）。