brainstorming_skill

Overview

This skill guides focused brainstorming before implementing features, building components, or making changes. It helps clarify user intent, surface constraints and success criteria, and explore alternative approaches so planning and implementation start from a shared WHAT, not premature HOW. Use it when requests are ambiguous or multiple valid interpretations exist.

How this skill works

The skill first assesses whether brainstorming is needed by checking signals of clarity or ambiguity in the request. It then asks targeted questions one at a time to understand purpose, users, constraints, success metrics, and edge cases. After understanding the idea it proposes 2–3 concrete approaches with pros/cons and a recommended option, then captures key decisions in a short design summary and offers clear handoff choices (plan, refine, or pause). It enforces YAGNI and incremental validation throughout.

When to use it

• Requirements are vague or use vague language ("make it better", "add something like")
• A request has multiple reasonable interpretations or trade-offs to consider
• You don’t yet know success criteria or target users
• You want to compare a few distinct implementation approaches before planning
• The feature scope needs refinement before writing tasks

Best practices

• Ask one question at a time and prefer multiple-choice prompts when natural
• Start broad (purpose), then narrow (users, constraints, success metrics, edge cases)
• Propose 2–3 concrete approaches and lead with a recommendation and rationale
• Keep outputs concise (200–300 words per section) and validate with the user frequently
• Apply YAGNI: prefer simple, proven patterns over speculative complexity

Example use cases

• User says "help me think through notifications" — clarify audience, channels, and success metrics
• Ambiguous feature request like "improve onboarding" — explore goals, constraints, and measurable outcomes
• Choice between server-side or client-side rendering — list approaches with pros/cons and recommended trade-offs
• New component design where existing patterns may apply — identify reuse vs new implementation
• Feature spikes where multiple engineering trade-offs exist and a lightweight design doc is needed