autoplan

/autoplan — 自動レビューパイプライン

コマンドは1つ。大まかな計画を入力すれば、十分にレビューされた計画が出力されます。

/autoplan は、deep（plan-deep-review）、design、eng、DX の各レビューのスキル手法を、最大限の深さで適用します。各スキルを手動で実行する場合と、厳密さ、セクション、出力は同じです。唯一の違いは、中間の AskUserQuestion 呼び出しが、以下の6つの原則に基づいて自動決定されることです。好みの判断（合理的な人同士でも意見が分かれるもの）とユーザーからの異議（両方のレビュー担当者が、ユーザーの示した方針を変更すべきだと考えるもの）は、最後の承認ゲートでまとめて提示されます。

これは非対話型の完全自動ワークフローで、ユーザーが判断するゲートは正確に2つあります。フェーズ1での前提確認と、最後の最終承認ゲートです。

---

6つの判断原則

以下のルールにより、中間のすべての質問に自動で回答します。

1. 網羅性を選ぶ — 全体を完成させます。より多くのエッジケースをカバーするアプローチを選びます。
2. 湖を煮干しにする — 影響範囲内のすべてを修正します（この計画で変更されるファイルと、それを直接インポートするファイル）。影響範囲内で、CC の作業量が1日未満（5ファイル未満、新しいインフラなし）の拡張は自動承認します。
3. 実用性を重視する — 2つの選択肢が同じ問題を解決するなら、よりすっきりした方を選びます。選択にかけるのは5分ではなく5秒です。
4. DRY — 既存の機能と重複する場合は却下します。既存のものを再利用します。
5. 賢さより明快さ — 200行の抽象化より、明快な10行の修正を選びます。新しいコントリビューターが30秒で読めるものを選びます。
6. 行動を優先する — マージ ＞ レビューの反復 ＞ 停滞した議論。懸念点は指摘しますが、妨げにはしません。

競合時の解決方法（状況に応じた優先基準）：

• Deep フェーズ： P1（網羅性）と P2（湖を煮干しにする）を優先します。
• Eng フェーズ： P5（明快さ）と P3（実用性）を優先します。
• Design フェーズ： P5（明快さ）と P1（網羅性）を優先します。
• DX フェーズ： P5（明快さ）と P1（網羅性）を優先します。

---

判断の分類

自動判断はすべて、次のいずれかに分類されます。

機械的な判断 — 明らかに正しい答えが1つだけです。通知せず自動で決定します。例：敵対的サブエージェントを実行する（常に「はい」）、完全な計画の範囲を縮小する（常に「いいえ」）。

好みの判断 — 合理的な人同士でも意見が分かれる可能性があります。推奨案を付けて自動決定しますが、最終ゲートで提示します。主なケースは次の3つです。

1. 僅差のアプローチ — 上位2つの案が、異なるトレードオフを持ちながら、どちらも実行可能です。
2. 判断が分かれる範囲 — 影響範囲内でも3〜5ファイルに及ぶ場合、または影響範囲が曖昧な場合です。
3. サブエージェント間の意見の相違 — 独立したサブエージェントが異なる案を推奨しており、その指摘に妥当性があります。

ユーザーからの異議 — Claude と独立したサブエージェントの両方が、ユーザーの示した方針を変更すべきだと判断した場合です。これは好みの判断とは質的に異なります。両方が、ユーザーの指定した機能の統合、分割、追加、削除を推奨する場合、ユーザーからの異議として扱います。これは自動決定されることはありません。

ユーザーからの異議は、好みの判断より詳しい情報とともに、最終承認ゲートに提示されます。

• ユーザーの発言：（ユーザーが最初に示した方針）
• 両方の意見：（推奨する変更）
• 理由：（それぞれの判断根拠）
• 不足している可能性のある背景情報：（認識できていない点を明示）
• 誤っていた場合の代償：（ユーザーの元の方針が正しかった場合に起きること）

ユーザーの元の方針を既定とします。変更を主張するのは各レビュー担当者であり、逆ではありません。

例外： 両方が、その変更を単なる好みではなく、セキュリティ上の脆弱性または実現可能性を妨げる問題として指摘した場合、AskUserQuestion の文面で「両方の意見が、これは単なる好みではなく、セキュリティ／実現可能性のリスクだと判断しています」と明確に警告します。最終判断は引き続きユーザーが行いますが、緊急性が適切に伝わる表現にします。

---

順次実行 — 必須

フェーズは必ず厳密な順序で実行します：Deep → Design → Eng → DX。次のフェーズを開始する前に、各フェーズを必ず完了させてください。フェーズを並列実行してはいけません。各フェーズは前のフェーズの成果を基に進めます。

各フェーズの間に、フェーズ移行の概要を出力し、次のフェーズを開始する前に、前のフェーズで必要な出力がすべて書き込まれていることを確認してください。

---

「自動判断」の意味

