@angar2/taskery 0.6.1 → 0.8.0

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

@@ -1,13 +1,13 @@
 ---
 name: project-init
-description: taskery 도입 직후 1회성 — 진입 문서(PROJECT/AGENT-GUIDE/…) + 제품 관통 기획 문서(그룹 A 작성 / 그룹 B 골격) 생성
+description: taskery 도입 직후 1회성 — AGENTS.md 리포 값 + 진입 문서(PROJECT/GLOSSARY/…) + 리포 로컬 룰 초안 + 제품 관통 기획 문서(그룹 A 작성 / 그룹 B 골격) 생성
 ---
 
 # /project-init
 
 ## 개요
 
-taskery 도입 직후 **1회성**으로 호출. 사용자 또는 동료가 새 리포에 npx로 taskery 세팅 직후 처음 부르는 스킬. `.project/` 영역의 사람용/메인용 진입 문서와 **제품 관통 기획 문서**(루트 평평 배치)를 만든다.
+taskery 도입 직후 **1회성**으로 호출. 사용자 또는 동료가 새 리포에 npx로 taskery 세팅 직후 처음 부르는 스킬. 진입 문서 `AGENTS.md`의 리포 값(메타·명령)을 채우고, `.project/` 영역의 사람용/메인용 문서와 **제품 관통 기획 문서**(루트 평평 배치), 그리고 이 리포의 로컬 룰 초안을 만든다.
 
 제품 관통 문서 2그룹 (`.project/` 루트):
 - **그룹 A — 정적(내용까지 작성)**: SERVICE-POLICY.md / TECH-STACK.md / ARCHITECTURE.md. project-init이 인터뷰로 *작성*. (이후 plan-init은 부수적 add/mod만.)
@@ -53,6 +53,25 @@ taskery 도입 직후 **1회성**으로 호출. 사용자 또는 동료가 새
    - Q4: 단일 리포 / 멀티 리포?
    - Q5: (멀티 리포 시) 연결 리포 목록 + 각 역할?
 
+### Step 2.5 — `AGENTS.md` 리포 값 채우기
+
+진입 문서 `AGENTS.md`(프로젝트 루트)에는 **이 리포의 값이 들어갈 빈 칸 4개**가 있다. 이 칸이 placeholder(`<예: ...>`)로 남으면 `/task-dev` self-check 게이트, `/task-close` 최종 게이트, `/task-test` 격리 세션이 **실행할 명령을 찾지 못한다.** 본 단계에서 반드시 채운다.
+
+> `CLAUDE.md`는 `@AGENTS.md` 임포트 한 줄이라 채울 것이 없다. 값은 `AGENTS.md`에만 쓴다.
+
+| 절 | 채울 내용 | 출처 |
+|----|----------|------|
+| `## 프로젝트 메타` | 이름 / 타입 / 한 줄 소개 | Step 2 수집 결과 그대로 |
+| `## 검증 명령` | 린트 · 타입체크 · 빌드 — *코드 상태* 검증 | 기존 코드면 `package.json` scripts·`Makefile` 등에서 탐지 후 confirm / 빈 프로젝트면 스택 확정 후 기입 |
+| `## 테스트 명령` | 단위 · 통합 · E2E — *테스트 실행* | 위와 동일 |
+| `## 검수 실행 명령` | 기준 포트 · 실행 명령 | 앱을 띄워 사람이 확인하는 프로젝트만. 아니면 **절 전체를 삭제** |
+
+규칙:
+- 백틱 안 명령은 *그대로 실행 가능한* 형태여야 한다. 추상 서술 금지.
+- 해당 없는 항목은 **행 자체를 삭제**한다. 빈 백틱(``)을 남기지 않는다.
+- 아직 정할 수 없으면 placeholder를 지우고 *"미정 — 첫 `/task-plan`에서 확정"*이라고 명시한다. 방치 금지.
+- 최종안을 사용자에게 보여주고 confirm 받은 후 기록한다.
+
 ### Step 3 — `.project/PROJECT.md` 작성
 
 사람용 진입 문서. 개발자가 *"이 프로젝트 뭐 하는 거야?"* 알 수 있게.
@@ -138,45 +157,64 @@ taskery 도입 직후 **1회성**으로 호출. 사용자 또는 동료가 새
 <!-- 기능 그룹 / 도메인 섹션이 여기 누적된다. 초기엔 비어 있음. -->
 ```
 
-### Step 4 — `.project/AGENT-GUIDE.md` 작성
+### Step 4 — 리포 로컬 룰 초안 작성 (`TEST_RULE.local.md` · `DEV_RULE.local.md`)
+
+이 둘은 코어 짝이 없는 로컬 전용 문서이나 **모든 리포에 반드시 존재해야 한다** (`TASKERY_RULE` §8). 없으면 이후 세션이 이 프로젝트의 검증·구현 방식을 모른 채 일반론으로 진행한다.
+
+1. **리포 분석** — 기존 코드가 있으면 테스트 러너·빌드 도구·실행 스크립트를 탐지한다(`package.json` scripts, `Makefile`, `*.xcodeproj`, `pytest.ini` 등).
+2. **초안 제시 → 사용자 confirm → 생성.** 탐지 결과를 근거로 채운 초안을 보여주고 승인받은 후 `.project/rules/`에 작성한다.
+3. 빈 프로젝트라 정할 것이 없으면 **섹션 헤더만 있는 골격을 생성**한다 (각 절에 *"첫 `/task-plan`에서 확인 후 기록"* 표시). **파일 자체는 어떤 경우에도 생성한다.**
+
+`TEST_RULE.local.md` 골격:
+
+```markdown
+# TEST_RULE.local.md — 이 리포의 검증 규칙
+
+> 이 프로젝트에서 각 테스트 방식을 *실제로 어떻게 실행하나* + *무엇을 얼마나 검증하나*의 단일 소스.
+> 구성과 의무는 `.project/rules/TASKERY_RULE.md` §8 참조.
+> `*.local.md`는 taskery update가 건드리지 않는다 — 이 리포가 소유한다.
+
+## 방식별 실행 경로
+
+> 그대로 실행 가능한 명령·경로로 적는다. 모르면 비워 두지 말고 `/task-plan`이 사용자에게 확인한 즉시 기록한다.
 
