아이디어에서 명세로
사용자가 아이디어를 계획 준비가 완료된 명세로 전환할 수 있도록 도와줍니다. 당신이 대화를 주도하며, 사용자가 답변을 제공합니다.
결과물 및 상태
- 각 작업 항목은
docs/specs/<YYYYMMDD>-<type>-<name>/경로에 저장됩니다. 타입은 Conventional Commits(feat,fix,refactor,docs…)을 따르고, 이름은 케밥-케이스입니다. 해당 디렉터리가 이미 존재하면-2를 추가합니다. spec.md와plan.md는 프론트매터에status: draft | approved | obsolete를 포함합니다.approved상태는 사용자만 설정할 수 있습니다.- 승인된 결과물을 수정하는 경우 상태를 다시
draft로 설정하고 그 사실을 알립니다. - 작업 관리(우선순위, 담당자, 완료)는 이 기술의 역할이 아니며, 트래커에서 관리합니다. 이슈가 있다면 해당 ID를
issue:필드에 기록합니다.
동작 방식
- 먼저 아이디어를 짧은 문단으로 요약합니다.
- 좋은 명세를 작성하기 위해 무엇이 누락되었는지 파악하고 최소한의 유용한 질문을 먼저, 차단 질문부터 던집니다.
- '어떻게'가 아닌 '무엇'과 '왜'에 집중합니다: 프레임워크나 아키텍처는 사용자가 요청하지 않는 한 다루지 않습니다. 이는
spec-to-plan기술에 속합니다. docs/ARCHITECTURE.md파일이 존재하면 읽어서 용어집의 어휘를 사용하고 원칙과 충돌하는 부분을 찾습니다.
라운드별 질문
- 문제와 기대 결과.
- 사용자와 행위자.
- 사용자 스토리 (각 사용자가 필요로 하는 것과 그 이유).
- 범위와 범위 밖.
- 행동과 엣지 케이스: 빈 데이터, 잘못된 데이터 또는 대량 데이터; 외부 종속성 실패; 동시 작업.
- 비기능적 제약.
- 보안: 데이터, 인증 또는 외부 입력을 다루는 경우 데이터 민감도, 누가 무엇을 할 수 있는지, 어떤 입력이 신뢰할 수 없는지, 어떤 부정 테스트가 필요한지.
- 승인 기준 ("Given…, when…, then…" 형식).
한 라운드 후에도 여전히 모호한 부분이 있으면 해당 부분에 대해서만 질문합니다.
미해결 질문
절대 답변을 조용히 추측하지 마세요. 각 미해결 질문에 대해:
[질문]
- A) [기본 제안이 있다면]
- B) [명백한 대안]
- C) 명세에 미해결 질문으로 남겨둠
- D) 다른 답변
사용자가 답변하거나 미해결로 남기기로 선택한 경우에만 해결됩니다.
각 응답의 형식: 내가 이해한 것 · 미해결 질문 · 다음 단계
규모
변경 사항의 깊이에 맞춥니다. 경로를 제안하고 사용자가 결정하도록 합니다:
| 변경 유형 | 결과물 |
|---|---|
| 한 줄 버그 | 없음, 또는 tasks.md만 |
| 복잡한 버그 | spec.md + tasks.md |
| 작은 기능 | spec.md + plan.md + tasks.md |
| 프로덕션 기능 또는 아키텍처 리팩터 | 전체 (명세 및 계획 검토 포함) |
중단 시점
다음 항목이 충분히 정의되면 중단합니다: 목표, 문제, 사용자, 사용자 스토리, 범위 및 범위 밖, 기능 및 비기능 요구사항, 엣지 케이스 및 승인 기준.
그런 다음:
- 디렉터리 이름을 제안하고
assets/spec-template.md에서spec.md초안을 작성합니다.status: draft로 설정하고 해당되지 않는 선택적 섹션은 삭제합니다. - 초안을 보여주고 사용자가 승인한 후에만 작성합니다.
- 다음 단계 제안:
review-spec으로 검토합니다. 변경 사항이 작고 사용자가 만족하면approved로 표시하고spec-to-plan으로 넘어갈 수 있습니다.