planning

計画立案

対話を通じて反復的に、詳細な実装計画を作成します。懐疑的に、徹底的に、協力的に進めてください。

セットアップ（開始前）

1. 自律モード — 呼び出し元のコマンドから渡されます。指定がない場合は、デフォルトで Critical にします。

   モード	動作
   Autopilot	独自に調査し、計画全体を作成して、最終確認のみを求めます
   Critical（デフォルト）	調査ステップごとに、草案の作成前に確認質問をします。判断が必要な箇所では設計の選択肢を提示します
   Verbose	すべてのサブステップで状況を確認します。理解を検証し、範囲を確認し、不明点を提示して、各フェーズの前に確認を求めます

2. コミット設定とオーケストレーション — Autopilot 以外では、AskUserQuestion を通じて一度だけ質問します（両方の質問を1回にまとめます。セッションで Workflow ツールが使えない場合は2つ目の質問を省略します）。

   質問	選択肢
   「手動検証に合格した後、各フェーズの完了時にコミットを作成しますか？」	1. はい（推奨）、2. いいえ。コミットは自分で行います
   「調査スパイクを Workflow スクリプトとして実行しますか？（並列エージェントが増え、トークン消費量も増えます）」	1. はい — Workflow ファンアウト、2. いいえ — 通常のサブエージェント（デフォルト）

   2つ目の質問に「はい」と答えることが、Workflow ツールに必要な明示的なオプトインです。Autopilot（質問なし）の場合は、通常のサブエージェントをデフォルトとして使用します。

3. 過去の知見 — 任意のサブスキル： ~/.agentic-learnings.json が存在する場合は、最初に /learning recall <topic> を実行します。

