@angar2/taskery 0.1.0

package/template/.claude/skills/refine.md

@@ -0,0 +1,177 @@
+---
+description: 회고 메타 — FRICTION_LOG 정독 + 반복 패턴 감지 + bottoms-up 보강 제안 (PLAYBOOK 부활 / 새 룰)
+---
+
+# /refine
+
+## 개요
+
+5 task마다 또는 사용자 호출 시 메인이 `.project/FRICTION_LOG.md`를 정독해 *반복 패턴 감지* + *bottoms-up 보강 제안*. PLAYBOOK 미래 옵션 항목 부활 검토 또는 새 룰 추가 제안. 사용자 OK 시 적용.
+
+**핵심 정신**: *"선제적 작성 금지, 진짜 데이터 모이면 그때 추가"* — top-down 선제적 작성 함정 회피.
+
+## 호출 시점
+
+- 5 task 닫고 나서 (`/task-close` 5회 후 메인이 사용자에게 *"`/refine` 돌릴까요?"* 제안 OK).
+- 사용자가 *"짜증 정리 좀"* / *"`/refine`"* 명시 호출.
+- 짜증 패턴이 단기 폭증할 때 (메인 자체 판단으로 사용자에게 제안).
+
+## 입력 처리
+
+인자 없음. 기본 흐름.
+
+옵션 인자 = `--scope last-N` (예: `--scope last-10` — 최근 10개 짜증만). 미명시 시 *전체* 정독.
+
+## 단계
+
+### Step 1 — FRICTION_LOG.md 정독
+
+1. `.project/FRICTION_LOG.md` Read.
+2. 파일 없거나 비어 있으면 종료 + 안내:
+   *"FRICTION_LOG가 비어 있어. 짜증 데이터 누적되면 다시 호출. 평소 *'이거 짜증나'* 발화해주면 메인이 한 줄씩 추가."*
+3. 인자 `--scope last-N` 있으면 마지막 N개 행만 추출.
+
+### Step 2 — 패턴 분류 + 빈도 카운트
+
+짜증 항목을 카테고리로 분류:
+
+| 카테고리 | 예시 |
+|---------|------|
+| 형식 위반 | task 헤더 누락 / 섹션 빠짐 / status 잘못 작성 |
+| 컨텍스트 부담 | 메인 세션이 무거워짐 / 답변 느림 / 압축 발생 |
+| 스킬 미스매치 | `/task-init` 인터뷰 짜증 / `/task-plan` 질문 너무 많음 / 등 |
+| Test Plan 가정 | 격리 세션이 메인 가정 못 풀어 헤맴 |
+| git/커밋 흐름 | 브랜치 이름 충돌 / 커밋 순서 헛갈림 |
+| 멀티리포 통신 | shared/ 메시지 못 잡음 / .env 빠짐 |
+| 자동화 부족 | 같은 작업 반복 / 자동화 가능한데 수동 |
+| 기타 | 위 카테고리 외 |
+
+각 카테고리 *빈도 카운트* + 짜증 행 인용.
+
+### Step 3 — 반복 패턴 감지
+
+빈도 ≥ 3회 카테고리는 *반복 패턴*으로 간주. 빈도 < 3회는 *단발성*으로 분류.
+
+```markdown
+## 반복 패턴 (≥ 3회)
+
+1. <카테고리>: <N회>
+   - 짜증 1: "<원문 인용>" (<날짜 / TASK 맥락>)
+   - 짜증 2: ...
+   - ...
+
+2. <카테고리>: <N회>
+   ...
+```
+
+### Step 4 — PLAYBOOK 항목 매핑
+
+`plan/PLAYBOOK.md` Read. 반복 패턴마다 *부활 후보 항목* 매핑:
+
+| 반복 패턴 카테고리 | PLAYBOOK 후보 항목 |
+|------------------|--------------------|
+| 형식 위반 | §4 minimal form hook |
+| 컨텍스트 부담 | §1 컨텍스트 격리 강화 / §2 압축 평가 subagent |
+| 스킬 미스매치 | (PLAYBOOK 외 — 스킬 instruction 보강 검토) |
+| Test Plan 가정 | (PLAYBOOK 외 — TASK_DOC_RULE.md §3.3 보강 검토) |
+| git/커밋 흐름 | (PLAYBOOK 외 — GIT_RULE.md 보강 검토) |
+| 멀티리포 통신 | (PLAYBOOK 외 — LINKED-REPOS.md 보강 검토) |
+| 자동화 부족 | §3 Python orchestrator (큰 그림) / §7 자동 PR 리뷰 |
+| 큰 묶음 작업 부담 | §5 `/plan-roadmap` 스킬 |
+| task 누적 우선순위 | §8 우선순위 컬럼 부활 |
+| npx update 충돌 | §9 머지 로직 엣지 케이스 보강 |
+
+### Step 5 — bottoms-up 제안서 작성
+
+```markdown
+## /refine 제안서 — <YYYY-MM-DD>
+
+### 반복 패턴 (≥ 3회)
+- <카테고리 1>: <N회>
+- <카테고리 2>: <N회>
+
+### PLAYBOOK 부활 검토
+1. **§<N> <항목명>** 부활 검토
+   - 사유: <패턴 N회 누적 — PLAYBOOK §<N> 매핑>
+   - 도입 방법: <PLAYBOOK §<N> 본문 §방법 그대로 인용 + 적용 영역>
+   - 얻는 것: <효용>
+   - 주의: <함정 — PLAYBOOK §<N> §주의 인용>
+
+2. ...
+
+### PLAYBOOK 외 보강 제안
+1. **<문서 / 스킬>** 보강
+   - 사유: <패턴 N회>
+   - 보강 방향: <구체 수정 제안>
+   - 영향 범위: <수정 대상 파일>
+
+### 단발성 짜증 (< 3회 — 데이터 더 모이기 대기)
+- <짜증 인용 N>회
+
+### 추천 다음 행동
+- <사용자 OK 시 적용 순서>
+```
+
+### Step 6 — 사용자 합의
+
+제안서 보여주기 + *"어느 항목 적용할까?"* 묻기.
+
+분기:
+- **사용자 OK한 항목 → 즉시 적용 (또는 별도 task로 분리)**:
+  - PLAYBOOK 부활: 해당 PLAYBOOK 항목 *방법* 그대로 따라 새 task 생성 — `/task-init` 호출 권장 (큰 변경이면).
+  - 스킬 instruction 보강: 해당 `template/.claude/skills/<스킬>.md` 직접 Edit + 사유 기록.
+  - TASK_DOC_RULE / GIT_RULE 보강: 해당 룰 파일 Edit + 수정 이력 행 추가.
+- **거부한 항목 → 보류** (FRICTION_LOG에 *"보류 — `/refine` <YYYY-MM-DD>"* 메모).
+- **단발성 → 그대로 누적** (반복되면 다음 `/refine`에서 다시 검토).
+
+### Step 7 — FRICTION_LOG 갱신
+
+본 `/refine` 호출 결과를 FRICTION_LOG에 메타 행 추가:
+
+```markdown
+## /refine — <YYYY-MM-DD>
+
+- 반복 패턴: <카테고리> N회 / <카테고리> N회
+- 부활 적용: §<N> <항목명> (TASK-<NNN>으로 분리)
+- 보강 적용: <문서명> §<N> Edit
+- 보류: <항목>
+- 단발성 누적: N건
+```
+
+이 메타 행은 다음 `/refine`이 *이전 회고 결과 참조*용.
+
+### Step 8 — 결과 보고
+
+```
+✅ /refine 완료
+- 정독한 짜증 행: <N>건
+- 반복 패턴: <카테고리> N개
+- 적용한 보강: <목록>
+- 보류: <목록>
+- 단발성 누적: <N>건 (다음 회고 대기)
+
+다음 일정: <5 task 후 / 사용자 호출 시>
+```
+
+## 도구 가이드
+
+- **Read**: `.project/FRICTION_LOG.md` / `plan/PLAYBOOK.md` / 보강 대상 룰/스킬 파일 정독
+- **Edit**: 보강 적용 (TASK_DOC_RULE / GIT_RULE / 스킬 instruction Edit) + FRICTION_LOG 메타 행 추가
+- **AskUserQuestion**: Step 6 합의 — 어느 항목 적용할지 사용자 답
+- **Write**: 신규 룰/문서 추가 (드뭄 — 보통 PLAYBOOK 부활 항목이 새 hook 등 신규 파일 생성 요청 시)
+
+## 주의사항
+
+- **선제적 작성 금지** — *진짜 데이터(반복 패턴) 없이* PLAYBOOK 부활 절대 X. 합리적 변형 차단 함정 회피의 핵심.
+- **단발성 짜증 = 데이터 부족** — < 3회 패턴은 *부활 검토 X*. 누적 대기.
+- **자체 판단으로 룰 작성 금지** — 보강 제안은 *사용자 합의 후* 적용. *"이거 좋아 보여"* 자체 판단으로 즉시 Edit X.
+- **합리적 변형 차단 함정** — minimal form hook 부활 시 *섹션 존재* 검사만. *내용 검증 X* — 25행 화이트리스트 함정 회피 (PLAYBOOK §4 §주의 참조).
+- **PLAYBOOK 본문 인용 그대로** — *방법* 인용 시 자체 추측 작성 금지. PLAYBOOK 본문 한 줄씩 따라가며 적용.
+- **`/refine` 호출 빈도** — 매 task마다 호출 X. 5 task 또는 짜증 누적 폭증 시. 너무 잦으면 *회고 자체가 짜증*.
+- **회고 → 보강 → 다음 task** 흐름 — 보강 적용은 *별도 task로 분리* 권장 (큰 변경이면). `/task-init` 호출하고 plan에 부활 사유 기록.
+
+## 상태 전이
+
+해당 없음 (meta 레벨 — task 상태 전이 X).
+
+단 보강 적용이 *별도 task*로 분리되면 그 task는 일반 흐름 (draft → planned → ... → closed) 따라감.

