uctm 1.5.4 → 2.0.0

package/references/xml-schema.md

@@ -4,10 +4,12 @@ uc-taskmanager 에이전트용 XML 통신 형식 정의.
 
 ---
 
-## 1. Dispatch 형식 (디스패처 → 수신자)
+> **디스패처 라벨**: dispatch를 발신하고 task-result를 수신하는 디스패처 역할은 **orchestrator**가 수행한다. 아래 §1/§2의 "디스패처"는 모두 orchestrator를 가리킨다.
+
+## 1. Dispatch 형식 (orchestrator → 수신자)
 
 ```xml
-<dispatch to="{receiver}" work="{WORK_ID}" task="{TASK_ID}" execution-mode="{direct|pipeline|full}">
+<dispatch to="{receiver}" work="{WORK_ID}" task="{TASK_ID}">
   <ref-cache>                                        <!-- 선택사항 -->
     <ref key="shared-prompt-sections">{파일 내용}</ref>
     <ref key="file-content-schema">{파일 내용}</ref>
@@ -36,13 +38,12 @@ uc-taskmanager 에이전트용 XML 통신 형식 정의.
 
 | 속성 | 값 |
 |------|-----|
-| `to` | builder, verifier, committer, planner, scheduler, specifier |
+| `to` | builder, verifier, committer, planner, specifier |
 | `task` | `TASK-NN` — WORK 접두사 포함 금지 |
-| `execution-mode` | direct / pipeline / full (생략 시 full 기본값) |
 
 ---
 
-## 2. Task Result 형식 (수신자 → 디스패처)
+## 2. Task Result 형식 (수신자 → orchestrator)
 
 ```xml
 <task-result work="{WORK_ID}" task="{TASK_ID}" agent="{agent}" status="{PASS|FAIL}">
@@ -118,3 +119,99 @@ uc-taskmanager 에이전트용 XML 통신 형식 정의.
 - `<ref-cache>` 없는 dispatch 또는 task-result XML은 완전히 유효 — 에이전트는 `REFERENCES_DIR`에서 파일을 읽는 것으로 폴백.
 - ref-cache를 아직 지원하지 않는 에이전트는 해당 요소를 무시하고 정상적으로 파일을 읽음.
 - 부분적 ref-cache (일부 키만 존재)도 허용 — 없는 키는 디스크에서 읽음.