-메인 세션 진입 가이드. 새 메인 세션이 부르는 *"읽고 시작"* 문서.
+- **데이터 검증** (DB / 파일 / 상태 조회): <아직 미정>
+- **API 호출** (엔드포인트 / 외부 인터페이스): <아직 미정>
+- **UI 동작 · E2E** (클릭 / 입력 / 흐름 자동화): <아직 미정>
+- **시각 실행** (앱 기동 + 화면 캡처): <아직 미정>
+- **기타**: <아직 미정>
+
+## 테스트 실행 환경 (격리 실행 경로)
+
+> 실제 앱을 띄워 UI를 자동 조작하는 스위트를 **사용자의 화면·마우스·키보드를 뺏지 않고** 돌리는 경로.
+> 여기가 비어 있으면 자동 게이트·격리 세션은 그 스위트를 실행하지 않고 사용자 승인을 받는다.
+> 적을 수 있는 것: 창 숨김·헤드리스 플래그 / 가상 디스플레이·컨테이너 / VM / CI 러너 위임 / 점유 스위트를 제외하는 한정 실행 옵션.
+> 결정 자체도 기록 대상 — 격리 경로를 두지 않기로 했다면 *"없음 — 매번 승인(사용자 결정 YYYY-MM-DD)"*로 적어 미결정 상태와 구분한다.
+
+<아직 미정>
+
+## 범위·방식 정책
+
+> 무엇을 얼마나 검증하나 — 수정 루프에서의 실행 범위, 테스트 신설 상한 등.
+
+<아직 미정>
+```
+
+`DEV_RULE.local.md` 골격:
 
 ```markdown
-# AGENT-GUIDE.md
-
-## 활성 plan 버전   <!-- 값 = NNN_slug 폴더명(버전 아님). 헤딩 텍스트는 lib.js/스킬이 의존하므로 변경 X -->
-<예: 001_mvp — `.project/plans/001_mvp/` 참조>
-
-## 메인이 매 세션 시작 시 읽을 것
-1. `CLAUDE.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`
-- task 진행: `/task-dev` → `/task-test` → `/task-close`
-- 불편 등록: `/log-friction` (사용자 호출 / 발화 캐치 / task-close 자체 감지)
-
-## 폴더 구조
-- `.project/rules/` — 코어 룰 (TASK_DOC_RULE / GIT_RULE / CHANGELOG_RULE / MOCKUP_RULE)
-- `.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 빈 템플릿."
-멀티 리포면 "LINKED-REPOS.md 참조">
+# DEV_RULE.local.md — 이 리포의 구현 규칙
+
+> 이 프로젝트 고유의 구현 정책. 구성과 의무는 `.project/rules/TASKERY_RULE.md` §8 참조.
+> `*.local.md`는 taskery update가 건드리지 않는다 — 이 리포가 소유한다.
+
+## 구현 정책
+
+<아직 미정 — 코드 배치 관행 · 금지 패턴 · 의존성 추가 기준 등>
+
+## 빌드·실행 전제
+
+<아직 미정 — 테스트 전 빌드 필요 여부 등>
 ```
 
 ### Step 4.5 — `.project/GLOSSARY.md` 작성 (도메인 용어집)
@@ -243,8 +281,7 @@ stash FRICTION_LOG #3 반영 — 프로젝트 도메인 용어를 *영문/한글
 - `.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` (코어 룰)
+- `.project/rules/{TASKERY_RULE,TASK_DOC_RULE,GIT_RULE,CHANGELOG_RULE,MOCKUP_RULE}.md` (코어 룰 5종)
 
 → `/project-init`은 폴더 생성 X. 누락 시(`init` 안 거치고 수동 셋업한 경우)에만 `mkdir -p` 실행.
 