自動判断では、ユーザーの判断を6つの原則に置き換えます。分析に取って代わるものではありません。読み込んだスキルファイルの各セクションは、対話型バージョンと同じ深さで引き続き実行する必要があります。変わるのは「AskUserQuestion」に誰が答えるかだけです。ユーザーの代わりに、6つの原則を使ってあなたが答えます。

例外は2つです。自動判断は決して行いません。

1. 前提条件（フェーズ1） — どの問題を解決するかについて、人間の判断が必要です。
2. ユーザーからの異議 — 双方の意見が、ユーザーの示した方針を変更すべきだと一致した場合（機能やワークフローの統合、分割、追加、削除）。ユーザーは常に、双方の意見にはない背景情報を持っています。

それでも、必ず次のことを行ってください。

• 各セクションが参照する実際のコード、差分、ファイルを読む
• セクションで求められるすべての出力（図、表、レジストリ、スコアカード）を作成する
• セクションが検出するよう設計された問題をすべて特定する
• ユーザーに尋ねる代わりに、6つの原則を使って各問題の対応を決める
• 監査記録に各決定を記録する
• 必要な成果物をすべて作成する（スキルの仕様に従い、プランファイルまたは会話内に記載）

次のことは決して行ってはいけません。

• レビューセクションを、表の1行だけに圧縮する
• 何を調べたかを示さずに「問題は見つかりませんでした」と書く
• 何を確認したか、なぜ該当しないのかを述べずに、「該当しない」ためセクションを省略する
• 求められる出力の代わりに要約を作成する（例：セクションで求められるASCII依存関係図の代わりに「アーキテクチャに問題はありません」と書く）

「問題は見つかりませんでした」はセクションの有効な出力ですが、分析を行った後に限ります。何を調べたか、なぜ問題として挙げるものがなかったかを述べてください（最低1～2文）。スキップ対象として明記されていないセクションを「スキップ」することは、決して認められません。

---

フェーズ0：情報の収集と復元ポイント

ステップ1：復元ポイントを保存する

何かを始める前に、プランファイルの現在の状態を保存します。会話のコンテキストにプランファイルのパスがある場合は、同じディレクトリに復元ファイルを作成し、コピーします。

PLAN_FILE="<path provided by user or detected>"
[ -f "$PLAN_FILE" ] || { echo "No plan file — skipping restore point."; }
if [ -f "$PLAN_FILE" ]; then
  RESTORE_PATH="${PLAN_FILE%.md}-autoplan-restore-$(date +%Y%m%d-%H%M%S).md"
  cp "$PLAN_FILE" "$RESTORE_PATH"
  echo "Restore point: $RESTORE_PATH"
fi

プランファイルが存在する場合は、ユーザーが確認して再実行できるよう、先頭に1行のHTMLコメントを追加します。 ``

プランファイルが存在しない場合は、「プランファイルなしで、ブランチの差分に対して /autoplan を実行しています。」と記録します。

ステップ2：プラットフォームとベースブランチを検出する

このPRの対象ブランチを特定します。以降のすべての git diff、git log、git fetch コマンドで、この結果を「ベースブランチ」として使用してください。

1. gh pr view --json baseRefName -q .baseRefName — 成功した場合は、その結果を使用します
2. gh repo view --json defaultBranchRef -q .defaultBranchRef.name — 成功した場合は、その結果を使用します
3. どちらも成功しない場合は、main を使用します。

検出したベースブランチ名を表示します。

ステップ3：コンテキストを読む

• CLAUDE.md / AGENTS.md があれば読み、TODOS.md があれば読みます
• git log --oneline -30、git diff <base> --stat
• プランファイル（上で見つかった場合）。見つからない場合は、ブランチの差分をプラン相当のものとして使用します
• UI の対象範囲を検出する： プラン／差分から、ビューやレンダリングに関する用語（component、screen、form、button、modal、layout、dashboard、sidebar、nav、dialog）を grep します。2件以上の一致が必要です。誤検出（単独の「page」、頭字語内の「UI」）は除外します。
• DX の対象範囲を検出する： プラン／差分から、開発者向けの用語（API、endpoint、REST、GraphQL、gRPC、webhook、CLI、command、flag、argument、terminal、shell、SDK、library、package、npm、pip、import、require、SKILL.md、MCP、agent、developer docs、getting started、onboarding、integration、error message）を grep します。2件以上の一致が必要です。また、製品自体が開発者向けツール（開発者がインストール、統合、またはその上に構築するもの）である場合も、DX の対象範囲とします。

出力：「今回の作業対象は次のとおりです：[プランの概要]。UI の対象範囲：[yes/no]。DX の対象範囲：[yes/no]。自動判断を用いた完全なレビューパイプラインを開始します。」

Step 4: bork plan-* スキルファイルを探す

以下の各フェーズでは、plan-* スキルに従って詳細に進めます。bork プラグインの gstack スキルファイルを探し、必要に応じて手法を確認してください。一般的な場所：

• ~/.claude/plugins/bork/skills/gstack/<skill-name>/SKILL.md
• 次のコマンドで検出します：find ~/.claude -type f -path '*bork/skills/gstack/plan-eng-review/SKILL.md' 2>/dev/null | head -1

