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