@angar2/taskery 0.4.0 → 0.6.0

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

@@ -7,67 +7,37 @@ description: plan(기능 그룹) 생성 — NNN 채번 폴더 + PLAN.md/ROADMAP.
 
 ## 개요
 
-plan(기능 그룹)마다 호출. **plan = 작업을 묶는 기능 그룹 단위** — 제품 전체 스냅샷(버전)이 아니다. 규모는 가변: 기능 그룹 하나가 보편이나, 첫 plan(MVP처럼 여러 기능 그룹을 묶은 큰 plan)도 같은 흐름으로 처리한다(특례 없음).
+plan(기능 그룹)마다 호출. **plan = 작업을 묶는 기능 그룹 단위** — 제품 전체 스냅샷(버전)이 아니다. 규모 가변(기능 그룹 하나가 보편, 첫 plan=MVP처럼 여러 그룹 묶음도 같은 흐름, 특례 없음).
 
 본 스킬이 만드는 것:
-- **plan 로컬(그룹 C)** — `.project/plans/<NNN_slug>/`에 `PLAN.md` + `ROADMAP.md` 생성.
+- **plan 로컬(그룹 C)** — `.project/plans/<NNN_slug>/`에 `PLAN.md` + `ROADMAP.md`.
 - **제품 관통 문서(그룹 B) delta — 의도 레벨만** — `.project/FEATURES.md` / `.project/UX-UI.md`에 이 기능 그룹의 *섹션 헤더 + 의도 스텁* append.
 
-본 스킬이 만들지 *않는* 것:
-- **제품 관통 문서 전체 생성** — SERVICE-POLICY/TECH-STACK/ARCHITECTURE/DATA-MODEL/API-SPEC/FEATURES/UX-UI 7종은 `/project-init`이 루트에 작성/골격화 완료. plan-init은 부수적 add/mod만.
-- **DATA-MODEL/API-SPEC 상세 본문** — 스키마·엔드포인트는 *선기획 금지*. 구현 동반으로 task 진행(`/task-plan` Phase 0 / `/task-dev`)이 채운다. plan-init은 빈 섹션 헤더만 둘 수 있다.
+만들지 *않는* 것:
+- **제품 관통 문서 전체 생성** — 7종(SERVICE-POLICY/TECH-STACK/ARCHITECTURE/DATA-MODEL/API-SPEC/FEATURES/UX-UI)은 `/project-init` 영역. plan-init은 부수적 add/mod만.
+- **DATA-MODEL/API-SPEC 상세 본문** — 스키마·엔드포인트 *선기획 금지*. 구현 동반으로 task(`/task-plan` Phase 0 / `/task-dev`)가 채운다. plan-init은 빈 섹션 헤더만 둘 수 있다.
 
-> plan 폴더명은 `NNN_<slug>` 형식(3자리 채번 + 기능 그룹 slug). 예: `001_mvp`, `002_compare-products`. tasks 폴더도 동일명.
+## 호출 시점 + 입력
 
-## 호출 시점
+- `/project-init` 직후 첫 plan(보통 MVP) 또는 새 기능 그룹 착수 시.
+- 인자 = plan slug (예: `/plan-init compare-products`). 없으면 *"어느 기능 그룹? slug 알려줘 (예: mvp, compare-products)"*. 한국어면 영어 *의미 변환* → kebab-case(공백 불가, 3 단어 이내).
+- **자투리는 plan 없이** — 단발 버그·오타·의존성 업데이트는 plan-init 없이 `/task-init`로 바로(무소속). 전역 TASK-NNN이 순서 보장.
 
-- `/project-init` 직후 첫 plan(보통 MVP) 생성 시.
-- 새 기능 그룹(예: `compare-products` 다음 `auth-system`) 착수 시.
+## 생성 (CLI — 채번+폴더+골격+AGENT-GUIDE)
 
-> **자투리는 plan 없이** — 급한 버그·오타·의존성 업데이트 같은 단발 작업은 어느 기능 그룹에도 안 묶인다. plan-init 호출 없이 `/task-init`로 바로 진행(무소속). 전역 TASK-NNN이 순서를 보장하므로 소속과 무관하다.
+`plan_init` 도구로 생성한다 (MCP 도구 `plan_init` 또는 동일 `npx @angar2/taskery plan-init <slug>`). 한 번으로 코드가 원자 수행: **NNN 채번**(3자리, 최대+1) · **폴더**(`plans/<NNN_slug>/` + `tasks/<NNN_slug>/{spec-diffs,screenshots,mockup}/`) · **골격 Write**(ROADMAP/PLAN/BACKLOG, 아래 형식 placeholder) · **AGENT-GUIDE `## 활성 plan 버전` 갱신**. 성공 반환 `{ plan, nnn, planDir, tasksDir }` — 이후 단계는 이 `plan`(=`<NNN_slug>`) 사용. PROJECT.md/AGENT-GUIDE 부재 시 에러 → *"`/project-init` 먼저 호출 필요"* 안내 후 중단.
 
-## 입력 처리
+**legacy 게이트** — `plans/`에 NNN 채번 아닌 폴더(구버전 `v1.0`/`alpha` 등) 잔존 시 `{gated:true, legacyDirs}`로 멈춘다(폴더 생성 X). 사용자 호출 + 경고: *"`plans/`에 NNN 채번 아닌 폴더(<legacyDirs>)가 있어. 새 plan을 NNN로 채번하면 활성 plan이 갈려 원래 문제 재발. 수동 이전(문서 루트 이동 + `NNN_slug` 리네임 + AGENT-GUIDE 갱신) 후 진행할지, 그래도 진행할지 결정해줘."* → 강행 시 `force:true`(CLI는 `--force`)로 재호출.
 
-인자 = plan slug (예: `/plan-init compare-products`). 인자 없으면 사용자에게 *"어느 plan(기능 그룹)? slug 알려줘 (예: mvp, compare-products)"* 질문. 형식: 한국어면 영어 *의미 변환* → kebab-case(공백 불가, 3 단어 이내 권장).
+> 폴더 생성·`tasks/<NNN_slug>/`·AGENT-GUIDE 갱신은 코드가 완료 — 아래는 골격 placeholder를 *내용으로 채우는* 단계(LLM 판단)다.
 
-## 단계
+## ROADMAP.md 내용 채우기
 