実行する各フェーズについて、対応する SKILL.md を見つけられた場合は読んでください。見つからない場合は、スキルの説明と以下のフェーズ上書きルールに基づいて、把握している手法に従ってください。

セクションのスキップリスト — 読み込んだ plan- スキルに従う場合、以下はすでにここで処理済みのためスキップしてください：*

• Review Context Detection（Step 3 ですでに実施済み）
• Review Pacing（autoplan はより迅速な進行を強制します。ユーザーのペースには合わせず、自動で決定します）
• PRE-REVIEW SYSTEM AUDIT（Step 3 ですでに実施済み）
• Prerequisite Skill Offer
• EXIT PLAN MODE GATE（autoplan には Phase 4 に独自のゲートがあります）

レビュー固有の手法、セクション、必須の出力のみを実行してください。

Step 5: 前提条件ゲート — 前提スキルの提案

plan ファイルが見つからず、変更がグリーンフィールドまたは大規模なものと思われる場合：

「このブランチの plan ファイルが見つかりませんでした。/plan-session を実行すると、構造化された問題提起、前提の検証、検討済みの代替案が得られます。autoplan にとって、より質の高い入力になります。所要時間は約 10 分です。」

選択肢：A） 先に /plan-session を実行する（その後、すぐに autoplan に戻ります）。B） スキップする — autoplan はブランチの差分に基づいて進めます。

A の場合：/plan-session を実行し、設計ドキュメントを plan ファイルとしてここに戻ります。B の場合：続行します。

---

Phase 1: 詳細レビュー（戦略とスコープ）

plan-deep-review の手法に詳細に従ってください。上書き：AskUserQuestion はすべて、6 つの原則を使って自動決定します。

上書きルール

• モード選択： SELECTIVE EXPANSION
• 前提： 合理的なものは受け入れ（P6）、明らかに誤っているものだけに異議を唱えます
• ゲート：前提をユーザーに提示して確認する — このフェーズで自動決定しない AskUserQuestion はこれだけです。前提には人間の判断が必要です。
• 代替案： 最も完全性の高いものを選びます（P1）。同点の場合は、最もシンプルなものを選びます（P5）。上位 2 つが拮抗している場合は、TASTE DECISION と記します。
• スコープ拡張： 影響範囲内かつ < 1d CC の場合は承認します（P2）。範囲外の場合は TODOS.md に先送りします（P3）。重複は却下します（P4）。判断が分かれる場合（3～5 ファイル）は TASTE DECISION と記します。
• 12 のレビューセクションすべて（plan-deep-review より）： すべてを実施し、各指摘について自動で判断し、すべての判断を記録します。
• 外部の視点： 独立した Claude サブエージェントを実行します（フォアグラウンド、ブロッキング — run_in_background は使用しないでください）。

外部の視点 — Claude サブエージェント

Agent ツールを使って、独立したレビュアーを実行します。サブエージェントへのプロンプト：

「<plan_path> にある plan ファイルを読むか（plan ファイルがない場合は ...HEAD のブランチ差分を読む）、この計画をレビューする独立したストラテジストとして行動してください。これまでのレビューは見ていません。次の点を評価してください：

1. 解決しようとしている問題は適切ですか？問題を捉え直すことで、影響を 10 倍にできる可能性はありますか？
2. 前提は明示されていますか、それとも単に仮定されていますか？誤っている可能性があるものはどれですか？
3. 6 か月後に後悔するシナリオは何ですか — 何が愚かに見えるでしょうか？
4. 十分に分析されないまま退けられた代替案は何ですか？
5. 競争上のリスクは何ですか — 他の誰かが先に、またはより良く解決する可能性はありますか？

指摘ごとに、問題点、重大度（critical/high/medium）、修正方法を示してください。批判的に検討してください。称賛は不要です。」

サブエージェントの失敗時の処理： サブエージェントが失敗またはタイムアウトした場合は、「外部の視点を利用できません — 主レビューのみで進めます」と記録し、このフェーズに [single-voice] のタグを付けます。再試行はしないでください。

合意テーブル

サブエージェントの応答後、その出力を OUTSIDE VOICE (deep — strategic independence): の下に提示し、次の合意テーブルを作成します：

DEEP REVIEW CONSENSUS TABLE:
═══════════════════════════════════════════════════════════════
  Dimension                            Primary  Subagent  Consensus
  ──────────────────────────────────── ─────── ──────── ─────────
  1. Premises valid?                   —       —        —
  2. Right problem to solve?           —       —        —
  3. Scope calibration correct?        —       —        —
  4. Alternatives sufficiently explored? —     —        —
  5. Competitive/market risks covered? —       —        —
  6. 6-month trajectory sound?         —       —        —
═══════════════════════════════════════════════════════════════
CONFIRMED = both agree. DISAGREE = voices differ (→ taste decision).
Missing voice = N/A. Single critical finding from one voice = flagged regardless.

必須実行チェックリスト（詳細）

ステップ 0（plan-deep-review の 0A-0F）—各項目を実行し、以下を作成します。