@@ -254,7 +291,7 @@ mkdir -p .project/{changelog,flows,plans,tasks}
 mkdir -p .project/shared/sent/completed .project/shared/received/completed
 ```
 
-`.project/FRICTION_LOG.md`도 `init`이 카피한 빈 템플릿 그대로 사용. **이미 있으면 덮어쓰기 X** — 사용자 데이터 보호.
+`.project/FRICTION_LOG.md`는 배포되지 않는다 — `/log-friction`이 첫 기록 때 생성한다. **이미 있으면 덮어쓰기 X** — 사용자 데이터 보호.
 
 ### Step 7.5 — git 초기화 + 첫 ref 분기 (빈 폴더 케이스)
 
@@ -284,11 +321,11 @@ git branch -a                                        # main(또는 master) + dev
 ### Step 8 — 결과 보고
 
 작성된 파일 목록 + 다음 단계 안내:
-- *"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) 작성."*
+- *"AGENTS.md 리포 값 4칸(메타·검증·테스트·검수 명령) 기입 + PROJECT.md(초기 빌드 로드맵 포함) / LINKED-REPOS.md / GLOSSARY.md / .env + 제품 관통 문서(그룹 A 작성: SERVICE-POLICY·TECH-STACK·ARCHITECTURE / 그룹 B 골격: DATA-MODEL·API-SPEC·FEATURES·UX-UI, 타입 해당분) + 리포 로컬 룰 초안(TEST_RULE.local.md · DEV_RULE.local.md) 생성. (빈 골격 폴더·코어 룰은 npx init이 이미 카피한 것 그대로 — project-init이 생성 X). **빈 폴더 케이스라 git init + dev 분기까지 완료** (이미 git 리포면 건너뜀). 다음은 `/plan-init <기능그룹>`으로 첫 plan(MVP면 여러 기능 그룹을 묶은 큰 plan) 작성."*
 
 **결과 commit 흐름** (GIT_RULE 정합):
 - 현재 브랜치(= 부모, 기본 dev)가 dev/main이면 직접 commit *금지* (git-guard.sh 차단). 두 가지 default 흐름:
-  1. **첫 task에 묶기 (권장)**: `/plan-init` 끝나고 첫 `/task-init` (보통 TASK-001 부트스트랩 chore)으로 만든 작업 브랜치에서 init 산출물(PROJECT/AGENT-GUIDE/LINKED-REPOS/.env)도 함께 commit. task-close 단계의 "태스크 문서 커밋"에 자연스럽게 묶임.
+  1. **임시 docs 브랜치 (권장)**: `git checkout -b docs/{개발자}_init-bootstrap` 후 commit → 현재 브랜치(부모)에 `--no-ff` 머지. **첫 task 브랜치에 묶는 방식은 쓰지 않는다** — init 산출물은 메인 워크트리에 남고 task는 별도 워크트리라 같은 브랜치에 담을 경로가 없다.
   2. **임시 docs 브랜치**: `git checkout -b docs/{개발자}_init-bootstrap` 후 commit → 현재 브랜치(부모)에 `--no-ff` 머지. 첫 task 생성 *전*에 init 결과를 깔끔히 기록하고 싶을 때.
 
 ## 도구 가이드

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

@@ -80,11 +80,11 @@ LOCK_FILE="$HOME/.taskery/${PROJECT_ID}.merge.lock"
      - `$MAIN_WT/.project/rules/GIT_RULE.md` (프로젝트별 — 우선)
      - `~/.claude/rules/GIT_RULE.md` (글로벌)
      둘 다 없으면 종료 + *"GIT_RULE 누락"* 보고.
-   - **로컬 오버라이드** — `$MAIN_WT/.project/rules/GIT_RULE.local.md`가 있으면 함께 Read하고, 겹치는 항목은 **로컬 우선** 적용한다 (`npx update` 미터치 영역). 단 로컬 룰이 뒤집을 수 없는 것: 부모 브랜치 직접 커밋 금지 · `--no-ff` 강제 · 머지 락 직렬화 · destructive 명령 사용자 승인.
+   - **로컬 오버라이드** — `$MAIN_WT/.project/rules/GIT_RULE.local.md`가 있으면 함께 Read하고, 겹치는 항목은 **로컬 우선**, **겹치지 않는 로컬 조항도 그대로 준수**한다 (`TASKERY_RULE` §7 — 구속력은 코어와 동등). 단 로컬 룰이 뒤집을 수 없는 것: 부모 브랜치 직접 커밋 금지 · `--no-ff` 강제 · 머지 락 직렬화 · destructive 명령 사용자 승인.
 
 ### Step 2 — 최종 검증 명령 재실행 (게이트)
 
-`$MAIN_WT/CLAUDE.md`의 `## 검증 명령` (빌드/린트/타입체크) 만 재실행. **하나라도 FAIL이면 close 차단**.
+`$MAIN_WT/AGENTS.md`의 `## 검증 명령` (빌드/린트/타입체크) 만 재실행. **하나라도 FAIL이면 close 차단**.
 
 | 명령 | 결과 |
 |------|------|
@@ -114,10 +114,10 @@ FAIL 시:
 
 | # | 대상 | 갱신 내용 |
 |---|------|----------|
-| 1 | `.project/plans/<활성 plan>/PLAN.md` | 본 task에 해당하는 체크리스트 항목 `[x]` + TASK 번호 표기 |
+| 1 | `.project/plans/<활성 plan>/PLAN.md` | 본 task에 해당하는 체크리스트 항목 `[x]` + **`TASK-NNN`(3자리 제로패드) 문자열 표기 의무** — Step 3 `close`가 이 문자열을 grep 게이트로 검사한다(로드맵 출처 `ST-N`/`RM-NNN` 태스크만 — BL·DR 출처는 체크리스트 항목 자체가 없어 검사 제외). 누락 시 `blocked:'docs'`로 멈춘다 |
 | 2 | `.project/plans/<활성 plan>/ROADMAP.md` | Stage 상태·완료 노트 (출처가 `ST-N`이거나 Stage 진척이 생긴 경우) |
-| 3 | `.project/changelog/<YYYY-MM>.md` | 본 task 항목 추가. **파일이 없으면 생성한다** (형식은 `.project/rules/CHANGELOG_RULE.md` — `.local.md` 있으면 그쪽 우선) |
-| 4 | 본 task가 수정한 **제품 관통 문서·plan 문서**의 `## 수정 이력` | 해당 문서마다 행 추가, 표가 없으면 신설. 대상 목록의 출처 = `spec-diffs/` + Dev Plan Phase 0 기록 (등록 케이스는 `.project/`가 git 밖이라 `git diff`로 찾을 수 없다). **task 문서는 제외** — close가 잠그는 별개 계열이다 |
+| 3 | `.project/changelog/` | **close CLI가 자동 append한다** (헤더·날짜·타입·변경 요약=Dev Plan Phase 명. 단일 `CHANGELOG.md`/월별 두 형식 지원, 파일 없으면 생성 — `CHANGELOG_RULE` §2). 세션은 작성 불요 — 요약을 보강하고 싶을 때만 append된 항목을 자유 편집(선택) |
+| 4 | 본 task가 수정한 **제품 관통 문서·plan 문서**의 `## 수정 이력` | 해당 문서마다 행 추가(표가 없으면 신설) + **행에 `TASK-NNN`(3자리 제로패드) 문자열 표기 의무** — Step 3 `close`가 `spec-diffs/` 대상 문서(DEL 제외)마다 이 문자열을 grep 게이트로 검사한다. 누락 시 `blocked:'docs'`. 대상 목록의 출처 = `spec-diffs/` + Dev Plan Phase 0 기록 (등록 케이스는 `.project/`가 git 밖이라 `git diff`로 찾을 수 없다). **task 문서는 제외** — close가 잠그는 별개 계열이다 |
 | 5 | 후속 task 후보 (있을 때만) | **손편집 금지** — `backlog_add` 도구(또는 `npx @angar2/taskery backlog-add ...`)로 등재한다. BL 채번·서식·`withMetaLock` 직렬화를 코드가 보장하며, 파일 위치는 등록/미등록과 무관하게 **항상 메인 워크트리**(`.project/tasks/<활성 plan>/BACKLOG.md`)다 — 위 "편집 위치" 분기가 적용되지 않는 유일한 항목 |
 | 6 | `spec-diffs/` ↔ 실제 문서 변경 | 기재한 diff가 실제 반영됐는지 대조 |
 
