$ man context-wiki/plan-mode

プランモードは読み取り専用モードだ。Claude がコードベースを探索し、ファイルを読み、パターンを調査し、ステップを設計する。何にも触れない。ファイルの編集なし。コードの変更なし。状態を変えるコマンドの実行なし。ただ考えるだけ。Cursor ではプランモードに切り替えることで、エージェントに行動前の分析を強制できる。Claude Code では Shift+Tab で切り替える。重要な洞察：プランモードでは、Claude は仮定を立てる代わりに明確化のための質問をする。これだけで、複雑なタスクには使う価値がある。

パターン

複数の有効なアプローチがある場合や、大きなトレードオフがある場合にプランモードを使う。多くのファイルに触れる新機能の構築。データモデルのリファクタリング。キャンペーンワークフローのゼロからの設計。まだ完全に理解していない問題のデバッグ。 シンプルで明確に定義されたタスクにはプランモードを使わない。何をどこで変えるか正確に分かっているなら、そのままエージェントモードへ進む。変数のリネーム、タイポの修正、フィールドの追加。これらに計画は不要。 判断基準：タスクが複数の方法で失敗し得るなら、まず計画する。単純明快なら、そのまま実行する。

プロのコツ

私は複雑なタスクにはすべてプランモードを使う。だが単に「計画を立てて」とは言わない。具体的に、どのエージェントを使うか、各エージェントにどんなコンテキストが必要か、どの順序で実行するか、どのタスクを並行で走らせられるかを Claude に伝えさせる。これが実際のコンテキストエンジニアリングだ。コンテキストをエンジニアリングする計画をエンジニアリングしている。Clay Wiki を構築したとき、プランモードのアウトプットは各エージェントがどのファイルを作成するか、どの既存ファイルに編集が必要か、そして 4 つのエージェントすべてが異なるファイルを操作するため並行実行できることを正確に教えてくれた。あの計画がなければ、互いに干渉するエージェントを起動していただろう。

パターン

良いプランモードのアウトプットには以下が含まれる：(1) 作成するファイル（フルパス付き）。(2) 変更するファイル（どんな変更が必要か）。(3) タスク間の依存関係。どれが先に実行される必要があるか？どれが並行実行できるか？(4) 各タスクへのモデル推奨。重いクリエイティブな作業にはデフォルトモデル。コピペして適応させる作業には高速モデル。(5) 検証ステップ。実行後にすべてうまくいったことをどう確認するか？ プランモードのアウトプットが曖昧なステップの番号付きリストにすぎないなら、Claude に十分なコンテキストを与えていない。関連ファイルを読み込み、アーキテクチャを説明し、もう一度聞く。計画の質は、提供するコンテキスト次第だ。計画もコンテキストエンジニアリングだ。