+
+---
+
+## 5. Gate 요소 (orchestrator → Main Claude)
+
+`<gate>`는 orchestrator가 자율 실행을 일시 정지하고 Main Claude(및 사용자)의 승인 또는 결정을 요청할 때 반환하는 정지 신호입니다. orchestrator는 `<gate>`를 반환한 뒤 Main Claude의 응답(승인 또는 `<decision>`)이 돌아올 때까지 재개하지 않습니다.
+
+### type="stage" — 단계 완료 승인 게이트
+
+```xml
+<gate type="stage" work="WORK-12" stage="specifier">
+  <summary>Requirement.md 작성 완료. FR 6건, NFR 2건 도출.</summary>
+  <next-stage>planner</next-stage>
+</gate>
+```
+
+### type="decision" — 결정 필요 게이트
+
+```xml
+<gate type="decision" work="WORK-12" stage="planner">
+  <context>인증 방식으로 세션 기반과 JWT 중 선택이 필요합니다. 기존 코드베이스는 세션 기반이나 신규 마이크로서비스 확장 계획이 있습니다.</context>
+  <options>
+    <option id="1">세션 기반 유지 (기존 컨벤션 일치)</option>
+    <option id="2">JWT 전환 (확장성 우선)</option>
+  </options>
+  <recommended>option 1 — 현재 스코프에서는 확장 계획이 확정되지 않아 리스크가 낮은 세션 기반 유지를 권고</recommended>
+</gate>
+```
+
+| 속성 | 값 |
+|------|-----|
+| `type` | `stage`(단계 완료 승인 요청) / `decision`(선택 필요) |
+| `work` | `WORK_ID` |
+| `stage` | 현재 정지된 단계: `specifier`/`planner`/`builder`/`verifier`/`committer` |
+
+- `type="decision"`은 `<context>`(배경 — 왜 결정이 필요한가), `<options>`(선택지 목록), `<recommended>`(권고안)을 하위 요소로 반드시 포함한다.
+- Main Claude는 `<gate>` 수신 시 사용자에게 승인/선택을 구하고, 결과를 `<decision>`(§ 7)으로 orchestrator에 재전달하여 재개시킨다.
+- 게이트 정지는 활동 로그의 `GATE_WAIT`(stage 게이트) 또는 `DECISION_WAIT`(decision 게이트) 이벤트와 짝을 이룬다 → `work-activity-log.md` 참조.
+
+---
+
+## 6. needs-decision 요소 (자식 에이전트 → orchestrator)
+
+`<needs-decision>`은 자식 에이전트(builder/verifier 등)가 구현 중 스스로 결정할 수 없는 사항을 발견했을 때, task-result와 함께(또는 대신) orchestrator에 상향 보고하는 신호입니다. Main Claude로 직접 올라가지 않고 먼저 orchestrator가 받는다는 점에서 `<gate type="decision">`과 구분됩니다.
+
+```xml
+<needs-decision work="WORK-12" task="TASK-03" agent="builder">
+  <context>TASK 스펙에 명시되지 않은 에러 응답 포맷이 필요합니다. 기존 엔드포인트는 두 가지 포맷이 혼재합니다.</context>
+  <options>
+    <option id="1">엔드포인트 A 방식(`{error: string}`)에 통일</option>
+    <option id="2">엔드포인트 B 방식(`{code, message}`)에 통일</option>
+  </options>
+  <recommended>option 2 — 신규 API 표준에 부합</recommended>
+</needs-decision>
+```
+
+| 속성 | 값 |
+|------|-----|
+| `work` | `WORK_ID` |
+| `task` | `TASK_ID` |
+| `agent` | 신호를 발생시킨 자식 에이전트 |
+
+- orchestrator는 `<needs-decision>` 수신 시 자동 결정 가능 여부를 판단한다.
+  - 자동 결정 가능 → `<decision by="auto">`(§ 7)로 확정하고 자식 작업을 재개시킴.
+  - 자동 결정 불가 → `<gate type="decision">`(§ 5)으로 승격하여 Main Claude에 전달.
+- 어느 경로든 결정 내용은 `works/{WORK_ID}/DECISIONS.md`에 기록된다 → `file-content-schema.md` § 4 참조.
+
+---
+
+## 7. decision 요소 (확정 결정 기록)
+
+`<decision>`은 게이트(§ 5) 또는 needs-decision(§ 6)에 대해 내려진 확정 결정을 기록하는 요소입니다. 사용자 승인분(`by="user"`)과 orchestrator 자동결정분(`by="auto"`)이 동일한 형식을 공유합니다.
+
+```xml
+<decision work="WORK-12" stage="planner" by="user">
+  <context>인증 방식으로 세션 기반과 JWT 중 선택이 필요했음.</context>
+  <chosen>세션 기반 유지</chosen>
+  <rationale>기존 컨벤션과의 일치를 우선함</rationale>
+</decision>
+```
+
+```xml
+<decision work="WORK-12" task="TASK-03" by="auto">
+  <context>에러 응답 포맷 불일치 — builder의 needs-decision.</context>
+  <chosen>엔드포인트 B 방식(`{code, message}`)에 통일</chosen>
+  <rationale>신규 API 표준과 일치, 리스크 낮음</rationale>
+</decision>
+```
+
+| 속성 | 값 |
+|------|-----|
+| `work` | `WORK_ID` |
+| `stage` / `task` | 결정이 발생한 단계 또는 TASK (해당하는 것 사용) |
+| `by` | `user`(사용자 승인) / `auto`(orchestrator 자동결정) |
+
+- orchestrator는 `<decision>` 확정 즉시 `works/{WORK_ID}/DECISIONS.md`의 해당 항목을 `PENDING → RESOLVED`로 갱신하고, 활동 로그에 `DECISION` 이벤트를 기록한다 → `work-activity-log.md` 참조.

package/skills/sdd-pipeline/SKILL.md

@@ -1,6 +1,6 @@
 # sdd-pipeline references
 
-파이프라인 에이전트(specifier, planner, scheduler, builder, verifier, committer)가 참조하는 규칙/스키마 문서 모음.
+파이프라인 에이전트(orchestrator, specifier, planner, builder, verifier, committer)가 참조하는 규칙/스키마 문서 모음.
 
 직접 사용자 호출용이 아니라 에이전트 내부 참조용입니다.
 

package/skills/uctm-init/SKILL.md

@@ -61,8 +61,7 @@ works/가 없으면:
   "Bash(python:*)",
   "Bash(ruff:*)",
   "Bash(make:*)",
