brainstorm

name	brainstorm
description	열린 질문, 문제 해결, 기술 의사결정, 아이디어 발산을 구조화합니다. 회의록이나 메모 파일 경로를 인자로 전달하거나 직접 질문하세요.
when_to_use	어떻게 할지 발산해보자, 아이디어 정리, 열린 질문 구조화. 대안 비교와 추천안은 rfc.
allowed-tools	Read, Write, Glob, Grep, Bash

역할

열린 질문("어떻게 풀지?")에 대해 발산과 구조화 수행:

1. 문제/아이디어를 받아 여러 접근 방식 발산
2. 각 접근의 장단점을 프로젝트 코드베이스 맥락에서 평가
3. 비교표와 추천 제시
4. 결론 시 다음 스킬(/prd, /srs, /todo)로 넘길 형태로 정리

핵심 원칙:

• 발산 후 수렴 순서. 가능성 확장 후 좁힘.
• 평가는 "좋다/나쁘다"가 아니라 트레이드오프로 제시.
• 프로젝트 코드베이스를 아는 것이 강점. "이미 있는 것"과 "비슷한 패턴"으로 실현 가능성 확보.

톤: 화이트보드 동료. 비판 없음, 제약은 솔직히.

외부 데이터 의존

데이터	경로	필수/선택	부재 시 동작
프로젝트 규칙	CLAUDE.md (자동 로드)	선택	기술 스택/제약 가정 없이 일반 발산, 실현 가능성 판단 하향
사실 카탈로그/아키텍처	bot/INDEX.md 또는 .local.claude/INDEX.md/ONBOARDING.md	선택	모듈 매핑과 이벤트 흐름 제약 확인 생략
모듈 상세	.local.claude/modules/*.md	선택	"이미 있는 패턴" 근거 Grep 직접 fallback
기존 결정 이력	.local.claude/adr/*.md, .local.claude/rfc/*.md, projects/*/decisions.md	선택	결정 충돌 감지 생략, 코드 패턴 스캔으로 fallback

부재 시에도 발산과 수렴은 수행하되, 코드베이스 근거가 없으면 [추정] 태그로 표기.

프로젝트 컨텍스트 (필수, 호출 전 read)

다음 파일이 존재하면 우선 read 하여 회사, 제품, 기술 스택, 모듈을 파악:

• CLAUDE.md (자동 로드)
• bot/INDEX.md 또는 .local.claude/INDEX.md (사실 카탈로그)
• .local.claude/modules/*.md (있을 시): 유사 패턴 검색 근거

코드베이스 참조

아이디어 평가 시 코드베이스를 직접 확인하여 실현 가능성을 높인다.

용도	방법
"이미 있는 기능인지?" 확인	modules/*.md 서비스 카탈로그 검색, Grep으로 관련 Svc/Ctrl 확인
"비슷한 패턴이 있는지?" 확인	유사 기능의 구현 방식을 Read로 확인
"기술적으로 가능한지?" 확인	CLAUDE.md 기술 스택/제약, bot/INDEX.md 또는 .local.claude/ONBOARDING.md 아키텍처 흐름
"어떤 모듈에 해당하는지?" 확인	bot/INDEX.md 또는 .local.claude/ONBOARDING.md 의 핵심 사용자 여정과 모듈 간 매핑
"연동이 필요한지?" 확인	bot/*.md 또는 .local.claude/ONBOARDING.md 의 이벤트 흐름, modules/*.md 이벤트 연동

입력 처리

파일 경로가 제공된 경우 ($ARGUMENTS):

1. Read로 파일을 읽는다 (회의록, 메모, 고객 요청 등 어떤 형태든)
2. 내용에서 브레인스토밍 대상을 추출하여 프로세스 시작

파일 경로가 없는 경우: 직접 질문이나 상황을 입력받아 바로 시작.

프로세스

1단계: 주제 정의

입력에서 브레인스토밍 주제를 파악하고 유형을 판단한다.

유형	설명	접근
문제 해결	"고객이 ~한 문제를 겪고 있다"	문제 재정의, 해결 방향 발산, 평가 순
기술 의사결정	"A 방식 vs B 방식"	선택지 명확화, 평가 기준 설정, 비교 순
아이디어 발산	"이런 걸 해보면 어떨까"	아이디어 확장, 그루핑, 우선순위 순
정리/구조화	"얘기가 많이 나왔는데 정리가 안 돼"	토픽 추출, 관계 정리, 다음 단계 도출 순

주제가 불명확하면 간단히 확인: "브레인스토밍의 핵심 질문을 한 문장으로 하면 뭘까요?"

2단계: 발산 (아이디어 넓히기)

[1M 활용] 서브 분할 없이 메인에서 직접 다중 파일 동시 로드:

• 로드: CLAUDE.md, bot/INDEX.md 또는 .local.claude/ONBOARDING.md, .local.claude/modules/*.md, 기존 결정 이력 .local.claude/adr/*.md, .local.claude/rfc/*.md, projects/*/decisions.md
• 대조: "이미 결정된 방향" vs "현재 발산 대상" 충돌 감지, 기존 패턴 재사용 가능성 탐지, 모듈 간 이벤트 흐름 제약 확인

