deepen-plan

Deepen Plan

Introduction

Note: The current year is 2026. Use this when searching for recent documentation and best practices.

ce:plan does the first planning pass. deepen-plan is a second-pass confidence check.

Use this skill when the plan already exists and the question is not "Is this document clear?" but rather "Is this plan grounded enough for the complexity and risk involved?"

This skill does not turn plans into implementation scripts. It identifies weak sections, runs targeted research only for those sections, and strengthens the plan in place.

document-review and deepen-plan are different:

• Use the document-review skill when the document needs clarity, simplification, completeness, or scope control
• Use deepen-plan when the document is structurally sound but still needs stronger rationale, sequencing, risk treatment, or system-wide thinking

Interaction Method

Use the platform's question tool when available. When asking the user a question, prefer the platform's blocking question tool if one exists (AskUserQuestion in Claude Code, request_user_input in Codex, ask_user in Gemini). Otherwise, present numbered options in chat and wait for the user's reply before proceeding.

Ask one question at a time. Prefer a concise single-select choice when natural options exist.

Plan File

<plan_path> #$ARGUMENTS </plan_path>

If the plan path above is empty:

1. Check docs/plans/ for recent files
2. Ask the user which plan to deepen using the platform's blocking question tool when available (see Interaction Method). Otherwise, present numbered options in chat and wait for the user's reply before proceeding

Do not proceed until you have a valid plan file path.

Core Principles

1. Stress-test, do not inflate - Deepening should increase justified confidence, not make the plan longer for its own sake.
2. Selective depth only - Focus on the weakest 2-5 sections rather than enriching everything.
3. Prefer the simplest execution mode - Use direct agent synthesis by default. Switch to artifact-backed research only when the selected research scope is large enough that returning all findings inline would create avoidable context pressure.
4. Preserve the planning boundary - No implementation code, no git command choreography, no exact test command recipes.
5. Use artifact-contained evidence - Work from the written plan, its Context & Research, Sources & References, and its origin document when present.
6. Respect product boundaries - Do not invent new product requirements. If deepening reveals a product-level gap, surface it as an open question or route back to ce:brainstorm.
7. Prioritize risk and cross-cutting impact - The more dangerous or interconnected the work, the more valuable another planning pass becomes.