メニュー
コーディングタスクを Plan → Implement → Review → Retrospect の4フェーズで実行する。複雑なタスク・設計が必要なタスク・品質保証が重要なタスク、大きな機能追加・リファクタリング・アーキテクチャ変更に使う。「ちゃんと作りたい」「しっかり実装して」「品質重視で」といった要望にも対応する。ユーザーが /cursor-pir2 と入力したら必ずこのスキルを使う。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
codex（OpenAI のコーディングエージェント）に codex CLI 経由で相談するスキル。第二意見・別アプローチ・難所のレビューを codex に求めるときに使う。CLI の実行と完走管理は codex-runner サブエージェントが担い、メインエージェントは codex-runner を background で起動して即座に別作業へ移る（何時間かかってもブロックされない）。タスクの重さに応じて reasoning effort と model（GPT-5.6 系）を毎回明示的に選び（既定任せにしない）、相談・レビューは sandbox=read-only。「codexに聞いて」「codexの意見」「codexに相談」「codexならどうする」「ask codex」「second opinion from codex」などで起動する。呼び出し元自身がタスク途中で codex に相談すると判断したときも、本スキルの手順が SSOT になる。ユーザーが /codex と入力したら必ずこのスキルを使う。
codex（OpenAI のコーディングエージェント）に codex CLI 経由で相談するスキル。第二意見・別アプローチ・難所のレビューを codex に求めるときに使う。CLI の実行と完走管理は codex-runner サブエージェントが担い、メイン Claude は codex-runner を background で起動して即座に別作業へ移る（何時間かかってもブロックされない）。タスクの重さに応じて reasoning effort と model（GPT-5.6 系）を毎回明示的に選び（既定任せにしない）、相談・レビューは sandbox=read-only。「codexに聞いて」「codexの意見」「codexに相談」「codexならどうする」「ask codex」「second opinion from codex」などで起動する。Claude 自身がタスク途中で codex に相談すると判断したときも、本スキルの手順が SSOT になる。ユーザーが /codex と入力したら必ずこのスキルを使う。
codex（OpenAI のコーディングエージェント）に codex CLI 経由で相談するスキル。第二意見・別アプローチ・難所のレビューを codex に求めるときに使う。CLI の実行と完走管理は codex-runner サブエージェントが担い、メインエージェントは codex-runner を background で起動して即座に別作業へ移る（何時間かかってもブロックされない）。タスクの重さに応じて reasoning effort と model（GPT-5.6 系）を毎回明示的に選び（既定任せにしない）、相談・レビューは sandbox=read-only。「codexに聞いて」「codexの意見」「codexに相談」「codexならどうする」「ask codex」「second opinion from codex」などで起動する。呼び出し元自身がタスク途中で codex に相談すると判断したときも、本スキルの手順が SSOT になる。ユーザーが /cursor-codex と入力したら必ずこのスキルを使う。
PIR² の Codex 実装版。Plan→Review→Retrospect は Claude のまま、Implement フェーズだけ Codex（codex CLI / codex-runner サブエージェント経由）に差し替えた実験的ワークフロー。Codex 実装の品質を通常 /pir2 と比較するために使う。大きく結合した実装は IMPLEMENTATION_UNITS による直列 fresh セッション化に対応。ユーザーが /pir2codex と入力したら必ずこのスキルを使う。
PIR² の Codex 実装版。Plan→Review→Retrospect は Claude のまま、Implement フェーズだけ Codex（codex CLI / codex-runner サブエージェント経由）に差し替えた実験的ワークフロー。Codex 実装の品質を通常 /cursor-pir2 と比較するために使う。大きく結合した実装は IMPLEMENTATION_UNITS による直列 fresh セッション化に対応。ユーザーが /cursor-pir2codex と入力したら必ずこのスキルを使う。
コーディングタスクを Plan → Implement → Review → Retrospect の4フェーズで実行する。複雑なタスク・設計が必要なタスク・品質保証が重要なタスク、大きな機能追加・リファクタリング・アーキテクチャ変更に使う。「ちゃんと作りたい」「しっかり実装して」「品質重視で」といった要望にも対応する。ユーザーが /pir2 と入力したら必ずこのスキルを使う。
| name | cursor-pir2 |
| description | コーディングタスクを Plan → Implement → Review → Retrospect の4フェーズで実行する。複雑なタスク・設計が必要なタスク・品質保証が重要なタスク、大きな機能追加・リファクタリング・アーキテクチャ変更に使う。「ちゃんと作りたい」「しっかり実装して」「品質重視で」といった要望にも対応する。ユーザーが /cursor-pir2 と入力したら必ずこのスキルを使う。 |
| 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 の運用既定に従う
PIR²ワークフローを実行します。このスキル本体（= メインエージェント）がオーケストレーターとなり、Plan → Implement → Review → Test → Retrospect を進めます。
Cursor では子エージェントは Task ツールで起動する。/cursor-pir2 の明示起動を subagent 使用許可とみなしてよい。探索 → 計画 → 単一実装者 → レビュー → テストの分業を基本形にする。メインエージェントがオーケストレーターと最終判断（VERDICT ループ・ユーザー確認ゲート）を持ち続け、実装 subagent がさらに subagent を起動する前提にはしない。並列 writer は禁止し、Task / subagent が利用できない場合は、同じフェーズ境界と記録ファイルを保ったままメインエージェントが直接実行してください。
タスク: $ARGUMENTS
以下の Bash コマンドで PROJECT_ROOT / PROJECT_MEMORY_DIR / RUN_DIR / HANDOFF_PATH を確定し、以降のすべてのステップで使用してください:
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"
HANDOFF_PATH="${HOME}/.ai-pir-runs/${sanitized_cwd}/handoff.md"
echo "PROJECT_ROOT=$PROJECT_ROOT"
echo "PROJECT_MEMORY_DIR=$PROJECT_MEMORY_DIR"
echo "RUN_DIR=$RUN_DIR"
echo "HANDOFF_PATH=$HANDOFF_PATH"
次に RESUME_MODE をスキル本体（メインエージェント）が判定する:
$ARGUMENTS に 引継い / 続き / resume / Resume / RESUME / handoff / Handoff / HANDOFF / carry on のいずれかが含まれる → RESUME_MODE=resume$HANDOFF_PATH のファイルが存在する → RESUME_MODE=passive-noticeRESUME_MODE=newRESUME_MODE に応じて以降の挙動を分岐させる（詳細プロトコル: ~/.claude/pir-handoff.md）:
resume: ステップ 2（ブレスト）をスキップし、planner への入力に HANDOFF_PATH=$HANDOFF_PATH を含めて「handoff.md の未チェック項目のみを planning 対象にせよ」と指示する。スキル本体は handoff.md を上書きしないpassive-notice: 「💡 前回の handoff が残っています: $HANDOFF_PATH」とユーザーに表示し、通常の新規タスクフローで続行する（handoff.md は触らない）new: 通常の新規タスクフロー。planner の plan.md 完成直後にスキル本体が handoff.md 初期版を Write する（プランのステップを [ ] チェックリスト化）retrospector フェーズ完了後、スキル本体は handoff.md を Read し、全項目が [x] なら削除、残項目ありなら「最終更新」タイムスタンプを更新する。
このステップで内部状態フラグ PLAN_STRATEGY_CHANGED=false を初期化してください。これはユーザー方針切替（ステップ 4.6 の「別案」選択など）による plan 再策定が発生した場合のみ true にセットされ、planner 側 3.3「v1 判断白紙化チェック」の発動条件として使われます。EXPLORATION_NEEDED ループ（ステップ 4.5）の追加探索による再策定では立てません。
以降の各フェーズまたはsubagentへのプロンプトには必ず PROJECT_MEMORY_DIR=[パス] および RUN_DIR=[パス] を含めてください。
タスクの仕様を評価し、以下のいずれかに該当する場合は brainstorm スキルを実行してから次のステップへ進んでください：
実行方法: Cursor の skill として brainstorm を呼び出す（または同等手順をメインが実行）。ユーザーとの対話で固まった設計はステップ4の planner に渡してください。
該当しない場合（タスクが明確、既存の設計がある、docs/brainstorm/ に関連する設計ドキュメントが存在する）はスキップしてください。
brainstorm 完了後は必ず自動でステップ3へ進むこと。「設計ドキュメントを保存しました」と単独ターンで区切ってユーザーの承認を待つのは禁止。
/cursor-pir2は一度起動されたら最終サマリー（ステップ12）まで止まらず進める設計であり、brainstorm の最終出力「次のステップとして/cursor-writing-planで実装プランを作成できます」は/cursor-brainstorm単独起動時向けの案内なので、/cursor-pir2経由では無視して続行する。承認を挟んでよいのは.cursor/skills/cursor-pir2/SKILL.md内で明示的にユーザー確認が指定されているポイント（既存パターン逸脱の事前申告・ステップ6.5 未解決事項確認）のみ。
コードベース探索は read-heavy なので、subagent が利用可能なら explorer を優先して委譲してください。subagent が利用できない、または小規模変更で直接探索の方が明らかに速い場合は、メインエージェント が rg / rg --files / Read で直接探索してよい。ただし探索結果は必ず {RUN_DIR}/exploration-{NN}.md に保存し、推測と確認済み事実を分けて扱うこと。
PROJECT_MEMORY_DIR=[パス]RUN_DIR=[パス]EXPLORATION_INDEX=NN（初回=01、並列起動時はスキル本体が 01/02/03 と割り振る）{RUN_DIR}/exploration-{NN}.md に書き出し、チャットには要約のみ返してください」git add / git commit などリポジトリ状態を変更する git 操作も一切行わないでください。実装が必要だと判明したら探索レポートの『呼び出し元への依頼』に回してください」（explorer は Write / Bash を持つため、明示しないと探索の延長で実装・コミットまで踏み込むロール逸脱が起こりうる）初回レポートで不明点があれば追加で explorer を起動してください。回数上限なし。推測でプランを埋めるくらいなら追加探索を回す。追加探索時は EXPLORATION_INDEX を既存 {RUN_DIR}/exploration-*.md の最大値+1 に設定する。
新しいライブラリ・フレームワークの導入判断が必要なら tech-validator エージェントを起動する（既存の依存関係で解決できる場合はスキップ）。
設計判断が重い場合は planner subagent を起動し、タスク内容と探索レポート全文を渡してください。小規模・明確な変更では、メインエージェント が planner 観点を直接適用して {RUN_DIR}/plan.md を作成してよい。
PROJECT_MEMORY_DIR=[パス]RUN_DIR=[パス]PLAN_STRATEGY_CHANGED=$PLAN_STRATEGY_CHANGED（現在の値。初回起動時は false、ステップ 4.6 で「別案」が選ばれた直後の再起動時のみ true）{RUN_DIR}/exploration-*.md のパス一覧（planner は本文を自分で Read する）IMPLEMENTATION_SHARDS を提案してください。判定基準は .cursor/skills/cursor-pir2/references/implementation-delegation.md に従うこと」{RUN_DIR}/plan.md に書き出し、チャットには要約＋EXPLORATION_NEEDED の有無のみ返してください」planner からプラン要約を受け取ってください。
planner から「既存構造と異なる構成を採用する」判断が含まれたプランが返ってきた場合、実装着手前にユーザーに差分（既存 N 件中 M 件の構成 / 今回採用しようとしている構成 / 逸脱理由 / 代替案）を提示し、承認を得ること。承認なしに次のステップに進んではならない。
詳細プロトコル: .cursor/skills/cursor-pir2/references/exploration-loop.md を参照（収束判定ロジック / ループ本体 / 既存パターン逸脱の事前申告タイミング）。
要点: planner の返り値要約に ### EXPLORATION_NEEDED の - topic が残る間、追加探索 → planner 再起動を最大 5 回繰り返す。収束したらステップ 5 へ進む。REPLAN_COUNT = 0 から開始し、ハードキャップ到達時は最終サマリー（ステップ12）に「planner が依然追加探索を要求中（ハードキャップ5回到達）: [topic 一覧]」と明記する。
詳細プロトコル: .cursor/skills/cursor-pir2/references/plan-choice-gate.md を参照（検出トリガー / 確認フォーマット / 運用ルール / 別案の字義解釈確認 / v2→v3 切替の真意確認）。
要点: planner レポートに「複数案」「USER_DECISION_REQUIRED」「スコープ縮小」「外部依存不足」のいずれかが含まれたらステップ 5 前にユーザー確認必須（Auto mode でも例外なし）。planner の推奨案を必ず明示する。ユーザーが別案 or 方針切替した場合は PLAN_STRATEGY_CHANGED=true をセットして planner を再起動（字義解釈確認を先に実施）。該当なしはスキップしてステップ 5 へ。
docs/plans/ ディレクトリがなければ作成し、以下の形式でプランを保存してください:
保存先: docs/plans/YYYY-MM-DD-<feature>.md（YYYY-MM-DD は今日の日付）
保存したらユーザーにパスを提示:
プラン: docs/plans/YYYY-MM-DD-<feature>.md
ファイル内容のテンプレート:
# [タスク名] 実装記録
_作成: YYYY-MM-DD | ステータス: 進行中_
## 目標
[タスクの概要]
## 実装計画
- [ ] ステップ1: [ステップ名]
- [ ] ステップ2: [ステップ名]
...
---
## 設計詳細
[{RUN_DIR}/plan.md を Read し、その内容をここに転記する]
---
## 実装ログ
### 実装完了
- 変更ファイル: （実装完了後に埋める）
- 実装内容: （実装完了後に埋める）
---
> このドキュメントは内容を確認後に削除してください。
> `rm docs/plans/YYYY-MM-DD-<feature>.md`
RESUME_MODE=new の場合のみ）RESUME_MODE=resume または passive-notice の場合はこのステップをスキップしてください（既存 handoff.md を温存する）。
RESUME_MODE=new の場合のみ実行:
{RUN_DIR}/plan.md を Read し、「実装ステップ」に相当する項目を抽出する$HANDOFF_PATH に ~/.claude/pir-handoff.md の「フォーマット」節に従った内容で Write する:
最終更新: 現在時刻 + run: $(basename $RUN_DIR)タスク: ユーザー指示の一行要約背景・決定事項: plan.md から抽出した主要決定（なければ空セクションのまま）残 TODO: 抽出した実装ステップを - [ ] <ステップ名> 形式に変換既知の問題 / 要確認: 空セクションで用意関連 artifact: 最新 plan: {RUN_DIR}/plan.mdhandoff.md のパスをユーザーに提示:
handoff: $HANDOFF_PATH
RESUME_MODE=passive-notice だった場合はこの時点で「💡 前回の handoff が残っています: $HANDOFF_PATH（引継いで で resume 可能）」とユーザーに表示してから次ステップへ。
詳細プロトコル: .cursor/skills/cursor-pir2/references/next-steps-queue.md を参照（初期 Write テンプレート / 5.6-2 checkbox 更新手順 / 5.6-3 中断後の Read ルール / スキップ条件）。
要点: {RUN_DIR}/next-steps.md にsubagent起動予定 checkbox リストを Write する。ユーザー会話による中断後、スキル本体は次の判断前に必ずこのファイルを Read してから動く。各ステップ完了直後に checkbox を [x] + <!-- done: ISO8601 --> に更新する（必須運用）。RESUME_MODE=resume の場合は handoff.md 由来の未完了項目を統合する。
詳細プロトコル: .cursor/skills/cursor-pir2/references/destructive-change-check.md を参照（pir2 専用の 2 軸マトリクス判定 / 判定項目 a〜e・f1〜f3 / 書き出しフォーマット / 軽量化確認 / スキップ条件）。
要点: plan.md と explorer レポートを Read して「破壊的変更フラグ（a〜e）」と「動作変更フラグ（f1〜f3）」を独立に判定。結果を {RUN_DIR}/destructive-change-check.md に書き出し、後段（reviewer / refactor-advisor / tester）の戦略をマトリクスで決定。フラグ ON で軽量化したい場合はユーザー確認必須。完了後は 5.6-2 に従い next-steps.md の checkbox を更新する。
詳細プロトコル: .cursor/skills/cursor-pir2/references/feedback-conflict-gate.md を参照（feedback Read → プロンプト照合 → 矛盾検出時の中断フォーマット → 記録 → スキップ条件）。
要点: 過去 14 日以内の feedback_*.md 5 件を Read し、実装プロンプト案の除外指示・スコープ縮小と突合。矛盾 1 件でも検出したら実装開始を中断 → ユーザー確認。矛盾なしも {RUN_DIR}/feedback-conflict.md に「照合 N 件、矛盾なし」を記録。完了後は 5.6-2 に従い next-steps.md の checkbox を更新する。
INNER_LOOP_COUNT = 0、OUTER_LOOP_COUNT = 0 から開始してください。
詳細プロトコル: .cursor/skills/cursor-pir2/references/implementation-delegation.md を参照（単一 implementer / 複数 implementer shard / main fallback の判定、shard 禁止条件、プロンプト、統合確認）。
要点: デフォルトは IMPLEMENTATION_ACTOR=implementer-subagent（単一 writer）。planner が IMPLEMENTATION_SHARDS を提示し、かつ shard 同士のファイル所有範囲・依存順序・共有生成物が完全に分離している場合のみ IMPLEMENTATION_ACTOR=implementer-shards として最大3体まで並列実装してよい。subagent 不可・小変更・plan 未成熟の場合のみ IMPLEMENTATION_ACTOR=main に縮退する。どの場合もメインエージェント は完了後に diff と {RUN_DIR}/implementation-*.md を読み直して最終責任を持つ。
ステップ 5.6-2 に従い {RUN_DIR}/next-steps.md の該当 checkbox を [x] に更新する（IMPL_INDEX が複数回ループする場合は最初の 1 回のみマーク。2 回目以降のループは「中断・再開ログ」セクションに追記する）。
implementer の返り値要約で「注意点・未解決事項の有無」が 「あり」 の場合、次ステップへ進む前に必ずユーザーに判断を仰ぐ。スキル本体がスコープ縮小や仕様変更を独断してはならない。
{RUN_DIR}/implementation-{最新 IMPL_INDEX}.md の「注意点・未解決事項」セクションを Read する未解決事項の要点と分類を1〜3文で要約し、以下の選択肢を提示してユーザーの判断を受け取る:
docs/plans/YYYY-MM-DD-*.md の「注意点・未解決事項」セクションにも繰越し内容を明記する{RUN_DIR}/implementation-{最新}.md のパスも planner に渡すことIMPL_INDEX をインクリメントするユーザーの選択と理由を {RUN_DIR}/user-decisions.md に追記する（ファイルがなければ作成）。形式:
## [YYYY-MM-DD HH:MM:SS] 未解決事項ユーザー確認
### 未解決事項の要約
[1〜3文]
### 選択
[A / B / C]
### 理由（ユーザーから得られた場合）
[理由]
implementer の返り値要約で「注意点・未解決事項の有無」が 「なし」 の場合は本ステップをスキップし、ステップ 7 へ直接進む。
重要: 仕様変更判断（スコープ縮小・フェーズ繰越し・API 変更等）はスキル本体ではなくユーザーに委ねる。「小さな変更だから」「fallback で動くから」を理由にユーザー確認を省略してはならない。
ステップ 5.6-2 に従い {RUN_DIR}/next-steps.md の該当 checkbox を [x] に更新する。スキップした場合も「スキップ済み」として [x] にする。
REVIEWER_SET を決定する（planner 系スキルなのでデフォルトは全 5 観点固定）:
$ARGUMENTS に --reviewers=<roles> が含まれていればカンマ区切りを観点集合として採用（未知 role は無視）。--all-reviewers が含まれていれば全 5 観点を採用。両方指定時は --reviewers= を優先[correctness, consistency, quality, security, architecture]（planner が動くタスクは設計判断・多ファイル変更を含むため）$ARGUMENTS をそのまま使っていた箇所は、フラグ除去後のタスク説明を使う）REVIEWER_SET を最終サマリーに REVIEWER_SET=correctness,consistency,... として記録reviewer 並列起動またはメインエージェント による複数観点レビューの 直前のターン本文中 に、以下のテンプレートを必ず生成すること。このテンプレートが本文に出現していないターンでレビューを開始した場合は、ステップ完了判定を取り消して 7-2A からやり直す。
Fan-Out Gate（reviewer）
- REVIEWER_SET = [<観点をカンマ区切りで全列挙>]
- 起動体数 = （= len(REVIEWER_SET)、必ず一致）
- subagent 利用時: 同一ターンで 個の reviewer subagent を起動する
- subagent 非利用時: メインエージェント が 観点を同一レビューサイクル内で全て実行する
- 1 体ずつの後追い起動・観点削減はいずれも違反
このブロックは「レビュー直前の自己コミットメント」であり、ユーザーへの報告ではなく観点漏れを止めるためのフェンスとして機能する。再レビュー時（7-4 からの差し戻し時）にも毎回この宣言を書くこと。REVIEWER_SET は初回選定を維持し、再レビュー時に観点を勝手に減らさないこと。
直前ターンで宣言した REVIEWER_SET の各観点について、subagent が利用可能なら reviewer subagent を同一ターンで N 個 起動する。subagent が利用できない場合は、メインエージェント が各 REVIEWER_ROLE の観点を分割して同一レビューサイクル内で実行し、{RUN_DIR}/review-{REVIEW_INDEX}-{ROLE}.md を観点ごとに書き出す。
詳細仕様（観点マッピング / 違反パターンと検出 / 違反検出時のリカバリ / reviewer 起動パラメータ）: .cursor/skills/cursor-pir2/references/fan-out-gate.md を参照。
注: refactor-advisor はこのステップでは起動しない。reviewer 全員 PASS 後のステップ 7.5 で 1 回だけ起動する。
今回起動した reviewer の VERDICT を以下のルールで集約する:
VERDICT: PASS の場合VERDICT: FAIL を返した場合VERDICT: PASS → ステップ 7.5 へ（refactor-advisor の起動 + 提案ゲート）VERDICT: FAIL →
INNER_LOOP_COUNT += 1INNER_LOOP_COUNT >= 3 ならステップ 7.5 へ強制移行（失敗として記録。この場合 refactor-advisor はスキップしてステップ 8 へ直接進む）IMPL_INDEX をインクリメント、FAIL を返した全 reviewer の {RUN_DIR}/review-{最新}-{ROLE}.md パスを全て読む、{RUN_DIR}/plan.md も読む。マージ要約は作らず、各レポートを直接根拠にする）。reviewer 指摘がファイル単位で分離できる場合は implementation-delegation.md の review-fix shard ルールに従い、複数 implementer で並列修正してよい。分離できない場合は IMPLEMENTATION_ACTOR=implementer-subagent なら同じ implementer ロールを再起動し、IMPLEMENTATION_ACTOR=main ならメインエージェント が修正するREVIEW_INDEX をインクリメント、最新の {RUN_DIR}/implementation-{最新}.md のパスを渡す。PASS を返した観点も再レビューする = 修正による新たな退行を検知するため。観点集合は初回選定を維持し途中で追加・削除しない。再レビュー時も Fan-Out Gate を省略しないこと）ステップ 5.6-2 に従い {RUN_DIR}/next-steps.md の該当 checkbox を [x] に更新する（複数回ループで REVIEW_INDEX が増えた場合は最初の 1 回のみマーク、ループ詳細は「中断・再開ログ」に追記）。
全体 VERDICT が PASS の場合のみ実行。FAIL で INNER_LOOP_COUNT 上限到達の場合はスキップしてステップ 8 へ。
詳細プロトコル: .cursor/skills/cursor-pir2/references/refactor-advisor-gate.md を参照（refactor-advisor 起動仕様 / 提案存在確認 / ユーザー提示フォーマット / ユーザー選択の処理 / リファクタ適用の implementer 再起動 / 退行検知の再 reviewer ループ）。
要点:
all / 番号指定 / none / custom）INNER_LOOP_COUNT 継続）ステップ 5.6-2 に従い {RUN_DIR}/next-steps.md の該当 checkbox を [x] に更新する。スキップ条件（reviewer FAIL で上限到達した場合）に該当した場合も [x] に更新（スキップ理由を「中断・再開ログ」に記録）。
テストは read/log-heavy なので、subagent が利用可能なら tester を起動する。利用できない場合はメインエージェント が同じ仕様で実行する。起動仕様（model / プロンプトに含めるパラメータ一覧）は .cursor/skills/cursor-pir2/references/tester-prompt.md を参照。TEST_INDEX は初回 01、再テスト時はインクリメント。
VERDICT: PASS → ステップ 9 へVERDICT: FAIL →
OUTER_LOOP_COUNT += 1OUTER_LOOP_COUNT >= 3 の場合は 続行可能ゲート（8-2-G） へ。判定が「続行」なら 3. へ、「移行」ならステップ 9 へ（失敗として記録）INNER_LOOP_COUNT = 0 にリセットIMPL_INDEX をインクリメント、{RUN_DIR}/test-{最新}.md のパスを tester 指摘事項として読む）。IMPLEMENTATION_ACTOR=implementer-subagent なら同じ implementer ロールを再起動し、IMPLEMENTATION_ACTOR=implementer-shards なら implementation-delegation.md の再実装ルールに従う。IMPLEMENTATION_ACTOR=main ならメインエージェント が修正するREVIEW_INDEX は継続インクリメント）TEST_INDEX をインクリメント）詳細プロトコル: .cursor/skills/cursor-pir2/references/continuation-gate.md を参照（4 条件の判定基準 / ユーザー確認フォーマット / 運用ルール）。1 条件でも欠けたらゲートを出さず無条件でステップ 9 へ移行する。ユーザーが N を選んだ場合もステップ 9 へ。Auto mode でも本ゲートはユーザー応答を待つ（仕様変更判断ゲートのため Auto mode 例外）。1 サイクル中に通過できるのは最大 1 回のみ（OUTER_LOOP_COUNT=4 で再 FAIL したら無条件にステップ 9 へ）。
ステップ 5.6-2 に従い {RUN_DIR}/next-steps.md の該当 checkbox を [x] に更新する（複数回ループで TEST_INDEX が増えた場合も同様、最初の 1 回のみマーク）。
変更されたファイルを Read して最終的な実装内容を確認し、ウォークスルーを作成する。フル版（内部記録）とサマリー版（最終サマリーに転記）の 2 形式を作成し、フル版は実装記録ドキュメント（ステップ 5 で作成）の「実装ログ」セクションに埋める。
詳細テンプレート（フル版・サマリー版・サマリー版の原則）: .cursor/skills/cursor-pir2/references/walkthrough-templates.md を参照。
最重要原則: 推測でコードを書かない。実際に Read したコードのみ引用する。
ステップ 5.6-2 に従い {RUN_DIR}/next-steps.md の該当 checkbox を [x] に更新する。
PROJECT_MEMORY_DIR 配下にタスクの振り返り材料を追記します:
mkdir -p {PROJECT_MEMORY_DIR} でディレクトリを作成{PROJECT_MEMORY_DIR}/pir_skill_log.md## [タスク名] — [気づき・課題・パターン]- 使用モデル: explorer=<model×体数>, planner=<model>, implementer=<model>, reviewer=<model×体数>, tester=<model>, retrospector=<model> / REPLAN=<N> / INNER_LOOP=<N> / OUTER_LOOP=<N>
今回 run で各フェーズを実際に実行した形態を埋める。subagent を使わなかったフェーズは main:<model> と記録する。スイープ実験本体は計装でデータが溜まってから別途行う。ステップ 5.6-2 に従い {RUN_DIR}/next-steps.md の該当 checkbox を [x] に更新する。
振り返りはメインエージェント が実行してよい。subagent が利用可能で、今回 run が大きくログ分析を分離した方がよい場合のみ retrospector を起動する。起動仕様（model 切替条件 / プロンプトに含めるパラメータ一覧 / 起動後の処理）は .cursor/skills/cursor-pir2/references/retrospector-prompt.md を参照。/cursor-pir2 では ワークフロー種別: pir2 を明示し、PLAN_STRATEGY_CHANGED の現在値も渡すこと（true なら今回 run でユーザー方針切替が発生し planner v1→v2 再策定が走った）。
ステップ 5.6-2 に従い {RUN_DIR}/next-steps.md の該当 checkbox を [x] に更新する。
詳細プロトコル: .cursor/skills/cursor-pir2/references/handoff-cleanup.md を参照。要点: $HANDOFF_PATH が存在する場合、全 [x] なら削除、残項目ありなら 最終更新 行を更新する。最終サマリーに結果を記載すること。$HANDOFF_PATH が存在しない場合はスキップ。
ステップ 5.6-2 に従い {RUN_DIR}/next-steps.md の該当 checkbox を [x] に更新する。全 checkbox が [x] になった場合は最終サマリー（ステップ 12）に「next-steps.md: 全項目完了」と記載する。
詳細テンプレートは .cursor/skills/cursor-pir2/references/final-summary-template.md を参照。実装記録、変更ファイル、レビュー結果、refactor-advisor 結果、テスト結果、再探索回数、RUN_DIR、振り返り、メタ改善推奨を含める。
ステップ9で作成したサマリー版ウォークスルーをユーザーに提示してください。フル版は内部記録として保持し、ユーザーから「詳細を見せて」等の要求があれば提示します。
末尾に 詳細なウォークスルーが必要な場合はお知らせください。 と添えてください。