@angar2/taskery 0.8.0 → 1.0.0

package/template/.taskery/rules/TASKERY_RULE.md

@@ -0,0 +1,112 @@
+# TASKERY_RULE — taskery 참고서
+
+> 사용법이 막혔을 때 읽는 참고서다. 매번 읽지 않는다 — 평소에는 `AGENTS.md`와 그 단계의 스킬만 읽는다.
+> taskery 패키지가 관리하는 파일이라 `update`로 갱신된다. 이 리포만의 규칙은 `*.local.md`에 적는다.
+
+## 1. taskery란
+
+작업을 태스크 단위로 열고 마무리하는 도구다. 판단(요구 정리·코드 작성·완료 기준 작성·충돌 해결)은 AI가 하고, 누가 해도 결과가 같은 일(번호 발급·분기·기록·커밋·병합·정리)은 명령이 한다.
+
+## 2. 태스크의 다섯 단계
+
+| 단계 | 스킬 | 부르는 명령 |
+|---|---|---|
+| 시작 | `task-init` | `prepare-task` |
+| 기획 | `task-plan` | `approve-plan` |
+| 개발 | `task-dev` | `test-code` |
+| 테스트 | `task-test` | `test-scenario` |
+| 마무리 | `task-close` | `verify-close` → `commit-task` → `merge-task` → `close-task` |
+
+- **크기**(`small`·`medium`·`large`)는 태스크 문서에 얼마나 적나를 정한다. small은 커밋 하나, medium·large는 Phase마다 커밋 하나다.
+- **스위치**(기획·개발·테스트)는 그 단계를 정식으로 거치나를 정한다. 기본은 모두 켜짐이다. 개발 꺼짐 태스크는 코드를 바꾸지 않고 병합을 건너뛴다. 개발과 테스트를 둘 다 끌 수는 없다.
+- **진행 범위**는 사용자의 가장 최근 지시를 따른다. 말하지 않으면 한 단계, "~까지"면 그 단계까지, "끝까지"면 병합까지. 범위와 무관하게 눈으로 확인할 시나리오·테스트 FAIL·풀지 못한 충돌에서는 멈춘다.
+- 태스크 상태는 열림·닫힘 둘뿐이다. 단계 표는 명령이 성공할 때만 채워진다.
+
+## 3. 명령
+
+명령은 MCP 도구가 있으면 도구로, 없으면 `npx @angar2/taskery <명령>`으로 부른다. 막히면 명령이 왜 멈췄고 무엇을 하라고 알려 준다.
+
+| 명령 | 하는 일 |
+|---|---|
+| `status` | 열린 태스크·단계 표·단계별 시간·문서 경로·워크트리 경로, 플랜별 시작할 수 있는 태스크·읽지 못한 항목 |
+| `plan-init <slug> [--title "<제목>"]` | 다음 플랜 번호로 `plans/<NNN>_<slug>/PLAN.md` 틀 |
+| `prepare-task "<제목>" --slug --type --size [--switch] [--range] [--plan] [--item] [--from] [--dev] [--no-worktree] [--no-branch]` | 번호·브랜치·워크트리·태스크 문서·기록 |
+| `approve-plan <TASK>` | 태스크 문서 검사 → 계획 끝 기록 |
+| `test-code [TASK]` | 등록된 코드 테스트 실행. 태스크를 주면 개발 칸 기록 |
+| `test-code --register "<명령>" …` | 코드 테스트 명령 목록 등록(부를 때마다 전체 교체). 없으면 `--register none` |
+| `test-scenario <TASK> <번호> pass\|fail "증거"` | 시나리오 결과. 모두 끝나면 테스트 칸 |
+| `test-scenario <TASK> <번호> accept "<사용자가 한 말>"` | FAIL을 알고 넘어가기로 한 사용자 판단 기록 |
+| `verify-close <TASK>` | 마무리 검사만 |
+| `commit-task <TASK>` | Phase별 코드 커밋 + 병합 확인 요약 |
+| `merge-task <TASK>` | 병합 잠금 안에서 부모 최신으로 rebase → 병합 |
+| `close-task <TASK>` | 워크트리·브랜치 정리 → 닫기 → 백로그 연결 표시 → 변경 기록 → 시간 보고 |
+| `prune [--yes]` | 닫힌 태스크에 남은 워크트리·브랜치 정리. 기본은 항목마다 묻는다. 커밋 안 된 변경이 있는 곳은 건너뛴다 |
+| `backlog-add "<제목>" [--type <종류>]` | 백로그 번호를 발급해 `BACKLOG.md` 열린 항목 맨 위에 빈 양식 |
+| `backlog-get [BL-번호]` | 번호를 주면 그 항목 전문, 없으면 열린 항목 목록 |
+| `backlog-mark <BL-번호> <TASK>` | `--from` 없이 연 태스크를 백로그 항목에 연결 |
+| `orca-dispatch-task <TASK> --agent claude\|codex --model <모델> [--note "<한 줄>"]` | 오케스트레이션이 Orca 새 탭에 태스크 세션을 띄우고 첫 지시문을 보낸다(Orca 전용). 탭 handle은 태스크 문서 메타 `tab`에 남는다 |
+| `report-task <TASK> "<한 줄>"` | 태스크 세션이 오케스트레이션에 보고 한 줄을 남긴다(`.taskery/reports.log`) |
+| `wait-reports` | 오케스트레이션이 백그라운드 셸로 걸어 두는 대기. 안 읽은 보고가 생기면 출력하고 끝나고, 보고 없이 10분이면 오래 조용한 태스크 탭 목록과 함께 끝난다 (CLI만) |
+| `init` · `update` · `add <claude\|codex>` | 설치 · 갱신 · 플랫폼 추가 (CLI만) |
+
+태스크 명령(`approve-plan`~`merge-task`)에 `--range "<새 범위>"`를 붙이면 태스크 문서의 범위 메모만 바뀐다.
+
+## 4. 코드 테스트와 실사용 테스트
+
+- **코드 테스트**(개발 단계): 린트·타입·빌드·단위 테스트처럼 **앱·화면을 켜지 않는** 명령만 등록한다. 3분이 기준이고, 넘으면 명령이 알린다(끊지 않는다).
+- **실사용 테스트**(테스트 단계): 완료 기준 시나리오를 실제로 해 본다. 앱 실행 방법은 `TEST_RULE.local.md`에 적는다. 증거(실행 출력·화면 캡처 경로·사용자 확인 시각) 없는 PASS는 없다.
+
+## 5. 워크트리
+
+- 모든 태스크는 브랜치와 워크트리를 분기한다. 태스크 수행은 그 워크트리 안에서 한다.
+- 워크트리는 Orca 탭 안이면 Orca가, 아니면 `~/.taskery/worktrees/<projectId>/`에 taskery가 만든다.
+- 부모 브랜치 = 본진(리포 원래 폴더)이 서 있는 브랜치다. 본진은 다른 태스크가 병합받는 자리라 부모 브랜치에 그대로 둔다.
+- 생략은 사용자가 명시할 때만: `--no-worktree`(본진에서 브랜치만), `--no-branch`(본진의 현재 브랜치에서). 생략 태스크가 열려 있는 동안 본진이 부모 브랜치를 떠나 있거나 커밋 안 된 코드를 가지면, 다른 태스크의 `prepare-task`·`merge-task`가 원인 태스크를 알리고 멈춘다.
+- 워크트리를 지우는 일은 태스크를 연 주인이 본진에서 `close-task`로 한다. 정리가 막혀 남은 것은 `prune`으로 정리한다.
+- 새 워크트리 준비: `.taskery/manifest.json`의 `buildOutput`에 등록된 빌드 결과 폴더(예: Rust `target`)를 본진에서 APFS 복제(`cp -Rc`)로 심고, 워크트리마다 자기 폴더로 빌드한다. 등록이 없거나 APFS가 아니면 건너뛴다. `package-lock.json`이 있으면 `npm ci`를 한다. 등록은 `init`이 스택을 보고 적고(Xcode 프로젝트는 `DerivedData` — 코드 테스트 명령에 `-derivedDataPath DerivedData`를 붙인다), 바꿀 때는 매니페스트를 고친다. 등록한 폴더는 `.git/info/exclude`에 들어가 코드로 커밋되지 않는다. 끝난 태스크를 `close-task`로 닫을 때 그 워크트리의 빌드 결과 폴더를 본진으로 복제해 다음 태스크의 씨앗으로 쓴다.
+
+## 6. taskery 파일 — 모두 git 밖, 본진에 한 벌
+
+`.taskery/`·`AGENTS.md`·`CLAUDE.md`·`.claude/`·`.codex/`·`.mcp.json`은 git이 추적하지 않는다(`.git/info/exclude`). 워크트리에는 `AGENTS.md`·`CLAUDE.md`가 복사되고 나머지는 본진을 가리키는 링크로 놓인다 — 어느 워크트리에서 고쳐도 본진의 한 벌이 바뀐다. 커밋 대상은 코드뿐이다.
+
+```
+.taskery/
+├─ manifest.json 설치 정보, 코드 테스트 명령, 빌드 결과 폴더 등록
+├─ rules/        TASKERY_RULE · GIT_RULE · TASK_DOC_RULE · MOCKUP_RULE · CHANGELOG_RULE · TEST_RULE.local · DEV_RULE.local
+├─ spec/         제품 문서 — 내용 있는 것만
+├─ plans/<NNN>_<slug>/
+│  ├─ PLAN.md    목표 + 태스크 목록
+│  └─ tasks/     태스크 문서 (TASK_DOC_RULE)
+├─ changelog/    월별 변경 기록 (CHANGELOG_RULE)
+├─ PROJECT.md · GLOSSARY.md · BACKLOG.md · FRICTION_LOG.md
+├─ reports.log   오케스트레이션 보고 (report-task가 쓴다)
+└─ .state/       명령이 따로 저장하는 기록과 잠금 파일 — 읽거나 고치지 않는다
+```
+
+## 7. PLAN.md 태스크 목록
+
+```markdown
+## 태스크 목록
+1. 로그인 화면 — 선행: 없음
+2. 로그인 API 연결 — 선행: 1
+```
+
+- 한 줄 형식은 `<항목 번호>. <한 줄 설명> — 선행: <항목 번호들 또는 없음>`이다.
+- `prepare-task --item <항목 번호>`로 열면 명령이 그 줄 끝에 `(TASK-012)`를 붙인다.
+- `status`는 끝나지 않았고 열린 태스크가 없으며 선행 항목이 모두 끝난 항목을 시작할 수 있는 태스크로 보여 준다. 항목이 끝났다 = 줄 끝에 가장 최근 연결된 태스크가 마무리 기록(병합, 병합이 없는 태스크는 `commit-task` 완료)을 남기고 닫힌 것. 형식을 읽지 못한 줄은 '읽지 못한 항목'으로 따로 보여 준다.
+
+## 8. 로컬 규칙
+
+- 이 리포만의 규칙은 `.taskery/rules/<문서>.local.md`에 적는다. `init`이 `TEST_RULE.local.md`·`DEV_RULE.local.md` 틀을 만들고, `update`는 `*.local.md`를 건드리지 않는다.
+- `TEST_RULE.local.md` — 이 프로젝트의 앱 실행 방법(검수 서버·터널 포함)과 테스트 방식.
+- `DEV_RULE.local.md` — 이 프로젝트의 구현 규칙.
+- 코드·테스트 방식에 관한 새 규칙은 AI가 문장을 제안하고 사용자가 승인한 뒤 넣는다.
+
+## 수정 이력
+
+| 날짜 | 변경 사항 |
+|---|---|
+| 2026-10-01 | 1.0판 — 참고서로 다시 썼다. 7상태·멀티세션 내부 동작·훅·제품 관통 문서 7종·멀티리포 설명을 빼고, 다섯 단계·명령·워크트리·git 밖 파일·PLAN.md 목록 형식을 담았다 |
+| 2026-10-01 | S4 — 로컬 규칙 틀(`TEST_RULE.local.md`·`DEV_RULE.local.md`)을 `init`이 만든다는 줄을 더했다 |
+| 2026-10-01 | S3 — 오케스트레이션 명령 `orca-dispatch-task`·`report-task`·`wait-reports`와 `reports.log`를 더했다 |
+| 2026-10-01 | S2 — `prune`·`backlog-*`·`prepare-task --from`·`status`의 시작할 수 있는 태스크, 새 워크트리 준비(빌드 결과 폴더 APFS 복제·exclude 등록·닫을 때 본진 씨앗 갱신·`npm ci`)를 더했다 |