@@ -128,16 +128,19 @@ FAIL 시:
 
 `task_close` 도구 (또는 `npx @angar2/taskery close TASK-NNN`) 한 번으로 다음을 코드가 수행:
 - **Phase 기능 커밋** — uncommitted 코드 변경분(`.project/` 외)을 task.md `### Phase N`의 `- 파일:` 필드에 매핑해 Phase 순서대로 자동 커밋 (GIT_RULE 메시지 형식, 태그 자동: feature→`feat:` / bug→`fix:` / improve→`improve:` / refactor→`refactor:` / docs·chore→`docs:`). 매핑 폴백은 GIT_RULE §"Phase↔파일 매핑 규칙" — 한 파일이 여러 Phase에 걸치면 *가장 이른 Phase*, Dev Plan에 없는 *빌드 산출물*(`*.pbxproj`·잠금파일)은 *마지막 Phase*에 자동 편입(커밋 메시지에 사유 표기).
+- **문서 게이트** (모든 변이 앞) — Step 2.5 항목 1(PLAN 체크리스트)·4(수정 이력)의 `TASK-NNN` 표기를 grep 검사. 누락 시 `blocked:'docs'`로 멈춘다(아무것도 안 바뀐 상태).
 - **status → `closed`** — task 문서 헤더 (`.gitignore` 케이스 자동 판정 — 등록=메인WT / 미등록=워크트리).
-- **flows/문서 커밋** (미등록 케이스) — 워크트리 안 `.project/flows/` + task 문서.
+- **CHANGELOG 자동 append** — `[TASK-NNN]` 항목을 changelog 파일 맨 위에 삽입(없으면 생성, 재호출 중복 가드). 세션 수기 작성 불요.
+- **flows/문서 커밋** (미등록 케이스) — 워크트리 안 `.project/flows/` + task 문서 + changelog.
 - **추적 마커 빈커밋** — 부모 브랜치보다 앞선 커밋이 0개(코드 0·`.project` gitignore인 docs/분석 task)면 채번 보존용 1개.
 
-반환 JSON `{ prepped, branch, parent, wtPath, registered, commits, aheadOfParent, multiPhase?, autoAssigned? }`. **`parent`(= task 헤더에 기록된 부모 브랜치, 예 `dev` / `dev_feat_x`)가 이후 Step 4·5의 rebase·머지 대상이다** — 아래 명령의 `$PARENT`로 사용. (task-init이 fork 시점 현재 브랜치를 헤더에 기록해뒀다.)
+반환 JSON `{ prepped, branch, parent, wtPath, registered, commits, aheadOfParent, changelog, multiPhase?, autoAssigned? }`. **`parent`(= task 헤더에 기록된 부모 브랜치, 예 `dev` / `dev_feat_x`)가 이후 Step 4·5의 rebase·머지 대상이다** — 아래 명령의 `$PARENT`로 사용. (task-init이 fork 시점 현재 브랜치를 헤더에 기록해뒀다.)
 
 - **`multiPhase` / `autoAssigned`가 있으면 Step 8 보고에 그대로 옮긴다** — 코드가 자동 편입한 파일과 그 근거(어느 Phase로 갔는지)를 사용자가 볼 수 있어야 한다. 재배치 목적의 수동 커밋 재작업은 하지 않는다(GIT_RULE: 중간 커밋 독립 빌드 비보장).
 
 **콜백 (반환 `blocked` 필드 / npx는 특수 exit — 메인이 LLM 판단 후 처리):**
 - **`blocked:'mapping'`** (npx exit 2 — `{files, phases, reason}`): Dev Plan `- 파일:` 필드가 변경 파일을 못 덮음(**미매핑 — 빌드 산출물이 아닌 일반 파일 한정**. 다중 Phase 파일·산출물은 위 폴백으로 자동 처리돼 여기 오지 않는다). → 메인이 Dev Plan + `git -C "$WT_PATH" diff --name-only` 정독 후 **코드 변경분을 Phase별로 수동 커밋**(GIT_RULE 형식, 위 태그) → `task_close` 도구(또는 `npx ... close`) **재호출**. 코드가 이미 커밋돼 있으므로 close가 status=closed + 문서 커밋 + 마커를 자동 완료한다.
+- **`blocked:'docs'`** (npx exit 4 — `{missing:[{kind:'plan'|'history', file}...]}`): PLAN 체크리스트 또는 수정 이력에 `TASK-NNN` 표기 누락. → missing 목록의 문서를 채운 후(Step 2.5 항목 1·4 형식) `task_close` 도구(또는 `npx ... close`) **그대로 재호출** — 게이트는 모든 변이 앞이라 코드·상태 아무것도 안 바뀌었다.
 - **`blocked:'status'`** (npx exit 3 — `{current}`): status가 `tested`가 아님. Step 1~2 통과했다면 발생 X. 발생 시 사용자 보고 + 중단.
 
 > **close 후 task 문서 수정 금지** — close가 status=`closed`로 잠갔다(`closed-immutable.sh` hook 차단). 이후 Step 4 충돌 해결 내역은 *task 문서가 아니라 rebase/머지 커밋 메시지*에 기록한다.
@@ -231,9 +234,16 @@ git -C "$MAIN_WT" merge --no-ff "$BRANCH"
 - 사용자 부정 반응 발화 누적
 - **충돌 해결에서 *판단 불가 (4-c)* 1회 이상** — 멀티세션 자료 한계 신호
 
