@angar2/taskery 0.2.1 → 0.3.1

package/template/shared/skills/project-init/SKILL.md

@@ -1,13 +1,19 @@
 ---
 name: project-init
-description: taskery 도입 직후 1회성 — PROJECT.md / AGENT-GUIDE.md / LINKED-REPOS.md / .env 빈 골격 생성
+description: taskery 도입 직후 1회성 — 진입 문서(PROJECT/AGENT-GUIDE/…) + 제품 관통 기획 문서(그룹 A 작성 / 그룹 B 골격) 생성
 ---
 
 # /project-init
 
 ## 개요
 
-taskery 도입 직후 **1회성**으로 호출. 사용자 또는 동료가 새 리포에 npx로 taskery 세팅 직후 처음 부르는 스킬. `.project/` 영역의 사람용/메인용 진입 문서 골격을 만든다.
+taskery 도입 직후 **1회성**으로 호출. 사용자 또는 동료가 새 리포에 npx로 taskery 세팅 직후 처음 부르는 스킬. `.project/` 영역의 사람용/메인용 진입 문서와 **제품 관통 기획 문서**(루트 평평 배치)를 만든다.
+
+제품 관통 문서 2그룹 (`.project/` 루트):
+- **그룹 A — 정적(내용까지 작성)**: SERVICE-POLICY.md / TECH-STACK.md / ARCHITECTURE.md. project-init이 인터뷰로 *작성*. (이후 plan-init은 부수적 add/mod만.)
+- **그룹 B — 성장(골격→채움)**: DATA-MODEL.md / API-SPEC.md / FEATURES.md / UX-UI.md. project-init이 *빈 골격*만. 기능 그룹별 본문은 이후 plan-init(FEATURES/UX-UI 의도) + task 진행(DATA-MODEL/API-SPEC 상세)이 채움.
+
+> **plan 로컬 문서**(PLAN.md / ROADMAP.md)는 본 스킬이 만들지 않는다 — 그건 `/plan-init`이 plan(기능 그룹) 폴더마다 생성한다.
 
 ## 호출 시점
 
@@ -76,6 +82,60 @@ taskery 도입 직후 **1회성**으로 호출. 사용자 또는 동료가 새
 - `src/` — 소스 코드
 - `.project/` — taskery 메타 영역
 - ...
+
+## 초기 빌드 로드맵
+<프로젝트 전체를 관통하는 *거시 빌드 순서* — 구현 → 배포 → 보안 등 큰 덩어리 단계.
+1회성 기록(완료돼도 living 갱신 X). 기능 그룹 단위 task 순서는 plans/<NNN_slug>/ROADMAP.md, 앞으로의 후보는 글로벌 BACKLOG.md가 담당 — 셋은 역할이 안 겹친다.>
+
+1. <예: 코어 도메인 + 데이터 모델 구현>
+2. <예: 인증 / 권한>
+3. <예: 배포 파이프라인 + 스테이징>
+4. <예: 보안 점검 + 프로덕션>
+```
+
+> `## 초기 빌드 로드맵`은 Step 2 인터뷰에서 *거시 단계*를 1~2개 질문으로 수집해 채운다. 비어 있으면 자리표시자만 두고 사용자에게 *"전체 빌드 순서 큰 덩어리로 알려줘"* 1회 질문.
+
+### Step 3.5 — 제품 관통 문서 그룹 A 작성 (`.project/` 루트)
+
+정적 제품 관통 문서 3종(그룹 A)을 *인터뷰로 작성*. 프로젝트 t=0의 상위 정책/스택/구조 — "척추"만 단단히. 한 문서씩 핵심 질문 1~3개, 사용자 답 받고 작성.
+
+**타입 조건부**: `frontend` → SERVICE-POLICY 생략 가능 / `backend` → (해당 없음, 3종 모두) / `library`·`cli` → SERVICE-POLICY 생략 가능. 무관 문서는 *생성 안 함*(빈 골격도 X).
+
+1. **SERVICE-POLICY.md** (백엔드/풀스택 등 해당 시): 사용자 권한 / 데이터 보존 / 결제·과금 정책 등 핵심 1~3개.
+2. **TECH-STACK.md**: 언어 / 프레임워크 / 주요 라이브러리 + *선택 이유*.
+3. **ARCHITECTURE.md**: 시스템 구조 (단일 / 레이어드 / 마이크로서비스 / 멀티 리포 등) + 핵심 경계.
+
+각 문서 공통 골격:
+
+```markdown
+# <SERVICE-POLICY | TECH-STACK | ARCHITECTURE> — <프로젝트명>
+
+> 제품 관통 문서 (정적, 그룹 A). project-init이 작성, 이후 변경은 해당 정책/스택/구조를
+> 새로 도입·변경하는 task에서 spec-diff와 함께 갱신.
+
+<인터뷰 답 기반 본문>
+```
+
+### Step 3.6 — 제품 관통 문서 그룹 B 골격 (`.project/` 루트)
+
+성장 제품 관통 문서 4종(그룹 B)을 *빈 골격*만 Write. 본문은 plan/task가 채운다 — 여기서 *선기획 금지*.
+
+**타입 조건부**: `frontend` → DATA-MODEL / API-SPEC 생략 가능 / `backend` → UX-UI 생략 가능 / `library` → UX-UI 생략 가능. 무관 문서는 생성 안 함.
+
+- **FEATURES.md** / **UX-UI.md** — *plan-init이 기능 그룹마다 의도 섹션 append*.
+- **DATA-MODEL.md** / **API-SPEC.md** — *task 진행(task-plan Phase 0 / task-dev)이 구현 동반으로 상세 채움*. 선스펙 금지.
+
+공통 골격 (각 문서):
+
+```markdown
+# <FEATURES | UX-UI | DATA-MODEL | API-SPEC> — <프로젝트명>
+
+> 제품 관통 문서 (성장, 그룹 B). 기능/도메인 섹션으로 자기기술(self-describing) —
+> 어느 plan이 추가했는지 태그하지 않는다(기능 분류 = 본 문서 섹션 구조가 단일 진실).
+> FEATURES/UX-UI: plan-init이 기능 그룹마다 의도 섹션 추가.
+> DATA-MODEL/API-SPEC: task 진행이 스키마·엔드포인트를 구현 동반으로 채움(선스펙 금지).
+
+<!-- 기능 그룹 / 도메인 섹션이 여기 누적된다. 초기엔 비어 있음. -->
 ```
 
 ### Step 4 — `.project/AGENT-GUIDE.md` 작성