package/template/.taskery/rules/TASK_DOC_RULE.md

@@ -0,0 +1,84 @@
+# TASK_DOC_RULE
+
+> 태스크 문서를 쓰는 법이다. `task-plan`이 헷갈릴 때 읽는다.
+
+## 1. 모양
+
+`prepare-task`가 `.taskery/plans/<플랜>/tasks/<NNN>_<slug>.md`를 만든다.
+
+```markdown
+# TASK-012 설정 화면 저장 버튼 색 변경
+<!-- taskery: plan=001_mvp type=improve size=small switch=plan,dev,test range=끝까지 parent=dev by=taskery -->
+
+| 시작·기획 | 개발 | 테스트 | 닫기 |
+|---|---|---|---|
+| ✅ 2분 | ✅ 3분 | ⏳ | – |
+
+## 목표
+## 완료 기준
+## 만질 파일
+## 결정
+## 결과
+```
+
+- **맨 위 두 줄(메타)과 단계 표는 명령이 쓴다.** 손대지 않는다. 범위가 바뀌면 다음 태스크 명령에 `--range "<새 범위>"`를 붙인다.
+- medium·large는 `## 요구사항`(목표 아래)과 `## Phase`(만질 파일 아래)가 더 있다.
+- 전체 15~30줄이면 충분하다.
+
+## 2. 절마다 쓰는 법
+
+| 절 | 쓰는 법 |
+|---|---|
+| `## 목표` | 무엇을 왜 하는지 한두 줄. 첫 줄이 small 커밋의 사유와 변경 기록 요약이 된다 |
+| `## 요구사항` | (medium·large) 정리한 요구 목록 |
+| `## 완료 기준` | 실사용 테스트 시나리오. 아래 3절 |
+| `## 만질 파일` | 한 줄에 `- 경로` 하나. 설명은 ` — ` 뒤에 적는다. 폴더는 `src/auth/`처럼 끝에 `/` |
+| `## Phase` | (medium·large) 아래 4절 |
+| `## 결정` | 다른 선택지가 있었고 나중에 "왜 이렇게 했지"를 물을 만한 결정만 `무엇을 정했나 — 왜` 한 줄. 없으면 비운다 |
+| `## 결과` | `test-scenario`가 시나리오 결과를 한 줄씩 붙인다. 직접 쓰지 않는다 |
+
+`approve-plan`은 목표와 만질 파일이 있는지, 테스트가 켜져 있으면 완료 기준이 1~5개인지 본다.
+
+## 3. 완료 기준
+
+```markdown
+## 완료 기준
+1. [AUTO] 설정 화면 → 저장 버튼을 본다 → 버튼이 파란색으로 보인다
+2. [USER] 설정 화면 → 이름을 바꾸고 저장 → 목록에 바뀐 이름이 보인다
+```
+
+- 한 줄 형식은 `<번호>. [AUTO|USER] 시작 → 행동 → 기대하는 끝 상태`, 최대 5개. `test-scenario`의 번호는 이 순서다.
+- `[AUTO]`는 AI가 실행해 확인하고, `[USER]`는 사용자가 눈으로 확인한다.
+- 시나리오 하나에 의도 하나, 한 번의 실행 흐름이다. 기대값은 사용자가 화면에서 보는 결과로만 적는다.
+- 실행 방법(쿼리·훅·명령)은 적지 않는다. 내부 값(DB 행·로그·픽셀)은 코드 테스트의 몫이다.
+- 무언가를 없애는 태스크는 대신 보여야 할 것을 함께 적는다.
+- 이 태스크 브랜치에서 실제로 해 볼 수 있는 것만 적는다.
+
+## 4. Phase (medium·large)
+
+```markdown
+## Phase
+### Phase 1 — 로그인 API
+- 파일: `src/auth/login.ts`, `src/auth/session.ts`
+- 사유: 토큰 인증으로 바꾼다
+
+### Phase 2 — 로그인 화면
+- 파일:
+  - `src/ui/LoginForm.tsx`
+- 사유: 새 API를 화면에 잇는다
+```
+
+- `commit-task`가 Phase마다 커밋 하나를 만든다. 파일은 한 줄에 쉼표로, 또는 들여쓴 목록으로 적는다.
+- 한 파일이 여러 Phase에 걸치지 않게 나눈다. 걸치면 앞 Phase 커밋에 들어가고 메시지에 "(Phase 1·2 변경 포함)"이 붙는다.
+- 목록에 없는 파일(잠금 파일 등)은 마지막 Phase 커밋에 들어가고, 병합 확인 요약에 "계획 확인 뒤 추가된 파일"로 보인다.
+- small은 Phase 없이 커밋 하나다.
+
+## 5. 부속 자료
+
+화면 캡처는 태스크 문서 옆 `screenshots/`, 목업은 `mockup/`에 둔다. 처음 쓸 때 만든다.
+
+## 수정 이력
+
+| 날짜 | 변경 사항 |
+|---|---|
+| 2026-10-01 | 1.0판 — 메타 두 줄·단계 표(명령이 씀)와 목표·완료 기준·만질 파일·결정·결과 절로 바꿨다. 6칸 헤더·7상태·Scope·Test Plan·요구사항↔시나리오 대조표·spec-diff·폴더 승격을 뺐다 |