-### Step 1 — 사전 검증 + 메인 워크트리 검출
-
-1. **메인 워크트리 검출**:
-   ```sh
-   MAIN_WT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")
-   ```
-2. 메인 워크트리 dev 체크아웃 검증 — 위배 시 사용자 호출 + 중단.
-3. `$MAIN_WT/.project/PROJECT.md` 존재 확인 — 없으면 *"`/project-init` 먼저 호출 필요"* + 중단.
-
-### Step 2 — plan slug 확정 + NNN 채번 + legacy 게이트
-
-1. slug 확정 (인자 또는 사용자 질문 — 위 입력 처리).
-2. **다음 plan 번호 + legacy 검출** — `bin/lib.js`의 `computeNextPlanNumber(MAIN_WT)` 호출:
-   ```js
-   const lib = require('@angar2/taskery/bin/lib');
-   const { next, legacyDirs } = lib.computeNextPlanNumber(MAIN_WT);
-   // next = '001'/'002'/... (3자리 zero-pad), legacyDirs = NNN_ 패턴 아닌 기존 폴더 목록
-   ```
-   bash 등가(참고):
-   ```sh
-   ls -1 "$MAIN_WT/.project/plans" 2>/dev/null | grep -E '^[0-9]{3}_' \
-     | sed -E 's/^([0-9]{3})_.*/\1/' | sort -n | tail -1
-   ```
-3. **legacy 게이트** — `legacyDirs`가 비어 있지 않으면(예: 구버전 `v1.0`, `alpha` 폴더 잔존):
-   - 즉시 사용자 호출 + 경고: *"`plans/`에 NNN 채번이 아닌 폴더(<legacyDirs>)가 있어. 새 plan을 NNN로 채번하면 활성 plan이 갈려 원래 문제가 재발해. 먼저 수동 이전(문서 루트 이동 + 폴더 `NNN_slug` 리네임 + AGENT-GUIDE 활성 plan 갱신)을 끝낸 뒤 진행할지, 그래도 진행할지 결정해줘."*
-   - 사용자 명시 confirm 전 폴더 생성 금지.
-4. plan 폴더명 = `${next}_${slug}` (예: `001_mvp`).
-
-### Step 3 — plan 폴더 생성 + ROADMAP.md 작성
-
-1. `$MAIN_WT/.project/plans/<NNN_slug>/` 디렉토리 생성.
-2. **ROADMAP.md** 작성 — *현재 plan(기능 그룹) 한정* task 단계 로드맵. *ROADMAP 작성 4룰*:
-   1. ROADMAP은 *현재 plan 한정* — 다른 기능 그룹 후보는 글로벌 `.project/BACKLOG.md`. 프로젝트 전체 거시 빌드 순서는 `PROJECT.md ## 초기 빌드 로드맵`(별개).
-   2. 진행 순서에 task 번호(TASK-NNN) 강제 금지 — *Stage(영역) 단위*로만 명시 (예측 불가 task 합류 시 번호 어긋남 방지).
-   3. Stage 안 *작업 단위 명시* 필요 (한 task 분량 권장 — 다음 task 진행 시 메인 세션이 ROADMAP 보고 작업 범위 판단 가능).
-   4. 작업 단위에 task 번호 컬럼 추가 X / *상태 컬럼만* (⏳ 대기 / 🔧 진행 중 / ✅ 완료 / ❌ 폐기) — Living document.
+*현재 plan 한정* task 단계를 placeholder에 채운다. *ROADMAP 작성 4룰*:
+1. *현재 plan 한정* — 다른 기능 그룹 후보는 글로벌 `.project/BACKLOG.md`. 프로젝트 전체 거시 빌드 순서는 `PROJECT.md ## 초기 빌드 로드맵`(별개).
+2. 진행 순서에 task 번호(TASK-NNN) 강제 금지 — *Stage(영역) 단위*로만 (task 합류 시 번호 어긋남 방지).
+3. Stage 안 *작업 단위 명시*(한 task 분량 권장 — 다음 task 진행 시 메인이 ROADMAP 보고 범위 판단).
+4. 작업 단위에 task 번호 컬럼 X / *상태 컬럼만*(⏳ 대기 / 🔧 진행 중 / ✅ 완료 / ❌ 폐기) — Living document.
 
 ```markdown
 # ROADMAP — <NNN_slug>
@@ -81,13 +51,13 @@ plan(기능 그룹)마다 호출. **plan = 작업을 묶는 기능 그룹 단위
 | <한 task 분량 작업> | ⏳ 대기 |
 ```
 
-### Step 4 — PLAN.md 작성 (얇은 인덱스 — 하드룰)
+## PLAN.md 내용 채우기 (얇은 인덱스 — 하드룰)
 
-PLAN.md는 *얇은 인덱스*다. 이 기능 그룹이 건드린 루트 문서 요약 + task 체크리스트만 둔다.
+PLAN.md는 *얇은 인덱스*다 — 이 기능 그룹이 건드린 루트 문서 요약 + task 체크리스트만.
 
 **하드룰 (중복 차단):**
-- **각 항목 = 루트 문서 섹션 *링크 1줄*. 본문 복제 금지.** 기능 상세는 `.project/` 루트 문서에만 존재(단일 홈).
-- `## 활성 task 버전` 류 *자기선언 라인 작성 금지* — 활성 plan의 단일 진실은 `AGENT-GUIDE.md`뿐. plan 로컬이 중복 선언하지 않는다.
+- **각 항목 = 루트 문서 섹션 *링크 1줄*. 본문 복제 금지.** 기능 상세는 `.project/` 루트 문서에만(단일 홈).
+- `## 활성 task 버전` 류 *자기선언 라인 작성 금지* — 활성 plan 단일 진실은 `AGENT-GUIDE.md`뿐.
 
 ```markdown
 # PLAN — <NNN_slug>
@@ -103,79 +73,34 @@ PLAN.md는 *얇은 인덱스*다. 이 기능 그룹이 건드린 루트 문서
 - [ ] <작업 단위> (ROADMAP Stage N)
 ```
 
-### Step 5 — 제품 관통 문서(그룹 B) 의도 레벨 delta
+## 제품 관통 문서(그룹 B) 의도 레벨 delta
 
-`.project/` 루트 제품 관통 문서에 이 기능 그룹의 *의도*를 명시한다. **의도 레벨만 — 상세 선작성 금지.**
+`.project/` 루트 문서에 이 기능 그룹의 *의도*를 명시한다. **의도 레벨만 — 상세 선작성 금지.**
 
-- **FEATURES.md / UX-UI.md (필수)**: 이 기능 그룹의 *섹션 헤더 + 의도 스텁* append. "이 기능이 무엇 / 어떤 화면" — 구현 전에도 선언 가능(그게 기능 그룹 기획의 본질). 섹션은 *기능/도메인 자기기술* — 어느 plan이 추가했는지 태그하지 않는다(기능 분류 = 제품 관통 문서 섹션 구조가 단일 진실).
+- **FEATURES.md / UX-UI.md (필수)**: 이 기능 그룹의 *섹션 헤더 + 의도 스텁* append. "무엇 / 어떤 화면" — 구현 전에도 선언 가능(기능 그룹 기획의 본질). 섹션은 *기능/도메인 자기기술* — 어느 plan이 추가했는지 태그 X(기능 분류 = 제품 관통 문서 섹션 구조가 단일 진실).
   ```markdown
   ## <기능 그룹 이름>
   <의도 1~3줄: 무엇을 / 누구를 위해 / 핵심 화면·동작. 상세 스펙은 task 진행에서.>
   ```