-  "Bash(git:*)",
-  "Bash(curl:*)"
+  "Bash(git:*)"
 ]
 ```
 

package/skills/work-pipeline/SKILL.md

@@ -13,12 +13,11 @@ description: Triggers the WORK-PIPELINE. Use this skill when
 - `[new-feature]`, `[enhancement]`, `[bugfix]`, `[new-work]`, `[WORK start]`
 - 또는 대괄호 안의 커스텀 태그
 
-`../../references/agent-flow.md`를 읽고 오케스트레이션 흐름을 따릅니다.
-
 **WORK 재개** — 메시지에 기존 WORK-ID와 실행 의도가 있을 때:
 - "WORK-XX 계속실행", "WORK-XX 실행", "resume WORK-XX", "continue WORK-XX"
 - "파이프라인 재개", "WORK 계속"
-- → agent-flow.md § 기존 WORK 재개 따르기
+
+두 경우 모두 아래 "오케스트레이션 흐름"을 따릅니다.
 
 ## References Directory (CRITICAL)
 
@@ -29,34 +28,36 @@ description: Triggers the WORK-PIPELINE. Use this skill when
 REFERENCES_DIR = {Base directory}/../../references
 ```
 
-**모든 서브에이전트 호출**(specifier, planner, scheduler, builder, verifier, committer)에 이 절대 경로를 반드시 전달해야 합니다.
-프롬프트 텍스트 상단에 포함:
+`orchestrator` spawn 시 이 절대 경로를 반드시 전달해야 합니다. orchestrator가 레퍼런스 파일을 찾기 위해 이 경로가 필요합니다. 없으면 파일을 찾지 못하고 루프에 빠집니다.
 
-```
-REFERENCES_DIR={absolute_path}
-```
+## Auto 모드 감지
 
-서브에이전트가 레퍼런스 파일을 찾기 위해 이 경로가 필요합니다. 없으면 파일을 찾지 못하고 루프에 빠집니다.
+사용자의 메시지에 "auto" 또는 "자동으로"가 포함되면 **auto 모드**로 spawn합니다. 그 외에는 **gated 모드**(기본값)로 spawn합니다.
 
-## 파이프라인 흐름
+## 오케스트레이션 흐름
 
-1. **specifier 에이전트 spawn** (Agent 도구 사용) — 요구사항 분석, `works/WORK-NN/Requirement.md` 생성, execution-mode 결정 (direct/pipeline/full)
-2. **⛔ 정지 — specifier의 출력 요약을 사용자에게 제시하고 명시적 승인 대기.** 사용자가 승인할 때까지 다음 에이전트를 호출하지 말 것. 생성된 내용(Requirement.md, direct 모드면 PLAN.md, TASK 파일)을 보여주고 "진행할까요?" 질문
-3. **specifier가 반환한 execution-mode에 따라 진행:**
-   - `direct`: builder spawn → verifier spawn → committer spawn
-   - `pipeline`: planner spawn → 각 TASK에 대해 → builder spawn → verifier spawn → committer spawn
-   - `full`: planner spawn → **⛔ 2차 승인 정지** → scheduler spawn → 각 TASK에 대해 → builder spawn → verifier spawn → committer spawn
+Main Claude는 `orchestrator` 에이전트 하나만 spawn합니다. specifier/planner/builder/verifier/committer는 orchestrator가 내부에서 중첩 spawn(TASK DAG 스케줄링 포함)하므로 Main Claude가 직접 호출하지 않습니다.
 
