메뉴
새 feature의 외부 관찰 가능한 동작(WHAT)을 사용자와 대화하며 spec.md로 확정한다. 요구사항이 모호하거나 여러 화면·경로에 걸친 다단계 feature를 정의하려는 신호가 보이면 트리거한다. 버그 수정, 한 줄 변경, 이미 구체적인 요구에는 쓰지 않는다. "/write-spec", "스펙 작성", "기능 정의"로도 호출한다.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | write-spec |
| description | 새 feature의 외부 관찰 가능한 동작(WHAT)을 사용자와 대화하며 spec.md로 확정한다. 요구사항이 모호하거나 여러 화면·경로에 걸친 다단계 feature를 정의하려는 신호가 보이면 트리거한다. 버그 수정, 한 줄 변경, 이미 구체적인 요구에는 쓰지 않는다. "/write-spec", "스펙 작성", "기능 정의"로도 호출한다. |
| argument-hint | feature description |
새 feature의 외부 관찰 가능한 동작(WHAT)을 사용자와 대화하며 확정한다.
spec은 시스템을 블랙박스로 놓고, 그 경계면에서 "완료"를 판정하는 기준에 사용자와 합의하는 문서다. spec의 판정 기준이 유일한 원본이 되고, plan과 테스트는 ID로 이를 참조한다.
| 입력 | 출력 |
|---|---|
$ARGUMENTS (feature 설명), 참조 이미지는 artifacts/<feature>/references/에 | artifacts/<feature>/spec.md (WHAT 전용 스펙) |
구현 선택(파일 배치, 스키마, 라이브러리, 테스트 유형)은 spec.md에 넣지 않는다. 그 결정은 plan.md의 몫이다. 경계를 지키지 않으면 구현을 바꿀 때마다 spec을 고치게 된다.
이미 내린 결정을 뒤집지 않기 위해, 질문을 시작하기 전에 존재하는 맥락을 읽는다.
순서:
artifacts/<feature>/idea.md: 이미 결정된 방향과 원칙artifacts/<feature>/spec.md: 이전 논의 기록 (있다면)artifacts/<feature>/references/: 참조 자료가 있다면 구조와 정보 계층 파악완전히 새로운 feature라 1~3이 없으면 4부터 시작한다.
질문하기 전에 두 가지를 사용자에게 보여주고 확인받는다. 코드를 쓰기 전에 오해를 드러내기 위해서다.
내가 지금 가정하고 있는 것:
1. 로그인한 사용자만 대상 (게스트 지원 안 함)
2. 모바일·데스크톱 동시 지원
재진술 (모호 → 측정 가능):
- "대시보드를 빠르게" → 4G에서 LCP < 2.5s, 초기 데이터 < 500ms
→ 이대로 진행할까요, 아니면 바로잡을까요?
요구사항이 이미 구체적이면 재진술 블록은 생략한다. 가정은 항상 보여준다. "가정 없음"이라도 그렇게 적는다.
$ARGUMENTS에 대한 사용자 흐름을 시뮬레이션하며 빈칸을 찾는다.
시뮬레이션 순서:
사용자가 관찰할 수 있는 것(WHAT) 만 묻는다. 파일 경로, 레이어 배치, 테이블 설계, 테스트 전략은 plan.md에서 결정한다.
idea.md, 이전 spec.md에 있을 수 있다references/spec-template.md의 섹션 구조를 따른다. 형식, ID 규칙, 판정 기준 작성 가이드는 template에 있다.
S1, S1-1, INV-1)로 참조한다. 원본이 하나여야 수정할 곳도 하나다.| 문장 | 판정 | 이유 |
|---|---|---|
| 사용자가 이메일로 로그인하면 대시보드로 이동한다 | OK | 관찰 가능한 입력 → 관찰 가능한 결과 |
/api/login 엔드포인트가 JWT를 반환한다 | NG | 구현 수단. plan.md 소관 |
| 완료된 할 일에는 취소선이 표시된다 | OK | 외부에서 보이는 상태 |
Zustand store의 todos가 업데이트된다 | NG | 내부 상태 |
파일명: artifacts/<feature>/spec.md
spec이 확정되면 다음 단계를 새 세션(/clear)에서 시작한다 (필요한 상태는 spec.md가 전부 들고 있다):
/sketch-wireframe <feature>/draft-plan <feature>여러 feature에 쌓인 `artifacts/*/learnings.md`를 정리한다 — 중복 병합, 충돌 해소, 낡은 항목 폐기, hypothesis 확정. 승격은 하지 않는다. learnings.md가 여러 feature에 쌓였을 때 트리거하고, 단일 feature 진행 중에는 쓰지 않는다. "/compound", "회고", "메모리 정리"로도 호출한다.
spec.md를 기반으로 구현 계획(artifacts/<feature>/plan.md)을 작성한다. 여러 파일에 걸치거나 시나리오가 서로 의존하는 product feature에 쓴다. 한 세션에 끝나는 작업·meta-tooling·명백한 변경은 내장 plan 모드로 한다. "/draft-plan", "draft plan", "계획 작성", "구현 계획"으로도 호출한다.
확정된 artifacts/<feature>/plan.md의 Task를 TDD로 하나씩 구현하고 Task당 한 커밋을 만든다. 사용자가 "이제 구현 시작", "플랜 실행" 같은 신호를 보낼 때 트리거한다. plan.md 없이 바로 구현하는 경우에는 쓰지 않는다. "/execute-plan", "플랜 실행", "구현 시작"으로도 호출한다.
날것의 아이디어를 실행 가능한 one-pager(artifacts/<feature>/idea.md)로 다듬는 옵션 모듈. 아이디어가 막연하거나 MVP 범위·추진 방향을 정해야 할 때("이거 괜찮을까?", "뭘 먼저 만들지?") 트리거한다. 요구사항이 이미 구체적이면 건너뛰고 /write-spec으로 간다. "/idea-refine", "아이디어 정리", "ideate"로도 호출한다.
spec.md를 기반으로 HTML 와이어프레임을 생성하는 옵션 모듈. 레이아웃 구조가 바뀌는 UI feature(새 화면, 새 레이아웃, 화면 간 흐름)에 사용한다. 서버·데이터 전용 변경이나 레이아웃이 그대로인 변경에는 쓰지 않는다. "/sketch-wireframe", "wireframe", "와이어프레임", "레이아웃 확인"으로도 호출한다.