uctm 1.5.3 → 2.0.0

package/references/xml-schema.md

@@ -1,120 +1,217 @@
-# Agent Communication XML Schema
+# 에이전트 통신 XML 스키마
 
-XML communication format definition for uc-taskmanager agents.
+uc-taskmanager 에이전트용 XML 통신 형식 정의.
 
 ---
 
-## 1. Dispatch Format (Dispatcher → Receiver)
+> **디스패처 라벨**: 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}">
-  <ref-cache>                                        <!-- optional -->
-    <ref key="shared-prompt-sections">{file content}</ref>
-    <ref key="file-content-schema">{file content}</ref>
-    <ref key="xml-schema">{file content}</ref>
-    <ref key="context-policy">{file content}</ref>
-    <ref key="work-activity-log">{file content}</ref>
+<dispatch to="{receiver}" work="{WORK_ID}" task="{TASK_ID}">
+  <ref-cache>                                        <!-- 선택사항 -->
+    <ref key="shared-prompt-sections">{파일 내용}</ref>
+    <ref key="file-content-schema">{파일 내용}</ref>
+    <ref key="xml-schema">{파일 내용}</ref>
+    <ref key="context-policy">{파일 내용}</ref>
+    <ref key="work-activity-log">{파일 내용}</ref>
   </ref-cache>
-  <references-dir>{absolute path to references directory}</references-dir>
+  <references-dir>{references 디렉토리 절대 경로}</references-dir>
   <context>
-    <project>{project name}</project>
+    <project>{프로젝트 이름}</project>
     <language>{lang_code}</language>
     <plan-file>works/{WORK_ID}/PLAN.md</plan-file>
   </context>
   <task-spec>
     <file>works/{WORK_ID}/TASK-XX.md</file>
-    <title>{title}</title>
+    <title>{제목}</title>
     <action>{implement|verify|commit|plan|route}</action>
-    <description>{optional}</description>
+    <description>{선택사항}</description>
   </task-spec>
   <previous-results>
-    <result task="{TASK_ID}" status="{PASS|FAIL|SKIP}">{summary}</result>
+    <result task="{TASK_ID}" status="{PASS|FAIL|SKIP}">{요약}</result>
   </previous-results>
   <cache-hint sections="{section1},{section2}"/>
 </dispatch>
 ```
 
-| Attribute | Value |
-|-----------|-------|
-| `to` | builder, verifier, committer, planner, scheduler, specifier |
-| `task` | `TASK-NN` — WORK prefix must NOT be included |
-| `execution-mode` | direct / pipeline / full (defaults to full if omitted) |
+| 속성 | 값 |
+|------|-----|
+| `to` | builder, verifier, committer, planner, specifier |
+| `task` | `TASK-NN` — WORK 접두사 포함 금지 |
 
 ---
 
-## 2. Task Result Format (Receiver → Dispatcher)
+## 2. Task Result 형식 (수신자 → orchestrator)
 
 ```xml
 <task-result work="{WORK_ID}" task="{TASK_ID}" agent="{agent}" status="{PASS|FAIL}">
-  <summary>{1-2 line summary}</summary>
+  <summary>{1-2줄 요약}</summary>
   <files-changed>
-    <file action="{created|modified|deleted}" path="{path}">{description}</file>
+    <file action="{created|modified|deleted}" path="{path}">{설명}</file>
   </files-changed>
   <verification>
-    <check name="{type}" status="{PASS|FAIL|N/A}">{output}</check>
+    <check name="{type}" status="{PASS|FAIL|N/A}">{출력}</check>
   </verification>
-  <notes>{notes}</notes>
-  <ref-cache>                                        <!-- optional -->
-    <ref key="shared-prompt-sections">{file content}</ref>
-    <ref key="file-content-schema">{file content}</ref>
-    <ref key="xml-schema">{file content}</ref>
-    <ref key="context-policy">{file content}</ref>
-    <ref key="work-activity-log">{file content}</ref>
+  <notes>{메모}</notes>
+  <ref-cache>                                        <!-- 선택사항 -->
+    <ref key="shared-prompt-sections">{파일 내용}</ref>
+    <ref key="file-content-schema">{파일 내용}</ref>
+    <ref key="xml-schema">{파일 내용}</ref>
+    <ref key="context-policy">{파일 내용}</ref>
+    <ref key="work-activity-log">{파일 내용}</ref>
   </ref-cache>
 </task-result>
 ```
 
 ---
 
-## 3. Context-Handoff Element
+## 3. Context-Handoff 요소
 
 ```xml
 <context-handoff from="{agent}" detail-level="{FULL|SUMMARY|DROP}">