-## ⚠️ CRITICAL: 에이전트 Spawn 규칙
+### Gated 모드 (기본값 — "auto"/"자동으로" 없음)
+
+1. **최초 spawn**: `orchestrator`를 `mode=gated`로 spawn. 프롬프트 상단에 `REFERENCES_DIR=...`와 `mode=gated`를 포함하고, 사용자 요청 원문(및 재개 시 `WORK_ID`)을 전달. 반환된 **agentId를 보관**한다(다음 재개에 사용).
+2. **`<gate>` 수신 시 정지**: orchestrator가 `<gate type="stage">`(고정 게이트: specifier 완료 후 / planner 완료 후) 또는 `<gate type="decision">`(동적 의사결정)을 반환하면 orchestrator는 그 자리에서 yield(파킹)한 상태다.
+   - `type="stage"`: `<summary>`를 사용자에게 제시하고 진행 승인을 요청.
+   - `type="decision"`: `<context>`/`<options>`/`<recommended>`를 **AskUserQuestion**으로 제시해 사용자 선택을 받는다.
+3. **재개**: 사용자의 승인 또는 결정을 **`SendMessage(agentId, 결정내용)`으로 orchestrator에 전달해 재개**한다(컨텍스트 유지). agentId가 유실되었거나 SendMessage가 실패하면(세션 종료, 크로스세션 등) 로그(`work_{WORK}.log`) 기반으로 orchestrator를 **re-spawn**하는 폴백을 사용한다 — 이 경우도 재개 지정은 name이 아니라 **agentId**(또는 재-spawn 결과의 새 agentId)로 한다.
+4. **반복**: 2~3을 orchestrator가 최종 WORK 요약을 반환할 때까지 반복한다.
+5. **종료**: orchestrator가 최종 요약(`## 자동 결정 사항` 포함)을 반환하면 사용자에게 제시하고, **`TaskStop(agentId)`으로 orchestrator를 종료**한다.
 
-- **모든 에이전트는 Agent 도구를 통해 spawn해야 합니다.** Main Claude가 직접 코드 구현, 파일 생성, git 명령 실행 또는 에이전트의 작업을 수행하면 안 됩니다.
-- specifier가 builder dispatch XML을 반환하면 builder 에이전트에 전달할 것 — 직접 실행하지 말 것.
+### Auto 모드 ("auto"/"자동으로" 포함)
 
-## Auto 모드
+1. `orchestrator`를 `mode=auto`로 **1회만 spawn**. 프롬프트 상단에 `REFERENCES_DIR=...`와 `mode=auto`를 포함.
+2. 게이트/의사결정 정지 없이 orchestrator가 전체 파이프라인을 완주하고 최종 요약(`## 자동 결정 사항` 포함)을 반환한다.
+3. 반환된 최종 요약을 사용자에게 제시한다. (파킹 상태가 아니므로 TaskStop 불필요.)
 
-사용자의 메시지가 "auto" 또는 "자동으로"로 끝나면, 모든 승인 단계를 건너뛰고 전체 파이프라인을 자동 실행합니다. 승인 게이트를 건너뛸 수 있는 유일한 경우입니다.
+## ⚠️ CRITICAL: 에이전트 Spawn 규칙
 
-Auto 모드 감지 시, 모든 서브에이전트 프롬프트에 "auto"를 포함합니다.
+- Main Claude가 spawn하는 에이전트는 **orchestrator 하나뿐**이다. Main Claude가 직접 코드 구현, 파일 생성, git 명령 실행 또는 orchestrator의 작업을 수행하면 안 된다.
+- 게이트 재개는 항상 **agentId** 기준(SendMessage/TaskStop 모두)으로 한다 — name 재사용에 의한 오배달을 방지한다.
 
 ## Arguments
 

package/.agent/router_rule_config.json

@@ -1,47 +0,0 @@
-{
-  "$schema": "http://uc-taskmanager.local/schemas/router-rules/v1.0.json",
-  "version": "1.1.0",
-  "description": "Router execution-mode 판정 기준 설정. 프로젝트별로 이 파일을 수정하여 라우팅 기준을 커스터마이즈한다.",
-  "decision_flow": [
-    "1. build_test_required 여부 판단 → false이면 direct",
-    "2. single_domain + sequential DAG → pipeline",
-    "3. 아래 full_conditions 중 하나라도 해당 → full"
-  ],
-  "rules": {
-    "direct": {
-      "description": "Router 단독 처리 — 빌드/테스트 검증 불필요, 서브에이전트 0",
-      "criteria": {
-        "build_test_required": false,
-        "note": "파일 수·줄 수 무관. 검증 없이 끝나는 작업이면 direct (텍스트 편집, 설정 변경, 단순 치환 등)"
-      }
-    },
-    "pipeline": {
-      "description": "Builder → Verifier → Committer 단일 흐름 — Builder 1회 호출",
-      "criteria": {
-        "build_test_required": true,
-        "single_domain_only": true,
-        "max_tasks": 5,
-        "dag_complexity": "sequential",
-        "note": "빌드/테스트 필요하지만 단일 도메인(BE만 또는 FE만)이고 한 흐름으로 처리 가능한 경우"
-      }
-    },
-    "full": {
-      "description": "Planner → Scheduler → [Builder → Verifier → Committer] × N",
-      "criteria": {
-        "any_of": [
-          "task_count > 5",
-          "dag_complexity == complex (TASK 간 의존성이 2레벨 이상)",
-          "multi_domain == true (BE + FE 동시 변경)",
-          "new_module == true (신규 모듈/기능 — 설계→구현→검증 다단계)",
-          "partial_rollback_needed == true (TASK 실패 시 부분 롤백 필요)"
-        ],
-        "note": "Builder를 여러 번 독립 호출해야 안전한 규모"
-      }
-    }
-  },
-  "customization_guide": {
-    "uc-taskmanager형 프로젝트 (md 편집 중심)": "direct 범위를 넓게. build_test_required=false인 경우 대부분 direct 처리",
-    "uc-teamspace형 프로젝트 (코드 개발 중심)": "pipeline/full 중심. 단순 버그 수정은 pipeline, 멀티도메인 기능은 full",
-    "max_tasks 조정": "팀 규모나 컨텍스트 한계에 따라 pipeline의 max_tasks를 3~7 사이로 조정 가능"
-  }
-}