-- **DATA-MODEL.md / API-SPEC.md (선택 — 빈 헤더까지만)**: 이 그룹이 데이터/엔드포인트를 도입할 거면 *빈 섹션 헤더*만 둘 수 있다. **스키마·엔드포인트 본문 선작성 금지** — 구현 동반으로 `/task-plan` Phase 0 / `/task-dev`가 채운다(taskery anti-waterfall: TASK_DOC_RULE §1.4 / DEV_RULE §2 정합).
-
-타입 조건부: project-init이 만들지 않은 문서(예: frontend의 DATA-MODEL)는 delta도 없음.
+- **DATA-MODEL.md / API-SPEC.md (선택 — 빈 헤더까지만)**: 데이터/엔드포인트 도입 예정이면 *빈 섹션 헤더*만. **스키마·엔드포인트 본문 선작성 금지** — 구현 동반으로 `/task-plan` Phase 0 / `/task-dev`가 채운다(anti-waterfall: TASK_DOC_RULE §1.4 / DEV_RULE §2).
+- **그룹 A (SERVICE-POLICY/TECH-STACK/ARCHITECTURE)**: 이 그룹이 새 정책/스택/구조 도입 시만 수정. 도입 없으면 건너뜀.
 
-### Step 6 — 그룹 A 점검 (부수적 add/mod)
+타입 조건부: project-init이 안 만든 문서(예: frontend의 DATA-MODEL)는 delta도 없음.
 
-이 기능 그룹이 *새 정책 / 새 스택 / 새 구조*를 도입하면 해당 루트 문서(SERVICE-POLICY / TECH-STACK / ARCHITECTURE)를 수정한다. 도입 없으면 건너뜀. (그룹 A는 project-init이 작성한 정적 제품 관통 문서 — plan-init은 부수적 변경만.)
+## 결과 보고
 
-### Step 7 — `tasks/<NNN_slug>/` 디렉토리 준비
+작성 산출물 목록 + 다음 단계:
+- *"`<NNN_slug>/` plan 생성 완료 — PLAN/ROADMAP + FEATURES/UX-UI 의도 stub. AGENT-GUIDE 활성 plan `<NNN_slug>` 갱신. 다음은 `/task-init`으로 첫 task (스키마/엔드포인트 상세는 task 진행에서 구현 동반)."*
 
-1. `$MAIN_WT/.project/tasks/<NNN_slug>/` 디렉토리 생성 (빈 폴더).
-2. `tasks/<NNN_slug>/spec-diffs/`, `screenshots/`, `mockup/` 빈 폴더 미리 생성.
-3. `tasks/<NNN_slug>/BACKLOG.md` 빈 골격 Write — *plan(기능 그룹)별 task 후보 누적용*, 글로벌 `.project/BACKLOG.md`와 별개:
-
-```markdown
-# BACKLOG — <NNN_slug>
-
-> 본 파일은 *<NNN_slug> plan 진행 중 누적되는 후속 task 후보* 추적용.
-> 글로벌 `.project/BACKLOG.md` (다음 기능 그룹 후보 카탈로그) 와 별개.
-
-| 위치 | 영역 | 역할 |
-|------|------|------|
-| `.project/BACKLOG.md` (글로벌) | 다음 기능 그룹 후보 카탈로그 (다음 plan에서 검토) | Living document |
-| `.project/tasks/<NNN_slug>/BACKLOG.md` (본 파일) | 현재 plan 진행 중 누적된 후속 task 후보 | 한 plan 내 task close 직후 후보 누적 |
-
-## 후속 task 후보
-
-(사용자 발화 또는 task-close 직후 메인 감지로 한 행씩 추가. 빈 상태 default.)
-```
-
-빈 골격만 작성. 본문은 task 진행하면서 사용자 발화 또는 메인 감지로 누적.
-
-### Step 8 — `AGENT-GUIDE.md` 활성 plan 갱신
-
-`$MAIN_WT/.project/AGENT-GUIDE.md`의 `## 활성 plan 버전` 섹션 다음 줄을 `<NNN_slug>`로 갱신 (헤딩 텍스트 자체는 변경 X — lib.js/스킬이 의존). **반드시** — 누락 시 메인 세션이 옛 plan 보고 헤맴.
-
-### Step 9 — 결과 보고
-
-작성된 산출물 목록 + 다음 단계 안내:
-- *"`<NNN_slug>/` plan 생성 완료 — PLAN.md / ROADMAP.md + 제품 관통 문서 FEATURES/UX-UI 의도 stub 추가. AGENT-GUIDE.md 활성 plan `<NNN_slug>`로 갱신. 다음은 `/task-init`으로 첫 task 생성 (스키마/엔드포인트 상세는 task 진행에서 구현 동반)."*
-
-**결과 commit 흐름** (GIT_RULE 정합):
-- dev 직접 commit *금지* (git-guard.sh 차단). 두 가지 default 흐름:
-  1. **첫 task에 묶기 (권장)**: `/project-init` 직후 본 스킬 호출이면 init 산출물과 같은 작업 브랜치(보통 TASK-001 부트스트랩 chore)에 함께 commit. 새 기능 그룹 착수면 새 task 브랜치 또는 임시 docs 브랜치에서.
-  2. **임시 docs 브랜치**: `git checkout -b docs/{개발자}_plan-{NNN_slug}` 후 commit → dev에 `--no-ff` 머지. 다음 task 생성 *전*에 plan 산출물을 깔끔히 기록하고 싶을 때.
-
-## 도구 가이드
-
-- **Read**: PROJECT.md / `.project/` 루트 제품 관통 문서(FEATURES/UX-UI 등 delta 대상)
-- **Bash**: `MAIN_WT` 검출, `mkdir -p plans/<NNN_slug> tasks/<NNN_slug>/{spec-diffs,screenshots,mockup}`
-- **bin/lib.js**: `computeNextPlanNumber`(채번 + legacy 검출)
-- **Write/Edit**: PLAN.md / ROADMAP.md 작성, 제품 관통 문서 FEATURES/UX-UI delta append, AGENT-GUIDE 활성 plan 갱신
-- **AskUserQuestion**: slug 확정 / legacy 게이트 confirm
+**commit 흐름** (GIT_RULE): 현재 브랜치(= 부모)가 dev/main이면 직접 commit *금지*(git-guard 차단). default 둘:
+1. **첫 task에 묶기 (권장)**: `/project-init` 직후면 init 산출물과 같은 작업 브랜치(보통 TASK-001 부트스트랩 chore)에 함께. 새 기능 그룹이면 새 task 브랜치 또는 임시 docs 브랜치.
+2. **임시 docs 브랜치**: `git checkout -b docs/{개발자}_plan-{NNN_slug}` → commit → **현재 브랜치(부모) `--no-ff` 머지**(부모가 dev면 dev, dev_feat_x면 dev_feat_x).
 
 ## 주의사항
 