-  <what>{changes/verification details}</what>
-  <why>{decision rationale}</why>       <!-- FULL only -->
-  <caution>{caveats}</caution>          <!-- FULL only -->
-  <incomplete>{incomplete items}</incomplete>  <!-- FULL only -->
+  <what>{변경/검증 상세}</what>
+  <why>{결정 근거}</why>       <!-- FULL만 -->
+  <caution>{주의사항}</caution>          <!-- FULL만 -->
+  <incomplete>{미완료 항목}</incomplete>  <!-- FULL만 -->
 </context-handoff>
 ```
 
-| detail-level | Included Fields |
+| detail-level | 포함 필드 |
 |:---:|---|
 | `FULL` | what, why, caution, incomplete |
-| `SUMMARY` | what only (1-3 lines) |
-| `DROP` | Element omitted |
+| `SUMMARY` | what만 (1-3줄) |
+| `DROP` | 요소 생략 |
 
 ---
 
-## 4. ref-cache Element Definition
+## 4. ref-cache 요소 정의
 
-`<ref-cache>` is an optional container element that carries pre-loaded reference file contents within dispatch and task-result XML. When present, receiving agents MUST use these contents instead of reading files from disk.
+`<ref-cache>`는 dispatch 및 task-result XML 내에서 미리 로딩된 레퍼런스 파일 내용을 전달하는 선택적 컨테이너 요소입니다. 존재할 경우, 수신 에이전트는 디스크에서 파일을 읽는 대신 반드시 이 내용을 사용해야 합니다.
 
-### Structure
+### 구조
 
 ```xml
 <ref-cache>
-  <ref key="{filename-without-extension}">{full file content}</ref>
+  <ref key="{확장자 없는 파일명}">{전체 파일 내용}</ref>
   ...
 </ref-cache>
 ```
 
-| Element | Required | Description |
-|---------|----------|-------------|
-| `<ref-cache>` | Optional | Container for cached reference files. Omit entirely if no cache is available. |
-| `<ref key="...">` | — | Individual reference file. `key` is the filename without extension (e.g., `shared-prompt-sections`). |
+| 요소 | 필수 | 설명 |
+|------|------|------|
+| `<ref-cache>` | 선택 | 캐시된 레퍼런스 파일 컨테이너. 캐시가 없으면 전체 생략. |
+| `<ref key="...">` | — | 개별 레퍼런스 파일. `key`는 확장자 없는 파일명 (예: `shared-prompt-sections`). |
 
-### Recognized Keys
+### 인식되는 키
 
-| Key | Corresponding File |
-|-----|--------------------|
+| 키 | 대응 파일 |
+|-----|-----------|
 | `shared-prompt-sections` | `{REFERENCES_DIR}/shared-prompt-sections.md` |
 | `file-content-schema` | `{REFERENCES_DIR}/file-content-schema.md` |
 | `xml-schema` | `{REFERENCES_DIR}/xml-schema.md` |
 | `context-policy` | `{REFERENCES_DIR}/context-policy.md` |
 | `work-activity-log` | `{REFERENCES_DIR}/work-activity-log.md` |
 
-### Backward Compatibility
+### 하위 호환성
+
+- `<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 자동결정) |
 
-- Dispatch or task-result XML without `<ref-cache>` is fully valid — agents fall back to reading files from `REFERENCES_DIR`.
-- Agents that do not yet support ref-cache simply ignore the element and read files normally.
-- Partial ref-cache (only some keys present) is allowed — missing keys are read from disk.
+- 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

