Brainstorming Ideas Into Designs

Overview

Trigger Conditions

• User describes a new feature idea or goal
• User asks "how should we build X?"
• Creative work requires design exploration before planning

• /brainstorm

  command invoked
• Transition from a vague requirement to structured design is needed

Phase 1: Context Loading

1. Check memory files (

   project-context.md

   ,

   learned-patterns.md

   ,

   decisions-log.md

   ) for known patterns, stack, and conventions
2. Read relevant existing code, docs, and recent commits
3. Review existing designs in

   docs/plans/

   for related prior work
4. Identify constraints from the existing architecture
5. Note what you already know — do NOT re-ask the user for information you can discover

Context Sources Priority

• Memory files have been checked
• Relevant codebase areas have been explored
• You can summarize what you already know about this domain

Phase 2: Idea Exploration

1. Ask ONE question per message — never multiple questions
2. Prefer multiple choice questions when possible
3. Focus on understanding purpose, constraints, and success criteria
4. Build on context loaded in Phase 1 — skip questions you can already answer
5. Convert vague answers into specific, testable criteria

Question Flow Decision Table

Question Rules

• You understand the core purpose and who it serves
• You know the constraints (technical, timeline, scope)
• You have identified success criteria and non-goals
• No critical ambiguities remain about intent

Phase 3: Approach Exploration

Approach Comparison Template

## Approach A: [Name] (Recommended)
**Summary:** [2-3 sentences]
**Pros:** [list]
**Cons:** [list]
**Complexity:** [Low/Medium/High]
**Risk:** [What could go wrong]
**Why recommended:** [1-2 sentences]

## Approach B: [Name]
...

## Approach C: [Name] (if needed)
...

• You have proposed at least 2 approaches
• Each approach has explicit trade-offs
• You have made a clear recommendation
• User has indicated which approach to pursue

Phase 4: Design Presentation

1. Present the design in logical sections scaled to complexity
2. Ask after each section whether it looks right so far
3. Be ready to go back and revise any section based on feedback
4. Cover all relevant design dimensions

Design Sections by Complexity

Section Presentation Order

1. Architecture — High-level structure and key decisions
2. Components — What pieces exist and how they relate
3. Data Flow — How data moves through the system
4. Error Handling — What can go wrong and how to handle it
5. Testing Strategy — How to verify correctness
6. Performance — Only if relevant constraints exist
7. Security — Only if handling sensitive data or auth

• All relevant design sections have been presented
• User has approved each section (or revisions were made)
• The complete design is coherent and addresses all requirements

Phase 5: Documentation and Transition

1. Write the validated design to

   docs/plans/YYYY-MM-DD-<topic>-design.md

2. Commit the design document
3. Update self-learning memory:

   • memory/decisions-log.md

     — any architectural decisions made

   • memory/learned-patterns.md

     — any new conventions discussed
4. Invoke the

   planning

   skill to create a detailed implementation plan

Design Document Template

# [Topic] Design Document

**Date:** YYYY-MM-DD
**Status:** Approved
**Approach:** [Which approach was chosen]

## Problem Statement
[What problem this solves and for whom]

## Design

### Architecture
[High-level structure]

### Components
[Key pieces and their relationships]

### Data Flow
[How data moves through the system]

### Error Handling
[What can go wrong and how it is handled]

## Decisions Made
- [Decision 1]: [Rationale]
- [Decision 2]: [Rationale]

## Non-Goals
- [What was explicitly excluded and why]

## Next Steps
Invoke planning skill to create implementation plan.

• Design document is saved to

  docs/plans/

• Memory files are updated with new decisions/patterns
• User has confirmed the design is complete

Anti-Patterns / Common Mistakes

Anti-Rationalization Guards

• "Let me just scaffold the project first..." — No. Design first.
• "The design is obvious..." — Then it will be quick to document. Do it.
• "The user seems impatient..." — Poor design wastes more time than brainstorming.

Integration Points

self-learning

planning

task-decomposition

spec-writing

verification-before-completion

Concrete Examples

Example: Simple Feature Brainstorm

User: "I want to add dark mode to the app"

Phase 1: [Check memory — React app, Tailwind CSS, no current theme system]
Phase 2: "Should dark mode (A) follow system preference automatically,
          (B) be a manual toggle only, or (C) both with manual override?"
Phase 3: Approach A: CSS variables + Tailwind dark: prefix
         Approach B: Theme context provider with CSS-in-JS
         Recommend A — aligns with existing Tailwind usage
Phase 4: Section 1: Architecture — Tailwind dark mode with class strategy
         Section 2: Components — ThemeToggle component, layout wrapper
Phase 5: Save design doc, invoke planning skill

Example: Transition to Planning

Design approved and saved to docs/plans/2026-03-15-dark-mode-design.md.
Updated memory/decisions-log.md with theme system decision.
Invoking planning skill to create implementation plan.

Key Principles

• One question at a time — Do not overwhelm
• Multiple choice preferred — Easier to answer
• YAGNI ruthlessly — Remove unnecessary features
• Explore alternatives — Always propose 2-3 approaches
• Incremental validation — Present and approve in sections
• Build on context — Use self-learning memory to avoid re-asking known things

Skill Type