-- **plan-init은 *제품 관통 문서 전체를 만드는 스킬이 아니다*** — 7종은 project-init 영역. 본 스킬은 plan 로컬(PLAN/ROADMAP) + 제품 관통 문서 delta(의도)만.
-- **delta는 의도 레벨까지만** — FEATURES/UX-UI 의도 스텁은 두되, DATA-MODEL/API-SPEC 스키마·엔드포인트 *본문 선작성 금지*. 상세는 구현 동반(task).
-- **제품 관통 문서에 plan 태그 금지** — 기능 섹션은 자기기술. 어느 plan이 만들었는지 표기하지 않는다(plan은 작업 묶음이지 영구 기능 분류 단위가 아님).
-- **PLAN.md 본문 복제 금지** — 각 항목 = 루트 문서 섹션 링크 1줄. `## 활성 task 버전` 자기선언 라인 작성 X.
-- **legacy 폴더 감지 시 진행 보류** — NNN 아닌 폴더 잔존 시 사용자 confirm 전 새 plan 생성 금지.
-- **AGENT-GUIDE 활성 plan 갱신 *반드시*** — 값 = `NNN_slug`. 헤딩 텍스트 변경 X.
-- 답 받기 전 자동 추정 진행 X. 단 PROJECT.md / 기존 루트 문서 정보로 *제안*은 OK (사용자 confirm 후).
-
-## 상태 전이
-
-해당 없음 (plan 레벨 — task 상태 X).
+- **plan-init은 제품 관통 문서 전체를 만드는 스킬이 아니다** — 7종은 project-init 영역. 본 스킬은 plan 로컬(PLAN/ROADMAP) + 제품 관통 문서 delta(의도)만.
+- **delta는 의도 레벨까지만** — DATA-MODEL/API-SPEC 스키마·엔드포인트 *본문 선작성 금지*. 상세는 구현 동반(task).
+- **제품 관통 문서에 plan 태그 금지** — 기능 섹션은 자기기술.
+- **PLAN.md 본문 복제 금지** — 각 항목 = 루트 문서 섹션 링크 1줄. `## 활성 task 버전` 자기선언 X.
+- **legacy 폴더 감지 시 진행 보류** — 사용자 confirm 전 새 plan 생성 금지.
+- 답 받기 전 자동 추정 진행 X. 단 PROJECT.md/기존 루트 문서로 *제안*은 OK(confirm 후).

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

@@ -287,9 +287,9 @@ git branch -a                                        # main(또는 master) + dev
 - *"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 흐름:
+- 현재 브랜치(= 부모, 기본 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 단계의 "태스크 문서 커밋"에 자연스럽게 묶임.
-  2. **임시 docs 브랜치**: `git checkout -b docs/{개발자}_init-bootstrap` 후 commit → dev에 `--no-ff` 머지. 첫 task 생성 *전*에 init 결과를 깔끔히 기록하고 싶을 때.
+  2. **임시 docs 브랜치**: `git checkout -b docs/{개발자}_init-bootstrap` 후 commit → 현재 브랜치(부모)에 `--no-ff` 머지. 첫 task 생성 *전*에 init 결과를 깔끔히 기록하고 싶을 때.
 
 ## 도구 가이드
 

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

@@ -1,13 +1,13 @@
 ---
 name: task-close
-description: task git 마무리 — 검증 게이트 + 커밋 순서 + 머지 락 직렬화 + dev --no-ff 병합 + 워크트리/브랜치 자동 정리, tested → closed (멀티세션 0.1.2+)
+description: task git 마무리 — 검증 게이트 + 커밋 순서 + 머지 락 직렬화 + 부모 브랜치 --no-ff 병합 + 워크트리/브랜치 자동 정리, tested → closed (멀티세션 0.1.2+)
 ---
 
 # /task-close
 
 ## 개요
 
-`tested` 상태 task의 git 마무리. **호출 위치 자유** — 워크트리 cwd / 메인 워크트리 cwd / 다른 세션이 호출한 서브 세션 모두 동작 동일 (모든 git 명령이 `git -C <경로>` 형태라 cwd 무관). 사전 rebase → 충돌 해결 (3단계 에스컬레이션) → 머지 락 → 락 안 재 rebase → dev `--no-ff` 머지 → 워크트리 제거 + 작업 브랜치 자동 삭제.
+`tested` 상태 task의 git 마무리. **호출 위치 자유** — 워크트리 cwd / 메인 워크트리 cwd / 다른 세션이 호출한 서브 세션 모두 동작 동일 (모든 git 명령이 `git -C <경로>` 형태라 cwd 무관). `close` CLI 결정적 준비(Phase 커밋·status=closed·문서 커밋·추적 마커) → 사전 rebase → 충돌 해결 (3단계 에스컬레이션) → 머지 락 → 락 안 재 rebase → 부모 브랜치 `--no-ff` 머지 → 워크트리 제거 + 작업 브랜치 자동 삭제.
 
 **최종 게이트**: 모든 검증 명령 재실행 — 린트/타입체크/빌드 PASS여야 진행.
 
@@ -56,17 +56,17 @@ LOCK_FILE="$HOME/.taskery/${PROJECT_ID}.merge.lock"
 ### Step 1 — 사전 검증
 
 1. **메인 워크트리 검출** (위 핵심 변수).
-2. **메인 워크트리 = dev 검증**:
+2. **메인 워크트리 = 부모 브랜치 확인**: 메인 워크트리는 이 task의 *부모 브랜치*(task-init 시점 현재 브랜치, 헤더 기록)에 서 있어야 close가 그 부모로 되병합한다. 정확한 부모 일치는 Step 3 `close`가 검증(불일치 시 명확한 에러로 중단)하므로, 여기서는 detached HEAD만 조기 차단한다.
    ```sh
    CURRENT=$(git -C "$MAIN_WT" rev-parse --abbrev-ref HEAD)
-   [ "$CURRENT" = "dev" ] || abort "메인 워크트리가 dev 아님 (현재: $CURRENT). taskery 정책 위배"
+   [ "$CURRENT" != "HEAD" ] || abort "메인 워크트리가 detached HEAD — 부모 브랜치로 체크아웃 필요"
    ```
 3. **워크트리 미커밋 변경 확인**:
    ```sh
    git -C "$WT_PATH" status --porcelain
    ```
-   - 결과 *있음* = 정상 흐름 (taskery 정책: `/task-dev` = *git 작업 X*). 본 변경분은 Step 6-3에서 *task-close가 자동 Phase 커밋 생성*으로 처리.
-   - 결과 *없음* = 변경분 0건 → Step 2 검증만 수행 후 Step 6-3 자동 커밋 단계 스킵. **단 6-7까지 거쳐도 워크트리 브랜치가 dev보다 앞선 커밋이 0개면 Step 6-8에서 추적 마커 빈커밋 1개 생성** (`.project` gitignore + docs/분석 전용 task → 채번 보존).
+   - 결과 *있음* = 정상 흐름 (taskery 정책: `/task-dev` = *git 작업 X*). 본 변경분은 Step 3 `close`가 *Dev Plan Phase 매핑 → Phase별 자동 커밋*으로 처리.
+   - 결과 *없음* = 변경분 0건 → Step 2 검증만 수행. **워크트리 브랜치가 부모보다 앞선 커밋이 0개면 Step 3 `close`가 추적 마커 빈커밋 1개 생성** (`.project` gitignore + docs/분석 전용 task → 채번 보존).
    - **차단 X** — 본 단계는 *상태 인지*용. close 중단 사유 X.
 4. **task 파일 + GIT_RULE 확인**:
    - task 문서 위치 분기 (`.gitignore` 케이스):
@@ -101,16 +101,32 @@ FAIL 시:
   - *"고쳐"* → status `developing`으로 되돌림 + `/task-dev` 안내 + close 중단.
   - *"OK 마무리"* → 결함 명시한 채 진행 (Result 섹션에 *"검증 명령 X FAIL 알려진 결함 — 사유: ..."* 추가).
 
-### Step 3 — 사전 rebase (락 외, UX용 조기 충돌 감지)
+### Step 3 — 결정적 준비 (`task_close` 도구)
+
+`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:`).
+- **status → `closed`** — task 문서 헤더 (`.gitignore` 케이스 자동 판정 — 등록=메인WT / 미등록=워크트리).
+- **flows/문서 커밋** (미등록 케이스) — 워크트리 안 `.project/flows/` + task 문서.
+- **추적 마커 빈커밋** — 부모 브랜치보다 앞선 커밋이 0개(코드 0·`.project` gitignore인 docs/분석 task)면 채번 보존용 1개.
+
+반환 JSON `{ prepped, branch, parent, wtPath, registered, commits, aheadOfParent }`. **`parent`(= task 헤더에 기록된 부모 브랜치, 예 `dev` / `dev_feat_x`)가 이후 Step 4·5의 rebase·머지 대상이다** — 아래 명령의 `$PARENT`로 사용. (task-init이 fork 시점 현재 브랜치를 헤더에 기록해뒀다.)
+
+**콜백 (반환 `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:'status'`** (npx exit 3 — `{current}`): status가 `tested`가 아님. Step 1~2 통과했다면 발생 X. 발생 시 사용자 보고 + 중단.
+
+> **close 후 task 문서 수정 금지** — close가 status=`closed`로 잠갔다(`closed-immutable.sh` hook 차단). 이후 Step 4 충돌 해결 내역은 *task 문서가 아니라 rebase/머지 커밋 메시지*에 기록한다.
+
+### Step 4 — 사전 rebase + 충돌 자체 해결 (락 외, UX용 조기 감지)
+
+`close`가 모든 변경을 커밋했으므로 rebase가 깨끗하게 replay된다. `$PARENT` = Step 3 `close` 반환의 `parent`(머지 대상 부모 브랜치).
 
 ```sh
-git -C "$WT_PATH" rebase dev
+git -C "$WT_PATH" rebase "$PARENT"
 ```
 
-- 충돌 없음 → Step 6으로 (커밋 순서).
-- 충돌 있음 → Step 4 (3단계 에스컬레이션).
-
-### Step 4 — 충돌 자체 해결 (3단계 에스컬레이션)
+- 충돌 없음 → Step 5 (머지).
+- 충돌 있음 → 아래 3단계 에스컬레이션. 해결 내역은 *커밋 메시지*에 기록(문서는 closed라 수정 X).
 
 #### 4-a. 단순 충돌 → 자동 해결
 
@@ -124,7 +140,7 @@ git -C "$WT_PATH" rebase dev
 | 순위 | 자료 | 위치 |
 |------|------|------|
 | 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 풍부 메시지) |
+| 2 | 커밋 메시지 | `git log --all --grep` (GIT_RULE 풍부 메시지) |
 | 3 | diff | 변경 코드 자체 |
 
 - 1순위 부재 시 2/3순위 자동 fallback + 사용자에게 *자료 한계* 보고
@@ -136,132 +152,26 @@ git -C "$WT_PATH" rebase dev
 - 해결 방향 후보 제시 + 사용자 결정 후 재개.
 - 사용자가 중단 결정 시: `git -C "$WT_PATH" rebase --abort` 자동 + close 중단.
 
-### Step 5 — 태스크 문서에 충돌 해결 내역 추가 (해당 시)
+### Step 5 — 머지 락 + 락 안 재 rebase + 부모 브랜치 머지
 
-충돌 해결 1건이라도 발생했으면 task 문서에 기록.
+머지 락 안에서 [락 안 rebase → 메인WT 검증 → 부모 브랜치 `--no-ff` 머지]를 직렬 수행한다 (`bin/lib.js` `withMergeLock(projectId, fn)` — 다른 세션 머지와 직렬화). Phase 커밋·status=closed·문서 커밋·추적마커는 Step 3 `close`가 이미 끝냈으므로 본 단계는 *락 + rebase + 머지*만 담당. 메인 워크트리는 부모 브랜치(`$PARENT`)에 서 있어야 하며(close가 이미 검증), 머지는 그 부모 위로 이뤄진다.
 
-`.gitignore` 케이스 분기:
+#### 5-1. 머지 락 획득
 
-| 케이스 | 위치 | 흐름 |
-|--------|------|------|
-| 미등록 | `$WT_PATH/.project/tasks/<NNN_slug>/...` | 워크트리 안 task 문서 수정 → Step 6 Phase 커밋에 *코드 + 문서 = 한 커밋*에 포함 |
-| 등록 | `$MAIN_WT/.project/tasks/<NNN_slug>/...` | 워크트리 안 코드만 한 커밋 + 메인 워크트리 절대 경로 task 문서를 **proper-lockfile**로 별도 수정 (`bin/lib.js` `withMetaLock` — 머지 커밋 미포함, 메인 로컬 보존) |
+`bin/lib.js` `withMergeLock(projectId, fn, opts)` (proper-lockfile, `stale=LOCK_TIMEOUT_MS`, retries 5). 재시도 모두 실패 시 → 사용자 보고 + 중단.
 