package/template/.claude/skills/task-close.md

@@ -0,0 +1,178 @@
+---
+description: task git 마무리 — 검증 명령 재실행 게이트 + 커밋 순서 준수 + dev --no-ff 병합, tested → closed
+---
+
+# /task-close
+
+## 개요
+
+`tested` 상태 task의 git 마무리. 작업 브랜치(없으면 생성)에서 커밋 순서(GIT_RULE 준수) 따라 진행 + dev 병합 + status `closed`.
+
+**최종 게이트**: 모든 검증 명령 재실행 — 린트/타입체크/빌드/단위테스트 PASS여야 진행.
+
+## 호출 시점
+
+- `/task-test` PASS 후 + 사용자 OK.
+- `/task-test` FAIL 후 사용자 *"OK 마무리"* (알려진 결함 명시 채로).
+
+## 입력 처리
+
+인자 = (선택) `TASK-NNN` 또는 자동 선택.
+
+분기:
+- **인자 명시**: 해당 task 파일.
+- **인자 없음**: 활성 plan 버전의 *상태=tested인 가장 최근 task* 자동 선택 + confirm.
+
+## 단계
+
+### Step 1 — task 파일 + GIT_RULE 확인
+
+1. `.project/AGENT-GUIDE.md` Read → 활성 plan 버전 확인.
+2. task 파일 Read:
+   - 인자 있음 → 해당 파일.
+   - 인자 없음 → `tested` 상태 가장 최근 task. confirm. 없으면 *"마무리할 task 없음."* + 종료.
+3. 상태 = `tested` 검증. 그 외면 종료 (단 알려진 결함 *"OK 마무리"*는 status=tested로 명시되어 있어야 함).
+4. GIT_RULE Read 우선순위:
+   - `.project/rules/GIT_RULE.md` (프로젝트별 — 우선)
+   - `~/.claude/rules/GIT_RULE.md` (글로벌)
+   둘 다 없으면 종료 + *"GIT_RULE 누락"* 보고.
+
+### Step 2 — 최종 검증 명령 재실행 (게이트)
+
+`CLAUDE.md`의 *검증 명령* 모두 재실행. **하나라도 FAIL이면 close 차단**:
+
+| 명령 | 결과 |
+|------|------|
+| 린트 | exit 0 + 에러 0 |
+| 타입체크 | exit 0 |
+| 빌드 | exit 0 |
+| 단위 테스트 | 모든 케이스 PASS |
+
+FAIL 시:
+- 사용자에게 보고 — *"검증 명령 X가 FAIL. 어떻게 할까?"*
+- 분기:
+  - *"고쳐"* → status를 `developing`으로 되돌림 + `/task-dev` 안내 + close 중단.
+  - *"OK 마무리"* → 결함 명시한 채 진행 (Result 섹션에 *"검증 명령 X FAIL 알려진 결함 — 사유: ..."* 추가).
+
+PASS 시 Step 3으로.
+
+### Step 3 — 작업 브랜치 확인/생성
+
+1. `git branch --show-current` 실행 → 현재 브랜치 확인.
+2. 분기:
+   - **현재 브랜치 = `{타입}/{개발자}_TASK-<NNN>_<slug>`** → 그대로 진행.
+   - **현재 브랜치 = `dev`** (또는 다른 곳) → 새 작업 브랜치 생성:
+     ```
+     git checkout -b {타입}/{개발자}_TASK-<NNN>_<slug>
+     ```
+     - **타입**: feature → `feature`, bug → `bug`, improvement → `improve`, refactor → `refactor`, docs → `docs`, chore → `chore`
+     - **개발자**: 메인 세션 = `claude`, 사용자 세션 = `angar2` 등 (실제 작업자)
+     - **slug**: task 파일명에서 그대로
+     - 예: `feature/claude_TASK-007_login-feature`
+3. 작업 브랜치 진입 후 *변경분이 미리 stage* 되어 있어야 함. dev에서 작업했다면 이미 working tree에 변경분 있음 — 그대로 새 브랜치 진입 후 staging.
+4. **작업 브랜치 생성과 staging/commit은 별도 Bash 호출로 분리**. `git checkout -b ... && git add ... && git commit ...` 같이 `&&`로 묶으면 git-guard.sh가 *명령 텍스트 분석 시점*에 dev 브랜치로 판정해 commit을 차단함 (분리하면 정상 통과). 묶음 명령 default X.
+
+### Step 4 — 커밋 (GIT_RULE 순서 준수)
+
+**필수 순서**:
+
+1. **Phase별 기능 커밋** — Dev Plan의 각 Phase마다 1개 커밋.
+   - 같은 파일이 여러 Phase에 걸쳐 변경됐으면 *단일 통합 커밋 1개*로 묶음. 커밋 메시지 본문에 Phase별 변경을 `-`로 나열, 헤더 태그/번호는 마지막 Phase 사용.
+   - 메시지 형식 (GIT_RULE.md):
+     ```
+     {태그}: [TASK-<NNN>] Phase <N> - <작업 요약>
+
+     - <처리 내용 1>
+     - <처리 내용 2>
+     - 사유: <변경 이유>
+     ```
+   - 태그: feature → `feat:`, bug → `fix:`, improvement → `improve:`, refactor → `refactor:`, docs/chore → `docs:`, 테스트 파일 → `test:`
+2. **flows/ 모듈 커밋 (해당 시)** — `.project/flows/<module>.md` 변경분 있으면 별도 커밋:
+   ```
+   docs: [TASK-<NNN>] flows/<module>.md 갱신
+
+   - <변경 요약>
+   - 사유: <변경 이유>
+   ```
+3. **태스크 문서 커밋**:
+   ```
+   docs: [TASK-<NNN>] 태스크 문서 완료
+   ```
+   - 대상: `.project/tasks/<vX.X>/<NNN>_<slug>.md` (단일 파일) 또는 `.project/tasks/<vX.X>/TASK-<NNN>_<slug>/task.md` (폴더 승격) — *task 본 파일 + 해당 NNN의 vX.X 공통 spec-diffs/<NNN>_<slug>_spec-diff.md / screenshots/<NNN>_*.png* 묶음.
+   - spec-diffs/screenshots는 *vX.X 공통* 위치 — 폴더 승격 시에도 task 폴더 안에 만들지 X (TASK_DOC_RULE §1.5 참조).
+4. **CHANGELOG 커밋 (해당 시)**:
+   - `.project/changelog/<YYYY-MM>.md` Edit (없으면 신규 Write):
+     ```markdown
+     # <YYYY-MM>
+
+     ## TASK-<NNN> — <제목>
+     - <Phase 1 요약>
+     - <Phase 2 요약>
+     - ...
+     ```
+   - 커밋:
+     ```
+     docs: [TASK-<NNN>] CHANGELOG 업데이트
+     ```
+   - 본 task에서 변경분 없으면 본 단계 *완전히 스킵* (빈 commit 금지).
+
+### Step 5 — dev 병합
+
+1. `git checkout dev` 실행.
+2. 일반 타입(feature/bug/improvement/refactor/docs/chore) → **`git merge --no-ff <작업 브랜치>` 강제** (fast-forward 절대 금지).
+   - `-m` 옵션 사용 금지 — 머지 커밋 메시지는 git 기본값 사용.
+3. plan/roadmap 임시 docs 브랜치 예외 — 단일 커밋이라 `--ff-only` 가능 (일반 흐름에서는 거의 발생 X).
+4. **작업 브랜치 자동 삭제 금지** — 사용자 명시 승인(*"브랜치 삭제해"*)이 있을 때만 `git branch -d`. 미승인 시 보존.
+
+### Step 6 — task 파일 status 전환
+
+헤더 status → `closed` Edit. 단 이 Edit은 closed-immutable.sh hook에 잡힐 수 있음 — task 파일 *마지막* 수정으로 적용한 후 별도 커밋 불필요(이미 Step 4-3에서 커밋함).
+
+→ Edit이 Step 4-3 커밋 *전*에 일어나야 하므로 실제 흐름은:
+
+**실제 순서 재정리**:
+1. Step 4-1: Phase 기능 커밋
+2. Step 4-2: flows/ 커밋 (해당 시)
+3. **task 파일 status를 `closed`로 Edit** (closed-immutable.sh hook 차단되지 X — 이 Edit은 *허용*. status가 closed가 *된 후 재수정*이 차단)
+4. Step 4-3: 태스크 문서 커밋 (status=closed 적용된 채로)
+5. Step 4-4: CHANGELOG 커밋
+6. Step 5: dev 병합
+
+### Step 7 — 결과 보고
+
+```
+✅ TASK-<NNN> closed
+- 작업 브랜치: <브랜치명>
+- 커밋: Phase <N>개 + 태스크 문서 + (CHANGELOG)
+- dev 병합: --no-ff 완료
+- 상태: tested → closed
+- 작업 브랜치 보존 (삭제하려면 "브랜치 삭제해" 명시)
+- 다음: 새 task 시작은 /task-init, 5 task 누적 시 /refine으로 회고
+```
+
+## 도구 가이드
+
+- **Read**: GIT_RULE / task 파일 / CLAUDE.md 검증 명령 정독
+- **Bash**: git 명령 (`branch`, `checkout`, `add`, `commit`, `merge`) + 검증 명령 재실행. **유일하게 git 사용 허가된 스킬**
+- **Edit**: task 파일 status → `closed`, CHANGELOG 갱신
+- **Write**: CHANGELOG 신규 (없으면)
+
+## 주의사항
+
+- **검증 명령 재실행 게이트** — `/task-dev` self-check / `/task-test` 격리 세션 PASS와 *별개로* 본 단계에서 한 번 더 실행. 환경 변화 / 부분 작업 / 메인 가정 등 잡는 안전망. 무리하게 게이트 우회 X.
+- **dev 직접 커밋 절대 X** — 작업 브랜치에서만. dev 브랜치에서 `git commit` 시도하면 git-guard.sh hook이 차단. hook이 0회 작동하도록 정상 흐름 준수.
+- **`--no-ff` 강제** — 머지 커밋 없으면 작업 브랜치 분기 정보 영구 손실. fast-forward 시도 절대 X.
+- **destructive 명령 사용자 승인 필수** — `git reset --hard` / `git push --force` / `git branch -D` / `git clean -fd` 사용자 명시 승인 없이 절대 실행 X. 충돌/오류 시 사용자에게 보고 + 승인 요청 의무.
+- **민감 정보 staging X** — `.env` / `credentials.json` / API key 등 staging 절대 X. `.gitignore`에 포함되어 있어도 한 번 더 점검.
+- **빈 commit 금지** — CHANGELOG 변경 없으면 4-4 단계 스킵. `--allow-empty` 사용 금지.
+- **작업 브랜치 자동 삭제 X** — 사용자 명시 승인 있을 때만. 머지 후 자동 삭제 룰 X (분기 정보 보존).
+- **branch -D 사용자 승인 필수** — `-d` (안전 삭제)는 머지 확인된 브랜치만 가능. `-D` (강제 삭제)는 사용자 명시 승인 필수.
+- **`-m` 옵션 머지 커밋에 사용 금지** — git 기본 메시지 사용 (GIT_RULE §병합 커밋).
+
+## 상태 전이
+
+| 진입 시 | 종료 시 |
+|--------|--------|
+| `tested` | `closed` |
+
+(검증 명령 FAIL + 사용자 *"고쳐"* → `developing`으로 되돌림. 본 스킬 자체는 거기서 중단.)

