Smart Issue Plan

Smart Issue Plan

GitHub Issue を分析し、コードベースを探索して実装計画を作成する。既存の計画がある場合は更新する。

引数の解析

$ARGUMENTS を以下のルールで解析する:

• レビューループのフラグ（位置は問わない。該当トークンは除去する）:
  • --codex-review-loop または -cdxrl → {レビューモード} = standard、{レビュー系統} = codex
  • --codex-advs-review-loop または -cdxarl → {レビューモード} = adversarial、{レビュー系統} = codex
  • --claude-review-loop または -cldrl → {レビューモード} = standard、{レビュー系統} = claude
  • --claude-adv-review-loop または -cldarl → {レビューモード} = adversarial、{レビュー系統} = claude
  • 複数指定時: adversarial を優先し（より強いレビュー）、{レビュー系統} は adversarial 側のフラグに従う。モードが同格で系統だけ競合する場合（例: -cdxrl -cldrl）は codex を優先し（別系統モデルの独立性がより高い）、その旨を 1 行通知する
  • どれも無ければ {レビューモード} は off
  • いずれかのフラグが明示指定された場合は {ループ明示} = true を立てる（収束後の自動投稿の可否に使う）
  • 旧 -codex-loop（ハイフン 1 つ）を検出した場合は、--codex-review-loop（-cdxrl）／敵対的レビューなら --codex-advs-review-loop（-cdxarl）にリネームされた旨を案内して処理を止め、再指定を促す（旧フラグを Issue 番号の一部として解釈しない）
• -p より前の部分 → Issue 番号（# は除去）
• -p より後の部分 → {プロンプト}（計画の観点・制約に関する追加指示）
• -p がない場合 → 残り全体を Issue 番号として扱い、{プロンプト} は空
• Issue 番号が未指定の場合 → AskUserQuestion で Issue 番号を確認する

例: /smart-issue-plan #42 -p パフォーマンスを重視して → Issue 番号: 42、プロンプト: 「パフォーマンスを重視して」 例: /smart-issue-plan #42 --codex-review-loop → レビューモード: standard、系統: codex 例: /smart-issue-plan #42 -cdxarl → レビューモード: adversarial、系統: codex 例: /smart-issue-plan #42 -cldarl → レビューモード: adversarial、系統: claude

{レビューモード} が off でも、計画がセキュアな設計を要すると判定した場合は adversarial に自動昇格する（「レビューループ（codex 系 / claude 系）」セクションのセキュリティ自動発動を参照）。{レビューモード} が off 以外になった場合の挙動は同セクションを参照。

ツール選択

GitHub API 操作には GitHub MCP ツールを優先する。コードベース探索には Glob, Grep, Read を使用する。claude 系レビューループのエージェント起動には Workflow ツールを使用する（Agent ツールは effort を指定できないため使わない）。

手順

1. Issue の読み取り

引数から抽出した Issue 番号で issue_read を呼ぶ。以下に該当する場合は通知して終了:

• Issue が存在しない、またはクローズ済み
• Pull Request（issue_read の pull_request フィールドあり）— PR に対する計画は本スキルの対象外
• Issue 本文が空でラベルも無い — 要件を判断できないため、ユーザーに内容を確認してから進める

コンテキストに残すのは タイトル・本文（長い場合は要件・受け入れ基準部分のみ）・ラベル・直近 5 件以内のコメント のみ。他のフィールド（イベント履歴、古いコメント等）は破棄する。

Issue 本文が Figma / Slack / 外部ドキュメントへのリンクに依存している場合、取得可能なら参照する。取得できない場合はユーザーに内容の要点を確認してから手順 4 に進む（推測で計画を作らない）。

2. 既存計画の確認

Issue のコメントに「## 実装計画」を含むものがあるか確認する。また search_issues で「[実装計画] <タイトルのキーワード>」を検索する。

• 既存計画あり → 更新モードへ（手順 8）
• 既存計画なし → 新規作成モードへ（手順 3）

3. 出力先の確認

計画を作成する前に、出力先をユーザーに確認する:

• Issue コメントとして投稿（デフォルト）
• 新規 Issue として作成 — 計画が大きい場合や、計画自体をタスクとして追跡したい場合に適する

4. コードベース探索

Issue の内容から関連するキーワード・ファイルパス・機能領域を特定し、以下の観点でコードベースを探索する。探索は推測ではなく実際のコード構造に基づいて行う。

4-0. 分析時点 SHA の取得