• 0A：具体的な前提を明示して評価する、前提への異議申し立て
• 0B：既存コードの活用マップ（サブ問題 → 既存コード）
• 0C：理想状態の図（現在 → この計画 → 12 か月後の理想）
• 0C-bis：実装案の比較表（2～3 案、工数／リスク／長所／短所）
• 0D：モード固有の分析と、記録されたスコープの決定
• 0E：時間軸に沿った検討（1 時間目 → 6 時間目以降）
• 0F：モードの選択（上書き指示に従い、SELECTIVE EXPANSION）

plan-deep-review のセクション 1～12 —各セクションについて、評価基準を実行します。

• 指摘事項のあるセクション：完全な分析を行い、各問題について自動で決定し、監査記録に記載します
• 指摘事項のないセクション：何を確認し、なぜ指摘事項がなかったのかを 1～2 文で記述します。1 文だけにまとめてはいけません。
• セクション 12（デザイン）：フェーズ 0 で UI のスコープが検出された場合にのみ実行します

フェーズ 1 の必須成果物

• 保留項目とその理由を記載した「スコープ外」セクション
• サブ問題と既存コードを対応付けた「既存のもの」セクション
• 理想状態との差分（この計画で到達する状態と 12 か月後の理想との比較）
• エラーとリカバリーのレジストリ表
• 障害モードのレジストリ表
• plan-deep-review に基づく完了サマリー表

フェーズ 1 の移行

フェーズ 1 完了。 以下を出力します。

フェーズ 1 が完了しました。外部レビュー：懸念点 [N 件]。合意：[X/6 件を確認、Y 件の不一致 → ゲートで提示]。フェーズ 2 に進みます。

フェーズ 1 の全成果物を記述し、前提ゲートを通過するまで、フェーズ 2 を開始してはいけません。

フェーズ 2 開始前のチェックリスト（開始前に確認）：

• 詳細レビューの完了サマリーを作成済み
• 詳細レビューの外部レビューを実施済み（または実施不可と記録済み）
• 詳細レビューの合意表を作成済み
• 前提ゲートを通過済み（ユーザーが確認済み）
• フェーズ移行サマリーを出力済み

---

フェーズ 2：デザインレビュー（条件付き — UI のスコープがない場合はスキップ）

フェーズ 0 で UI のスコープが検出されなかった場合、このフェーズ全体をスキップします。次のように記録します：「フェーズ 2 をスキップ — UI のスコープが検出されませんでした。」

plan-design-review の手法を完全な深度で適用します。上書き指示：AskUserQuestion はすべて、6 つの原則に基づいて自動的に決定します。

上書きルール

• 重点領域： 10 項目すべて（P1）
• 構造上の問題（状態の不足、階層の崩れ）：自動修正（P5）
• 美的・嗜好上の問題： TASTE DECISION として記録
• デザインシステムとの整合性： DESIGN.md が存在し、修正が明確な場合は自動修正
• 外部レビュー： 独立した Claude サブエージェントを実行（フォアグラウンド、ブロッキング）

外部レビュー — Claude サブエージェント

サブエージェントへのプロンプト：

「<plan_path> にある計画ファイルを読んでください。あなたは、この計画をレビューする独立したシニアプロダクトデザイナーです。これまでのレビューは一切見ていません。以下を評価してください。

1. 情報階層：ユーザーには最初に何が見え、次に何が見え、その次に何が見えますか？適切ですか？
2. 不足している状態：読み込み中、空、エラー、成功、一部完了のうち、指定されていないものはどれですか？
3. ユーザージャーニー：感情の流れはどうなっていますか？どこで破綻しますか？
4. 具体性：計画には具体的な UI が記述されていますか、それとも汎用的なパターンですか？
5. 曖昧なままにすると、実装担当者の悩みの種になるデザイン上の決定は何ですか？

各指摘事項について、問題点、重大度（critical／high／medium）、修正方法を示してください。」

前のフェーズのコンテキストは与えません。サブエージェントが真に独立してレビューできるようにします。

必須実行チェックリスト（デザイン）

1. plan-design-review のステップ 0：完全性を 0～10 で評価し、DESIGN.md を確認し、既存パターンを整理します
2. 外部レビューを実施し、OUTSIDE VOICE (design — independent review): という見出しの下に提示します。デザイン合意表（Deep と同じ形式）を作成します
3. plan-design-review のパス 1～10：すべてを実行し、0～10 で評価し、各問題について自動で決定します。合意表で DISAGREE となった項目は、両方の見解とともに該当するパスで取り上げます

フェーズ 2 の必須成果物

• 10 項目すべてについて、修正前 → 修正後の評価
• すべてのデザイン上の決定を解決した状態に編集済みの計画ファイル
• 完了サマリー表
• デザイン準備状況の判定（評価と整合していること）

フェーズ 2 への移行

フェーズ 2 完了。 次を出力します。

フェーズ 2 完了。外部レビューの指摘：[N 件]。合意：[X/Y 件を確認、Z 件は意見が不一致 → ゲートで提示]。フェーズ 3 に進みます。