-분기:
-- 감지 신호 있음 → *"이번 task에서 X 부분이 마찰이었어 보여 — `/log-friction`으로 등록할까?"* OK 시 자동 발동.
-- 없음 → prompt X.
+분기 — **감지했으면 성격부터 가른다** (`TASKERY_RULE` §9):
+
+| 성격 | 판단 기준 | 제안 |
+|------|----------|------|
+| **taskery 자체의 결함** | 모든 리포에서 똑같이 발생할 문제 (스킬 지시 모순 / CLI 반환값이 문서와 다름 / 절차 자체의 빈틈) | *"이번 task에서 X 부분이 마찰이었어 보여 — `/log-friction`으로 등록할까?"* OK 시 자동 발동 |
+| **이 리포의 특성** | 이 프로젝트에서만 해당하는 방식·관행 (테스트 범위·실행 방법·빌드 전제·명명 관행) | *"이걸 이 리포 규칙(`<문서>.local.md`)으로 등록할까?"* **OK 받은 후에만** 해당 `.local.md`를 생성·추가한다. 문안은 사용자와 확정한 내용으로 적는다 |
+
+- 둘 다 해당하면 **둘 다 제안**한다.
+- 신호 없음 → prompt X.
+- 로컬 룰 등록은 **반드시 질문 후 승인**을 거친다 — 임의 생성 금지.
 
 ### Step 7 — 워크트리 / 브랜치 정리 (비가역 — git-guard 면제 조항)
 
@@ -271,8 +281,8 @@ git -C "$MAIN_WT" worktree remove "$WT_PATH"
 ✅ TASK-<NNN> closed
 - 작업 브랜치: <BRANCH> (삭제 / 보존)
 - 워크트리: <WT_PATH> (제거 / 보존)
-- 커밋: Phase <N>개 + 태스크 문서 + (CHANGELOG)
-- 문서 갱신: <Step 2.5 점검 6항 중 실제 갱신한 것 — 예: PLAN.md 체크리스트 [x] / changelog 2026-08 신규 / ARCHITECTURE 수정이력 1행. 없으면 "해당 없음">
+- 커밋: Phase <N>개 + 태스크 문서 + CHANGELOG(close 자동 append — 반환 `changelog`의 file·added|skipped)
+- 문서 갱신: <Step 2.5 점검 6항 중 실제 갱신한 것 + 문서 게이트(PLAN·수정이력) 통과 명시. 없으면 "해당 없음">
 - 자동 편입: <multiPhase / autoAssigned 있을 때만 — 예: `src/ipc.ts` Phase 2·5 → Phase 2 / `project.pbxproj` → Phase 3(빌드 산출물)>
 - 부모 브랜치 병합: <PARENT> ← --no-ff 완료 ($MERGE_COMMIT)
 - 충돌 해결: <건수, 자료 한계 보고 있으면 포함>
@@ -282,9 +292,9 @@ git -C "$MAIN_WT" worktree remove "$WT_PATH"
 
 ## 도구 가이드
 
-- **Read**: GIT_RULE / task 파일 / CLAUDE.md 검증 명령 정독 / `task_close` 반환 JSON
+- **Read**: GIT_RULE / task 파일 / AGENTS.md 검증 명령 정독 / `task_close` 반환 JSON
 - **Bash / 도구**: `task_close` 도구(또는 `npx @angar2/taskery close TASK-NNN`) 결정적 준비 + git 명령 (`rebase`, `merge`, `worktree`, `branch`) + 검증 명령 재실행. **유일하게 git 사용 허가된 스킬**
-- **Edit / Write**: (매핑 콜백 시) 수동 Phase 커밋용 staging / CHANGELOG 내용 (close가 커밋). **close 후 task 문서는 closed라 수정 X**
+- **Edit / Write**: (매핑·docs 콜백 시) 수동 Phase 커밋용 staging / PLAN·수정이력 보완 / (선택) CHANGELOG 요약 보강 — 본문은 close가 자동 append. **close 후 task 문서는 closed라 수정 X**
 - **bin/lib.js**: `withMergeLock` (머지 락 — Step 5)
 
 ## 주의사항

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

@@ -9,11 +9,11 @@ description: task 구현 — Dev Plan Phase 순서대로 코드 작성 + self-ch
 
 `planned` 상태 task의 Dev Plan을 Phase 순서대로 구현. 각 Phase 완료 시 체크박스 갱신 + Result 섹션에 진행 기록. 모든 Phase 완료 + self-check (린트/타입/빌드/단위테스트) PASS 시 status를 `developed`로 갱신.
 
-self-check 명령은 프로젝트 루트 `CLAUDE.md`의 *검증 명령* 섹션 참조 — 단일 진실 소스.
+self-check 명령은 진입 문서 `AGENTS.md`의 *검증 명령* 섹션 참조 — 단일 진실 소스.
 
 ## 멀티세션 메타 위치 (0.1.2+)
 