@@ -85,16 +145,18 @@ taskery 도입 직후 **1회성**으로 호출. 사용자 또는 동료가 새
 ```markdown
 # AGENT-GUIDE.md
 
-## 활성 plan 버전
-<예: v1.0 — `.project/plans/v1.0/` 참조>
+## 활성 plan 버전   <!-- 값 = NNN_slug 폴더명(버전 아님). 헤딩 텍스트는 lib.js/스킬이 의존하므로 변경 X -->
+<예: 001_mvp — `.project/plans/001_mvp/` 참조>
 
 ## 메인이 매 세션 시작 시 읽을 것
 1. `CLAUDE.md` — 프로젝트 메타 + 검증 명령 + 룰 참조
-2. `.project/PROJECT.md` — 프로젝트 개요
-3. `.project/plans/<활성버전>/PLAN.md` — 활성 plan 진입 (이게 9 기획 문서 인덱스)
-4. `.project/GLOSSARY.md` — 도메인 용어집 (영문/한글 표기 일관성 단일 진실 소스)
-5. `.project/tasks/<활성버전>/BACKLOG.md` — 현재 plan 진행 중 누적된 후속 task 후보 (사용자 발화 *"이건 다음 task로"* / task-close 직후 메인 감지로 추가)
-6. `.project/AGENT-GUIDE.md` — 본 파일 (그대로)
+2. `.project/PROJECT.md` — 프로젝트 개요 + 초기 빌드 로드맵
+3. `.project/` 루트 제품 관통 문서 — SERVICE-POLICY / TECH-STACK / ARCHITECTURE / DATA-MODEL / API-SPEC / FEATURES / UX-UI (해당 시. 기능 분류 단일 진실)
+4. `.project/plans/<활성 plan>/PLAN.md` — 활성 plan(기능 그룹) 인덱스 (이 그룹이 건드린 루트 문서 요약 + task 체크리스트)
+5. `.project/GLOSSARY.md` — 도메인 용어집 (영문/한글 표기 일관성 단일 진실 소스)
+6. `.project/tasks/<활성 plan>/BACKLOG.md` — 현재 plan 진행 중 누적된 후속 task 후보 (사용자 발화 *"이건 다음 task로"* / task-close 직후 메인 감지로 추가)
+7. `.project/AGENT-GUIDE.md` — 본 파일 (그대로)
+8. `.project/TEST-GUIDE.md` — 검증 방법 문서 (각 테스트 방식의 이 프로젝트 실제 실행 경로). 매 세션 통독 아니라 *`/task-plan`·`/task-test` 시 참조* — 발견성 위해 등재
 
 ## 작업 흐름
 - task 시작: `/task-init` 또는 `/task-plan`
@@ -103,12 +165,14 @@ taskery 도입 직후 **1회성**으로 호출. 사용자 또는 동료가 새
 
 ## 폴더 구조
 - `.project/rules/` — 코어 룰 (TASK_DOC_RULE / GIT_RULE / CHANGELOG_RULE / MOCKUP_RULE)
-- `.project/plans/<vX.X>/` — 9 기획 문서
-- `.project/tasks/<vX.X>/` — task 문서
+- `.project/*.md` (루트) — 제품 관통 문서 (SERVICE-POLICY / TECH-STACK / ARCHITECTURE / DATA-MODEL / API-SPEC / FEATURES / UX-UI)
+- `.project/plans/<NNN_slug>/` — plan(기능 그룹) 로컬: PLAN.md / ROADMAP.md
+- `.project/tasks/<NNN_slug>/` — task 문서
 - `.project/flows/` — 도메인 흐름
 - `.project/shared/` — 멀티리포 메시지
 - `.project/changelog/` — 월별 변경 이력
 - `.project/FRICTION_LOG.md` — 불편 데이터
+- `.project/TEST-GUIDE.md` — 검증 방법 문서 (각 테스트 방식의 이 프로젝트 실제 실행 경로. 제품 관통 문서 아님)
 
 ## 멀티리포
 <단일 리포면 "단일 리포. LINKED-REPOS.md 빈 템플릿."
@@ -132,7 +196,7 @@ stash FRICTION_LOG #3 반영 — 프로젝트 도메인 용어를 *영문/한글
 ## 운용 룰
 
 - 영문 알파벳 순 정렬
-- 출처: 본 용어가 도입된 task/plan 문서 경로 (예: `plans/v1.0/FEATURES.md`)
+- 출처: 본 용어가 도입된 제품 문서/task 경로 (예: `.project/FEATURES.md`)
 - 동의어 / 변형 표기 발견 시 본 표 기준으로 정합
 ```
 
@@ -176,8 +240,8 @@ stash FRICTION_LOG #3 반영 — 프로젝트 도메인 용어를 *영문/한글
 `npx @angar2/taskery init`이 이미 다음 빈 골격 폴더 생성:
 - `.project/changelog/` (`.gitkeep`)
 - `.project/flows/` (`.gitkeep`)
-- `.project/plans/` (`.gitkeep` — `/plan-init`이 `vX.X/` 하위 작성)
-- `.project/tasks/` (`.gitkeep` — `/task-init`이 `vX.X/<NNN>_<slug>.md` 작성)
+- `.project/plans/` (`.gitkeep` — `/plan-init`이 `NNN_slug/` 하위 작성)
+- `.project/tasks/` (`.gitkeep` — `/task-init`이 `NNN_slug/TASK-<NNN>_<slug>.md` 작성)
 - `.project/shared/{sent,received}/completed/` (`.gitkeep`)
 - `.project/FRICTION_LOG.md` (빈 템플릿)
 - `.project/rules/{TASK_DOC_RULE,GIT_RULE,CHANGELOG_RULE,MOCKUP_RULE}.md` (코어 룰)
@@ -220,7 +284,7 @@ git branch -a                                        # main(또는 master) + dev
 ### Step 8 — 결과 보고
 
 작성된 파일 목록 + 다음 단계 안내:
-- *"PROJECT.md / AGENT-GUIDE.md / LINKED-REPOS.md / GLOSSARY.md / .env 생성. (FRICTION_LOG.md / 빈 골격 폴더는 npx init이 이미 카피한 것 그대로). **빈 폴더 케이스라 git init + dev 분기까지 완료** (이미 git 리포면 건너뜀). 다음은 `/plan-init <버전명>`으로 9 기획 문서 작성."*
+- *"PROJECT.md(초기 빌드 로드맵 포함) / AGENT-GUIDE.md / LINKED-REPOS.md / GLOSSARY.md / .env + 제품 관통 문서(그룹 A 작성: SERVICE-POLICY·TECH-STACK·ARCHITECTURE / 그룹 B 골격: DATA-MODEL·API-SPEC·FEATURES·UX-UI, 타입 해당분) 생성. (FRICTION_LOG.md / TEST-GUIDE.md(검증 방법 문서, 빈 골격) / 빈 골격 폴더는 npx init이 이미 카피한 것 그대로 — project-init이 생성 X). **빈 폴더 케이스라 git init + dev 분기까지 완료** (이미 git 리포면 건너뜀). 다음은 `/plan-init <기능그룹>`으로 첫 plan(MVP면 여러 기능 그룹을 묶은 큰 plan) 작성."*
 
 **결과 commit 흐름** (GIT_RULE 정합):
 - dev 직접 commit *금지* (git-guard.sh 차단). 두 가지 default 흐름:
@@ -230,15 +294,18 @@ git branch -a                                        # main(또는 master) + dev
 ## 도구 가이드
 
 - **Read**: 기존 README / package.json 정독
-- **Write**: 신규 .md 파일 생성
+- **Write**: 신규 .md 파일 생성 (진입 문서 + 제품 관통 문서 그룹 A/B)
 - **Bash**: `mkdir -p .project/changelog .project/flows`, `ls`, `cat package.json | head -20`
-- **AskUserQuestion**: 인터뷰 분기 시 질문 라운드 (한 번에 한 질문씩)
+- **AskUserQuestion**: 인터뷰 분기 시 질문 라운드 — 메타 + 초기 빌드 로드맵 + 그룹 A(정책/스택/구조) 핵심 질문 (한 번에 한 질문씩)
 
 ## 주의사항
 
 - *덮어쓰기 default 금지* — 이미 PROJECT.md 있으면 confirm.
 - 인터뷰 분기에서 *자동 추정 진행 금지*. 빈 프로젝트면 사용자 답 받고 작성.
 - 한 번에 너무 많은 질문 X. 사용자 답 받고 다음 질문.
+- **그룹 A는 "척추"만** — 상위 정책/스택/구조에 한정. 세부까지 파고들어 t=0 과부담 만들지 말 것.
+- **그룹 B는 골격만** — DATA-MODEL/API-SPEC 스키마·엔드포인트 *선작성 금지*(선기획 함정). 본문은 task 진행이 구현 동반으로 채운다.
+- **타입 조건부 생략** — frontend → SERVICE-POLICY/DATA-MODEL/API-SPEC 생략 가능, backend → UX-UI 생략 가능. 무관 문서는 골격조차 만들지 않는다.
 - 이 스킬은 **1회성**. 두 번째 호출은 의미 X (덮어쓰기 confirm 거치게 됨).
 
 ## 상태 전이

package/template/shared/skills/task-close/SKILL.md

@@ -73,8 +73,8 @@ LOCK_FILE="$HOME/.taskery/${PROJECT_ID}.merge.lock"
      ```sh
      git -C "$MAIN_WT" check-ignore -q "$MAIN_WT/.project/dummy"
      ```
-     - exit 0 (등록됨): `$MAIN_WT/.project/tasks/<vX.X>/...` (단일 소스)
-     - exit 1 (미등록): `$WT_PATH/.project/tasks/<vX.X>/...` (워크트리 안)
+     - exit 0 (등록됨): `$MAIN_WT/.project/tasks/<NNN_slug>/...` (단일 소스)
+     - exit 1 (미등록): `$WT_PATH/.project/tasks/<NNN_slug>/...` (워크트리 안)
    - 상태 = `tested` 검증. 그 외면 종료 (단 알려진 결함 *"OK 마무리"*는 status=tested로 명시되어 있어야 함).
    - GIT_RULE Read 우선순위:
      - `$MAIN_WT/.project/rules/GIT_RULE.md` (프로젝트별 — 우선)
@@ -123,12 +123,12 @@ git -C "$WT_PATH" rebase dev
 
 | 순위 | 자료 | 위치 |
 |------|------|------|
-| 1 | 태스크 문서 + plan 문서 (양쪽 정독 후 의도 종합) | 태스크: `$MAIN_WT/.project/tasks/<vX.X>/...` (등록 케이스) / `~/.taskery/worktrees/<projectId>/TASK-...` 다른 워크트리 (미등록 케이스, SSoT 조회로 경로 산출). plan: `$MAIN_WT/.project/plans/<vX.X>/` (ROADMAP / FEATURES / ARCHITECTURE / TECH-STACK 등) |
+| 1 | 태스크 문서 + 제품/plan 문서 (양쪽 정독 후 의도 종합) | 태스크: `$MAIN_WT/.project/tasks/<NNN_slug>/...` (등록 케이스) / `~/.taskery/worktrees/<projectId>/TASK-...` 다른 워크트리 (미등록 케이스, SSoT 조회로 경로 산출). 제품 관통 문서(FEATURES / ARCHITECTURE / TECH-STACK / DATA-MODEL / API-SPEC 등) = `$MAIN_WT/.project/<doc>.md` (루트 평평). plan 로컬(ROADMAP / PLAN) = `$MAIN_WT/.project/plans/<NNN_slug>/` |
 | 2 | 커밋 메시지 | `git log dev --grep` (GIT_RULE 풍부 메시지) |
 | 3 | diff | 변경 코드 자체 |
 
 - 1순위 부재 시 2/3순위 자동 fallback + 사용자에게 *자료 한계* 보고
-- 태스크 문서 = 본 task의 *세부 의도* / plan 문서 = *전체 의도* (Stage 순 / 의존 그래프 / 의도된 위치 분리). 충돌 영역의 *그림 전체*는 plan 문서가 더 명확한 경우 많음 (Stage 순서로 *먼저 머지된 쪽 다음 줄에 추가* 등)
+- 태스크 문서 = 본 task의 *세부 의도* / 제품·plan 문서 = *전체 의도* (Stage 순 / 의존 그래프 / 의도된 위치 분리). 충돌 영역의 *그림 전체*는 제품 문서(FEATURES/ARCHITECTURE)·ROADMAP이 더 명확한 경우 많음 (Stage 순서로 *먼저 머지된 쪽 다음 줄에 추가* 등)
 - 정독 후 *의미 의도 추출* → 충돌 해결 → `git rebase --continue`
 
 #### 4-c. 판단 불가 → 사용자 호출
@@ -144,8 +144,8 @@ git -C "$WT_PATH" rebase dev
 
 | 케이스 | 위치 | 흐름 |
 |--------|------|------|
-| 미등록 | `$WT_PATH/.project/tasks/<vX.X>/...` | 워크트리 안 task 문서 수정 → Step 6 Phase 커밋에 *코드 + 문서 = 한 커밋*에 포함 |
-| 등록 | `$MAIN_WT/.project/tasks/<vX.X>/...` | 워크트리 안 코드만 한 커밋 + 메인 워크트리 절대 경로 task 문서를 **proper-lockfile**로 별도 수정 (`bin/lib.js` `withMetaLock` — 머지 커밋 미포함, 메인 로컬 보존) |
+| 미등록 | `$WT_PATH/.project/tasks/<NNN_slug>/...` | 워크트리 안 task 문서 수정 → Step 6 Phase 커밋에 *코드 + 문서 = 한 커밋*에 포함 |
+| 등록 | `$MAIN_WT/.project/tasks/<NNN_slug>/...` | 워크트리 안 코드만 한 커밋 + 메인 워크트리 절대 경로 task 문서를 **proper-lockfile**로 별도 수정 (`bin/lib.js` `withMetaLock` — 머지 커밋 미포함, 메인 로컬 보존) |
 
 기록 형식 (task.md Result 섹션 안):
 ```markdown
@@ -233,7 +233,7 @@ closed-immutable.sh hook *허용* 영역 (status=closed 적용된 *후* 재수
 docs: [TASK-<NNN>] 태스크 문서 완료
 ```
 
-- 대상: `$WT_PATH/.project/tasks/<vX.X>/<NNN>_<slug>.md` (단일) 또는 `.../TASK-<NNN>_<slug>/task.md` (폴더 승격) + spec-diffs / screenshots / mockup (vX.X 공통, TASK_DOC_RULE §1.5).
+- 대상: `$WT_PATH/.project/tasks/<NNN_slug>/<NNN>_<slug>.md` (단일) 또는 `.../TASK-<NNN>_<slug>/task.md` (폴더 승격) + spec-diffs / screenshots / mockup (`<NNN_slug>` 공통, TASK_DOC_RULE §1.5).
 - **등록 케이스**: Step 6-5에서 메인 워크트리 직접 수정으로 처리 — 별도 커밋 X (워크트리 머지에 포함 X).
 
 #### 6-7. CHANGELOG 커밋 (해당 시)
@@ -376,4 +376,4 @@ git -C "$MAIN_WT" worktree remove "$WT_PATH"
 - **task 문서 단일 진실 소스** — `.gitignore` 케이스에 따라 메인 워크트리 또는 워크트리. 다른 세션의 충돌 해결 자료 정독 시 *SSoT 조회 → 워크트리 경로 산출* (미등록 케이스) 또는 *메인 워크트리 절대 경로* (등록 케이스).
 - **워크트리 + 브랜치 자동 제거** — GIT_RULE.md "작업 브랜치 삭제 정책" 면제 조항 (taskery 한정). 보존 키워드 시 양쪽 보존.
 - **safety net** — Step 14 복구 명령 출력. 사용자가 잘못 삭제 인지 시 즉시 복구 가능.
-- **BACKLOG.md 무관** — `.project/tasks/<vX.X>/BACKLOG.md` 체크 마킹은 `/task-init` Step 7.5가 처리(`[ ]` → `[x]` + `- TASK: TASK-NNN`). `[x]` = *task로 옮김* 의미라 close 시점에 추가 마킹 X. 완료 추적은 `npx @angar2/taskery status`(진행 중이면 dev 미머지가 정상) → 목록에 없을 때만 `git log dev --grep 'BL-NNN'` 순.
+- **BACKLOG.md 무관** — `.project/tasks/<NNN_slug>/BACKLOG.md` 체크 마킹은 `/task-init` Step 7.5가 처리(`[ ]` → `[x]` + `- TASK: TASK-NNN`). `[x]` = *task로 옮김* 의미라 close 시점에 추가 마킹 X. 완료 추적은 `npx @angar2/taskery status`(진행 중이면 dev 미머지가 정상) → 목록에 없을 때만 `git log dev --grep 'BL-NNN'` 순.

package/template/shared/skills/task-dev/SKILL.md

@@ -23,8 +23,8 @@ MAIN_WT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")
 
 | 케이스 | task 문서 / Result 갱신 위치 | CLAUDE.md (검증 명령) |
 |--------|---------------------------|----------------------|
-| 등록 (퍼블릭 리포 default) | `$MAIN_WT/.project/tasks/<vX.X>/...` (`bin/lib.js` `withMetaLock`) | `$MAIN_WT/CLAUDE.md` |
-| 미등록 | `$WT_PATH/.project/tasks/<vX.X>/...` (워크트리 안, 머지 시 dev 반영) | `$MAIN_WT/CLAUDE.md` (CLAUDE.md는 단일 소스) |
+| 등록 (퍼블릭 리포 default) | `$MAIN_WT/.project/tasks/<NNN_slug>/...` (`bin/lib.js` `withMetaLock`) | `$MAIN_WT/CLAUDE.md` |
+| 미등록 | `$WT_PATH/.project/tasks/<NNN_slug>/...` (워크트리 안, 머지 시 dev 반영) | `$MAIN_WT/CLAUDE.md` (CLAUDE.md는 단일 소스) |
 
 self-check 명령은 워크트리(`$WT_PATH`)에서 실행 — 코드 변경이 워크트리 안에 있으므로 검증 대상도 거기.
 
@@ -33,6 +33,7 @@ self-check 명령은 워크트리(`$WT_PATH`)에서 실행 — 코드 변경이
 - `/task-plan` 끝나고 기획 합의된 직후.
 - 도중 끊겼던 task 이어서 구현 (status=`developing`).
 - `/task-test` FAIL 후 사용자 *"고쳐"* 응답 → status가 `developing`으로 되돌아온 경우 재진입.
+  - **시각 어긋남 FAIL의 경우** — 격리 세션이 준 *어긋남 목록*(예: "헤더 색 틀림 / 카드 세로로 쌓임 / 저장버튼 없음")을 **한 번에 배치로** 수정한다 (흠을 사용자가 찾는 게 아니라 test가 찾아준 목록을 보고 고침). 수정 후 `/task-test` 재검사 — 라운드 상한 3회(task-test 흐름 참조).
 
 ## 입력 처리
 
@@ -49,7 +50,7 @@ self-check 명령은 워크트리(`$WT_PATH`)에서 실행 — 코드 변경이
 1. `.project/AGENT-GUIDE.md` Read → 활성 plan 버전 확인.
 2. task 파일 Read:
    - 인자 있음 → 해당 파일.
-   - 인자 없음 → `ls .project/tasks/<vX.X>/` 결과 중 status=`planned` 또는 `developing`인 가장 최근 파일. 발견 시 *"TASK-<NNN> 진행할까요?"* confirm. 없으면 *"진행할 task 없음. `/task-plan` 먼저 호출."* + 종료.
+   - 인자 없음 → `ls .project/tasks/<NNN_slug>/` 결과 중 status=`planned` 또는 `developing`인 가장 최근 파일. 발견 시 *"TASK-<NNN> 진행할까요?"* confirm. 없으면 *"진행할 task 없음. `/task-plan` 먼저 호출."* + 종료.
 3. 상태 검증:
    - `planned` → 신규 진행 (Step 2 status 전환).
    - `developing` → 이어가기 (Step 2 skip — 이미 developing).
@@ -76,9 +77,9 @@ self-check 명령은 워크트리(`$WT_PATH`)에서 실행 — 코드 변경이
 
 ### Step 4 — Phase 0 처리 (있을 시)
 
-Dev Plan에 Phase 0(plan 문서 변경)이 있으면:
-1. `.project/plans/<vX.X>/<문서>.md` Edit.
-2. `.project/tasks/<vX.X>/spec-diffs/<NNN>_<slug>_spec-diff.md` 이미 `/task-plan`에서 만들어졌으면 그대로. 없으면 작성 (TASK_DOC_RULE §spec-diff 형식 참조).
+Dev Plan에 Phase 0(제품 관통 문서 변경)이 있으면:
+1. `.project/<문서>.md` (루트 제품 관통 문서) Edit. **DATA-MODEL/API-SPEC 상세는 구현 동반으로 여기서 확정** — plan-init이 미룬 스키마·엔드포인트 본문을 실제 구현 기준으로 채운다.
+2. `.project/tasks/<NNN_slug>/spec-diffs/<NNN>_<slug>_spec-diff.md` 이미 `/task-plan`에서 만들어졌으면 그대로. 없으면 작성 (TASK_DOC_RULE §spec-diff 형식 참조).
 3. Phase 0 `진행: [x]` Edit.
 
 ### Step 5 — flows/ 업데이트 (해당 시)
@@ -188,7 +189,7 @@ stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서
 - **Phase 순서 건너뛰기 X** — Phase 1 끝나기 전 Phase 2 진행 X. 의존 관계 깨짐 + 디버깅 어려워짐.
 - **계획 외 스코프 확장 X** — Dev Plan에 없는 파일 다루기 전 사용자 confirm. *"이 부분 같이 작업해야 할 것 같은데 OK?"* 합의 후 진행.
 - **모호 발화 confirm 룰 (stash FRICTION_LOG #21+22 반영)** — 사용자 발화가 코드/문서/기능 영역에서 *복수 매칭* 가능할 때 자율 추정 영구 금지. 메인 *자체 안 1개* + *"X 의미 맞아?"* 한 줄 confirm 후 진행. 옵션 4개 늘어놓기 금지 (메인 판단 위임 회피 패턴). 예: 사용자 *"환경설정 아이콘"* 발화 → popover 톱니 / Settings 탭바 아이콘 둘 다 가능 → 어느 영역인지 한 줄 confirm 필수.
-- **디자인 산출 정독 의무 (stash FRICTION_LOG #14+19 / #12 일반화)** — task에 디자인 산출 (HTML 목업 / Figma / 디자인 파일 등) 있으면 메인이 *직접 Read* 후 구현. sub-agent 위임 금지 (요약만 받아 디자인 정합 깨짐). 구현 = 디자인 산출 기준 (역방향 X — 코드 편의로 디자인 어김 절대 X). 목업 위치 = `.project/tasks/<vX.X>/mockup/<task-doc-name>-mockup.html`.
+- **디자인 산출 정독 의무 (stash FRICTION_LOG #14+19 / #12 일반화)** — task에 디자인 산출 (HTML 목업 / Figma / 디자인 파일 등) 있으면 메인이 *직접 Read* 후 구현. sub-agent 위임 금지 (요약만 받아 디자인 정합 깨짐). 구현 = 디자인 산출 기준 (역방향 X — 코드 편의로 디자인 어김 절대 X). 목업 위치 = `.project/tasks/<NNN_slug>/mockup/<task-doc-name>-mockup.html`.
 - **self-check FAIL 시 `developed` 전환 X** — 무리하게 상태 갱신 금지. 메인 자체 수정 시도 → 안 되면 사용자에게 보고. *"잘 될 거야"* 가정 금지.
 - **로그 심기 잊지 X** — Dev Plan 작성 시 `[로그]` 항목 명시되어 있으면 *반드시* 실제 로그 코드 삽입. 격리 세션 / 운영 디버깅 모두 의존.
 - **Result 섹션 진행만** — 테스트 결과는 `/task-test`가 기록. 메인이 *"잘 됐을 거야"* 가정 작성 금지.

package/template/shared/skills/task-init/SKILL.md

@@ -66,30 +66,30 @@ description: task 시작 — 워크트리 분기 + 6 섹션 빈 골격 + 헤더
 
 ### Step 2 — active plan 버전 확인
 
-1. `$MAIN_WT/.project/AGENT-GUIDE.md` Read → *활성 plan 버전* 추출 (예: `v1.0`).
-2. AGENT-GUIDE.md 없거나 활성 버전 누락 시 → 사용자에게 *"활성 plan 버전이 없는데 `/plan-init` 먼저 실행할까요?"* 묻고 중단.
-3. `$MAIN_WT/.project/plans/<vX.X>/` 디렉토리 존재 확인. 없으면 동일하게 `/plan-init` 안내 + 중단.
+1. `$MAIN_WT/.project/AGENT-GUIDE.md` Read → *활성 plan* 추출 (예: `001_mvp` — `NNN_slug` 폴더명).
+2. AGENT-GUIDE.md 없거나 활성 plan 누락 시 → 사용자에게 *"활성 plan 버전이 없는데 `/plan-init` 먼저 실행할까요?"* 묻고 중단.
+3. `$MAIN_WT/.project/plans/<NNN_slug>/` 디렉토리 존재 확인. 없으면 동일하게 `/plan-init` 안내 + 중단.
 
 ### Step 3 — 분기 판단 + 메타 수집
 
 직전 대화 정독:
 - 작업 주제 / 유형 / 출처 / 규모 추정 가능?
   - **추정 가능** → 분기 1 (제안):
-    *"직전 맥락 보니 다음 task 만들까요? 주제: <X> / 유형: <Y> / 출처: <Z> / 규모: <W> / 플랜: <vX.X>. 어떠세요?"*
+    *"직전 맥락 보니 다음 task 만들까요? 주제: <X> / 유형: <Y> / 출처: <Z> / 규모: <W> / plan: <NNN_slug>. 어떠세요?"*
     사용자 답 — *"OK"* / *"규모는 large야"* / *"유형은 bug야"* 등 부분 수정 받음.
   - **추정 불가** → 분기 2 (인터뷰): 한 번에 한 질문씩.
     - Q1: *"무슨 작업인가요? (한 줄로)"*
     - Q2: *"유형? (feature / bug / improvement / refactor / docs / chore)"*
     - Q3: *"출처? (백로그 BL-NNN / 로드맵 RM-NNN / 직접 요구사항 DR)"*
     - Q4: *"규모? (micro / small / medium / large) — 잘 모르겠으면 추정 알려드림."*
-    - (필요 시) Q5: *"플랜 버전 `<vX.X>` 맞나요?"*
+    - (필요 시) Q5: *"plan `<NNN_slug>` 맞나요?"*
 
 수집 항목 (모두 확정되어야 진행):
 - 주제 (한국어 — kebab-slug 변환은 Step 4)
 - 유형: `feature` / `bug` / `improvement` / `refactor` / `docs` / `chore`
 - 출처: `BL-NNN` / `RM-NNN` / `DR`
 - 규모: `micro` / `small` / `medium` / `large`
-- 플랜 버전: 활성 버전 그대로 (Step 2에서 가져온 값)
+- plan: 활성 plan 그대로 (Step 2에서 가져온 `NNN_slug` 값)
 
 ### Step 4 — TASK 번호 결정 + 결정적 슬러그 + SSoT 안전망
 
@@ -116,8 +116,8 @@ NEXT=$((MAX + 1))
 
 #### 4.2 메타 가져오기 (BL/RM)
 
-- BL: `$MAIN_WT/.project/tasks/<활성버전>/BACKLOG.md` Read → `BL-NNN` 블록 파싱 → `{ status, type, title, slug, summary, target, taskNums }` (활성 버전은 `AGENT-GUIDE.md`에서 검출. `bin/lib.js`의 `parseBacklogItem(mainWtPath, blId)` 호출 권장). 개요 / 대상 영역 → task.md §1 Requirements 초안에 자동 복사 (얕은 분석이 task 문서 시작점)
-- RM: `$MAIN_WT/.project/plans/<활성버전>/ROADMAP.md` Read → `RM-NNN` grep → 항목 메타 파싱
+- BL: `$MAIN_WT/.project/tasks/<활성 plan>/BACKLOG.md` Read → `BL-NNN` 블록 파싱 → `{ status, type, title, slug, summary, target, taskNums }` (활성 plan은 `AGENT-GUIDE.md`에서 검출. `bin/lib.js`의 `parseBacklogItem(mainWtPath, blId)` 호출 권장). 개요 / 대상 영역 → task.md §1 Requirements 초안에 자동 복사 (얕은 분석이 task 문서 시작점)
+- RM: `$MAIN_WT/.project/plans/<활성 plan>/ROADMAP.md` Read → `RM-NNN` grep → 항목 메타 파싱
 - DR: 사용자 발화에서 주제 그대로
 
 #### 4.2.5 이미 `[x]` BL 재진행 케이스
@@ -149,8 +149,8 @@ git -C "$MAIN_WT" branch --no-merged dev --list \
 
 1. 파일 vs 폴더 분기 (기존 룰 유지):
    - **파일 default**: 단일 `NNN_<slug>.md`.
-   - **폴더 승격 조건**: (a) 규모 `large`, 또는 (b) 사용자 명시 *"폴더로 만들어줘"*, 또는 (c) task에 *추가 자료* 다수 예상.
-   - **spec-diffs / screenshots / mockup은 vX.X 공통** — 단일/폴더 모두 `.project/tasks/<vX.X>/{spec-diffs,screenshots,mockup}/`에 위치. (TASK_DOC_RULE §1.5)
+   - **폴더 승격 조건**: *사용자 명시* 시에만 (*"폴더로 만들어줘"* 류). 규모 large·추가 자료 다수여도 자동 승격하지 않는다 — 기본은 항상 단일 파일. 기능 자체는 유지(사용자가 원하면 그대로 사용).
+   - **spec-diffs / screenshots / mockup은 `<NNN_slug>` 공통** — 단일/폴더 모두 `.project/tasks/<NNN_slug>/{spec-diffs,screenshots,mockup}/`에 위치. (TASK_DOC_RULE §1.5)
 2. 브랜치명 산출 (멀티세션 형식):
    ```
    {타입}/{개발자}_TASK-NNN_{출처}_{슬러그}
@@ -184,8 +184,8 @@ git -C "$MAIN_WT" check-ignore -q "$MAIN_WT/.project/dummy"
 
 | 결과 | 케이스 | 작성 위치 |
 |------|--------|----------|
-| exit 0 | **등록됨** (퍼블릭 리포 default) | **메인 워크트리** (`$MAIN_WT/.project/tasks/<vX.X>/`) — proper-lockfile로 안전 쓰기. 멀티세션 공유 단일 소스. dev untracked (git 자동 무시) |
-| exit 1 | **미등록** | **워크트리 안** (`$WT_PATH/.project/tasks/<vX.X>/`) — 워크트리 커밋 + 머지 시 dev에 반영 |
+| exit 0 | **등록됨** (퍼블릭 리포 default) | **메인 워크트리** (`$MAIN_WT/.project/tasks/<NNN_slug>/`) — proper-lockfile로 안전 쓰기. 멀티세션 공유 단일 소스. dev untracked (git 자동 무시) |
+| exit 1 | **미등록** | **워크트리 안** (`$WT_PATH/.project/tasks/<NNN_slug>/`) — 워크트리 커밋 + 머지 시 dev에 반영 |
 
 빈 골격 형식 (TASK_DOC_RULE §1.3 참조):
 
@@ -194,7 +194,7 @@ git -C "$MAIN_WT" check-ignore -q "$MAIN_WT/.project/dummy"
 
 | 생성일 | 플랜 | 유형 | 규모 | 상태 |
 |--------|------|------|------|------|
-| <YYYY-MM-DD> | <vX.X> | <유형> | <규모> | draft |
+| <YYYY-MM-DD> | <NNN_slug> | <유형> | <규모> | draft |
 
 ## Requirements
 
@@ -242,7 +242,7 @@ git -C "$MAIN_WT" check-ignore -q "$MAIN_WT/.project/dummy"
 - 워크트리: <WT_PATH>
 - 브랜치: <BRANCH>
 - task 문서: <TASK_DOC_PATH> (메인 워크트리 / 워크트리 안 — 위 케이스에 따라)
-- 헤더: <생성일> / <vX.X> / <유형> / <규모> / draft
+- 헤더: <생성일> / <NNN_slug> / <유형> / <규모> / draft
 - BL 마킹: BL-<NNN> [x] (BL 출처 시. RM/DR이면 생략)
 - 다음: /task-plan TASK-<NNN> 으로 기획 채우기 (워크트리 폴더에서 새 세션 열어 진행 / 메인 세션 그대로 진행 / 메인이 서브 세션 spawn 등 운영 모델 자유)
 ```
@@ -250,7 +250,7 @@ git -C "$MAIN_WT" check-ignore -q "$MAIN_WT/.project/dummy"
 ## 도구 가이드
 
 - **Bash**: 메인 워크트리 검출 / 사전 검증 / `git worktree add` / SSoT 조회 / TASK-NNN 계산
-- **Read**: `$MAIN_WT/.project/AGENT-GUIDE.md` / `$MAIN_WT/.project/tasks/<활성버전>/BACKLOG.md` / `$MAIN_WT/.project/plans/<활성버전>/ROADMAP.md`
+- **Read**: `$MAIN_WT/.project/AGENT-GUIDE.md` / `$MAIN_WT/.project/tasks/<활성 plan>/BACKLOG.md` / `$MAIN_WT/.project/plans/<활성 plan>/ROADMAP.md`
 - **Write**: task.md 빈 골격 작성 (위치는 .gitignore 케이스에 따라)
 - **AskUserQuestion**: 분기 2 인터뷰 (한 번에 한 질문)
 
@@ -258,8 +258,8 @@ git -C "$MAIN_WT" check-ignore -q "$MAIN_WT/.project/dummy"
 
 - **워크트리 생성 + task 문서 작성만 담당** — 본문 채우기 금지. Requirements / Scope / Dev Plan / Test Plan 본문은 *반드시* `/task-plan`에서.
 - **단계 경계 — 허용/금지 명시 (stash FRICTION_LOG #11 반영)**:
-  - **허용 (화이트리스트)**: `$MAIN_WT/.project/plans/<활성버전>/ROADMAP.md` §4(다음 작업 영역) 확인 / SSoT 조회 / TASK-NNN 계산 / 빈 골격 Write
-  - **금지 (블랙리스트)**: ARCHITECTURE.md / API-SPEC.md / FEATURES.md 등 9 기획 문서 본문 Read / 도메인 코드 Read · Grep / 기존 task 본문 Read
+  - **허용 (화이트리스트)**: `$MAIN_WT/.project/plans/<활성 plan>/ROADMAP.md` §4(다음 작업 영역) 확인 / SSoT 조회 / TASK-NNN 계산 / 빈 골격 Write
+  - **금지 (블랙리스트)**: ARCHITECTURE.md / API-SPEC.md / FEATURES.md 등 `.project/` 루트 제품 관통 문서 본문 Read / 도메인 코드 Read · Grep / 기존 task 본문 Read
   - 본문 정보 수집은 *다음 단계 `/task-plan`*에서 수행.
 - **자동 추정 진행 X** — 직전 맥락 명확해도 *제안 + 사용자 OK* 거친 후 워크트리/파일 생성.
 - **상태는 `draft` 고정** — `/task-init` 끝의 상태는 `draft` 외 작성 금지.