• 探索を始める前に git rev-parse --short HEAD で現在の HEAD の short SHA を取得し、分析日とともに保持する。これは「どのコード状態を分析したか」を表すため、計画作成時（手順 5）ではなく探索開始時点で取得する
• 取得した SHA・分析日は手順 5 でテンプレートの「分析時点」欄へ転記する（smart-issue-resolve 側の陳腐化検出の基準になる）
• git が使えない環境では SHA 記録をスキップし、テンプレートには「未記録」と書く（クロスツール配布の degradation）

4a. エントリポイントの特定

• Issue が言及する機能・画面・API のエントリポイントを Grep/Glob で探す
• ルーティング定義、コンポーネント定義、コマンドハンドラなど起点となるファイルを見つける

4b. 依存グラフの把握

• エントリポイントから import/require を辿り、変更が波及するファイル群を特定する
• 共通モジュール・型定義・設定ファイルへの依存も確認する

4c. 既存パターンの確認

• 類似機能がどう実装されているか Read で確認し、踏襲すべきパターンを把握する
• テストの書き方（テストフレームワーク、ディレクトリ構成、命名規則）も確認する

4d. 境界条件の確認

• 外部 API・DB スキーマ・設定ファイルなど、変更に制約を与える境界を特定する
• CI/CD パイプライン、lint ルール、型チェック設定など品質ゲートも確認する

5. 実装計画の作成

手順 4 の探索結果（主要ファイル・採用パターン・境界条件）を 10 行程度に要約してから計画作成に入る。要約が作れないなら探索が不十分なので 4a〜4d の該当箇所を再実行する。

assets/plan-template.md の構成で計画を作成する。{プロンプト} の指示があればそれを計画の観点に反映する。

テンプレートへの転記:

• 手順 4-0 で取得した SHA・分析日を「分析時点」欄に記入する（git が無い場合は「未記録」）
• 手順 4 で確認したデータ契約・API 契約・参照ブロックを「依拠した前提」セクションに、実ファイルパス＋確認方法（ファイル:行 または Grep パターン）付きで記入する。スキーマ移行期など前提が変わりうる箇所は必ず残す

計画は日本語で記述する。実装の詳細（具体的なコード）は書かず、方針と手順に留める。

推奨ブランチ名の提案:

プロジェクト側に独自のブランチ命名規則（CLAUDE.md・AGENTS.md・README 等で明示されている場合）があればそちらを優先し、なければ以下の規則に従って計画内に推奨ブランチ名を記載する。

フォーマット: {type}/issue-{番号}-{簡潔な説明}

ルール:

• kebab-case（小文字 + ハイフン区切り）、ASCII のみ
• Issue に紐づく作業は必ず issue-{番号} を含める
• 説明部分は 英語・3〜5 語 程度
• マイルストーン分割がある場合は末尾に -m{番号} を付ける

計画完成後、「レビューループ（codex 系 / claude 系）」セクションの レビューモードの確定（セキュリティ自動発動） を評価する。{レビューモード} が off 以外に確定したらレビューループを実施し、その後は次のように分岐する:

• {ループ明示} = true（収束または打ち切り投稿を選択）→ 手順 6 をスキップして手順 7（投稿）へ
• {ループ明示} = false（セキュリティ自動発動のみ）→ 手順 6（承認ゲート）を通してから手順 7 へ

{レビューモード} が off のままならレビューはせず手順 6 へ進む。

6. プレビューと承認

レビューループを実施し、かつ {ループ明示} = true の場合はこの手順をスキップする（オプション指定が投稿のオプトイン）。セキュリティ自動発動のみ（{ループ明示} = false）の場合、およびループのフォールバック（codex:rescue / codex exec 利用不能 / Workflow 利用不能）時は通常どおり実施する。

作成した計画の全文をユーザーに提示し、投稿前に承認を得る。

• 影響範囲・手順・リスクに抜けがないかユーザーが確認できる形で出す
• 承認なしに GitHub へ投稿しない（一度投稿したコメントの編集履歴は残るため）
• 修正指示があれば計画を書き直してから再度提示する

7. 投稿

手順 3 で決めた出力先に投稿する:

• Issue コメント → add_issue_comment で投稿
• 新規 Issue → issue_write で「[実装計画] <元タイトル>」として作成し、元 Issue への参照リンクを本文冒頭に記載

レビューループを実施した場合、投稿本文の末尾にレビュー済み表記（「レビューループ（codex 系 / claude 系）」セクション参照）を付ける。

投稿後、URL を表示し、実装に着手する場合は /smart-issue-resolve #<Issue 番号> を新規セッションで実行するよう案内して終了。