-본 스킬은 워크트리에서 호출되는 게 default (멀티세션 — 각 워크트리 = 독립 세션). 다만 호출 위치 자유 — 메인 cwd / 서브 세션 호출 등 다른 운영 모델에서도 cwd 무관 동작. 메타(`.project/`, `CLAUDE.md`) 접근 시 **메인 워크트리 절대 경로** 우선.
+본 스킬은 워크트리에서 호출되는 게 default (멀티세션 — 각 워크트리 = 독립 세션). 다만 호출 위치 자유 — 메인 cwd / 서브 세션 호출 등 다른 운영 모델에서도 cwd 무관 동작. 메타(`.project/`, `AGENTS.md`) 접근 시 **메인 워크트리 절대 경로** 우선.
 
 ```sh
 MAIN_WT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")
@@ -21,10 +21,10 @@ MAIN_WT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")
 
 `.gitignore` 케이스 분기:
 
-| 케이스 | task 문서 / Result 갱신 위치 | CLAUDE.md (검증 명령) |
+| 케이스 | task 문서 / Result 갱신 위치 | AGENTS.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는 단일 소스) |
+| 등록 (`.project/`가 `.gitignore`에 있음) | `$MAIN_WT/.project/tasks/<NNN_slug>/...` (`bin/lib.js` `withMetaLock`) | `$MAIN_WT/AGENTS.md` |
+| 미등록 (**기본 설치값** — `fork`/`status` 반환의 `registered:false`) | `$WT_PATH/.project/tasks/<NNN_slug>/...` (워크트리 안, 머지 시 dev 반영) | `$MAIN_WT/AGENTS.md` (AGENTS.md는 단일 소스) |
 
 self-check 명령은 워크트리(`$WT_PATH`)에서 실행 — 코드 변경이 워크트리 안에 있으므로 검증 대상도 거기.
 
@@ -47,19 +47,20 @@ self-check 명령은 워크트리(`$WT_PATH`)에서 실행 — 코드 변경이
 
 ### Step 1 — task 파일 + 검증 명령 확인
 
-1. `.project/AGENT-GUIDE.md` Read → 활성 plan 버전 확인.
+1. `status` 도구(또는 `npx @angar2/taskery status`)로 활성 plan 확인.
 2. task 파일 Read:
    - 인자 있음 → 해당 파일.
-   - 인자 없음 → `ls .project/tasks/<NNN_slug>/` 결과 중 status=`planned` 또는 `developing`인 가장 최근 파일. 발견 시 *"TASK-<NNN> 진행할까요?"* confirm. 없으면 *"진행할 task 없음. `/task-plan` 먼저 호출."* + 종료.
+   - 인자 없음 → `status` 도구(또는 `npx @angar2/taskery status`)의 *진행중 태스크* 목록에서 후보를 찾는다 — task 문서는 미등록 케이스에서 **각 task의 워크트리 안에만** 있으므로, 메인 워크트리에서 `ls .project/tasks/<NNN_slug>/`로 찾으면 아무것도 안 나와 *"task가 없다"*고 잘못 끝난다. 각 후보의 문서 경로는 `status`가 알려주는 워크트리 경로 아래 `.project/tasks/<NNN_slug>/`다. 그중 status=`planned` 또는 `developing`인 가장 최근 task. 발견 시 *"TASK-<NNN> 진행할까요?"* confirm. 진행중 목록 자체가 비어 있을 때만 *"진행할 task 없음. `/task-plan` 먼저 호출."* + 종료.
 3. 상태 검증:
    - `planned` → 신규 진행 (Step 2 status 전환).
    - `developing` → 이어가기 (Step 2 skip — 이미 developing).
    - 그 외 → 종료 + 안내.
-4. 프로젝트 루트 `CLAUDE.md` Read → 두 섹션 명령 추출:
+4. 진입 문서 `AGENTS.md` Read → 두 섹션 명령 추출:
    - **`## 검증 명령`** (코드 상태 — 빌드/린트/타입체크): self-check 게이트의 단일 진실 소스 (Step 6).
    - **`## 테스트 명령`** (테스트 실행 — 단위/통합/E2E): 구현 후 테스트 실행의 단일 진실 소스 (Step 6.5).
    - stash FRICTION_LOG #25 반영 — 두 섹션 분리. self-check 게이트는 *코드 상태*만, 테스트는 *별도 단계*.
-5. **프로젝트 로컬 룰 확인** — `$MAIN_WT/.project/rules/DEV_RULE.local.md`(구현 정책)와 `$MAIN_WT/.project/rules/TEST_RULE.local.md`(테스트 범위·방식 정책)를 각각 있으면 Read한다 (없으면 넘어간다. `npx update` 미터치 영역이라 프로젝트가 자유롭게 소유한다). 본 스킬 조항과 겹치는 항목은 **로컬 룰을 우선 적용**한다 — 프로젝트마다 구현·테스트 실행 방식이 다르므로 본 스킬 조항은 *안전한 기본값*이다. **Step 6.5의 테스트 실행 범위·신설 상한은 `TEST_RULE.local.md`가 있으면 그 규정을 따른다** (본 스킬이 테스트를 실제로 실행하는 주체이므로, 그 파일을 읽지 않으면 프로젝트 고유 규칙이 무력해진다).
+   - **미기입 가드**: 값이 `<예:` 로 시작하는 placeholder이거나 비어 있으면 **그 명령을 실행하지 않는다.** 이 리포는 진입 문서가 아직 안 채워진 상태이므로 *"`AGENTS.md`의 `## 검증 명령`이 비어 있다. `/project-init`으로 채운 뒤 다시 부르거나, 지금 값을 알려달라"*고 사용자에게 알리고 **중단**한다. placeholder를 명령으로 착각해 실행하면 매번 실패하며 원인을 엉뚱한 데서 찾게 된다.
+5. **프로젝트 로컬 룰 확인** — `$MAIN_WT/.project/rules/DEV_RULE.local.md`(구현 정책)와 `$MAIN_WT/.project/rules/TEST_RULE.local.md`(테스트 범위·방식 정책)를 각각 Read한다. 둘 다 모든 리포에 있어야 하는 필수 문서이며(`TASKERY_RULE` §8), **없으면 사용자에게 알리고** 본 스킬의 기본값으로 진행한다 (`npx update` 미터치 영역이라 프로젝트가 자유롭게 소유한다). 본 스킬 조항과 겹치는 항목은 **로컬 룰을 우선 적용**한다 — 프로젝트마다 구현·테스트 실행 방식이 다르므로 본 스킬 조항은 *안전한 기본값*이다. **Step 6.5의 테스트 실행 범위·신설 상한은 `TEST_RULE.local.md`가 있으면 그 규정을 따른다** (본 스킬이 테스트를 실제로 실행하는 주체이므로, 그 파일을 읽지 않으면 프로젝트 고유 규칙이 무력해진다).
    - **로컬 룰이 뒤집을 수 없는 것** (충돌 시 코어 우선): 멀티세션 불변식(머지 락 · 메인 워크트리 테스트 금지 · git 명령은 `/task-close`만) · destructive 명령 사용자 승인 · 상태 전이 유효성.
 
 ### Step 2 — status 전환 (planned → developing)
