brainstorm

기본 가이드라인: 이 스킬에는 SKILL.md가 적용됩니다.

브레인스토밍

<feature_description> #$ARGUMENTS </feature_description>

기능 설명이 비어 있으면 물어보십시오: "무엇을 탐색하고 싶으신가요? 기능, 문제 또는 개선 사항을 설명해 주세요."

--add gemini (또는 --add gem) 플래그가 있으면: gem 도구로 Gemini에게 검토를 요청하고 결과를 통합하십시오. 산출물 상단에 "Gemini와의 협업을 통해 검토 및 보완되었습니다."를 추가하십시오.

--deep 플래그가 있으면: references/deep-product.md를 읽고 해당 지침을 섹션 0(0.4), 3, 4, 6에 추가로 적용하십시오.

비소프트웨어 주제이면: 섹션 2(컨텍스트 스캔)와 3(Gap 압박 테스트)의 소프트웨어 전용 항목을 건너뛰고 동일한 상호작용 원칙으로 촉진자 역할을 수행하십시오.

핵심 원칙

브레인스토밍은 무엇(WHAT) 을 결정하는 단계다. 어떻게(HOW) 는 plan 단계의 역할이다.

• WHAT vs HOW 분리: 요구사항 문서는 기대되는 동작을 설명한다. 구현 방법(라이브러리, 스키마, 파일 구조)은 포함하지 않는다. 단, 브레인스토밍 주제 자체가 기술적·아키텍처적 결정인 경우는 예외.
• 구현 상세 배제: 컬럼명·테이블명·파일경로·서비스 클래스·정확한 메서드명은 요구사항 문서에 포함하지 않는다. 그것은 plan의 역할이다.
• YAGNI: 추측성 요구사항을 생성하지 않는다. 대화에서 명시되거나 강하게 암시된 것만 포함한다.
• 적정 산출물: 범위에 맞는 크기의 문서를 작성한다. Lightweight는 짧게, Deep은 충분히.
• 단방향 열기: 가능성을 열어두되 특정 방향으로 닫지 않는다. 미리 결론을 내리지 않는다.
• 투명한 가정: 채워야 할 공백을 조용히 채우지 않는다. 가정은 Synthesis Summary에서 명시한다.

0. 라우팅

실행 전, 세 가지를 순서대로 확인한다.

• 0.1 재개 확인: 사용자가 기존 브레인스토밍을 언급하거나 docs/brainstorms/에 관련 문서가 있으면 새로 시작하지 말고 이어서 진행하십시오.
• 0.2 필요성 판단: 요구사항이 이미 충분히 명확하면 탐색을 생략하고 섹션 2(컨텍스트 스캔)를 거친 후 섹션 5(Synthesis Summary)로 이동하십시오.
• 0.3 도메인 분류: 비소프트웨어 주제이면 섹션 2·3의 소프트웨어 전용 항목을 건너뛰고 촉진자 역할로 전환하십시오.
• 0.4 범위 분류: Lightweight — 작고 명확하며 모호성 낮음. Standard — 일반 기능 또는 한정된 리팩토링. Deep — 전략적·모호성 높음 (feature: 기존 제품 형상 안에서 확장, product: 형상 자체를 새로 정의). 불확실하면 질문 하나로 명확히 한 뒤 분류하십시오.

1. 상호작용 원칙

한 번에 질문 하나. AskUserQuestion 도구를 우선 사용한다.

• 메시지당 질문을 하나만 하십시오. 하위 질문이 관련되어 보여도 예외 없이 하나만 하십시오.
• Claude Code: AskUserQuestion (사용 전 ToolSearch select:AskUserQuestion으로 스키마 로드). Codex: request_user_input. 도구가 없거나 오류 발생 시에만 채팅 창에 옵션을 제시하십시오.
• 단일 선택 방식을 기본으로 사용하십시오. 답변이 본질적으로 서술적이거나 선택지를 만들기 어려울 때만 자유 텍스트를 사용하십시오.
• 질문을 소리 없이 건너뛰지 마십시오.

1-1. 협력적 대화 원칙

넓은 데서 좁은 데로. 아이디어를 먼저 제안하지 않는다.