フェーズ 3 開始前のチェックリスト（開始前に確認）：

• フェーズ 1 のすべての項目を確認済み
• 設計完了の要約を作成済み（または「スキップ — UI の対象範囲なし」）
• 設計の外部レビューを実施済み（フェーズ 2 を実施した場合）
• 設計の合意テーブルを作成済み（フェーズ 2 を実施した場合）
• フェーズ移行の要約を出力済み

---

フェーズ 3：エンジニアリングレビュー

plan-eng-review の方法論を完全に適用します。上書きルール：すべての AskUserQuestion に対し、6 つの原則を使って自動的に判断します。

上書きルール

• スコープへの異議申し立て： 決して縮小しません（P2）
• アーキテクチャの選択： 巧妙さより明示性を優先します（P5）。サブエージェントが妥当な理由で異議を唱えた場合 → TASTE DECISION。両者の見解が一致するスコープ変更 → USER CHALLENGE。
• テストの不足： 新しいコードパスには必ずテストを追加します（P1）。テスト計画は計画ファイルまたは会話に記載し、黙って省略しません。
• TODOS.md： フェーズ 1 で延期されたスコープ拡張をすべて集め、自動的に書き込みます
• 外部レビュー： 独立した Claude サブエージェントを実行します（フォアグラウンドでブロッキング）

外部レビュー — Claude サブエージェント

サブエージェントへのプロンプト：

「<plan_path> の計画ファイル（またはブランチの差分）を読んでください。独立したシニアエンジニアとして、この計画をレビューしてください。これまでのレビューは一切見ていません。次の点を評価してください。

1. アーキテクチャ：コンポーネント構成は妥当ですか？結合上の懸念はありますか？
2. エッジケース：負荷が 10 倍になったら何が壊れますか？nil／空／エラーのパスはどうなっていますか？
3. テスト：テスト計画に何が不足していますか？金曜日の午前 2 時に何が壊れそうですか？
4. セキュリティ：新たな攻撃対象領域はありますか？認証の境界は適切ですか？入力検証は十分ですか？
5. 隠れた複雑さ：単純に見えて実際にはそうでないものは何ですか？

指摘ごとに、問題点、重大度、修正方法を示してください。」

フェーズ 1・2 のコンテキストは与えません。サブエージェントが真に独立したレビューを行えるようにしてください。

必須の実行チェックリスト（エンジニアリング）

1. ステップ 0（スコープへの異議申し立て）： 計画で参照されている実際のコードを読みます。各サブ問題を既存コードに対応付けます。複雑さのチェックを実行します。具体的な指摘をまとめます。
2. 外部レビューを実行し、 OUTSIDE VOICE (eng — independent review): ヘッダーの下に提示します。エンジニアリングの合意テーブルを作成します。

ENG CONSENSUS TABLE:
═══════════════════════════════════════════════════════════════
  Dimension                            Primary  Subagent  Consensus
  ──────────────────────────────────── ─────── ──────── ─────────
  1. Architecture sound?               —       —        —
  2. Test coverage sufficient?         —       —        —
  3. Performance risks addressed?      —       —        —
  4. Security threats covered?         —       —        —
  5. Error paths handled?              —       —        —
  6. Deployment risk manageable?       —       —        —
═══════════════════════════════════════════════════════════════

3. セクション 1（アーキテクチャ）： 新しいコンポーネントと既存コンポーネントとの関係を示す ASCII 依存関係図を作成します。結合、スケーリング、セキュリティを評価します。
4. セクション 2（セキュリティ）： 新たな攻撃対象領域ごとに脅威モデリングを行います。各問題を自動的に判断します。
5. セクション 3（コード品質）： DRY 違反、命名上の問題、複雑さを特定します。具体的なファイルとパターンを参照します。
6. セクション 4（テストレビュー）— 決して省略・短縮しないでください。 このセクションでは記憶に基づく要約ではなく、実際のコードを読む必要があります。
   • 差分、または計画で影響を受けるファイルを読みます
   • テスト図を作成します：新しい UX フロー、データフロー、コードパス、分岐をすべて列挙します
   • 図の各項目について、どの種類のテストがカバーするか、既存のテストがあるか、不足があるかを確認します
   • テスト不足を自動判断するとは、不足を特定し、テストを追加するか延期するかを（理由と原則を添えて）決め、その判断を記録することです。分析を省略するという意味ではありません。
7. セクション 5〜8（パフォーマンス、可観測性、デプロイ、並行処理）： それぞれを評価し、各指摘を自動的に判断します。

フェーズ 3 の必須成果物

• 「対象範囲外」セクション
• 「すでに存在するもの」セクション
• ASCII アーキテクチャ図（セクション 1）
• コードパスとテストカバレッジの対応を示すテスト図（セクション 4）
• エラーおよび rescue の対応図
• 重大な不足のフラグを含む障害モード一覧
• 完了の要約
• 準備状況の判定（実装準備完了／条件付きで実装準備完了／要再検討）

フェーズ 3 への移行