package/template/.taskery/rules/TEST_RULE.local.md

@@ -0,0 +1,16 @@
+# TEST_RULE.local
+
+> 이 리포의 실사용 테스트 방법이다. `task-dev`·`task-test`가 읽는다. 이 리포가 소유하는 파일이라 `update`가 건드리지 않는다.
+> 아는 내용만 적는다. 모르는 절은 비워 두고, 작업 중에 확인되면 그때 채운다. 코드 테스트 명령은 여기가 아니라 `test-code --register`로 등록한다.
+
+## 앱 실행
+
+<!-- 앱을 켜는 명령과 경로. 실제 사용자 데이터를 건드리지 않고 켜는 방법(격리 인자·시험용 데이터 폴더 등) -->
+
+## 검수 서버·터널
+
+<!-- 사용자가 화면을 확인할 주소와 띄우는 방법 -->
+
+## 테스트 방식
+
+<!-- 실사용 테스트에 필요한 것(시험용 계정·샘플 파일 위치 등)과 이 프로젝트에서 지키는 방식 -->

package/template/AGENTS.md

@@ -1,55 +1,17 @@
 # AGENTS.md
 
-> 본 문서는 에이전트 최상위 지침이다. 세션 시작 시 자동 로드된다.
-> **본 문서에는 규칙·사용법을 추가하지 않는다** — 규칙은 `.project/rules/`, 이 리포의 커스텀은 `*.local.md`가 담당한다. 본 문서에서 갱신이 허용되는 것은 아래 리포 값 칸(프로젝트 메타 · 각 명령)뿐이다.
-
----
-
-## 최상위 지침 — taskery 강제
-
-1. 본 리포지토리는 **taskery로 운영된다.** taskery는 task 단위 라이프사이클(문서 · 상태 · git · 검증)을 스킬과 CLI로 관리하는 시스템이다.
-2. **taskery 사용은 선택이 아니라 강제다.** 모든 작업은 예외 없이 taskery의 흐름을 통해서만 수행한다. taskery를 우회한 임의 진행 — 수동 git 운영 · 스킬 미호출 작업 · 규칙 밖 문서 생성 — 은 전면 금지된다.
-3. **`.project/rules/TASKERY_RULE.md`를 필독하라.** taskery의 전체 사용법은 전부 그 설명서에 있다. 읽지 않은 채로 작업을 시작하지 않는다.
-4. **`.project/rules/`의 모든 규칙을 무조건 따른다.** 코어 룰과 이 리포의 `*.local.md` 커스텀 룰 전부가 대상이다. 겹치는 조항은 로컬이 최우선이고, 겹치지 않는 로컬 조항도 그대로 준수한다. **어떤 사유로도 규칙 위반은 정당화되지 않는다.**
-5. **사용자가 명시한 범위만 수행한다.** 명시하지 않은 단계로 스스로 진입하는 것은 영구 금지다.
-6. **세션 시작 시 현재 위치를 자가 진단한다** — 메인 워크트리인지 task 워크트리인지 판정한 후 그에 맞는 흐름으로 진입한다. *"메인에서 그냥"* 류의 발화는 규칙 충돌 신호다. 정지하고 확인한다. (방법과 상세는 `TASKERY_RULE` §5.)
-
----
-
-## 프로젝트 메타
-
-- **이름**: <프로젝트명>
-- **타입**: <frontend / backend / fullstack / cli / library / other>
-- **소개 (한 줄)**: <도메인 / 비전>
-- **상세**: `.project/PROJECT.md` 참조
-
-## 검증 명령
-
-> 각 명령은 그대로 실행 가능한 형태로 적는다. 해당 없는 항목은 행을 삭제한다.
-
-- 린트: `<예: npm run lint>`
-- 타입체크: `<예: npm run typecheck>`
-- 빌드: `<예: npm run build>`
-
-## 테스트 명령
-
-- 단위 테스트: `<예: npm test>`
-- 통합 테스트: `<있을 때만>`
-- E2E 테스트: `<있을 때만>`
-
-## 검수 실행 명령
-
-> 앱을 띄워 사용자가 직접 확인해야 하는 프로젝트에만 해당한다. 아니면 이 절 전체를 삭제한다.
-
-- 기준 포트: `<예: 5100>`
-- 실행 명령: `<예: npm run dev -- --port <PORT>>`
-- 터널: `<선택 — 외부 확인이 필요할 때만>`
-
----
-
-## 세션 진입 절차
-
-1. 본 문서 정독
-2. `.project/rules/TASKERY_RULE.md` 필독 — taskery 사용법 전체
-3. `npx @angar2/taskery status` — 활성 plan · 진행중 task 확인
-4. `.project/` 제품 관통 문서 + 활성 plan의 `PLAN.md` 정독
+## taskery
+1. 이 리포는 taskery로 운영한다. 모든 작업은 taskery 스킬과 명령으로 한다.
+2. 사용자가 명시한 범위만 수행한다. 범위를 말하지 않으면 한 단계만 하고 멈춘다. "~까지", "끝까지"라고 하면 거기까지 이어 간다. 눈으로 확인할 항목·테스트 실패·풀지 못한 충돌에서는 멈춘다.
+3. 태스크는 항상 브랜치와 워크트리를 분기한다. 생략은 사용자가 명시할 때만 하고, 먼저 제안하지 않는다.
+4. git과 로컬 규칙은 `.taskery/rules/GIT_RULE.md`와 `*.local.md`를 따른다.
+5. taskery 명령은 MCP 도구가 있으면 도구로, 없으면 `npx @angar2/taskery`로 부른다.
+6. 사용법이 막히면 `.taskery/rules/TASKERY_RULE.md`를 참고한다.
+
+## 프로젝트
+- 이름: <프로젝트명>
+- 타입: <frontend / backend / fullstack / cli / library / other>
+- 소개: <한 줄>
+
+## 세션 시작
+- `taskery status`로 진행 중인 태스크를 확인한다.