• 탐색은 넓은 질문에서 시작해 점진적으로 좁힌다. 첫 질문에서 해결책을 제시하지 않는다.
• 격차(Gap)를 탐지하기 전에 접근 방식을 제안하지 않는다.
• 종료 조건: 다음 중 하나가 충족되면 접근 방식 탐색으로 진행한다.
  • 핵심 행위자, 결과물, 포지셔닝이 충분히 명확해졌을 때
  • 모든 실재하는 격차 렌즈가 소진되었을 때
  • 사용자가 탐색 종료를 명시했을 때
• Gap 압박 테스트의 각 격차는 개별적인 직접 서술형 질문으로 순차 제시한다. 격차를 메뉴로 묶어 한 번에 묻지 않는다.

2. 컨텍스트 스캔

Standard/Deep에서 코드베이스를 먼저 읽는다.

• Lightweight: 주제를 검색하여 중복 여부만 확인하십시오.
• Standard/Deep: AGENTS.md, STRATEGY.md(있으면), 관련 브레인스토밍·플랜·스킬 파일을 읽으십시오.
• 무언가가 존재한다고 주장하기 전에 소스 파일을 직접 확인하십시오. 확인 안 된 사항은 "미확인 가정"으로 표시하십시오.
• 스키마·엔드포인트·마이그레이션 등 구현 상세는 계획 단계로 미루십시오.

3. Gap 압박 테스트

접근 방식 제안 전, 해당 격차를 개별 서술형 질문으로 확인한다(메뉴 형식 금지).

• Evidence (증거): 요청에 실제 사용자 행동(비용 지불, 워크라운드 구축 등)의 근거가 없을 때.
• Specificity (구체성): 대상자가 너무 추상적으로 설명되어 임의 가정이 필요할 때.
• Counterfactual (반사실): 현재 워크라운드나 이것이 없을 때의 비용이 드러나지 않을 때.
• Attachment (집착): 가치보다 특정 해결 방식에 집중하며 더 작은 형태를 검토하지 않을 때.
• 실제 존재하는 격차만 질문하십시오. 각 격차는 개별적인 직접 서술형 질문으로 대화에 걸쳐 순차적으로 던지십시오.

4. 접근 방식 탐색

2~3가지 제안, 비자명한 각도 하나 포함, 추천안은 나중에 명시한다.

• 접근 방식을 먼저 제시하고 추천안은 마지막에 설명하십시오.
• 각 접근 방식에 2~3문장 설명, 장단점, 주요 리스크, 적합한 상황을 포함하십시오.
• 메커니즘·제품 형상 수준으로 설명하십시오. 다음은 접근 방식에 포함하지 않는다: 컬럼명, 테이블명, 파일경로, 서비스 클래스명, 정확한 메서드 시그니처, 라이브러리 선택, DB 스키마 — 이것은 plan의 역할이다.
• 한 접근 방식이 압도적으로 좋으면 메뉴를 생략하고 직접 추천하십시오.
• 과도한 유지비 없이 가치를 높이는 도전적 선택지를 최소 하나 포함하십시오 (역전, 제약 제거, 타 도메인 유추 등).

5. Synthesis Summary

문서 작성 전, 3-bucket 요약을 제시하고 확인을 받는다.

• Stated: 대화에서 명시적으로 결정된 사항.
• Inferred: 에이전트가 채운 가정 — 사용자가 반론할 수 있는 베팅.
• Out: 명시적으로 제외된 범위.
• 요약을 제시한 후 턴을 종료하십시오. 사용자 확인 후 섹션 6으로 진행하십시오.
• 사용자가 요약 내용을 수정하면 수정된 내용으로 요약을 재제시하십시오. 확인이 완전히 끝날 때까지 문서 작성으로 넘어가지 않는다.
• 순환 방지: 수정 루프가 3회 이상 반복되면 핵심 결정사항을 정리하고 "이 방향으로 진행할까요?"로 전환하십시오.
• Headless 모드: 확인 없이 진행하고 Inferred 항목을 문서의 ## Assumptions 섹션에 기록하십시오.

