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 at start: "I'm using the brainstorming skill to refine your idea into a design."

Quick Reference

The Process

Copy this checklist to track progress:

Brainstorming Progress:
- [ ] Phase 1: Understanding (purpose, constraints, criteria gathered)
- [ ] Phase 2: Exploration (2-3 approaches proposed and evaluated)
- [ ] Phase 3: Design Presentation (design validated in sections)
- [ ] Phase 4: Design Documentation (design written to docs/plans/)
- [ ] Phase 5: Worktree Setup (if implementing)
- [ ] Phase 6: Planning Handoff (if implementing)

Phase 1: Understanding

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

Example using AskUserQuestion:

Question: "Where should the authentication data be stored?"
Options:
  - "Session storage" (clears on tab close, more secure)
  - "Local storage" (persists across sessions, more convenient)
  - "Cookies" (works with SSR, compatible with older approach)

Phase 2: Exploration

• •Propose 2-3 different approaches
• •For each: Core architecture, trade-offs, complexity assessment
• •Use AskUserQuestion tool to present approaches as structured choices
• •Ask your human partner which approach resonates

Example using AskUserQuestion:

Question: "Which architectural approach should we use?"
Options:
  - "Event-driven with message queue" (scalable, complex setup, eventual consistency)
  - "Direct API calls with retry logic" (simple, synchronous, easier to debug)
  - "Hybrid with background jobs" (balanced, moderate complexity, best of both)

Phase 3: Design Presentation

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

Phase 4: Design Documentation

After design is validated, write it to a permanent document:

• •File location: docs/plans/YYYY-MM-DD-<topic>-design.md (use actual date and descriptive topic)
• •RECOMMENDED SUB-SKILL: Use zenpowers:writing-clearly-and-concisely (if available) for documentation quality
• •Content: Capture the design as discussed and validated in Phase 3, organized into the sections that emerged from the conversation
• •Commit the design document to git before proceeding

Phase 5: Worktree Setup (for implementation)

When design is approved and implementation will follow:

• •Announce: "I'm using the using-git-worktrees skill to set up an isolated workspace."
• •REQUIRED SUB-SKILL: Use zenpowers:using-git-worktrees
• •Follow that skill's process for directory selection, safety verification, and setup
• •Return here when worktree ready

Phase 6: Planning Handoff

Ask: "Ready to create the implementation plan?"

When your human partner confirms (any affirmative response):

• •Announce: "I'm using the writing-plans skill to create the implementation plan."
• •REQUIRED SUB-SKILL: Use zenpowers:writing-plans
• •Create detailed plan in the worktree

Question Patterns

When to Use AskUserQuestion Tool

Use AskUserQuestion 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 for partner
• •Forces explicit choice (prevents vague "maybe both" responses)

When to Use Open-Ended Questions

Use open-ended questions for:

• •Phase 3: Design validation ("Does this look right so far?")
• •When you need detailed feedback or explanation
• •When partner should describe their own requirements
• •When structured options would limit creative input

Example decision flow:

• •"What authentication method?" → Use AskUserQuestion (2-4 options)
• •"Does this design handle your use case?" → Open-ended (validation)

When to Revisit Earlier Phases

digraph revisit_phases {
    rankdir=LR;
    "New constraint revealed?" [shape=diamond];
    "Partner questions approach?" [shape=diamond];
    "Requirements unclear?" [shape=diamond];
    "Return to Phase 1" [shape=box, style=filled, fillcolor="#ffcccc"];
    "Return to Phase 2" [shape=box, style=filled, fillcolor="#ffffcc"];
    "Continue forward" [shape=box, style=filled, fillcolor="#ccffcc"];

    "New constraint revealed?" -> "Return to Phase 1" [label="yes"];
    "New constraint revealed?" -> "Partner questions approach?" [label="no"];
    "Partner questions approach?" -> "Return to Phase 2" [label="yes"];
    "Partner questions approach?" -> "Requirements unclear?" [label="no"];
    "Requirements unclear?" -> "Return to Phase 1" [label="yes"];
    "Requirements unclear?" -> "Continue forward" [label="no"];
}

You can and should go backward when:

• •Partner reveals new constraint during Phase 2 or 3 → Return to Phase 1
• •Validation shows fundamental gap in requirements → Return to Phase 1
• •Partner questions approach during Phase 3 → Return to Phase 2
• •Something doesn't make sense → Go back and clarify

Don't force forward linearly when going backward would give better results.

Key Principles