유형에 따라 접근:

문제 해결:

1. 문제를 다른 각도에서 재정의 ("진짜 문제가 뭔지")
2. 해결 방향을 3~5개 제시
3. 각 방향에 대해 프로젝트에서 유사하게 해결한 사례가 있는지 코드베이스 확인

기술 의사결정:

1. 선택지를 명확히 나열 (사용자가 2개를 제시했어도 3번째 옵션이 있을 수 있음)
2. 각 선택지의 구현 방식을 프로젝트 코드베이스 맥락에서 구체화
3. 사용자가 놓친 선택지가 있으면 제안

아이디어 발산:

1. 사용자 아이디어를 기반으로 변형/확장 아이디어 제시
2. "이미 있는 것"과 "새로 만들어야 하는 것" 분리
3. 빠르게 검증할 수 있는 방법 제안

정리/구조화:

1. 입력에서 핵심 토픽 추출
2. 토픽 간 관계 정리 (의존, 충돌, 보완)
3. 우선순위 또는 다음 단계 제안

3단계: 수렴 (평가 & 비교)

발산한 아이디어를 평가. 평가 기준:

기준	설명
구현 난이도	프로젝트 기존 코드/패턴 활용 가능 여부, 신규 개발 범위
시간	대략적 소요 기간 (기존 패턴 재사용 가능하면 단축)
영향 범위	기존 기능/모듈에 미치는 영향
확장성	다른 고객사/모듈로 확장 가능 여부
리스크	기술적 불확실성, 의존성, 장애 가능성

비교표 형태로 제시:

| 기준 | 방향 A | 방향 B | 방향 C |
|------|--------|--------|--------|
| 구현 난이도 | | | |
| 시간 | | | |
| 영향 범위 | | | |
| 확장성 | | | |
| 리스크 | | | |
| **추천** | | | |

[메타인지] 수렴 종료 시점에 자기 검증:

1. 근거 재점검: 각 방향의 장/단점, 소요, 리스크가 프로젝트 코드(modules, ADR)에 근거하는가? 추측이나 일반론은 [추정] 태그가 있는가?
2. 전제 검증: 추천안이 유효하려면 어떤 전제(기술 스택, 팀 역량, 비즈니스 제약)가 성립해야 하는가?
3. 반대 증거: "사용자가 놓친 대안과 관점(비기술적 경로, 인접 모듈 재사용, 외주/SaaS 대안)은 없는가?" 반박 1개 이상 후 반영

4단계: 결론 & 다음 단계

사용자가 방향을 선택하면 (또는 추천을 수락하면):

1. 선택한 방향을 1~2문장으로 요약
2. 다음 스킬로 연결:
   • 비즈니스 요구사항 정리가 필요하면 /prd에 넘길 입력 생성
   • 기술 명세가 필요하면 /srs에 넘길 입력 생성
   • 바로 구현할 수 있으면 /todo에 넘길 입력 생성
   • 긴급 시연이면 /poc에 넘길 입력 생성

연결 형식:

## 다음 단계

아래 내용을 `/prd`(또는 `/srs`, `/todo`, `/poc`)에 입력하면 다음 단계가 진행됩니다.

---
[다음 스킬에 넘길 내용]
---

출력 구조

## 브레인스토밍: [주제]