8. 更新モード

既存の計画コメント/Issue を読み取り、前回の計画からの差分を特定して更新する。

8a. 変更点の特定

• 計画の「分析時点」欄に記録された SHA を基準に、計画作成後の変更を特定する:
  • SHA が記録され git cat-file -e <記録SHA> で解決できる場合 → git log <記録SHA>..HEAD -- <計画言及ファイル> で、計画作成後に計画言及ファイルへ入った変更を確認する
  • SHA が未記録、または解決できない（shallow clone 等）場合 → 従来どおり git log --oneline --since="<計画作成日>"（計画コメントのタイムスタンプ基準）にフォールバックする
• Issue の新しいコメント（要件変更・追加指示）を確認する
• 計画が言及するファイルの現在の状態を Read で確認し、既に実装済みの手順を特定する

8b. 計画の再評価

• 実装済みの手順は完了マーク（✅）を付ける
• 要件変更やコード変更により無効になった手順は修正する
• 新たに判明したリスクや依存関係を追加する

8b の再評価が終わった時点で「レビューループ（codex 系 / claude 系）」セクションのレビューモードの確定を評価し、{レビューモード} が off 以外なら実施する。{ループ明示} = true で収束または打ち切り投稿を選んだ場合は 8c の承認ゲートをスキップして投稿し、レビュー済み表記を付ける（セキュリティ自動発動のみの場合は 8c の承認ゲートを維持する）。

8c. 更新の投稿

• 更新内容のプレビューをユーザーに提示し、承認を得る（手順 6 と同じ承認ゲート）
• 計画コメントの場合 → 新しいコメントとして更新版を投稿（add_issue_comment）し、前回コメントへのリンクを冒頭に記載
• 計画 Issue の場合 → 本文を直接更新（issue_write）

レビューループ（codex 系 / claude 系）

{レビューモード} が off 以外の場合に実施する。目的は計画作成の文脈から独立したレビュー。codex 系は別系統モデル（Codex）が、claude 系はコンテキスト隔離した Opus エージェント（発見役〔レビュワー / Breaker〕・敵対 Judge バッチは effort high、plan-editor のみ max。包括ラウンド〔初回セット round 1〕のみ標準レビュワーを G1/G2/G3・敵対 Breaker を S/C/O に分割して並列起動し、以降のラウンドは単発 1 体。敵対 Judge は Breaker の攻撃シナリオを ≤4 件/バッチに分割し並列裁定）がレビュー・裁定を担う。Claude 自身（オーケストレーター）がレビュー・裁定を模擬・代行してはならない。

いずれのモード・系統でも、返ってきた指摘に対する 採用 / 不採用（過剰対応かどうか）の判定は、レビュイーが行う（codex 系はオーケストレーター、claude 系は plan-editor エージェント。この不変則はモード・系統によらず変わらない）。

レビューモードの確定（セキュリティ自動発動）

計画がセキュアな設計を要するかを判定する。次のいずれかに該当すれば「セキュリティ影響あり」とみなす（判断に迷う場合はセキュア側に倒す）:

• Issue のラベル・タイトル・本文が、認証/認可・ログイン・パスワード・トークン/JWT・セッション・暗号/ハッシュ・個人情報(PII)・決済/課金・秘密情報/API キー・OAuth/SSO 等に言及している
• 計画が、認証・認可・暗号・セッション管理・決済・シークレット/環境変数の取り扱いに触れる設計を含む

セキュリティ影響ありと判定し、かつ {レビューモード} が off または standard の場合、{レビューモード} を adversarial に昇格させ、発動理由（検出したシグナル）をユーザーに 1 行で明示する。{レビュー系統} は次のとおり決める:

• 系統フラグが明示されている → その系統のまま adversarial へ昇格
• フラグ未指定（off からの自動発動） → codex 系のレビュー取得経路（Claude Code ホストの codex:rescue / Codex CLI ホストの codex exec）のいずれかが利用可能なら codex、いずれも利用不能なら claude（Workflow 必須）。両方利用不能ならフォールバック（後述）に従う

{ループ明示} = false（フラグ未指定でセキュリティ検出により発動）の場合、レビューは実施するが 手順 6 / 8c の承認ゲートは維持する（外部への投稿を伴う自動化は明示オプトイン時のみ）。

