brainstorming

icartsh's avatarfrom icartsh

코드나 구현 계획을 작성하기 전, 무언가를 생성하거나 개발할 때 사용합니다. 협력적인 질문, 대안 탐색 및 점진적 검증을 통해 거친 아이디어를 구체화된 설계로 발전시킵니다. 명확한 'Mechanical' 프로세스 중에는 사용하지 마십시오.

⭐0stars🔀0forks📁View on GitHub🕐Updated Dec 21, 2025⬇️2downloads
[Architecture Design]

When & Why to Use This Skill

This Claude skill facilitates the transition from raw ideas to structured technical designs through a collaborative, iterative brainstorming process. It employs a 'one question at a time' approach to refine requirements, explores multiple architectural alternatives with trade-offs, and validates designs incrementally to ensure clarity and feasibility before implementation begins. By focusing on the 'why' and 'how' before the 'code', it prevents over-engineering and aligns development goals with project constraints.

Use Cases

  • Refining a vague software feature idea into a concrete technical specification with defined components and data flows.
  • Evaluating different architectural patterns for a new project by analyzing trade-offs, recommendations, and specific constraints.
  • Breaking down complex development tasks into manageable sections and documenting the design in Git-ready markdown files for team alignment.
  • Using guided questioning to identify potential edge cases, error handling strategies, and testing requirements during the early design phase.
namebrainstorming
description코드나 구현 계획을 작성하기 전, 무언가를 생성하거나 개발할 때 사용합니다. 협력적인 질문, 대안 탐색 및 점진적 검증을 통해 거친 아이디어를 구체화된 설계로 발전시킵니다. 명확한 'Mechanical' 프로세스 중에는 사용하지 마십시오.

아이디어를 설계로 브레인스토밍하기 (Brainstorming Ideas Into Designs)

Overview

자연스러운 협업 대화를 통해 아이디어를 구체화된 설계와 사양(Spec)으로 바꾸도록 돕습니다.

먼저 현재 프로젝트 context를 이해한 다음, 아이디어를 다듬기 위해 질문을 하나씩 던집니다. 무엇을 구축하려는지 이해했다면 설계를 작은 섹션(200-300자)으로 나누어 제시하고, 각 섹션이 끝날 때마다 지금까지의 내용이 맞는지 확인합니다.

The Process

아이디어 이해하기(Understanding the idea):

  • 먼저 현재 프로젝트 상태를 확인합니다(파일, 문서, 최근 커밋).
  • 아이디어를 다듬기 위해 질문을 한 번에 하나씩 합니다.
  • 가능한 경우 객관식 질문을 선호하지만, 주관식 질문도 괜찮습니다.
  • 메시지 당 하나의 질문만 합니다. 한 주제에 더 많은 탐색이 필요하면 여러 질문으로 나눕니다.
  • 이해에 집중합니다: 목적, 제약 조건, 성공 기준.

접근 방식 탐색하기(Exploring approaches):

  • 트레이드오프가 있는 2-3가지의 서로 다른 접근 방식을 제안합니다.
  • 권장 사항과 그 이유를 포함하여 대화 형식으로 옵션을 제시합니다.
  • 권장하는 옵션을 먼저 제시하고 그 이유를 설명합니다.

설계 제시하기(Presenting the design):

  • 무엇을 구축할지 이해했다고 판단되면 설계를 제시합니다.
  • 설계를 200-300자 정도의 섹션으로 나눕니다.
  • 각 섹션이 끝날 때마다 지금까지의 내용이 맞는지 확인합니다.
  • 내용: 아키텍처, 컴포넌트, 데이터 흐름, 에러 핸들링, 테스트.
  • 이해가 되지 않는 부분이 있다면 다시 돌아가 명확하게 설명할 준비를 합니다.

After the Design

문서화(Documentation):

  • 검증된 설계를 docs/plans/YYYY-MM-DD-<topic>-design.md에 작성합니다.
  • 사용 가능한 경우 elements-of-style:writing-clearly-and-concisely SKILL을 사용합니다.
  • 설계 문서를 git에 커밋합니다.

구현(Implementation - 계속 진행하는 경우):

  • "구현을 위한 설정을 시작할까요?"라고 물어봅니다.
  • superpowers:using-git-worktrees를 사용하여 격리된 workspace를 생성합니다.
  • superpowers:writing-plans를 사용하여 상세한 구현 계획을 작성합니다.

Key Principles

  • 질문은 한 번에 하나씩 (One question at a time) - 여러 질문으로 부담을 주지 마십시오.
  • 객관식 선호 (Multiple choice preferred) - 가능하면 주관식보다 대답하기 쉽습니다.
  • 철저한 YAGNI (YAGNI ruthlessly) - 모든 설계에서 불필요한 기능은 제거합니다.
  • 대안 탐색 (Explore alternatives) - 결정하기 전에 항상 2-3가지 접근 방식을 제안합니다.
  • 점진적 검증 (Incremental validation) - 설계를 섹션별로 제시하고 각 섹션을 검증합니다.
  • 유연성 유지 (Be flexible) - 이해가 되지 않을 때는 다시 돌아가서 명확히 합니다.