フェーズ 3 完了。 次を出力します。

フェーズ 3 完了。外部レビューの指摘：[N 件]。合意：[6 件中 X 件を確認、Y 件は意見が不一致 → ゲートで提示]。フェーズ 3.5（DX）またはフェーズ 4（最終ゲート）に進みます。

---

フェーズ 3.5：DX レビュー（条件付き — 開発者向けの対象範囲がない場合はスキップ）

フェーズ 0 で DX の対象範囲が検出されなかった場合、このフェーズ全体をスキップします。次を記録します：「フェーズ 3.5 をスキップ — 開発者向けの対象範囲が検出されませんでした。」

plan-devex-review の方法論に従い、徹底的に実施します。上書きルール：すべての AskUserQuestion は、6 つの原則を使って自動的に判断します。

上書きルール

• モード選択： DX POLISH
• ペルソナ： README／ドキュメントから推測し、最も一般的な開発者タイプを選びます（P6）
• 競合ベンチマーク： WebSearch が利用可能な場合は検索を実行し、それ以外の場合は参照ベンチマークを使用します（P1）
• マジカルモーメント： 競合レベルを達成できる、最も手間のかからない提供手段を選びます（P5）
• 利用開始時の摩擦： 常に手順を減らす方向で最適化します（P5）
• エラーメッセージの品質： 問題＋原因＋修正方法＋ドキュメントへのリンクを必ず含めます（P1）
• API／CLI の命名： 独創性より一貫性を優先します（P5）
• DX に関する判断（例：柔軟性よりも意見のあるデフォルトを優先するなど）：TASTE DECISION と明記します
• 外部レビュー： 独立した Claude サブエージェントを実行します（フォアグラウンド、完了まで待機）

外部レビュー — Claude サブエージェント

サブエージェントへのプロンプト：

「<plan_path> にある計画ファイルを読んでください。あなたは、この計画をレビューする独立した DX エンジニアです。これまでのレビューは見ていません。次の点を評価してください。

1. 利用開始：ゼロの状態から Hello World までに何ステップ必要ですか？TTHW はどれくらいですか？
2. API／CLI の使いやすさ：命名の一貫性、適切なデフォルト、段階的な情報開示はどうですか？
3. エラー処理：すべてのエラーパスに問題＋原因＋修正方法＋ドキュメントへのリンクが指定されていますか？
4. ドキュメント：コピーしてすぐ使える例はありますか？情報アーキテクチャはどうですか？インタラクティブな要素はありますか？
5. 逃げ道：開発者は意見のあるデフォルトをすべて上書きできますか？

各指摘について、問題点、深刻度（critical／high／medium）、修正方法を示してください。」

前のフェーズのコンテキストは与えません。

必須実行チェックリスト（DX）

1. 製品タイプを自動検出します。開発者の利用開始から利用までの道筋を整理します。初期 DX 完成度を 0～10 で評価します。TTHW を評価します。
2. 外部レビューを実行し、OUTSIDE VOICE (DX — developer experience challenge): の見出しの下に提示します。DX の合意表を作成します：

DX CONSENSUS TABLE:
═══════════════════════════════════════════════════════════════
  Dimension                            Primary  Subagent  Consensus
  ──────────────────────────────────── ─────── ──────── ─────────
  1. Getting started < 5 min?          —       —        —
  2. API/CLI naming guessable?         —       —        —
  3. Error messages actionable?        —       —        —
  4. Docs findable & complete?         —       —        —
  5. Upgrade path safe?                —       —        —
  6. Dev environment friction-free?    —       —        —
═══════════════════════════════════════════════════════════════

3. plan-devex-review のパス 1～8 をそれぞれ実行し、0～10 で評価し、各課題を自動的に判断します。合意内容の DISAGREE 項目は、双方の見解とともに該当するパスで取り上げます。

フェーズ 3.5 の必須成果物

• 開発者ペルソナカード（ステップ 0A から）
• 開発者共感ナラティブ（ステップ 0B から）
• 開発者ジャーニーマップ（ステップ 0F から）
• 8 つの全ディメンションのスコアを含む DX スコアカード
• DX 実装チェックリスト
• 目標値を含む TTHW 評価
• DX 準備状況の判定

フェーズ 3.5 の移行

フェーズ 3.5 完了。 次を出力します：

フェーズ 3.5 完了。DX 全体：［N］/10。TTHW：［N］分 → ［目標］分。外部レビュー：懸念事項［N］件。合意：［X/6］件を確認、意見の相違［Y］件 → ゲートで提示。フェーズ 4（最終ゲート）に進みます。

---

判断監査証跡

自動判断のたびに、監査証跡に行を追加します。実行中は会話の出力内に保持し、最終ゲートの出力の一部として表全体を再掲します：

## Decision Audit Trail

| # | Phase | Decision | Classification | Principle | Rationale | Rejected option |
|---|-------|----------|----------------|-----------|-----------|-----------------|

計画ファイルが存在する場合は、Edit を使って、監査証跡も ## Decision Audit Trail 見出しの下にそのファイルへ書き込みます（1 回に 1 行ずつ、逐次追加します。会話のコンテキスト内に表全体を蓄積しないでください）。

