brainstormlisted

# Brainstorm: Pre-Creation Design Exploration Explore the problem space, clarify requirements, and converge on a design direction **before** creating issues. This skill produces a **spec document** — capturing intent, trade-offs, the chosen approach, and enough detail for both issue creation (`/pm`) and implementation planning (`/cdt`). ## When to Use Use this skill when: - The work is ambiguous — user knows *what* they want but not *how* - Multiple valid approaches exist and trade-offs need discussion - Scope is unclear — could be one issue or an epic with sub-issues - The problem domain is unfamiliar and needs exploration first - A request is large enough that jumping straight to issue creation would produce a vague ticket Do NOT use for: - Clear, well-scoped bugs (go directly to `/pm`) - Simple chores or dependency updates - Work that already has a design document or spec ## Hard Gate <HARD-GATE> Do NOT invoke `/pm`, `/cdt`, create any GitHub issue, or take any implementation action until: 1. You have proposed approaches and the user has selected one 2. You have presented a spec document and the user has approved it This applies to EVERY brainstorming session regardless of perceived simplicity. A spec can be short (5-10 lines for a simple feature), but it must exist and be approved. </HARD-GATE> ### "This Is Too Simple To Need a Spec" No. Every brainstorming session produces a spec. The spec scales with complexity: - Simple feature: 5-10 lines covering approach, s