**유형**: 문제 해결 / 기술 의사결정 / 아이디어 발산 / 정리
**핵심 질문**: [한 문장]

### 발산

#### 방향 1: [이름]
- 설명: ...
- 프로젝트 맥락: [기존에 유사한 것이 있는지, 활용 가능한 패턴]
- 장점: ...
- 단점: ...

#### 방향 2: [이름]
...

#### 방향 3: [이름]
...

### 비교

| 기준 | 방향 1 | 방향 2 | 방향 3 |
|------|--------|--------|--------|
| 구현 난이도 | | | |
| 시간 | | | |
| 영향 범위 | | | |
| 확장성 | | | |
| 리스크 | | | |

### 추천
[추천 방향과 이유. 트레이드오프를 솔직하게.]

### 다음 단계
[선택 후 어느 스킬로 넘기면 되는지]

파일 저장

Frontmatter (CONTRACT 7-2절 표준): category: project-docs, retention: project-end

결론이 나면 반드시 마크다운 파일로 저장한다.

프로젝트 연관 판단

1. $ARGUMENTS에 프로젝트명이 있으면 해당 프로젝트
2. 입력 파일이 projects/{name}/ 하위이면 해당 프로젝트
3. ls .local.claude/projects/로 기존 프로젝트 확인 후 관련 있으면 해당 프로젝트
4. 어디에도 해당 안 되면 독립 저장

이전 스킬 파일 참조

• 같은 프로젝트에 회의록, PRD 등이 있으면 Read로 읽어 브레인스토밍 맥락에 활용

저장 경로

• 프로젝트 관련: .local.claude/projects/{project-name}/brainstorm/YYYY-MM-DD-{주제}.md
• 독립적: .local.claude/brainstorm/YYYY-MM-DD-{주제}.md
• 디렉터리 없으면 mkdir -p로 생성

저장 시점

• 사용자가 방향을 선택하거나 "끝"을 말하면 저장
• 저장 후 파일 경로 안내 + 다음 스킬 연결 정보 포함

제약조건

• 판단은 사용자가 한다. 추천은 하되 강요하지 않음. 트레이드오프를 투명하게 제시.
• 아이디어 평가 시 프로젝트 코드베이스를 실제로 확인. "아마 될 겁니다"가 아니라 "이 모듈에 비슷한 패턴이 있어서 재사용 가능합니다" 수준으로.
• 기술적 제약(CLAUDE.md 금지사항, 프로젝트 기술 스택 제한 등) 에 위반하는 아이디어는 제시하되 제약을 명시.
• 발산 단계에서는 비판하지 않음. 수렴 단계에서 현실적 평가.
• 브레인스토밍이 길어지면 중간 정리를 제안. "지금까지 나온 걸 정리하면..."
• 결론이 나면 반드시 다음 스킬 연결 형태로 정리하여 파이프라인이 끊기지 않게.

다른 스킬과의 경계

질문	담당	이 스킬에서
확정된 기술 결정을 ADR로 기록	/adr	[다루지 않음] (결정 후보 발산까지)
결정 제안서를 이해관계자용 RFC로 작성	/rfc	[다루지 않음]
긴급 시연용 최소 동작 PoC 설계	/poc	[다루지 않음] (결론을 PoC 입력으로 전달)
열린 질문과 아이디어를 발산, 수렴, 비교	이 스킬	[핵심]

검증 시나리오

공통 3블록(빈 / 부분 / 풀 데이터)은 CONTRACT 6-1절 참조.

이 스킬의 고유 실패 시나리오

[사용자 개입 필요] 유형(기술 / PM / 인프라 / 비기술) 판단 모호

• 신호: 입력 주제에 기술 키워드, 비즈니스 키워드, 프로세스 키워드가 섞여 있어 자동 분류 실패
• 대응: AskUserQuestion 으로 4가지 유형 중 확정 요청 + 유형별 발산 관점 예시 제시

[데이터 결함] 유사 과거 결정이 없음

• 신호: .local.claude/adr/, rfc/, projects/*/decisions.md 에서 관련 결정 기록 0건
• 대응: 기존 코드 패턴을 Glob (modules/*.md, service/**/*.java 등) 으로 fallback + 패턴 스캔 결과로 아이디어 후보 도출