cursor-ir

name	cursor-ir
description	軽量な Implement → Review の2フェーズワークフロー。タスクが明確で小さい場合に使う。バグ修正・小機能追加・設定変更・ファイル修正など、計画不要で「サクッとやって」「これ直して」「簡単な変更」といった要望に対応する。ユーザーが /cursor-ir と入力したら必ずこのスキルを使う。
argument-hint	[タスクの説明]

Cursor 実行時の注意（第2波）

• 子エージェントは Task ツール（subagent_type）で起動する。Claude の Agent ツール語彙は使わない
• メインエージェントがオーケストレーター。VERDICT ループ・ユーザー確認ゲート・ループカウンタはメインが保持する
• Claude 専用機能（TeamCreate / Agent Teams / ~/.claude/hooks）は Cursor では非対応のためスキップする（必要なら通常の直列 Task 起動へ縮退）
• ベンダーモデル名（reasoning / coding / reasoning 等）はハードコードしない。agent overlay の role=reasoning|coding と Cursor UI の運用既定に従う

IR — Implement → Review

軽量ワークフローを実行します。プランニング・振り返りなしで、小さいタスクに使います。このスキル本体（= メインエージェント）がオーケストレーターとなり、implementer / reviewer を Task ツールで順に起動します。子 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-ir は handoff 連携を行わないため、HANDOFF_PATH / RESUME_MODE は不要です。

---

ステップ 1: 実装 (role=coding)

スキル本体（メインエージェント）が implementer subagentを Task ツールで起動してください。

• role: coding（モデル名はピンしない）
• プロンプト:
  • PROJECT_MEMORY_DIR=[パス]
  • RUN_DIR=[パス]
  • IMPL_INDEX=01（初回。再実装時はインクリメント）
  • タスク内容（$ARGUMENTS）
  • 「プランなしで直接実装してください。plan.md は存在しません。実装完了レポート本体は {RUN_DIR}/implementation-{IMPL_INDEX}.md に書き出し、チャットには要約のみ返してください」

実装要約を受け取ったら次のステップへ進んでください。

---

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

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

REVIEWER_SET を決定する:

1. ユーザーフラグのパース: $ARGUMENTS に --reviewers=<roles> が含まれていればカンマ区切りを観点集合として採用（未知 role は無視）。--all-reviewers が含まれていれば全 5 観点を採用。両方指定時は --reviewers= を優先。フラグ抽出後の残りをタスク説明として扱う
2. フラグ未指定時の自動選定（以下を上から評価し該当観点を集合に追加）:
   1. correctness は常に含める（動作正否の最低限ゲート）
   2. 実装がコード変更を含む（ドキュメント・設定のみでない。implementer 返り値の変更ファイル一覧で判定） → consistency を追加
   3. タスク文言または {RUN_DIR}/implementation-{IMPL_INDEX}.md の差分テキストにセキュリティ関連語句（認証 / 認可 / auth / token / secret / password / credential / SQL / XSS / CSRF / シリアライズ / 外部API / ユーザー入力 / validate / sanitize / 権限 / 暗号 / crypto / 脆弱性）が含まれる → security を追加
   4. 実装で新規ファイル追加・新規ディレクトリ作成・複数モジュール/レイヤー跨ぎ → architecture を追加
   5. 実装で新規関数・メソッド・クラスの追加、またはロジック変更行数 > 20 行 → quality を追加
   6. 判断に迷う（implementation-*.md が読めない・タスク文言が曖昧・上記ルールで 1 体しか選ばれないが自信なし） → 全 5 観点にフォールバック
3. 決定した REVIEWER_SET を最終サマリー（ステップ 4）に記録

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

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

Fan-Out Gate（reviewer）

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

このブロックは「起動直前の自己コミットメント」であり、自分の手癖（1 体ずつ逐次起動する癖）を止めるためのフェンスとして機能する。再レビュー時（ステップ 3 の差し戻し時）にも毎回この宣言を書くこと。

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 より少ない
• 観点を独自判断で減らした
• 直前ターンの宣言テンプレートが省略された

各体の起動パラメータ:

• role: coding（モデル名はピンしない）
• プロンプト（共通。REVIEWER_ROLE のみ変える）:
  • PROJECT_MEMORY_DIR=[パス]
  • RUN_DIR=[パス]
  • REVIEW_INDEX=01（初回。再レビュー時はインクリメント。起動する全体で同じ番号を共有する）
  • REVIEWER_ROLE=[correctness|consistency|quality|security|architecture]（体ごとに変える。REVIEWER_SET に含まれる観点のみ）
  • {RUN_DIR}/implementation-{最新 IMPL_INDEX}.md のパス
  • 「plan.md は存在しません。implementation-*.md のみをレビュー対象としてください。レビューレポート本体は {RUN_DIR}/review-{REVIEW_INDEX}-{REVIEWER_ROLE}.md に書き出し、チャットには VERDICT + 要約のみ返してください」

VERDICT 集約

今回起動した reviewer の VERDICT を以下のルールで集約する:

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

---

ステップ 3: レビューループ (最大2回)

LOOP_COUNT = 0 から始めてください。

全体 VERDICT: FAIL の場合:

1. LOOP_COUNT += 1
2. LOOP_COUNT >= 2 に達した場合はループを終了してステップ4へ進む
3. implementer を再起動する（IMPL_INDEX をインクリメント、FAIL を返した全 reviewer の {RUN_DIR}/review-{最新}-{ROLE}.md パスを全てレビュー指摘事項として渡す、元のタスク内容も渡す）
4. 2-2A（Fan-Out Gate 宣言）→ 2-2B（並列発火）の手順で reviewer を 同じ REVIEWER_SET で並列で再起動して VERDICT を確認する（REVIEW_INDEX をインクリメント、最新の {RUN_DIR}/implementation-{最新}.md のパスを渡す。PASS を返した観点も再レビューする。観点集合は初回選定を維持し途中で追加・削除しない。再レビュー時も Fan-Out Gate を省略しないこと）
5. 全体 FAIL なら繰り返す

全体 VERDICT: PASS になったらステップ4へ進んでください。

---

ステップ 4: 最終サマリーの提示

## IR 完了サマリー

### タスク
[タスクの説明]

### 変更ファイル
[実装完了レポートから抜粋]

### レビュー結果
- 最終 VERDICT: [PASS/FAIL]
- ループ回数: [LOOP_COUNT]
- REVIEWER_SET: [起動した観点をカンマ区切り、例: correctness,consistency]
- 観点別の VERDICT: [REVIEWER_SET に含まれる観点のみ。例: correctness=[...], consistency=[...]]
- [主な指摘事項があれば記載]