package/template/.claude/skills/task-dev.md

@@ -0,0 +1,155 @@
+---
+description: task 구현 — Dev Plan Phase 순서대로 코드 작성 + self-check 게이트, planned → developing → developed
+---
+
+# /task-dev
+
+## 개요
+
+`planned` 상태 task의 Dev Plan을 Phase 순서대로 구현. 각 Phase 완료 시 체크박스 갱신 + Result 섹션에 진행 기록. 모든 Phase 완료 + self-check (린트/타입/빌드/단위테스트) PASS 시 status를 `developed`로 갱신.
+
+self-check 명령은 프로젝트 루트 `CLAUDE.md`의 *검증 명령* 섹션 참조 — 단일 진실 소스.
+
+## 호출 시점
+
+- `/task-plan` 끝나고 기획 합의된 직후.
+- 도중 끊겼던 task 이어서 구현 (status=`developing`).
+- `/task-test` FAIL 후 사용자 *"고쳐"* 응답 → status가 `developing`으로 되돌아온 경우 재진입.
+
+## 입력 처리
+
+인자 = (선택) `TASK-NNN` 또는 자동 선택.
+
+분기:
+- **인자 명시**: 해당 task 파일 진행.
+- **인자 없음**: 활성 plan 버전의 *상태=planned 또는 developing인 가장 최근 task* 자동 선택 + confirm.
+
+## 단계
+
+### Step 1 — task 파일 + 검증 명령 확인
+
+1. `.project/AGENT-GUIDE.md` Read → 활성 plan 버전 확인.
+2. task 파일 Read:
+   - 인자 있음 → 해당 파일.
+   - 인자 없음 → `ls .project/tasks/<vX.X>/` 결과 중 status=`planned` 또는 `developing`인 가장 최근 파일. 발견 시 *"TASK-<NNN> 진행할까요?"* confirm. 없으면 *"진행할 task 없음. `/task-plan` 먼저 호출."* + 종료.
+3. 상태 검증:
+   - `planned` → 신규 진행 (Step 2 status 전환).
+   - `developing` → 이어가기 (Step 2 skip — 이미 developing).
+   - 그 외 → 종료 + 안내.
+4. 프로젝트 루트 `CLAUDE.md` Read → *검증 명령* 섹션의 린트/타입체크/빌드/테스트 명령 추출. 이 명령들이 self-check 게이트의 단일 진실 소스.
+
+### Step 2 — status 전환 (planned → developing)
+
+진입 시 `planned`인 경우만 헤더 status를 `developing`으로 Edit.
+
+### Step 3 — Phase 순서대로 구현
+
+1. Dev Plan의 Phase 1부터 순서대로 진행. 순서 건너뛰기 X.
+2. 각 Phase:
+   - **파일 / 왜 / 어떻게 / 완료 기준** 정독.
+   - 코드 작성 (Edit / Write).
+   - 주요 로직 체크포인트마다 *로그 심기* (예: `console.log` / `print` / `logger.info`) — 디버깅 + `/task-test` 격리 세션이 흐름 추적 가능하게.
+   - 완료 기준 충족 확인. 미충족이면 같은 Phase 내 추가 작업.
+   - Phase의 `진행: [ ]` → `진행: [x]` Edit.
+3. 계획 외 변경 필요 시 사용자에게 먼저 확인 — *"이 Phase에서 X도 같이 손대야 하는데 OK?"*. 합의 없이 스코프 확장 X.
+
+### 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 형식 참조).
+3. Phase 0 `진행: [x]` Edit.
+
+### Step 5 — flows/ 업데이트 (해당 시)
+
+도메인/비즈니스 흐름이 변경된 경우:
+1. `.project/flows/<module>.md` 확인.
+2. 없으면 신규 Write (모듈 단위 흐름 문서). 있으면 해당 항목 Edit.
+3. 변경 없는 단순 버그 수정 / 스타일 / 설정 변경 → flows/ 업데이트 X.
+
+| 상황 | flows/ 업데이트 |
+|------|-------------|
+| 신규 기능 추가 | 필요 |
+| 기존 기능 로직 변경 (함수명/플로우 변경) | 필요 |
+| 단순 버그 수정 (로직 변경 없음) | 불필요 |
+| 스타일/포맷/설정 변경 | 불필요 |
+
+### Step 6 — self-check 게이트
+
+Step 1에서 추출한 검증 명령을 *전부* 실행. 모두 PASS여야 `developed`로 전이 가능.
+
+| 명령 | PASS 기준 |
+|------|---------|
+| 린트 (예: `npm run lint`) | exit 0 + 에러 0 |
+| 타입체크 (예: `npm run typecheck`) | exit 0 |
+| 빌드 (예: `npm run build`) | exit 0 |
+| 단위 테스트 (예: `npm test <범위>`) | 모든 케이스 PASS |
+
+**FAIL 시**:
+1. 메인이 자체 수정 시도 — 에러 메시지 분석 + 코드 수정 + 재실행.
+2. 같은 종류 fail이 3회 반복되면 사용자에게 보고 + 판단 요청 (*"이 에러가 풀리지 않아. 추가 정보 필요"*).
+3. 수정 + 재PASS 시까지 status `developing` 유지. PASS 못 받으면 `developed` 전환 X.
+
+### Step 7 — Result 섹션 진행 기록
+
+`## Result` 섹션의 *진행* 부분 Edit (테스트 결과는 `/task-test`에서 채움):
+
+```markdown
+## Result
+
+### 진행
+- Phase 1: <구현 요약 — 변경 파일 / 핵심 로직>
+- Phase 2: <...>
+- Phase N: <...>
+
+### 테스트 (격리 세션 결과)
+(`/task-test`에서 채움)
+```
+
+- 각 Phase 한두 줄로 무엇을 어떻게 했는지 요약.
+- 변경 파일 목록 명시 (예: `src/auth/login.ts` 신규, `src/api/auth.test.ts` 12 케이스 추가).
+
+### Step 8 — status 전환 + 결과 보고
+
+1. 헤더 status → `developed` Edit.
+2. 결과 보고:
+
+```
+✅ TASK-<NNN> 구현 완료
+- Phase: <N>개 모두 [x]
+- 변경 파일: <목록>
+- self-check: lint/typecheck/build/test 모두 PASS
+- 상태: developing → developed
+- 다음: /task-test TASK-<NNN> 으로 격리 세션 검증
+```
+
+## 도구 가이드
+
+- **Read**: task 파일 / `CLAUDE.md` 검증 명령 / 관련 코드 정독
+- **Edit / Write**: 코드 작성 + Phase 체크박스 갱신 + Result 섹션 갱신 + status 전환
+- **Bash**: 검증 명령 실행 (린트/타입/빌드/단위테스트). **git 명령 절대 X — `/task-close`만 git 담당**
+- **Grep / Glob**: 추가 코드 탐색 (Phase 진행 중 인접 영향 발견 시)
+
+## 주의사항
+
+- **git 명령 절대 X** — 본 스킬은 코드만. `git commit` / `git push` / `git branch` 등 모두 `/task-close`에서. self-check fail 후 *재실행*도 git 무관.
+- **Phase 순서 건너뛰기 X** — Phase 1 끝나기 전 Phase 2 진행 X. 의존 관계 깨짐 + 디버깅 어려워짐.
+- **계획 외 스코프 확장 X** — Dev Plan에 없는 파일 다루기 전 사용자 confirm. *"이 부분 같이 작업해야 할 것 같은데 OK?"* 합의 후 진행.
+- **self-check FAIL 시 `developed` 전환 X** — 무리하게 상태 갱신 금지. 메인 자체 수정 시도 → 안 되면 사용자에게 보고. *"잘 될 거야"* 가정 금지.
+- **로그 심기 잊지 X** — Dev Plan 작성 시 `[로그]` 항목 명시되어 있으면 *반드시* 실제 로그 코드 삽입. 격리 세션 / 운영 디버깅 모두 의존.
+- **Result 섹션 진행만** — 테스트 결과는 `/task-test`가 기록. 메인이 *"잘 됐을 거야"* 가정 작성 금지.
+- **flows/ 업데이트 누락 X** — 신규 기능 / 로직 변경이면 `.project/flows/<module>.md` 갱신. 미갱신 시 다음 task가 옛 정보 보고 헤맴.
+
+## 상태 전이
+
+| 진입 시 | 종료 시 |
+|--------|--------|
+| `planned` | `developed` |
+| `developing` (이어가기) | `developed` |
+
+self-check FAIL → `developing` 그대로 유지 (수정 + 재PASS 시까지).
+
+**self-check 게이트 hard-fail 조건**:
+- 완료 조건 미체크 (Phase `진행: [ ]` 잔존) → `developed` 전환 차단
+- Bash 에러 (검증 명령 fail) → `developed` 전환 차단
+- 보안 취약점 — 메인 자체 검토 (1차 자기검토. 진짜 데이터 모이면 PLAYBOOK §7 자동 PR 리뷰 부활)