@@ -0,0 +1,94 @@
+---
+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:*)"
+]
+```
+
+기존 `permissions.allow` 및 `permissions.deny` 항목을 보존하고 누락된 것만 추가.
+
+```
+권한 추가됨:
+  보고: ✓ {N}개 권한이 .claude/settings.local.json에 추가됨 (총: {T})
+사용자가 건너뛰면:
+  보고: - 권한 설정 건너뜀
+이미 모두 설정됨:
+  보고: - 모든 권한이 이미 설정됨
+```
+
+### 3. 요약
+
+모든 단계 완료 후 요약 표시:
+
+```
+uc-taskmanager 초기화 완료!
+
+  ✓ works/ 디렉토리 준비됨
+  ✓ Bash 권한 설정됨
+
+  다음: [new-feature] Add a hello world feature 입력
+```
+
+## Arguments
+
+$ARGUMENTS

package/skills/work-pipeline/SKILL.md

@@ -1,72 +1,64 @@
 ---
 name: work-pipeline
-description: Triggers the WORK-PIPELINE. Use this skill when (1) user request starts with a [] tag (e.g., [new-feature], [bugfix]), or (2) user asks to resume/continue a WORK (e.g., "WORK-01 계속실행", "resume WORK-01", "WORK-01 실행", "continue WORK-01").
+description: Triggers the WORK-PIPELINE. Use this skill when 
+(1) user message starts with a bracketed tag like [anything], e.g. [WORK], [new-feature], [bugfix], [New game], [enhancement]
+(2) user asks to resume/continue a WORK-NN (e.g., "WORK-01 계속실행", "resume WORK-01", "WORK-01 실행", "continue WORK-01").
 ---
 
-# WORK-PIPELINE Trigger
+# WORK-PIPELINE 트리거
 
-Read `../../references/agent-flow.md` and follow the orchestration flow.
+## 트리거 감지
 
-## Trigger Detection
-
-**New WORK** — message starts with `[...]` tag:
+**새 WORK** — 메시지가 `[]` 태그로 시작하면 실행:
 - `[new-feature]`, `[enhancement]`, `[bugfix]`, `[new-work]`, `[WORK start]`
-- Or any custom tag in square brackets
+- 또는 대괄호 안의 커스텀 태그
 
-**Resume WORK** — message mentions existing WORK-ID with execution intent:
+**WORK 재개** — 메시지에 기존 WORK-ID와 실행 의도가 있을 때:
 - "WORK-XX 계속실행", "WORK-XX 실행", "resume WORK-XX", "continue WORK-XX"
 - "파이프라인 재개", "WORK 계속"
-- → Follow agent-flow.md § Resuming Existing WORK
+
+두 경우 모두 아래 "오케스트레이션 흐름"을 따릅니다.
 
 ## References Directory (CRITICAL)
 
-When this skill is triggered, Claude Code provides the "Base directory for this skill" as an absolute path.
-Derive the **REFERENCES_DIR** from it:
+이 스킬이 트리거되면 Claude Code가 "Base directory for this skill"을 절대 경로로 제공합니다.
+여기서 **REFERENCES_DIR**을 유도합니다:
 
 ```
 REFERENCES_DIR = {Base directory}/../../references
 ```
 
-You MUST pass this absolute path to **every sub-agent invocation** (specifier, planner, scheduler, builder, verifier, committer).
-Include it at the top of the prompt text:
-
-```
-REFERENCES_DIR={absolute_path}
-```
-
-Sub-agents need this path to read their reference files. Without it, they cannot find the files and will loop.
+`orchestrator` spawn 시 이 절대 경로를 반드시 전달해야 합니다. orchestrator가 레퍼런스 파일을 찾기 위해 이 경로가 필요합니다. 없으면 파일을 찾지 못하고 루프에 빠집니다.
 
-## Callback Info Passthrough
+## Auto 모드 감지
 
-If the user's prompt contains `CALLBACK_URL=...` and `CALLBACK_TOKEN=...`, extract these values and pass them to **every sub-agent invocation** alongside REFERENCES_DIR:
+사용자의 메시지에 "auto" 또는 "자동으로"가 포함되면 **auto 모드**로 spawn합니다. 그 외에는 **gated 모드**(기본값)로 spawn합니다.
 
-```
-CALLBACK_URL={url}
-CALLBACK_TOKEN={token}
-```
+## 오케스트레이션 흐름
 
-**Main Claude (this skill) must NEVER send callbacks itself.** Only sub-agents send callbacks.
+Main Claude는 `orchestrator` 에이전트 하나만 spawn합니다. specifier/planner/builder/verifier/committer는 orchestrator가 내부에서 중첩 spawn(TASK DAG 스케줄링 포함)하므로 Main Claude가 직접 호출하지 않습니다.
 
-## Pipeline Flow
+### Gated 모드 (기본값 — "auto"/"자동으로" 없음)
 
-1. **Spawn specifier agent** (via Agent tool) — analyzes the requirement, creates `works/WORK-NN/Requirement.md`, determines execution-mode (direct/pipeline/full)
-2. **⛔ STOP — Present the specifier's output summary to the user and WAIT for explicit approval.** Do NOT call the next agent until the user approves. Show what was created (Requirement.md, PLAN.md if direct mode, TASK files) and ask "Proceed?"
-3. **Follow the execution-mode** returned by specifier:
-   - `direct`: spawn builder (Agent tool) → spawn verifier+committer (single Agent tool, see agent-flow.md § Combined Agent Invocation)
-   - `pipeline`: for each TASK → spawn builder → spawn verifier+committer (repeat per TASK)
-   - `full`: spawn planner → **⛔ STOP for 2nd approval** → spawn scheduler → scheduler handles [builder → verifier+committer] × N
+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를 종료**한다.
 
-## ⚠️ CRITICAL: Agent Spawn Rules
+### Auto 모드 ("auto"/"자동으로" 포함)
 
-- **EVERY agent MUST be spawned via the Agent tool.** Main Claude must NEVER implement code, create files, run git commands, or perform any agent's work directly.
-- In direct mode: spawn specifier → spawn builder → spawn verifier+committer (**3 Agent tool calls**).
-- verifier+committer is a **single spawn** that performs both roles in sequence (see agent-flow.md).
-- If specifier returns builder dispatch XML, pass it to the builder agent — do NOT execute it yourself.
+1. `orchestrator`를 `mode=auto`로 **1회만 spawn**. 프롬프트 상단에 `REFERENCES_DIR=...`와 `mode=auto`를 포함.
+2. 게이트/의사결정 정지 없이 orchestrator가 전체 파이프라인을 완주하고 최종 요약(`## 자동 결정 사항` 포함)을 반환한다.
+3. 반환된 최종 요약을 사용자에게 제시한다. (파킹 상태가 아니므로 TaskStop 불필요.)
 
