--- name: sd-spec description: SI/업무시스템 요구사항을 분석해 spec.md 로 구조화 — 초안 배치(요건→설계 순차 빌드) + init 배치(코드-first 역작성 + [구현] 마킹) + 부분 수정 인라인 처리. Use when "요구사항 분석", "SI 분석", "업무시스템 spec 작성", "/sd-spec init" 을 요청할 때. --- # sd-spec 요구사항을 분석하여 spec.md 1개로 산출. 최우선 목적 = 정확한 spec (환각 차단·누락 차단). 연산 단위로 채워나감 — 호출 1회 = 연산 1개, spec.md 라는 영속 산출물에 대한 연산의 모음. ## 입출력 - **Input**: Requirement Source (회의록·메일·문서·PDF·발화 등 비정형 자료) + 사용자와의 대화 + (재진입 시) 기존 spec.md. - **Output**: spec.md 1개 (후속 도구 sd-impl·sd-demo 의 입력 계약). - **폴더**: `.specs/{yyMMddHHmmss}_{slug}/`. - `yyMMddHHmmss`: 현재 시각을 이 형식으로 생성 (예: `260513204500` = 2026-05-13 20:45:00; PowerShell `Get-Date -Format "yyMMddHHmmss"`, bash `date +%y%m%d%H%M%S` 등). - `slug`: 짧은 한·두 단어. 허용 문자는 한글·영문·`_`·`-`·공백 (그 외 문자는 금지). ## 연산 sd-spec 은 3종의 연산으로 동작. 사용자 지시를 받으면 아래 디스패치로 분기. 작성은 배치로 한 번에 하고, 사용자가 사후 검토(검토 패키지)로 정정. ### 디스패치 | 지시 유형 | 연산 | 처리 경로 | | ----------------------------------------------------- | ----------- | --------------------------------------------- | | "분석해줘"·"요구사항 분석"·"초안 작성"·"spec 작성" 류 (신규 spec.md 작성) | 초안 배치 | 메인 에이전트가 직접 순차 수행 (아래 "초안 배치") | | arg `init` (`/sd-spec init [범위]`) — 기존 코드베이스를 근거로 신규 spec.md 역작성 | init 배치 | 메인 에이전트가 직접 순차 수행 (아래 "init 배치") | | 그 외 모든 지시 ("X를 Y로"·"A를 B와 합쳐"·"이 섹션 이상해"·"설계만 다시"·재진입 정정) | 부분 수정 | SKILL.md 인라인 처리 (아래 "부분 수정") | - 초안 배치·init 배치는 메인 에이전트가 자율 진행. 실행 중 사용자에게 묻지 않음 (모르면 [OPEN]) — requirement-source-handling.md 의 "사용자에게 즉시 확인" 항목도 배치 중에는 [OPEN] + 검토 패키지 보고로 대체 (부분 수정 등 대화형 연산에서는 원문대로 즉시 확인). - 초안 배치·init 배치는 **신규 spec.md 작성 전용**. 기존 spec.md 가 있는 재진입(부분 재작업·정정·"설계만 다시")은 모두 부분 수정 경로. - arg `init` 없이 "코드(베이스) 기반 spec 작성"·"현황 spec 화" 류 발화만 온 경우: init 배치 의도로 추정하되 **진입 전 사용자 확인 필수** — 확인 없이 init 배치 진입 금지. ### 초안 배치 (메인 직접 순차 수행) 신규 spec.md 작성 지시("분석해줘"·"초안 작성"·"spec 작성" 류). 메인 에이전트가 spec.md 를 **한 줄기로 순차 빌드**함 (코딩하듯 — 앞 단위가 만든 §7·§8·§9 를 뒤 단위가 재사용·확장). 작성은 전부 메인 직접, **검증만 독립 서브에이전트**. **준비**: - 폴더·경로: "입출력" 의 폴더 규칙으로 신규 `.specs/{yyMMddHHmmss}_{slug}/spec.md` 경로를 만들고, "spec.md 골격" 으로 골격(§1~§10 빈 헤더)을 작성. - 시스템명: 사용자와 합의한 시스템명(제목 `{name}`). 날짜: 현재 날짜를 `yyyy-MM-dd` 로 (§10 로그 타임스탬프용; PowerShell `Get-Date -Format "yyyy-MM-dd"`, bash `date +%F` 등). 자료(Requirement Source)는 직접 읽음. **단계 (직렬 — 각 단계는 그 시점에 확정된 것만 다룸)**: 1. **요건 (§1~3 + §7)**: `references/format.md` 의 요건·공통 작성법(§1·§2·§3·§7)을 읽고, 공유 형식은 본 SKILL.md 의 "spec.md 형식" 절을 따름. 자료를 직접 읽어 §1 개요·§2 업무 프로세스(pivotal event 로 §2/§3 분할)·§3 기타 요구를 작성. 작성 중 나오는 도메인 어휘·공통 규격은 §7 에 누적. **§4~9 는 빈 헤더로 두고 손대지 않음** (설계 단계 이전이므로). 비자명 항목엔 근거, 모르면 [OPEN]. 2. **설계 (§4~6 순차 빌드 + §8·§9·§7 점진 누적)**: `references/format.md` 의 설계 작성법(§4~9)을 읽음. §1~3·§7 을 입력으로 §4 화면 → §5 자동 처리 → §6 공통·기반 의 단위를 **하나씩 순차로** 작성. 각 단위(§4.x 등)를 작성하면서 그 단위가 참조하는 §8 도메인 모델·§9 외부 인터페이스를 **그 자리에서 즉시 spec 에 추가·갱신** (없으면 신설, 있으면 재사용·필드 확장)하고, 새 용어는 §7 에 누적. §4 첫머리 화면 목록 표도 단위가 늘 때마다 갱신. 별도 "집계" 단계는 없음 — 누적이 곧 §8·§9 작성임 (§8·§9 불변식은 "섹션 구조" 절 참조). 3. **검증 (독립 서브에이전트, 규모 비례)**: 작성 완료 spec 을, 작성한 메인이 아닌 **독립 서브에이전트로 검증**함 (자기검증 편향 차단). 검증 항목 — ① 근거 좌표 1:1 실재 대조(원자료 재독), ② 원자료↔spec 전수 누락 역대조 + 자료 커버리지, ③ 요구 커버리지(요건 → §4~6 역대조), ④ dangling 참조 검색. 규모(자료 수·근거 수)에 비례해 항목별/자료별로 서브에이전트를 병렬로 펼치되, 대상이 아주 작으면 메인 직접도 허용. 근거 위조로 판정된 항목은 `(근거: …)` 를 떼고 [OPEN] 으로 강등(원 좌표는 메모로 보존). 4. **검토 패키지 + 정지**: "연산 사이 검토" 의 검토 패키지를 제시하고 정지. ### init 배치 (코드-first) 기존 코드베이스를 Requirement Source 로 삼아 신규 spec.md 를 역작성하고, §4~6 각 단위를 코드와 대조 검증 후 `[구현]` 마킹. 코드가 결정 근거 — 대조 차이는 전부 spec 수정으로 해소. **범위**: `init` 뒤에 범위(앱·패키지·경로)가 오면 그 범위로 한정, 없으면 전체 코드베이스. 코드 조사는 워킹트리 파일을 직접 읽기·검색으로만 수행. **준비**: 초안 배치 준비와 동일 (폴더·골격·시스템명·날짜). 자료 = 분석 범위의 코드. **단계 (직렬)**: 1. **요건 (§1~3 + §7)**: 초안 배치 1단계와 동일하되 자료 = 코드. 라우트·화면·처리 흐름에서 업무 프로세스를 역추론해 작성. 역추론 항목은 전부 비자명 취급 — `(근거: <파일 경로[:라인]>)` 부착, 추론 한계(업무 의도·왜)는 [OPEN]. 2. **설계 (§4~6 + §8·§9·§7)**: 초안 배치 2단계와 동일하되, 단위·항목·동작·로직을 코드에서 직접 도출. 코드에 없는 동작 작성 금지. 3. **전수 커버리지 역대조 (독립 서브에이전트)**: 코드의 화면·라우트·자동 처리·공통 기능 전수 목록 ↔ §4~6 단위 목록을 역대조 — spec 에 단위 자체가 없는 누락 발견. 누락 발견 시 2단계로 회귀해 단위 추가 후 재대조. 4. **단위 검토 + `[구현]` 마킹**: §4.x/§5.x/§6.x 단위마다 검토 서브에이전트 1개를 병렬 실행. 서브에이전트는 **보고 전용** — spec.md 를 수정하지 않음. prompt 는 아래 "단위 검토 서브에이전트 prompt". - 보고 처리 (메인이 일괄 편집 — 차이는 전부 spec 수정으로 해소): - (a) 코드 위반 → spec 작성 오류. 문서를 코드에 맞게 수정. - (b) spec 내부 모순 → 코드 기준으로 정정. - (c) spec 미정의 + 코드 채움 → 코드 동작을 spec 에 추가. - 수정한 단위만 재대조 서브에이전트 재실행. **차이 0건 단위의 헤더에 `[구현]` 부착** (테스트·시연 불요 — 기존 운영 코드는 동작하는 것으로 간주). 코드로 확인 불가한 [OPEN] 항목이 남은 단위는 마킹 보류. 5. **검증 (독립 서브에이전트)**: ① 근거 좌표(파일 경로·라인) 실재 대조, ② dangling 참조 검색. (초안 배치 3단계의 번안 — 누락 역대조는 3단계가 수행, 요구 커버리지는 §1~3 자체가 §4~6 역추론이므로 생략.) 6. **검토 패키지 + 정지**: "연산 사이 검토" 동일. #### 단위 검토 서브에이전트 prompt 아래를 그대로 복사 후 `<…>` 만 채움: ```` sd-spec init 배치의 spec ↔ 코드 단위 대조를 수행해줘. **대상**: - spec.md 경로: <절대경로> - 단위 식별자: <§4.x / §5.x / §6.x> - 코드 분석 범위: <경로 목록 또는 "전체"> **작업**: 1. spec.md 의 §<단위> 본문 + 그 본문이 참조하는 §5/§6/§7/§8/§9 항목을 읽기. 2. 분석 범위에서 해당 단위를 구현하는 코드를 직접 검색해 찾아 모두 읽기. 3. spec ↔ 코드를 항목(필드·동작·분기·계산식) 단위로 1:1 대조. 4. 차이 발견 시 아래 3분류로 보고: - (a) **코드 위반**: spec 에 적혔는데 코드에 없거나 다름. - (b) **spec 내부 모순**: §A 정의 vs §B 정의 충돌. (양쪽 인용 명시) - (c) **spec 미정의 + 코드 존재**: 코드 동작인데 spec 본문에 정의·분기·경계 케이스 명시 없음. 5. 보고 형식 (각 차이 1건마다): ### 차이 N: <도메인 어휘로 표현된 한줄 요약> - 분류: (a) / (b) / (c) - spec 위치: §X.x line Y - spec 인용: "..." - 코드 위치: - 코드 동작: <도메인 어휘로> 6. 코드로 존재·동작을 확인할 수 없는 spec 항목(외부 연동 동작 등)은 "확인 불가" 로 별도 목록 보고. 7. 차이 0건 + 확인 불가 0건이면 `차이 없음, 검증 통과` 1줄만 응답. **제약**: - 파일 수정 금지 — 보고 전용. - 보고 본문에 코드 식별자(변수명·SQL 함수명·타입 키워드 등) 노출 금지. 도메인 어휘로 풀어 쓸 것. ```` ### 부분 수정 (인라인) 초안 배치·init 배치(신규 spec.md 작성) 외의 모든 지시는 SKILL.md 가 메인 에이전트로 직접 처리. 재진입(기존 spec.md 에 대한 추가 작업 — "설계만 다시"·재설계 포함)도 이 경로. **입력 spec.md 읽기 범위**: 기존 spec.md 에 대한 작업이므로 부분 수정 착수 전 ① 수정 대상 § 본문 → ② 그 본문이 이름 기반 참조(`[화면.X]`·`[모델.X]`·`[공통 정의.X]` 등 "본문 내 참조")로 가리키는 § 를 재귀적으로(참조의 참조까지) → ③ §10 본문 외 확정 사항 전체 를 읽음. 다른 세션이 누적한 결정·제약은 전역이면 §10·단위 한정이면 그 단위의 진행방법 NOTE 나 인라인 `[OPEN]` 에 모이도록 형식("신뢰도 표기"·"진행 방법 누적" 절)이 규정함. 부분 검색·부분 읽기로 대상 § 만 보고 §10·참조 § 를 빠뜨리지 않음. - **정밀 지시** ("§4.2 의 X 컬럼을 Y로", "이 항목 [OPEN] 으로") → 바로 편집. 무관 섹션은 건드리지 않음 (일괄 치환 금지 — 편집 대상을 유일하게 좁혀서 수정). - **모호 지적** ("이 섹션 이상해", "여기 흐름이 안 맞아") → 무엇이 문제인지 진단을 먼저 제시 → 사용자 합의 → 편집. 추측으로 바로 고치지 않음. - **구조 변경** (병합·분할·추가: "A 화면과 B 화면을 합쳐", "이 프로세스를 둘로 나눠") → 이름 기반 참조 cascade: - `[화면.X]`·`[모델.X]`·`[프로세스.X]` 등 이름 기반 참조("본문 내 참조" 절)를 검색으로 전수 추적해, 병합·분할·삭제로 끊기는 참조를 함께 갱신. - § 번호는 자주 바뀌므로 이름으로 추적. 변경 후 dangling 참조가 남지 않게 확인. - **구현 마커 제거** (§4~6 자신 또는 그 의존 § 를 수정한 경우) → 아래 "§4~6 `[구현]` 마커 제거" 절을 따라 영향 §4~6 의 `[구현]` 마커를 제거. - 작성 형식·신뢰도 표기는 아래 "작성 원칙" 과 **대상 섹션의 작성법** (아래 "§별 작성법" 절에 따라 references/format.md 의 대상 § 작성법을 읽기) 을 따름. ### §4~6 `[구현]` 마커 제거 §4.x/§5.x/§6.x 본문이나 그 본문이 의존하는 § 를 수정했을 때, 그 §4~6 헤더의 `[구현]` 마커를 제거할지 판정. sd-spec 부분 수정·sd-impl spec 수정 양쪽이 따르는 단일 출처(sd-impl 은 지금 재구현 중인 본 단위는 제외). **의존 식별** — §4.x/§5.x/§6.x 본문에 다음이 나타나면 그 §의 의존 대상: - `관련 섹션:` 줄의 `[프로세스.X]`·`[기타.X]`·`[화면.X]`·`[자동 처리.X]`·`[기반.X]`·`[외부 인터페이스.X]`. - 본문 어디든 등장하는 `[모델.X…]`·`[공통 정의.X]`. - §7 외부 자료 명세를 컬럼명 일치로 끌어다 쓴 양식 매핑 표(해당 §7.x). - 모달 호출 `→ [화면.X]` 의 그 §4.x. **판정·보고** — 그 수정 때문에 §4~6 의 구현을 새로 만들거나 고쳐야 하면 제거(sd-impl 재실행 대기), 구현 변경 없이 spec 과 맞는 문서상 변경(문구·참조 정리 등)이면 유지. 기능 추가도 구현을 고쳐야 하므로 제거 — 직접·의존 수정 구분이 아니라 구현 변경 필요 여부로만 판정. 에이전트가 영향 §4~6 마다 판정해 결과만 보고하고, 불분명한 항목만 번호·한 줄 이유로 합의. ### 연산 사이 검토 각 연산(배치·부분 수정) 완료 후 동일하게: 1. spec.md 갱신 (작성/편집 완료). 2. **검토 패키지** 를 채팅으로 제시: - 이번에 쓴 섹션의 한 줄 요약. - `[OPEN]` 목록 (이번 연산이 남긴 미확정 항목). - 검증 결과 요약 (배치 연산의 경우 검증 서브에이전트가 반환한 근거 위조·누락·dangling 참조 보고). - 자료 커버리지 보고 (쓴 자료 중 spec 에 미반영된 부분). - **검증 서브에이전트 실패 시** (배치): 검증 서브에이전트가 하나라도 실패하면 부분 결과로 검토 패키지를 만들지 말고 실패 사실을 [error] 로 알린 뒤 해당 검증만 재실행해 보완. 전건 정상 반환이어야 검증 완료로 간주. 3. **정지**. 초안 배치가 끝나도 후속 수정으로 자동 진입 금지. 다음 연산은 사용자가 호출. ## 작성 원칙 배치·부분 수정 모두에 적용되는 spec 정확성 원칙 (상위 행동 규칙·sd-design-rules 와 중복 금지, sd-spec 고유분만). - **비자명 항목 inline 근거** — 자료에서 해석·도출한 비자명 항목에는 근거를 부착(아래 "신뢰도 표기"). 사용자가 직접 말한 자명한 항목엔 붙이지 않음. - **모르면 [OPEN]** — 근거가 없으면 임의로 채우지 말고 [OPEN] 으로 표기 (판정 기준은 "신뢰도 표기" 절). - **단순화 차단** — spec 의 식·분기·경계를 그대로 풀어쓰기. 방어 처리(NULL 강제·0 클램프·가드·분기 생략)로 임의 변형 금지(상위 "인터페이스 설계 시"·"결측 보존"의 spec 적용). 정확 풀이 부담이 크면 단순화안을 [OPEN] 표기하거나 검토 패키지에서 보고. - **형식 준수** — 각 § 작성법 규약 + 그 § 첫머리 "모범" 의 example-spec.md 모범 §를 형식 모범으로 직접 대조 (모범을 읽지 않고 텍스트 규칙만으로 작성 금지). 다른 §·example 에서는 **형식만** 가져오고 **내용물**(항목·컬럼·필드·액션·동작) 은 본 §의 자료·발언에서 직접 도출. 검증 단계(독립 서브에이전트)는 위 원칙의 준수를 독립 컨텍스트에서 사후 검증함 (검증 항목은 "초안 배치" 3단계 참조). 사람 사후 검토(검토 패키지)가 최종 안전망. ## spec.md 형식 ### 섹션 구조 spec.md 의 § 별 섹션 이름과 분류: **분류 기준**: - **요건**: 고객 입장 As-Is/To-Be — 무엇을·왜. - **설계**: 그것을 어떻게 만드나 — 구현 + 구현에 필요한 정보(UI·데이터구조·외부API). - **공통**: 요건·설계 양쪽에서 도출·편집되는 어휘·규격. - **자연 도출**: 직접 작성하는 단위가 아니라 다른 섹션을 쓰다 파생되는 섹션. 출처가 공통(§7 — 양쪽)인지 설계(§8·§9 — §4~6 파생)인지로 구분. - **§8·§9 불변식**: §4~6 에 없는 기능의 도메인 모델·외부 인터페이스는 존재할 수 없음 — 설계 산물로서 §4~6 의 종속. | § | 섹션 | 분류 | | --- | ---------------- | ---------------------------- | | §1 | 개요 | 요건 명세 | | §2 | 업무 프로세스 | 요건 | | §3 | 기타 요구사항 | 요건 | | §4 | 화면 | 설계 | | §5 | 자동 처리 | 설계 | | §6 | 공통·기반 기능 | 설계 | | §7 | 공통 정의 | 공통 자연 도출 (요건·설계 양쪽에서 도출·편집) | | §8 | 도메인 모델 | 설계 자연 도출 (§4~6 에서 파생) | | §9 | 외부 인터페이스 | 설계 자연 도출 (§4~6 에서 파생) | | §10 | 본문 외 확정 사항 | 메타 (결정이 발생할 때마다 누적) | ### 신뢰도 표기 spec.md 본문에서 항목의 신뢰도를 나타내는 표기. 전부 날짜 없음 (§10 로그 타임스탬프 제외). | 표기 | 의미 | | ------------------- | ---------------------------------------------------------------------------------------------------------- | | (무표기) | 직접·자명, 또는 미검토 초안. 기본 상태. | | 줄끝 `(근거: 출처)` | 자료에서 해석·도출한 **비자명** 항목의 근거 (예: `(근거: 회의록 L12)`). 사용자가 직접 말한 자명 항목엔 안 붙임. 위치 = 표는 비고 칸, 산문은 줄 끝. | | `[OPEN]` | 근거 없음. 필요 시 추측·필요자료 메모 동반 (예: `[OPEN] 박스당 수량 — As-Is상 24 추정, 미확인`). | | `[구현]` | §4~6 구현 완료 표시. 부착은 sd-impl·sd-spec init 배치 소관 (init 배치는 코드 대조 차이 0건 시 부착). §4~6 또는 그 의존 § 수정 시 제거는 sd-spec·sd-impl 양쪽 수행 (아래 "§4~6 `[구현]` 마커 제거" 절). | - `[OPEN]` 판정: 근거 부족(상위 행동 규칙 "결정 근거" 적용). As-Is 만 근거 / 추정 / 답변 범위 흡수 = 근거 없음 → `[OPEN]`. - 확정 여부는 사용자가 직접 관리 — 헤더에 상태 마커(`[확정: 날짜]`·`[OPEN: 날짜]` 등)를 붙이지 않음. - 예외: §10 "본문 외 확정 사항" 의 로그 항목은 순서 보존용 날짜를 유지(`- YYYY-MM-DD: ...`). 이는 신뢰도 마커가 아니라 로그 타임스탬프. ### 본문 내 참조 (이름 기반) 본문 내에서 다른 섹션을 참조할 때 § 번호 대신 `[카테고리.이름]` 형식 사용. 다단 표기 가능. § 번호는 분석 중 자주 바뀌므로 이름 기반 표기가 더 안정적. 예: - `[모델.재고]`·`[모델.박스.수량]`·`[모델.박스.품목.코드]`. - `[화면.재고 확인]`·`[프로세스.입고]`·`[기타.과거 재고 조회]`. - `[자동 처리.재고 스냅샷]`·`[기반.DataLog 기록]`·`[외부 인터페이스.ERP 입고 통보]`·`[공통 정의.Location 라벨]`. **관련 섹션 한 줄**: §2~§6·§9 본문에 `관련 섹션: [카테고리.이름], ...` 형식의 한 줄로 참조·의존 섹션을 콤마로 나열 (카테고리 제한 없음). 별도 작성 단위가 아님 — 다른 sub-section 작성 시 곁가지로 자동 누적. ### sub-section 헤더 레벨 §별 sub-section 의 spec.md 본문 표기 룰 통합 — 평문 (헤더 없이 라벨·한 줄·bullet 직접) / h4 마크다운 헤더 (`####`). | § | 평문 sub-section (형식) | h4 sub-section | | -- | ------------------------------------------------------------- | -------------------------------------------------------------------- | | §2 | BPMN (mermaid fence) · 흐름 설명 bullet · 관련 섹션 (한 줄) | (없음) | | §4 | 헤더 인덱스 (한 줄씩) · 기능 개요 (라벨 + bullet) | 와이어프레임 · 항목 · 동작 · 시각 규칙 · 도메인 규칙·로직 · 자유 추가 | | §5 | 목적 (라벨 + 한 줄) · 트리거 (라벨 + 본문) · 관련 섹션 (한 줄) | 처리 · 예외 처리 · 자유 추가 | | §6 | 목적 · 트리거·적용 범위 (해당) · 관련 섹션 · 참조 매뉴얼 (기본 기능) | (없음 — bespoke 만 본문 자유 서술, 필요 시 h4 자유 추가) | | §9 | 기본 정보 (라벨 bullet 3) · 관련 섹션 (한 줄) | 자료 매핑 · 예외 처리 | ### 진행 방법 누적 작업 중 사용자와 진행 방식을 합의하면 (예: "시트별로 분석") 즉시 누적. 적용 범위에 따라 2 경로: **spec 전체에 적용되는 경우** → §10 의 진행 방법 항목으로 누적 (`- YYYY-MM-DD: ...` bullet 형식). **분석 단위 한정** (§X.Y 또는 그 내부의 sub-section/sub-단위) → 해당 단위 도입부에 NOTE blockquote 작성: - 형식: `> **NOTE** (진행 방법): <한 줄 요약>` blockquote + 다단 (`> 1. ...`·`> 2. ...` 형식). - 분석 단위에 `[OPEN]` 항목이 남아 있으면 본 NOTE 가 다른 대화 재진입 시 진행 룰 회복의 출처가 됨. - 본 단위가 모두 확정되면, NOTE 는 유지 (진행 이력 기록 보존) 하거나 제거 (분석 단위에만 적용되었던 룰이므로) 가능. ## §별 작성법 각 § 의 작성법(분할 절차·본문 구조·sub-section·모범)은 `references/format.md` 에 있음 — 요건·공통(§1·§2·§3·§7)과 설계(§4·§5·§6·§8·§9)를 한 파일로 통합. 작성·부분 수정 시 읽기: - 공유 형식(위 "spec.md 형식" 절: 섹션 구조·신뢰도 표기·본문 내 참조·sub-section 헤더 레벨·진행 방법)·골격·§10 은 본 SKILL.md 에 유지. - **부분 수정** 시: `references/format.md` 의 편집 대상 섹션 작성법을 읽은 뒤 편집. - **초안 배치·init 배치** 는 메인이 요건 단계·설계 단계에서 `references/format.md` 를 읽음. ## §10 본문 외 확정 사항 §1~§9 의 어느 곳에도 자연스럽게 들어가지 않는 결정·메모를 누적. §1~§9 의 적절한 자리에 넣을 수 있는 결정은 §10 에 두지 않음 (누락 도피처가 아님). **모범**: example-spec.md §10. ### 형식 각 항목의 구조: - **헤더 1줄** (필수): `- YYYY-MM-DD: <결정 한 줄>`. - 분석 제외 시: `- YYYY-MM-DD [제외]: <결정 한 줄>`. - 날짜는 항목 작성 시점의 현재 날짜 `yyyy-MM-dd` (초안·init 배치는 준비 단계 생성값 재사용). 순서 보존용 로그 타임스탬프이며 신뢰도 마커가 아님. - **자식 bullet**: 형식 자유 (개수·내용 모두 자유). - **결정 근거 1개 이상 필수**. - 자유 항목 예시: 자료 위치·영향 범위·대화 발췌·메모·관련 § 등. - 분석 제외 시 추가 필수 항목: `후속 처리`·`자료 위치`. ### 포괄 결정 종류 매번 분류하지 않음 — 자연 흐름대로 누적. 분석 제외 신호가 있을 때만 `[제외]` 마커 부착. - **진행 방법**: **spec 전체** 작업에 대한 사용자 합의 진행 방식 (예: 작성 순서·범위 한정·전체 적용 규칙 등). 분석 단위에 한정된 진행 방법은 `## spec.md 형식` 의 "진행 방법 누적" 절 참조 — sd-spec 자신의 후속 참조용. - **미래 결정**: 해당 단계에 도달하기 전에 미리 내린 결정 (예: "추후 §4.5 작성 시 X 항목 포함") — sd-spec 자신의 후속 참조용. - **구현 영역 결정**: spec 본문에 들어가지 않는 구현 측 결정 (예: 라이브러리 선택) — sd-impl 의 후속 참조용. - **부정 결정**: "X 안 함" 부정 명시 — 반복 질문 방지용. - **분석 제외**: 본 spec 에서 다루지 않는 항목 — 다른 spec·sd-dev·운영 잔손 등 외부 후속 처리 대상. ### 예시 ``` - 2026-05-22: 월간 마감 자동화 — 안 함 - 근거: 회계팀 수동 처리 선호 - 자료 위치: 회의록_3.md L120-135 - 영향: §5 자동 처리 후보에서 제외 - 2026-05-22: 구현 시 결제 라이브러리 X 사용 - 근거: 사용자 명시 (PG사 계약 호환) - 2026-05-22 [제외]: 다국어 지원 - 근거: 현재 단계 아님 - 후속 처리: 다른 spec 신규 - 자료 위치: 회의록_3.md L80-95 - 2026-05-22: §4 와이어프레임은 영역 추상화만, 시각 디테일은 항목 표/동작 절로 분리 - 근거: 사용자 합의 — 와이어 분량 관리 ``` ## spec.md 골격 (초안·init 배치) 초안 배치·init 배치에서 spec.md 를 신규 생성할 때 사용하는 골격. `{name}` 은 사용자와 합의한 시스템명. ```markdown # {name} 요구 분석서 ## 1. 개요 ### 1.1 핵심 목적 ### 1.2 주요 목표 ### 1.3 최종 사용자/이해관계자 ### 1.4 환경/장치 ## 2. 업무 프로세스 ## 3. 기타 요구사항 ## 4. 화면 ## 5. 자동 처리 ## 6. 공통·기반 기능 ## 7. 공통 정의 ## 8. 도메인 모델 ## 9. 외부 인터페이스 ## 10. 본문 외 확정 사항 ``` 초안 배치 작성 범위 (골격 §1~§10 헤더는 준비 단계에서 생성됨, 본문은 두 단계로 채워짐): - 요건 단계: §1 개요·§2.x/§3.x 헤더·본문 (BPMN·흐름 설명 등)·§7 공통 정의(공통 자연 도출) 작성. 미확정 항목은 인라인 `[OPEN]`. §4~6·§8·§9 는 헤더만 두고 본문은 비움. - 설계 단계: §4 화면·§5 자동 처리·§6 공통·기반 기능 본문 작성 → 그 §4~6 이 참조한 모델·외부호출을 모아 §8 도메인 모델·§9 외부 인터페이스를 파생 작성. - §10 에는 자료에서 도출된 제외 결정 (`[제외]` 마커) 을 반영. ## 외부 참조 | 자료 | 용도 | | ---------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | [references/format.md](references/format.md) | §별 작성법 — 요건·공통 (§1·§2·§3·§7) + 설계 (§4·§5·§6·§8·§9). 초안 배치 요건·설계 단계 및 §1~9 부분 수정에서 읽기 | | [references/example-spec.md](references/example-spec.md) | spec.md 형식 모범 (WMS 예시 1건). 각 § 작성법의 "모범" 표기에서 참조 | | `${CLAUDE_PLUGIN_ROOT}/references/requirement-source-handling.md` | Requirement Source 부정확성 처리 (STT 오타·화자 모호·발화 모호·도메인 용어 다의성) |