Deep Plan

Delegate the hard thinking (planning, architecture, trade-off analysis) to an Opus sub-agent, then execute the plan in the main model. Optimizes for cost when the main conversation is running on a cheaper model but the task genuinely benefits from Opus-level reasoning for planning.

When this is worth using

Use when all of these hold:

• The task has real complexity (multi-step, judgment calls, non-obvious trade-offs).
• The main conversation is on Sonnet or Haiku (not Opus — if the main model is already Opus, this skill doesn't save money).
• Errors would be expensive to undo (stakeholder deliverable, production code, payroll numbers).

Do not use for: simple lookups, syntax questions, arithmetic, single-step tasks, things the main model handles fine on its own. Sub-agent overhead would cost more than it saves.

Flow

1. Confirm the task is worth the overhead. If it's clearly trivial, tell the user this skill isn't worth it for this request and just answer directly. Don't auto-delegate everything.
2. Extract the full task context. Pull the user's actual request, any relevant files, constraints, prior conversation context — everything the sub-agent needs to plan well. The sub-agent starts fresh, so the prompt must be self-contained.
3. Invoke the Plan sub-agent with model override. Use the Agent/Task tool with:
   • subagent_type: "Plan"
   • model: "opus"
   • description: short summary of what to plan (3–5 words)
   • prompt: full self-contained brief — goal, context, constraints, expected plan format. End with "Return a step-by-step plan with file paths, decisions, and risk flags. Do not execute."
4. Receive the plan. The sub-agent returns a structured plan.
5. Surface the plan to the user for review. Show the plan as-is (or lightly reformatted for readability). Ask one question: "Run this as-is, or want to tweak?" Let the user edit or approve.
6. Execute the plan in the main model. Once approved, step through the plan using the main model's regular tools. Do not re-invoke the sub-agent for execution — that defeats the cost savings.

Prompt template for the Plan sub-agent

When invoking the sub-agent, use this shape:

Task: {one-sentence goal}

Context:
- {file paths, system, relevant state}
- {prior conversation points that matter}
- {user preferences or conventions already established}

Constraints:
- {what must NOT change}
- {formatting, output, tools to use}
- {things that have bitten past attempts, if known}

Required plan shape:
- Step-by-step with file paths and tool calls where relevant
- Flag architectural decisions and trade-offs explicitly
- Call out risks and what could go wrong
- Do NOT execute. Return the plan only.

Output format: numbered steps, one action per step.

Cost reminder

Sub-agent tokens are billed at the sub-agent's model rate. So if the main conversation is on Sonnet and planning is delegated to Opus:

• Planning cost = Opus rate × planning tokens (small)
• Execution cost = Sonnet rate × execution tokens (usually large)
• Net: much cheaper than running the entire task on Opus.

If the main conversation is already on Opus, this skill adds overhead without saving money — the main model can plan just as well inline. Tell the user that when they trigger it on Opus, and ask whether they want to proceed anyway (for context-isolation benefits) or skip delegation.

Pitfalls

• Delegating trivial work. If the task is simple, skip the sub-agent and answer directly. This skill should be conservative about firing.
• Under-briefing the sub-agent. It has no memory of this conversation. If you forget to include a constraint, the plan will miss it. Err toward over-including context in the prompt.
• Executing in the sub-agent. The sub-agent plans only. If you let it execute, you're paying Opus rates for the whole task — the opposite of the goal.
• Skipping user review of the plan. The user should see the plan before you execute it. Planning is the step most likely to go sideways; catching it before execution is much cheaper than catching it after.
• Re-delegating mid-execution. If a new sub-problem arises during execution, handle it in the main model unless it's genuinely another deep-plan moment. Don't death-spiral into nested sub-agents.

Example

User: /deep-plan refresh the P5 carwash deck from the new source workbook and make sure every number ties

What to do:

1. Confirm this is worth delegation — yes, multi-step, stakeholder deliverable, numbers have to tie.
2. Build the sub-agent prompt including: period number, deck path, source workbook path, reference to the carwash-deck-refresh skill, the user's "don't overwrite manual edits" preference, the validation-pass requirement.
3. Invoke Agent with subagent_type: "Plan", model: "opus".
4. Get back a 6–10 step plan (read workbook, update KPIs, update tables, rename Mid-Period → Period End, validation pass, report changes, etc.).
5. Show plan to user: "Here's Opus's plan — run as-is, or adjust?"
6. On approval, execute in the main (cheaper) model using the actual pptx/xlsx tools.

What this skill does not do

• Switch the main conversation's model. Only invokes sub-agents with a model override.
• Run arbitrary tools in the sub-agent. Sub-agent is planning-only.
• Apply to conversational or trivial questions — those should just get answered directly.
• Chain multiple sub-agents for the same task. One plan, one execution.