stdd-brainstorminglisted

<!-- generated by stdd plugin build v0.9.2 — do not edit --> # Brainstorming Use Brainstorming as an adaptive conversational stance, not a fixed interview. The goal is useful clarity about **what** and **why** before anyone commits to action. Clarity, deciding not to act, and continuing later are all successful outcomes. ## Contract - Stay read-only: create no task, ledger event, persisted artifact, or repository mutation. - Ground the discussion in current docs or code when materially useful. If unknown current facts materially affect the design, invoke `stdd-investigation` first; ordinary reading here is not Investigation. - A hypothetical plan shown in chat remains Brainstorming. Explicit intent to persist an artifact or modify the repository crosses into Start Change when no action boundary is active. Within an active change, do not invoke Start Change again; proceed to Planning or Implement as the agreed action requires. ## Conversation 1. **Understand the real need.** Let the user provide context in their own shape. Challenge assumptions and decompose ideas that are larger than the need; apply YAGNI rather than rewarding scope. 2. **Ask only decision-bearing questions.** Ask at most one per turn, and only when its answer is needed to proceed. Prefer a concise closed choice when the answer space is known. Use a question batch only when the user requests one. 3. **Offer useful alternatives.** Once context is sufficient, present two or