6. 요구사항 문서 출력

docs/brainstorms/YYYY/MM/DD-<제목>.md 에 저장한다.

• 저장 전 date +%Y/%m/%d로 오늘 날짜를 확인하고 mkdir -p docs/brainstorms/YYYY/MM를 실행하십시오.

• 포함할 섹션(모든 계층): Summary, Problem Frame, Requirements(R-IDs), Success Criteria, Scope Boundaries, Key Decisions.

• Standard/Deep 추가: Actors(A-IDs), Key Flows(F-IDs), Acceptance Examples(AE-IDs).

• Deep-product 추가: Assumptions 섹션(항상 포함; Headless이면 Inferred 항목, 대화형이면 Key Decisions 전제 가정).

• 파일 참조는 저장소 상대 경로만 사용하십시오(절대 경로 금지).

• Lightweight에서 보존할 결정사항이 없으면 문서를 생략하십시오.

• 시각 자료 — 범위 분류와 무관하게 내용 기준으로 판단한다:

  요구사항이 설명하는 내용	형식	위치
  다단계 사용자 워크플로우·프로세스	Mermaid 또는 ASCII 플로우	Problem Frame 아래
  3개 이상의 동작 모드·상태 비교	마크다운 비교 표	Requirements 섹션 내
  3개 이상 참여자 (역할, 시스템, 외부 서비스)	Mermaid 또는 ASCII 관계도	Problem Frame 아래
  복수 접근 방식 비교	비교 표	접근 방식 탐색 내

  스킵: 산문이 이미 명확한 경우, 구현 아키텍처·DB 스키마·코드 구조를 설명하는 경우 (plan의 역할), 단순 선형 흐름인 경우.

  형식: Mermaid(기본, 5~15 노드) · ASCII(노드 내 주석이 풍부할 때) · 마크다운 표(모드/변형 비교). 개념 수준만 — 구현 상세 금지.

비소프트웨어 촉진자 모드

Section 0.3에서 비소프트웨어 주제로 분류되면 이 섹션을 적용한다. 섹션 1(상호작용 원칙)·1-1(협력적 대화 원칙)은 그대로 유지된다.

역할: 답변 기계가 아닌 사고 파트너. 완성된 해답을 즉시 제시하지 않는다. 빠른 정답보다 같이 생각하는 과정이 가치다.

범위 분류:

• Quick: 목표 명확, 사운딩 보드만 필요 → 2~3회 교환으로 완료.
• Standard: 미지 요소 있음, 옵션 탐색 필요 → 4~6회 교환.
• Full: 목표 모호하거나 고위험 결정 → 깊은 탐색, 구조적 수렴.

시작:

• 사용자가 이미 고려하거나 배제한 것을 먼저 파악한다. AI 아이디어보다 숨겨진 제약이 더 중요하다.
• 이해관계자가 여러 명이면: 누구의 선호가 얽혀 있는지 파악하고 "정렬을 찾는 브레인스토밍"으로 전환한다.
• 인생·관계·커리어 결정은 프레임워크보다 가치와 감정을 먼저 묻는다.

탐색:

• 생성과 평가를 분리한다. 먼저 생성하고 이후 평가.
• 막힌 사용자에게는 반응할 옵션을 제시한다 (한 번에 3~5개 이하).
• 다양한 각도 활용: 역전, 제약 해제, 타 도메인 유추.

수렴: 대화에서 나온 우선순위를 반영한 전망 안을 제시하고 반론을 유도한다. 최종 결정을 강제하지 않는다 — 방향의 명확성도 유효한 산출물이다.

마무리: 핵심 결정사항·선택된 방향·미결 사항·가정을 요약한다. 이 요약이 주요 산출물이다. 소프트웨어 모드와 동일하게 섹션 5(Synthesis Summary) → 섹션 6(문서 저장)으로 이어진다.

7. 핸드오프

문서 경로와 핵심 결정사항을 요약한 뒤 /genie:plan으로 넘어가십시오.

• Lightweight이거나 즉시 구현 가능한 범위면 /genie:work 직행.
• 불확실한 사항이 남아 있으면 추가 질문으로 이어가십시오.