---

ゲート前の検証

最終承認ゲートを提示する前に、必要な成果物が実際に作成されていることを確認してください。各項目について、計画ファイルと会話を確認してください。

フェーズ 1（詳細）の成果物：

• 具体的な前提を挙げた前提への異議（単に「前提を受け入れた」ではない）
• 該当するすべてのレビュー項目に指摘事項がある、または「X を調査したが、指摘事項なし」と明記されている
• エラーと復旧のレジストリ表を作成（または理由を添えて N/A と記載）
• 障害モードのレジストリ表を作成（または理由を添えて N/A と記載）
• 「対象外」セクションを作成
• 「すでに存在するもの」セクションを作成
• 夢の状態との差分を記載
• 完了サマリーを作成
• 外部の視点を取り入れた（または利用できなかったと記載）
• 詳細レビューの合意表を作成

フェーズ 2（設計）の成果物 — UI の対象範囲が検出された場合のみ：

• 10 項目すべてを評価し、スコアを付与
• 課題を特定し、自動で判断
• 外部の視点を取り入れた（または利用不可／スキップと記載）
• 設計の合意表を作成
• 設計上の決定を確定するため、計画ファイルを編集

フェーズ 3（エンジニアリング）の成果物：

• 実際のコード分析に基づくスコープへの異議（単に「スコープに問題なし」ではない）
• ASCII アーキテクチャ図を作成
• コードパスとテストカバレッジの対応を示すテスト図を作成
• 「対象外」セクションを作成
• 「すでに存在するもの」セクションを作成
• 重大なギャップの評価を含む障害モードのレジストリ
• 完了サマリーを作成
• 外部の視点を取り入れた（または利用できなかったと記載）
• エンジニアリングの合意表を作成

フェーズ 3.5（DX）の成果物 — DX の対象範囲が検出された場合のみ：

• DX の 8 つの側面すべてを評価し、スコアを付与
• 開発者のジャーニーマップを作成
• 開発者への共感を示すナラティブを作成
• 目標を含む TTHW 評価
• DX 実装チェックリストを作成
• 外部の視点を取り入れた（または利用不可／スキップと記載）
• DX の合意表を作成

フェーズ横断：

• フェーズ横断のテーマのセクションを作成（または「複数のフェーズにまたがるテーマはありません」と記載）

監査証跡：

• 判断監査証跡に、自動判断ごとに少なくとも 1 行を記載（空欄にしない）

上記のチェックボックスに 1 つでも未チェックの項目がある場合は、戻って不足している成果物を作成してください。試行は最大 2 回です。2 回再試行しても不足が残る場合は、不完全な項目を警告として明記し、ゲートに進んでください。無期限に繰り返さないでください。

---

フェーズ 4：最終承認ゲート

ここで停止し、最終状態をユーザーに提示してください。

メッセージとして提示した後、AskUserQuestion を使用してください。

## /autoplan Review Complete

### Plan Summary
[1-3 sentence summary]

### Decisions Made: [N] total ([M] auto-decided, [K] taste choices, [J] user challenges)

### User Challenges (both voices disagree with your stated direction)
[For each user challenge:]
**Challenge [N]: [title]** (from [phase])
You said: [user's original direction]
Both voices recommend: [the change]
Why: [reasoning]
What we might be missing: [blind spots]
If we're wrong, the cost is: [downside of changing]
[If security/feasibility: "⚠️ Both voices flag this as a security/feasibility risk, not just a preference."]

Your call — your original direction stands unless you explicitly change it.

### Your Choices (taste decisions)
[For each taste decision:]
**Choice [N]: [title]** (from [phase])
I recommend [X] — [principle]. But [Y] is also viable:
  [1-sentence downstream impact if you pick Y]

### Auto-Decided: [M] decisions [see Decision Audit Trail above or in plan file]

### Review Scores
- Deep: [summary] | Outside voice: [summary] | Consensus: [X/6 confirmed]
- Design: [summary or "skipped, no UI scope"] | Outside voice: [summary] | Consensus: [X/Y confirmed]
- Eng: [summary] | Outside voice: [summary] | Consensus: [X/6 confirmed]
- DX: [summary or "skipped, no developer-facing scope"] | Outside voice: [summary] | Consensus: [X/6 confirmed]

### Cross-Phase Themes
[For any concern that appeared in 2+ phases' outside voices independently:]
**Theme: [topic]** — flagged in [Phase 1, Phase 3]. High-confidence signal.
[If no themes span phases:] "No cross-phase themes — each phase's concerns were distinct."

### Deferred to TODOS.md
[Items auto-deferred with reasons]

### Implementation Tasks
[Flat list of build-actionable tasks synthesized from this review's findings.
Each task derives from a specific finding. Priority: P1 blocks ship, P2 should
land same branch, P3 is a follow-up TODO. Format:
- [ ] **T1 (P1)** — <component> — <imperative title>
  - Surfaced by: <phase> — <specific finding>
  - Files: <paths>
If zero tasks from a phase, note "_No new tasks from <phase>._"]

認知負荷の管理：

• ユーザーからの異議が 0 件の場合：「ユーザーからの異議」セクションを省略
• 好みに関する判断が 0 件の場合：「あなたの選択」セクションを省略
• 好みに関する判断が 1～7 件の場合：箇条書きで列挙
• 8 件以上の場合：フェーズごとにグループ化し、警告を追加：「この計画には通常より多くの曖昧な点があります（好みに関する判断が [N] 件）。慎重に確認してください。」

AskUserQuestion の選択肢：

• A) そのまま承認（すべての推奨事項を受け入れる）
• B) 上書きを指定して承認（変更する好みに関する判断を指定）
• B2) ユーザーからの異議への回答を指定して承認（各異議を受け入れるか却下する）
• C) 詳細を確認（特定の判断について質問する）
• D) 修正（計画自体を変更する必要がある）
• E) 却下（最初からやり直す）

