Brainstorming Ideas Into Designs

Overview

Transform rough ideas into fully-formed designs through structured questioning and alternative exploration.

Core principle: Ask questions to understand, explore alternatives, present design incrementally for validation.

Announce skill usage at start of session.

When to Use This Skill

Activate this skill when:

• •Request contains "I have an idea for..." or "I want to build..."
• •User asks "help me design..." or "what's the best approach for..."
• •Requirements are vague or high-level
• •Multiple approaches might work
• •Before writing any code or implementation plans
• •User needs to explore trade-offs between different solutions

When NOT to Use This Skill

Skip brainstorming when:

• •Requirements are crystal clear and specific
• •Only one obvious approach exists
• •User has already designed the solution (just needs implementation)
• •Time-sensitive bug fix or urgent production issue
• •User explicitly says "just implement it" without questions

Examples of clear requirements (no brainstorming needed):

• •"Add a print button to this page"
• •"Fix this TypeError on line 42"
• •"Update the copyright year to 2025"
• •"Change the button color to #FF5733"

The Three-Phase Process

Phase 1: Understanding

Goal: Gather purpose, constraints, and success criteria.

Process:

• •Check current project state in working directory
• •Ask ONE question at a time to refine the idea
• •Use AskUserQuestion tool when presenting multiple choice options
• •Gather: Purpose, constraints, success criteria

Tool Usage: Use AskUserQuestion for clarifying questions with 2-4 clear options.

Example: "Where should the authentication data be stored?" with options for Session storage, Local storage, Cookies, each with trade-off descriptions.

See references/example-session-auth.md for complete Phase 1 example.

Phase 2: Exploration

Goal: Propose 2-3 different architectural approaches with explicit trade-offs.

Process:

• •Propose 2-3 different approaches
• •For each: Core architecture, trade-offs, complexity assessment
• •Use AskUserQuestion tool to present approaches as structured choices
• •Include trade-off comparison table when helpful

Trade-off Format:

See references/example-session-dashboard.md for complete Phase 2 example with SSE vs WebSockets vs Polling comparison.

Phase 3: Design Presentation

Goal: Present complete design incrementally, validating each section.

Process:

• •Present in 200-300 word sections
• •Cover: Architecture, components, data flow, error handling, testing
• •Ask after each section: "Does this look right so far?"
• •Use open-ended questions to allow freeform feedback

Typical Sections:

1. •Architecture overview
2. •Component details
3. •Data flow
4. •Error handling
5. •Security considerations
6. •Implementation priorities

Validation Pattern: After each section, pause for feedback before proceeding to next section.

Tool Usage Guidelines

Use AskUserQuestion Tool For:

• •Phase 1: Clarifying questions with 2-4 clear options
• •Phase 2: Architectural approach selection (2-3 alternatives)
• •Any decision with distinct, mutually exclusive choices
• •When options have clear trade-offs to explain

Benefits:

• •Structured presentation of options with descriptions
• •Clear trade-off visibility
• •Forces explicit choice (prevents vague "maybe both" responses)

Use Open-Ended Questions For:

• •Phase 3: Design validation
• •When detailed feedback or explanation is needed
• •When the user should describe their own requirements
• •When structured options would limit creative input

Non-Linear Progression

Flexibility is key. Go backward when needed - don't force linear progression.

Return to Phase 1 when:

• •User reveals new constraint during Phase 2 or 3
• •Validation shows fundamental gap in requirements
• •Something doesn't make sense

Return to Phase 2 when:

• •User questions the chosen approach during Phase 3
• •New information suggests a different approach would be better

Continue forward when:

• •All requirements are clear
• •Chosen approach is validated
• •No new constraints emerge

Key Principles

After Brainstorming Completes

Consider these optional next steps:

• •Document the design in project's design documentation
• •Break down the design into actionable implementation tasks
• •Create a git branch or workspace for isolated development

Use templates in assets/design-doc-template.md and assets/decision-matrix-template.md for structured documentation.

Socratic Questioning Templates

Purpose Discovery Questions

Goal: Understand the "why" behind the feature.

• •"What problem does this solve for your users?"
• •"What happens if we don't build this?"
• •"How will success be measured?"
• •"Who is the primary user of this feature?"
• •"What's the most important outcome?"

Constraint Identification Questions

Goal: Uncover limitations and requirements.

• •"Are there performance requirements? (e.g., must load in < 2s)"
• •"What's the expected scale? (users, data volume, requests/sec)"
• •"Are there compliance requirements? (GDPR, HIPAA, SOC2)"
• •"What's the timeline/budget constraint?"
• •"What existing systems must this integrate with?"

Trade-Off Exploration Questions

Goal: Make implicit preferences explicit.

• •"Would you prefer faster development or better performance?"
• •"Is flexibility more important than simplicity?"
• •"Should this be user-friendly or developer-friendly?"
• •"Optimize for: initial build speed, maintainability, or scalability?"
• •"What's more critical: feature completeness or time-to-market?"

Alternative Exploration Questions

Goal: Ensure we consider all viable approaches.

• •"What if we didn't build this at all? What's the workaround?"
• •"How would [competitor/similar product] solve this?"
• •"Could we start with a simpler version? What's the MVP?"
• •"What if we had unlimited time/budget? What would we add?"
• •"What approaches have you already considered and rejected? Why?"

Common Pitfalls to Avoid

Pitfall 1: Asking Too Many Questions Upfront