package/agents/scheduler.md

@@ -1,152 +0,0 @@
----
-name: scheduler
-description: Agent that manages the TASK dependency DAG for a specific WORK and executes the pipeline. Reads the WORK's PLAN.md and dispatches builder → verifier → committer sequentially according to dependency order.
-tools: Read, Write, Edit, Bash, Glob, Grep, Task
-model: haiku
----
-
-# 1. 역할
-
-당신은 **Scheduler** — WORK 파이프라인 실행 에이전트입니다.
-
-- 대상 WORK의 TASK 의존성 DAG를 분석하고 READY 순서대로 파이프라인 실행
-- 각 TASK에 대해 builder → verifier → committer를 순차적으로 디스패치
-- WORK의 모든 TASK가 완료될 때까지 실행을 반복하며 진행 상황 추적
-
----
-
-# 2. 수행업무
-
-| 업무 | 설명 |
-|------|------|
-| WORK 식별 | 사용자 요청에서 WORK_ID 파싱; 없으면 미완료 WORK 자동 감지 |
-| DAG 해석 | 각 TASK의 완료 상태와 의존성을 확인하여 READY 목록 결정 |
-| Builder 디스패치 | READY TASK를 builder 서브에이전트에 디스패치 |
-| Verifier 디스패치 | builder 결과를 verifier에 전달하여 검증 |
-| Committer 디스패치 | verifier 승인 결과를 committer에 전달하여 커밋 |
-| 재시도 처리 | FAIL 시 builder에 최대 3회 재디스패치 |
-
----
-
-# 3. 수행 절차
-
-## 3-1. 사전작업
-
-### STEP 1. STARTUP — 레퍼런스 파일 즉시 읽기 (필수)
-
-**REFERENCES_DIR 확인**: 입력에서 `REFERENCES_DIR=...` 라인을 확인. 해당 절대 경로 사용. 없으면 `.claude/references`를 기본값으로 사용.
-
-`{REFERENCES_DIR}/`에서 다음 파일을 읽기: 
-1. `file-content-schema.md`
-2. `shared-prompt-sections.md`
-3. `xml-schema.md`
-4. `work-activity-log.md`
-5. `callback-protocol.md`
-6. `context-policy.md`
-
-### STEP 2. 콜백 START + 활동 로그 START
-
-- 활동 로그: `work-activity-log.md`를 참조하여 START 기록
-- 콜백: `callback-protocol.md`를 참조하여 START Callback 전송
-
-## 3-2. 파이프라인 실행
-
-### STEP 1. WORK 식별 및 초기 로드
-
-→ 미완료 WORK 자동 감지: `shared-prompt-sections.md` § 4 참조
-
-초기 상태 로드:
-
-```
-Use Read tool: "works/${WORK_ID}/PLAN.md"
-Use Read tool: "works/${WORK_ID}/work_${WORK_ID}.log" (마지막 몇 줄)
-```
-
-### STEP 2. DAG 해석
-
-→ 상태 판정: `shared-prompt-sections.md` § 4 참조
-
-```
-work_${WORK_ID}.log의 마지막 줄 읽기:
-  COMMITTER_DONE — TASK-NN → TASK-NN 완료, 다음 TASK 확인
-  로그 없음 또는 PLANNER_DONE    → 모든 TASK가 대기 중
-
-각 TASK에 대해:
-  해당 TASK의 COMMITTER_DONE이 로그에 존재 → DONE
-  모든 의존성이 DONE → READY
-  그 외 → BLOCKED
-
-READY TASK: 오름차순 번호 순서로 실행
-```
-
-해당 WORK 내의 TASK만 처리. 다른 WORK 접근 금지.
-
-### STEP 3. Builder 디스패치
-
-→ dispatch XML 형식: `xml-schema.md` § 1 참조 (to="builder", action="implement")
-
-아래 dispatch XML을 생성하여 반환. **호출은 Main Claude가 수행.**
-
-### STEP 4. Verifier 디스패치
-
-FAIL → builder 재시도 (최대 3회). 3회 실패 → 파이프라인 중단.
-
-→ dispatch XML 형식: `xml-schema.md` § 1 참조 (to="verifier", action="verify")
-→ Sliding Window (Builder→Verifier): `context-policy.md` Scheduler Dispatch 섹션 참조
-
-아래 dispatch XML을 생성하여 반환. **호출은 Main Claude가 수행.**
-
-### STEP 5. Committer 디스패치
-
-→ dispatch XML 형식: `xml-schema.md` § 1 참조 (to="committer", action="commit")
-→ Sliding Window (Verifier FULL + Builder SUMMARY): `context-policy.md` Scheduler Dispatch 섹션 참조
-→ TASK 간 의존성 전달: `context-policy.md` Inter-TASK Dependency Transfer 섹션 참조
-
-### STEP 6. Committer FAIL 재시도:
-
-1. FAIL task-result에서 `<reason>` 읽기
-2. builder에 재디스패치
-3. 최대 2회 재시도 (총 3회 시도). 3회 실패 → TASK FAILED 표시, 파이프라인 중단
-
-## 3-3. 제약사항 및 금지사항
-
-### 실행 범위
-- 지정된 WORK 내의 TASK만 실행
-- 다른 WORK의 TASK를 혼합하지 말 것
-- TASK가 1개뿐인 단순한 WORK라도 builder → verifier → committer 파이프라인 필수
-- 파이프라인 우회 시 활동 로그 항목 누락 → WORK 완료 인식 실패
-
-## 3-4. 출력 형식
-
-### 출력 규칙
-- dispatch XML 또는 진행 보고 **만** 반환. 앞뒤에 요약, 설명, 부연을 추가하지 말 것.
-- 출력 시간을 최소화하기 위해 최대한 간결하게 반환.
-
-### 진행 보고
-
-TASK 완료 후 상태 출력 (진행 상황은 활동 로그에서 추적):
-
-```
-✅ TASK-XX 완료 — commit: {hash}
-📊 {WORK_ID}: {done}/{total}
-🔓 다음: TASK-YY
-⏳ 대기: TASK-ZZ (TASK-YY 완료 후)
-```
-
-전체 WORK 완료 시:
-
-```
-🎉 {WORK_ID} 완료!
-   총: {N}개 task, {N}개 commit
-```
-
-다중 WORK 상태 확인: → `shared-prompt-sections.md` § 4 참조
-
-## 4. 결과물 생성 및 작업완료 절차
-
-- 활동 로그: `work-activity-log.md`를 참조하여 DONE 기록
-- 콜백: `callback-protocol.md`를 참조하여 DONE Callback 전송
-
-## 5. 결과 보고
-
-정의된 역할을 모두 끝내면 Main Claude에 보고하고 종료

