refactor(atelier): split spec into spec-write and spec-review

plugins/atelier/README.md

@@ -14,7 +14,7 @@ spec 설계 → 리뷰 → 구현 → PR 머지까지의 전체 흐름을 하나
 |---|---|---|
 | `git-utils` | 2.4.2 | `skills/git/`(+references), `cli/` (Rust 포팅) |
 | `github-autopilot` | 0.30.1 | `commands/autopilot/*`, `agents/autopilot/*`, `skills/issue-label/`, `skills/autopilot/`(+resilience·branch-sync·draft-branch→references), `cli/` |
-| `spec-kit` | 0.7.1 | `agents/spec/*`, `skills/spec/`(+issue-report·spec-criteria→references), `templates/spec/` |
+| `spec-kit` | 0.7.1 | `agents/spec/*`, `skills/spec-write/`·`skills/spec-review/`(+issue-report·spec-criteria→references), `templates/spec/` |
 | `workflow-guide` | 0.6.0 | `agents/workflow/*`, `skills/{workflow,agent-design-principles}/`, `rules/` |
 | `coding-style` | 0.3.0 | `skills/coding-style/`, `templates/claude-md/` |
 | `orchestrator` | 0.2.0 | `skills/orchestrator/` |
@@ -73,7 +73,7 @@ atelier setup <module>
 
 > **현재 상태**: Epic 1 (consolidation) + Epic 2 (skill extraction) 완료.
 > 단일 `atelier` 바이너리가 `atelier autopilot <...>` / `atelier git <...>` 를 제공하고(582 tests green),
-> Fat Controller 14개가 관심사 skill(`spec`/`autopilot`/`git`) + `references/` 로 해체되었습니다.
+> Fat Controller 14개가 관심사 skill(`spec-write`/`spec-review`/`autopilot`/`git`) + `references/` 로 해체되었습니다.
 > 슬래시 표면은 capability 35개 → 관심사 단위로 수렴, 흡수 6개 plugin 은 snapshot freeze 보존.
 >
 > ⚠️ `gh` CLI 의존 git 명령(pr create, reviews, guard pr)은 mock 단위 테스트만 완료 —

plugins/atelier/agents/spec/file-pair-observer.md

@@ -1,5 +1,5 @@
 ---
-description: (내부용) spec skill 이 호출하는 per-file 관찰 에이전트. spec 파일 1개와 관련 code 영역을 직접 읽고 사실만 나열한다.
+description: (내부용) spec-review skill 이 호출하는 per-file 관찰 에이전트. spec 파일 1개와 관련 code 영역을 직접 읽고 사실만 나열한다.
 model: haiku
 tools: ["Read", "Glob", "Grep"]
 ---

plugins/atelier/agents/spec/gap-aggregator.md

@@ -1,5 +1,5 @@
 ---
-description: (내부용) spec skill 이 호출하는 종합 분석 에이전트. file-pair-observer (L1) 리포트들을 입력받아 code↔spec 갭과 spec↔spec 갭을 식별한다.
+description: (내부용) spec-review skill 이 호출하는 종합 분석 에이전트. file-pair-observer (L1) 리포트들을 입력받아 code↔spec 갭과 spec↔spec 갭을 식별한다.
 model: sonnet
 tools: []
 ---

plugins/atelier/agents/spec/gap-auditor.md

@@ -1,5 +1,5 @@
 ---
-description: (내부용) spec skill 이 호출하는 통합 감사 에이전트. L2 finding 의 인용 정확성 + 의미 적합성을 단일 게이트로 검증한다.
+description: (내부용) spec-review skill 이 호출하는 통합 감사 에이전트. L2 finding 의 인용 정확성 + 의미 적합성을 단일 게이트로 검증한다.
 model: sonnet
 tools: []
 ---