4. 設計ドキュメント（読み、遵守する） — 対象システムの設計ドキュメント（thoughts/*/design-docs/<system-slug>.md）がある場合は、調査の前に読みます。計画では用語集の用語を使い、不変条件や境界に違反しないようにします。矛盾があれば、暗黙のうちに避けて計画するのではなく、明示的な判断事項としてユーザーに提示します。計画で設計を意図的に変更する場合は、設計ドキュメントの更新（Decision log + Amendment log）を計画のステップに含めます。desplega:design-docs を参照してください。

10のルール

1. まず骨組みを作る — 調査の前に、計画モードを終了し、cc-plugin/base/skills/planning/template.md を基に thoughts/<username|shared>/plans/YYYY-MM-DD-description.md を作成します。（ユーザー名がわかっている場合は taras などの名前を使い、それ以外は thoughts/shared/ にします。）ファイルは段階的に更新します。ユーザーが早い段階で軌道修正できます。

2. 負荷の高い作業はすべてサブエージェントに任せる — ファイルの読み取り、調査、検証を対象とします。デフォルトで run_in_background: true にします。生のツール出力をメインセッションに含めないでください。 サブエージェント一覧：codebase-locator（ファイルの特定）、codebase-analyzer（現在の実装の把握）、codebase-pattern-finder（類似機能の検索）、context7 MCP（ライブラリやフレームワークの詳細）、Explore または general-purpose（言及されたファイルの読み取り）。 実行担当の振り分け：desplega:delegate-work が使える場合は、デフォルトのモデルではなく、対応表に従って各サブエージェントのモデルを選びます（特定 → Haiku、分析 → Sonnet）。セットアップで Workflow ファンアウトを選んだ場合は、各セクションの調査スパイクを Workflow スクリプトとして実行します（同じ対応表に従って model／effort／agentType のオプションを指定します）。計画の草案作成は、常にメインセッションで行います。

3. AskUserQuestion を使って質問する — 規約については desplega:ask-user を参照してください。チャット上で箇条書きにして直接質問してはいけません。

4. 各ステップの後に質問する（Critical／Verbose） — 計画をセクションごとに進めます。現状分析 → 実装アプローチ → フェーズ概要 → フェーズ詳細の順です。各セクションで、サブエージェントを起動し、調査結果を統合し（file:line 形式の参照を含めます）、不足情報について質問し、草案を作成してから次のセクションに進みます。思い込みは、質の低い計画を生む最大の原因です。

5. 各フェーズに具体的な成果物を定める — 各フェーズの概要には、完了時に存在しているファイル、機能、または出力を明記します。「Xを改善する」「Yをリファクタリングする」は要注意の表現です。

6. 作業の実証：自動検証＋自動QAを最大限に活用する — すべてを実行可能なコマンド（低レベル）と、エージェント主導のQA（ブラウザー操作、スクリーンショットの差分比較、CLI の手順確認）に移します。手動検証は例外です。個々のフェーズでの通常の確認ではなく、複数領域にまたがるQAや、証拠の提示が多く必要なQAには、desplega:qa ドキュメントへのリンクを含む独立した ### QA Spec (optional): を用意します。

7. 分割を提案する — フェーズのサブステップが4つを超える場合、または異なる関心事が2つを超える場合は、分割します。1回の実装セッションに収まらない計画は、複数の小さな計画（例：契約 → ストレージ → UI）に分割します。逆の場合も同様です。タスク全体が1つのサブシステム内で約1～3フェーズに収まる場合は、完全な計画ではなく /one-shot（desplega:one-shot）を提案します。

8. 率直かつ遠慮なく異議を唱える — 計画が大きすぎる、曖昧である、関心事が混在している、または明白なリスクがある場合は、desplega:feedback を使用します。過剰な設計も対象です。提案された抽象化、レイヤー、新しい依存関係を desplega:engineering-standards（削除テスト、2アダプタールール、新規依存関係テスト）に照らして検討し、同文書の異議申し立てプロトコルに従って、よりシンプルな代替案を具体的に示しながら、基準を満たさない点に異議を唱えます。黙っていることは、破滅的な共感です。

9. 計画を提示する前に、Haiku サブエージェントで構造を検証する（model: haiku を指定した general-purpose）。以下を確認します。すべてのフェーズに3つの Success Criteria サブセクションがあること、すべての項目が - [ ] 形式であること、自動チェックが実行可能なコマンドであること、参照されているパスが存在すること。計画を提示する前に修正を適用します。

10. 新しいセッションに引き継ぐ — この場では決して実装しない。 終了時の手順：

    1. /file-review:file-review <plan-path> を開き（Autopilot の場合を除く）、コメントを反映します。

    2. 必要に応じて、ギャップ分析のために desplega:reviewing を呼び出します（AskUserQuestion で提案します）。

    3. 任意のサブスキル： 重要な知見が得られた場合は、/learning capture で記録します。

    4. いずれかのフェーズに ### QA Spec (optional): ブロックがある場合、 引き継ぎ前に desplega:qa を使ってQAドキュメント（thoughts/<username|shared>/qa/YYYY-MM-DD-[feature].md）を作成します。シナリオは計画ではなく、ドキュメントに記載します。

    5. AskUserQuestion を使ってユーザーに尋ねます。

       質問	選択肢
       "Plan ready. What's next?"	1. 新しいセッションで実装する、2. 先に /review を実行する、3. 今は完了（計画を保留する）

    6. 次の内容を明確に伝えます。「Claude Code の新しいセッションを開き、/desplega:implement-plan <path> を実行してください。新しいセッションを開始することで、実装コンテキストをクリーンに保てます。」

コミットの統合

Setup でフェーズごとのコミットが有効になっている場合：

• 各フェーズの手動検証に合格した後、[phase N] <brief description> 形式でコミットします。
• 手動検証に合格したことを明示的に確認してから、コミットします。
• それ以外の場合はスキップします。コミットはユーザーが行います。

Success Criteria の形式（必須）

標準の形式と見出し階層は cc-plugin/base/skills/planning/template.md に記載されています。構造の検証は自動的に実行されます（ルール9、Haiku サブエージェント）。