# Bt Ideate > name: bt:ideate - Skill: `btraut/bt-ideate` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add btraut/bt-ideate` - Raw SKILL.md: https://api.skillmd.com/api/skills/btraut/bt-ideate/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: btraut (https://skillmd.com/u/btraut) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/btraut/bt-ideate --- name: bt:ideate description: Explore an idea through collaborative dialogue without committing to a requirements document. Use when the user wants to clarify their thinking, test directions, or talk through a possible feature or improvement without deciding yet whether it should become a full project. --- # bt:ideate Use this skill to guide a user from a rough idea to a clearer understanding of what they might want. `bt:ideate` is for exploration, not durable artifact creation. It should help the user sharpen their thinking through focused questions, pressure-testing, and lightweight comparison of directions, then end with an in-chat summary and possible next steps. This skill does not write files. If the user wants something durable, move into a more formal requirements flow as a next step rather than creating files here. If the feature description is empty, ask: "What would you like to explore? Please describe the feature, problem, or improvement you're thinking about." Do not proceed until you have a concrete topic. ## Core Principles 1. **Keep it exploratory** - This is for clarifying thinking, not forcing commitment. - Do not turn a loose conversation into process theater. 2. **Use disciplined question flow** - Ask one question at a time. - Pressure-test the request. - Bring alternatives and tradeoffs instead of just interviewing. 3. **Stay lightweight unless the idea earns more rigor** - A shallow idea should stay shallow. - If the idea becomes substantial, surface that and suggest moving into a more formal requirements flow. 4. **Prefer shared understanding over artifact production** - The goal is a clearer mental model, not a requirements doc. - End with a summary the user can react to in chat. ## Interaction Rules 1. **Ask one question per response** - Do not batch unrelated questions together. 2. **Prefer single-select multiple choice** - Use it when choosing one direction, one priority, or one next step. 3. **Use multi-select rarely** - Only use it for compatible sets like goals, constraints, or non-goals. - If prioritization matters, follow up by asking which selected item is primary. 4. **Use open-ended questions when options would be misleading** - Do not force multiple-choice structure onto fuzzy or novel answers. 5. **Mark exactly one option as recommended** - In Codex `request_user_input`, suffix the label with `(Recommended)`. - In Claude `AskUserQuestion`, use an explicit `recommended` flag when available or clearly label one option as recommended. - In other environments, make the recommendation explicit in the prompt or option label. 6. **Use the platform's question tool when available** - Prefer the blocking question tool for the current platform: - Codex: `request_user_input` - Claude Code: `AskUserQuestion` - Gemini: `ask_user` - If no blocking question tool exists, present numbered options in chat and wait for the user's reply before proceeding. ## Output Guidance - Keep outputs concise. - Prefer short sections and brief bullets. - Only add as much detail as the next decision actually needs. ## Workflow ### Phase 0: Assess and Orient Figure out whether context matters and how much structure the conversation actually needs before you start pushing it. 1. **Decide whether repo context matters** - If the topic is abstract, exploratory, or product-only, skip repo scanning entirely. - If the topic is clearly tied to the current project, do a shallow context scan before substantive questions. 2. **When scanning, keep it light** - Search for the topic, related features, or obvious adjacent docs or code. - Skim only enough to avoid asking questions the repo can already answer. - Do not drift into deep implementation analysis. 3. **Check whether the user actually needs a more formal flow instead** - If the user is already converging on a real project, asking for durable requirements, or clearly wants something that could hand off to planning, note that a more formal requirements flow may be the better fit. - Do not force the switch. Keep ideating unless the user wants the more formal flow. ### Phase 1: Explore the Idea Clarify the thinking, challenge weak framing, and surface better directions while the conversation is still exploratory. 1. **Pressure-test the request** - Ask whether this is the real problem or a proxy for one. - Ask what outcome actually matters. - Ask what happens if nothing changes. - Ask whether there is a simpler framing or adjacent move that would be more useful. - Use this to sharpen the conversation, not to bulldoze the user's intent. 2. **Run the collaborative dialogue** - Ask one question at a time. - Start broad when needed: problem, users, value, constraints. - Narrow later: preferences, exclusions, edge cases, tradeoffs. - Surface alternatives, reframes, and tradeoffs whenever they help clarify the direction. - When the idea genuinely has multiple serious directions, pause the normal question flow and compare those directions directly before continuing. - If the user changes an earlier answer, acknowledge the change explicitly and treat it as valid. - If that change alters the logic of the next question, say that and ask a different next question; otherwise say that it does not change the flow and ask the same next question again. - Stop asking questions once the idea is clear enough to summarize confidently, or once the user explicitly wants to move on. 3. **Compare approaches** - Do this when the idea genuinely has multiple serious directions and the user would benefit from seeing them compared side by side. - Do not manufacture options just to look thoughtful. - Present 2-3 concrete directions. - Lead with your recommendation and explain why. - When useful, include one higher-upside challenger option that could materially increase usefulness or reveal a better framing without disproportionate carrying cost. - For each option, keep it short and cover: - what it is - why it is attractive - what tradeoff or risk comes with it - when it is the right fit ### Phase 2: Shared Understanding Summary Make the current understanding explicit so the user can confirm, correct, or sharpen it before choosing what happens next. - Once the conversation is clear enough, explicitly switch from questions to summarizing the current understanding. - Present the summary in sections of about `200-300 words` each rather than one long dump. - Use sections such as: - the problem or opportunity being explored - the most promising direction or directions - notable constraints, tradeoffs, or open questions - what seems worth doing next, if anything - After each section, ask whether it matches the user's understanding before moving to the next section. - If the user corrects a section, acknowledge the correction explicitly and, when useful, briefly restate the updated understanding so the shared understanding is visible. - Do not reply with a lazy "got it" and move on unless the correction is truly minor. - Incorporate each correction into the remaining summary. - Once all summary sections are confirmed, move on to next-step options. ### Phase 3: Next Steps Give the user a clean choice between continuing exploration, formalizing the idea, starting implementation, or stopping without forcing an artifact. 1. **Offer lightweight next-step options** - Prefer the platform's blocking question tool when available. - Ask: "What would you like to do next?" - Present only the options that actually apply: - `Keep exploring (Recommended)` - continue the conversation and probe further - `Turn this into bt:btrainstorm` - move into the more formal requirements-doc flow - `Move toward implementation` - stop exploring and start doing the job directly in the current session - `Done for now` 2. **Handle the selected option** - If the user selects `Keep exploring (Recommended)`, return to Phase 1 and continue with one question at a time. - If the user selects `Turn this into bt:btrainstorm`, immediately run `bt:btrainstorm` in the current session using the clarified ideation summary as context. Do not write a file first. - If the user selects `Move toward implementation`, start working directly in the current session using the finalized ideation summary as context. Do not force a handoff to another skill first. - If the user selects `Done for now`, end cleanly with the confirmed in-chat summary.