@@ -100,7 +101,7 @@ Dev Plan에 Phase 0(제품 관통 문서 변경)이 있으면:
 
 ### Step 6 — self-check 게이트 (`## 검증 명령` — 코드 상태)
 
-`CLAUDE.md` `## 검증 명령` 섹션의 명령을 *전부* 실행. 모두 PASS여야 다음 단계 (Step 6.5 테스트 실행) 진입 가능. 테스트 명령은 본 게이트에서 실행 X.
+`AGENTS.md` `## 검증 명령` 섹션의 명령을 *전부* 실행. 모두 PASS여야 다음 단계 (Step 6.5 테스트 실행) 진입 가능. 테스트 명령은 본 게이트에서 실행 X.
 
 | 명령 | PASS 기준 |
 |------|---------|
@@ -120,7 +121,7 @@ Dev Plan에 Phase 0(제품 관통 문서 변경)이 있으면:
 
 stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서 단일 시점 실행 (task-close / hook 영역 중복 제거).
 
-`CLAUDE.md` `## 테스트 명령` 섹션의 명령을 *전부* 실행. 모두 PASS여야 `developed`로 전이 가능. **본 게이트는 *구현 완료 시점 1회*다** — 아래 "수정 루프 국면"에 해당하는 동안에는 매 사이클 전부 실행하지 않는다. 또한 수정 루프 국면을 거친 뒤 곧바로 `/task-test`로 이어가는 경우에는 국면 ⑥에 따라 본 게이트의 전체 실행을 생략하고 *격리 세션의 실행*으로 갈음한다 (그때의 `developed` 전이 근거 = 린트·타입체크 PASS + 변경이 닿는 테스트 PASS이며, 전체 스위트는 격리 세션이 책임진다).
+`AGENTS.md` `## 테스트 명령` 섹션의 명령을 *전부* 실행. 모두 PASS여야 `developed`로 전이 가능. **본 게이트는 *구현 완료 시점 1회*다** — 아래 "수정 루프 국면"에 해당하는 동안에는 매 사이클 전부 실행하지 않는다. 또한 수정 루프 국면을 거친 뒤 곧바로 `/task-test`로 이어가는 경우에는 국면 ⑥에 따라 본 게이트의 전체 실행을 생략하고 *격리 세션의 실행*으로 갈음한다 (그때의 `developed` 전이 근거 = 린트·타입체크 PASS + 변경이 닿는 테스트 PASS이며, 전체 스위트는 격리 세션이 책임진다).
 
 | 명령 | PASS 기준 |
 |------|---------|
@@ -142,13 +143,13 @@ stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서
 
 | 상황 | 실행 방식 |
 |------|----------|
-| `TEST-GUIDE.md` *테스트 실행 환경* 절에 **격리 실행 경로**(창 숨김·헤드리스 플래그 / 컨테이너·가상 디스플레이 / VM / CI 러너) 선언됨 | 그 경로로 **자동 실행 OK** |
+| `TEST_RULE.local.md` *테스트 실행 환경* 절에 **격리 실행 경로**(창 숨김·헤드리스 플래그 / 컨테이너·가상 디스플레이 / VM / CI 러너) 선언됨 | 그 경로로 **자동 실행 OK** |
 | 격리 경로 없음 + 비점유 부분만 한정 실행 가능 (번들·프로젝트·태그 지정 등) | **비점유 부분만 자동 실행**, 점유 스위트는 제외 |
 | 격리 경로 없음 + 한정 수단도 없음 | **자동 실행 금지** — 사용자에게 *무엇을 왜 돌려야 하고 얼마나 걸리며 그동안 화면·입력을 못 쓴다*를 예고하고 승인을 받은 뒤에만 실행 |
 
 - 헤드리스 모드가 존재하면 항상 그쪽을 쓴다.
 - 본 task가 UI를 건드리지 않는데(순수 로직·CLI 등) 테스트 명령이 UI 스위트를 포함하면, 그 스위트는 실행 대상이 아니다.
-- 격리 실행 경로를 새로 확인했으면 `TEST-GUIDE.md` *테스트 실행 환경* 절에 기록해 다음 task가 재사용하게 한다.
+- 격리 실행 경로를 새로 확인했으면 `TEST_RULE.local.md` *테스트 실행 환경* 절에 기록해 다음 task가 재사용하게 한다.
 
 **수정 루프 국면 — 재실행 범위 비례 (recordion FRICTION 2026-08-08 반영)**:
 
@@ -156,7 +157,7 @@ stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서
 
 1. **매 사이클 실행** — 린트·타입체크(수 초) + *변경한 파일이 닿는 테스트* + 그 테스트가 쓰는 공유 헬퍼를 함께 쓰는 테스트. 대개 1~2개·수십 초다.
 2. **전체 게이트(Step 6 + Step 6.5)는 국면이 끝날 때 1회** — 국면 도중에는 돌리지 않는다. 풀빌드를 포함한 Step 6도 매 사이클 대상이 아니다. (국면이 끝나는 시점에 *실제로 돌릴지*는 아래 ⑥이 정한다 — 바로 `/task-test`로 이어가면 격리 세션의 실행으로 갈음한다.)