package/template/.claude/skills/task-init.md

@@ -0,0 +1,142 @@
+---
+description: task 시작 — 6 섹션 빈 골격 + 헤더 5컬럼 (status=draft) task.md 생성
+---
+
+# /task-init
+
+## 개요
+
+새 task 시작 시 호출. `.project/tasks/<vX.X>/` 안에 *빈 골격* task.md 생성. 헤더 5컬럼 채우고 6 섹션은 placeholder만. 상태는 `draft`로 작성.
+
+본 스킬은 *생성만* 담당. Requirements / Scope / Dev Plan / Test Plan 본문은 다음 단계 `/task-plan`에서 채움.
+
+## 호출 시점
+
+- 새 task 시작 시 (사용자 발화: *"~~ 추가해줘"*, *"~~ 버그 고쳐"*, *"~~ 리팩터링"*).
+- 직전 대화로 작업 맥락 명확해진 직후.
+
+## 입력 처리
+
+인자 = (선택) 주제 / 유형 / 규모 / 플랜. 예: `/task-init 로그인 기능` 또는 인자 없이 호출.
+
+두 분기:
+- **분기 1 (제안)**: 직전 맥락 명확 → 메인이 *"이렇게 task 만들까요?"* 제안 + 사용자 confirm.
+- **분기 2 (인터뷰)**: 직전 맥락 부족 → 한 번에 한 질문씩 인터뷰.
+
+**자동 추정 진행 X** — 사용자 confirm 또는 답 받기 전 파일 생성 금지.
+
+## 단계
+
+### Step 1 — active plan 버전 확인
+
+1. `.project/AGENT-GUIDE.md` Read → *활성 plan 버전* 추출 (예: `v1.0`).
+2. AGENT-GUIDE.md 없거나 활성 버전 누락 시 → 사용자에게 *"활성 plan 버전이 없는데 `/plan-init` 먼저 실행할까요?"* 묻고 중단.
+3. `.project/plans/<vX.X>/` 디렉토리 존재 확인. 없으면 동일하게 `/plan-init` 안내 + 중단.
+
+### Step 2 — 분기 판단 + 메타 수집
+
+직전 대화 정독:
+- 작업 주제 / 유형 / 규모 추정 가능?
+  - **추정 가능** → 분기 1 (제안):
+    *"직전 맥락 보니 다음 task 만들까요? 주제: <X> / 유형: <Y> / 규모: <Z> / 플랜: <vX.X>. 어떠세요?"*
+    사용자 답 — *"OK"* / *"규모는 large야"* / *"유형은 bug야"* 등 부분 수정 받음.
+  - **추정 불가** → 분기 2 (인터뷰): 한 번에 한 질문씩.
+    - Q1: *"무슨 작업인가요? (한 줄로)"*
+    - Q2: *"유형? (feature / bug / improvement / refactor / docs / chore)"*
+    - Q3: *"규모? (micro / small / medium / large) — 잘 모르겠으면 추정 알려드림."*
+    - (필요 시) Q4: *"플랜 버전 `<vX.X>` 맞나요?"*
+
+수집 항목 (모두 확정되어야 진행):
+- 주제 (한국어 — kebab-slug 변환은 Step 4에서)
+- 유형: `feature` / `bug` / `improvement` / `refactor` / `docs` / `chore`
+- 규모: `micro` / `small` / `medium` / `large`
+- 플랜 버전: 활성 버전 그대로 (Step 1에서 가져온 값)
+
+### Step 3 — TASK 번호 결정
+
+1. `ls .project/tasks/<vX.X>/` 실행 → 디렉토리 안 파일/폴더 목록 추출.
+2. 파일명 / 폴더명 패턴 검출:
+   - 파일: `NNN_<slug>.md` (예: `001_login-form.md`, `012_db-migration.md`)
+   - 폴더: `TASK-NNN_<slug>/` (예: `TASK-003_payment-flow/`)
+3. NNN 최대값 + 1 = 새 task 번호. 빈 디렉토리면 `001`.
+4. 3자리 zero-padded (`001`, `015`, `120`).
+
+### Step 4 — 파일 vs 폴더 결정 + slug 변환
+
+1. 파일 vs 폴더 분기:
+   - **파일 default**: 단일 `NNN_<slug>.md` (예: `008_login-feature.md`).
+   - **폴더 승격 조건**: (a) 규모 `large`, 또는 (b) 사용자 명시 *"폴더로 만들어줘"*, 또는 (c) task에 *추가 자료*(서브 문서 / mockup / 디자인) 다수 예상.
+     → `TASK-NNN_<slug>/task.md` 생성. 추가 자료는 *task 폴더 안에 자유롭게* 위치.
+   - **`spec-diffs/` + `screenshots/`는 *vX.X 공통* 사용**: 단일 파일이든 폴더 승격이든 `.project/tasks/<vX.X>/{spec-diffs,screenshots}/`에 위치 (파일명에 NNN prefix로 task 식별 — `<NNN>_<slug>_spec-diff.md`). task 폴더 안에 spec-diffs/screenshots 생성하지 않음.
+   - 위 디렉토리는 `/plan-init` Step 5가 vX.X 만들 때 함께 mkdir됨. `/task-init`은 디렉토리 가정만, 직접 생성 X.
+2. slug 변환 — 한국어 → 영어 kebab-case:
+   - 짧고 명확하게 (3 단어 이내 권장).
+   - 소문자 + 하이픈만. 예: *"로그인 기능 추가"* → `login-feature`, *"모바일 사파리 폼 새로고침 버그"* → `mobile-safari-form-refresh`.
+3. 사용자에게 슬러그 confirm (선택):
+   *"파일명: `<NNN>_<slug>.md` 어떠세요? (수정 원하면 말씀)"*
+
+### Step 5 — 빈 골격 작성
+
+`# TASK-<NNN> — <한국어 제목>` + 헤더 5컬럼 + 6 섹션 placeholder. 양식은 `template/.project/rules/TASK_DOC_RULE.md` §1.3 참조.
+
+```markdown
+# TASK-<NNN> — <한국어 제목>
+
+| 생성일 | 플랜 | 유형 | 규모 | 상태 |
+|--------|------|------|------|------|
+| <YYYY-MM-DD> | <vX.X> | <유형> | <규모> | draft |
+
+## Requirements
+
+(사용자 요구 + 메인 증폭 — `/task-plan`에서 채움)
+
+## Scope
+
+(영향 범위 — `/task-plan`에서 채움)
+
+## Dev Plan
+
+(Phase 1, 2, ... — `/task-plan`에서 채움)
+
+## Test Plan
+
+(테스트 방법 + 검증 명령 — `/task-plan`에서 채움)
+
+## Result
+
+(진행 + 테스트 결과 — `/task-dev`, `/task-test`에서 채움)
+```
+
+- 6 섹션 placeholder는 *빈 헤딩 + 한 줄 안내*. 구체 내용 X.
+- 폴더 승격 시 `TASK-<NNN>_<slug>/task.md`로 동일 본문 작성. spec-diffs/screenshots는 vX.X 공통(`.project/tasks/<vX.X>/{spec-diffs,screenshots}/` — `/plan-init` Step 5가 mkdir)을 그대로 사용. task 폴더 안에 spec-diffs/screenshots 별도 생성 X.
+
+### Step 6 — 결과 보고
+
+```
+✅ TASK-<NNN> 생성 완료
+- 파일: .project/tasks/<vX.X>/<NNN>_<slug>.md (또는 폴더 승격 시 경로)
+- 헤더: <생성일> / <vX.X> / <유형> / <규모> / draft
+- 다음: /task-plan TASK-<NNN> 으로 기획 채우기
+```
+
+## 도구 가이드
+
+- **Read**: `.project/AGENT-GUIDE.md` (활성 버전 확인)
+- **Bash**: `ls .project/tasks/<vX.X>/` (NNN 결정), `mkdir -p .project/tasks/<vX.X>/TASK-<NNN>_<slug>` (폴더 승격 시 — task 폴더 자체만, spec-diffs/screenshots는 vX.X 공통 사용)
+- **Write**: 새 task.md 생성
+- **AskUserQuestion**: 분기 2 인터뷰 (한 번에 한 질문)
+
+## 주의사항
+
+- **본문 채우기 금지** — 본 스킬은 *빈 골격 생성만*. Requirements / Scope / Dev Plan / Test Plan 본문은 *반드시* `/task-plan`에서. 미리 채우면 task 의도가 흐트러져 다음 단계 인터뷰 흐름이 깨짐.
+- **자동 추정 진행 X** — 직전 맥락 명확해도 *제안 + 사용자 OK* 거친 후 파일 생성. 맥락 부족 시 인터뷰. 빠뜨린 메타(유형/규모) 채로 작성 금지.
+- **상태는 `draft` 고정** — `/task-init` 끝의 상태는 `draft` 외 작성 금지. 다음 상태(`planned`)는 `/task-plan` 끝에 갱신.
+- **NNN 충돌 회피** — `ls` 결과 정확히 파싱. 파일/폴더 둘 다 검사 (폴더 승격 task의 NNN도 같은 시퀀스).
+- **slug 한국어 잔존 X** — 영어 kebab-case로 변환. *"로그인-기능"* 같은 한글 슬러그 금지.
+- **헤더 5컬럼 모두 채움** — *"미정"* placeholder 작성 금지. 메타 부족하면 사용자에게 묻기.
+
+## 상태 전이
+
+| 진입 시 | 종료 시 |
+|--------|--------|
+| (없음 — 신규 생성) | `draft` |