package/references/callback-protocol.md

@@ -1,40 +0,0 @@
-# 콜백
-
-각 에이전트가 CE7 API를 통해 서버에 START/DONE/FAILED 이벤트를 전송
-
-**활성화 조건:** 
-1. CLAUDE.md에 Callback_URL 이 설정된 경우
-2. 설정정보가 없을 경우 **모든 콜백 생략**
-
-**CALLBACK_URL 및 CALLBACK_TOKEN 확인 방법:**
-1. CLAUDE.md에 Callback_URL 및 Callback_TOKEN 확인
-
-**전송 시점:**
-- **START**: 에이전트 실행 시작 시 (STARTUP 이후)
-- **DONE**: 맨 마지막, task-result XML 반환 직전
-- **FAILED**: 복구 불가능한 실패 시, FAIL task-result 반환 직전
-
-**전송 방법** (단일 curl 명령):
-```bash
-curl -s --connect-timeout 3 --max-time 5 -X POST "$CALLBACK_URL" \
-  -H "Authorization: Bearer $CALLBACK_TOKEN" \
-  -H "Content-Type: application/json" \
-  -d '{"stage":"BUILDER","event":"START","workId":"WORK-09","taskId":"TASK-01"}' \
-  2>/dev/null || true
-```
-
-- `--connect-timeout 3`: 연결 대기 최대 3초
-- `--max-time 5`: 전체 요청 최대 5초
-- `|| true`: 실패해도 에이전트 실행 계속
-
-**Agent별 docs 포함 (실제 파일 내용을 포함해야함):**
-- specifier DONE: `"docs": {"requirementContent": "<Requirement.md 내용>"}`
-- planner DONE: `"docs": {"planContent": "<PLAN.md 내용>"}`
-- builder START: `"docs": {"taskContent": "<TASK-NN.md 내용>"}`
-- committer DONE: `"docs": {"resultContent": "<TASK-NN_result.md 내용>"}`
-
-**토큰 사용량** (DONE 이벤트에 추가):
-```json
-{"inputTokens": 1234, "outputTokens": 567, "cacheCreationTokens": 890, "cacheReadTokens": 456}
-```
-콜백 실패 시 계속 진행.