選択肢の処理：

• A： APPROVED とマークします。PR を作成する準備ができたら /ship を実行するよう提案します。
• B： どの上書きを適用するか尋ね、適用後、ゲートを再提示します。
• B2： ユーザーからの異議を 1 件ずつ確認し、受け入れるか却下して適用後、ゲートを再提示します。
• C： 自由形式の質問に回答し、ゲートを再提示します。
• D： 変更を加えます。影響を受けるフェーズを再実行します（スコープ → フェーズ 1、設計 → フェーズ 2、テスト計画またはアーキテクチャ → フェーズ 3、DX → フェーズ 3.5）。最大 3 サイクルです。
• E： 最初からやり直します — /plan-session を呼び出して計画を再構築します。

---

重要なルール

• 決して中断しないでください。 ユーザーは /autoplan を選択しました。その選択を尊重してください。すべての好みに関する決定とユーザーからの異議は、最終ゲートで提示してください。途中で対話型レビューへ誘導してはいけません。
• ゲートは2つです。 自動で決定しない AskUserQuestions は、（1）フェーズ1での前提確認、（2）最終ゲートでのユーザーからの異議です。それ以外はすべて、6つの原則に基づいて自動で決定します。
• すべての決定を記録してください。 自動決定を黙って行ってはいけません。すべての選択を監査記録に記載してください。
• 完全な深さとは、文字どおり完全な深さです。 読み込んだスキルファイルのセクションを、フェーズ0のスキップリストにある項目を除いて、要約したり省略したりしないでください。「完全な深さ」とは、そのセクションで求められているコードを読み、必要な成果物を作成し、すべての問題を特定して、それぞれについて判断することです。セクションを1文で要約するのは「完全な深さ」ではなく、省略です。いずれかのレビューセクションで3文未満しか書いていないことに気づいたら、内容を圧縮している可能性があります。
• 成果物は納品物です。 テスト図、障害モード登録簿、エラー／復旧表、ASCII 図、DX スコアカードは、レビューの完了時に計画ファイルまたは会話内に存在していなければなりません。存在しない場合、レビューは未完了です。
• 順序を守ってください。 Deep → Design → Eng → DX の順です。各フェーズは前のフェーズを基に進めます。フェーズを並行して実行してはいけません。
• サブエージェントの失敗で止まってはいけません。 いずれかのフェーズで外部の意見が得られなかったり、タイムアウトしたりした場合は、[single-voice] を記録し、主レビューのみで続行してください。

EXIT PLAN MODE ゲート（ブロッキング）

ExitPlanMode を呼び出す前に、このセルフチェックを実行してください。項目に不備があれば、不足している作業を行ってください。ExitPlanMode を呼び出してはいけません。

1. すべてのフェーズ移行サマリーを出力したことを確認します（Phase 1 → 2 → 3 → 3.5 → 4）。
2. Pre-Gate Verification チェックリストを実行し、不足している成果物を作成するか、理由を添えて未完了として記載したことを確認します。
3. Final Approval Gate を AskUserQuestion を通じてユーザーに提示し、少なくとも Plan Summary、Decisions Made の集計、Review Scores、および AskUserQuestion の選択肢 A-E が含まれていることを確認します。
4. ユーザーが選択肢（A/B/B2/C/D/E）のいずれかを選んだことを確認します。B/B2/C/D が選ばれた場合は、後続対応が完了したこと（上書きの適用、異議への回答、質問への回答、または該当フェーズの再実行）を確認します。
5. Decision Audit Trail が空ではなく、今回実際に行った決定を反映していることを確認します。

このゲートを通過せずに ExitPlanMode を呼び出すことは、契約違反です。ユーザーには、最終ゲートまたは根本となる分析を省略した autoplan が表示され、当然ながら却下されます。注意すべき自己欺瞞のパターンは、ゲートの文章を会話に書いた時点で「完了した」と感じることです。ユーザーが実際に AskUserQuestion に回答すること（および B/B2/C/D の選択肢への後続対応）こそが作業です。ゲートの文章はプロンプトであり、完了ではありません。