Write TechSpec
docs/specs/<slug>/_techspec.md를 생성합니다 — 사양 요구 사항에 대한 기술적 답변입니다. PRD는 무엇과 왜를 정의했습니다. 이 문서는 어떻게, 어디에, 무엇으로를 결정하며, 이 문서의 빌드 순서(Build Order)는 write-tasks가 작업 그래프로 변환하는 대상이므로, 여기서의 시퀀싱 품질이 나중의 실행 품질이 됩니다.
사전 조건 — 두 가지 진입 모드
$ARGUMENTS는 사양(slug 또는 경로)을 명명하거나 리팩터/버그 수정을 설명합니다. 제품 동작 변경 여부에 따라 모드를 선택합니다:
- 기능 작업(제품 동작 변경) —
docs/specs/<slug>/_prd.md가 존재해야 합니다. 그렇지 않으면 중단하고 사용자에게write-prd를 안내합니다. 제품 결정에는 먼저 제품 대화가 필요합니다. PRD에 여기에 속하는 낮은 수준의 기술 결정이 포함된 경우, 이를 발견 사항으로 표면화하고 무음 복제 대신 재배치를 제안합니다. - 리팩터 또는 버그 수정(제품 동작 변경 없음) — 이 스킬이 파이프라인 진입점입니다. PRD 인터뷰는 없습니다. 사양 폴더가 아직 없으면
write-prd의 번호 매기기 규칙(<spec-root>/NNNN-<kebab-slug>/, 구성된 Spec Root 및 해결된 아카이브 디렉토리(기본 제공docs/specs루트의 경우docs/history/specs/, 그렇지 않은 경우<spec-root>/_archived/)를 스캔하여 가장 높은 접두사를 찾음)에 따라 폴더를 생성하고, 다운스트림 스킬이 구문 분석하는 계약만 포함하는 **최소_prd.md**를 작성합니다: 머리말(spec,status: active,surfaces, 버그 수정의 경우type: fix또는 리팩터의 경우type: refactor), 문제 설명, 프로젝트 제약 조건, 목표, 핵심 기능, 비목표, 그리고## Decisions아래의 명확화 기록(Clarification Record) — 엔지니어링 관점에서 몇 줄씩입니다. 기록은 write-prd의 명확화 가이드를 따릅니다: 사람이 답변한 질문당 하나의- YYYY-MM-DD: <질문> — <답변>줄, 또는 사람이 없을 때 저자의 결정 출처를 명명하는Autonomous route: no person present; decisions taken from <source>.입니다. 이는write-tasks,qa-gate,archive-spec이 단일 아티팩트 계약을 유지하기 위해 존재합니다. 제품 문서가 아닙니다.