package/template/shared/skills/add-backlog/SKILL.md

@@ -1,46 +1,16 @@
 ---
 name: add-backlog
-description: 사용자 발화로 *plan(기능 그룹)별* tasks/<NNN_slug>/BACKLOG.md에 task 후보 1건 추가 — 얕은 분석(개요/대상 영역) + BL-NNN 채번 + withMetaLock 직렬화 (0.1.2+)
+description: 백로그 등록 — backlog-add로 번호와 빈 양식을 받아 BACKLOG.md 항목 하나의 필수 칸을 채운다
 ---
 
-# /add-backlog
+# add-backlog
 
-사용자 발화를 받아 *활성 plan별 백로그* `.project/tasks/<NNN_slug>/BACKLOG.md`에 task 후보를 1건씩 누적한다. **얕은 분석**만 — 코드 직접 탐색 X, 추정 수준. 본격 분석은 다음 단계 `/task-plan`.
+프로젝트 백로그(`.taskery/BACKLOG.md`, 하나뿐)에 항목 하나를 등록한다.
 
-## 호출 시점
+- `.taskery/BACKLOG.md` 맨 위의 쓰는 법을 따른다.
+- `backlog-add "<제목>"`(종류를 알면 `--type`)으로 양식을 받은 뒤 나머지 필수 칸(종류·현상)을 채운다. 모자라면 사용자에게 한 줄로 묻는다.
+- 선택 칸은 대화·작업 맥락에 근거가 있을 때만 줄을 더해 적거나 제안한다. 근거가 없으면 두지 않는다. 칸을 채우려고 지어내지 않는다.
 