-기록 형식 (task.md Result 섹션 안):
-```markdown
-### 충돌 해결 (close 직전 rebase)
-- 자료 우선순위: 태스크 문서 (다른 세션 TASK-XXX) / 커밋 메시지 / diff
-- 자료 한계 보고: (있으면 명시)
-- 해결 방향: <한 줄 요약>
-- 영향 파일: <목록>
-```
-
-### Step 6 — 머지 락 획득 + 락 안 재 rebase + 커밋 시퀀스
-
-#### 6-1. 머지 락 획득
-
-`bin/lib.js` `withMergeLock(projectId, fn, opts)` 호출. 내부 동작:
-
-```js
-// proper-lockfile
-await lockfile.lock(LOCK_FILE, {
-  stale: LOCK_TIMEOUT_MS,
-  retries: { retries: 5, factor: 1, minTimeout: 1000, maxTimeout: 1000 },
-});
-```
-
-재시도 모두 실패 시 → 사용자 보고 + 중단.
-
-#### 6-2. 락 안에서 rebase 재실행
+#### 5-2. 락 안에서 rebase 재실행
 
 ```sh
-git -C "$WT_PATH" rebase dev
+git -C "$WT_PATH" rebase "$PARENT"
 ```
 
-락 외 rebase 이후 *다른 세션이 dev 머지했을 수 있음* — 락 안 rebase로 흡수.
-- 재충돌 발견 시 Step 4 에스컬레이션 재실행 + Step 5 문서 기록 재실행.
-
-#### 6-3. Phase 기능 커밋 (Dev Plan 각 Phase마다 1개 — task-close가 자동 생성)
-
-> **책임 영역**: taskery 정책상 `/task-dev` = *git 작업 X* (워크트리 코드만 수정). 본 단계가 *task-close가 uncommitted 변경분 정독 → task.md `## Dev Plan` Phase 진행 [x] 매핑 → Phase별 commit 자동 생성*하는 단일 진입점이다.
-
-자동 생성 절차:
-
-1. **uncommitted 변경분 정독**:
-   ```sh
-   git -C "$WT_PATH" status --porcelain
-   git -C "$WT_PATH" diff --name-only
-   ```
-2. **task.md `## Dev Plan` 정독** — Phase별 `진행: [x]` + 파일 매핑 추출.
-3. **Phase ↔ 변경 파일 매핑**:
-   - 한 Phase가 단독 파일 영역이면 → Phase별 1 커밋.
-   - 같은 파일이 여러 Phase에 걸쳐 있으면 → *단일 통합 커밋 1개*로 묶음 (Phase 번호 표기는 *Phase X+Y*).
-   - 매핑 모호 / Dev Plan 본문 추적 불가 시 → 사용자 호출 + 결정 (자동 진행 X).
-- 메시지 형식 (GIT_RULE.md):
-  ```
-  {태그}: [TASK-<NNN>] Phase <N> - <작업 요약>
+락 외(Step 4) rebase 이후 *다른 세션이 부모 브랜치에 머지했을 수 있음* — 락 안 rebase로 흡수.
+- 재충돌 발견 시 Step 4 에스컬레이션 재실행 (해결 내역은 커밋 메시지 — 문서 closed).
 
-  - <처리 내용 1>
-  - <처리 내용 2>
-  - 사유: <변경 이유>
-  ```
-- 태그: feature → `feat:`, bug → `fix:`, improvement → `improve:`, refactor → `refactor:`, docs/chore → `docs:`, 테스트 → `test:`
+> Phase 커밋 · flows/문서 커밋 · status=closed · 추적 마커는 **Step 3 `close`가 이미 완료**했다. 본 단계는 머지 락 안에서 *재 rebase + 메인WT 검증 + 부모 머지*만 수행한다.
 
-> **GIT_RULE 풍부 메시지** — 본 메시지는 *충돌 해결 자료 2순위*로 쓰인다. 의도 한 줄 압축.
-
-> **자동 분리 로직 코드 구현**은 본 SKILL.md 영역 외 — 메인 세션이 본 절차를 따라 *수동/대화형* 진행. 향후 `bin/lib.js`에 `splitUncommittedByPhase(wtPath, taskMd)` 영역 별도 라운드.
-
-#### 6-4. flows/ 모듈 커밋 (해당 시)
-
-`$WT_PATH/.project/flows/<module>.md` 변경분 있으면 별도 커밋:
-```
-docs: [TASK-<NNN>] flows/<module>.md 갱신
-```
-
-- **`.gitignore` 미등록 케이스 한정** — 등록 케이스는 *워크트리 외부* 메인 워크트리 직접 수정 + `withMetaLock`.
-
-#### 6-5. task 파일 status → `closed` Edit
-
-closed-immutable.sh hook *허용* 영역 (status=closed 적용된 *후* 재수정이 차단).
-
-- **.gitignore 등록 케이스**: 메인 워크트리 task 문서를 `withMetaLock`으로 status=`closed` 갱신.
-- **.gitignore 미등록 케이스**: 워크트리 안 task 문서를 Edit.
-
-#### 6-6. 태스크 문서 커밋 (미등록 케이스 한정)
-
-```
-docs: [TASK-<NNN>] 태스크 문서 완료
-```
-
-- 대상: `$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 커밋 (해당 시)
-
-`$MAIN_WT/.project/rules/CHANGELOG_RULE.md` 정독 후 형식 / 위치 준수.
-
-- 위치 분기:
-  - 미등록 — 워크트리 안 `$WT_PATH/.project/changelog/<YYYY-MM>.md` 갱신 + 커밋
-  - 등록 — `$MAIN_WT/.project/changelog/<YYYY-MM>.md` `withMetaLock` 갱신 (커밋 X)
-- 본 task에서 변경분 없으면 본 단계 *완전히 스킵* (빈 commit 금지).
-
-#### 6-8. 추적 마커 빈커밋 (폴백 — 머지 커밋 미생성 케이스 한정)
-
-> **조건**: 6-3 ~ 6-7을 모두 거쳤는데도 워크트리 브랜치가 dev보다 앞선 커밋이 **0개**인 경우에만 발동.
-> **발생 케이스**: `.project`가 gitignore된 프로젝트에서 *코드 변경 0 + 산출물이 메인 워크트리 직접 수정 task 문서뿐*인 docs/분석 전용 task. 워크트리에 추적 가능한 변경이 없어 6-3 ~ 6-7이 전부 스킵된 상태.
-> **이유**: 이대로 Step 8 `--no-ff` 머지를 하면 브랜치가 dev와 동일 커밋이라 *Already up to date* → 머지 커밋이 생성되지 않는다. 그러면 dev 히스토리에 `TASK-NNN` 흔적이 남지 않고, 이후 작업 브랜치가 자동 삭제(Step 13)되면 `getNextTaskNumber`가 진행중 브랜치·dev 머지 양쪽에서 번호를 찾지 못해 **다음 task가 같은 번호를 재사용/충돌**한다.
-
-```sh
-if [ "$(git -C "$WT_PATH" rev-list --count dev..HEAD)" -eq 0 ]; then
-  git -C "$WT_PATH" commit --allow-empty \
-    -m "docs: [TASK-<NNN>] 추적 마커 — 코드 0·.project gitignore (채번 보존)"
-fi
-```
-
-- 마커 커밋으로 브랜치가 dev보다 1커밋 앞서게 되어, Step 8 `--no-ff` 머지가 정상 머지 커밋을 생성한다 (머지 커밋 메시지의 브랜치명에 `TASK-NNN`이 포함되어 grep 추적 가능).
-- 추적 변경이 하나라도 있는 일반 task는 조건(`-eq 0`)에 걸리지 않아 발동하지 않는다 — 기존 동작 그대로.
-
-### Step 7 — 메인 워크트리 uncommitted 검증 (머지 직전)
+#### 5-3. 메인 워크트리 uncommitted 검증 (머지 직전)
 
 ```sh
 git -C "$MAIN_WT" status --porcelain
