uctm 1.5.0 → 1.5.2

package/skills/work-pipeline/SKILL.md

@@ -1,25 +1,30 @@
 ---
 name: work-pipeline
-description: Triggers the WORK-PIPELINE when a user request starts with a [] tag (e.g., [new-feature], [bugfix], [WORK start]). Use this skill whenever you detect a [] tag at the beginning of a user message.
+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").
 ---
 
 # WORK-PIPELINE Trigger
 
-When the user's message starts with a `[]` tag, start the WORK-PIPELINE by reading `../skills/sdd-pipeline/references/agent-flow.md` and following the orchestration flow.
+Read `../../references/agent-flow.md` and follow the orchestration flow.
 
 ## Trigger Detection
 
-Any message starting with `[...]` triggers this pipeline:
+**New WORK** — message starts with `[...]` tag:
 - `[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-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:
 
 ```
-REFERENCES_DIR = {Base directory}/../sdd-pipeline/references
+REFERENCES_DIR = {Base directory}/../../references
 ```
 
 You MUST pass this absolute path to **every sub-agent invocation** (specifier, planner, scheduler, builder, verifier, committer).
@@ -31,14 +36,32 @@ REFERENCES_DIR={absolute_path}
 
 Sub-agents need this path to read their reference files. Without it, they cannot find the files and will loop.
 
+## Callback Info Passthrough
+
+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:
+
+```
+CALLBACK_URL={url}
+CALLBACK_TOKEN={token}
+```
+
+**Main Claude (this skill) must NEVER send callbacks itself.** Only sub-agents send callbacks.
+
 ## Pipeline Flow
 
-1. **Call specifier agent** — analyzes the requirement, creates `works/WORK-NN/Requirement.md`, determines execution-mode (direct/pipeline/full)
+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`: call builder → committer
-   - `pipeline`: call builder → verifier → committer in sequence
-   - `full`: call planner → **⛔ STOP for 2nd approval** → scheduler → [builder → verifier → committer] × N
+   - `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
+
+## ⚠️ CRITICAL: Agent Spawn Rules
+
+- **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.
 
 ## Auto Mode
 

package/skills/work-status/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: work-status
-description: Shows WORK progress and TASK status. Use when the user asks about WORK list, WORK progress, TASK status, or pipeline status (e.g., "WORK list", "WORK-01 progress", "show 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
@@ -10,7 +10,7 @@ Check and report the current status of WORKs and TASKs.
 ## How to Check
 
 1. Read `works/WORK-LIST.md` for the master index of all WORKs
-2. For a specific WORK, read `works/WORK-NN/PROGRESS.md` for TASK-level progress
+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
 
 ## Status Values

package/agents/agent-flow.md

@@ -1,279 +0,0 @@
-# Agent Flow — Main Claude Orchestration Guide
-
-> **All agent invocations are performed by Main Claude.**
-> Sub-agents only return results (dispatch XML or task-result XML) after completing their work.
-> Main Claude receives return values and invokes the next agent.
-
----
-
-## Pipeline Flow
-
-```
-[] tag detected → invoke specifier
-    │
-    Check specifier return value
-    │
-    ├─ Assumed (direct) → specifier creates Requirement.md + PLAN.md + TASK-00
-    │                      → returns builder dispatch XML
-    │                      → execute § direct procedure
-    │
-    └─ Delegated (pipeline/full) → specifier creates Requirement.md only
-                                    → returns planner dispatch XML
-                                    → execute § planner-driven procedure
-```
-
----
-
-## Direct Mode (Specifier Assumes Planner)
-
-```
-1. Invoke specifier → creates Requirement.md + PLAN.md + TASK-00 + returns builder dispatch XML
-2. ⛔ STOP — Present summary to user and WAIT for approval (do NOT invoke builder)
-3. Invoke builder (dispatch XML as prompt) — includes self-check
-4. Invoke verifier+committer (builder result as prompt) — verify then commit in one spawn
-```
-
-> Verifier+Committer combined: single spawn performs verification, then creates result.md and git commit.
-
----
-
-## Pipeline Mode (Separate Planner Invocation)
-
-```
-1. Invoke specifier+planner (single spawn) → creates Requirement.md + PLAN.md + TASK-NN + determines execution-mode
-2. ⛔ STOP — Present Requirement.md + PLAN.md + TASK list and WAIT for approval
-3. Invoke builder (per-TASK dispatch XML as prompt)
-4. Invoke verifier+committer (builder result as prompt) — verify then commit in one spawn
-```
-
-> Specifier+Planner combined: specifier.md role first (Requirement.md), then planner.md role (PLAN.md + TASKs) in one spawn.
-
----
-
-## Full Mode (With Scheduler)
-
-```
-1. Invoke specifier+planner (single spawn) → Requirement.md + PLAN.md + TASKs + execution-mode: full
-2. ⛔ STOP — Present Requirement.md + PLAN.md + TASK list and WAIT for approval
-3. Invoke scheduler → DAG analysis + READY TASK + returns builder dispatch XML
-4. Invoke builder (dispatch XML as prompt) → implementation
-5. Invoke verifier+committer (builder result as prompt) → verify then commit in one spawn
-6. If incomplete TASKs remain, return to step 3
-```
-
-Parallel execution: When scheduler returns multiple READY TASKs, invoke builders concurrently.
-
----
-
-## Resuming Existing WORK
-
-Resume pipeline for a WORK that already has PLAN.md + TASKs:
-
-```
-1. Invoke scheduler → check READY TASKs + return builder dispatch XML
-2. Invoke builder → implementation
-3. Invoke verifier+committer → verify then commit in one spawn
-4. If incomplete TASKs remain, return to step 1
-```
-
----
-
-## Combined Agent Invocation
-
-### Specifier+Planner (single spawn)
-
-When invoking specifier in pipeline/full mode, include both agent definitions:
-
-```
-Prompt to agent:
-  "You will perform two roles in sequence.
-
-   Role 1 — Specifier: Read specifier.md and create Requirement.md.
-   Role 2 — Planner: Read planner.md and create PLAN.md + TASK files.
-
-   Execute Role 1 first, then Role 2. Return the combined result."
-```
-
-- Use specifier's model (opus) for the spawn
-- Agent reads both specifier.md and planner.md from REFERENCES_DIR
-- Returns: Requirement.md + PLAN.md + TASK files + execution-mode
-
-### Verifier+Committer (single spawn)
-
-When invoking verification after builder completes:
-
-```
-Prompt to agent:
-  "You will perform two roles in sequence.
-
-   Role 1 — Verifier: Read verifier.md and verify build/lint/test.
-   Role 2 — Committer: Read committer.md and create result.md + git commit.
-
-   Execute Role 1 first. If verification PASSES, execute Role 2.
-   If verification FAILS, skip Role 2 and return FAIL result."
-```
-
-- Use verifier's model (haiku) for the spawn
-- Agent reads both verifier.md and committer.md from REFERENCES_DIR
-- On PASS: returns verification result + commit hash
-- On FAIL: returns verification failure only (no commit)
-
----
-
-## Agent Role Summary
-
-| Agent | Role | Model | Combined With |
-|-------|------|-------|---------------|
-| specifier | Requirement analysis | opus | + planner (pipeline/full) |
-| planner | PLAN + TASK decomposition | opus | combined into specifier spawn |
-| scheduler | DAG management + dispatch | haiku | standalone |
-| builder | Code implementation | sonnet | standalone |
-| verifier | Build/lint/test verification | haiku | + committer |
-| committer | Result report + git commit | haiku | combined into verifier spawn |
-
----
-
-## Sub-agent Spawn Count by Mode
-
-| Mode | Spec+Plan | Scheduler | Builder | Veri+Commit | Total |
-|------|:---------:|:---------:|:-------:|:-----------:|:-----:|
-| direct | 1 (assumed) | — | 1 | 1 | **3** |
-| pipeline | 1 (combined) | — | 1 | 1 | **3** |
-| full (N TASKs) | 1 (combined) | 1 | N | N | **2 + 2N** |
-
-**Before vs After (6 TASKs):**
-
-| | Before | After | Reduction |
-|---|:---:|:---:|:---:|
-| Spawns | 2 + 3×6 = 20 | 2 + 2×6 = 14 | **-30%** |
-
----
-
-## Approval Gates (CRITICAL)
-
-> **MUST STOP and wait for explicit user approval before invoking the next agent.**
-> Do NOT proceed until the user says "approve", "승인", "proceed", "go ahead", or equivalent.
-> The only exception is auto mode — when the user's original message contains "auto" or "자동으로".
-
-| Mode | Approvals | Timing | What to show user |
-|------|:---------:|--------|-------------------|
-| direct | 1 | After Specifier completes | Requirement.md + PLAN.md + TASK-00.md summary |
-| pipeline/full | 1 | After Specifier+Planner completes | Requirement.md + PLAN.md + TASK list |
-| auto-approve | 0 | — | Skip all approval gates |
-
-> Note: pipeline/full now has **1 approval** (not 2), since specifier and planner run in one spawn.
-
-**How to request approval:**
-1. Present a summary of what the specifier+planner created (files, scope, execution-mode)
-2. Ask: "Proceed?" or equivalent
-3. **WAIT for user response** — do NOT invoke builder until approved
-
----
-
-## Bash CLI Execution (Server Automation)
-
-Run the pipeline independently without a conversation session. `claude -p` acts as Main Claude.
-
-```bash
-env -u CLAUDECODE -u ANTHROPIC_API_KEY claude -p \
-  "[new-work] {task description}" \
-  --dangerously-skip-permissions \
-  --output-format stream-json \
-  --verbose \
-  2>&1 | tee /tmp/pipeline.log
-```
-
-| Option | Purpose |
-|--------|---------|
-| `env -u CLAUDECODE` | Bypass nested execution block |
-| `env -u ANTHROPIC_API_KEY` | Use subscription auth (Max) instead of API key |
-| `--dangerously-skip-permissions` | Skip permission prompts for unattended execution |
-| `--output-format stream-json --verbose` | Streaming for real-time monitoring |
-
-Resume interrupted pipeline:
-```bash
-env -u CLAUDECODE -u ANTHROPIC_API_KEY claude -p \
-  "Resume WORK-XX pipeline." \
-  --dangerously-skip-permissions
-```
-
----
-
-## References Directory Passing (REQUIRED)
-
-Main Claude MUST pass the references directory path to every sub-agent invocation.
-This allows sub-agents to locate their reference files regardless of installation method (npm or plugin).
-
-**How to pass:**
-- Prepend `REFERENCES_DIR={absolute_path}` at the top of the prompt for every Task tool call
-- For npm installations: use `.claude/agents` (default, resolved from project root)
-- For plugin installations: derive from the skill's "Base directory" (`{base_dir}/../sdd-pipeline/references`)
-
-**Example:**
-```
-REFERENCES_DIR=C:/Users/me/.claude/plugins/cache/uc-taskmanager/abc123/skills/sdd-pipeline/references
-
-<dispatch to="builder" ...>
-  ...
-</dispatch>
-```
-
-If REFERENCES_DIR is not available (e.g., npm installation without plugin), sub-agents fall back to `.claude/agents/`.
-
----
-
-## Context Handoff (Sliding Window)
-
-| Distance | Level | Content |
-|----------|-------|---------|
-| Previous | FULL | what + why + caution + incomplete |
-| 2 steps back | SUMMARY | what 1-2 lines |
-| 3+ steps | DROP | Not passed |
-
----
-
-## ref-cache Chain Propagation
-
-`<ref-cache>` carries pre-loaded reference file contents through the pipeline, eliminating redundant disk reads in each sub-agent.
-
-### Rules
-
-1. **First agent (typically specifier)** — no ref-cache available on dispatch. Reads reference files from `REFERENCES_DIR` normally.
-
-2. **Agent returns task-result** — if the agent supports ref-cache, it includes `<ref-cache>` in its task-result XML containing all reference files it loaded.
-
-3. **Main Claude propagates ref-cache** — when dispatching the next agent, copy the `<ref-cache>` block from the previous task-result into the new dispatch XML unchanged.
-
-4. **Receiving agent skips file reads** — when `<ref-cache>` is present in the dispatch XML, the agent reads reference content from `<ref>` elements instead of reading files from disk.
-
-5. **Missing ref-cache** — if a task-result does not contain `<ref-cache>` (agent does not support it yet), omit `<ref-cache>` from the next dispatch. The receiving agent falls back to reading files from disk.
-
-### Flow Example
-
-```
-specifier+planner (no ref-cache in) → reads files → returns task-result with <ref-cache>
-  ↓ Main Claude copies <ref-cache> into dispatch
-builder (ref-cache in) → skips file reads → returns task-result with <ref-cache>
-  ↓ Main Claude copies <ref-cache> into dispatch
-verifier+committer (ref-cache in) → skips file reads → commit
-```
-
-### Phase 2: Selective Section Delivery
-
-Instead of passing full reference files, Main Claude extracts only the sections each agent needs. This reduces dispatch token size by 50-70%.
-
-**Main Claude reads reference files once at pipeline start**, then delivers condensed `<ref-cache>` per agent using this mapping:
-
-| Agent | shared-prompt-sections | file-content-schema | xml-schema | context-policy | work-activity-log |
-|-------|:---:|:---:|:---:|:---:|:---:|
-| **specifier+planner** | §1,§2,§7,§8,§9,§11 | §0,§1,§2,§3 | §1,§3 | — | full |
-| **scheduler** | §4,§8,§10 | §1,§6 | §1,§3,§4,§5 | full | full |
-| **builder** | §1,§2,§10,§12 | §2,§3 | §1,§2,§4 | Builder section | full |
-| **verifier+committer** | §1,§2,§8,§10,§12 | §3,§4,§5,§6,§7 | §1,§2,§4 | Verifier+Committer | full |
-
-**Delivery format**: Condense each `<ref key="">` to contain only the needed sections, not the full file. Use one-line summaries for simple rules, keep full content only for templates and code blocks.
-
-### Constraints
-
-- **ref-cache does not replace REFERENCES_DIR** — always pass `REFERENCES_DIR` (or `<references-dir>`) in every dispatch regardless of ref-cache presence, for backward compatibility.
-- **Agents may still read files** — if ref-cache content is insufficient, agents fall back to reading from disk.

package/agents/context-policy.md

@@ -1,94 +0,0 @@
-# Context Handoff Policy
-
-Sliding window context transfer rules between agents.
-
-## Sliding Window
-
-| Step Distance | Detail Level | Rule |
-|---------------|-------------|------|
-| Immediate (1 step) | `FULL` | All 4 fields transmitted |
-| 2 steps back | `SUMMARY` | `what` field only, 1-3 lines |
-| 3+ steps back | `DROP` | Omitted |
-
-## Context-Handoff 4 Fields
-
-| Field | FULL | SUMMARY | Content |
-|-------|:----:|:-------:|---------|
-| `what` | ✅ | ✅ | Summary of changes/verification (2-5 lines) |
-| `why` | ✅ | ❌ | Decision rationale (2-4 lines) |
-| `caution` | ✅ | ❌ | Caveats, conditional completion (1-3 lines) |
-| `incomplete` | ✅ | ❌ | Incomplete items (1-2 lines, "None" if empty) |
-
-## Pipeline Stage Input/Output
-
-### Builder
-
-Input: TASK spec + dependent TASK result.md context-handoff (sliding window)
-
-Output:
-```xml
-<task-result status="PASS|FAIL">
-  <context-handoff from="builder" detail-level="FULL">
-    <what>Changes made</what><why>Rationale</why><caution>Caveats</caution><incomplete>Incomplete items</incomplete>
-  </context-handoff>
-</task-result>
-```
-
-### Verifier
-
-Input: TASK spec + Builder context-handoff (FULL)
-
-Output:
-```xml
-<task-result status="PASS|FAIL">
-  <context-handoff from="verifier" detail-level="FULL">
-    <what>Verification results</what><why>Judgment rationale</why><caution>Manual checks needed</caution><incomplete>Items that could not be verified</incomplete>
-  </context-handoff>
-</task-result>
-```
-
-### Committer
-
-Input: Verifier context-handoff (FULL) + Builder context-handoff (SUMMARY) + progress.md (gate)
-
-Processing:
-1. progress.md gate: exists + Status=COMPLETED + Files changed is not empty
-2. Gate passed → write result.md + git commit
-3. Gate failed → return FAIL (triggers scheduler retry)
-
-Output: → `{REFERENCES_DIR}/file-content-schema.md` § 4 reference
-
-## Inter-TASK Dependency Transfer
-
-- Immediate dependent TASK: context-handoff **FULL** (all 4 fields)
-- 2 steps back: **SUMMARY** (what only)
-- 3+ steps back: **DROP**
-
-## Scheduler Dispatch
-
-```xml
-<!-- Verifier: Builder FULL -->
-<dispatch to="verifier">
-  <context-handoff from="builder" detail-level="FULL">...</context-handoff>
-</dispatch>
-
-<!-- Committer: Verifier FULL + Builder SUMMARY -->
-<dispatch to="committer">
-  <context-handoff from="verifier" detail-level="FULL">...</context-handoff>
-  <context-handoff from="builder" detail-level="SUMMARY"><what>...</what></context-handoff>
-</dispatch>
-
-<!-- Next TASK Builder: dependency distance applied -->
-<dispatch to="builder" task="TASK-YY">
-  <previous-results>
-    <context-handoff from="prev-task" task="TASK-XX" detail-level="FULL">...</context-handoff>
-    <context-handoff from="prev-prev-task" task="TASK-WW" detail-level="SUMMARY"><what>...</what></context-handoff>
-  </previous-results>
-</dispatch>
-```
-
-## Committer Retry
-
-1. Failure cause: progress.md not found / Status≠COMPLETED / No files changed
-2. Re-dispatch to builder including existing progress.md
-3. Maximum 2 retries (3 attempts total). 3 failures → TASK FAILED, pipeline halted