brainstorming-ideas-into-designs

bobmatnyc's avatarfrom bobmatnyc

Interactive idea refinement using Socratic method to develop fully-formed designs

⭐36stars🔀6forks📁View on GitHub🕐Updated Jan 3, 2026

When & Why to Use This Skill

This Claude skill facilitates interactive idea refinement using the Socratic method to transform vague concepts into robust, fully-formed technical designs. It ensures architectural clarity through structured questioning, multi-approach exploration, and incremental validation, preventing premature implementation and reducing technical debt.

Use Cases

  • Initial Project Scoping: Refining a high-level feature idea into a concrete technical specification through structured dialogue and requirement gathering.
  • Architectural Decision Making: Proposing and evaluating multiple technical approaches with detailed trade-offs and complexity assessments to find the optimal solution.
  • Requirement Clarification: Using the Socratic method to uncover hidden constraints, success criteria, and project goals before any code is written.
  • Design Validation: Presenting complex system architectures in digestible sections to ensure alignment between the user's vision and the proposed implementation plan.
nameBrainstorming Ideas Into Designs
descriptionInteractive idea refinement using Socratic method to develop fully-formed designs
when_to_usewhen partner describes any feature or project idea, before writing code or implementation plans
version2.2.0
level1
references[]
noteAlready optimal at 75 lines - intentionally compact, no references needed

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."

The Process

Phase 1: Understanding

  • Check current project state in working directory
  • Ask ONE question at a time to refine the idea
  • Prefer multiple choice when possible
  • Gather: Purpose, constraints, success criteria

Phase 2: Exploration

  • Propose 2-3 different approaches
  • For each: Core architecture, trade-offs, complexity assessment
  • Ask your human partner which approach resonates

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?"

Phase 4: 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."
  • Switch to skills/collaboration/using-git-worktrees
  • Follow that skill's process for directory selection, safety verification, and setup
  • Return here when worktree ready

Phase 5: 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."
  • Switch to skills/collaboration/writing-plans skill
  • Create detailed plan in the worktree

When to Revisit Earlier Phases

You can and should go backward when:

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

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

During exploration:

  • When approaches have genuine trade-offs: skills/architecture/preserving-productive-tensions

Before proposing changes to existing code:

  • Understand why it exists: skills/research/tracing-knowledge-lineages

Remember

  • One question per message during Phase 1
  • Apply YAGNI ruthlessly
  • Explore 2-3 alternatives before settling
  • Present incrementally, validate as you go
  • Go backward when needed - flexibility > rigid progression
  • Announce skill usage at start