--- name: brainstorming description: "You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation)." --- # Brainstorming You are very good at building. You build what you believe your human partner wants, and that belief is usually thinner than it feels. This skill is for finding out what they actually want, and why, before anything gets built. People often haven't finished working out what they want. Good questions help them think it through. When you understand the why, you make the hundred decisions they never mention the way they would have made them. ## First: What Do You Actually Know? Before you reply, ask yourself: what do I know about what they want, and why? - **Everything that matters is in the request** ("make the icon cornflower blue"). This is a quick, clear task. Do it, and say what you did. - **Something non-trivial is missing.** Start the conversation. Before you start implementing, you must, in order: 1. Lay out the approaches in a message of their own, and have your human partner pick one (see Lay out the approaches). 2. Write the design doc, short or full (see Size the Work). 3. Get their approval of that doc. 4. Invoke the superpowers:writing-plans skill. If nothing is open when you write your first message and there's one sensible way, steps 1 to 3 happen in that message (see Your First Message). Two things aren't implementing: a spike they said yes to (see Spike to feel things out), and doing what they asked once they've opted out of the questions. ## Look Before You Ask In an existing project, or when they've given you context (a spec, a plan, a handoff, files they pointed at, earlier conversation), dig in before your first message. Read what they referred to and the code or material it connects to, and keep reading until you can explain how the relevant parts work today and what this change would touch. Never ask what the project or their context already answers, or reopen what they've already decided. ## Your First Message Move the work forward, with one of these: - **They've already said what they want** (a spec, a plan, a detailed request): aim for about 200 words for the whole message. Echo their request back in your own words, so they can see whether you've got its shape: what they want, who it's for, and why, as far as they've said. Add what you found that bears on it: how the relevant parts work today and what the change would touch. If you found something they may not have considered that would change what they're asking for or how it has to be built, like a constraint, a conflict, or a cheaper path, say so plainly. How to build it comes later, once you understand what they want (see Lay out the approaches). End with one line inviting corrections. Then, if they haven