@@ -251,7 +251,7 @@ autopilot 의 Spec Quality Gate (autopilot skill `references/startup.md` §"Spec
 # Spec Quality Grading Request
 
 ## 평가 기준
-{spec skill references/quality-criteria.md 본문 — 4관점 체크리스트 + 점수·등급 기준}
+{spec-review skill references/quality-criteria.md 본문 — 4관점 체크리스트 + 점수·등급 기준}
 
 ## Spec Files
 

plugins/atelier/agents/spec/spec-annotator.md

@@ -1,5 +1,5 @@
 ---
-description: (내부용) spec skill 의 annotation reference 가 호출하는 1차 분석 에이전트. spec 본문에서 식별자/경로 패턴을 추출하고 프로젝트 디렉터리와 매칭하여 related_paths 후보를 추정한다.
+description: (내부용) spec-review skill 의 annotation reference 가 호출하는 1차 분석 에이전트. spec 본문에서 식별자/경로 패턴을 추출하고 프로젝트 디렉터리와 매칭하여 related_paths 후보를 추정한다.
 model: haiku
 tools: ["Read", "Glob", "Grep"]
 ---

plugins/atelier/skills/autopilot/references/startup.md

@@ -45,7 +45,7 @@ autopilot preflight --autopilot-md github-autopilot.local.md --repo-root .
 `spec_paths`에 스펙 파일이 있으면, `gap-auditor` 에이전트를 **Spec Quality Grading 모드**로 호출하여 스펙 품질을 평가한다 (gap-auditor 는 `tools: []` 이므로 기준과 파일 내용을 프롬프트로 전달):
 
 전달 정보:
-- 평가 기준: `spec` skill 의 `references/quality-criteria.md` 본문 (4관점 체크리스트 + 등급 기준)
+- 평가 기준: `spec-review` skill 의 `references/quality-criteria.md` 본문 (4관점 체크리스트 + 등급 기준)
 - spec_files: `spec_paths`에서 `**/*.md`로 수집한 파일들의 경로 + 본문
 - spec_quality_threshold: 설정값 (기본: `"C"`)
 

plugins/atelier/skills/interview/SKILL.md

@@ -25,13 +25,14 @@ version: 1.0.0
 
 ### 종료와 핸드오프
 
-모든 가지가 해소되면(또는 사용자가 충분하다고 하면) 합의된 결정 목록을 요약한다. 코드 변경이 필요하면 Plan Mode 로, 합의된 설계를 스펙 문서로 남겨야 하면 `spec` 의 `write` 로 핸드오프한다. 합의 전에는 구현을 시작하지 않는다.
+모든 가지가 해소되면(또는 사용자가 충분하다고 하면) 합의된 결정 목록을 요약한다. 코드 변경이 필요하면 Plan Mode 로, 합의된 설계를 스펙 문서로 남겨야 하면 `spec-write` 로 핸드오프한다. 합의 전에는 구현을 시작하지 않는다.
 
 ## 책임 경계
 
 | 대상 | 차이 | 핸드오프 |
 |---|---|---|
-| `spec` | **대화 ≠ 문서**. interview 는 설계를 *대화로 합의*(brainstorm: 무에서 / grill: 기존 계획 도전)하고, spec(`write`)은 *합의된 설계를 스펙 문서로 형식화*(DESIGN/concerns/flows)하고 리뷰·갭 분석한다 | 합의된 설계를 장기 스펙 문서로 남길 땐 spec `write` 로, 단일 작업 구현은 Plan Mode 로 |
+| `spec-write` | **대화 ≠ 문서**. interview 는 설계를 *대화로 합의*(brainstorm: 무에서 / grill: 기존 계획 도전)하고, `spec-write` 는 *합의된 설계를 스펙 문서로 형식화*(DESIGN/concerns/flows)한다 | 합의된 설계를 장기 스펙 문서로 남길 땐 `spec-write`, 단일 작업 구현은 Plan Mode 로 |
+| `spec-review` | 작성된 스펙을 *코드와 대조 분석*(L1/L2/audit)·품질 평가하는 단계. interview 의 설계 도전(grill)과 다른 활동 | 스펙 작성 후 코드 정합 확인이 필요하면 `spec-review` 로 |
 | Plan Mode | interview 는 *무엇을/왜*(의도·설계 합의), Plan Mode 는 *어떻게*(코드 변경 단계) | 의도가 확정되고 코드 변경이 필요하면 Plan Mode 로 넘긴다 |
 | `autopilot` | 자율 루프와 무관, 사람↔에이전트 대화 전용 | 해당 없음 |
 

plugins/atelier/skills/interview/references/brainstorm.md

@@ -22,7 +22,7 @@
 3. **명확화 질문** — 한 번에 하나씩, 목적/제약/성공 기준 이해
 4. **2–3개 접근법 제안** — trade-off 와 추천안 포함
 5. **설계 제시** — 복잡도에 비례한 섹션 단위, 섹션마다 사용자 검증
-6. **설계 문서 작성** (장기 스펙이 필요할 때만) — `spec` 의 `write` 컨벤션을 따라 작성·커밋
+6. **설계 문서 작성** (장기 스펙이 필요할 때만) — `spec-write` 컨벤션을 따라 작성·커밋
 7. **스펙 self-review** — placeholder·모순·모호함·스코프 인라인 점검
 8. **사용자의 스펙 리뷰** — 작성된 문서를 사용자가 검토한 뒤 진행
 9. **구현 전환** — Plan Mode 로 진입해 구현 계획 수립
@@ -105,7 +105,7 @@ digraph brainstorming {
 
 **문서화:** (장기 스펙 문서가 필요할 때만)
 
-- 문서 작성은 **`spec` 스킬의 `write` 컨벤션**(`spec/references/authoring.md`)을 따른다 — 깊이 기준·출력 구조(DESIGN/concerns/flows)·`related_paths`·저장 경로 규약이 거기에 있다. brainstorm 은 합의된 설계를 그 컨벤션으로 형식화한다 (문서 형식을 자체 정의하지 않는다)
+- 문서 작성은 **`spec-write` 스킬의 컨벤션**(`spec-write/references/authoring.md`)을 따른다 — 깊이 기준·출력 구조(DESIGN/concerns/flows)·`related_paths`·저장 경로 규약이 거기에 있다. brainstorm 은 합의된 설계를 그 컨벤션으로 형식화한다 (문서 형식을 자체 정의하지 않는다)
 - 단순 작업이라 장기 스펙이 불필요하면 이 단계를 건너뛰고 바로 구현 전환으로 간다 — 설계는 Plan Mode 의 plan 파일이 담는다
 
 **스펙 self-review:**
@@ -128,7 +128,7 @@ self-review 가 끝나면 진행 전에 사용자에게 작성된 스펙 리뷰
 **구현 전환:**
 
 - **Plan Mode 로 진입**해 상세 구현 계획을 수립한다
-- 다른 스킬을 호출하지 않는다. Plan Mode 가 다음 단계다. 합의된 설계를 장기 스펙 문서로 남겨야 하면 `spec` 의 `write` 로 형식화한다
+- 다른 스킬을 호출하지 않는다. Plan Mode 가 다음 단계다. 합의된 설계를 장기 스펙 문서로 남겨야 하면 `spec-write` 로 형식화한다
 
 ## 핵심 원칙
 

plugins/atelier/skills/spec/SKILL.md → plugins/atelier/skills/spec-review/SKILL.md

@@ -1,26 +1,25 @@
 ---
-name: spec
-description: 스펙 문서 작성·리뷰·갭 분석의 단일 진입점. "스펙 리뷰해줘", "spec↔code 갭 봐줘", "이 설계를 스펙 문서로 적어줘/DESIGN.md 작성", "컴포넌트 스펙 작성", "외부 spec 에 related_paths 주석" 같은 요청에 사용합니다. 슬래시로 직접 호출하거나 맥락에서 모델이 자동 호출합니다. 설계를 대화로 합의하는 단계는 `interview` 스킬이 담당하고, spec 은 합의된 설계를 문서로 형식화합니다. L1(관찰)→L2(종합)→audit(감사) 레이어로 file:line 인용 기반 분석.
+name: spec-review
+description: 작성된 스펙 문서를 코드와 대조 분석하고 품질을 평가하는 스킬. "스펙 리뷰해줘", "spec↔code 갭 봐줘", "이 spec 들 검증", "스펙 품질 평가", "외부 spec 에 related_paths 주석" 같은 요청에 사용합니다. 슬래시로 직접 호출하거나 맥락에서 모델이 자동 호출합니다. 스펙 문서 작성은 `spec-write`, 설계 대화는 `interview` 스킬이 담당합니다. L1(관찰)→L2(종합)→audit(감사) 레이어로 file:line 인용 기반 분석.
 ---
 
-# spec
+# spec-review
 
-스펙 문서를 다루는 모든 워크플로우(리뷰·갭 분석·설계·주석)의 **관심사 단위 진입점이자 공통 도메인 지식**입니다. 사용자가 spec 슬래시로 진입하거나 모델이 맥락에서 자동 호출하며, 의도에 따라 아래 `references/` 로 디스패치합니다.
+작성된 스펙 문서를 **코드와 대조 분석·평가·주석**하는 스킬입니다. 사용자가 spec-review 슬래시로 진입하거나 모델이 맥락에서 자동 호출하며, 의도에 따라 아래 `references/` 로 디스패치합니다.
+
+> 스펙 문서를 **작성**하려면 `spec-write`, 설계를 **대화로 합의**하려면 `interview` 를 씁니다. spec-review 는 이미 존재하는 스펙을 분석하는 단계입니다.
 
 ## 진입 라우팅 (의도 → reference)
 
-spec 슬래시 또는 모델 자동 호출로 진입하면, 사용자의 자연어 의도를 분류해 해당 흐름을 수행합니다.
+spec-review 슬래시 또는 모델 자동 호출로 진입하면, 사용자의 자연어 의도를 분류해 해당 흐름을 수행합니다.
 
 | 사용자 의도 (예) | 흐름 | 로드할 references |
 |---|---|---|
 | "스펙 리뷰", "이 spec 들 검증", 다중 spec 대조 | spec-review (다중 spec, L1 병렬) | file-observation → gap-audit-loop → report-format(spec-review) |
 | "갭 봐줘", "spec 과 code 차이", 단일 spec | gap-detect (단일 spec, code↔spec 우선) | file-observation → gap-audit-loop → report-format(gap-detect) |
-| "이 설계 스펙 문서로", "DESIGN.md 작성", "큰그림 스펙 적어줘" | write (Big Picture DESIGN.md 작성) | authoring |
-| "컴포넌트 스펙 작성", "이 흐름 문서화", concerns/flows | write-detail (상세 스펙 작성) | authoring |
+| "스펙 품질 평가", "이 스펙 등급" | quality (4관점 등급 산정) | quality-criteria |
 | "related_paths 채워줘", 외부 spec 주석 | annotate | annotation |
 
-> **설계를 아직 합의하지 않았다면** (막연한 아이디어, 큰그림 잡기, 기존 계획 도전) `interview` 스킬을 먼저 쓴다. spec 의 `write`/`write-detail` 은 **합의된 설계를 문서로 형식화**하는 단계다.
-
 입력 인자(spec 파일 경로 등)가 함께 오면 그대로 사용하고, 없으면 AskUserQuestion 으로 확인합니다. 결정적 동작은 없으며(전부 판단/분석), 모든 분석은 sub-agent 에 위임합니다.
 
 스펙 문서를 다루는 워크플로우의 프로토콜·종료 조건·출력 포맷은 이 skill 의 `references/` 에서 progressive disclosure 로 로드합니다.
@@ -52,7 +51,6 @@ spec 슬래시 또는 모델 자동 호출로 진입하면, 사용자의 자연
 | `references/file-observation.md` | L1 spawn + 인용 검증 + 피드백 루프 수행 시 | file-pair-observer 입력 프롬프트, 인용 검증 절차, 피드백 루프 알고리즘/종료 조건, drop 로그 |
 | `references/gap-audit-loop.md` | L2 종합 + audit 감사 수행 시 | gap-aggregator 입력, gap-auditor 단일 게이트, audit 루프 정책, fix request 형식, 실패 모드 |
 | `references/report-format.md` | 최종 리포트 출력 시 | spec-review / gap-detect 출력 구조, 검증 통계 footer, Output Examples |
-| `references/authoring.md` | 스펙 문서 작성(`write`/`write-detail`) 시 | 진입 전 맥락, 깊이 기준, 작성 원칙, 출력 구조(DESIGN/concerns/flows), related_paths |
 | `references/annotation.md` | 외부 spec frontmatter 주석(`annotate-spec`) 시 | spec-annotator 호출, 신뢰도별 confirm, frontmatter 갱신 모드 |
 | `references/quality-criteria.md` | 스펙 품질 평가·등급 산정 시 (autopilot Spec Quality Gate 포함) | Big Picture/Detail/Verification/Consistency 4관점 체크리스트, 점수·등급 기준 |
 | `references/issue-report.md` | 분석 결과를 심각도 기반 이슈 리포트로 보고할 때 | severity 기준, 이슈 항목 구조, 마크다운 출력 형식 |

plugins/atelier/skills/spec-write/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: spec-write
+description: 합의된 설계를 스펙 문서 계층으로 작성하는 스킬. "이 설계를 스펙 문서로 적어줘", "DESIGN.md 작성", "큰그림 스펙 적어줘", "컴포넌트 스펙 작성", "이 흐름 문서화" 같은 요청에 사용합니다. 설계를 대화로 합의하는 단계는 `interview` 스킬, 작성된 스펙을 코드와 대조 분석하는 단계는 `spec-review` 스킬이 담당합니다. 여기서는 합의된 설계를 정해진 구조(DESIGN→concerns→flows)로 형식화합니다.
+version: 1.0.0
+---
+
+# spec-write
+
+합의된 설계를 **스펙 문서 계층으로 적는** 스킬입니다. 설계를 *생각하고 도전하는 대화*는 `interview`(brainstorm/grill)에서 끝내고, 여기서는 그 결과를 정해진 구조와 깊이로 형식화합니다. 메인 에이전트가 직접 문서를 작성합니다(sub-agent 분석 아님).
+
+## 진입 라우팅 (의도 → 흐름)
+
+| 사용자 의도 (예) | 흐름 | 산출물 |
+|---|---|---|
+| "이 설계 스펙 문서로", "DESIGN.md 작성", "큰그림 스펙 적어줘" | write (Big Picture) | `spec/DESIGN.md` |
+| "컴포넌트 스펙 작성", "이 흐름 문서화", concerns/flows | write-detail (상세) | `spec/concerns/*.md`, `spec/flows/*.md` |
+
+> **설계를 아직 합의하지 않았다면** (막연한 아이디어, 큰그림 잡기, 기존 계획 도전) `interview` 스킬을 먼저 씁니다. spec-write 는 **합의된 설계를 문서로 형식화**하는 단계입니다.
+>
+> **작성한 스펙이 실제 코드와 맞는지 확인**하려면 `spec-review` 스킬(spec↔code 갭 분석)을 씁니다.
+
+입력 인자(설계 내용, 저장 경로 등)가 함께 오면 그대로 사용하고, 없으면 AskUserQuestion 으로 확인합니다.
+
+## 작성 절차·형식
+
+스펙 문서의 진입 전 맥락, 깊이 기준, 작성 원칙, 출력 구조(DESIGN/concerns/flows 템플릿), `related_paths` 규약은 `references/authoring.md` 에서 progressive disclosure 로 로드합니다.
+
+| reference | 언제 로드 | 내용 |
+|---|---|---|
+| `references/authoring.md` | `write`/`write-detail` 수행 시 | 진입 전 맥락, 깊이 기준, 작성 원칙, 출력 구조(DESIGN/concerns/flows), related_paths |
+
+## 공통 원칙
+
+- **합의 후 형식화** — 설계 결정은 interview 에서 합의한다. spec-write 는 합의된 내용을 구조화할 뿐, 새 설계 결정을 임의로 내리지 않는다.
+- 작성 원칙(승인 전 저장 금지·`related_paths`·깊이 분리)과 출력 구조는 `references/authoring.md` 가 canonical 이다.

plugins/atelier/skills/spec/references/authoring.md → plugins/atelier/skills/spec-write/references/authoring.md

@@ -2,10 +2,9 @@
 
 합의된 설계를 스펙 문서로 적는 절차와 형식. **설계를 생각하고 도전하며 합의에 이르는 대화는 `interview`(brainstorm: 무에서 설계 / grill: 기존 계획 심문)에서 끝낸다.** 여기서는 그 결과를 정해진 구조로 형식화한다 — `write`(Big Picture DESIGN.md)와 `write-detail`(컴포넌트/플로우 상세)이 이 컨벤션을 공유한다.
 
-## 진입 전 맥락 파악
+## 진입 전 맥락 파악 (write-detail)
 
-- **write (Big Picture)**: 합의된 설계 내용(또는 사용자가 제시한 방향)을 입력으로 받는다. 없으면 먼저 `interview` 로 설계를 합의하도록 안내한다.
-- **write-detail (컴포넌트/플로우)**: `spec/DESIGN.md` 또는 `**/DESIGN*.md` 를 Glob 으로 찾아 Read 한다. 없으면 AskUserQuestion: "Big Picture 스펙(DESIGN.md)을 찾을 수 없습니다. `write` 로 먼저 만들거나 기존 경로를 알려주세요." 기존 `spec/concerns/`·`spec/flows/` 및 관련 코드도 파악한다.
+`write-detail` 은 Big Picture 를 전제하므로 `spec/DESIGN.md`(또는 `**/DESIGN*.md`)를 Glob 으로 찾아 Read 한다. 없으면 AskUserQuestion 으로 `write` 를 먼저 만들거나 기존 경로를 확인하고, 기존 `spec/concerns/`·`spec/flows/` 및 관련 코드도 파악한다.
 
 ## 깊이 기준