-- 명시 호출: `/add-backlog 로그인 빈 화면 떠`
-- 발화 캐치: *"~ 백로그에 추가해 줘"* 등 백로그 추가 의도 발화
-- 무인자 호출 시 *"어떤 항목? 한 줄로 알려줘"* 인터뷰. 다건 명시 시 1건씩 순차 처리.
+## 부르는 명령
 
-## 판단 (LLM, 코드 탐색 X)
-
-발화에서 후보 1건을 뽑아 추정 수준의 메타를 산출한다:
-
-- **유형** (`feature` / `bug` / `improve` / `refactor` / `docs` / `chore`) — 자동 추정, *모호 시 사용자 confirm* (예: *"메뉴 검색 개선"* = feature/improve 모호)
-- **제목** — 한 줄, 간결, 한국어
-- **개요** — 한 줄. bug → 원인 추정 / feature → 구상 / improve → 개선 방향
-- **대상 영역** — 한 줄. 추정 수준 (이 파일 / 모듈일 거다)
-- **슬러그** — 한국어 제목 → 영어 *의미 변환* → kebab-case (3 단어 이내, 음역 X). 예: *"로그인 빈 화면"* → `login-empty-page`
-
-> *코드 직접 탐색 금지*. 본 스킬은 *메모지 누적*만. 자동 추정 진행 X — 메타는 사용자 OK 또는 명백한 발화 매칭 후에만 추가.
-
-## 추가 + 보고
-
-`backlog_add` 도구로 추가한다 (MCP 도구 `backlog_add` 또는 동일 `npx @angar2/taskery backlog-add --type <t> --title <제목> --slug <slug> --summary <개요> --target <대상영역>`). 채번(BL-NNN)·서식·placeholder 치환·`withMetaLock` 직렬화·메인 워크트리 위치는 코드가 보장한다. 활성 plan BACKLOG.md 부재 시 도구가 에러를 반환한다 → *"`/plan-init` 먼저 호출해 활성 plan 디렉토리 + BACKLOG.md 생성 필요"* 안내 후 중단.
-
-성공 반환 `{ blNum, blId }`로 보고한다:
-
-```
-✅ BL-<NNN> [<유형>] <제목> — <NNN_slug> 백로그 추가됐어.
-   - 개요: <개요>
-   - 대상 영역: <대상 영역>
-   - 슬러그: <slug>
-다음: 진행 의향이면 *"BL-<NNN> 진행"*이라고 말해. `/task-init`이 메타 그대로 받아 워크트리를 분기하고 항목을 `[x]` 확인 마킹할게.
-```
-
-## 주의사항
-
-- **얕은 분석만** — 도메인 코드 Read · Grep 금지. 본격 분석은 `/task-plan`.
-- **글로벌 `.project/BACKLOG.md`(plan 기획 후보)와 혼동 X** — 본 스킬은 *활성 plan별*만. 글로벌은 `/plan-init` 영역.
-- **체크박스 의미** — `[ ]` = 미확인(메모) / `[x]` = 확인(task로 옮김). 부모 머지·완료 여부와 무관 — 완료 추적은 `taskery status` + 부모 머지커밋.
+- `backlog-add`

