--- name: requirements-to-spec description: 사용자가 거친 요구사항, 배경, 불확실한 질문을 가져오거나 제품·기능 문서 작성을 요청할 때 사용합니다. 저장소와 필요한 외부 사실을 조사한 뒤 PRD를 먼저 제시하고, 별도 사용자 메시지의 승인 후 기술 스펙을 작성하며, 다시 별도 승인 후 구현 작업으로 인계합니다. --- # 요구사항에서 스펙 만들기 ## 출력 언어 사용자가 출력 언어를 명시적으로 지정하면 해당 언어를 사용합니다. 지정하지 않으면 이 스킬이 만드는 모든 사용자 대상 출력, 문서, 프롬프트, 보고서, 계획, 스펙 및 기타 산출물을 한국어로 작성합니다. 제목, 섹션, 레이블, 표, 체크리스트, 다이어그램과 템플릿에도 같은 언어를 사용합니다. 코드, 명령어, 파일 경로, 식별자, API 이름, 모델 ID, 프로토콜 이름과 필수 고유명사는 번역하지 않습니다. ## 진행 흐름 1. 요청을 다시 표현하고 `확정`, `조사 필요`, `사용자 결정 필요`, `제외`로 나눕니다. 2. 코드·문서·이력·테스트에서 답을 찾을 수 있는 내용은 사용자에게 묻지 않고 조사합니다. 3. 최신 외부 사실이나 지정 URL이 판단에 필요하면 브라우저로 공식·1차 자료를 확인합니다. 4. `.codex/temp/YYYYMMDD-HHMM-feat--workflow.md`에 조사 결과, 결정, 제외 방향과 다음 단계를 갱신합니다. 5. 요구사항이 정리되면 `prd-writer`로 PRD를 작성합니다. 다음 단계를 막는 열린 질문이 있으면 문서 링크와 함께 질문 전문·선택지·권장안·영향을 대화에 제시하고 현재 턴을 끝냅니다. 6. 이후 별도 사용자 메시지에서 PRD 경로 또는 버전을 확인하며 기술 스펙 작성을 승인받습니다. 열린 질문이 남아 있으면 답변도 함께 확인합니다. 7. 승인 메시지가 먼저 왔더라도 열린 질문을 아직 대화에 제시하지 않았거나 답을 받지 못했다면, 승인 상태는 보존하되 질문을 문서 링크와 함께 먼저 제시하고 현재 턴을 끝냅니다. 8. 열린 질문이 모두 해결된 승인 PRD를 파일에서 다시 읽고 `technical-spec-writer`로 별도 기술 스펙을 작성합니다. 같은 방식으로 다음 단계를 막는 열린 질문을 제시한 뒤 현재 턴을 끝냅니다. 9. 이후 별도 사용자 메시지에서 기술 스펙 경로 또는 버전을 확인하며 구현을 승인받고, 열린 질문의 답변까지 확인한 경우에만 `start-implementation-thread`를 적용합니다. ## 문서 구조 제품·기능 워크플로우의 정식 문서는 책임이 다른 두 파일로 유지합니다. ```text .codex/temp/-prd.md .codex/temp/-technical-spec.md ``` - PRD는 왜 만드는지, 무엇을 만들지, 범위와 수용 기준을 결정합니다. - 기술 스펙은 확정된 PRD를 바탕으로 구현 계약과 검증 방법을 결정합니다. - PRD와 기술 스펙을 한 파일로 합치지 않습니다. ## 승인 규칙 - 제품·기능 요청은 `요구사항 조사 → PRD 제시 → 별도 기술 스펙 승인 → 기술 스펙 제시 → 별도 구현 승인` 순서를 지킵니다. - 열린 질문이 모두 해결되어 승인·취소만 남으면 `../../references/workflow-confirmation-ui.md`에 따라 버튼형 승인 카드를 제시합니다. 버튼이 게시한 후속 메시지는 별도 사용자 승인 메시지로 처리합니다. - 다음 단계를 막는 열린 질문은 문서에만 두지 않습니다. 해당 문서의 절대 경로 링크와 함께 질문 전문, 선택지, 현재 권장안과 선택 영향을 사용자 대화에 먼저 제시합니다. - 사용자가 문서를 승인했더라도 아직 제시하거나 답받지 않은 열린 질문이 있으면 다음 단계로 넘어가지 않습니다. 기존 승인을 취소하지 않고 질문 답변만 추가로 받습니다. - `승인`은 열린 질문의 권장안을 자동 선택한다는 뜻이 아닙니다. 질문을 대화에 제시한 뒤 사용자가 `권장안대로 승인`이라고 답한 경우에만 제시된 모든 권장안을 일괄 선택한 것으로 기록합니다. - 사용자는 `권장안대로 승인`하거나 질문 ID별로 직접 답할 수 있습니다. 직접 답한 결정은 문서에 반영한 뒤 다음 단계의 입력으로 사용합니다. - 최초 요청의 `PRD와 스펙 작성 후 구현해줘` 같은 미래형 문장은 다음 단계의 승인으로 인정하지 않습니다. - 가능성 검토나 설계 토론 뒤 사용자가 구현 방향을 채택한 표현도 기술 스펙 또는 구현 승인으로 인정하지 않습니다. 승인 대상 문서와 변경 범위를 제시한 뒤 별도 승인받습니다. - 처음부터 `구현해줘`, `수정해줘`, `바로 진행해줘`라고 요청해도 PRD·기술 스펙·구현의 각 범위를 제시하기 전 승인으로 소급하지 않습니다. - 구현 승인은 제시된 기술 스펙의 경로 또는 버전을 확인한 별도 사용자 메시지에서 받습니다. - 조사 중 발견한 별도 버그, 독립 리팩터링과 요청하지 않은 기능은 구현 범위에 포함하지 않습니다. - 삭제, 배포, 외부 전송, 결제, 권한 변경과 비가역 데이터 변경은 해당 행동 직전에 대상과 영향을 확인합니다. ## 완료 점검 - [ ] 사용자가 설명하지 않아도 확인 가능한 사실을 직접 조사했는가 - [ ] PRD와 기술 스펙을 책임이 다른 문서로 작성했는가 - [ ] PRD를 제시한 턴에서 기술 스펙을 이어서 작성하지 않았는가 - [ ] 기술 스펙을 제시한 턴에서 구현을 시작하지 않았는가 - [ ] 별도 사용자 메시지의 승인 대상 경로 또는 버전을 확인했는가 - [ ] 다음 단계를 막는 열린 질문을 문서 링크와 함께 대화에 먼저 제시했는가 - [ ] `승인`을 열린 질문의 권장안 일괄 선택으로 오해하지 않았는가 - [ ] 열린 질문의 답변을 승인 문서에 반영한 뒤 다음 단계로 넘어갔는가 - [ ] 요청과 직접 관련 없는 변경을 구현 범위에 포함하지 않았는가 - [ ] 탐색·설계 대화의 방향 채택을 구현 승인으로 확대하지 않았는가