192 lines
10 KiB
Markdown
192 lines
10 KiB
Markdown
---
|
|
name: "brainstorming"
|
|
description: "구현 전에 아이디어를 질문과 설계안으로 구체화합니다. 기능 추가, 동작 변경, 신규 개발처럼 창의적 작업을 시작하기 전에 반드시 호출합니다."
|
|
---
|
|
|
|
# 아이디어를 설계로 구체화하기
|
|
|
|
자연스러운 협업형 대화를 통해 아이디어를 완성도 높은 설계와 명세로 바꿉니다.
|
|
|
|
먼저 현재 프로젝트 문맥을 이해한 뒤, 질문을 한 번에 하나씩 하면서 아이디어를 구체화합니다. 무엇을 만들지 충분히 이해했다면 설계를 제시하고 사용자 승인을 받습니다.
|
|
|
|
<HARD-GATE>
|
|
설계를 제시하고 사용자 승인을 받기 전까지는 구현 스킬 호출, 코드 작성, 프로젝트 스캐폴딩, 기타 구현 행동을 해서는 안 됩니다. 이 규칙은 작업이 얼마나 단순해 보이든 항상 적용됩니다.
|
|
</HARD-GATE>
|
|
|
|
## 안티 패턴: "이건 너무 단순해서 설계가 필요 없다"
|
|
|
|
모든 작업은 이 과정을 거쳐야 합니다. 할 일 목록, 단일 함수 유틸리티, 설정 변경도 예외가 아닙니다. "단순한" 작업일수록 검증되지 않은 가정 때문에 불필요한 재작업이 생기기 쉽습니다. 설계는 짧아도 되지만, 반드시 제시하고 승인을 받아야 합니다.
|
|
|
|
## 체크리스트
|
|
|
|
아래 항목별로 작업을 만들고, 순서대로 완료해야 합니다.
|
|
|
|
1. **프로젝트 문맥 탐색** - 파일, 문서, 최근 커밋 확인
|
|
2. **시각 보조 도구 제안** - 시각적 질문이 예상되면 별도 메시지로 제안
|
|
3. **명확화 질문 진행** - 한 번에 하나씩 질문하며 목적, 제약, 성공 기준 파악
|
|
4. **2~3개 접근법 제안** - 트레이드오프와 추천안 포함
|
|
5. **설계 제시** - 복잡도에 맞춰 섹션별로 설명하고 승인 받기
|
|
6. **설계 문서 작성** - `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`에 저장
|
|
7. **명세 자체 점검** - placeholder, 모순, 모호성, 범위 확인
|
|
8. **사용자 문서 검토** - 구현 전 설계 문서 검토 요청
|
|
9. **구현 단계 전환** - 다음 단계로 `writing-plans` 스킬 호출
|
|
|
|
## 프로세스 흐름
|
|
|
|
기본 흐름은 아래와 같습니다.
|
|
|
|
1. 현재 프로젝트 문맥을 탐색합니다.
|
|
2. 필요한 경우 시각 보조 도구를 별도 메시지로 제안합니다.
|
|
3. 질문을 한 번에 하나씩 하며 요구를 구체화합니다.
|
|
4. 2~3개의 접근법을 비교하고 추천안을 제시합니다.
|
|
5. 설계를 섹션 단위로 설명하며 단계적으로 승인을 받습니다.
|
|
6. 승인된 설계를 문서로 저장합니다.
|
|
7. 문서를 스스로 점검해 빈칸, 모순, 모호함을 제거합니다.
|
|
8. 사용자에게 문서 검토를 요청합니다.
|
|
9. 승인이 끝나면 다음 단계로 `writing-plans`를 호출합니다.
|
|
|
|
## 프로세스
|
|
|
|
**아이디어 이해**
|
|
|
|
- 먼저 현재 프로젝트 상태를 확인합니다.
|
|
- 요청이 여러 독립 하위 시스템을 포함하면, 세부 질문 전에 먼저 분해가 필요한지 판단합니다.
|
|
- 하나의 명세로 다루기 너무 크다면 하위 프로젝트로 나누고, 첫 번째 하위 프로젝트만 일반 설계 흐름으로 진행합니다.
|
|
- 적절한 범위라면 질문을 한 번에 하나씩 하며 구체화합니다.
|
|
- 가능하면 객관식 질문을 우선 사용하되, 필요하면 서술형도 사용합니다.
|
|
- 각 메시지에는 질문 하나만 포함합니다.
|
|
- 목적, 제약 조건, 성공 기준을 이해하는 데 집중합니다.
|
|
- 너무 일찍 구현 방향으로 뛰어들지 말고, 범위와 기대 결과를 먼저 고정합니다.
|
|
- "간단해 보인다"는 이유로 질문 단계를 생략하지 않습니다.
|
|
|
|
**접근법 탐색**
|
|
|
|
- 서로 다른 2~3개의 접근법을 제안합니다.
|
|
- 각 접근법의 장단점과 추천 이유를 함께 설명합니다.
|
|
- 추천안을 먼저 제시하고, 왜 그 선택이 적합한지 설명합니다.
|
|
- 접근법은 기능 관점뿐 아니라 유지보수, 테스트 용이성, 사용자 경험까지 함께 비교합니다.
|
|
|
|
**설계 제시**
|
|
|
|
- 무엇을 만들지 충분히 이해했다면 설계를 제시합니다.
|
|
- 각 섹션은 복잡도에 맞게 짧게 또는 자세히 설명합니다.
|
|
- 각 섹션 뒤에는 지금까지 맞는지 확인을 요청합니다.
|
|
- 아키텍처, 구성요소, 데이터 흐름, 오류 처리, 테스트를 다룹니다.
|
|
- 이해되지 않는 부분이 있으면 다시 질문하고 명확히 합니다.
|
|
- 한 번에 모든 내용을 밀어 넣기보다, 사용자가 따라올 수 있는 단위로 나눠 검증합니다.
|
|
|
|
**격리와 명확성을 고려한 설계**
|
|
|
|
- 시스템을 명확한 목적을 가진 작은 단위로 나눕니다.
|
|
- 각 단위는 잘 정의된 인터페이스로 통신하고, 독립적으로 이해 및 테스트 가능해야 합니다.
|
|
- 각 단위에 대해 "무엇을 하는가, 어떻게 사용하는가, 무엇에 의존하는가"를 설명할 수 있어야 합니다.
|
|
- 내부 구현을 몰라도 역할을 이해할 수 있어야 하며, 내부를 바꿔도 소비자가 깨지지 않아야 합니다.
|
|
- 파일이 지나치게 커지면 책임이 과도하게 섞였다는 신호로 봅니다.
|
|
|
|
**기존 코드베이스에서 작업할 때**
|
|
|
|
- 변경 제안 전에 현재 구조와 패턴을 먼저 탐색합니다.
|
|
- 현재 작업에 영향을 주는 구조적 문제는 설계에 포함해 개선할 수 있습니다.
|
|
- 현재 목표와 무관한 리팩터링은 제안하지 않습니다.
|
|
|
|
## 설계 제시 규칙
|
|
|
|
- 섹션별로 끊어서 설명하고, 각 섹션 뒤에 확인을 받습니다.
|
|
- 설계는 복잡도에 맞춰 짧게 또는 자세히 조절합니다.
|
|
- 구조, 데이터 흐름, 오류 처리, 테스트 전략을 빠뜨리지 않습니다.
|
|
- 사용자가 "지금까지 맞다"고 확인하기 전까지 다음 단계로 밀어붙이지 않습니다.
|
|
|
|
## 금지 사항
|
|
|
|
- 설계 승인 전에 구현 스킬 호출
|
|
- 설계 승인 전에 코드 작성
|
|
- 질문 여러 개를 한 번에 던지는 방식
|
|
- 대안 비교 없이 단일 해법만 제시하는 방식
|
|
- 현재 목표와 무관한 대형 리팩터링 제안
|
|
- 사용자 검토 없이 바로 구현 계획 또는 구현으로 넘어가는 방식
|
|
|
|
## 설계 후 단계
|
|
|
|
**문서화**
|
|
|
|
- 승인된 설계를 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`에 작성합니다.
|
|
- 사용자가 다른 문서 위치를 선호하면 그 경로를 우선합니다.
|
|
- 가능하면 명확하고 간결한 문체를 유지합니다.
|
|
|
|
**명세 자체 점검**
|
|
|
|
설계 문서를 작성한 뒤 아래 항목을 빠르게 확인합니다.
|
|
|
|
1. **Placeholder 점검** - `TBD`, `TODO`, 미완성 섹션, 모호한 요구사항이 있는지 확인
|
|
2. **내부 일관성 점검** - 섹션끼리 모순되지 않는지 확인
|
|
3. **범위 점검** - 단일 구현 계획으로 충분한 범위인지 확인
|
|
4. **모호성 점검** - 여러 해석이 가능한 요구사항을 하나로 명확히 고정
|
|
|
|
문제가 있으면 문서 안에서 바로 수정하고 진행합니다.
|
|
|
|
**사용자 검토 게이트**
|
|
|
|
설계 검토가 끝나면, 구현 계획으로 넘어가기 전에 사용자에게 작성된 명세 문서를 검토해 달라고 요청합니다.
|
|
|
|
예시 문구:
|
|
|
|
> 명세를 `<path>` 에 작성했습니다. 구현 계획을 쓰기 전에 변경하고 싶은 점이 있는지 검토해 주세요.
|
|
|
|
사용자가 승인할 때까지 기다립니다. 변경 요청이 있으면 수정하고 다시 점검합니다.
|
|
|
|
**구현 전환**
|
|
|
|
- 다음 단계에서는 `writing-plans` 스킬을 호출합니다.
|
|
- 다른 구현 스킬을 먼저 호출하지 않습니다.
|
|
|
|
## 기대 결과
|
|
|
|
이 스킬의 결과물은 다음을 만족해야 합니다.
|
|
|
|
- 사용자 의도가 구조화된 설계 문장으로 정리되어 있어야 합니다.
|
|
- 구현 전에 범위와 성공 기준이 합의되어 있어야 합니다.
|
|
- 설계 문서만 읽어도 다음 단계에서 무엇을 구현할지 알 수 있어야 합니다.
|
|
- 설계 문서는 placeholder 없이 구체적이어야 합니다.
|
|
|
|
## 핵심 원칙
|
|
|
|
- **한 번에 한 질문** - 여러 질문을 한꺼번에 던지지 않습니다.
|
|
- **객관식 우선** - 답하기 쉬운 형식을 우선합니다.
|
|
- **YAGNI 준수** - 불필요한 기능은 설계에서 제거합니다.
|
|
- **대안 비교** - 항상 2~3개의 접근법을 제시합니다.
|
|
- **점진적 검증** - 설계를 제시하고 승인받은 뒤 다음으로 진행합니다.
|
|
- **유연한 명확화** - 이해가 부족하면 다시 질문합니다.
|
|
|
|
## 안티 패턴 신호
|
|
|
|
다음 생각이 들면 흐름을 다시 점검합니다.
|
|
|
|
- 이건 너무 간단해서 설계가 필요 없다
|
|
- 구현하면서 알아가도 된다
|
|
- 사용자 의도는 아마 이럴 것이다
|
|
- 설계 문서는 나중에 써도 된다
|
|
- 구현 스킬부터 불러도 큰 문제는 없다
|
|
|
|
이런 생각은 대부분 브레인스토밍 단계를 건너뛰려는 신호입니다.
|
|
|
|
## 시각 보조 도구
|
|
|
|
목업, 다이어그램, 시각 옵션을 보여주는 브라우저 기반 보조 수단입니다. 이는 별도 모드가 아니라 필요할 때 사용하는 도구입니다.
|
|
|
|
**제안 시점**
|
|
|
|
앞으로의 질문이 시각 요소를 포함할 가능성이 높다면, 아래 문구를 반드시 **단독 메시지**로 제안합니다.
|
|
|
|
> 지금 논의하는 내용 중 일부는 웹 브라우저에서 직접 보여드리면 더 이해하기 쉬울 수 있습니다. 진행하면서 목업, 다이어그램, 비교안 같은 시각 자료를 준비할 수 있습니다. 아직 새 기능이라 토큰 사용량이 많을 수 있는데, 사용해 보시겠어요? (로컬 URL 열기 필요)
|
|
|
|
이 제안 메시지에는 다른 질문, 요약, 설명을 섞지 않습니다. 사용자의 답변을 기다린 뒤 계속 진행합니다.
|
|
|
|
**질문별 판단**
|
|
|
|
사용자가 수락했더라도 모든 질문을 브라우저로 처리하지는 않습니다. 매 질문마다 "읽는 것보다 보는 것이 더 이해하기 쉬운가?"를 기준으로 판단합니다.
|
|
|
|
- 브라우저 사용: 목업, 와이어프레임, 레이아웃 비교, 아키텍처 다이어그램 같은 시각 중심 내용
|
|
- 터미널 사용: 요구사항 질문, 개념적 선택지, 트레이드오프 설명, 범위 결정 같은 텍스트 중심 내용
|
|
|
|
자세한 사용법은 [visual-companion.md](./visual-companion.md)를 참고합니다.
|