-3. **테스트 러너가 빌드를 포함하지 않으면 빌드를 선행**한다 — 옛 산출물로 돌면 이미 고친 결함이 남아 있는 것처럼 보여 없는 버그를 쫓게 된다 (recordion에서 이 때문에 30분을 소모했다). 어느 명령이 빌드를 포함하는지는 `TEST-GUIDE.md`에 기록해 재사용한다.
+3. **테스트 러너가 빌드를 포함하지 않으면 빌드를 선행**한다 — 옛 산출물로 돌면 이미 고친 결함이 남아 있는 것처럼 보여 없는 버그를 쫓게 된다 (recordion에서 이 때문에 30분을 소모했다). 어느 명령이 빌드를 포함하는지는 `TEST_RULE.local.md`에 기록해 재사용한다.
 4. **무관한 테스트가 깨질 때만 범위를 넓힌다** — 예상 밖 실패가 나오면 그때 상위 범위로 확대한다.
 5. **회귀 누락 위험은 2 + `/task-test` 격리 세션의 이중 게이트가 막는다.** 좁힌 범위 때문에 회귀를 놓친다는 우려로 매 사이클 전체를 도는 것은 비용 대비 효과가 없다.
 6. **`/task-test`로 바로 이어갈 때는 2의 전체 1회를 생략한다** — 격리 세션이 `## 검증 명령`·`## 테스트 명령`을 다시 전부 실행하므로 같은 스위트를 연달아 두 번 돌리는 셈이 된다. 세션이 `developed`에서 멈추고 사용자에게 제어를 넘길 때만 메인이 전체를 1회 실행한다. (결과: 전체 스위트는 태스크당 원칙 1회.)
@@ -200,7 +201,7 @@ stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서
 
 ### Step 9 — 검수 서버 기동 (중단점·해당 시)
 
-**조건**: ① 이번 세션이 여기서 멈추고 사용자에게 제어를 넘김(= `/task-test`로 계속 진행하지 않음) + ② `CLAUDE.md`(코덱스 `AGENTS.md`)에 `## 검수 실행 명령`이 선언됨.
+**조건**: ① 이번 세션이 여기서 멈추고 사용자에게 제어를 넘김(= `/task-test`로 계속 진행하지 않음) + ② `AGENTS.md`에 `## 검수 실행 명령`이 선언됨.
 
 - 두 조건 충족 시 — 그 명령으로 서버를 *백그라운드* 기동(포트 = 기준 포트 + TASK번호) + 접속 URL 보고. 모바일 검수가 필요하다고 판단되면 터널도 기동.
 - `/task-test`로 계속 진행하면 본 단계 생략 (마지막 단계에서만 기동 — 상세: GIT_RULE "멀티세션 검수 환경").
@@ -209,7 +210,7 @@ stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서
 
 ## 도구 가이드
 
-- **Read**: task 파일 / `CLAUDE.md` 검증 명령 / 관련 코드 정독
+- **Read**: task 파일 / `AGENTS.md` 검증 명령 / 관련 코드 정독
 - **Edit / Write**: 코드 작성 + Phase 체크박스 갱신 + Result 섹션 갱신
 - **Bash / 도구**: 검증 명령 실행 (린트/타입/빌드/단위테스트) / `set_status` 도구(또는 `npx @angar2/taskery set-status`) status 전이. **git 명령 절대 X — `/task-close`만 git 담당**
 - **Grep / Glob**: 추가 코드 탐색 (Phase 진행 중 인접 영향 발견 시)

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

@@ -1,6 +1,6 @@
 ---
 name: task-init
-description: task 시작 — 워크트리 분기 + 6 섹션 빈 골격 + 헤더 6컬럼 (부모 브랜치 자동 기록 · status=draft) task.md 생성 (멀티세션 0.1.2+)
+description: task 시작 — 워크트리 분기 + 빈 골격(헤더 6컬럼 + 본문 5 섹션) (부모 브랜치 자동 기록 · status=draft) task.md 생성 (멀티세션 0.1.2+)
 ---
 
 # /task-init
@@ -23,7 +23,7 @@ description: task 시작 — 워크트리 분기 + 6 섹션 빈 골격 + 헤더
 직전 대화 정독 → 추정 가능하면 분기 1(제안), 불가하면 분기 2(인터뷰):
 - Q1 *"무슨 작업? (한 줄로)"* / Q2 *"유형? (feature / bug / improvement / refactor / docs / chore)"* / Q3 *"출처? (백로그 BL-NNN / 로드맵 Stage ST-N / 직접 요구사항 DR)"* / Q4 *"규모? (micro / small / medium / large)"* / (필요 시) Q5 *"plan `<NNN_slug>` 맞나요?"*
 
-수집 항목(모두 확정 후 진행): 주제(한국어) · 유형 · 출처 · 규모 · plan(활성 plan — `status` 도구나 AGENT-GUIDE에서). 활성 plan 부재 시 *"`/plan-init` 먼저 실행할까요?"* 안내 + 중단.
+수집 항목(모두 확정 후 진행): 주제(한국어) · 유형 · 출처 · 규모 · plan(활성 plan — `status` 도구에서). 활성 plan 부재 시 *"`/plan-init` 먼저 실행할까요?"* 안내 + 중단.
 
 ## Step 2 — 출처별 메타 + 슬러그
 
@@ -49,7 +49,7 @@ description: task 시작 — 워크트리 분기 + 6 섹션 빈 골격 + 헤더
 
 ## Step 5 — 골격 확인 + 보고
 
-반환 `docPath`(절대 경로)를 Read해 헤더 6컬럼 + 6 섹션 placeholder + status=draft 확인만 한다. **본문 작성 금지** — Requirements / Scope / Dev Plan / Test Plan은 *반드시* `/task-plan`에서.
+반환 `docPath`(절대 경로)를 Read해 헤더 6컬럼 + 본문 5 섹션(Requirements / Scope / Dev Plan / Test Plan / Result) placeholder + status=draft 확인만 한다. (`TASK_DOC_RULE`이 말하는 "6 섹션"은 헤더 표를 1개로 세는 표기다.) **본문 작성 금지** — Requirements / Scope / Dev Plan / Test Plan은 *반드시* `/task-plan`에서.
 
 > **폴백** (반환에 `docPath` 없이 `scaffoldError`만 있을 때만): TASK_DOC_RULE §1.3 형식으로 해당 위치에 직접 작성(생성일=오늘, status=draft, 단일=`<NNN>_<slug>.md` / 폴더=`TASK-<NNN>_<slug>/task.md`).