spec-review
"/spec-review", "spec review", "스펙 리뷰", "문서 리뷰", "설계 문서 수정", "requirements 수정", "요구사항 수정", "design.md 수정해줘", "requirements.md 변경", "plan 수정" Gate 밖에서 v2 파이프라인 문서(requirements.md / plan.json / design.m
SKILL.mdskills/spec-review/SKILL.md
GitHub/spec-review — Gate 밖 문서 동기화 리뷰 (v2)
specify/blueprint 승인 게이트 밖에서도 문서 기반 피드백 → 파일 수정 → 관련 파일 동기화를 수행한다.
v2 파이프라인 아티팩트 구조
<spec_dir>/
├── requirements.md ← /specify 산출물. 요구사항 SSoT. 직접 편집 가능 (마크다운).
├── plan.json ← /blueprint 산출물. 태스크/verify/contracts 상태. CLI로만 수정.
├── contracts.md ← /blueprint 산출물. cross-module 인터페이스 + 불변식.
└── design.md ← /blueprint Phase 4.5 산출물. 아키텍처 문서 (human-only).
수정 원칙:
requirements.md→ 직접 Edit (마크다운 SSoT, CLI 불필요)plan.json→sr-harness-cli plan merge만 사용 (직접 편집 금지)contracts.md→ 직접 Edit (마크다운)design.md→ 직접 Edit (human-only, /execute가 읽지 않음)
왜 필요한가
blueprint 승인 게이트 내:
"R-T1.2 수정해줘" → requirements.md 수정 → design.md 재렌더링 → ✅
게이트 밖 (다른 세션, 일반 대화):
"design.md §4 수정해줘" → design.md만 수정 → ❌ requirements.md 미반영
/spec-review는 언제든지 파이프라인과 동일한 동기화를 제공한다.
실행 흐름
Step 1: spec_dir 로드
1. .sr-harness/specs/ 디렉토리에서 spec 목록 확인
2. spec이 1개 → 자동 로드
3. spec이 2개+ → 사용자에게 선택 질문
AskUserQuestion(
question: "리뷰할 spec을 선택해주세요.",
options: [
{ label: "wheel-controller-uart-refactor", description: "requirements.md + plan.json 있음" },
{ label: "narrow-corridor-navigation", description: "requirements.md만 있음 (blueprint 미실행)" }
]
)
Step 2: 현재 상태 표시
Spec: wheel-controller-uart-refactor
Pipeline stage: blueprint 완료 (requirements + plan + design 있음)
Documents:
✅ requirements.md — R-B1~R-B3, R-U1~R-U2, R-T1~R-T4 (18 sub-reqs)
✅ plan.json — 11 tasks, 2 journeys, 18 verify entries
✅ contracts.md — 3 interfaces, 2 invariants
✅ design.md — 9 sections
❌ plan.json — 없음 (blueprint 미실행)
Step 3: 피드백 수신 루프
사용자의 자연어 피드백을 받아 처리한다.
사용자 피드백 수신
↓
피드백 유형 분류:
├── Sub-requirement 수정 → "R-T1.2의 then을 변경해줘"
├── Sub-requirement 추가 → "R-B2에 인증 실패 케이스 추가"
├── Sub-requirement 삭제 → "R-U1.3 삭제해줘"
├── Parent req 수정 → "R-T1 behavior 문구 변경"
├── contracts 수정 → "invariant 추가해줘"
├── design.md 섹션 수정 → "§4의 시퀀스가 틀렸다"
├── plan.json task 수정 → "T3 action 문구 변경"
└── 전반적 보완 요청 → "에러 핸들링이 전체적으로 부족하다"
↓
파일 수정 (아래 규칙 적용)
↓
영향 범위 분석 → 관련 파일 동기화
↓
갱신된 내용 제시
↓
[Continue / Done]
Step 4: 파일 수정 규칙
requirements.md 수정 (직접 Edit)
v2 requirements.md 포맷:
## R-B1: <parent title>
#### R-B1.1: <sub title>
- given: <precondition>
- when: <trigger>
- then: <expected outcome>
수정 유형별 처리:
| 피드백 | 처리 |
|---|---|
| sub-req GWT 수정 | #### R-X<n>.Y: 해당 블록 Edit |
| sub-req 추가 | 부모 req 아래 새 #### R-X<n>.Y: 블록 추가 |
| sub-req 삭제 | 해당 블록 삭제, 이후 번호 재정렬 |
| parent behavior 수정 | ## R-X<n>: 줄 + behavior 라인 Edit |
plan.json 수정 (CLI 경유)
cat > /tmp/sr-plan-patch.json << 'EOF'
{"tasks": [{"id": "T3", "action": "새로운 action 문구"}]}
EOF
sr-harness-cli plan merge <spec_dir> --patch --json "$(cat /tmp/sr-plan-patch.json)"
task status 변경은 sr-harness-cli plan task <spec_dir> --status T3=done 사용.
contracts.md / design.md 수정 (직접 Edit)
마크다운 파일이므로 해당 섹션을 직접 Edit. 전체 재작성 금지 — 수정된 섹션만.
Step 5: 영향 범위 분석 + 동기화
수정된 파일에 따라 연쇄 동기화:
| 수정 대상 | 동기화 필요 파일 |
|---|---|
requirements.md sub-req GWT |
design.md §4 (해당 기능 상세 섹션) |
requirements.md parent req |
design.md §4, §3 (엔티티 영향 시) |
requirements.md R-T req |
contracts.md (인터페이스 영향 시), design.md §2, §6 |
contracts.md interface/invariant |
design.md §6, §2 |
plan.json task 변경 |
design.md §5 (시퀀스 다이어그램) |
동기화 규칙:
- 영향받는 문서의 해당 섹션만 재생성 (전체 재작성 금지)
- 재생성 시 requirements.md ID 가시성 유지 (R-B1.1, R-T2.3 등)
- plan.json 수정 후 반드시
sr-harness-cli plan validate <spec_dir>실행
Step 6: 결과 제시
## 수정 완료
### 파일 변경
- requirements.md: R-T1.2 then 항목 수정
- requirements.md: R-B2.4 추가 (인증 실패 케이스)
### 동기화
- design.md §4 R-T1 섹션 재생성
- design.md §4 R-B2 섹션에 R-B2.4 추가
[Continue reviewing / Done]
제약 사항
- plan.json 직접 편집 금지 — 반드시
sr-harness-cli plan merge/task경유 - 요구사항 신규 추가 시 — 해당 sub-req를 fulfill하는 task가 plan.json에 없으면 경고 표시 ("R-B2.4가 plan.json에 coverage되지 않습니다. /blueprint를 다시 실행하거나 수동으로 task를 추가하세요.")
- plan.json validate 실패 시 — 사용자에게 보고, 수정 제안
사용 예시
# 다음 날 design.md를 다시 읽다가 문제 발견
/spec-review
> "R-T1.2의 then에 'E-Stop 발행' 조건 추가해줘"
# → requirements.md R-T1.2 then Edit → design.md §4 R-T1 섹션 재생성
# 리뷰 미팅 후 피드백 반영
/spec-review
> "contracts.md의 wheel_cmd invariant에 timeout 조건 추가"
# → contracts.md Edit → design.md §6 재생성
# plan.json task 수정
/spec-review
> "T5 action 문구를 더 명확하게 바꿔줘"
# → sr-harness-cli plan merge --patch → design.md §5 재생성
/specify · /blueprint 게이트와의 차이
| 게이트 내 | /spec-review | |
|---|---|---|
| 실행 시점 | specify/blueprint 세션 안 | 언제든지 |
| 세션 | 연속 세션 | 독립 세션 |
| 파일 동기화 | 자동 | 자동 |
| 다음 단계 진행 | Approve 시 | 없음 (Done만) |
| plan.json coverage 체크 | 자동 | 경고만 |