brainstorming

What this skill does

# Brainstorming

Technical design collaboration through natural dialogue. Adapts to expertise level and problem complexity through understanding, exploration, and validation stages.

## Skill Methodology

Natural collaborative dialogue for technical design through understanding, exploration, and validation. Extends DEVELOPER and ENGINEER profiles with adaptive guidance for architectural decisions.

> [!IMPORTANT]
> The skill embodies Understand → Explore → Validate → Design
>
> - Process skill instructions systematically
> - Take time to read, understand, and apply each section's logic carefully
> - Rushing past documented procedures causes **fatal** execution errors

### Natural Design Flow

Design conversations naturally progress through these stages:

1. **Understanding** - Clarify what you're building through focused questions
2. **Exploration** - Consider alternative approaches and trade-offs together
3. **Validation** - Present design in sections, checking alignment as you go

These stages guide the conversation but aren't rigid phases. Real design work is iterative and messy - be ready to circle back and clarify when something doesn't make sense.

> [!IMPORTANT]
> Design quality emerges through dialogue and incremental validation, not procedural compliance.

## Understanding Stage

Start by understanding what you're building and why.

### Establishing Context

Check the current project state first:

- Review existing patterns and conventions
- Identify architectural constraints and requirements
- Note related technical decisions and their rationale
- Understand success criteria and validation approach

### Clarifying Through Questions

Ask one focused question at a time, adapting style to context.

#### Collaborating with Technical Experts

- Ask focused technical questions
- Challenge assumptions and explore trade-offs
- Engage as peers in technical dialogue
- Use open-ended questions to explore nuanced territory

#### Limited Technical Background

- Provide context before questions
- Explain features and implications
- Make options concrete through multiple choice
- Guide exploration while maintaining collaboration

#### Example Questions

- What specific problem needs solving?
- What technical constraints exist?
- What defines successful implementation?
- What are the primary integration points?

### What Understanding Looks Like

You'll know you understand when:

- Problem definition is clear and validated
- Technical constraints are explicit
- Success criteria are established
- Integration points are identified

## Exploration Stage

Once you understand what you're building, explore how to build it.

### Generating Alternatives

Develop 2-3 distinct technical approaches together:

- Analyze complexity vs maintainability trade-offs
- Evaluate alignment with existing architecture
- Consider operational implications
- Assess implementation effort and risk

### Presenting Recommendations

Share your recommended approach conversationally:

- Lead with your recommendation and technical reasoning
- Explain why alternatives were considered and rejected
- Highlight specific trade-offs relevant to this context
- Stay receptive to alternative perspectives

### Applying YAGNI Ruthlessly

Challenge complexity at every turn:

- Remove features not immediately necessary
- Defer optimization until measurement validates need
- Question assumptions about future requirements
- Keep the simplest solution that works

### What Exploration Achieves

Good exploration produces:

- 2-3 alternative approaches with trade-offs analyzed
- Recommended approach with clear technical justification
- Complexity either justified or removed
- Shared understanding of why this approach fits

## Validation Stage

Present the design incrementally, validating as you go.

### Presenting Design Sections

Break the design into focused sections (200-300 words):

- Architecture overview and system relationships
- System structure and state management approach
- Integration contracts and interaction points
- Error handling and edge case strategy
- Testing approach and validation criteria

#### Design Documentation Level

Present design at the architectural level:

- Describe components, relationships, and decisions in prose
- Focus on design rationale and trade-offs
- Document architectural patterns and approaches
- Avoid implementation code or configuration examples during design sessions
- Reserve detailed implementation for subsequent implementation sessions

### Validating Progressively

After each section, check alignment:

- "Does this approach address the requirements?"
- "Should we adjust anything before continuing?"
- Clarify misunderstandings immediately
- Adjust direction based on feedback

### Refining Through Dialogue

As the design takes shape:

- Discuss elements as they're confirmed
- Explain alternatives considered and rejection rationale
- Clarify assumptions needing validation during implementation
- Identify areas requiring further technical investigation

### What Validation Delivers

Validated designs include:

- Architecture design confirmed
- System structure agreed upon
- Integration contracts defined
- Error handling strategy established
- Testing approach determined

## Adaptive Collaboration

Adapt your approach based on expertise level and problem complexity.

### Expertise Level Adaptation

Match your collaboration style to the user's technical background.

#### Technical Experts

- Dive deep into architectural trade-offs
- Challenge technical decisions directly
- Explore edge cases and failure modes
- Match technical depth and rigor

#### Limited Technical Background

- Provide educational context
- Explain implications of choices
- Use concrete examples and analogies
- Build understanding incrementally

#### In All Cases

- Maintain natural conversation flow
- Ask one question at a time
- Be ready to shift modes based on signals
- Trust the collaborative process

### Complexity Management

Scale your approach to match problem size.

#### Small Focused Problems

- Understanding and exploration can flow together naturally
- Present consolidated design sections when appropriate
- Maintain flexibility while staying systematic

#### Large Complex Challenges

- Take time with each stage
- Validate understanding before exploring approaches
- Present design in smaller sections
- Manage cognitive load through pacing

## Design Principles

These principles guide all design collaboration:

- **Systematic questioning** - One question at a time maintains focus and prevents overwhelm
- **Multiple alternatives** - Never commit to the first idea; exploring options prevents premature optimization
- **Incremental validation** - Checking alignment early catches misalignment before it compounds
- **Ruthless simplicity** - Challenge every layer of complexity; remove what isn't immediately necessary
- **Progressive dialogue** - Build understanding iteratively; go back when something doesn't make sense
- **Natural flow** - Let the conversation emerge; adapt to context rather than forcing structure

## Quality Standards

Strong designs demonstrate both completeness and simplicity.

### Completeness

- Problem definition and technical constraints clear
- Implementation approach with system structure defined
- Integration points and contracts specified
- Error handling and failure modes addressed
- Testing strategy and success criteria established

### Simplicity

- Every complexity layer has clear justification
- No speculative features for imagined future needs
- Clear path from current state to validated design
- Implementation can proceed without additional architectural decisions

## Session Completion

The validated design serves as implementation reference. Expect refinement as edge cases emerge during actual implementation - that's normal and healthy.

> [!IMPORTANT]
> If user requests a conversation log to document this brainstorming session, the `conversation-log` sk