package/template/shared/skills/log-friction/SKILL.md

@@ -1,96 +1,18 @@
 ---
 name: log-friction
-description: 사용자가 작업 흐름 중 겪은 불편(friction)을 .project/FRICTION_LOG.md에 한 행 기록한다. 사용자가 짜증·불만·답답함을 표현하면 자동 발동(등록 제안). 명시 호출(`/log-friction`) 또는 `/task-close` 직후 마찰 신호 자체 감지 시에도 발동한다.
+description: 불편 기록 — 사용자가 taskery를 쓰다 겪은 불편을 .taskery/FRICTION_LOG.md에 한 줄로 남긴다(사용자가 부르거나 동의했을 때만)
 ---
 
-# /log-friction
+# log-friction
 
-## 개요
+taskery 불편 기록을 한 줄 남긴다. 명령 없이 파일에 직접 쓴다.
 
-사용자가 작업 흐름 중 겪은 불편을 `.project/FRICTION_LOG.md`에 한 행 기록한다.
-후속 조치 X — 분석 / 패턴 감지 / 룰 제안 자체를 본 스킬이 수행하지 않는다. 사용자가 직접 검토 후 판단한다.
+- taskery를 쓰다 사용자가 겪은 불편을 `.taskery/FRICTION_LOG.md`에 한 줄로 남긴다. 기록만 한다 — 분석·규칙 제안을 하지 않는다.
+- 부르는 때: 사용자가 직접 부를 때, 또는 사용자가 taskery 사용 중 불만을 말했을 때 "불편 기록에 남길까요?"라고 한 번 묻고 동의했을 때. AI 스스로 헤맨 것은 적지 않는다.
+- 파일이 없으면 만든다. 머리에 `# FRICTION_LOG`와 표 머리 `| 날짜 | 불편 | 맥락 |`를 둔다.
+- 표 끝에 `| YYYY-MM-DD | <사용자의 말을 되도록 그대로> | <태스크 번호·스킬·명령> |` 한 줄을 붙인다. 칸 구성은 바꾸지 않는다.
+- 붙인 줄을 사용자에게 보여 준다.
 
-## 호출 시점 (3가지 트리거)
+## 부르는 명령
 
-1. **사용자 명시 호출** — `/log-friction "<불편 내용>"` 또는 인자 없이 호출
-2. **사용자 불만 발화 캐치** — 메인 세션이 사용자 발화에서 불편·짜증·답답함 신호를 감지하면 *"이거 FRICTION_LOG에 등록할까?"* 제안한 후 사용자 OK 시 자동 발동
-3. **task-close 직후 메인 자체 감지** — 작업 중 마찰 신호(동일 단계 재호출 / 실패 반복 / 사용자 부정 반응 누적 등)가 감지된 경우에만 *"이번 task에서 X 부분이 마찰이었어 보여 — 등록할까?"* 제안한 후 사용자 OK 시 발동. 감지 신호 없으면 호출 X
-
-## 입력 처리
-
-- 인자 형태 (사용자 명시 호출):
-  - `/log-friction "<불편 내용>"` — 큰따옴표 인자에 본문 직접 전달
-  - `/log-friction` — 인자 없이 호출 시 메인이 사용자에게 *"어떤 점이 불편했는지?"* 묻고 답변을 받음
-- 자동 발동 시: 메인이 캐치한 발화 또는 감지한 마찰 신호를 사용자에게 *확인 차원*으로 보여주고 등록 본문에 대해 합의를 받음
-
-## 단계
-
-### Step 1 — 호출 경로 확인
-
-호출 형태에 따라 분기한다.
-
-- 직접 호출 (인자 있음) → 인자 본문을 등록 후보로 사용
-- 직접 호출 (인자 없음) → 사용자에게 불편 내용을 질문
-- 자동 발동 (불만 발화 캐치) → 캐치한 발화를 등록 후보로 보여주고 사용자 합의
-- 자동 발동 (task-close 자체 감지) → 감지한 마찰 신호를 보여주고 사용자 합의
-
-### Step 2 — 등록 본문 확정
-
-사용자가 합의한 내용을 한 행(1~3 문장 이내)으로 정리한다.
-
-포맷:
-
-```
-- YYYY-MM-DD | <맥락 — TASK 번호 또는 호출 시점> | <불편 내용 요약>
-```
-
-### Step 3 — FRICTION_LOG.md 한 행 추가
-
-`.project/FRICTION_LOG.md`를 Read한 후 마지막 행 다음에 신규 행을 Append(Edit)한다.
-
-**파일이 없으면 아래 골격을 먼저 Write한 후 첫 행을 작성한다.** (taskery는 이 파일을 배포하지 않는다 — 첫 기록 시점에 생긴다.)
-
-```markdown
-# FRICTION_LOG
-
-> 사용자가 작업 흐름 중 겪은 불편 / 한계 / 짚이는 부분의 누적.
-> `/log-friction` 스킬이 사용자 합의 후 한 행씩 추가한다.
-
-**사용 규칙**:
-- 한 행에 한 불편
-- 손수 편집 X — 메인이 대화로 적음
-- 사용자 명시 호출 / 사용자 불만 발화 캐치 / task-close 직후 마찰 신호 자체 감지 시 추가
-
----
-
-## 불편 누적
-
-| 날짜 | 불편 | 맥락 (어느 task / 스킬 / 카테고리) |
-|------|------|-----------------------------------|
-```
-
-### Step 4 — 결과 보고
-
-```
-✅ /log-friction 완료
-- 추가된 행: <등록 본문>
-- 누적 행 수: <N>건
-- 다음 호출: 사용자 명시 / 불만 발화 캐치 / task-close 자체 감지 중 하나
-```
-
-## 도구 가이드
-
-- **Read**: `.project/FRICTION_LOG.md` 정독
-- **Edit**: 마지막 행 다음에 신규 행 Append
-- **AskUserQuestion**: Step 1·2 사용자 합의
-
-## 주의사항
-
-- 본 스킬은 *기록 행위*만 수행한다. 패턴 분석 / PLAYBOOK 매핑 / 룰 제안 X.
-- task-close 자체 감지 트리거는 *마찰 신호 감지* 시에만 발동한다. 감지 없는 task-close에서 prompt 강제 X.
-- 사용자 합의 없이 자동 등록 X. 자동 발동 경로도 반드시 사용자 OK 후 기록한다.
-- 메인 자체 판단으로 등록 본문을 임의 가공·확장 X. 사용자 발화 또는 감지한 신호를 *그대로 인용* 원칙.
-
-## 상태 전이
-
-해당 없음 (meta 레벨 — task 상태 전이 X).
+- 없음

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