@@ -270,7 +180,9 @@ git -C "$MAIN_WT" status --porcelain
 - 변경 있으면 → 사용자 호출 + 결정 (stash / 중단).
 - 등록 케이스에서 task 문서 직접 수정이 *.gitignore 차단으로 status에 안 잡힘* — 정상.
 
-### Step 8 — dev 머지
+#### 5-4. 부모 브랜치 `--no-ff` 머지
+
+메인 워크트리는 부모 브랜치(`$PARENT`)에 체크아웃돼 있다(close 검증). 그 위로 작업 브랜치를 머지한다.
 
 ```sh
 git -C "$MAIN_WT" merge --no-ff "$BRANCH"
@@ -278,12 +190,13 @@ git -C "$MAIN_WT" merge --no-ff "$BRANCH"
 
 - `-m` 옵션 금지 (git 기본 메시지).
 - 머지 커밋 해시 캡처: `MERGE_COMMIT=$(git -C "$MAIN_WT" rev-parse HEAD)`
+- 브랜치가 부모보다 1커밋 이상 앞서야 머지 커밋이 생성된다 — Step 3 `close`의 추적 마커가 docs/분석 task의 0-커밋 케이스를 이미 보장(채번 보존).
 
-### Step 9 — 머지 락 해제
+#### 5-5. 머지 락 해제
 
 `withMergeLock` 콜백 종료 시 자동 release.
 
-### Step 10 — 마찰 신호 자체 감지 (`/log-friction` 발동 후보)
+### Step 6 — 마찰 신호 자체 감지 (`/log-friction` 발동 후보)
 
 본 task 진행 중 *마찰 신호* 누적 여부를 검사. 감지 시 `/log-friction` 등록을 사용자에게 제안.
 
@@ -297,7 +210,9 @@ git -C "$MAIN_WT" merge --no-ff "$BRANCH"
 - 감지 신호 있음 → *"이번 task에서 X 부분이 마찰이었어 보여 — `/log-friction`으로 등록할까?"* OK 시 자동 발동.
 - 없음 → prompt X.
 
-### Step 11 — worktree remove 사전 검증
+### Step 7 — 워크트리 / 브랜치 정리 (비가역 — git-guard 면제 조항)
+
+#### 7-1. worktree remove 사전 검증
 
 ```sh
 git -C "$WT_PATH" status --porcelain  # unstaged
@@ -305,36 +220,34 @@ git -C "$WT_PATH" ls-files --others --exclude-standard  # 추적 X 파일
 ```
 
 - 발견 시 사용자 호출 + 결정:
-  - 보존 → Step 12, 13 모두 건너뜀 (브랜치도 보존 — 정합)
-  - 삭제 → Step 12 진행
-  - 취소 → close 중단 (dev 머지는 이미 완료)
+  - 보존 → 7-2, 7-3 모두 건너뜀 (브랜치도 보존 — 정합)
+  - 삭제 → 7-2 진행
+  - 취소 → close 중단 (부모 브랜치 머지는 이미 완료)
 
-### Step 12 — 워크트리 제거
+#### 7-2. 워크트리 제거
 
 ```sh
 git -C "$MAIN_WT" worktree remove "$WT_PATH"
 ```
 
-### Step 13 — 브랜치 자동 삭제 / 보존
+#### 7-3. 브랜치 자동 삭제 / 보존
 
-- **보존 키워드 감지** (`keep` / `--keep-branch` / `브랜치 남겨` / `브랜치 보존` / `브랜치 유지`) → 보존 + 워크트리도 보존 (Step 11~13 건너뛴 것과 정합).
+- **보존 키워드 감지** (`keep` / `--keep-branch` / `브랜치 남겨` / `브랜치 보존` / `브랜치 유지`) → 보존 + 워크트리도 보존 (7-1~7-3 건너뛴 것과 정합).
 - **그 외** → `git -C "$MAIN_WT" branch -d "$BRANCH"`
 
-### Step 14 — 안전망 출력
+### Step 8 — 안전망 출력 + 결과 보고
 
 ```
 삭제됨: $BRANCH
 복구: git -C "$MAIN_WT" branch $BRANCH $MERGE_COMMIT
 ```
 
-### Step 15 — 결과 보고
-
 ```
 ✅ TASK-<NNN> closed
 - 작업 브랜치: <BRANCH> (삭제 / 보존)
 - 워크트리: <WT_PATH> (제거 / 보존)
 - 커밋: Phase <N>개 + 태스크 문서 + (CHANGELOG)
-- dev 병합: --no-ff 완료 ($MERGE_COMMIT)
+- 부모 브랜치 병합: <PARENT> ← --no-ff 완료 ($MERGE_COMMIT)
 - 충돌 해결: <건수, 자료 한계 보고 있으면 포함>
 - 상태: tested → closed
 - 다음: 새 task 시작은 /task-init. 마찰 신호 감지된 경우 /log-friction 등록 제안
@@ -342,23 +255,23 @@ git -C "$MAIN_WT" worktree remove "$WT_PATH"
 
 ## 도구 가이드
 