-## Auto Mode
+## ⚠️ CRITICAL: 에이전트 Spawn 규칙
 
-If the user's message ends with "auto" or "자동으로", skip ALL approval steps and execute the entire pipeline automatically. This is the ONLY case where approval gates can be skipped.
+- Main Claude가 spawn하는 에이전트는 **orchestrator 하나뿐**이다. Main Claude가 직접 코드 구현, 파일 생성, git 명령 실행 또는 orchestrator의 작업을 수행하면 안 된다.
+- 게이트 재개는 항상 **agentId** 기준(SendMessage/TaskStop 모두)으로 한다 — name 재사용에 의한 오배달을 방지한다.
 
 ## Arguments
 
-User requirement: $ARGUMENTS
+사용자 요구사항: $ARGUMENTS

package/skills/work-status/SKILL.md

@@ -3,31 +3,31 @@ name: work-status
 description: Shows WORK status (read-only). Use ONLY when the user asks to VIEW status — not to execute or resume. Matches queries like "WORK 목록", "상태 확인", "WORK-01 상태", "show status". Do NOT use for "실행", "계속", "resume" — those go to work-pipeline.
 ---
 
-# WORK Status
+# WORK 상태
 
-Check and report the current status of WORKs and TASKs.
+WORK 및 TASK의 현재 상태를 확인하고 보고합니다.
 
-## How to Check
+## 확인 방법
 
-1. Read `works/WORK-LIST.md` for the master index of all WORKs
-2. For a specific WORK, read last line of `works/WORK-NN/work_WORK-NN.log` for current progress
-3. For a specific TASK, read `works/WORK-NN/TASK-NN_result.md` for completion details
+1. `works/WORK-LIST.md`를 읽어 모든 WORK의 마스터 인덱스 확인
+2. 특정 WORK의 경우 `works/WORK-NN/work_WORK-NN.log` 마지막 줄을 읽어 현재 진행 상황 확인
+3. 특정 TASK의 경우 `works/WORK-NN/TASK-NN_result.md`를 읽어 완료 상세 확인
 
-## Status Values
+## 상태 값
 
-| Status | Meaning |
-|--------|---------|
-| `IN_PROGRESS` | WORK created, TASKs being executed |
-| `DONE` | All TASKs committed — committer auto-sets on last TASK |
-| `COMPLETED` | Archived to `_COMPLETED/` — set during push |
+| 상태 | 의미 |
+|------|------|
+| `IN_PROGRESS` | WORK 생성됨, TASK 실행 중 |
+| `DONE` | 모든 TASK 커밋됨 — committer가 마지막 TASK에서 자동 설정 |
+| `COMPLETED` | `_COMPLETED/`로 아카이빙됨 — push 시 설정 |
 
-## Display Format
+## 표시 형식
 
 ```
-WORK Status
-  WORK-01: User Authentication    ✅ 5/5 completed
-  WORK-02: Payment Integration    🔄 2/4 in progress
-  WORK-03: Admin Dashboard        ⬜ 0/6 pending
+WORK 상태
+  WORK-01: 사용자 인증    ✅ 5/5 완료
+  WORK-02: 결제 연동      🔄 2/4 진행 중
+  WORK-03: 관리자 대시보드  ⬜ 0/6 대기
 ```
 
 ## 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 사이로 조정 가능"
-  }
-}