아이디어를 설계로 브레인스토밍하기

개요

자연스러운 협업 대화를 통해 아이디어를 완전한 설계와 명세로 전환할 수 있도록 돕습니다.

먼저 현재 프로젝트 컨텍스트를 이해한 후, 적응형 배칭을 사용하여 질문을 던져 아이디어를 구체화합니다. 무엇을 구축할지 이해했다고 판단되면 설계를 제시하고 사용자 승인을 받습니다.

안티패턴: "이건 설계가 필요 없을 정도로 간단해"

모든 프로젝트는 이 프로세스를 거칩니다. 할 일 목록, 단일 함수 유틸리티, 설정 변경 — 모두 포함됩니다. "단순한" 프로젝트일수록 검증되지 않은 가정으로 인해 가장 많은 작업이 낭비됩니다. 설계는 짧을 수 있지만(정말 단순한 프로젝트의 경우 몇 문장) 반드시 제시하고 승인을 받아야 합니다.

체크리스트

다음 각 항목에 대한 태스크를 생성하고 순서대로 완료해야 합니다:

프로젝트 컨텍스트 탐색 — 파일, 문서, 최근 커밋 확인
명확화 질문 — 적응형 배칭: 관련 질문을 그룹화하여 왕복 횟수 감소, 후속 질문은 대상 단일 질문 사용
2-3가지 접근 방식 제안 — 장단점 및 권장 사항 포함
설계 발표 — 복잡도에 따라 섹션 크기 조정, 각 섹션마다 사용자 승인 획득
설계 문서 작성 — docs/plans/YYYY-MM-DD-<주제>-design.md에 저장하고 커밋
구현으로 전환 — writing-plans 스킬을 호출하여 구현 계획 생성

프로세스 흐름

digraph brainstorming {
    "프로젝트 컨텍스트 탐색" [shape=box];
    "명확화 질문" [shape=box];
    "2-3가지 접근 방식 제안" [shape=box];
    "설계 섹션 발표" [shape=box];
    "사용자가 설계 승인?" [shape=diamond];
    "설계 문서 작성" [shape=box];
    "writing-plans 스킬 호출" [shape=doublecircle];

    "프로젝트 컨텍스트 탐색" -> "명확화 질문";
    "명확화 질문" -> "2-3가지 접근 방식 제안";
    "2-3가지 접근 방식 제안" -> "설계 섹션 발표";
    "설계 섹션 발표" -> "사용자가 설계 승인?";
    "사용자가 설계 승인?" -> "설계 섹션 발표" [label="아니오, 수정"];
    "사용자가 설계 승인?" -> "설계 문서 작성" [label="예"];
    "설계 문서 작성" -> "writing-plans 스킬 호출";
}

최종 상태는 writing-plans 호출입니다. frontend-design, mcp-builder 또는 다른 구현 스킬을 호출하지 마십시오. 브레인스토밍 후 호출하는 유일한 스킬은 writing-plans입니다.

프로세스

아이디어 이해:

먼저 현재 프로젝트 상태 확인 (파일, 문서, 최근 커밋)
적응형 배칭을 사용한 질문 — 관련 질문을 그룹화하여 왕복 횟수 감소:
- 첫 번째 배치: 목적, 제약 조건, 범위, 기술 선택 포함
- 후속 질문: 흥미롭거나 모호한 답변에 기반한 대상 단일 질문
<host: claude-code>
- 가능하면 객관식 옵션 사용 (AskUserQuestion은 질문당 2-4개 옵션 지원)
- AskUserQuestion은 폼당 최대 4개 질문 지원 — 이를 사용하여 왕복 횟수 감소
<host: codex, opencode, cursor>
- 옵션을 번호 목록으로 제시하고 사용자에게 선택한 번호로 답변 요청
- 채팅 과부하를 방지하기 위해 턴당 최대 3개 질문으로 그룹화
목적, 제약 조건, 성공 기준 이해에 집중

접근 방식 탐색:

장단점이 있는 2-3가지 접근 방식 제안
권장 사항과 그 이유를 포함하여 대화식으로 옵션 제시
권장 옵션을 먼저 제시하고 이유 설명

설계 발표:

구축할 내용을 이해했다고 판단되면 설계 제시
각 섹션의 크기를 복잡도에 맞게 조정: 간단하면 몇 문장, 복잡하면 최대 200-300 단어
각 섹션 후에 지금까지 올바른지 확인
다루어야 할 내용: 아키텍처, 컴포넌트, 데이터 흐름, 오류 처리, 테스트
이해되지 않는 부분이 있으면 다시 돌아가서 명확히 할 준비

설계 전용 모드

사용자가 실행 없이 설계 탐색만 원할 경우 브레인스토밍에 --design-only를 전달합니다.

--design-only 동작:

전체 브레인스토밍 흐름 실행 (컨텍스트 탐색 → 질문 → 접근 방식 → 설계 → 설계 문서 작성 → 커밋).
writing-plans 호출 시 --design-only 플래그를 전파합니다.
writing-plans는 플래그를 존중합니다: 정렬 검사 통과 → 중지 (실행 디스패치 안 함). 정렬 실패 시 writing-plans는 일반 실패 처리 방식대로 수정 및 재검사 후 중지 — 여전히 실행 디스패치 안 함. 지속적 실패 시 (최대 2회 수정 주기 후) 해결되지 않은 차이 요약과 함께 사용자에게 에스컬레이션 — 실행 디스패치 안 함.
파이프라인은 커밋된 설계 문서 + 계획으로 docs/plans/에 종료됩니다.

기본값 (플래그 없음): 브레인스토밍 → writing-plans → 정렬 검사 → 하위 에이전트 주도 개발 → … (자율적 핸드오프).

설계 이후

문서화:

검증된 설계를 docs/plans/YYYY-MM-DD-<주제>-design.md에 작성
가능하면 elements-of-style:writing-clearly-and-concisely 스킬 사용
설계 문서를 git에 커밋

자율적 핸드오프:

이것은 사용자의 마지막 상호작용 지점입니다 — 이후 모든 것은 자율적으로 실행됩니다.
자율적 컨텍스트와 함께 writing-plans 스킬을 호출: 설계가 승인되었으며 추가 사용자 입력이 필요 없음을 전달
writing-plans 스킬은 Claude Code의 Plan Mode를 선호하며(가능한 경우), 다른 환경에서는 내장된 계획 프로세스로 대체합니다.
이 지점부터의 파이프라인: writing-plans → 정렬 검사 → 팀 실행 → PR 생성 → PR 모니터링
다른 스킬을 호출하지 마십시오. writing-plans가 다음 단계입니다. 나머지 자율적 파이프라인을 처리합니다.

핵심 원칙

적응형 질문 배칭 - 관련 질문을 그룹화하여 왕복 횟수 감소, 후속 질문은 대상 단일 질문 사용
객관식 선호 - 가능할 때 개방형보다 답변하기 쉬움
YAGNI 엄격히 적용 - 모든 설계에서 불필요한 기능 제거
대안 탐색 - 최종 결정 전에 항상 2-3가지 접근 방식 제안
점진적 검증 - 설계를 발표하고 진행 전에 승인 획득
유연성 유지 - 이해되지 않는 부분이 있으면 돌아가서 명확히 함
설계 승인 = 자율성 핸드오프 - 설계 승인 후 파이프라인은 사용자 입력 없이 실행됨

Claude Superpowers