Brainstorming

Clarify WHAT to build before HOW to build it.

Hard Gate

No implementation until the design is approved. Brainstorming produces a design document, not code. Do not invoke implementation skills, write production code, or create files outside docs/brainstorms/ until the user explicitly approves the design and moves to planning.

Core Process

Phase 0: Assess and Ground

Before diving into questions, do two things:

Ground in the codebase (when applicable). If the brainstorm relates to existing code, read the relevant modules, patterns, and constraints before generating options. This prevents suggesting approaches that conflict with the actual architecture. Skip for purely abstract brainstorms (tech choices, product direction) where no codebase context applies.

Right-size the artifact. Match ceremony to problem size. If the brainstorm resolves in 3 messages, don't force a formal design doc -- a summary comment is enough. If it spans multiple sessions and touches architecture, write the full Phase 3 doc. No ceremony tax.

Assess whether brainstorming is needed: