brainstorming

Brainstorming

설계 승인 없이 plan-task를 invoke하거나 코드를 작성하면 안 됩니다.

체크리스트

진입 즉시 ToolSearch("select:TaskCreate,TaskUpdate,TaskList")로 Task 도구를 로드한 후,

Task 도구가 없으면 멈추지 말고 대체 경로로 간다 — ToolSearch가 Task 계열을 반환하지 않는 호스트/세션이 있다(F-038). 그때는 ./scripts/checklist.sh 기반 durable checklist로 추적한다. 규율 SSOT: skills/references/task-tools-fallback.md. 아래 항목 각각에 대해 TaskCreate를 실행하세요.

Task 네이밍 규약: [Brainstorm] {항목명} (plan-task의 [Planning] Task와 구분) 완료 마킹 규약 [건너뛰기 금지]: 각 항목을 마치면 즉시 TaskUpdate(status="completed"), 마지막 항목(plan-task invoke)은 invoke 직전에 마킹 (규율 SSOT: rules/definition-of-done.md#task-마감-규율). work_id metadata: brainstorming 단계에서는 Work ID가 없으므로 {"phase": "brainstorming"}만 사용

1. 프로젝트 컨텍스트 파악 (파일, 최근 커밋, docs)
2. 명확화 질문 (한 번에 하나씩)
3. 2-3가지 접근법 + 추천
4. 설계 제시 및 사용자 승인
5. 스펙 문서 작성 (docs/specs/YYYY-MM-DD-{topic}.md)
6. 스펙 자가 검토 (플레이스홀더, 모순, 모호성)
7. 사용자 스펙 검토 대기
8. plan-task invoke

프로세스

1단계: 컨텍스트 파악

• 관련 파일, README, 최근 커밋 확인
• 규모 판단: 복수의 독립 서브시스템이면 분해 먼저 제안

2단계: 명확화 질문

• 한 번에 하나의 질문만
• 목적, 제약, 성공 기준에 집중
• 가능하면 객관식 선택지 제공

3단계: 접근법 제안

• 2-3가지 접근법과 트레이드오프
• 추천안과 이유를 먼저 제시

4단계: 설계 제시

• 각 섹션을 순서대로 제시하고 승인 확인
• 아키텍처, 컴포넌트, 데이터 흐름, 에러 처리, 테스트 전략 포함
• 수정 요청 시 해당 섹션 재작성

5단계: 스펙 문서 작성

저장 경로: docs/specs/YYYY-MM-DD-{topic}.md (docs/works/ 있으면 해당 Work와 연결)

스펙 문서 구조:

# {Topic} 설계

**Goal:** [한 문장]
**Architecture:** [2-3 문장]

## 요구사항
## 접근 방식
## 컴포넌트 구조
## 데이터 흐름
## 에러 처리
## 테스트 전략
## 범위 외

6단계: 자가 검토

1. 플레이스홀더 스캔: TBD, TODO, 미완성 섹션 → 즉시 수정
2. 일관성: 섹션 간 모순 없는지 확인
3. 범위: 단일 plan으로 구현 가능한가?
4. 모호성: 두 가지로 해석 가능한 요구사항 → 명확화

7단계: 사용자 검토 대기

세션 경계 주의: 이 단계에서 세션이 끝나면 대기 태스크가 다음 세션에 잔존한다 — 정상이다. 재개 판단 기준은 docs/specs/의 스펙 파일 (rules/task-resume.md 참고).

스펙을 `{path}`에 저장했습니다. 검토 후 수정 사항이 있으면 말씀해 주세요.
승인되면 plan-task로 넘어갑니다.

수정 요청 시 → 수정 후 자가 검토 재실행 승인 시 → 8단계