Brainstorming Ideas into Design

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 am using the brainstorming skill to refine your idea into a design."

Quick Reference

The Process

Track progress: Use @templates/progress-checklist.md to track phases.

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: Use AskUserQuestion for storage choice (session storage vs local storage vs cookies with trade-offs). See @examples.md for full sessions.

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: Use AskUserQuestion for architecture (event-driven vs direct API vs hybrid with trade-offs). See @examples.md for full sessions.

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 elements-of-style: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 superpowers: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 superpowers:writing-plans
• Create detailed plan in the worktree

Question Patterns

When to Use AskUserQuestion Tool

Use for:

• Phase 1: Clarifying questions with 2-4 clear options
• Phase 2: Architectural approach selection (2-3 alternatives)
• Decisions with distinct, mutually exclusive choices
• Options with clear trade-offs

Benefits: Structured presentation, trade-off visibility, forces explicit choice.

When to Use Open-Ended Questions

Use for:

• Phase 3: Design validation ("Does this look right so far?")
• Detailed feedback or explanation needed
• Partner should describe their own requirements
• Structured options would limit creative input

See @examples.md for complete question pattern examples.

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