セキュリティ自動発動時は、敵対的レビューの初回に STRIDE・認可・データフローの監査観点を注入する。claude 系（雛形 sip-plan-review-set の securityAudit: true）ではレンズ S の Breaker が監査を内蔵実施する（初回セット round 1 で STRIDE 監査 → security-audit.md 書き出し → セキュリティ break を 1 エージェントで実施。独立の前段監査スロットは持たない）。codex 系は敵対的モードの Breaker〔Claude〕がその観点を内蔵する。claude 系では、上で明示した発動理由（検出したシグナル）を securityReason として Workflow の args に渡す（レンズ S の監査プロンプトに「自動発動の理由」として埋め込まれるため。渡し忘れると理由が undefined になる）。監査に失敗した場合（返却の auditFailed: true。レンズ S が security-audit.md を書き出せなかった場合）は Breaker 内蔵のセキュリティ観点のみで続行し、その旨を完了報告に記す。

レビュー基準の収集（プロジェクト固有ルール）

レビュー実施前に、プロジェクト固有のコーディング規約・レビュー基準を収集し、標準・敵対的いずれのレビュー観点にも「プロジェクト固有基準」として明示的に注入する。汎用観点だけではドメイン固有の欠陥（例: アーキテクチャ層責務・トランザクション/DB・性能・テストカバレッジ基準）を取りこぼすため。ソース:

