From e4663d2f3f76648e9615bc6cc63678997f8ddb8f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EA=B9=80=EC=9A=A9=EC=84=B1?=
 <kys0213@gim-yongseong-ui-MacBookPro.local>
Date: Sat, 13 Jun 2026 10:43:05 +0900
Subject: [PATCH 1/7] feat(atelier): add interview skill
 (quick/grill/brainstorm)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Pre-work intent-alignment meta-skill with three modes routed from a single entry point (mirrors the spec skill's intent->reference dispatch):

- quick (default, inline): RG-CN-A frame (Restate/Goal/Constraints/Non-goals/Acceptance) -> 5-line mini-spec -> 'go' gate
- grill (references/grill.md): interrogate an existing plan branch-by-branch down the decision tree, one question at a time with a recommended answer, exploring the codebase instead of asking when possible
- brainstorm (references/brainstorm.md): context exploration -> clarifying questions -> 2-3 approaches with trade-offs -> section-by-section design validation (interface/module structure/dependency direction) with optional visualization -> design self-review -> approval hard gate -> handoff

Shared hard gate: no implementation before explicit approval. Boundaries documented vs spec:design (state-based split), Plan Mode, autopilot. Design persistence stays on existing channels (Plan Mode plan file / spec:design document) to avoid duplicating spec's artifact responsibility.

grill/brainstorm concepts adapted from obra/superpowers (MIT, (c) 2025 Jesse Vincent) brainstorming/grill-me skills, rewritten for atelier conventions with superpowers-ecosystem dependencies removed.

Closes #713 (reinterpreted: standalone deep-interview plugin -> atelier skill, per marketplace consolidation)

🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
---
 plugins/atelier/skills/interview/SKILL.md     |  89 +++++++++++++++
 .../skills/interview/references/brainstorm.md | 102 ++++++++++++++++++
 .../skills/interview/references/grill.md      |  70 ++++++++++++
 3 files changed, 261 insertions(+)
 create mode 100644 plugins/atelier/skills/interview/SKILL.md
 create mode 100644 plugins/atelier/skills/interview/references/brainstorm.md
 create mode 100644 plugins/atelier/skills/interview/references/grill.md

diff --git a/plugins/atelier/skills/interview/SKILL.md b/plugins/atelier/skills/interview/SKILL.md
new file mode 100644
index 00000000..98ddcd7a
--- /dev/null
+++ b/plugins/atelier/skills/interview/SKILL.md
@@ -0,0 +1,89 @@
+---
+name: interview
+description: 작업 착수 전 의도·설계를 사람과 합의하는 인터뷰 메타스킬. "의도부터 확정하자", "grill me / 이 계획 심문해줘 / 스트레스 테스트", "같이 brainstorm 하자 / 설계 같이 잡자" 같은 요청에 사용합니다. 슬래시로 직접 호출하거나 모델이 모호한 요청을 감지하면 사용을 제안하며, quick(의도 확정)·grill(기존 계획 심문)·brainstorm(무에서 설계) 모드로 라우팅합니다.
+version: 1.0.0
+---
+
+# interview
+
+코드를 건드리기 **전에** 의도·제약·완료 기준을 사람과 합의해 오해와 오버엔지니어링을 차단하는 단일 진입점입니다. atelier 의 **설계 최우선(Design First)** 원칙을 대화 단계에서 강제합니다.
+
+사용자가 interview 슬래시로 진입하거나 모델이 맥락에서 자동 호출하며, 자연어 의도를 분류해 아래 모드로 디스패치합니다.
+
+## 진입 라우팅 (의도 → 모드)
+
+| 사용자 의도 (예) | 모드 | 로드할 reference |
+|---|---|---|
+| "이거 정리/개선해줘"(모호), "뭐부터 할지 의도부터", 단발 작업 착수 | `quick` (기본) | (인라인) |
+| "grill me", "이 계획 심문해줘", "내 plan 스트레스 테스트", 기존 설계 검증 | `grill` | `references/grill.md` |
+| "같이 brainstorm", "설계 같이 잡자", "막연한데 방향 잡아줘", 무에서 설계 | `brainstorm` | `references/brainstorm.md` |
+
+입력 인자(대상 파일·기존 plan 경로 등)가 함께 오면 그대로 사용하고, 없으면 직접 묻습니다. 결정적 동작은 없으며 전부 **판단/대화**입니다.
+
+## 공통 원칙 (3모드 공유)
+
+1. **질문은 한 번에 하나씩** — 한꺼번에 쏟지 않는다. 답을 받아 다음 가지를 정한다.
+2. **각 질문마다 추천 답을 함께 제시** — 사용자가 0부터 생각하지 않게, "내 추천은 X (이유)" 형태로 default 를 제안.
+3. **코드베이스로 답할 수 있으면 질문하지 말고 탐색한다** — prior art·기존 컨벤션·영향 범위는 Grep/Read 로 직접 확인 후 사실로 제시. 사람의 시간은 *판단이 필요한 지점*에만 쓴다.
+4. **승인 전 구현 금지 (Hard Gate)** — 미니 명세/설계를 제시하고 사용자가 "go"(또는 승인)하기 전에는 코드 작성·스캐폴딩·파일 변경을 시작하지 않는다. 작업이 단순해 보여도 동일하게 적용한다.
+
+## quick 모드 (기본) — RG-CN-A 의도 확정
+
+단발 작업의 의도를 3–5분 안에 확정한다. 아래 5개 축을 **순서대로, 한 번에 하나씩** 확인하되, 코드베이스로 답 가능한 항목은 먼저 탐색해 "내가 확인한 사실"로 제시하고 사용자에겐 판단만 요청한다.
+
+```
+R(estate)     — 내가 이해한 요청 = ... (2~3 bullet 로 재진술)
+G(oal)        — 진짜 달성하려는 건? 왜 이걸 하는가
+C(onstraints) — 지켜야 할 컨벤션/제약? (있으면 코드베이스에서 먼저 탐색)
+N(on-goals)   — 명시적으로 안 건드릴 것?
+A(cceptance)  — "완료" 판정 기준?
+```
+
+옵션 항목 (5축 사이의 고정 위치에 삽입):
+- **Prior art**: C(onstraints) 확인 **전에** 코드베이스를 직접 탐색해 비슷한 패턴을 사실로 제시 (질문 아님)
+- **Risk surface**: A(cceptance) 까지 끝난 **뒤**, 다중 해석·넓은 영향 같은 위험 신호가 남아 있으면 마지막 1회 "가장 위험한 오해 후보"를 확인
+
+### quick 산출물 — 5줄 미니 명세
+확인이 끝나면 아래를 출력하고 사용자의 "go" 를 기다린다.
+
+```
+요청(R): ...
+목표(G): ...
+제약(C): ...
+비목표(N): ...
+완료(A): ...
+→ 이대로 진행할까요? ("go" 또는 수정사항)
+```
+
+## 자동 발동 트리거 (모델이 호출 제안)
+
+다음 신호 중 하나 이상이면 사용자에게 interview 사용을 **제안**한다 (강제하지 않음):
+- 동사가 추상적: "정리", "개선", "최적화", "리팩터"
+- 객체가 모호하거나 다중 해석 가능
+- 영향 범위가 5+ 파일로 추정됨
+- 새 기능/리팩터 키워드 + 컨벤션·제약 미언급
+
+## Skip 조건 (발동하지 않음)
+
+- 한 줄 수정, 오타, 단순 조회
+- 사용자가 "그냥 해" 류 빠른 진행을 명시
+- 이미 Plan Mode / `spec` 설계에 진입한 상태 (중복 게이트 방지)
+
+## 책임 경계 (중복 방지)
+
+| 대상 | interview 와의 차이 | 핸드오프 |
+|---|---|---|
+| `spec:design` | 분기는 **상태 기준**: 의도·요구사항이 아직 모호하면 interview, 의도는 합의됐고 아키텍처 구조(다중 컴포넌트)를 스펙 문서로 잡는 단계면 spec:design. interview 의 산출은 대화 내 합의(미니 명세·설계 요약), spec:design 의 산출은 스펙 문서 | brainstorm 중 아키텍처 규모로 판명되거나 설계의 문서 영속화가 필요하면 `spec:design` 으로 에스컬레이트. 역방향: spec:design 진입 시 의도가 아직 모호하면 interview 를 먼저 권한다 |
+| Plan Mode | interview 는 *무엇을/왜*(의도). Plan Mode 는 *어떻게*(코드 변경 단계 설계) | quick/brainstorm 으로 의도가 확정되고 코드 변경이 필요하면 Plan Mode 로 넘긴다 |
+| `autopilot` | 자율 루프와 무관. interview 는 사람↔에이전트 대화 전용 | 해당 없음 |
+
+## references 로드 가이드
+
+| reference | 언제 로드 | 내용 |
+|---|---|---|
+| `references/grill.md` | 기존 plan/design 을 심문(`grill`)할 때 | 결정 트리 순회, 의존성 해소 순서, 종료 조건, 합의 결정 출력 |
+| `references/brainstorm.md` | 무에서 설계(`brainstorm`)할 때 | 컨텍스트 탐색 → 명확화 질문 → 2–3 접근법 → 섹션별 설계 검증(+시각화 제안) → self-review → 승인 게이트 → 핸드오프 |
+
+## 출처
+
+`grill`/`brainstorm` 모드의 인터뷰·설계 게이트 개념은 [obra/superpowers](https://github.com/obra/superpowers) (MIT License, © 2025 Jesse Vincent) 의 `brainstorming`·`grill-me` 스킬에서 차용해 atelier 컨벤션·책임 경계에 맞게 재작성했습니다.
diff --git a/plugins/atelier/skills/interview/references/brainstorm.md b/plugins/atelier/skills/interview/references/brainstorm.md
new file mode 100644
index 00000000..1504a51b
--- /dev/null
+++ b/plugins/atelier/skills/interview/references/brainstorm.md
@@ -0,0 +1,102 @@
+# interview — brainstorm 모드
+
+막연한 아이디어를 **검증된 설계**로 함께 발전시킨다. 컨텍스트 탐색에서 출발해 접근법을 비교하고, 설계를 섹션 단위로 검증받고, self-review 와 승인 게이트를 거쳐 구현 단계로 넘긴다. `interview` SKILL.md 의 공통 원칙(한 번에 하나, 추천 답 동반, 코드베이스 우선 탐색, 승인 전 구현 금지)을 그대로 따른다.
+
+## 언제 쓰나
+
+- "같이 brainstorm 하자", "설계 같이 잡자", "막연한데 방향부터" 처럼 **아직 구체안이 없는** 작업
+- 이미 plan 이 있으면 `grill` 모드로. 의도가 이미 합의됐고 아키텍처 스펙 문서를 잡는 단계면 `spec:design` 으로.
+
+## 프로세스
+
+### 1. 컨텍스트 탐색 (먼저, 직접)
+질문하기 전에 코드베이스에서 prior art·관련 모듈·기존 컨벤션·영향 범위를 Grep/Read 로 확인한다. 발견한 사실을 "이미 X 패턴이 있습니다" 형태로 먼저 제시한다.
+
+### 2. 명확화 질문 — 한 번에 하나씩
+이해 갭을 메우는 질문을 하나씩 한다. 각 질문에 **추천 답과 근거**를 동반한다. 목적·제약·성공 기준이 드러날 때까지 계속하되, 코드로 답이 정해지는 건 묻지 말고 탐색 결과로 메운다.
+
+### 3. 접근법 2–3개 + trade-off
+설계 공간이 좁혀지면 **서로 다른 접근법 2–3개**를 제시한다.
+- 각 접근의 핵심 아이디어 / 장점 / 비용·리스크 / 적합 조건
+- 그중 **추천안과 이유**를 명시한다. 사용자가 선택하면 다음 단계로.
+
+### 4. 설계 제시 — 섹션 단위 검증
+선택된 방향을 **한 번에 쏟지 않고 섹션 단위로** 제시하고, 섹션마다 사용자 검증을 받은 뒤 다음으로 간다. 섹션 구성은 설계 산출물 3요소(인터페이스 정의·모듈 구조·의존성 방향)를 반드시 포함한다:
+
+1. 목적·범위 (비목표 포함)
+2. **인터페이스 정의** — 공개 API / 시그니처 / 계약
+3. **모듈 구조** — 책임 분리
+4. **의존성 방향** — 무엇이 무엇에 의존하는가
+5. 에러·엣지 케이스
+6. 영향 범위·리스크
+
+### 5. 시각화 (조건부 제안)
+텍스트보다 시각 표현이 이해를 명확히 돕는 섹션(구조 비교·흐름·대안 대조)에서는 **먼저 제안하고 동의를 받은 뒤** 사용한다:
+- markdown 표 / ASCII·mermaid 다이어그램 — 모듈 구조, 의존성 방향, 흐름
+- AskUserQuestion 의 preview — 대안 2–3개를 나란히 비교시킬 때
+
+모든 섹션에 강제하지 않는다. 시각화가 더해주는 게 없으면 텍스트로 간다.
+
+### 6. 설계 self-review
+최종 승인을 요청하기 직전 스스로 점검한다:
+- 섹션 간 모순은 없는가
+- 검증 안 된 가정이 사실처럼 적혀 있지 않은가
+- 요청하지 않은 추상화(YAGNI 위반)가 끼어들지 않았는가
+- 빠뜨린 엣지·사이드이펙트는 없는가
+
+발견하면 해당 섹션을 수정해 다시 제시한다.
+
+### 7. 승인 게이트 (Hard Gate)
+전체 설계 요약을 제시하고 **명시적 승인**을 받는다. 승인 전에는 코드 작성·스캐폴딩·파일 변경을 시작하지 않는다. 작업이 단순해 보여도 동일.
+
+```
+## 설계 요약
+- 접근: <선택안>
+- 인터페이스: <핵심 시그니처/계약>
+- 모듈 구조 / 의존성 방향: ...
+- 비목표: <안 건드릴 것>
+- 리스크: <남은 위험>
+→ 이 설계로 갈까요? (승인 / 섹션 수정)
+```
+
+### 8. 핸드오프 — 설계 영속화는 기존 채널로
+brainstorm 자체는 별도 설계 파일을 만들지 않는다 (스펙 문서는 `spec` 의 책임). 합의된 설계 요약을 들고:
+- 코드 변경 작업 → **Plan Mode** — plan 파일이 설계의 캐리어가 된다
+- 아키텍처/다중 컴포넌트 규모이거나 스펙 문서로 남겨야 하면 → **`spec:design`** 으로 에스컬레이트
+
+## 종료 조건
+
+- 설계 요약이 승인되어 Plan Mode/`spec` 으로 핸드오프됨
+- 또는 사용자가 방향을 보류/중단
+
+## 예시 (탐색 → 접근법 → 섹션별 검증 → 승인)
+
+사용자: "사용자 활동 로그 같이 brainstorm 하자"
+
+```
+[탐색] 기존 로깅/이벤트 인프라 확인 → src/events/ 에 EventBus 존재, DB 는 sqlite.
+       → "이미 EventBus 가 있어 여기에 얹는 게 자연스럽습니다."
+
+Q1 보존 기간 정책이 있나요?
+   추천: 90일 — 유사 테이블(audit_log)이 90일 보존. prior art 와 일치 권장.
+   → (사용자: 90일 확정)
+
+접근법 제시:
+  A. EventBus 구독자 추가 + 기존 audit_log 테이블 재사용
+     +적은 신규 코드 / -스키마가 audit 용이라 필드 안 맞을 수 있음
+  B. 전용 activity_log 테이블 신규
+     +깔끔한 모델 / -마이그레이션·신규 배선 비용
+  추천: A — 요구가 단순 조회 수준이고 EventBus 재사용으로 표면적 최소.
+  → (사용자: A 선택)
+
+[섹션별 제시] §인터페이스: ActivityLogger.record(event) 계약 → 검증 →
+  §모듈 구조: events/subscribers/activity.rs 단일 책임 → 검증 →
+  §의존성 방향: subscriber → EventBus 추상에만 의존 → 검증 → ...
+  (의존성 방향은 ASCII 다이어그램 제안 → 동의 시 도식화)
+
+[self-review] "retention 90일 삭제 주체가 미정" 발견 → §에러·엣지에 추가 후 재제시
+
+[설계 요약 제시] → "이 설계로 갈까요?" → (승인) → Plan Mode 핸드오프
+```
+
+승인 전에는 어떤 파일도 만들지 않는다.
diff --git a/plugins/atelier/skills/interview/references/grill.md b/plugins/atelier/skills/interview/references/grill.md
new file mode 100644
index 00000000..aef40ba0
--- /dev/null
+++ b/plugins/atelier/skills/interview/references/grill.md
@@ -0,0 +1,70 @@
+# interview — grill 모드
+
+이미 존재하는 plan/design 을 **집요하게 심문**해 공유된 이해에 도달할 때까지 결정 트리의 모든 가지를 해소한다. `interview` SKILL.md 의 공통 원칙(한 번에 하나, 추천 답 동반, 코드베이스 우선 탐색, 승인 전 구현 금지)을 그대로 따른다.
+
+## 언제 쓰나
+
+- 사용자가 "grill me", "이 계획 심문해줘", "내 설계 스트레스 테스트해줘" 라고 요청
+- 이미 작성된 plan / 설계 문서 / 접근안이 있고, 빈틈·암묵적 가정·결정 간 충돌을 드러내고 싶을 때
+
+## 프로세스
+
+### 1. 결정 트리 추출
+대상 plan/design 을 읽고, 내려야 할 **결정(decision)** 들을 트리로 분해한다.
+- 각 노드 = 하나의 결정 (예: "저장소를 Redis 로 할까 in-memory 로 할까")
+- 엣지 = 결정 간 의존성 (상위 결정이 하위 선택지를 제약)
+- 코드베이스로 답이 정해지는 노드(기존 컨벤션·prior art·제약)는 **질문하지 말고 탐색해 확정**하고 그 사실을 명시한다.
+
+### 2. 가지별 순회 — 한 번에 하나씩
+의존성 위상 순서로 루트→리프를 내려가며, 미해소 결정마다:
+1. 결정 지점과 선택지를 1–2줄로 제시
+2. **추천 답과 근거**를 함께 제시 ("내 추천: X — 이유")
+3. 사용자의 답/이견을 받아 확정
+4. 그 결정이 하위 가지를 가지치기하면(선택지 제거) 반영하고 다음으로
+
+질문은 **한 번에 하나만**. 답이 다음 가지의 전제가 되므로 묶어서 묻지 않는다.
+
+### 3. 모순·빈틈 적극 노출
+- 두 결정이 충돌하면(예: "동기 처리" + "10초 타임아웃 금지") 즉시 표면화하고 어느 쪽을 양보할지 묻는다.
+- plan 이 암묵적으로 가정한 것(미언급 전제)을 찾아 명시적 확인을 요청한다.
+- "가장 위험한 오해 후보"를 1개 지목하고 그 부분을 먼저 친다.
+
+## 종료 조건
+
+- 트리의 모든 가지가 (탐색 또는 합의로) 해소됨
+- 또는 사용자가 "충분하다 / 그만" 선언
+
+## 산출물 — 합의된 결정 목록
+
+```
+## 심문 결과 — 합의된 결정
+1. <결정 지점>: <확정 선택> — <근거>
+2. ...
+
+미해소(보류): <있으면 명시, 없으면 "없음">
+다음: 진행 or Plan Mode(코드 변경 설계)로 핸드오프
+```
+
+해소가 끝나면 코드 변경이 필요한 경우 Plan Mode 로, 아키텍처 규모면 `spec:design` 으로 핸드오프한다. 합의 전에는 구현을 시작하지 않는다.
+
+## 예시 (한 가지씩, 추천 답 동반)
+
+사용자: "이 캐시 추가 plan 좀 grill 해줘"
+
+```
+[탐색] 기존 코드에 cache 추상화가 있는지 먼저 확인 → src/cache/ 없음, HTTP 레이어에 직접 fetch.
+       → "현재 캐시 레이어가 없어 신규 도입입니다. 사실로 깔고 갑니다."
+
+Q1 (루트 결정) 캐시 저장소: in-memory vs Redis?
+   추천: in-memory — 단일 인스턴스이고 plan 에 분산 요구가 없음. 분산 전이면 Redis.
+   → (사용자: in-memory) → 하위 가지 "Redis 연결 설정" 가지치기됨
+
+Q2 무효화 전략: TTL vs 명시적 invalidate?
+   추천: TTL — 데이터 신선도 요구가 "분 단위 허용"이라 단순 TTL 로 충분.
+   → (사용자: TTL 60s 확정)
+
+[모순 노출] plan 의 "항상 최신 응답 보장" 문구와 TTL 60s 가 충돌.
+   → 어느 쪽을 양보할지 확인 요청 → (사용자: 60s stale 허용으로 문구 수정)
+```
+
+결과 출력은 위 "합의된 결정 목록" 형식을 따른다.

From 9582ec210ae99150c66fb5d58f8334c2c242f5b9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EA=B9=80=EC=9A=A9=EC=84=B1?=
 <kys0213@gim-yongseong-ui-MacBookPro.local>
Date: Sat, 13 Jun 2026 10:45:36 +0900
Subject: [PATCH 2/7] refactor(atelier): simplify grill reference to original
 instruction form
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The grill-me original derives its power from a single dense instruction, not a procedure. Drop the process steps, contradiction-exposure checklist, output template, and worked example; keep the core instruction (walk the design tree, resolve dependencies one-by-one, recommended answer per question, one at a time, explore codebase instead of asking) plus minimal atelier glue (termination + handoff).

🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
---
 plugins/atelier/skills/interview/SKILL.md     |  2 +-
 .../skills/interview/references/grill.md      | 69 ++-----------------
 2 files changed, 8 insertions(+), 63 deletions(-)

diff --git a/plugins/atelier/skills/interview/SKILL.md b/plugins/atelier/skills/interview/SKILL.md
index 98ddcd7a..58235d96 100644
--- a/plugins/atelier/skills/interview/SKILL.md
+++ b/plugins/atelier/skills/interview/SKILL.md
@@ -81,7 +81,7 @@ A(cceptance)  — "완료" 판정 기준?
 
 | reference | 언제 로드 | 내용 |
 |---|---|---|
-| `references/grill.md` | 기존 plan/design 을 심문(`grill`)할 때 | 결정 트리 순회, 의존성 해소 순서, 종료 조건, 합의 결정 출력 |
+| `references/grill.md` | 기존 plan/design 을 심문(`grill`)할 때 | 심문 지시문(설계 트리 가지별 해소·추천 답·한 번에 하나·코드 탐색 우선) + 종료/핸드오프 |
 | `references/brainstorm.md` | 무에서 설계(`brainstorm`)할 때 | 컨텍스트 탐색 → 명확화 질문 → 2–3 접근법 → 섹션별 설계 검증(+시각화 제안) → self-review → 승인 게이트 → 핸드오프 |
 
 ## 출처
diff --git a/plugins/atelier/skills/interview/references/grill.md b/plugins/atelier/skills/interview/references/grill.md
index aef40ba0..9ab722e3 100644
--- a/plugins/atelier/skills/interview/references/grill.md
+++ b/plugins/atelier/skills/interview/references/grill.md
@@ -1,70 +1,15 @@
 # interview — grill 모드
 
-이미 존재하는 plan/design 을 **집요하게 심문**해 공유된 이해에 도달할 때까지 결정 트리의 모든 가지를 해소한다. `interview` SKILL.md 의 공통 원칙(한 번에 하나, 추천 답 동반, 코드베이스 우선 탐색, 승인 전 구현 금지)을 그대로 따른다.
+기존 plan/design 을 집요하게 심문해 공유된 이해에 도달한다.
 
-## 언제 쓰나
+## 지시
 
-- 사용자가 "grill me", "이 계획 심문해줘", "내 설계 스트레스 테스트해줘" 라고 요청
-- 이미 작성된 plan / 설계 문서 / 접근안이 있고, 빈틈·암묵적 가정·결정 간 충돌을 드러내고 싶을 때
+이 계획의 모든 측면에 대해 **공유된 이해에 도달할 때까지 집요하게 인터뷰하라**. 설계 트리의 각 가지를 내려가며, 결정 사이의 의존성을 하나씩 해소하라. 각 질문마다 추천 답을 함께 제시하라.
 
-## 프로세스
+질문은 한 번에 하나씩만 하라.
 
-### 1. 결정 트리 추출
-대상 plan/design 을 읽고, 내려야 할 **결정(decision)** 들을 트리로 분해한다.
-- 각 노드 = 하나의 결정 (예: "저장소를 Redis 로 할까 in-memory 로 할까")
-- 엣지 = 결정 간 의존성 (상위 결정이 하위 선택지를 제약)
-- 코드베이스로 답이 정해지는 노드(기존 컨벤션·prior art·제약)는 **질문하지 말고 탐색해 확정**하고 그 사실을 명시한다.
+질문이 코드베이스 탐색으로 답해질 수 있다면, 묻지 말고 코드베이스를 탐색하라.
 
-### 2. 가지별 순회 — 한 번에 하나씩
-의존성 위상 순서로 루트→리프를 내려가며, 미해소 결정마다:
-1. 결정 지점과 선택지를 1–2줄로 제시
-2. **추천 답과 근거**를 함께 제시 ("내 추천: X — 이유")
-3. 사용자의 답/이견을 받아 확정
-4. 그 결정이 하위 가지를 가지치기하면(선택지 제거) 반영하고 다음으로
+## 종료와 핸드오프
 
-질문은 **한 번에 하나만**. 답이 다음 가지의 전제가 되므로 묶어서 묻지 않는다.
-
-### 3. 모순·빈틈 적극 노출
-- 두 결정이 충돌하면(예: "동기 처리" + "10초 타임아웃 금지") 즉시 표면화하고 어느 쪽을 양보할지 묻는다.
-- plan 이 암묵적으로 가정한 것(미언급 전제)을 찾아 명시적 확인을 요청한다.
-- "가장 위험한 오해 후보"를 1개 지목하고 그 부분을 먼저 친다.
-
-## 종료 조건
-
-- 트리의 모든 가지가 (탐색 또는 합의로) 해소됨
-- 또는 사용자가 "충분하다 / 그만" 선언
-
-## 산출물 — 합의된 결정 목록
-
-```
-## 심문 결과 — 합의된 결정
-1. <결정 지점>: <확정 선택> — <근거>
-2. ...
-
-미해소(보류): <있으면 명시, 없으면 "없음">
-다음: 진행 or Plan Mode(코드 변경 설계)로 핸드오프
-```
-
-해소가 끝나면 코드 변경이 필요한 경우 Plan Mode 로, 아키텍처 규모면 `spec:design` 으로 핸드오프한다. 합의 전에는 구현을 시작하지 않는다.
-
-## 예시 (한 가지씩, 추천 답 동반)
-
-사용자: "이 캐시 추가 plan 좀 grill 해줘"
-
-```
-[탐색] 기존 코드에 cache 추상화가 있는지 먼저 확인 → src/cache/ 없음, HTTP 레이어에 직접 fetch.
-       → "현재 캐시 레이어가 없어 신규 도입입니다. 사실로 깔고 갑니다."
-
-Q1 (루트 결정) 캐시 저장소: in-memory vs Redis?
-   추천: in-memory — 단일 인스턴스이고 plan 에 분산 요구가 없음. 분산 전이면 Redis.
-   → (사용자: in-memory) → 하위 가지 "Redis 연결 설정" 가지치기됨
-
-Q2 무효화 전략: TTL vs 명시적 invalidate?
-   추천: TTL — 데이터 신선도 요구가 "분 단위 허용"이라 단순 TTL 로 충분.
-   → (사용자: TTL 60s 확정)
-
-[모순 노출] plan 의 "항상 최신 응답 보장" 문구와 TTL 60s 가 충돌.
-   → 어느 쪽을 양보할지 확인 요청 → (사용자: 60s stale 허용으로 문구 수정)
-```
-
-결과 출력은 위 "합의된 결정 목록" 형식을 따른다.
+모든 가지가 해소되면(또는 사용자가 충분하다고 하면) 합의된 결정 목록을 요약한다. 코드 변경이 필요하면 Plan Mode 로, 아키텍처 규모면 `spec:design` 으로 핸드오프한다. 합의 전에는 구현을 시작하지 않는다.

From ccc3040ddcfc49bb30c0b6d2062a20bcf023b29d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EA=B9=80=EC=9A=A9=EC=84=B1?=
 <kys0213@gim-yongseong-ui-MacBookPro.local>
Date: Sat, 13 Jun 2026 10:56:24 +0900
Subject: [PATCH 3/7] refactor(atelier): port brainstorm reference faithfully
 from superpowers original
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The previous thematic rewrite lost substantial original content: scope assessment/decomposition for multi-subsystem requests, the 'too simple to need a design' anti-pattern rationale, task-driven checklist discipline, the process-flow digraph with revise loops, multiple-choice preference, design-for-isolation boundary tests, and existing-codebase rules (targeted improvement, no unrelated refactoring).

Replace it with a faithful Korean port preserving the original's full structure. Only four ecosystem bindings are substituted:
- writing-plans -> Plan Mode handoff
- browser visual companion -> AskUserQuestion(+preview) / markdown / ASCII / mermaid
- checklist -> TaskCreate
- docs/superpowers/specs/ -> project spec convention, with related_paths frontmatter so the atelier spec skill can consume the design doc (gap analysis / review)

Restores the design-doc -> self-review -> user review gate steps (3 of 9 checklist items) dropped earlier; the spec-SRP objection was overzealous since spec owns analysis workflows, not document authorship. MIT attribution header added (close port = substantial portion). SKILL.md boundary table, references guide, and attribution section updated to match.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
---
 plugins/atelier/skills/interview/SKILL.md     |   6 +-
 .../skills/interview/references/brainstorm.md | 200 +++++++++++-------
 2 files changed, 129 insertions(+), 77 deletions(-)

diff --git a/plugins/atelier/skills/interview/SKILL.md b/plugins/atelier/skills/interview/SKILL.md
index 58235d96..e386e237 100644
--- a/plugins/atelier/skills/interview/SKILL.md
+++ b/plugins/atelier/skills/interview/SKILL.md
@@ -73,7 +73,7 @@ A(cceptance)  — "완료" 판정 기준?
 
 | 대상 | interview 와의 차이 | 핸드오프 |
 |---|---|---|
-| `spec:design` | 분기는 **상태 기준**: 의도·요구사항이 아직 모호하면 interview, 의도는 합의됐고 아키텍처 구조(다중 컴포넌트)를 스펙 문서로 잡는 단계면 spec:design. interview 의 산출은 대화 내 합의(미니 명세·설계 요약), spec:design 의 산출은 스펙 문서 | brainstorm 중 아키텍처 규모로 판명되거나 설계의 문서 영속화가 필요하면 `spec:design` 으로 에스컬레이트. 역방향: spec:design 진입 시 의도가 아직 모호하면 interview 를 먼저 권한다 |
+| `spec:design` | 분기는 **상태 기준**: 의도·요구사항이 아직 모호하면 interview, 의도는 합의됐고 아키텍처 구조(다중 컴포넌트)를 잡는 단계면 spec:design. brainstorm 도 설계 문서를 산출하지만 **단일 작업 범위**이며 `related_paths` frontmatter 로 spec 스킬이 소비 가능한 형식으로 쓴다 | brainstorm 중 아키텍처/다중 컴포넌트 규모로 판명되면 `spec:design` 으로 에스컬레이트. 역방향: spec:design 진입 시 의도가 아직 모호하면 interview 를 먼저 권한다 |
 | Plan Mode | interview 는 *무엇을/왜*(의도). Plan Mode 는 *어떻게*(코드 변경 단계 설계) | quick/brainstorm 으로 의도가 확정되고 코드 변경이 필요하면 Plan Mode 로 넘긴다 |
 | `autopilot` | 자율 루프와 무관. interview 는 사람↔에이전트 대화 전용 | 해당 없음 |
 
@@ -82,8 +82,8 @@ A(cceptance)  — "완료" 판정 기준?
 | reference | 언제 로드 | 내용 |
 |---|---|---|
 | `references/grill.md` | 기존 plan/design 을 심문(`grill`)할 때 | 심문 지시문(설계 트리 가지별 해소·추천 답·한 번에 하나·코드 탐색 우선) + 종료/핸드오프 |
-| `references/brainstorm.md` | 무에서 설계(`brainstorm`)할 때 | 컨텍스트 탐색 → 명확화 질문 → 2–3 접근법 → 섹션별 설계 검증(+시각화 제안) → self-review → 승인 게이트 → 핸드오프 |
+| `references/brainstorm.md` | 무에서 설계(`brainstorm`)할 때 | 충실 포팅된 전체 플로우: HARD-GATE·"단순함" 안티패턴·task 체크리스트·스코프 분해 판정 → 명확화(객관식 선호) → 2–3 접근법 → 섹션별 설계(격리 설계·기존 코드 규율) → 설계 문서(related_paths)·self-review·사용자 리뷰 게이트 → Plan Mode 전환·시각 자료 |
 
 ## 출처
 
-`grill`/`brainstorm` 모드의 인터뷰·설계 게이트 개념은 [obra/superpowers](https://github.com/obra/superpowers) (MIT License, © 2025 Jesse Vincent) 의 `brainstorming`·`grill-me` 스킬에서 차용해 atelier 컨벤션·책임 경계에 맞게 재작성했습니다.
+`grill`/`brainstorm` 모드는 [obra/superpowers](https://github.com/obra/superpowers) (MIT License, © 2025 Jesse Vincent) 의 `grill-me`·`brainstorming` 스킬이 원본입니다. grill 은 원본 지시문을 보존했고, brainstorm 은 생태계 바인딩 4곳(writing-plans→Plan Mode, browser visual companion→AskUserQuestion·markdown 다이어그램, 체크리스트→TaskCreate, 문서 위치→프로젝트 spec 컨벤션)만 치환한 충실 포팅입니다. MIT 고지는 `references/brainstorm.md` 머리에 명시되어 있습니다.
diff --git a/plugins/atelier/skills/interview/references/brainstorm.md b/plugins/atelier/skills/interview/references/brainstorm.md
index 1504a51b..3f0c8879 100644
--- a/plugins/atelier/skills/interview/references/brainstorm.md
+++ b/plugins/atelier/skills/interview/references/brainstorm.md
@@ -1,102 +1,154 @@
 # interview — brainstorm 모드
 
-막연한 아이디어를 **검증된 설계**로 함께 발전시킨다. 컨텍스트 탐색에서 출발해 접근법을 비교하고, 설계를 섹션 단위로 검증받고, self-review 와 승인 게이트를 거쳐 구현 단계로 넘긴다. `interview` SKILL.md 의 공통 원칙(한 번에 하나, 추천 답 동반, 코드베이스 우선 탐색, 승인 전 구현 금지)을 그대로 따른다.
-
-## 언제 쓰나
+> Adapted from [obra/superpowers](https://github.com/obra/superpowers) `brainstorming` skill — MIT License, © 2025 Jesse Vincent.
+> 생태계 바인딩 4곳만 atelier 로 치환: writing-plans → Plan Mode / browser visual companion → AskUserQuestion·markdown 다이어그램 / 체크리스트 → TaskCreate / 문서 위치 → 프로젝트 spec 컨벤션.
+
+아이디어를 자연스러운 협업 대화를 통해 완전한 설계와 스펙으로 발전시킨다. 현재 프로젝트 컨텍스트를 이해하는 데서 출발해, 질문을 한 번에 하나씩 던져 아이디어를 다듬는다. 무엇을 만드는지 이해되면 설계를 제시하고 사용자 승인을 받는다.
+
+<HARD-GATE>
+설계를 제시하고 사용자가 승인하기 전까지는 어떤 구현 스킬도 호출하지 말고, 코드를 쓰지 말고, 프로젝트를 스캐폴딩하지 말고, 어떤 구현 행동도 하지 마라. 체감 난이도와 무관하게 모든 프로젝트에 적용된다.
+</HARD-GATE>
+
+## 안티패턴: "이건 너무 단순해서 설계가 필요 없다"
+
+모든 프로젝트가 이 프로세스를 거친다. todo 리스트, 함수 하나짜리 유틸, 설정 변경 — 전부 다. **"단순한" 프로젝트야말로 미검증 가정이 가장 큰 낭비를 만드는 곳이다.** 설계는 짧아도 된다(정말 단순하면 몇 문장이면 충분하다). 하지만 반드시 제시하고 승인을 받아야 한다.
+
+## 체크리스트
+
+아래 각 항목을 **TaskCreate 로 task 로 만들고 순서대로 완료**한다:
+
+1. **프로젝트 컨텍스트 탐색** — 파일, 문서, 최근 커밋 확인
+2. **시각 자료 제안** (시각 질문이 예상될 때) — 다른 내용과 결합하지 않은 별도 메시지로. 아래 "시각 자료" 섹션 참조
+3. **명확화 질문** — 한 번에 하나씩, 목적/제약/성공 기준 이해
+4. **2–3개 접근법 제안** — trade-off 와 추천안 포함
+5. **설계 제시** — 복잡도에 비례한 섹션 단위, 섹션마다 사용자 검증
+6. **설계 문서 작성** — 프로젝트 spec 컨벤션 위치에 저장하고 커밋
+7. **스펙 self-review** — placeholder·모순·모호함·스코프 인라인 점검
+8. **사용자의 스펙 리뷰** — 작성된 문서를 사용자가 검토한 뒤 진행
+9. **구현 전환** — Plan Mode 로 진입해 구현 계획 수립
+
+## Process Flow
+
+```dot
+digraph brainstorming {
+    "프로젝트 컨텍스트 탐색" [shape=box];
+    "시각 질문 예상?" [shape=diamond];
+    "시각 자료 제안\n(별도 메시지, 다른 내용 금지)" [shape=box];
+    "명확화 질문 (하나씩)" [shape=box];
+    "2-3 접근법 제안" [shape=box];
+    "설계 섹션별 제시" [shape=box];
+    "사용자 설계 승인?" [shape=diamond];
+    "설계 문서 작성" [shape=box];
+    "스펙 self-review\n(인라인 수정)" [shape=box];
+    "사용자 스펙 리뷰?" [shape=diamond];
+    "Plan Mode 진입" [shape=doublecircle];
+
+    "프로젝트 컨텍스트 탐색" -> "시각 질문 예상?";
+    "시각 질문 예상?" -> "시각 자료 제안\n(별도 메시지, 다른 내용 금지)" [label="yes"];
+    "시각 질문 예상?" -> "명확화 질문 (하나씩)" [label="no"];
+    "시각 자료 제안\n(별도 메시지, 다른 내용 금지)" -> "명확화 질문 (하나씩)";
+    "명확화 질문 (하나씩)" -> "2-3 접근법 제안";
+    "2-3 접근법 제안" -> "설계 섹션별 제시";
+    "설계 섹션별 제시" -> "사용자 설계 승인?";
+    "사용자 설계 승인?" -> "설계 섹션별 제시" [label="no, 수정"];
+    "사용자 설계 승인?" -> "설계 문서 작성" [label="yes"];
+    "설계 문서 작성" -> "스펙 self-review\n(인라인 수정)";
+    "스펙 self-review\n(인라인 수정)" -> "사용자 스펙 리뷰?";
+    "사용자 스펙 리뷰?" -> "설계 문서 작성" [label="수정 요청"];
+    "사용자 스펙 리뷰?" -> "Plan Mode 진입" [label="승인"];
+}
+```
 
-- "같이 brainstorm 하자", "설계 같이 잡자", "막연한데 방향부터" 처럼 **아직 구체안이 없는** 작업
-- 이미 plan 이 있으면 `grill` 모드로. 의도가 이미 합의됐고 아키텍처 스펙 문서를 잡는 단계면 `spec:design` 으로.
+**종착 상태는 Plan Mode 진입이다.** 다른 어떤 구현 스킬도 호출하지 않는다. brainstorm 이후의 유일한 다음 단계는 Plan Mode 다.
 
 ## 프로세스
 
-### 1. 컨텍스트 탐색 (먼저, 직접)
-질문하기 전에 코드베이스에서 prior art·관련 모듈·기존 컨벤션·영향 범위를 Grep/Read 로 확인한다. 발견한 사실을 "이미 X 패턴이 있습니다" 형태로 먼저 제시한다.
+**아이디어 이해:**
 
-### 2. 명확화 질문 — 한 번에 하나씩
-이해 갭을 메우는 질문을 하나씩 한다. 각 질문에 **추천 답과 근거**를 동반한다. 목적·제약·성공 기준이 드러날 때까지 계속하되, 코드로 답이 정해지는 건 묻지 말고 탐색 결과로 메운다.
+- 현재 프로젝트 상태(파일, 문서, 최근 커밋)를 먼저 확인한다
+- 상세 질문 전에 **스코프를 판정**한다: 요청이 여러 독립 서브시스템을 담고 있으면(예: "채팅 + 파일 저장 + 빌링 + 분석이 있는 플랫폼") 즉시 플래그한다. **분해가 먼저 필요한 프로젝트의 디테일을 다듬는 데 질문을 낭비하지 마라.**
+- 단일 스펙에 담기엔 큰 프로젝트면 사용자와 함께 서브프로젝트로 분해한다: 독립적인 조각은 무엇인가, 서로 어떻게 연결되나, 어떤 순서로 만들어야 하나. 그 다음 첫 서브프로젝트를 정상 설계 플로우로 brainstorm 한다. 각 서브프로젝트는 자기만의 스펙 → 계획 → 구현 사이클을 가진다
+- 적절한 스코프의 프로젝트는 질문을 한 번에 하나씩 던져 아이디어를 다듬는다
+- 가능하면 객관식을 선호한다 (AskUserQuestion 활용) — 주관식도 괜찮다
+- 메시지당 질문 하나 — 주제에 더 깊은 탐색이 필요하면 여러 질문으로 쪼갠다
+- 이해의 초점: 목적, 제약, 성공 기준
 
-### 3. 접근법 2–3개 + trade-off
-설계 공간이 좁혀지면 **서로 다른 접근법 2–3개**를 제시한다.
-- 각 접근의 핵심 아이디어 / 장점 / 비용·리스크 / 적합 조건
-- 그중 **추천안과 이유**를 명시한다. 사용자가 선택하면 다음 단계로.
+**접근법 탐색:**
 
-### 4. 설계 제시 — 섹션 단위 검증
-선택된 방향을 **한 번에 쏟지 않고 섹션 단위로** 제시하고, 섹션마다 사용자 검증을 받은 뒤 다음으로 간다. 섹션 구성은 설계 산출물 3요소(인터페이스 정의·모듈 구조·의존성 방향)를 반드시 포함한다:
+- 서로 다른 접근법 2–3개를 trade-off 와 함께 제안한다
+- 대화체로 제시하되 추천안과 그 이유를 명시한다
+- 추천안을 먼저 제시하고 왜인지 설명한다
 
-1. 목적·범위 (비목표 포함)
-2. **인터페이스 정의** — 공개 API / 시그니처 / 계약
-3. **모듈 구조** — 책임 분리
-4. **의존성 방향** — 무엇이 무엇에 의존하는가
-5. 에러·엣지 케이스
-6. 영향 범위·리스크
+**설계 제시:**
 
-### 5. 시각화 (조건부 제안)
-텍스트보다 시각 표현이 이해를 명확히 돕는 섹션(구조 비교·흐름·대안 대조)에서는 **먼저 제안하고 동의를 받은 뒤** 사용한다:
-- markdown 표 / ASCII·mermaid 다이어그램 — 모듈 구조, 의존성 방향, 흐름
-- AskUserQuestion 의 preview — 대안 2–3개를 나란히 비교시킬 때
+- 무엇을 만드는지 이해됐다고 믿으면 설계를 제시한다
+- 각 섹션을 복잡도에 비례해 조절한다: 단순하면 몇 문장, 미묘하면 200–300단어까지
+- 각 섹션 후 여기까지 맞는지 확인한다
+- 다룰 것: 아키텍처, 컴포넌트, 데이터 흐름, 에러 처리, 테스트
+- 뭔가 말이 안 되면 되돌아가 명확히 할 준비를 한다
 
-모든 섹션에 강제하지 않는다. 시각화가 더해주는 게 없으면 텍스트로 간다.
+**격리와 명료함을 위한 설계:**
 
-### 6. 설계 self-review
-최종 승인을 요청하기 직전 스스로 점검한다:
-- 섹션 간 모순은 없는가
-- 검증 안 된 가정이 사실처럼 적혀 있지 않은가
-- 요청하지 않은 추상화(YAGNI 위반)가 끼어들지 않았는가
-- 빠뜨린 엣지·사이드이펙트는 없는가
+- 시스템을 작은 단위로 쪼갠다. 각 단위는 하나의 명확한 목적을 갖고, 잘 정의된 인터페이스로 통신하며, 독립적으로 이해·테스트 가능해야 한다
+- 각 단위에 대해 답할 수 있어야 한다: 무엇을 하는가, 어떻게 쓰는가, 무엇에 의존하는가
+- 내부를 읽지 않고 단위가 뭘 하는지 이해할 수 있는가? 내부를 바꿔도 소비자가 깨지지 않는가? 아니라면 경계를 다시 잡아야 한다
+- 작고 경계가 분명한 단위는 에이전트 자신에게도 유리하다 — 한 번에 컨텍스트에 담을 수 있는 코드를 더 잘 추론하고, 파일이 집중되어 있을수록 편집이 더 신뢰할 만하다. 파일이 커지고 있다면 너무 많은 일을 하고 있다는 신호인 경우가 많다
+- 이 지향은 atelier 의 SOLID 원칙(`coding-style` skill)과 동일하다 — 설계 단계에서 SRP/ISP/DIP 를 미리 적용하는 것
 
-발견하면 해당 섹션을 수정해 다시 제시한다.
+**기존 코드베이스에서 작업:**
 
-### 7. 승인 게이트 (Hard Gate)
-전체 설계 요약을 제시하고 **명시적 승인**을 받는다. 승인 전에는 코드 작성·스캐폴딩·파일 변경을 시작하지 않는다. 작업이 단순해 보여도 동일.
+- 변경을 제안하기 전에 현재 구조를 탐색한다. 기존 패턴을 따른다
+- 기존 코드의 문제가 이번 작업에 영향을 주는 경우(너무 커진 파일, 불분명한 경계, 얽힌 책임)에는 targeted improvement 를 설계에 포함한다 — 좋은 개발자가 자기가 작업하는 코드를 개선하는 방식으로
+- 무관한 리팩터링은 제안하지 않는다. 현재 목표에 복무하는 것에 집중한다
 
-```
-## 설계 요약
-- 접근: <선택안>
-- 인터페이스: <핵심 시그니처/계약>
-- 모듈 구조 / 의존성 방향: ...
-- 비목표: <안 건드릴 것>
-- 리스크: <남은 위험>
-→ 이 설계로 갈까요? (승인 / 섹션 수정)
-```
+## 설계 이후
 
-### 8. 핸드오프 — 설계 영속화는 기존 채널로
-brainstorm 자체는 별도 설계 파일을 만들지 않는다 (스펙 문서는 `spec` 의 책임). 합의된 설계 요약을 들고:
-- 코드 변경 작업 → **Plan Mode** — plan 파일이 설계의 캐리어가 된다
-- 아키텍처/다중 컴포넌트 규모이거나 스펙 문서로 남겨야 하면 → **`spec:design`** 으로 에스컬레이트
+**문서화:**
 
-## 종료 조건
+- 검증된 설계(스펙)를 프로젝트의 spec 컨벤션 위치에 작성한다 (컨벤션이 없으면 사용자에게 위치를 확인한다 — 사용자 선호가 항상 우선)
+- frontmatter 에 **`related_paths`** 를 포함한다 — atelier `spec` 스킬(갭 분석·리뷰)이 이 문서를 그대로 소비할 수 있게 된다
+- 설계 문서를 git 워크플로우 컨벤션에 따라 커밋한다
 
-- 설계 요약이 승인되어 Plan Mode/`spec` 으로 핸드오프됨
-- 또는 사용자가 방향을 보류/중단
+**스펙 self-review:**
+스펙 문서를 쓴 뒤 새로운 눈으로 본다:
 
-## 예시 (탐색 → 접근법 → 섹션별 검증 → 승인)
+1. **Placeholder 스캔**: "TBD", "TODO", 미완성 섹션, 모호한 요구사항이 있는가? 고친다
+2. **내부 일관성**: 섹션끼리 모순되는가? 아키텍처가 기능 설명과 일치하는가?
+3. **스코프 점검**: 단일 구현 계획에 담길 만큼 집중되어 있는가, 분해가 필요한가?
+4. **모호함 점검**: 두 가지로 해석될 수 있는 요구사항이 있는가? 있으면 하나를 골라 명시한다
 
-사용자: "사용자 활동 로그 같이 brainstorm 하자"
+발견한 문제는 인라인으로 고친다. 재리뷰는 불필요 — 고치고 넘어간다.
 
-```
-[탐색] 기존 로깅/이벤트 인프라 확인 → src/events/ 에 EventBus 존재, DB 는 sqlite.
-       → "이미 EventBus 가 있어 여기에 얹는 게 자연스럽습니다."
+**사용자 리뷰 게이트:**
+self-review 가 끝나면 진행 전에 사용자에게 작성된 스펙 리뷰를 요청한다:
 
-Q1 보존 기간 정책이 있나요?
-   추천: 90일 — 유사 테이블(audit_log)이 90일 보존. prior art 와 일치 권장.
-   → (사용자: 90일 확정)
+> "스펙을 `<경로>` 에 작성하고 커밋했습니다. 구현 계획을 잡기 전에 검토하시고 수정할 부분이 있으면 알려주세요."
 
-접근법 제시:
-  A. EventBus 구독자 추가 + 기존 audit_log 테이블 재사용
-     +적은 신규 코드 / -스키마가 audit 용이라 필드 안 맞을 수 있음
-  B. 전용 activity_log 테이블 신규
-     +깔끔한 모델 / -마이그레이션·신규 배선 비용
-  추천: A — 요구가 단순 조회 수준이고 EventBus 재사용으로 표면적 최소.
-  → (사용자: A 선택)
+사용자의 응답을 기다린다. 수정 요청이 오면 반영하고 self-review 를 다시 돈다. 사용자가 승인한 뒤에만 진행한다.
 
-[섹션별 제시] §인터페이스: ActivityLogger.record(event) 계약 → 검증 →
-  §모듈 구조: events/subscribers/activity.rs 단일 책임 → 검증 →
-  §의존성 방향: subscriber → EventBus 추상에만 의존 → 검증 → ...
-  (의존성 방향은 ASCII 다이어그램 제안 → 동의 시 도식화)
+**구현 전환:**
 
-[self-review] "retention 90일 삭제 주체가 미정" 발견 → §에러·엣지에 추가 후 재제시
+- **Plan Mode 로 진입**해 상세 구현 계획을 수립한다
+- 다른 스킬을 호출하지 않는다. Plan Mode 가 다음 단계다. 아키텍처/다중 컴포넌트 스펙 작업으로 커졌으면 `spec:design` 으로 에스컬레이트한다
 
-[설계 요약 제시] → "이 설계로 갈까요?" → (승인) → Plan Mode 핸드오프
-```
+## 핵심 원칙
+
+- **질문은 한 번에 하나** — 여러 질문으로 압도하지 않는다
+- **객관식 선호** — 가능하면 주관식보다 답하기 쉽다 (AskUserQuestion)
+- **가차없는 YAGNI** — 모든 설계에서 불필요한 기능을 제거한다
+- **대안 탐색** — 정하기 전에 항상 2–3개 접근법을 제안한다
+- **점진적 검증** — 설계를 제시하고 승인받은 뒤 다음으로 간다
+- **유연하게** — 말이 안 되면 되돌아가 명확히 한다
+
+## 시각 자료
+
+brainstorm 중 목업·다이어그램·시각적 대안을 보여주는 도구다. **도구이지 모드가 아니다** — 사용자가 동의해도 모든 질문이 시각 자료를 거치는 게 아니라, 시각적 처리가 도움이 되는 질문에만 쓸 수 있게 되는 것이다.
+
+**제안하기:** 앞으로의 질문에 시각 콘텐츠(목업, 레이아웃, 다이어그램)가 필요할 것 같으면 동의를 한 번 구한다. **이 제안은 반드시 별도 메시지여야 한다** — 명확화 질문, 컨텍스트 요약, 다른 어떤 내용과도 결합하지 않는다. 거절하면 텍스트로만 진행한다.
+
+**질문별 판단:** 동의를 받았어도 **질문마다** 시각이냐 텍스트냐를 따로 결정한다. 기준: **읽는 것보다 보는 것이 이해에 더 나은가?**
+
+- **시각으로**: 내용 자체가 시각적인 것 — 목업, 레이아웃 비교, 모듈 구조·의존성·흐름 다이어그램 → markdown 표 / ASCII / mermaid. 대안 2–3개를 나란히 비교시킬 땐 AskUserQuestion 의 preview
+- **텍스트로**: 내용이 텍스트인 것 — 요구사항 질문, 개념 선택, trade-off 목록, 스코프 결정
 
-승인 전에는 어떤 파일도 만들지 않는다.
+UI 주제에 대한 질문이라고 자동으로 시각 질문인 건 아니다. "이 맥락에서 personality 가 무슨 뜻인가요?"는 개념 질문이라 텍스트로, "어느 wizard 레이아웃이 나은가요?"는 시각 질문이라 다이어그램으로 간다.

From 1b87a666af1e3d210e23f83f1b39943daa0d91cf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EA=B9=80=EC=9A=A9=EC=84=B1?=
 <kys0213@gim-yongseong-ui-MacBookPro.local>
Date: Sat, 13 Jun 2026 11:10:02 +0900
Subject: [PATCH 4/7] refactor(atelier): make grill the default inline mode,
 drop quick scaffolding
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Restructure the interview skill so the skill body serves the post-invocation reader, not the should-I-invoke decision (that is the frontmatter description's job).

- grill becomes the default inline behavior (absorbs references/grill.md, which is removed)
- brainstorm stays as the only reference, loaded for from-scratch design
- drop the quick/RG-CN-A mode: it was a #713 addition absent from the source skills and overlaps with grill's interrogate-to-shared-understanding
- drop the design-first rationale (CLAUDE.md owns it) and the body auto-trigger / skip tables (the description drives invocation; repeating them in the body once loaded is redundant)
- keep the responsibility-boundary table and source attribution

SKILL.md is now ~40 lines; the validator's 50-line minimum is a non-blocking warning (main.go exits non-zero only on failures), so CI stays green.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
---
 plugins/atelier/skills/interview/SKILL.md     | 85 ++++---------------
 .../skills/interview/references/grill.md      | 15 ----
 2 files changed, 18 insertions(+), 82 deletions(-)
 delete mode 100644 plugins/atelier/skills/interview/references/grill.md

diff --git a/plugins/atelier/skills/interview/SKILL.md b/plugins/atelier/skills/interview/SKILL.md
index e386e237..eff1021d 100644
--- a/plugins/atelier/skills/interview/SKILL.md
+++ b/plugins/atelier/skills/interview/SKILL.md
@@ -1,89 +1,40 @@
 ---
 name: interview
-description: 작업 착수 전 의도·설계를 사람과 합의하는 인터뷰 메타스킬. "의도부터 확정하자", "grill me / 이 계획 심문해줘 / 스트레스 테스트", "같이 brainstorm 하자 / 설계 같이 잡자" 같은 요청에 사용합니다. 슬래시로 직접 호출하거나 모델이 모호한 요청을 감지하면 사용을 제안하며, quick(의도 확정)·grill(기존 계획 심문)·brainstorm(무에서 설계) 모드로 라우팅합니다.
+description: 작업 착수 전 계획·설계를 사람과 대화로 다지는 인터뷰 메타스킬. "grill me / 이 계획 심문해줘 / 스트레스 테스트해줘", "같이 brainstorm 하자 / 설계 같이 잡자 / 막연한데 방향 잡아줘" 같은 요청에 사용합니다. 슬래시로 직접 호출하거나 모델이 모호한 요청을 감지하면 사용을 제안합니다. 기본은 기존 계획을 심문(grill)하고, 무에서 설계를 시작할 땐 brainstorm 으로 전환합니다.
 version: 1.0.0
 ---
 
 # interview
 
-코드를 건드리기 **전에** 의도·제약·완료 기준을 사람과 합의해 오해와 오버엔지니어링을 차단하는 단일 진입점입니다. atelier 의 **설계 최우선(Design First)** 원칙을 대화 단계에서 강제합니다.
+코드를 건드리기 전에 계획·설계를 사람과 대화로 다진다. 두 모드가 있다.
 
-사용자가 interview 슬래시로 진입하거나 모델이 맥락에서 자동 호출하며, 자연어 의도를 분류해 아래 모드로 디스패치합니다.
-
-## 진입 라우팅 (의도 → 모드)
-
-| 사용자 의도 (예) | 모드 | 로드할 reference |
+| 의도 | 모드 | 동작 |
 |---|---|---|
-| "이거 정리/개선해줘"(모호), "뭐부터 할지 의도부터", 단발 작업 착수 | `quick` (기본) | (인라인) |
-| "grill me", "이 계획 심문해줘", "내 plan 스트레스 테스트", 기존 설계 검증 | `grill` | `references/grill.md` |
-| "같이 brainstorm", "설계 같이 잡자", "막연한데 방향 잡아줘", 무에서 설계 | `brainstorm` | `references/brainstorm.md` |
-
-입력 인자(대상 파일·기존 plan 경로 등)가 함께 오면 그대로 사용하고, 없으면 직접 묻습니다. 결정적 동작은 없으며 전부 **판단/대화**입니다.
-
-## 공통 원칙 (3모드 공유)
-
-1. **질문은 한 번에 하나씩** — 한꺼번에 쏟지 않는다. 답을 받아 다음 가지를 정한다.
-2. **각 질문마다 추천 답을 함께 제시** — 사용자가 0부터 생각하지 않게, "내 추천은 X (이유)" 형태로 default 를 제안.
-3. **코드베이스로 답할 수 있으면 질문하지 말고 탐색한다** — prior art·기존 컨벤션·영향 범위는 Grep/Read 로 직접 확인 후 사실로 제시. 사람의 시간은 *판단이 필요한 지점*에만 쓴다.
-4. **승인 전 구현 금지 (Hard Gate)** — 미니 명세/설계를 제시하고 사용자가 "go"(또는 승인)하기 전에는 코드 작성·스캐폴딩·파일 변경을 시작하지 않는다. 작업이 단순해 보여도 동일하게 적용한다.
-
-## quick 모드 (기본) — RG-CN-A 의도 확정
+| 이미 계획/설계/접근안이 있고 빈틈을 찾고 싶다 (기본) | grill | 아래 인라인 지시 |
+| 아직 구체안이 없어 무에서 설계를 시작한다 | brainstorm | `references/brainstorm.md` 로드 |
 
-단발 작업의 의도를 3–5분 안에 확정한다. 아래 5개 축을 **순서대로, 한 번에 하나씩** 확인하되, 코드베이스로 답 가능한 항목은 먼저 탐색해 "내가 확인한 사실"로 제시하고 사용자에겐 판단만 요청한다.
+요청이 "막연한 아이디어 → 설계"면 brainstorm, "이 계획 검증/심문"이면 grill 이다. 헷갈리면 사용자에게 한 번 확인한다.
 
-```
-R(estate)     — 내가 이해한 요청 = ... (2~3 bullet 로 재진술)
-G(oal)        — 진짜 달성하려는 건? 왜 이걸 하는가
-C(onstraints) — 지켜야 할 컨벤션/제약? (있으면 코드베이스에서 먼저 탐색)
-N(on-goals)   — 명시적으로 안 건드릴 것?
-A(cceptance)  — "완료" 판정 기준?
-```
+## grill (기본)
 
-옵션 항목 (5축 사이의 고정 위치에 삽입):
-- **Prior art**: C(onstraints) 확인 **전에** 코드베이스를 직접 탐색해 비슷한 패턴을 사실로 제시 (질문 아님)
-- **Risk surface**: A(cceptance) 까지 끝난 **뒤**, 다중 해석·넓은 영향 같은 위험 신호가 남아 있으면 마지막 1회 "가장 위험한 오해 후보"를 확인
+이 계획의 모든 측면에 대해 **공유된 이해에 도달할 때까지 집요하게 인터뷰하라**. 설계 트리의 각 가지를 내려가며, 결정 사이의 의존성을 하나씩 해소하라. 각 질문마다 추천 답을 함께 제시하라.
 
-### quick 산출물 — 5줄 미니 명세
-확인이 끝나면 아래를 출력하고 사용자의 "go" 를 기다린다.
+질문은 한 번에 하나씩만 하라.
 
-```
-요청(R): ...
-목표(G): ...
-제약(C): ...
-비목표(N): ...
-완료(A): ...
-→ 이대로 진행할까요? ("go" 또는 수정사항)
-```
+질문이 코드베이스 탐색으로 답해질 수 있다면, 묻지 말고 코드베이스를 탐색하라.
 
-## 자동 발동 트리거 (모델이 호출 제안)
+### 종료와 핸드오프
 
-다음 신호 중 하나 이상이면 사용자에게 interview 사용을 **제안**한다 (강제하지 않음):
-- 동사가 추상적: "정리", "개선", "최적화", "리팩터"
-- 객체가 모호하거나 다중 해석 가능
-- 영향 범위가 5+ 파일로 추정됨
-- 새 기능/리팩터 키워드 + 컨벤션·제약 미언급
-
-## Skip 조건 (발동하지 않음)
-
-- 한 줄 수정, 오타, 단순 조회
-- 사용자가 "그냥 해" 류 빠른 진행을 명시
-- 이미 Plan Mode / `spec` 설계에 진입한 상태 (중복 게이트 방지)
-
-## 책임 경계 (중복 방지)
-
-| 대상 | interview 와의 차이 | 핸드오프 |
-|---|---|---|
-| `spec:design` | 분기는 **상태 기준**: 의도·요구사항이 아직 모호하면 interview, 의도는 합의됐고 아키텍처 구조(다중 컴포넌트)를 잡는 단계면 spec:design. brainstorm 도 설계 문서를 산출하지만 **단일 작업 범위**이며 `related_paths` frontmatter 로 spec 스킬이 소비 가능한 형식으로 쓴다 | brainstorm 중 아키텍처/다중 컴포넌트 규모로 판명되면 `spec:design` 으로 에스컬레이트. 역방향: spec:design 진입 시 의도가 아직 모호하면 interview 를 먼저 권한다 |
-| Plan Mode | interview 는 *무엇을/왜*(의도). Plan Mode 는 *어떻게*(코드 변경 단계 설계) | quick/brainstorm 으로 의도가 확정되고 코드 변경이 필요하면 Plan Mode 로 넘긴다 |
-| `autopilot` | 자율 루프와 무관. interview 는 사람↔에이전트 대화 전용 | 해당 없음 |
+모든 가지가 해소되면(또는 사용자가 충분하다고 하면) 합의된 결정 목록을 요약한다. 코드 변경이 필요하면 Plan Mode 로, 아키텍처 규모면 `spec:design` 으로 핸드오프한다. 합의 전에는 구현을 시작하지 않는다.
 
-## references 로드 가이드
+## 책임 경계
 
-| reference | 언제 로드 | 내용 |
+| 대상 | 차이 | 핸드오프 |
 |---|---|---|
-| `references/grill.md` | 기존 plan/design 을 심문(`grill`)할 때 | 심문 지시문(설계 트리 가지별 해소·추천 답·한 번에 하나·코드 탐색 우선) + 종료/핸드오프 |
-| `references/brainstorm.md` | 무에서 설계(`brainstorm`)할 때 | 충실 포팅된 전체 플로우: HARD-GATE·"단순함" 안티패턴·task 체크리스트·스코프 분해 판정 → 명확화(객관식 선호) → 2–3 접근법 → 섹션별 설계(격리 설계·기존 코드 규율) → 설계 문서(related_paths)·self-review·사용자 리뷰 게이트 → Plan Mode 전환·시각 자료 |
+| `spec:design` | 의도·요구사항이 아직 모호하면 interview, 의도는 합의됐고 아키텍처 구조(다중 컴포넌트)를 잡는 단계면 spec:design. brainstorm 도 설계 문서를 산출하지만 **단일 작업 범위**이며 `related_paths` frontmatter 로 spec 스킬이 소비 가능한 형식으로 쓴다 | brainstorm 중 아키텍처/다중 컴포넌트 규모로 판명되면 `spec:design` 으로 에스컬레이트 |
+| Plan Mode | interview 는 *무엇을/왜*(의도·설계 합의), Plan Mode 는 *어떻게*(코드 변경 단계) | 의도가 확정되고 코드 변경이 필요하면 Plan Mode 로 넘긴다 |
+| `autopilot` | 자율 루프와 무관, 사람↔에이전트 대화 전용 | 해당 없음 |
 
 ## 출처
 
-`grill`/`brainstorm` 모드는 [obra/superpowers](https://github.com/obra/superpowers) (MIT License, © 2025 Jesse Vincent) 의 `grill-me`·`brainstorming` 스킬이 원본입니다. grill 은 원본 지시문을 보존했고, brainstorm 은 생태계 바인딩 4곳(writing-plans→Plan Mode, browser visual companion→AskUserQuestion·markdown 다이어그램, 체크리스트→TaskCreate, 문서 위치→프로젝트 spec 컨벤션)만 치환한 충실 포팅입니다. MIT 고지는 `references/brainstorm.md` 머리에 명시되어 있습니다.
+`grill`·`brainstorm` 은 [obra/superpowers](https://github.com/obra/superpowers) (MIT License, © 2025 Jesse Vincent) 의 `grill-me`·`brainstorming` 스킬이 원본입니다. grill 은 원본 지시문을 보존했고, brainstorm 은 생태계 바인딩 4곳(writing-plans→Plan Mode, browser visual companion→AskUserQuestion·markdown 다이어그램, 체크리스트→TaskCreate, 문서 위치→프로젝트 spec 컨벤션)만 치환한 충실 포팅입니다. MIT 고지는 `references/brainstorm.md` 머리에 명시되어 있습니다.
diff --git a/plugins/atelier/skills/interview/references/grill.md b/plugins/atelier/skills/interview/references/grill.md
deleted file mode 100644
index 9ab722e3..00000000
--- a/plugins/atelier/skills/interview/references/grill.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# interview — grill 모드
-
-기존 plan/design 을 집요하게 심문해 공유된 이해에 도달한다.
-
-## 지시
-
-이 계획의 모든 측면에 대해 **공유된 이해에 도달할 때까지 집요하게 인터뷰하라**. 설계 트리의 각 가지를 내려가며, 결정 사이의 의존성을 하나씩 해소하라. 각 질문마다 추천 답을 함께 제시하라.
-
-질문은 한 번에 하나씩만 하라.
-
-질문이 코드베이스 탐색으로 답해질 수 있다면, 묻지 말고 코드베이스를 탐색하라.
-
-## 종료와 핸드오프
-
-모든 가지가 해소되면(또는 사용자가 충분하다고 하면) 합의된 결정 목록을 요약한다. 코드 변경이 필요하면 Plan Mode 로, 아키텍처 규모면 `spec:design` 으로 핸드오프한다. 합의 전에는 구현을 시작하지 않는다.

From 1b0ce6d4b0ab1aac2d61433368f707f8d24b9c78 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EA=B9=80=EC=9A=A9=EC=84=B1?=
 <kys0213@gim-yongseong-ui-MacBookPro.local>
Date: Sat, 13 Jun 2026 11:26:01 +0900
Subject: [PATCH 5/7] refactor(atelier): split design dialogue (interview) from
 spec authoring (spec write)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

spec:design bundled two concerns: the design *dialogue* (ping-pong + 6 perspectives + convergence) and the spec *document authoring* convention (DESIGN/concerns/flows templates). The dialogue overlapped with the new interview skill, leaving an ambiguous boundary.

Resolve by concern:
- interview owns the design dialogue (brainstorm: from-scratch, grill: challenge an existing plan)
- spec owns document authoring: rename design/design-detail -> write/write-detail, reframe design-protocol.md -> authoring.md (depth criteria, output templates, related_paths, save rules)

Remove the 6-perspective model (S/O/F/B/C/M) entirely: S/O/B duplicate CLAUDE.md SOLID and brainstorm's isolation/YAGNI lenses, F is covered by Fail Fast; concurrency/operability vary by goal and are added per-objective rather than as a fixed lens. The ping-pong loop and perspective-threshold convergence are dropped with it.

brainstorm no longer defines its own doc format — it defers to spec's write convention and only persists a doc when a long-lived spec is needed (otherwise the Plan Mode plan file carries the design). Cross-references updated: interview boundary table, spec routing/description/references guide, handoff lines. design-protocol.md removed; no residual referrers (verified).

🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
---
 plugins/atelier/skills/interview/SKILL.md     |   4 +-
 .../skills/interview/references/brainstorm.md |  11 +-
 plugins/atelier/skills/spec/SKILL.md          |  10 +-
 .../skills/spec/references/authoring.md       | 134 ++++++++++
 .../skills/spec/references/design-protocol.md | 236 ------------------
 5 files changed, 147 insertions(+), 248 deletions(-)
 create mode 100644 plugins/atelier/skills/spec/references/authoring.md
 delete mode 100644 plugins/atelier/skills/spec/references/design-protocol.md

diff --git a/plugins/atelier/skills/interview/SKILL.md b/plugins/atelier/skills/interview/SKILL.md
index eff1021d..80365034 100644
--- a/plugins/atelier/skills/interview/SKILL.md
+++ b/plugins/atelier/skills/interview/SKILL.md
@@ -25,13 +25,13 @@ version: 1.0.0
 
 ### 종료와 핸드오프
 
-모든 가지가 해소되면(또는 사용자가 충분하다고 하면) 합의된 결정 목록을 요약한다. 코드 변경이 필요하면 Plan Mode 로, 아키텍처 규모면 `spec:design` 으로 핸드오프한다. 합의 전에는 구현을 시작하지 않는다.
+모든 가지가 해소되면(또는 사용자가 충분하다고 하면) 합의된 결정 목록을 요약한다. 코드 변경이 필요하면 Plan Mode 로, 합의된 설계를 스펙 문서로 남겨야 하면 `spec` 의 `write` 로 핸드오프한다. 합의 전에는 구현을 시작하지 않는다.
 
 ## 책임 경계
 
 | 대상 | 차이 | 핸드오프 |
 |---|---|---|
-| `spec:design` | 의도·요구사항이 아직 모호하면 interview, 의도는 합의됐고 아키텍처 구조(다중 컴포넌트)를 잡는 단계면 spec:design. brainstorm 도 설계 문서를 산출하지만 **단일 작업 범위**이며 `related_paths` frontmatter 로 spec 스킬이 소비 가능한 형식으로 쓴다 | brainstorm 중 아키텍처/다중 컴포넌트 규모로 판명되면 `spec:design` 으로 에스컬레이트 |
+| `spec` | **대화 ≠ 문서**. interview 는 설계를 *대화로 합의*(brainstorm: 무에서 / grill: 기존 계획 도전)하고, spec(`write`)은 *합의된 설계를 스펙 문서로 형식화*(DESIGN/concerns/flows)하고 리뷰·갭 분석한다 | 합의된 설계를 장기 스펙 문서로 남길 땐 spec `write` 로, 단일 작업 구현은 Plan Mode 로 |
 | Plan Mode | interview 는 *무엇을/왜*(의도·설계 합의), Plan Mode 는 *어떻게*(코드 변경 단계) | 의도가 확정되고 코드 변경이 필요하면 Plan Mode 로 넘긴다 |
 | `autopilot` | 자율 루프와 무관, 사람↔에이전트 대화 전용 | 해당 없음 |
 
diff --git a/plugins/atelier/skills/interview/references/brainstorm.md b/plugins/atelier/skills/interview/references/brainstorm.md
index 3f0c8879..eea73a43 100644
--- a/plugins/atelier/skills/interview/references/brainstorm.md
+++ b/plugins/atelier/skills/interview/references/brainstorm.md
@@ -22,7 +22,7 @@
 3. **명확화 질문** — 한 번에 하나씩, 목적/제약/성공 기준 이해
 4. **2–3개 접근법 제안** — trade-off 와 추천안 포함
 5. **설계 제시** — 복잡도에 비례한 섹션 단위, 섹션마다 사용자 검증
-6. **설계 문서 작성** — 프로젝트 spec 컨벤션 위치에 저장하고 커밋
+6. **설계 문서 작성** (장기 스펙이 필요할 때만) — `spec` 의 `write` 컨벤션을 따라 작성·커밋
 7. **스펙 self-review** — placeholder·모순·모호함·스코프 인라인 점검
 8. **사용자의 스펙 리뷰** — 작성된 문서를 사용자가 검토한 뒤 진행
 9. **구현 전환** — Plan Mode 로 진입해 구현 계획 수립
@@ -103,11 +103,10 @@ digraph brainstorming {
 
 ## 설계 이후
 
-**문서화:**
+**문서화:** (장기 스펙 문서가 필요할 때만)
 
-- 검증된 설계(스펙)를 프로젝트의 spec 컨벤션 위치에 작성한다 (컨벤션이 없으면 사용자에게 위치를 확인한다 — 사용자 선호가 항상 우선)
-- frontmatter 에 **`related_paths`** 를 포함한다 — atelier `spec` 스킬(갭 분석·리뷰)이 이 문서를 그대로 소비할 수 있게 된다
-- 설계 문서를 git 워크플로우 컨벤션에 따라 커밋한다
+- 문서 작성은 **`spec` 스킬의 `write` 컨벤션**(`spec/references/authoring.md`)을 따른다 — 깊이 기준·출력 구조(DESIGN/concerns/flows)·`related_paths`·저장 경로 규약이 거기에 있다. brainstorm 은 합의된 설계를 그 컨벤션으로 형식화한다 (문서 형식을 자체 정의하지 않는다)
+- 단순 작업이라 장기 스펙이 불필요하면 이 단계를 건너뛰고 바로 구현 전환으로 간다 — 설계는 Plan Mode 의 plan 파일이 담는다
 
 **스펙 self-review:**
 스펙 문서를 쓴 뒤 새로운 눈으로 본다:
@@ -129,7 +128,7 @@ self-review 가 끝나면 진행 전에 사용자에게 작성된 스펙 리뷰
 **구현 전환:**
 
 - **Plan Mode 로 진입**해 상세 구현 계획을 수립한다
-- 다른 스킬을 호출하지 않는다. Plan Mode 가 다음 단계다. 아키텍처/다중 컴포넌트 스펙 작업으로 커졌으면 `spec:design` 으로 에스컬레이트한다
+- 다른 스킬을 호출하지 않는다. Plan Mode 가 다음 단계다. 합의된 설계를 장기 스펙 문서로 남겨야 하면 `spec` 의 `write` 로 형식화한다
 
 ## 핵심 원칙
 
diff --git a/plugins/atelier/skills/spec/SKILL.md b/plugins/atelier/skills/spec/SKILL.md
index 68bbb82f..a7f66813 100644
--- a/plugins/atelier/skills/spec/SKILL.md
+++ b/plugins/atelier/skills/spec/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: spec
-description: 스펙 설계·리뷰·갭 분석의 단일 진입점. "스펙 리뷰해줘", "spec↔code 갭 봐줘", "설계하자/큰그림 잡자", "컴포넌트 상세 설계", "외부 spec 에 related_paths 주석" 같은 요청에 사용합니다. 슬래시로 직접 호출하거나 맥락에서 모델이 자동 호출합니다. L1(관찰)→L2(종합)→audit(감사) 레이어로 file:line 인용 기반 분석.
+description: 스펙 문서 작성·리뷰·갭 분석의 단일 진입점. "스펙 리뷰해줘", "spec↔code 갭 봐줘", "이 설계를 스펙 문서로 적어줘/DESIGN.md 작성", "컴포넌트 스펙 작성", "외부 spec 에 related_paths 주석" 같은 요청에 사용합니다. 슬래시로 직접 호출하거나 맥락에서 모델이 자동 호출합니다. 설계를 대화로 합의하는 단계는 `interview` 스킬이 담당하고, spec 은 합의된 설계를 문서로 형식화합니다. L1(관찰)→L2(종합)→audit(감사) 레이어로 file:line 인용 기반 분석.
 ---
 
 # spec
@@ -15,10 +15,12 @@ spec 슬래시 또는 모델 자동 호출로 진입하면, 사용자의 자연
 |---|---|---|
 | "스펙 리뷰", "이 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 (Big Picture 핑퐁) | design-protocol |
-| "컴포넌트 상세", "이 흐름 설계", concerns/flows | design-detail | design-protocol |
+| "이 설계 스펙 문서로", "DESIGN.md 작성", "큰그림 스펙 적어줘" | write (Big Picture DESIGN.md 작성) | authoring |
+| "컴포넌트 스펙 작성", "이 흐름 문서화", concerns/flows | write-detail (상세 스펙 작성) | authoring |
 | "related_paths 채워줘", 외부 spec 주석 | annotate | annotation |
 
+> **설계를 아직 합의하지 않았다면** (막연한 아이디어, 큰그림 잡기, 기존 계획 도전) `interview` 스킬을 먼저 쓴다. spec 의 `write`/`write-detail` 은 **합의된 설계를 문서로 형식화**하는 단계다.
+
 입력 인자(spec 파일 경로 등)가 함께 오면 그대로 사용하고, 없으면 AskUserQuestion 으로 확인합니다. 결정적 동작은 없으며(전부 판단/분석), 모든 분석은 sub-agent 에 위임합니다.
 
 스펙 문서를 다루는 워크플로우의 프로토콜·종료 조건·출력 포맷은 이 skill 의 `references/` 에서 progressive disclosure 로 로드합니다.
@@ -50,7 +52,7 @@ 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/design-protocol.md` | 대화형 설계(`design`/`design-detail`) 시 | 핑퐁 루프, 6개 관점, 수렴 판단, 출력 구조 |
+| `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 기준, 이슈 항목 구조, 마크다운 출력 형식 |
diff --git a/plugins/atelier/skills/spec/references/authoring.md b/plugins/atelier/skills/spec/references/authoring.md
new file mode 100644
index 00000000..1aa10411
--- /dev/null
+++ b/plugins/atelier/skills/spec/references/authoring.md
@@ -0,0 +1,134 @@
+# 스펙 문서 작성 컨벤션
+
+합의된 설계를 스펙 문서로 적는 절차와 형식. **설계를 생각하고 도전하며 합의에 이르는 대화는 `interview`(brainstorm: 무에서 설계 / grill: 기존 계획 심문)에서 끝낸다.** 여기서는 그 결과를 정해진 구조로 형식화한다 — `write`(Big Picture DESIGN.md)와 `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 (Big Picture) → DESIGN.md** — 포함: 목표, 설계 철학(의견), 컴포넌트 목록과 책임, 컴포넌트 간 데이터 흐름, 확장 가능 지점. 제외: trait/인터페이스 시그니처, 의사코드, 상태 전이 다이어그램, DB 스키마, API 상세 (→ write-detail 영역).
+- **write-detail** — "구현자가 코드 구조를 잡을 수 있지만, 구현 방법은 선택할 수 있는 수준". DESIGN.md 의 철학·원칙을 존중하며 세부 구체화. ❌ DESIGN.md 큰그림 중복 기술, ❌ 구현 코드 작성(의사코드까지만).
+
+## 작성 원칙
+
+- 저장 경로는 AskUserQuestion 으로 확인한다 (기본값은 아래 각 출력 구조 참조).
+- **최종 승인 전까지 파일을 저장하지 않는다.** 내용을 제시하고 동의받은 뒤 Write.
+- 기존 코드를 참조하되, 스펙이 기존 구조에 종속되지 않도록 한다.
+- frontmatter `related_paths` 를 채운다 — 후속 `spec-review`·`gap-detect` 가 이 필드를 코드 영역 매핑 Hint 로 사용하므로 분석 정확도가 크게 오른다. 본문에서 언급된 모듈/디렉터리/식별자를 프로젝트 구조와 매칭하되, **확실한 경로만** 적는다(추정에 자신 없으면 비움). 신규 설계라 코드가 아직 없으면 비워둔다.
+
+## 출력 구조
+
+### write → DESIGN.md
+
+저장 경로 기본: `spec/DESIGN.md` (AskUserQuestion 확인 후 Write).
+
+```markdown
+---
+related_paths:
+  - {추정 코드 경로}
+---
+
+# DESIGN
+
+> **Date**: {오늘 날짜}
+> **Status**: Draft
+
+## 목표
+{1-3문장: 이 시스템이 해결하는 문제, 설계 목표로 서술}
+
+## 설계 철학
+{번호 매긴 원칙들. 각 1-2문장. 서술이 아닌 의견/결정.}
+
+### 1. {원칙 이름}
+{설명}
+
+## 전체 구조
+{ASCII 다이어그램: 컴포넌트 배치와 데이터 흐름}
+
+## 관심사 분리
+| 레이어 | 책임 | 비고 |
+|--------|------|------|
+
+## OCP 확장점
+{새 타입/시스템 추가 시 코어 변경 없이 확장 가능한 지점}
+
+## 미결정 사항
+{확정되지 않은 항목. write-detail 에서 구체화할 후보}
+
+## 상세 문서
+| 문서 | 설명 |
+|------|------|
+| [concerns/...](...) | ... |
+| [flows/...](...) | ... |
+```
+
+### write-detail → concerns/{name}.md (컴포넌트)
+
+저장 경로 기본: `spec/concerns/{component-name}.md` (AskUserQuestion 확인 후 Write). 저장 후 DESIGN.md 에 상세 문서 링크 추가를 제안한다.
+
+```markdown
+---
+related_paths:
+  - {추정 코드 경로}
+---
+
+# {컴포넌트 이름}
+
+> {한 문장: 이 컴포넌트가 하는 것과 하지 않는 것}
+
+## 역할
+{핵심 책임}
+
+## 인터페이스/Trait
+{합의된 시그니처}
+
+## 핵심 로직
+{의사코드 — 합의된 수준}
+
+## 에러 처리
+{실패 시나리오와 대응 정책}
+
+## 제약 조건
+{불변 조건, 한계, 성능 제약}
+
+## 관련 문서
+| 문서 | 관계 |
+|------|------|
+| [DESIGN.md](../DESIGN.md) | 전체 구조에서의 위치 |
+```
+
+### write-detail → flows/{nn-scenario}.md (플로우)
+
+저장 경로 기본: `spec/flows/{nn-scenario-name}.md`.
+
+```markdown
+---
+related_paths:
+  - {추정 코드 경로}
+---
+
+# Flow {번호}: {시나리오 이름}
+
+> {한 문장 요약}
+
+## 흐름 다이어그램
+{ASCII 다이어그램}
+
+## 단계별 설명
+{각 단계: 트리거 → 컴포넌트 → 데이터 → 결과}
+
+## 실패 경로
+{각 단계에서 실패 시}
+
+## 엣지 케이스
+{비정상적이지만 유효한 시나리오}
+
+## 관련 문서
+| 문서 | 관계 |
+|------|------|
+| [DESIGN.md](../DESIGN.md) | 전체 구조 |
+| [관련 concern](./concerns/xxx.md) | 관련 컴포넌트 상세 |
+```
diff --git a/plugins/atelier/skills/spec/references/design-protocol.md b/plugins/atelier/skills/spec/references/design-protocol.md
deleted file mode 100644
index a8815d52..00000000
--- a/plugins/atelier/skills/spec/references/design-protocol.md
+++ /dev/null
@@ -1,236 +0,0 @@
-# 대화형 설계 핑퐁 프로토콜
-
-`design` (Big Picture) 와 `design-detail` (컴포넌트/플로우 상세) 이 공유하는 대화형 설계 절차. AI가 먼저 채워진 초안을 제안하고, 사용자가 피드백/의사코드로 방향을 잡고, AI가 반영 후 다른 관점에서 도전하는 **핑퐁 세션**.
-
-## 핑퐁 루프 프로토콜
-
-세션 시작 이후 수렴할 때까지 반복:
-
-```
-1. AI가 설계의 한 측면을 구체적으로 제안한다 (빈 칸이 아닌 채워진 초안)
-2. 사용자가 응답한다:
-   - 동의 → 이 측면은 합의됨, 다음 측면으로
-   - 방향 수정 → AI가 수정 반영
-   - 의사코드/구조 제시 → AI가 설계 언어로 흡수 (단순 에코 아님)
-   - 새 관심사 제기 → AI가 해당 관심사를 탐색
-3. AI가 반영한 뒤, 다른 관점에서 하나의 구체적 도전을 제시한다
-4. AskUserQuestion으로 피드백을 요청한다
-```
-
-## 6개 관점
-
-대화 중 아래 관점들을 내부적으로 추적한다. **사용자에게 관점 이름이나 전환을 노출하지 않는다.**
-
-| 코드 | 관점 | 핵심 질문 |
-|------|------|----------|
-| S | 단순성 | 더 줄일 수 있나? 불필요한 추상화는 없나? |
-| O | OCP | 새 타입/시스템 추가 시 기존 코드 변경 없이 가능한가? |
-| F | 실패/복구 | 여기서 터지면? 재시도? 사람 개입? |
-| B | 경계 | 이 컴포넌트가 알아야 할 것 vs 몰라야 할 것 |
-| C | 동시성 | 동시 접근 시 어떻게 되나? |
-| M | 운영 | 상태 확인, 디버깅이 가능한가? |
-
-### 관점 전환 규칙
-
-- 사용자의 응답이 자연스럽게 특정 관점을 열면 → 그 흐름을 따라간다
-- 3회 이상 교환 동안 미탐색 관점이 있으면 → 구체적 시나리오로 자연스럽게 도입한다
-- 관점 전환을 선언하지 않고, 항상 구체적 시나리오로 질문한다
-
-```
-좋은 예:
-  "두 사용자가 동시에 아이템을 제출하면 어떻게 되나요? 지금 구조는 순차 처리라
-   두 번째 사용자가 대기하게 됩니다. 이게 괜찮은 건가요, 아니면 큐가 필요할까요?"
-
-  "여기에 trait를 세 종류가 구현하는데, 실제로 1-2개만 있을 수 있다면
-   추상화가 오히려 간접 참조만 추가합니다. 더 구현체가 생길 예정인가요?"
-
-나쁜 예:
-  "동시성에 대해 생각해보셨나요?"
-  "이 추상화가 정말 필요한가요?"
-```
-
-## 사용자 의사코드 처리
-
-사용자가 의사코드나 구조적 피드백을 제시하면:
-
-1. **설계 언어로 반영한다** — 의사코드를 에코하지 않고 설계 문서의 일부로 흡수한다
-2. **의사코드의 한 측면을 도전한다** — 관련 관점에서 구체적 시나리오를 제시한다
-
-```
-사용자: "loop { collect(); process(); done(); }"
-
-AI 반영: "수집 → 처리 → 완료 반영의 단순 루프로 정리했습니다.
-         Daemon은 이 루프만 돌리고, 무엇을 수집하고 어떻게 처리할지는
-         외부에서 정의하는 구조네요."
-
-AI 도전: "한 가지 — process()가 LLM 호출이라 30초~수분이 걸릴 텐데,
-         이 루프가 한 번에 하나만 처리하면 처리량이 제한됩니다.
-         동시에 여러 아이템을 process()할 수 있어야 하나요?"
-```
-
-## 수렴 판단 (모드별 임계값)
-
-수렴 조건은 design(Big Picture)과 design-detail(컴포넌트/플로우)이 다르다.
-
-**design (Big Picture)** — 다음 충족 시 수렴:
-- 6개 관점 중 **4개 이상**이 의미 있게 다뤄졌다
-- 핵심 아키텍처 (컴포넌트 목록 + 각각의 책임)에 사용자가 동의했다
-- 사용자가 **2-3회 연속** 새 관심사 없이 확인/동의만 했다
-
-**design-detail (컴포넌트/플로우)** — 단위가 좁으므로 기준이 낮다:
-- 6개 관점 중 **3개 이상** 다룸 (design 의 4개보다 낮음)
-- 컴포넌트: 인터페이스/역할 합의 + 핵심 로직 방향 결정 + 주요 에러 케이스 / 플로우: 주요 흐름(happy path) 합의 + 핵심 분기점
-- 사용자가 **2-3회 연속** 확인만 했다
-
-수렴 시 AskUserQuestion 으로 정리(파일 저장) 의사를 묻는다.
-
-## 안티패턴
-
-- ❌ 한 번에 여러 질문 나열 / 번호 매긴 설문지
-- ❌ 단계 선언 ("Phase 2로 넘어가겠습니다") / 관점 전환 선언
-- ❌ 빈 칸 채우기 ("목표가 뭐예요?", "액터가 누구예요?")
-- ❌ 사용자 의사코드를 그대로 에코
-- ✅ 한 번에 **하나의 구체적 제안** + **하나의 구체적 도전** + AskUserQuestion
-
-## frontmatter `related_paths` 권고 (설계 출력 공통)
-
-설계 산출물(spec) 상단에 YAML frontmatter 로 `related_paths` 를 채우는 것을 권장한다. 후속 `spec-review`·`gap-detect` 가 이 필드를 코드 영역 매핑 Hint 로 사용하므로, 채워두면 분석 정확도가 크게 오른다.
-
-- 본문에서 명시적으로 언급된 모듈/디렉터리/식별자를 프로젝트 디렉터리 구조와 매칭한다.
-- **확실한 경로만** 적는다. 추정에 자신 없으면 비워라 — 잘못된 Hint 는 자율 보강 fallback 보다 해롭다.
-- 신규 설계라 코드가 아직 없으면 비워둔다.
-
-## 공통 주의사항
-
-- 사용자가 이전 논의를 번복해도 자연스럽게 수용한다
-- 기존 코드를 참조하되 설계가 기존 구조에 종속되지 않도록 한다
-- 최종 승인 전까지 파일 저장 안 함
-
----
-
-## design-detail 세션 준비
-
-design-detail(컴포넌트/플로우 상세)는 design 이후 단계이므로 진입 전 맥락 파악이 필요하다.
-
-1. **맥락 파악**: `spec/DESIGN.md` 또는 `**/DESIGN*.md` 를 Glob 으로 찾아 Read. 없으면 AskUserQuestion: "Big Picture 스펙(DESIGN.md)을 찾을 수 없습니다. design 으로 먼저 만들거나, 기존 스펙 경로를 알려주세요." 기존 `spec/concerns/`·`spec/flows/` 및 관련 코드도 파악.
-2. **세션 타입 결정**: `flow` 키워드 → 플로우 세션, 그 외 → 컴포넌트 세션. 인자 없으면 DESIGN.md 의 컴포넌트/시나리오 목록 제시 후 선택.
-3. **초안 제안**: 해당 컴포넌트/시나리오 정보 + 기존 코드 구조 반영해 구체적 초안 먼저 제안 → 핑퐁 루프.
-
-## 깊이 기준
-
-- **design (Big Picture)** — 포함: 목표, 설계 철학(의견), 컴포넌트 목록과 책임, 컴포넌트 간 데이터 흐름, 확장 가능 지점. 제외: trait/인터페이스 시그니처, 의사코드, 상태 전이 다이어그램, DB 스키마, API 상세 (→ design-detail 영역).
-- **design-detail** — "구현자가 코드 구조를 잡을 수 있지만, 구현 방법은 선택할 수 있는 수준". DESIGN.md 의 철학·원칙을 존중하며 세부 구체화. ❌ DESIGN.md 큰그림 중복 기술, ❌ 구현 코드 작성(의사코드까지만).
-
-## 출력 구조
-
-### design → DESIGN.md
-
-저장 경로는 AskUserQuestion 으로 확인 (기본: `spec/DESIGN.md`) 후 Write.
-
-```markdown
----
-related_paths:
-  - {추정 코드 경로}
----
-
-# DESIGN
-
-> **Date**: {오늘 날짜}
-> **Status**: Draft
-
-## 목표
-{1-3문장: 이 시스템이 해결하는 문제, 설계 목표로 서술}
-
-## 설계 철학
-{번호 매긴 원칙들. 각 1-2문장. 서술이 아닌 의견/결정.}
-
-### 1. {원칙 이름}
-{설명}
-
-## 전체 구조
-{ASCII 다이어그램: 컴포넌트 배치와 데이터 흐름}
-
-## 관심사 분리
-| 레이어 | 책임 | 비고 |
-|--------|------|------|
-
-## OCP 확장점
-{새 타입/시스템 추가 시 코어 변경 없이 확장 가능한 지점}
-
-## 미결정 사항
-{확정되지 않은 항목. design-detail 에서 구체화할 후보}
-
-## 상세 문서
-| 문서 | 설명 |
-|------|------|
-| [concerns/...](...) | ... |
-| [flows/...](...) | ... |
-```
-
-### design-detail → concerns/{name}.md (컴포넌트)
-
-저장 경로 기본: `spec/concerns/{component-name}.md` (AskUserQuestion 확인 후 Write). 저장 후 DESIGN.md 에 상세 문서 링크 추가 제안.
-
-```markdown
----
-related_paths:
-  - {추정 코드 경로}
----
-
-# {컴포넌트 이름}
-
-> {한 문장: 이 컴포넌트가 하는 것과 하지 않는 것}
-
-## 역할
-{핵심 책임}
-
-## 인터페이스/Trait
-{합의된 시그니처}
-
-## 핵심 로직
-{의사코드 — 합의된 수준}
-
-## 에러 처리
-{실패 시나리오와 대응 정책}
-
-## 제약 조건
-{불변 조건, 한계, 성능 제약}
-
-## 관련 문서
-| 문서 | 관계 |
-|------|------|
-| [DESIGN.md](../DESIGN.md) | 전체 구조에서의 위치 |
-```
-
-### design-detail → flows/{nn-scenario}.md (플로우)
-
-저장 경로 기본: `spec/flows/{nn-scenario-name}.md`.
-
-```markdown
----
-related_paths:
-  - {추정 코드 경로}
----
-
-# Flow {번호}: {시나리오 이름}
-
-> {한 문장 요약}
-
-## 흐름 다이어그램
-{ASCII 다이어그램}
-
-## 단계별 설명
-{각 단계: 트리거 → 컴포넌트 → 데이터 → 결과}
-
-## 실패 경로
-{각 단계에서 실패 시}
-
-## 엣지 케이스
-{비정상적이지만 유효한 시나리오}
-
-## 관련 문서
-| 문서 | 관계 |
-|------|------|
-| [DESIGN.md](../DESIGN.md) | 전체 구조 |
-| [관련 concern](./concerns/xxx.md) | 관련 컴포넌트 상세 |
-```

From 340ce6506d764843c028010ced6d6c8289b25081 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EA=B9=80=EC=9A=A9=EC=84=B1?=
 <66245186+kys0213@users.noreply.github.com>
Date: Sat, 13 Jun 2026 13:49:46 +0900
Subject: [PATCH 6/7] refactor(atelier): split spec into spec-write and
 spec-review (#795)

---
 plugins/atelier/README.md                     |  4 +--
 .../atelier/agents/spec/file-pair-observer.md |  2 +-
 plugins/atelier/agents/spec/gap-aggregator.md |  2 +-
 plugins/atelier/agents/spec/gap-auditor.md    |  4 +--
 plugins/atelier/agents/spec/spec-annotator.md |  2 +-
 .../skills/autopilot/references/startup.md    |  2 +-
 plugins/atelier/skills/interview/SKILL.md     |  5 +--
 .../skills/interview/references/brainstorm.md |  6 ++--
 .../skills/{spec => spec-review}/SKILL.md     | 18 +++++-----
 .../references/annotation.md                  |  0
 .../references/file-observation.md            |  0
 .../references/gap-audit-loop.md              |  0
 .../references/issue-report.md                |  0
 .../references/quality-criteria.md            |  0
 .../references/report-format.md               |  0
 plugins/atelier/skills/spec-write/SKILL.md    | 35 +++++++++++++++++++
 .../references/authoring.md                   |  5 ++-
 17 files changed, 59 insertions(+), 26 deletions(-)
 rename plugins/atelier/skills/{spec => spec-review}/SKILL.md (68%)
 rename plugins/atelier/skills/{spec => spec-review}/references/annotation.md (100%)
 rename plugins/atelier/skills/{spec => spec-review}/references/file-observation.md (100%)
 rename plugins/atelier/skills/{spec => spec-review}/references/gap-audit-loop.md (100%)
 rename plugins/atelier/skills/{spec => spec-review}/references/issue-report.md (100%)
 rename plugins/atelier/skills/{spec => spec-review}/references/quality-criteria.md (100%)
 rename plugins/atelier/skills/{spec => spec-review}/references/report-format.md (100%)
 create mode 100644 plugins/atelier/skills/spec-write/SKILL.md
 rename plugins/atelier/skills/{spec => spec-write}/references/authoring.md (87%)

diff --git a/plugins/atelier/README.md b/plugins/atelier/README.md
index 38e789aa..3a4f196a 100644
--- a/plugins/atelier/README.md
+++ b/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 단위 테스트만 완료 —
diff --git a/plugins/atelier/agents/spec/file-pair-observer.md b/plugins/atelier/agents/spec/file-pair-observer.md
index 4ee5aecc..50c6c43d 100644
--- a/plugins/atelier/agents/spec/file-pair-observer.md
+++ b/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"]
 ---
diff --git a/plugins/atelier/agents/spec/gap-aggregator.md b/plugins/atelier/agents/spec/gap-aggregator.md
index 33e5a7fe..04fb9c01 100644
--- a/plugins/atelier/agents/spec/gap-aggregator.md
+++ b/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: []
 ---
diff --git a/plugins/atelier/agents/spec/gap-auditor.md b/plugins/atelier/agents/spec/gap-auditor.md
index d8c90ccb..5df39592 100644
--- a/plugins/atelier/agents/spec/gap-auditor.md
+++ b/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
 
diff --git a/plugins/atelier/agents/spec/spec-annotator.md b/plugins/atelier/agents/spec/spec-annotator.md
index 42a2f5a7..4bc04746 100644
--- a/plugins/atelier/agents/spec/spec-annotator.md
+++ b/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"]
 ---
diff --git a/plugins/atelier/skills/autopilot/references/startup.md b/plugins/atelier/skills/autopilot/references/startup.md
index 3ec548b9..60f9a292 100644
--- a/plugins/atelier/skills/autopilot/references/startup.md
+++ b/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"`)
 
diff --git a/plugins/atelier/skills/interview/SKILL.md b/plugins/atelier/skills/interview/SKILL.md
index 80365034..702fbce1 100644
--- a/plugins/atelier/skills/interview/SKILL.md
+++ b/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` | 자율 루프와 무관, 사람↔에이전트 대화 전용 | 해당 없음 |
 
diff --git a/plugins/atelier/skills/interview/references/brainstorm.md b/plugins/atelier/skills/interview/references/brainstorm.md
index eea73a43..675fd48c 100644
--- a/plugins/atelier/skills/interview/references/brainstorm.md
+++ b/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` 로 형식화한다
 
 ## 핵심 원칙
 
diff --git a/plugins/atelier/skills/spec/SKILL.md b/plugins/atelier/skills/spec-review/SKILL.md
similarity index 68%
rename from plugins/atelier/skills/spec/SKILL.md
rename to plugins/atelier/skills/spec-review/SKILL.md
index a7f66813..ef463991 100644
--- a/plugins/atelier/skills/spec/SKILL.md
+++ b/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 기준, 이슈 항목 구조, 마크다운 출력 형식 |
diff --git a/plugins/atelier/skills/spec/references/annotation.md b/plugins/atelier/skills/spec-review/references/annotation.md
similarity index 100%
rename from plugins/atelier/skills/spec/references/annotation.md
rename to plugins/atelier/skills/spec-review/references/annotation.md
diff --git a/plugins/atelier/skills/spec/references/file-observation.md b/plugins/atelier/skills/spec-review/references/file-observation.md
similarity index 100%
rename from plugins/atelier/skills/spec/references/file-observation.md
rename to plugins/atelier/skills/spec-review/references/file-observation.md
diff --git a/plugins/atelier/skills/spec/references/gap-audit-loop.md b/plugins/atelier/skills/spec-review/references/gap-audit-loop.md
similarity index 100%
rename from plugins/atelier/skills/spec/references/gap-audit-loop.md
rename to plugins/atelier/skills/spec-review/references/gap-audit-loop.md
diff --git a/plugins/atelier/skills/spec/references/issue-report.md b/plugins/atelier/skills/spec-review/references/issue-report.md
similarity index 100%
rename from plugins/atelier/skills/spec/references/issue-report.md
rename to plugins/atelier/skills/spec-review/references/issue-report.md
diff --git a/plugins/atelier/skills/spec/references/quality-criteria.md b/plugins/atelier/skills/spec-review/references/quality-criteria.md
similarity index 100%
rename from plugins/atelier/skills/spec/references/quality-criteria.md
rename to plugins/atelier/skills/spec-review/references/quality-criteria.md
diff --git a/plugins/atelier/skills/spec/references/report-format.md b/plugins/atelier/skills/spec-review/references/report-format.md
similarity index 100%
rename from plugins/atelier/skills/spec/references/report-format.md
rename to plugins/atelier/skills/spec-review/references/report-format.md
diff --git a/plugins/atelier/skills/spec-write/SKILL.md b/plugins/atelier/skills/spec-write/SKILL.md
new file mode 100644
index 00000000..d7ec9c3d
--- /dev/null
+++ b/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 이다.
diff --git a/plugins/atelier/skills/spec/references/authoring.md b/plugins/atelier/skills/spec-write/references/authoring.md
similarity index 87%
rename from plugins/atelier/skills/spec/references/authoring.md
rename to plugins/atelier/skills/spec-write/references/authoring.md
index 1aa10411..aea22f1e 100644
--- a/plugins/atelier/skills/spec/references/authoring.md
+++ b/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/` 및 관련 코드도 파악한다.
 
 ## 깊이 기준
 

From 86114dea3f3737b60189099918e362ce08593b6e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EA=B9=80=EC=9A=A9=EC=84=B1?=
 <kys0213@gim-yongseong-ui-MacBookPro.local>
Date: Sat, 13 Jun 2026 13:54:13 +0900
Subject: [PATCH 7/7] =?UTF-8?q?chore(validate):=20drop=20obsolete=20spec?=
 =?UTF-8?q?=20convergence=20invariant,=20relabel=20design=E2=86=92write?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The spec design→write refactor (#794) intentionally removed the 6-perspective ping-pong convergence model, dropping the '3개 이상' token (design-detail convergence threshold). The extraction-invariants guard flagged it as lost load-bearing content, but the removal was deliberate per the design-dialogue/spec-authoring split — so retire that invariant.

Also relabel the surviving spec output-structure invariants from spec/design·spec/design-detail to spec-write/write·spec-write/write-detail to match the renamed routes. All their tokens (## OCP 확장점, ## 핵심 로직, spec/concerns/, etc.) still resolve in spec-write/references/authoring.md.

Fixes validate-ci failure on #794.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
---
 tools/validate/extraction-invariants.json | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/tools/validate/extraction-invariants.json b/tools/validate/extraction-invariants.json
index ea7e77a8..e8dc0a45 100644
--- a/tools/validate/extraction-invariants.json
+++ b/tools/validate/extraction-invariants.json
@@ -5,14 +5,13 @@
     "plugins/atelier/commands"
   ],
   "invariants": [
-    {"domain": "spec/design", "token": "## OCP 확장점", "reason": "design DESIGN.md 출력 구조 섹션"},
-    {"domain": "spec/design", "token": "## 미결정 사항", "reason": "design DESIGN.md 출력 구조 섹션"},
-    {"domain": "spec/design", "token": "## 관심사 분리", "reason": "design DESIGN.md 출력 구조 섹션"},
-    {"domain": "spec/design-detail", "token": "## 핵심 로직", "reason": "design-detail concerns 출력 구조"},
-    {"domain": "spec/design-detail", "token": "## 흐름 다이어그램", "reason": "design-detail flows 출력 구조"},
-    {"domain": "spec/design-detail", "token": "3개 이상", "reason": "design-detail 수렴 임계값 (design 4개와 구분)"},
-    {"domain": "spec/design-detail", "token": "spec/concerns/", "reason": "design-detail 컴포넌트 저장 경로"},
-    {"domain": "spec/design-detail", "token": "spec/flows/", "reason": "design-detail 플로우 저장 경로"},
+    {"domain": "spec-write/write", "token": "## OCP 확장점", "reason": "write DESIGN.md 출력 구조 섹션"},
+    {"domain": "spec-write/write", "token": "## 미결정 사항", "reason": "write DESIGN.md 출력 구조 섹션"},
+    {"domain": "spec-write/write", "token": "## 관심사 분리", "reason": "write DESIGN.md 출력 구조 섹션"},
+    {"domain": "spec-write/write-detail", "token": "## 핵심 로직", "reason": "write-detail concerns 출력 구조"},
+    {"domain": "spec-write/write-detail", "token": "## 흐름 다이어그램", "reason": "write-detail flows 출력 구조"},
+    {"domain": "spec-write/write-detail", "token": "spec/concerns/", "reason": "write-detail 컴포넌트 저장 경로"},
+    {"domain": "spec-write/write-detail", "token": "spec/flows/", "reason": "write-detail 플로우 저장 경로"},
     {"domain": "spec/review", "token": "excerpt mismatch", "reason": "L1 인용 검증 실패 사유"},
     {"domain": "spec/review", "token": "gap-auditor", "reason": "audit 단일 게이트 에이전트"},
     {"domain": "spec/annotate", "token": "## 에러 처리", "reason": "annotate 에러 처리 (매칭 0건/retry)"},