/brainstorming — 설계 탐색 스킬

새 기능이나 시스템을 구현하기 전, 설계를 탐색하고 사용자의 승인을 받는다. Hard Gate: 승인 없이 코드 작성, 스캐폴딩, 구현 액션 일체 불가.

When to use

• 새 기능 아이디어 탐색
• "어떻게 구현할까" 수준의 초기 논의
• 접근법이 여러 개 존재하고 트레이드오프 비교가 필요할 때
• 기존 코드 없이 처음부터 설계할 때

동작 순서 (반드시 준수)

1단계: 프로젝트 컨텍스트 파악

• docs/ARCHITECTURE.md 읽기
• docs/specs/ 기존 스펙 확인
• 관련 패키지 구조 파악

2단계: 명확화 질문

구현 전 반드시 확인:

• 이 기능의 핵심 목적은?
• 기존 코드와 어떻게 연결되는가?
• 성능/보안 제약이 있는가?
• 우선순위 (빠른 구현 vs 확장성)?

3단계: 접근법 2-3가지 제시

각 접근법에 포함:

**접근법 A: [이름]**
- 설명: 한 줄 요약
- 장점: ...
- 단점: ...
- 적합한 경우: ...

4단계: 설계 문서 작성 (사용자 승인 후)

승인된 접근법을 바탕으로:

docs/specs/YYYY-MM-DD-{topic}-design.md

포함 내용:

• 선택한 접근법과 이유
• 도메인 모델 (Entity, VO, 관계)
• 레이어별 책임
• API 엔드포인트 초안
• DB 스키마 변경
• 열린 질문

5단계: /spec 연계

설계 문서 작성 완료 후 → /spec으로 공식 FEAT-NNN 스펙 문서화 권장.

Hard Gate 규칙

다음 중 어느 것도 승인 전에 하지 않는다:

• 코드 작성
• 파일 생성 (설계 문서 제외)
• 프로젝트 스캐폴딩
• 패키지/의존성 추가
• git commit

승인 = 사용자가 명시적으로 "이 접근법으로 진행해", "좋아", "승인" 등으로 확인한 경우.

/architect 와의 차이

References

• docs/NAMING.md — DDD/Clean Architecture 역할 명명 + 패키지 구조 + 레퍼런스 레포
• docs/STYLE_GUIDE.md — 원칙 (Karpathy 4 + 동료 협업 + 정량)
• docs/RED_FLAGS.md — 안티패턴
• docs/LAYER_RULES.md — 레이어 규칙