package/skills/init/SKILL.md

@@ -1,95 +0,0 @@
----
-name: uctm-init
-description: Initialize uc-taskmanager for the current project. Creates works/ directory and configures Bash permissions in .claude/settings.local.json. Use when the user says "uctm init", "initialize uctm", "uctm 초기화", or "초기화".
----
-
-# uc-taskmanager 초기화
-
-현재 프로젝트를 uc-taskmanager 파이프라인 실행을 위해 초기화합니다.
-
-## 단계
-
-### 1. works/ 디렉토리 생성
-
-```
-works/가 없으면:
-  works/ 생성
-  보고: ✓ works/ 디렉토리 생성됨
-아니면:
-  보고: - works/ 이미 존재
-```
-
-### 2. Bash 권한 설정
-
-**먼저 사용자에게 확인:** "에이전트에 필요한 Bash 권한을 .claude/settings.local.json에 자동 설정할까요? (recommended) [Y/n]"
-
-사용자가 승인하면 (yes/Y/확인):
-
-`.claude/settings.local.json` 읽기 (없으면 생성). 다음 권한을 `permissions.allow` 배열에 병합 — **이미 있는 것은 건너뛰기** (중복 금지):
-
-```json
-[
-  "Read(/**)",
-  "Edit(/**)",
-  "Write(/**)",
-  "Read(**)",
-  "Edit(**)",
-  "Write(**)",
-  "Bash(ls:*)",
-  "Bash(cat:*)",
-  "Bash(mkdir:*)",
-  "Bash(basename:*)",
-  "Bash(find:*)",
-  "Bash(wc:*)",
-  "Bash(sort:*)",
-  "Bash(tail:*)",
-  "Bash(head:*)",
-  "Bash(echo:*)",
-  "Bash(printf:*)",
-  "Bash(grep:*)",
-  "Bash(sed:*)",
-  "Bash(cut:*)",
-  "Bash(tr:*)",
-  "Bash(node:*)",
-  "Bash(npm run:*)",
-  "Bash(npm test:*)",
-  "Bash(bun run:*)",
-  "Bash(yarn:*)",
-  "Bash(cargo:*)",
-  "Bash(go build:*)",
-  "Bash(go test:*)",
-  "Bash(python:*)",
-  "Bash(ruff:*)",
-  "Bash(make:*)",
-  "Bash(git:*)",
-  "Bash(curl:*)"
-]
-```
-
-기존 `permissions.allow` 및 `permissions.deny` 항목을 보존하고 누락된 것만 추가.
-
-```
-권한 추가됨:
-  보고: ✓ {N}개 권한이 .claude/settings.local.json에 추가됨 (총: {T})
-사용자가 건너뛰면:
-  보고: - 권한 설정 건너뜀
-이미 모두 설정됨:
-  보고: - 모든 권한이 이미 설정됨
-```
-
-### 3. 요약
-
-모든 단계 완료 후 요약 표시:
-
-```
-uc-taskmanager 초기화 완료!
-
-  ✓ works/ 디렉토리 준비됨
-  ✓ Bash 권한 설정됨
-
-  다음: [new-feature] Add a hello world feature 입력
-```
-
-## Arguments
-
-$ARGUMENTS