brainstorming

name	brainstorming
description	Structured brainstorming and design process. Enforces exploration and user approval before any implementation. Covers project context analysis, approach proposals, design documentation, and spec review.

Brainstorming Skill

A structured design process that prioritizes exploration and validation before implementation. Sourced from obra/superpowers.

Core Principle

Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it.

Brainstorming is complete only when the user explicitly approves the final design specification.

Process Flow

Follow these nine steps in order. Do not skip steps.

Step 1: Explore Project Context

• Review existing files, documentation, and recent commits
• Understand the codebase structure and conventions
• Identify relevant prior work and dependencies
• Note technical constraints and existing patterns

Step 2: Offer Visual Companion (If Needed)

• As a standalone message, offer to create mockups or diagrams
• Use visual content only when it adds clarity beyond text
• Keep this offer separate from clarifying questions

Step 3: Ask Clarifying Questions

• Ask one question at a time — never batch multiple questions
• Prefer multiple-choice framing when possible
• Focus on understanding:
  • Purpose and goals
  • Constraints and limitations
  • Success criteria
  • User expectations
• Continue until you have sufficient context to propose approaches

Step 4: Propose 2-3 Approaches

For each approach, present:

• Description — what the approach entails
• Trade-offs — pros and cons
• Complexity — relative effort and risk
• Recommendation — which approach you favor and why

Let the user choose or refine before proceeding.

Step 5: Present Design

Scale documentation to complexity:

• Simple projects — a few sentences covering the approach
• Medium projects — 100-200 words with key decisions
• Complex projects — 200-300 words covering architecture, interfaces, and data flow

Present design in sections and request approval after each section before continuing.

Step 6: Write Design Documentation

Save the approved design to a spec document. Include:

• Problem statement
• Chosen approach with rationale
• System design with component breakdown
• Key interfaces and data flow
• Assumptions and open questions
• Implementation sequence

Step 7: Spec Review Loop

• Review the spec for completeness, consistency, and feasibility
• Iterate up to 3 times to refine
• Each iteration should address specific concerns or gaps
• Stop iterating when the spec is solid or the limit is reached

Step 8: User Reviews Final Spec

• Present the complete spec for user approval
• Address any final concerns or modifications
• Do not proceed until explicit approval is received

Step 9: Transition to Implementation

• Only after approval, create an implementation plan
• Break work into ordered, independently testable tasks
• The only implementation-adjacent action allowed is creating a plan

Design Principles

Isolation and Clarity

Every component in the design should answer:

• What does it do? — single, clear purpose
• How is it used? — well-defined interface
• What does it depend on? — explicit dependencies
• Can it be tested independently? — verifiable in isolation

Working with Existing Codebases

• Explore current structure before proposing changes
• Follow existing patterns and conventions
• Address problems that affect the current work
• Avoid unrelated refactoring — note it for later if needed

Scoping Large Projects

• Break large projects into independently scoped sub-projects
• Each sub-project should be deliverable on its own
• Define clear boundaries and integration points between sub-projects

Question Strategy

Effective Questions

• "What problem are you trying to solve?" (open-ended for context)
• "Would you prefer A) server-side rendering or B) client-side rendering?" (multiple choice)
• "What does success look like for this feature?" (success criteria)
• "Are there any hard constraints on technology or timeline?" (constraints)

Questions to Avoid

• Compound questions that combine multiple topics
• Yes/no questions when you need nuanced answers
• Technical questions before understanding the problem
• Questions about implementation details during the exploration phase

Anti-Patterns

• Jumping to code — writing any implementation before design approval
• Batch questioning — asking multiple questions in one message
• Over-designing — creating detailed specs for simple tasks
• Under-exploring — proposing solutions before understanding the problem
• Scope creep — expanding beyond the agreed design during review

When to Use This Skill

• Starting a new feature or project
• Redesigning an existing system
• Tackling an ambiguous or complex problem
• When the right approach is not immediately obvious
• Before any significant architectural decision

---

Sourced from obra/superpowers (MIT License)