@@ -1,106 +1,18 @@
 ---
 name: plan-init
-description: plan(기능 그룹) 생성 — NNN 채번 폴더 + PLAN.md/ROADMAP.md + 제품 관통 문서(FEATURES/UX-UI) 의도 레벨 delta
+description: 플랜 추가 — 새 기능 묶음을 plan-init으로 만들고 PLAN.md에 목표와 태스크 목록(선행 태스크 포함)을 적는다
 ---
 
-# /plan-init
+# plan-init
 
-## 개요
+새 기능 묶음(플랜)을 더하는 단계다.
 
-plan(기능 그룹)마다 호출. **plan = 작업을 묶는 기능 그룹 단위** — 제품 전체 스냅샷(버전)이 아니다. 규모 가변(기능 그룹 하나가 보편, 첫 plan=MVP처럼 여러 그룹 묶음도 같은 흐름, 특례 없음).
+- 새 기능 묶음을 추가할 때 쓴다. 받은 기획 문서가 있으면 읽고, 없으면 핵심만 묻는다.
+- `plan-init <slug>`(제목은 `--title`) 명령으로 플랜 번호·폴더·`PLAN.md` 틀을 만든다.
+- `PLAN.md`에 목표와 태스크 목록을 적는다. 항목 한 줄 형식은 `<항목 번호>. <한 줄 설명> — 선행: <항목 번호들 또는 없음>`이다(명령이 이 형식을 읽고, 열린 태스크 번호를 줄 끝에 붙인다). 다른 태스크가 먼저 끝나야 하는 태스크는 선행 태스크 칸에 적는다. 같은 파일을 크게 만지는 태스크끼리도 순서를 두는 편이 낫다.
+- 이 기획이 바꾸는 제품 문서(`spec/`)만 고친다.
+- 만든 것과 태스크 목록을 보고한다.
 
-본 스킬이 만드는 것:
-- **plan 로컬(그룹 C)** — `.project/plans/<NNN_slug>/`에 `PLAN.md` + `ROADMAP.md`.
-- **제품 관통 문서(그룹 B) delta — 의도 레벨만** — `.project/FEATURES.md` / `.project/UX-UI.md`에 이 기능 그룹의 *섹션 헤더 + 의도 스텁* append.
+## 부르는 명령
 
