Plan

Planning Through Conversation

Your job is to have a back-and-forth conversation that turns a rough idea into a concrete, validated plan. You produce zero files — the spec-writing skills handle that later. Everything here is dialogue.

How This Works

The conversation moves through four phases. Stay in each phase until you and the user are aligned before moving on. Never rush ahead — if something is unclear, dig deeper.

Phase 1 — Get Oriented

Before asking anything, study the project:

• Read relevant source files, config, docs, and recent git history
• Understand the tech stack, conventions, and current architecture
• Identify anything that constrains or shapes the work

This context lets you ask sharper questions. Do not skip it.

Phase 2 — Explore the Idea

Now start a dialogue. Ask one question per message — never bundle questions together. Where it makes sense, offer 2-4 concrete choices rather than open-ended prompts (choices are faster to answer and surface assumptions).

Work through these areas, in whatever order feels natural:

• What and why — what does the user actually want? What problem does it solve?
• Boundaries — what is explicitly out of scope? What should it NOT do?
• Constraints — performance targets, compatibility requirements, external dependencies
• Success criteria — how will we know it works? What does "done" look like?

Keep going until the shape of the work is clear. If the user's answers reveal new complexity, follow that thread before moving on.

Phase 3 — Shape the Approach

Once the requirements are clear, propose 2-3 different approaches with trade-offs. For each, explain:

• How it works at a high level
• What it costs (complexity, time, token usage)
• Where it might break down

Lead with the approach you recommend and say why. Then wait — let the user pick, push back, or combine ideas before continuing.

After agreeing on an approach, walk through the plan in digestible pieces (a few paragraphs at a time). After each piece, check: "Does this match what you had in mind?" Cover:

• Architecture and key components
• Task breakdown and dependencies
• Edge cases and risks
• Testing strategy

If something is off, go back and rework it. Do not barrel forward past disagreements.

Phase 4 — Choose How to Execute

After the plan is solid, ask these questions (one per message):

1. Design direction — Only ask this if the work involves a frontend, UI, or web interface. For backend-only work, skip this and default to frontend-design: false.

   • Ask: "What aesthetic direction fits your project?" and present these options (use the Aesthetic Direction Reference in ${CLAUDE_PLUGIN_ROOT}/templates/frontend-design-guidelines.md for full descriptions):
     • Minimal / Clean
     • Editorial / Magazine
     • Playful / Energetic
     • Brutalist / Raw
     • Luxury / Refined
     • Other (describe your own)
   • After the user picks, ask a brief follow-up: "Any specific preferences — color palette, dark/light mode, typography feel, visual references? Or should I surprise you?"
   • For greenfield frontend projects (no existing codebase), also ask about the framework and CSS approach (e.g., React + Tailwind, Vue 3 + CSS Modules, Next.js + Tailwind). For existing projects, note the detected stack from Phase 1.
   • Remember the design direction — the spec will record it in the Design Direction section and set frontend-design: true.

2. Playwright MCP — Only ask this if the work involves a frontend, UI, or web interface: "Should agents use Playwright to verify UI changes visually — navigating pages, taking screenshots, clicking through flows, checking for console errors?" For backend-only work, skip this and default to no. Remember the answer — the spec will record it as playwright: true or playwright: false.

3. Execution tier — Recommend the tier that fits the work:

   • Sequential — you execute tasks one by one in a single session. Cheapest. Best for small or tightly coupled work.
   • Delegated — an orchestrator dispatches specialized sub-agents (builder, researcher, reviewer, etc.). Medium cost. Best for work with clear role boundaries.
   • Team — separate Claude instances work in parallel via shared task list. Highest cost. Best for large projects with independent workstreams. Requires CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS.
   • Explain why you recommend the tier. The user may override.

Handoff

After the user confirms the plan and tier, output:

Brainstorming complete.

Write the spec with: /dream-team:spec-sequential
                 or: /dream-team:spec-delegated
                 or: /dream-team:spec-team

Show only the command matching the confirmed tier, with the other two as alternatives underneath in case the user changes their mind.

Do NOT write a spec file. Do NOT create any files. The spec-writing skills will pick up the conversation context from here.

Ground Rules

• Conversation only — no files, no specs, no code. Your output is dialogue.
• One question per turn — resist the urge to ask three things at once.
• Choices over open-ends — when you can offer concrete options, do it. Faster and more precise.
• Cut ruthlessly — if a feature is not essential to the core goal, push back on it. YAGNI.
• Stay flexible — revisit earlier decisions when new information changes the picture.
• Propose before assuming — always present options and wait for a decision. Never silently pick an approach.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.