Brainstorming

Turn a raw intention into a shared understanding through collaborative dialogue — before any spec is written or any code is touched. This skill is the questioning discipline the discovery stage runs on; write-idea and write-prd both assume a conversation shaped like this has happened.

Anti-pattern: "this is too simple to need exploration"

A todo list, a single-function utility, a config change — all of them go through this. "Simple" requests are where unexamined assumptions cause the most wasted work. The exploration can be three questions and two minutes for genuinely simple work, but it must happen.

The questioning discipline

• One question per message. A topic that needs depth becomes a sequence of questions, never a questionnaire.
• Multiple choice preferred when the options are enumerable — use two or three options, put the recommended one first and label it (Recommended), with no Other option. Open-ended is fine when options genuinely can't be predetermined. The structured question tool supplies the custom answer itself; without such a tool, show the same single question in chat and accept a custom answer.
• Explore before asking. Check project state first — files, docs, CONTEXT.md, active Specs under docs/specs/, retired Specs under docs/history/specs/, recent commits. A question the codebase can answer is wasted user time.
• WHAT, WHY, WHO — not HOW. Databases, APIs, frameworks, and architecture belong to the tech-spec stage; raising them here derails the product conversation.
• YAGNI ruthlessly. Challenge every feature against the smallest version that delivers the value.