• プロジェクトの CLAUDE.md / AGENTS.md に記載の規約
• リポジトリ内のコーディングルール集を Glob で探索する（**/rules/*.md・**/guidelines/*.md・docs/ 配下の規約など）。Issue・計画のドメインに関連するものだけを Read する（例: ddd-* / *architecture* / db-* / api-* / performance* / test-coverage* / security*）
• 手順 4 のコードベース探索で判明した既存パターン・境界条件

規約が見つからなければ下記の汎用観点のみで進める（クロスツール配布の degradation）。収集した基準は標準モードのテンプレート「プロジェクト固有基準」欄、および敵対的モードの Breaker 観点・Judge 照合対象に渡す。関連する規約は手順 5（計画作成）でも「依拠した前提」に反映しておくと、レビューでの手戻りを減らせる。

ループ手順（共通骨格）

1. レビュー取得 — {レビュー系統} × {レビューモード} に応じてレビューを取得する（下記）。レビュー対象は確定した計画テキスト（計画が言及するファイル・前提はリポジトリの実コードと照合する）
2. 妥当性判定（過剰対応チェック） — レビュイーが指摘を 1 件ずつ「採用 / 不採用」に分類する:
   • 採用: 計画の誤り・抜け・リスクを根拠付きで正しく突いている指摘
   • 不採用: 妥当性がない、オーバーエンジニアリングを招く、Issue のスコープ外 — 理由を 1 行で記録する（敵対的モードで Judge が「真の欠陥」と裁定した指摘でも、対応が過剰になるなら不採用にしてよい）
3. 修正 — レビュイーが採用指摘を計画に反映する
4. 収束判定 — 採用が 0 件ならループ終了（収束）。1 件以上なら手順 5（上限チェック）へ進む（必ず上限チェックを経由する。直接手順 1 へ戻らない）。なお claude 系は雛形 sip-plan-review-set 内部で dry-twice 方式（「指摘 0 / High・Medium 採用 0」のクリーンなラウンドが連続 2 回で収束・Low のみの採用は反映しつつクリーン扱い〔重大度フロア。Issue #134〕・1 回目クリーン後は差分スコープを解除したフルスコープの確認ラウンド）を採るため、本手順の「採用 0 件で即収束」は codex 系向けの記述である
5. 上限チェック — 現在のラウンド数（通算）を確認する:
   • ラウンド数が 3 の倍数（3, 6, 9, …）に達していない → ラウンドを +1 して手順 1 に戻る
   • 3 の倍数に達した → 残りの指摘の要約を提示して AskUserQuestion で確認する:
     • 続行 → ラウンドを +1 して手順 1 に戻る（次の 3 の倍数ラウンドで再度この確認を行う）
     • 打ち切って投稿 → 未収束のまま投稿フェーズへ（{ループ明示} = false のときは手順 6〔新規投稿〕または 8c〔更新〕の承認ゲートを通す。表記は「未収束で打ち切り」）
     • 中止 → 投稿せず、計画の現状をチャットに提示して終了

claude 系（雛形 sip-plan-review-set）でセット末尾が cleanStreak: 1（クリーン 1 回のまま 3 ラウンド上限に到達）だった場合、残指摘が空でも未収束（連続クリーン確認待ち）として返る。続行時は返却の cleanStreak を次セットの args に必ず引き継ぎ、次セット round 1 を差分スコープ解除の確認ラウンドとして dry-twice をセット境界を跨いで成立させる。

各ラウンドのモード・指摘数・採用数・不採用理由の要約を記録し、投稿後の完了報告に含める。計画レビューはコードの検証（テスト実行）を伴わないため、収束後は最終 QA を回さずそのまま投稿へ進む。

実行形態:

• codex 系 — オーケストレーターがラウンド単位で回す。レビュー・裁定の取得はホストで分岐する（Claude Code ホストは Skill ツールで codex:rescue を呼ぶ、Codex CLI ホスト＝本 skill 自体を Codex CLI が実行している場合は codex exec で独立した新規セッションを起動する。詳細は下記「標準モード」「敵対的モード」）。妥当性判定・計画修正はオーケストレーターが行う。敵対の裁定に「仕様未定」が含まれる場合は、修正前にオーケストレーターが AskUserQuestion でユーザーに仕様を確認し、確定内容を計画に反映する
• claude 系 — 骨格 1〜4 の 1 セット（最大 3 ラウンド）を雛形 sip-plan-review-set の Workflow 1 回で実行する。オーケストレーターは返却（converged / records / specQuestions）を受けて、上限チェック（AskUserQuestion）と裁定「仕様未定」のユーザー確認を行う（下記「claude 系」）

標準モード（codex 系: --codex-review-loop）

assets/codex-review-prompt.md のテンプレートを埋め、レビューを取得する:

• Claude Code ホスト（Skill ツールが使える）: Skill ツールで codex:rescue を呼び出す
• Codex CLI ホスト（本 skill 自体を Codex CLI が実行している。codex:rescue は Claude Code 専用のため存在しない）: codex exec（非対話・毎回新規セッション）を起動しテンプレートを渡す。起動手順（プロンプトの stdin リダイレクト・-o での出力回収・ホストのサンドボックス外での昇格実行）は assets/codex-review-prompt.md の「Codex CLI ホストでの補足」に必ず従う。計画を作成している現在のセッションとは独立した新規セッションでレビューを取得し、同一セッション内で自己レビューを完結させない（独立性が失われるため）

Codex が単独で計画とコードを照合してレビューする。

敵対的モード（codex 系: --codex-advs-review-loop / セキュリティ自動発動）

Claude=Breaker × Codex=Judge の二者構造でレビューする。計画にはテスト対象のコードがないため、反例テストの代わりに 設計への攻撃シナリオ を用いる。code-reviewer-adversarial スキルは disable-model-invocation のため Skill ツールから呼べない。その二者構造を本ループ内にインラインで再現する:

1. Breaker（Claude） — 計画を「破る」観点で、設計が耐えるべき具体的な攻撃シナリオ・脅威・欠落コントロールを列挙する。デフォルトは懐疑: 正常系（happy path）しか想定していない手順は実在の弱点として扱い、「後で対応する」前提や部分的な対処に信用を与えない。セキュリティ観点では STRIDE（なりすまし・改ざん・否認・情報漏洩・DoS・権限昇格）・信頼境界・認可漏れ・PII/秘密情報の露出・注入面を、一般観点では移行失敗・後方互換性破壊・version skew／スキーマドリフト・品質ゲートの抜け・運用/保守/可用性の設計欠落（可観測性・デプロイ/ロールバック・障害時や依存劣化時の挙動・単一障害点・過度な結合）・データ整合性/性能の設計欠落（トランザクション境界・冪等性・並行更新・部分失敗・不可逆な状態変更・N+1 や過剰 I/O）・テストカバレッジ計画の不足・アーキテクチャ層責務の逸脱を洗い出す。「レビュー基準の収集」で得たプロジェクト固有ルールがあれば、その観点も攻撃シナリオに含める。各シナリオに、計画のどの手順・前提が対処できていないかを付す
2. Judge（Codex） — assets/codex-judge-prompt.md のテンプレートに計画全文と Breaker の攻撃シナリオを埋め、レビューを取得する。Claude Code ホストでは Skill ツールで codex:rescue を呼び出す。Codex CLI ホスト（codex:rescue が存在しない）では codex exec を起動し、Breaker（現在のセッション）とは独立した新規セッションで裁定させる（起動手順は assets/codex-review-prompt.md の「Codex CLI ホストでの補足」に従う）。Codex はリポジトリの実コードと照合し、各シナリオを「真の欠陥 / 仕様未定 / 低優先度 / ノイズ」に裁定し、独立にも計画の欠陥を挙げる
3. Judge が「真の欠陥」「仕様未定」に分類した指摘を、共通骨格の手順 2（妥当性判定）に渡す

共犯化の回避: Judge（Codex）の裁定を Claude が模擬・代行しない。Breaker（Claude）と Judge（Codex）が別系統モデルであることが敵対的レビューの核。

claude 系（--claude-review-loop / --claude-adv-review-loop）

雛形 sip-plan-review-set（references/agent-orchestration.md）で実行する。Claude Code の Workflow ツール前提（利用できない環境はフォールバック参照）。

準備（Workflow 起動前にオーケストレーターが行う）:

1. 作業ディレクトリの作成 — {作業Dir} を作成する。配置はいま操作している作業ツリーで分岐する（判定: git rev-parse --git-dir と git rev-parse --git-common-dir の出力が異なれば linked worktree にいる〔linked では前者が <共有.git>/worktrees/<名前>、後者が <共有.git>〕。メイン作業ツリーでは両方とも同じ値〔通常 .git〕を返す。--show-toplevel とメインルートの文字列比較は使わない — /tmp と /private/tmp のようなパス正規化差で誤判定するため。{worktreeパス} 自体は git rev-parse --show-toplevel で取る。本スキルに -wt は無く、worktree を作りもしないため、既に worktree 内にいるセッションでのみ分岐する）:
   • linked worktree の中にいる場合（/smart-issue-resolve --worktree が作った worktree 内で計画を回す等） → {worktreeパス}/.smart-issue-work/plan-issue-<番号>/ を使う。/tmp と違い端末の再起動で作業ファイル（plan.md 等）が失われない。作成前に git -C "{worktreeパス}" check-ignore -q .smart-issue-work/（末尾のスラッシュ必須 — 無いとディレクトリ未作成の間は誤判定する）が失敗する（＝まだ無視されていない）場合、$(git rev-parse --git-common-dir)/info/exclude に .smart-issue-work/ を追記する（追跡対象の .gitignore は変更しない・ローカル限定の除外）。exclude 済みなら git status に出ずレビュー対象を汚さず、git worktree remove（--force なし）も阻害せず worktree 削除時に中身ごと消える。既に同名ディレクトリが存在する場合（前回の中断・再起動等）は黙って再利用せず、再利用するか作り直すかユーザーに確認する
   • メイン作業ツリーの場合（既定） → 従来どおり mktemp -d "${TMPDIR:-/tmp}/sip-issue-<番号>.XXXXXX" で作成する（OS の一時領域。メイン作業ツリーに置くと誰も掃除しないため、揮発領域のままにする）
   • いずれの場合もスキル側で削除手順は持たない（worktree 内は /smart-git-sync の worktree 削除に、/tmp は OS に任せる）
   • 置き場所を .claude/ 配下にしない（sandbox 有効なプロジェクトは .claude を denyWrite にしているのが通例で、作成・更新が Operation not permitted で落ちる）。sandbox で作成・書き込みが拒否された場合は mktemp -d（それも拒否される隔離セッションではセッション scratchpad 配下）へフォールバックし、作業ファイルが揮発する旨をユーザーに伝える
   • 永続するのは「端末の再起動・セッション切替」に対してであって、worktree の削除に対してではない（ExitWorktree({ action: "remove" }) やセッション teardown で {作業Dir} も消える。これは掃除不要とのトレードオフ）
2. context.md / plan.md の書き出し — 雛形の書式で {作業Dir}/context.md（Issue 要件・-p 指示・プロジェクト固有基準）と {作業Dir}/plan.md（確定した初期計画の全文）を書く
3. ゲート — {作業Dir}/context.md と {作業Dir}/plan.md のどちらか一方でも存在しない場合は Workflow を起動しない（作成に戻る）
4. 開始日時の実測 — 起動直前に TZ=Asia/Tokyo date '+%Y-%m-%d %H:%M:%S' を実測し、startedAt として Workflow の args に含める（開始ログ表示用。継続セットの再起動でも再実測する）

レビュー内容:

• 標準モードは Opus（effort high）のレビュワーエージェントが計画をレビューする（観点は codex 標準と同一・union 不変: 実現可能性・影響範囲の抜け・手順の妥当性・リスクの見落とし・運用/保守/可用性・データ整合性/性能・テストカバレッジ・アーキテクチャ境界・プロジェクト固有基準との整合）。包括ラウンド（初回セット round 1）のみ、観点を G1（実現可能性 / 手順の妥当性 / テストカバレッジ）/ G2（影響範囲の抜け / リスクの見落とし / データ整合性・性能）/ G3（運用・保守・可用性 / アーキテクチャ境界 / プロジェクト固有基準）の 3 グループに分割した並列レビュワーとして起動し、差分スコープのラウンド 2+ と確認ラウンドは**単発 1 体（全 9 観点横断）**で実施する（敵対 Breaker のレンズ分割と同型。グループ間の重複指摘は plan-editor の採用判定で統合。一部グループ失敗は reviewerDegraded フラグで伝播。Issue #113: トークン・ストール露出の抑制）
• 敵対的モードは Breaker（Opus / effort high）× Judge（別の Opus / effort high）の二者構造で、Breaker は上記「敵対的モード（codex 系）」と同じ攻撃観点を包括ラウンド（初回セット round 1）のみ S（セキュリティ）/ C（正確性・データ）/ O（運用・保守）の 3 レンズに分割した並列エージェントとして起動し、以降のラウンドは単発 1 体（全攻撃観点横断）で実施する（観点の union は従来の単一 Breaker と同一で内容は不変。反例テストは書かない。一部レンズ失敗は breakerDegraded フラグで伝播）。Judge は全レンズの攻撃シナリオを集約し ≤4 件/バッチに分割して並列に裁定する（各 Judge の作業量を有界にし無進捗ウォッチドッグへのストールを防ぐ）。Judge の裁定基準は codex Judge と同等（4 分類・「4 点に答えられるものだけを真の欠陥とする」防御基準）。収束は dry-twice（「指摘 0 / High・Medium 採用 0」のクリーンなラウンドが連続 2 回で確定。Low のみの採用は反映しつつクリーン扱い〔重大度フロア。Issue #134〕。1 回目クリーン後の確認ラウンドは差分スコープを解除したフルスコープ）。ラウンド 2 以降の Breaker / レビュワーは直前ラウンドで plan-editor が反映した計画修正が触れた計画節＋影響領域を重点対象にする（差分スコープ化。ラウンド 1 と確認ラウンドは計画全体の包括レビューで、重点付けであって抑制ではない。前ラウンド追記文への、さらなる詳細要求は指摘にしない）
• レビュー指摘・裁定には軽微指摘フィルタを適用する: 実装の挙動・設計判断を変えない細部（テスト関数名・改名指示・docstring / コメント文言・ファイル / 行番号列挙の完全性）は items にせず低優先度として除外する（列挙の完全性が Issue の成果物そのものであるドキュメント改訂系 Issue は対象内。plan-editor は Low を原則不採用。Issue #134）
• 採用判定・計画修正は plan-editor エージェントが {作業Dir}/plan.md を編集して行う。収束後はオーケストレーターが plan.md を読んで投稿する

Workflow 返却の扱い（詳細は references/agent-orchestration.md）:

• converged: true → まず specQuestions が空か確認する。空でなければ下記の specQuestions 処理を先に行う（最終ラウンドの全指摘が「仕様未定」でも converged: true で返るため）。空なら収束確定 → plan.md を投稿フェーズへ
• converged: false（3 ラウンド消化）→ 上限チェックの AskUserQuestion。続行なら startRound を +3、priorSummary に経緯要約 + 前セット最終ラウンドの採用修正内容（records 末尾の adoptedItems）を入れ、返却の cleanStreak も引き継いで同じ scriptPath で再起動（startedAt は再実測して渡す。差分スコープと dry-twice の連続クリーン判定をセット跨ぎで連続させる）
• specQuestions が空でない → 裁定「仕様未定」の項目をオーケストレーターが AskUserQuestion で確認し、確定内容を {作業Dir}/context.md（追加指示）へ追記する。修正が必要になれば未収束として次セットへ回す（converged: true で返っていても投稿しない）
• auditFailed: true → レンズ S の Breaker がセキュリティ監査（security-audit.md の書き出し）を完了できなかった旨を完了報告に明記する
• breakerDegraded: true → 一部の Breaker レンズ（S/C/O）が失敗し、その観点の攻撃シナリオが未生成のまま収束扱いになった旨を完了報告に明記し、plan.md 投稿前にユーザーへ確認する
• reviewerDegraded: true → 標準モードで一部のレビュワー観点グループ（G1/G2/G3）が失敗し、その観点の指摘が未生成のまま収束扱いになった旨を完了報告に明記し、plan.md 投稿前にユーザーへ確認する
• judgeDegraded: true → 一部の Judge バッチが失敗し攻撃シナリオが未裁定のまま収束扱いになった旨を完了報告に明記し、plan.md 投稿前にユーザーへ確認する
• status: 'agent-failed' → 1 回だけ resumeFromRunId で再開、それでも失敗ならフォールバック（claude 系）へ

claude 系の独立性はコンテキスト隔離 + 役割分離で担保する（レビュワー・Breaker・Judge・plan-editor は互いに fresh エージェント）。codex 系のような別系統モデルの独立性はないため、認証・決済・データスキーマ・外部 API 変更などの重要変更には codex 系を推奨する。

レビュー済み表記

投稿本文の末尾に以下の 1 行を付ける:

• codex 標準・収束時: 🤖 Codex レビュー済み（標準, N ラウンド, 最終ラウンド採用指摘 0 件）
• codex 敵対的・収束時: 🤖 Codex 敵対的レビュー済み（Breaker×Judge, N ラウンド, 最終ラウンド採用指摘 0 件）
• claude 標準・収束時: 🤖 Claude レビュー済み（標準, Opus/effort high, N ラウンド, 最終ラウンド採用指摘 0 件）
• claude 敵対的・収束時: 🤖 Claude 敵対的レビュー済み（Breaker×Judge=独立 Opus, N ラウンド, 最終ラウンド採用指摘 0 件）
• 打ち切り時: 🤖 <Codex|Claude> レビュー実施（<standard|adversarial>, N ラウンド, 未収束で打ち切り）

フォールバック

codex 系（codex:rescue / codex exec が利用不能時） — 以下のいずれかに該当する場合:

• 呼び出し不能 — レビュー取得の経路（Claude Code ホストの codex:rescue / Codex CLI ホストの codex exec）が使えない。具体的には: Claude Code ホストで Codex プラグイン未導入・Codex CLI 未設定により codex:rescue が呼び出せない、Codex CLI ホストで codex バイナリが未インストール・未認証・昇格実行が承認されない（ホストのサンドボックス内では codex exec は起動できない）などで codex exec の実行に失敗する、またはそれ以外のエージェント環境でいずれの経路も提供されない
• 復旧不能なハング — 呼び出し済みのレビュー/裁定が返らず（silent death）、assets/codex-review-prompt.md の「運用ノート」に従った復旧（cancel → --resume 再投入）を 2 回試みても完了しない（ハング時は即フォールバックせず、必ず先に復旧を試みる。Codex CLI ホストの codex exec はジョブレジストリを持たない同期呼び出しのため、この複雑な復旧手順は対象外 — 同テンプレートの「Codex CLI ホストでの補足」の診断〔stdin リダイレクト漏れ・昇格の欠落・timeout 不足〕を確認して再実行し、解消しなければ「呼び出し不能」に倒す）

該当した場合:

• Claude 自身でレビュー・裁定を代行しない
• セキュリティ自動発動のケース（フラグ未指定で発動）では、Workflow が使えるなら claude 系の敵対的レビューに切り替えて実施する（従来の「未実施」より安全側。このケースでも投稿前の承認ゲートは維持する）。Workflow も使えない場合は「セキュリティ影響を検出したが Codex 不在のためレビュー未実施」と明示して通常フロー（手順 6 / 8c の承認ゲートあり）に切り替える
• codex 系フラグが明示されているケースでは、勝手に claude 系へ切り替えない（ユーザーは別系統モデルのレビューを選んでいる）。「Codex レビュー未実施」と明示して通常フロー（承認ゲートあり）に切り替え、必要なら -cldrl / -cldarl での再実行を案内する
• レビュー済み表記は付けない

claude 系（Workflow 利用不能時） — Workflow ツールが無い環境、または agent() が resumeFromRunId での再開後も失敗する場合:

• Claude 自身（オーケストレーター）でレビュー・裁定を代行しない
• 「Claude レビュー未実施」と明示して通常フロー（手順 6 / 8c の承認ゲートあり）に切り替える。セキュリティ自動発動起点の場合は「セキュリティ影響を検出したがレビュー未実施」と明示する
• レビュー済み表記は付けない

注意事項

• Issue の要件が不明確な場合は AskUserQuestion でユーザーに確認してから計画を作成する
• コードベース探索が不十分なまま計画を作らない — 手順 4 の各ステップを確実に実行する
• 投稿前に必ず手順 6（または 8c）の承認ゲートを通す — GitHub のコメントは削除しても編集履歴が残るため、誤投稿の影響が大きい。例外: {ループ明示} = true でレビューループが収束（または打ち切り投稿を選択）した場合はオプション指定を事前オプトインとみなし承認ゲートなしで投稿する（セキュリティ自動発動のみの場合は承認ゲートを維持する）
• 計画の更新で既存コメントを直接書き換えない — 新規コメントとして履歴を残す（計画 Issue の本文更新は例外）