Brainstorming Ideas Into Designs

Overview

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.

Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.

When to Activate

Activate this skill when:

• User has a rough idea that needs refinement

• User is uncertain about scope or approach

• User says "I'm not sure what we need" or "I'm not sure how to approach this"

• During Phase 2 (Requirements) to explore WHAT to build

• During Phase 3 (Technical Design) to explore HOW to build it

Phase 2 Focus (Requirements):

• Clarifying what the feature should do

• Exploring different requirement scopes

• Understanding user needs and constraints

• Determining must-haves vs. nice-to-haves

Phase 3 Focus (Design):

• Exploring architectural approaches

• Comparing technical solutions

• Analyzing implementation trade-offs

Research-Driven Exploration

When exploring unclear requirements or designs, use web research to inform decisions:

For Requirements Exploration:

• Use WebSearch to find how others have solved similar problems

• Use WebFetch to analyze competitor features and documentation

• Research user expectations and industry standards

For Design Exploration:

• Use WebSearch to find architectural patterns and best practices

• Use WebFetch to read library/framework documentation

• Research performance benchmarks and case studies

For API Integration:

• Use Bash with curl to explore and test API endpoints

• Fetch API schemas and documentation

• Understand rate limits, authentication, and constraints

Research Questions to Answer:

• "How do similar products handle this?"

• "What are common pitfalls to avoid?"

• "What's the current best practice (2025)?"

• "Are there established patterns for this problem?"

🗣 Say: "Let me research this before proposing options. I'll look for prior art and best practices."

Document Research:

• Share key findings with user before presenting options

• Include sources for transparency

• Note any conflicting approaches found

The Process

Understanding the idea:

• Check out the current project state first (files, docs, recent commits)

• Ask questions one at a time to refine the idea

• Prefer multiple choice questions when possible, but open-ended is fine too

• Only one question per message - if a topic needs more exploration, break it into multiple questions

• Focus on understanding: purpose, constraints, success criteria

When to UltraThink: Before proposing architectural approaches, activate deep thinking if:

• Multiple valid solutions exist with significant trade-offs

• Decision has long-term architectural implications

• Requirements involve complex system interactions

• Security or performance are critical concerns

🗣 Say: "Let me ultrathink this before proposing approaches. I'll question fundamentals and consider implications from first principles."

During UltraThink:

• Question assumptions about requirements

• Consider second-order effects of each approach

• Think about what could go wrong (pre-mortem)

• Evaluate against similar systems you've seen

• Consider future maintainability and evolution

After UltraThink: Provide approaches with clear reasoning about trade-offs and long-term implications.

Exploring approaches:

• Propose 2-3 different approaches with trade-offs

• Present options conversationally with your recommendation and reasoning

• Lead with your recommended option and explain why

• Consider:

• Complexity (Low/Medium/High)

• Maintainability

• Performance implications

• Security considerations

• Testability

Presenting the design:

• Once you believe you understand what you're building, present the design

• Break it into sections of 200-300 words

• Ask after each section whether it looks right so far

• Cover: architecture, components, data flow, error handling, testing

• Be ready to go back and clarify if something doesn't make sense

After Brainstorming

For Requirements (Phase 2):

• Write validated requirements to docx/features/[NN-feature-name]/requirements.md

• Use EARS format (Event-Driven, State-Driven, Ubiquitous, Conditional, Optional)

• Include:

• Overview

• Functional requirements

• Non-functional requirements (performance, security, usability)

• Constraints

• Acceptance criteria

• Out of scope items

• Ask: "Requirements complete. Ready for design phase?"

For Design (Phase 3):

• Write the validated design to docx/features/[NN-feature-name]/design.md

• Include:

• Architecture Overview

• Component Structure

• Data Flow

• API Contracts

• Error Handling Strategy

• Security Considerations

• Performance Considerations

• Testing Strategy

• Ask: "Design complete. Ready for task breakdown?"

Transition:

• After requirements → Proceed to Phase 3 (Technical Design)

• After design → Transition to spec-driven-implementation skill for task breakdown

Key Principles

• One question at a time - Don't overwhelm with multiple questions

• Multiple choice preferred - Easier to answer than open-ended when possible

• YAGNI ruthlessly - Remove unnecessary features from all designs

• Explore alternatives - Always propose 2-3 approaches before settling

• Incremental validation - Present design in sections, validate each

• Be flexible - Go back and clarify when something doesn't make sense

• Think about testing - Good designs are testable designs

• Consider security - Build security in, don't bolt it on later

Example Questioning Flow

Understanding Purpose:

Q: "What's the primary goal of this authentication feature?" → User answers

Q: "Should it support multiple auth methods (email/password, OAuth, etc.) or just one method initially?" → User answers

Q: "What happens when a session expires - force re-login or offer refresh?" → User answers

Exploring Approaches:

Based on your requirements, I see 3 main approaches:

Option A: JWT-Based Authentication [RECOMMENDED] Pros: Stateless, scalable, works across services, standard Cons: Token invalidation complexity, larger payload Complexity: Medium Best for: Microservices, APIs, future scalability

Option B: Session-Based Authentication Pros: Simple invalidation, smaller cookies, familiar Cons: Requires session storage, scaling challenges Complexity: Low Best for: Monolithic apps, simple use cases

Option C: Hybrid Approach Pros: Combines benefits of both Cons: More complex, harder to maintain Complexity: High Best for: Complex enterprise requirements

I recommend Option A (JWT) because your requirements mention potential API integrations and future mobile app support. JWT is industry-standard for this use case.

Does this align with your thinking?

Presenting Design Incrementally:

Let me present the architecture in sections:

Section 1: High-Level Flow [200-300 words describing auth flow]

Does this look right so far? → User validates or requests changes

Section 2: Component Structure [200-300 words describing components]

How does this look? → Continue...

Integration with Spec-Driven Workflow

This skill can be used in two phases:

Phase 2 (Requirements):

• Use when user has rough idea but unclear requirements

• Helps clarify what to build vs. what's out of scope

• Explores different feature scopes and priorities

• Outputs to requirements.md in EARS format

Phase 3 (Technical Design):

• Use after requirements are defined

• Helps explore how to build the feature

• Compares architectural approaches with trade-offs

• Outputs to design.md with complete technical specs

After brainstorming completes:

• Phase 2 → Proceed to Phase 3 (Technical Design)

• Phase 3 → Transition to spec-driven-implementation for task breakdown

Notes

• Phase 2: Focus on "what" (what should system do? what's in/out of scope?)

• Phase 3: Focus on "how" (how should we build it? what are trade-offs?)

• Always present multiple options before recommending

• Validate incrementally - don't dump everything at once

• Be ready to backtrack if something doesn't make sense

• One question at a time - let user think and respond

• Good requirements lead to good designs

• Good designs enable good tests - think about testability

• Security and error handling are not afterthoughts