brainstorming

Brainstorming Ideas Into Designs

Overview

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.

Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.

The Process

Understanding the idea:

• Check out the current project state first (files, docs, recent commits)
• Ask questions one at a time to refine the idea
• Prefer multiple choice questions when possible, but open-ended is fine too
• Only one question per message - if a topic needs more exploration, break it into multiple questions
• Focus on understanding: purpose, success criteria

Constraints 수집 (반드시 질문): 아이디어 파악 후, 아래 4분류를 각각 질문하여 제약조건을 수집한다:

• Technical: 기술 스택, 인프라, 호환성 한계 (예: "기존 DB 유지?", "특정 언어/프레임워크 제약?")
• Resource: 시간, 인원, 예산, 환경 (예: "데드라인?", "1인 개발?", "서버 비용 한도?")
• Business: 법적/규제, 계약, 정책 (예: "개인정보보호법 적용?", "외부 API 계약 조건?")
• Scope: 하지 않을 것, 범위 외 (예: "MVP에서 명시적으로 제외할 것?")

사용자가 "없다"고 답해도 기록한다. 명시적 "제약 없음"은 암묵적 누락과 다르다.

Business Rules 수집: 제약조건 확인 후, 핵심 비즈니스 규칙을 질문한다:

• "이 서비스에서 반드시 지켜야 하는 도메인 규칙이 있는가?"
• "그 규칙의 근거(법령, 정책, 관행)는 무엇인가?"
• 각 규칙에 대해 Rule(무엇) / Rationale(왜) / Source(출처)를 확인

Exploring approaches:

• Propose 2-3 different approaches with trade-offs
• Present options conversationally with your recommendation and reasoning
• Lead with your recommended option and explain why

Devil's Advocate checkpoint (접근법 확정 직전):

• 추천한 접근법의 가장 큰 약점 1가지를 명시적으로 제시
• 사용자에게 질문: "이 접근법이 실패한다면 가장 큰 이유는 무엇일까요?"
• 사용자가 약점을 인지한 상태에서 최종 선택하도록 유도
• devil-advocate 스킬의 프레임워크 적용: 전제 공격 + 반례 제시 (각 1문장)
• 이 단계를 건너뛰지 않을 것 — 약점을 모른 채 진행하면 설계 품질이 저하됨

Presenting the design:

• Once you believe you understand what you're building, present the design
• Break it into sections of 200-300 words
• Ask after each section whether it looks right so far
• Cover: architecture, components, data flow, error handling, testing
• Be ready to go back and clarify if something doesn't make sense

After the Design (MANDATORY)

Documentation (MUST DO IMMEDIATELY after user approval):

• IMMEDIATELY write the validated design to docs/plans/NNNN.YYYY-MM-DD-<topic>-design.md (NNNN: 해당 폴더 내 최대 번호 + 1, 없으면 0001)
• This is NOT optional - do this BEFORE any implementation
• Include in the document:
  • Overview and goals
  • Key requirements summary
  • Constraints (Technical / Resource / Business / Scope 4분류)
  • Business Rules (Rule / Rationale / Source 테이블)
  • File structure (new/modified files list)
  • Detailed design (with code examples)
  • Implementation order (separable into TODO items)
  • Verification methods

TODO Generation (MUST DO after documentation):

• Create implementation tasks from the design
• Each TODO should be ONE independent work unit
• TODO order must match implementation order

PRD Handoff (Large feature / New project만):

• 다중 모듈, 새 도메인, 새 프로젝트인 경우에만 prd-strategist 호출
• Pass the design document path as context
• Small feature (단일 모듈, 명확한 요구사항)에서는 PRD 스킵 → 바로 writing-plans로 직행

Implementation (if continuing):

• writing-plans를 호출하여 구현 계획 작성
• Create isolated workspace if applicable

Key Principles

• One question at a time - Don't overwhelm with multiple questions
• Multiple choice preferred - Easier to answer than open-ended when possible
• YAGNI ruthlessly - Remove unnecessary features from all designs
• Explore alternatives - Always propose 2-3 approaches before settling
• Incremental validation - Present design in sections, validate each
• Be flexible - Go back and clarify when something doesn't make sense

Completion

설계가 docs/plans/에 저장되고 TODO가 생성되면 완료.

Troubleshooting

User gives vague idea with no constraints: Ask "What would make this a failure?" to surface hidden requirements and scope boundaries. Design discussion going too long: After 10+ exchanges without convergence, pause and summarize what's been decided so far. Present remaining open questions as a numbered list. Conflicting requirements discovered mid-design: Stop, present the conflict explicitly with trade-offs, and ask user to choose before continuing. User wants to skip brainstorming and jump to code: Confirm they have clear requirements. If yes, hand off to writing-plans or feature-development. If no, explain that 10 minutes of brainstorming saves hours of rework. Design keeps expanding in scope: Restate the original goal. Apply YAGNI: "Which of these features validates the core idea?"