brainstorm

# Brainstorm a Feature or Improvement Brainstorming answers **WHAT** to build through collaborative dialogue. It precedes the deeper technical planning that determines **HOW**. The durable output is a **requirements-only plan** under `docs/plans/`. Write it with `source: brainstorm` so planning does not invent product behavior, scope boundaries, or success criteria. This skill does not implement code. It explores, clarifies, and documents decisions for later planning or execution. ## Core Principles 1. **Assess scope first**. Match ceremony to the size and ambiguity of the work. 2. **Be a thinking partner**. Suggest alternatives, challenge assumptions, and explore what-ifs instead of only extracting requirements. 3. **Resolve product decisions here**. User-facing behavior, scope boundaries, and success criteria belong in this workflow. Detailed implementation belongs in planning. 4. **Keep implementation out by default**. Do not include libraries, schemas, endpoints, file layouts, or code-level design unless the brainstorm itself is inherently technical or architectural. 5. **Right-size the artifact**. Simple work gets a compact requirements-only plan or brief alignment. Larger work gets a fuller plan. Do not add ceremony that does not help planning. 6. **Apply YAGNI to carrying cost, not coding effort**. Prefer the simplest approach that delivers meaningful value. Avoid speculative complexity, but low-cost polish or delight is worth including when its ongoing cost is sm...