-- **Read**: GIT_RULE / task 파일 / CLAUDE.md 검증 명령 정독
-- **Bash**: git 명령 (`branch`, `rebase`, `merge`, `worktree`) + 검증 명령 재실행. **유일하게 git 사용 허가된 스킬**
-- **Edit / Write**: task 파일 갱신, CHANGELOG (메타 위치는 `.gitignore` 케이스에 따라)
-- **bin/lib.js**: `withMergeLock` (머지 락) / `withMetaLock` (메타 파일 쓰기 락)
+- **Read**: GIT_RULE / task 파일 / CLAUDE.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**
+- **bin/lib.js**: `withMergeLock` (머지 락 — Step 5)
 
 ## 주의사항
 
 - **사용자 명시 호출 외 자체 진입 영구 금지** (stash FRICTION_LOG #6+10/#20) — task-close는 git 영역. 사용자가 *"X부터 Y까지"* 범위 명시했는데 Y가 close 이전 단계면 close 자체 진입 영구 X.
 - **검증 명령 재실행 게이트** — `/task-dev` self-check와 *별개*. 환경 변화 / 부분 작업 잡는 안전망.
-- **dev 직접 커밋 절대 X** — 작업 브랜치에서만. dev에서 `git commit` 시도 시 git-guard.sh 차단. 모든 git 명령은 cwd 무관 `git -C "$WT_PATH" ...` / `git -C "$MAIN_WT" ...` 형태 강제. 셸 prefix(`cd && git`) / `--git-dir=` / `--work-tree=` 변형 영구 금지 (§호출 위치 정책).
+- **부모 브랜치 직접 커밋 절대 X** — 작업 브랜치에서만. 부모가 dev/main이면 그 브랜치에서 `git commit` 시도 시 git-guard.sh가 차단(git-guard는 main/dev 보호). 모든 git 명령은 cwd 무관 `git -C "$WT_PATH" ...` / `git -C "$MAIN_WT" ...` 형태 강제. 셸 prefix(`cd && git`) / `--git-dir=` / `--work-tree=` 변형 영구 금지 (§호출 위치 정책).
 - **`--no-ff` 강제** — 머지 커밋 없으면 분기 정보 영구 손실.
 - **머지 락 직렬화** — 두 세션이 동시 머지 시도해도 한쪽씩 순차 진행. 락 외 rebase로 race 흡수 + 락 안 재 rebase로 다른 세션 머지 흡수.
 - **충돌 자체 해결 3단계** — 단순 자동 / 의미적 자료 / 판단 불가 사용자. 자료 한계 발견 시 *반드시 사용자에게 보고* (1순위 자료 부재 등).
 - **자료 한계 보고** — 충돌 분석 시 *2/3순위 fallback 사용했음*을 사용자에게 명시. 묵묵히 진행 X.
 - **destructive 명령 사용자 승인 필수** — `git reset --hard` / `git push --force` / `git branch -D` / `git clean -fd` 사용자 명시 승인 없이 절대 실행 X. (단 `/task-close` 자동 흐름 `git branch -d` + `worktree remove`는 §"작업 브랜치 삭제 정책 — 자동 삭제 면제 조항" 면제)
 - **민감 정보 staging X** — `.env` / `credentials.json` / API key 등 staging 절대 X.
-- **빈 commit 금지 (예외 1건)** — CHANGELOG 변경 없으면 6-7 단계 스킵, `--allow-empty` 사용 금지. **단 Step 6-8 추적 마커 빈커밋만 예외** — 워크트리 브랜치가 dev보다 앞선 커밋이 0개일 때 채번 보존용으로 1개 허용.
+- **빈 commit 금지 (예외 1건)** — `close`가 변경 없는 영역은 빈 commit을 만들지 않는다. **단 Step 3 `close`의 추적 마커 빈커밋만 예외** — 워크트리 브랜치가 부모보다 앞선 커밋이 0개일 때 채번 보존용으로 1개 허용.
 - **`-m` 옵션 머지 커밋에 사용 금지** — git 기본 메시지 사용.
 - **검수 서버/터널 정리는 자기 것만** — 본 task가 검수용으로 띄운 서버·터널(자기 포트 것)만 종료. `pkill -f` 류 광역 종료 금지 (다른 세션 프로세스까지 죽임). 상세: GIT_RULE "멀티세션 검수 환경".
 
@@ -375,5 +288,5 @@ git -C "$MAIN_WT" worktree remove "$WT_PATH"
 - **머지 락** — `~/.taskery/<projectId>.merge.lock` 단일. 모든 세션 직렬화.
 - **task 문서 단일 진실 소스** — `.gitignore` 케이스에 따라 메인 워크트리 또는 워크트리. 다른 세션의 충돌 해결 자료 정독 시 *SSoT 조회 → 워크트리 경로 산출* (미등록 케이스) 또는 *메인 워크트리 절대 경로* (등록 케이스).
 - **워크트리 + 브랜치 자동 제거** — GIT_RULE.md "작업 브랜치 삭제 정책" 면제 조항 (taskery 한정). 보존 키워드 시 양쪽 보존.
-- **safety net** — Step 14 복구 명령 출력. 사용자가 잘못 삭제 인지 시 즉시 복구 가능.
-- **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'` 순.
+- **safety net** — Step 8 복구 명령 출력. 사용자가 잘못 삭제 인지 시 즉시 복구 가능.
+- **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`(진행 중이면 부모 미머지가 정상) → 목록에 없을 때만 `git log --all --grep 'BL-NNN'` 순.

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

@@ -62,7 +62,7 @@ self-check 명령은 워크트리(`$WT_PATH`)에서 실행 — 코드 변경이
 
 ### Step 2 — status 전환 (planned → developing)
 
-진입 시 `planned`인 경우만 헤더 status를 `developing`으로 Edit.
+`set_status` 도구로 `developing` 전이 (또는 `npx @angar2/taskery set-status TASK-<NNN> developing`) — 진입 시 `planned`이면 `developing`으로. 이미 `developing`(이어가기)이면 idempotent no-op. (유효전이 코드 검증.)
 
 ### Step 3 — Phase 순서대로 구현
 
@@ -156,7 +156,7 @@ stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서
 
 ### Step 8 — status 전환 + 결과 보고
 
-1. 헤더 status → `developed` Edit.
+1. `set_status` 도구로 `developed` 전이 (또는 `npx @angar2/taskery set-status TASK-<NNN> developed`) — self-check + 테스트 PASS 후. (유효전이 코드 검증.)
 2. 결과 보고:
 
 ```
@@ -179,8 +179,8 @@ stash FRICTION_LOG #14+19 / #25 반영 — 유닛 테스트는 본 단계에서
 ## 도구 가이드
 
 - **Read**: task 파일 / `CLAUDE.md` 검증 명령 / 관련 코드 정독
-- **Edit / Write**: 코드 작성 + Phase 체크박스 갱신 + Result 섹션 갱신 + status 전환
-- **Bash**: 검증 명령 실행 (린트/타입/빌드/단위테스트). **git 명령 절대 X — `/task-close`만 git 담당**
+- **Edit / Write**: 코드 작성 + Phase 체크박스 갱신 + Result 섹션 갱신
+- **Bash / 도구**: 검증 명령 실행 (린트/타입/빌드/단위테스트) / `set_status` 도구(또는 `npx @angar2/taskery set-status`) status 전이. **git 명령 절대 X — `/task-close`만 git 담당**
 - **Grep / Glob**: 추가 코드 탐색 (Phase 진행 중 인접 영향 발견 시)
 
 ## 주의사항