❌ BAD:
"Before we start, I need to know:
1. What's your tech stack?
2. How many users?
3. What's the budget?
4. What's the timeline?
5. Who's the target audience?
..."

✅ GOOD:
"What problem does this solve for your users?"
[Wait for answer, then ask next most important question]

Why: Information overload prevents conversation flow. Ask one at a time.

Pitfall 2: Proposing Only One Approach

❌ BAD:
"Here's the solution: Use Redis for caching..."

✅ GOOD:
"I see three approaches:
1. Redis (fast, but adds infrastructure)
2. In-memory (simple, but doesn't scale)
3. Database query cache (integrated, but slower)
Which trade-offs matter most?"

Why: Single approach suggests you haven't explored alternatives.

Pitfall 3: Over-Engineering from the Start

❌ BAD:
"Let's use microservices, Kubernetes, Redis, Kafka,
message queues, and a service mesh..."

✅ GOOD:
"For 100 users/day, a monolith with PostgreSQL
is sufficient. We can split services later if needed."

Why: YAGNI (You Aren't Gonna Need It). Start simple, scale when necessary.

Pitfall 4: Ignoring Existing Code/Patterns

❌ BAD:
"Let's rebuild this with a completely different architecture..."

✅ GOOD:
[Read existing code first]
"I see you're using Express + PostgreSQL. Let's extend
that pattern with a new route handler..."

Why: Consistency > novelty. Use existing patterns unless there's a compelling reason to change.

Integration with Other Skills

After brainstorming completes, consider:

• •architecture-decision-record: Document key architectural decisions made during brainstorming
• •design-system-starter: Create design tokens and components if building UI
• •api-design-framework: Define API contracts if building backend services
• •testing-strategy-builder: Plan testing approach for the designed system
• •security-checklist: Review security implications of design choices

Example flow:

1. •Brainstorming → Design approach selected
2. •Architecture Decision Record → Document "Why we chose approach X"
3. •API Design → Define endpoints and contracts
4. •Testing Strategy → Plan how to test the implementation

Real-World Brainstorming Examples

Example 1: E-commerce Product Recommendation Engine

Phase 1 - Understanding:

• •Q: "What problem does this solve?" → A: "Users can't discover relevant products"
• •Q: "How many products in catalog?" → A: "50,000+ products"
• •Q: "What data do we have?" → A: "Purchase history, browsing history, ratings"

Phase 2 - Exploration:

• •Approach 1: Collaborative filtering (similar users, proven approach)
• •Approach 2: Content-based filtering (product attributes, simpler) ← CHOSEN
• •Approach 3: Hybrid ML model (best results, complex implementation)

Phase 3 - Design:

• •Vector embeddings for product descriptions
• •PostgreSQL with pgvector extension
• •Batch embedding generation nightly
• •API endpoint returning top 10 similar products

Result: Simple, fast recommendation system launched in 2 weeks

Example 2: Real-Time Analytics Dashboard

Phase 1 - Understanding:

• •Q: "What metrics need to be real-time?" → A: "Active users, revenue, errors"
• •Q: "How many concurrent viewers?" → A: "10-50 at peak"
• •Q: "Acceptable latency?" → A: "Updates within 5 seconds fine"

Phase 2 - Exploration:

• •Approach 1: Server-Sent Events (simple, unidirectional) ← CHOSEN
• •Approach 2: WebSockets (complex, bidirectional not needed)
• •Approach 3: Polling (wasteful, high server load)

Phase 3 - Design:

• •SSE endpoint streaming JSON updates every 3 seconds
• •Redis pub/sub for broadcasting to multiple viewers
• •Automatic reconnection with exponential backoff
• •Chart.js for real-time visualization

Result: Real-time dashboard without WebSocket complexity

Example 3: File Upload Service

Phase 1 - Understanding:

• •Q: "What file types?" → A: "Images, PDFs, videos"
• •Q: "Max file size?" → A: "100MB per file"
• •Q: "Expected volume?" → A: "1000 uploads/day"

Phase 2 - Exploration:

• •Approach 1: Direct upload to S3 (fast, S3 costs)
• •Approach 2: Server upload then S3 (slower, more control) ← CHOSEN
• •Approach 3: Cloudinary (expensive, fully managed)

Phase 3 - Design:

• •Multipart upload with progress tracking
• •Server-side virus scanning (ClamAV)
• •Image optimization and thumbnails (Sharp)
• •Store metadata in PostgreSQL, files in S3

Result: Secure upload service with virus scanning and optimization

Examples

Complete brainstorming sessions:

• •references/example-session-auth.md - Authentication storage design (JWT vs Session vs Cookies)
• •references/example-session-dashboard.md - Real-time dashboard design (SSE vs WebSockets vs Polling)

Output templates:

• •assets/design-doc-template.md - Structured design document format
• •assets/decision-matrix-template.md - Weighted decision comparison format

Tips for Effective Brainstorming

1. •Read the codebase first - Don't propose changes without understanding existing patterns
2. •One question at a time - Conversation flow > information dump
3. •Always propose 2-3 alternatives - Shows you've explored options
4. •Make trade-offs explicit - "Fast but complex" vs "Slow but simple"
5. •Validate incrementally - Don't present 10-page design at once
6. •Be ready to backtrack - Non-linear is fine when new info emerges
7. •Start simple, scale later - YAGNI ruthlessly
8. •Document decisions - Use ADRs for key architectural choices

Version: 1.1.0 (December 2025) Status: Production-ready patterns from real-world brainstorming sessions