-만들지 *않는* 것:
-- **제품 관통 문서 전체 생성** — 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은 빈 섹션 헤더만 둘 수 있다.
-
-## 호출 시점 + 입력
-
-- `/project-init` 직후 첫 plan(보통 MVP) 또는 새 기능 그룹 착수 시.
-- 인자 = plan slug (예: `/plan-init compare-products`). 없으면 *"어느 기능 그룹? slug 알려줘 (예: mvp, compare-products)"*. 한국어면 영어 *의미 변환* → kebab-case(공백 불가, 3 단어 이내).
-- **자투리는 plan 없이** — 단발 버그·오타·의존성 업데이트는 plan-init 없이 `/task-init`로 바로(무소속). 전역 TASK-NNN이 순서 보장.
-
-## 생성 (CLI — 채번+폴더+골격+활성 plan 갱신)
-
-`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) · **활성 plan 갱신**(`.taskery-manifest.json`의 `activePlan`). 성공 반환 `{ plan, nnn, planDir, tasksDir }` — 이후 단계는 이 `plan`(=`<NNN_slug>`) 사용. manifest 부재 시 에러 → *"`npx @angar2/taskery init` 먼저 실행 필요"* 안내 후 중단.
-
-**legacy 게이트** — `plans/`에 NNN 채번 아닌 폴더(구버전 `v1.0`/`alpha` 등) 잔존 시 `{gated:true, legacyDirs}`로 멈춘다(폴더 생성 X). 사용자 호출 + 경고: *"`plans/`에 NNN 채번 아닌 폴더(<legacyDirs>)가 있어. 새 plan을 NNN로 채번하면 활성 plan이 갈려 원래 문제 재발. 수동 이전(문서 루트 이동 + `NNN_slug` 리네임 + `plan-switch`로 활성 plan 갱신) 후 진행할지, 그래도 진행할지 결정해줘."* → 강행 시 `force:true`(CLI는 `--force`)로 재호출.
-
-> 폴더 생성·`tasks/<NNN_slug>/`·활성 plan 갱신은 코드가 완료 — 아래는 골격 placeholder를 *내용으로 채우는* 단계(LLM 판단)다.
-
-## ROADMAP.md 내용 채우기
-
-*현재 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>
-
-> 본 plan(기능 그룹) 한정 task 단계. Stage 단위(task 번호 강제 X), 상태 컬럼만 Living.
-> 프로젝트 거시 빌드 순서는 PROJECT.md, 다음 기능 그룹 후보는 글로벌 BACKLOG.md.
-
-## Stage 1 — <영역명>
-| 작업 단위 | 상태 |
-|-----------|------|
-| <한 task 분량 작업> | ⏳ 대기 |
-```
-
-## PLAN.md 내용 채우기 (얇은 인덱스 — 하드룰)
-
-PLAN.md는 *얇은 인덱스*다 — 이 기능 그룹이 건드린 루트 문서 요약 + task 체크리스트만.
-
-**하드룰 (중복 차단):**
-- **각 항목 = 루트 문서 섹션 *링크 1줄*. 본문 복제 금지.** 기능 상세는 `.project/` 루트 문서에만(단일 홈).
-- `## 활성 task 버전` 류 *자기선언 라인 작성 금지* — 활성 plan 단일 진실은 `.taskery-manifest.json`의 `activePlan`뿐(조회는 `status`, 전환은 `plan-switch`).
-
-```markdown
-# PLAN — <NNN_slug>
-
-> 이 plan(기능 그룹)의 얇은 인덱스. 각 항목은 루트 문서 섹션 링크 1줄 — 본문은 복제하지 않는다.
-
-## 이 기능 그룹이 건드리는 루트 문서
-- [FEATURES.md › <이 그룹 섹션>](../../FEATURES.md) — <한 줄 요약>
-- [UX-UI.md › <이 그룹 섹션>](../../UX-UI.md) — <한 줄 요약>
-- (DATA-MODEL / API-SPEC — task 진행이 구현 동반으로 채움)
-
-## task 체크리스트
-- [ ] <작업 단위> (ROADMAP Stage N)
-```
-
-## 제품 관통 문서(그룹 B) 의도 레벨 delta
-
-`.project/` 루트 문서에 이 기능 그룹의 *의도*를 명시한다. **의도 레벨만 — 상세 선작성 금지.**
-
-- **FEATURES.md / UX-UI.md (있을 때 필수)**: 이 기능 그룹의 *섹션 헤더 + 의도 스텁* append. **파일이 없으면**(=`/project-init` 미실행 또는 타입상 해당 없음) 새로 만들지 말고 이 항목을 생략한 뒤, CLI가 쓴 `PLAN.md` 골격의 해당 링크 줄도 지운다 — 없는 문서를 가리키는 링크가 남으면 이후 세션이 계속 헤맨다. "무엇 / 어떤 화면" — 구현 전에도 선언 가능(기능 그룹 기획의 본질). 섹션은 *기능/도메인 자기기술* — 어느 plan이 추가했는지 태그 X(기능 분류 = 제품 관통 문서 섹션 구조가 단일 진실).
-  ```markdown
-  ## <기능 그룹 이름>
-  <의도 1~3줄: 무엇을 / 누구를 위해 / 핵심 화면·동작. 상세 스펙은 task 진행에서.>
-  ```
-- **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)**: 이 그룹이 새 정책/스택/구조 도입 시만 수정. 도입 없으면 건너뜀.
-
-타입 조건부: project-init이 안 만든 문서(예: frontend의 DATA-MODEL)는 delta도 없음.
-
-## 결과 보고
-
-작성 산출물 목록 + 다음 단계:
-- *"`<NNN_slug>/` plan 생성 완료 — PLAN/ROADMAP + FEATURES/UX-UI 의도 stub. 활성 plan `<NNN_slug>` 갱신. 다음은 `/task-init`으로 첫 task (스키마/엔드포인트 상세는 task 진행에서 구현 동반)."*
-
-**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는 의도 레벨까지만** — DATA-MODEL/API-SPEC 스키마·엔드포인트 *본문 선작성 금지*. 상세는 구현 동반(task).
-- **제품 관통 문서에 plan 태그 금지** — 기능 섹션은 자기기술.
-- **PLAN.md 본문 복제 금지** — 각 항목 = 루트 문서 섹션 링크 1줄. `## 활성 task 버전` 자기선언 X.
-- **legacy 폴더 감지 시 진행 보류** — 사용자 confirm 전 새 plan 생성 금지.
-- 답 받기 전 자동 추정 진행 X. 단 PROJECT.md/기존 루트 문서로 *제안*은 OK(confirm 후).
+- `plan-init`