# Plan > Use when the user wants to build something new or plan a feature. Collaborative brainstorming that explores requirements, constraints, and approach through natural dialogue before any spec is written. - **Type:** Skill - **Install:** `agentstack add skill-ratler-dream-team-plan` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [Ratler](https://agentstack.voostack.com/s/ratler) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [Ratler](https://github.com/Ratler) - **Source:** https://github.com/Ratler/dream-team/tree/main/skills/plan ## Install ```sh agentstack add skill-ratler-dream-team-plan ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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 Before asking your first question, assess the complexity of the work based on what you learned in Phase 1. This calibrates how deep you go: - **Small/simple** (config change, minor tweak, isolated fix): Ask a few pointed questions hitting the key decisions. Get to Phase 3 quickly. - **Medium** (new feature, moderate refactor): Thorough coverage of all four areas below, with follow-up on any branches that emerge. - **Complex** (new subsystem, cross-cutting change, architectural shift): Relentless, systematic exploration. Walk every branch of the decision tree. Resolve dependency chains between decisions. Do not move on until every branch is addressed. Do not announce your assessment — just let it shape how many questions you ask and how deep you dig. **Be opinionated, not neutral.** For every question you ask: 1. First, investigate the codebase for evidence that answers it (read files, check patterns, look at existing conventions). 2. If the codebase provides an answer, present it as a recommended default: "Based on [what you found], I think [recommendation]. Does that match your intent, or is there a different angle?" 3. If the codebase doesn't provide a clear answer, offer 2-4 concrete choices with a recommended pick and your reasoning. 4. The user confirms, adjusts, or overrides. This is faster than open-ended questions because the user reacts rather than generates. **Walk the decision tree.** When an answer creates downstream decisions, follow those branches immediately — don't leave them dangling to circle back to later. Resolve dependency chains sequentially: if choosing X implies questions A and B, ask A and B before moving to the next top-level area. **One question per turn by default.** When questions are tightly coupled — one answer directly implies a follow-up — bundle them in the same message. Otherwise, stick to one question per turn. 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 every branch of the decision tree is resolved. If the user's answers reveal new complexity, follow that thread before moving on. If the user says "move on" or "that's enough," respect it and advance to Phase 3. ### 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, unless tightly coupled** — default to one question per message. Exception: when one answer directly implies a follow-up, bundle them together. - **Opinionated over neutral** — investigate the codebase before asking. Present a recommended answer as the default; let the user confirm or override. Only fall back to open-ended questions when the codebase gives no signal. - **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. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [Ratler](https://github.com/Ratler) - **Source:** [Ratler/dream-team](https://github.com/Ratler/dream-team) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-ratler-dream-team-plan - Seller: https://agentstack.voostack.com/s/ratler - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.