brainstorming

Ramblurr's avatarfrom Ramblurr

IMMEDIATELY USE THIS SKILL when creating or develop anything and before writing code or implementation plans - refines rough ideas into fully-formed designs through structured Socratic questioning, alternative exploration, and incremental validation

⭐0stars🔀1forks📁View on GitHub🕐Updated Jan 4, 2026⬇️2downloads
[Architecture Design]

When & Why to Use This Skill

This Claude skill facilitates the transition from abstract concepts to concrete technical designs through a structured Socratic process. It helps developers and architects explore multiple approaches, evaluate trade-offs, and validate designs incrementally before any code is written, ensuring a robust and well-thought-out foundation for software implementation.

Use Cases

  • Case 1: Refining a vague feature request or product idea into a detailed technical architecture with defined components and data flows.
  • Case 2: Conducting a comparative analysis of different architectural patterns (e.g., microservices vs. monolith) to determine the best fit for project constraints.
  • Case 3: Validating complex system designs incrementally with a human partner to identify potential edge cases and error handling requirements early in the lifecycle.
  • Case 4: Bridging the gap between high-level ideation and low-level implementation planning by creating a structured design document as a handoff point.
nameBrainstorming
descriptionIMMEDIATELY USE THIS SKILL when creating or develop anything and before writing code or implementation plans - refines rough ideas into fully-formed designs through structured Socratic questioning, alternative exploration, and incremental validation

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: Planning Handoff

Note the response for later

Ask: "Ready to create the implementation plan?"

When your human partner confirms (any affirmative response):

  • Invoke Planning Document to learn about our document structure
  • Announce: "I'm using the Writing Plans skill to create the implementation plan."
  • Invoke Writing Plans skill
  • Create detailed Planning Document and place it under prompts/NNN-concept_plan.md

Phase 5: Worktree Setup (for implementation)

When design is approved and implementation will follow:

Ask: "Should I create the worktree for implementation?"

When your human partner confirms (any affirmative response):

  • Announce: "I'm using the Using Git Worktrees skill to set up an isolated workspace."
  • Switch to Using Git Worktree skill
  • Follow that skill's process for directory selection, safety verification, and setup
  • Return here when worktree ready

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.

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