/brainstorming

name: brainstorming
description: 기능 추가·컴포넌트 생성·동작 변경 등 모든 창작 작업 전에 사용. 구현 전에 의도·요구사항·설계를 대화로 확정 (심층 인터뷰가 필요한 대규모 기능은 /spec 사용)

Brainstorming (구현 전 설계 확정)

아이디어를 자연스러운 대화로 완성된 설계로 만든 뒤에만 구현에 들어간다.

**HARD GATE: 설계를 제시하고 사용자 승인을 받기 전에는 코드 작성·스캐폴딩·구현 착수 금지.** "너무 단순해서 설계가 필요 없다"는 함정이다 — 단순한 프로젝트일수록 검증 안 된 가정이 재작업을 만든다. 설계는 몇 문장이어도 되지만 반드시 제시하고 승인받는다.

프로세스

1. **프로젝트 컨텍스트 파악** — 파일, 문서, 최근 커밋 확인 2. **범위 판단** — 독립적인 서브시스템 여러 개를 묶은 요청이면 세부 질문 전에 분해부터 제안. 서브 프로젝트별로 spec → plan → 구현 사이클 3. **질문은 한 번에 하나씩** — 목적, 제약, 성공 기준을 파악. 가능하면 객관식 4. **접근법 2~3개 제안** — 트레이드오프와 함께, 추천안을 먼저 제시하고 이유 설명. YAGNI 원칙으로 불필요한 기능은 모든 안에서 제거 5. **설계 제시** — 섹션별로 복잡도에 맞는 분량(단순하면 몇 문장). 아키텍처·컴포넌트·데이터 흐름·에러 처리·테스트를 다루고 섹션마다 확인받기 6. **설계 문서 저장** — `{project}/docs/design-docs/[날짜]-[주제].md` (기존 하네스의 execute-plans와 연결) 7. **셀프 리뷰** — TBD/placeholder, 섹션 간 모순, 중의적 요구사항, 범위 적정성 검사 후 즉시 수정 8. **사용자 스펙 검토 요청** → 승인 후 /plan 으로 구현 계획 수립

설계 원칙

• 각 유닛은 하나의 명확한 목적 + 잘 정의된 인터페이스 + 독립 테스트 가능
• 유닛마다 답할 수 있어야 함: 무엇을 하나 / 어떻게 쓰나 / 무엇에 의존하나
• 내부를 읽지 않고 역할을 이해할 수 없거나, 내부 변경이 소비자를 깨뜨리면 경계 설계가 잘못된 것
• 기존 코드베이스에서는 기존 패턴을 따르고, 현재 작업에 영향을 주는 문제만 targeted 개선 포함 (무관한 리팩토링 제안 금지)