{"id":"60ba2724-0f45-4963-b73a-3e20942afcf9","slug":"uc-taskmanager-claude-agent","kind":"skill","name":"uc-taskmanager-claude-agent","summary":"Claude Code CLI용 범용 작업 파이프라인 서브에이전트","owner":"UCJung","repoUrl":"https://github.com/UCJung/uc-taskmanager-claude-agent","license":"GPL-3.0","licenseTier":"strong-copyleft","trust":"community","stars":1,"match":null,"fewStars":true,"format":"skill","createdAt":"2026-03-01T14:06:55.000Z","addedAt":"2026-10-22T02:24:06.763Z","logoUrl":"https://avatars.githubusercontent.com/u/5705493?v=4","linkOnly":false,"collection":null,"skillPath":null,"categories":["developer-tools","productivity","data-analytics"],"tags":["ai-agent","ai-pipeline","anthropic","claude","claude-code","claude-code-subagents","cli","context-window"],"runtime":"binary","local":true,"cloudCapable":false,"cloudCapability":"unknown","cloudReadyOnPlatform":false,"needsApiKey":false,"reviewed":false,"syncedAt":"2026-10-23T00:09:02.750Z","sample":false,"url":"https://conduits.dev/tools/uc-taskmanager-claude-agent","language":"HTML","transports":["stdio"],"install":{},"requirements":{"env":[],"upstreamMayCharge":false},"tools":null,"readme":"# uc-taskmanager (uctm)\n\n**English** | [한국어](README.ko.md)\n\n> An **SDD (Spec-Driven Development) WORK-PIPELINE subagent system** for Claude Code.\n> A team of specialized agents autonomously orchestrates the full flow — requirements → design → build → verify → commit.\n\n## 📖 Overview\n\n**uc-taskmanager** turns a single development request into a fully automated pipeline that runs **from requirements analysis all the way to commit**.\n\nWhen you type something like `[new-feature] Add a login feature`, the pipeline turns it into a **WORK (unit of work)**, decomposes it into multiple **TASKs**, and processes each stage with a dedicated agent — sequentially and in parallel.\n\nThe core ideas are **role separation** and **autonomous orchestration**. Instead of one giant agent doing everything, several agents — each with its own responsibility and model — collaborate.\n\n| Agent | Responsibility | Model |\n|-------|----------------|-------|\n| **orchestrator** | Coordinates, schedules, and commits the whole pipeline | opus |\n| **specifier** | Requirement specification (**What**) | opus |\n| **planner** | Implementation design & TASK decomposition (**How**) | opus |\n| **builder** | Actual code implementation + build self-check | sonnet |\n| **verifier** | Independent, read-only verification (build/lint/test/acceptance) | haiku |\n\nPipeline flow:\n\n```\nUser request\n   │\n   ▼\n[orchestrator]  ← spawned once by Main Claude\n   ├─ specifier   → Requirement.md (requirement spec)\n   ├─ planner     → PLAN.md + TASK DAG (design & decomposition)\n   └─ per TASK:\n        builder   → code implementation\n        verifier  → independent verification (PASS/FAIL)\n        [commit]   → orchestrator writes result.md inline → git commit\n   │\n   ▼\nWORK completion report\n```\n\nEvery artifact is preserved under `works/WORK-NN/` — the requirement spec (`Requirement.md`), plan (`PLAN.md`), per-TASK spec/result (`TASK-NN.md`, `TASK-NN_result.md`), decision log (`DECISIONS.md`), and activity log (`work_WORK-NN.log`).\n\n---\n\n## 📂 Artifacts\n\nThe pipeline automatically generates a documented paper trail for every WORK — no manual note-taking required.\n\n**Folder structure**\n\n```\nworks/\n├── WORK-LIST.md              # index & status of all WORKs\n├── WORK-NN/                  # one folder per WORK\n│   ├── Requirement.md        # requirement spec\n│   ├── PLAN.md               # implementation plan\n│   ├── TASK-01.md            # per-TASK spec (DAG node)\n│   ├── TASK-01_result.md     # per-TASK result\n│   ├── ...\n│   ├── DECISIONS.md          # decision log\n│   └── work_WORK-NN.log      # activity log (resume source)\n└── _COMPLETED/               # archive of finished WORKs\n```\n\n**Artifacts produced per stage**\n\n| Stage | Naming | Description |\n|-------|--------|-------------|\n| specifier | `Requirement.md` | Structured requirement spec (the What) |\n| planner | `PLAN.md` | WORK-level implementation plan |\n| planner | `TASK-NN.md` | Per-TASK spec — a node in the TASK DAG |\n| builder → verifier → commit | `TASK-NN_result.md` | Per-TASK result, written inline by the orchestrator after verifier PASS |\n| orchestrator | `DECISIONS.md` | Auto/user decision log with rationale |\n| orchestrator | `work_WORK-NN.log` | Activity log driving idempotent resume |\n| orchestrator | `WORK-LIST.md` | Global WORK list & status (IN_PROGRESS → DONE) |\n\n---\n\n## 🚀 Installation & Usage\n\n### Install\n\n**npm (recommended)**\n\n```bash\n# Global install\nnpm install -g uctm\n\n# Install the pipeline into your project (agents, skills, references under .claude/)\nuctm init\n\n# Install globally (~/.claude/) for use across all projects\nuctm init --global\n\n# Refresh files after upgrading\nuctm update\n```\n\n`uctm init` installs the agent definitions, skills, and references under your project's `.claude/`, and configures the Bash permissions the pipeline needs in `settings.local.json`.\n\n### Usage\n\nStart Claude Code and kick off new work with a **bracket tag**.\n\n```bash\nclaude\n```\n\n```\n[new-feature] Add a user profile editing feature\n```\n\nSupported trigger tags: `[new-feature]` · `[enhancement]` · `[bugfix]` · `[new-work]` · `[WORK start]` (or any custom bracket tag).\n\n**Two execution modes**\n\n| Mode | Description | Trigger |\n|------|-------------|---------|\n| **gated** (default) | Stops at **approval gates** after specifier and after planner, and presents options at each decision point | default |\n| **auto** | Runs end-to-end with no gates, auto-deciding every judgment call from the recommended option and reporting afterward | include \"auto\" in the request |\n\n```\n[new-feature] Add a dark-mode toggle, run it automatically   ← auto mode\n```\n\n**Resuming interrupted work**\n\n```\nresume WORK-12    ·    continue WORK-12\n```\n\nThe pipeline reads the activity log to determine where it stopped, **skips already-completed stages**, and continues. Even side-effecting steps like commits resume idempotently.\n\n---\n\n## ✨ Key Advantages\n\n**1. DAG-based TASK scheduling**\nTASK dependencies are interpreted as a DAG, so independent TASKs run **in parallel** while dependent ones keep their order — no unnecessary waiting.\n\n**2. Sliding-window context management**\nEach agent receives the previous stage in FULL, two stages back as a SUMMARY, and anything older DROPped. Long pipelines stay alive without context blow-up.\n\n**3. ref-cache — read references once**\nThe orchestrator reads the shared reference docs **exactly once** and hands each child only the sections it needs. Children never re-read the docs, eliminating token waste.\n\n**4. Verification independence**\nThe verifier re-runs build/lint/test/acceptance **independently in read-only mode**. Because the implementer (builder) and verifier are separated, implementation can never rubber-stamp itself.\n\n**5. Gates & automatic decisions**\nAt judgment points — ambiguous requirements, design trade-offs, scope overruns, irreversible changes — gated mode presents options to the user, while auto mode decides from the recommendation and records the rationale in `DECISIONS.md`.\n\n**6. Idempotent resume**\nAll progress is written to the activity log (`work_WORK-NN.log`), so an interrupted session resumes at the exact right point — with no duplicated or skipped commits.\n\n**7. Cost optimization via model tiering**\nHeavy reasoning (requirements, design) runs on opus, implementation on sonnet, and verification on haiku — balancing **quality against cost**.\n\n**8. Automatic artifact generation**\nEvery stage writes its output to disk — requirement spec, plan, per-TASK results, decision log, and activity log — giving you a complete, reviewable paper trail without any manual note-taking. See [Artifacts](#-artifacts).\n\n---\n\n## 🧩 Configuration Files\n\n`uctm init` installs the following under `.claude/`:\n\n```\n.claude/\n├── agents/       # pipeline agent definitions\n│   ├── orchestrator.md\n│   ├── specifier.md\n│   ├── planner.md\n│   ├── builder.md\n│   └── verifier.md\n├── references/   # shared rule/schema docs — read once by the orchestrator\n│   ├── agent-flow.md\n│   ├── context-policy.md\n│   ├── file-content-schema.md\n│   ├── operation-guide.md\n│   ├── shared-prompt-sections.md\n│   ├── work-activity-log.md\n│   └── xml-schema.md\n└── skills/       # user-triggerable skills\n    ├── uctm-init/\n    ├── work-pipeline/\n    ├── work-status/\n    └── sdd-pipeline/\n```\n\n**`agents/` — pipeline agent definitions**\n\n| File | Description |\n|------|-------------|\n| `orchestrator.md` | Autonomously orchestrates the whole pipeline via nested spawns; handles scheduling, gates, and inline commit |\n| `specifier.md` | Creates the requirement spec (the What) |\n| `planner.md` | Turns requirements into design + TASK DAG (the How) |\n| `builder.md` | Implements a TASK's code + build self-check |\n| `verifier.md` | Independent read-only verification (build/lint/test/acceptance) |\n\n**`references/` — shared rule/schema docs** (the orchestrator reads these once and distributes sections to children via ref-cache)\n\n| File | Description |\n|------|-------------|\n| `agent-flow.md` | Main Claude's role guide — trigger & gate boundaries, degraded mode |\n| `context-policy.md` | Sliding-window context handoff rules + retry policy |\n| `file-content-schema.md` | Single source of truth for artifact file formats & naming |\n| `operation-guide.md` | Operation Guide overlay contract — how a per-project guide drives external-system integration |\n| `shared-prompt-sections.md` | Common reusable prompt sections (output language, status detection, WORK-LIST, Bash rules) |\n| `work-activity-log.md` | Activity-log event rules driving idempotent resume |\n| `xml-schema.md` | Inter-agent XML protocol (ref-cache, gate, needs-decision, task-result) |\n\n**`skills/` — user-triggerable skills**\n\n| File | Description |\n|------|-------------|\n| `uctm-init/` | Initialize uctm for the project (creates `works/`, configures Bash permissions) |\n| `work-pipeline/` | Trigger the WORK-PIPELINE (starts orchestration) |\n| `work-status/` | Show WORK status (read-only) |\n| `sdd-pipeline/` | Internal reference bundle for the pipeline agents (not user-facing) |\n\n---\n\n## 🔗 Operation Guide overlay (optional)\n\nuctm's file-based pipeline is a **mechanical substrate**. A project may layer its own operating\nprocedure on top by declaring an **operation guide** in its `CLAUDE.md`:\n\n```\n## OperationGuide\ndocs/[GUIDE]_RND_OPERATION.md\n```\n\nWhen declared, the `work-pipeline` skill passes the guide's absolute path to the orchestrator\n(`OPERATION_GUIDE=…`, same pattern as `REFERENCES_DIR=`). The guide is treated as a **policy overlay**:\n\n- **orchestrator** records pipeline execution history at stage boundaries (run / step / artifact / finish),\n  using the tools the guide specifies (supported backend: `ucpm-mcp`).\n- **Main Claude** performs lifecycle work at the boundaries — requirement/state transitions, IA/TC\n  registration, test & release.\n- If the guide's tools are unavailable, calls **gracefully skip** and fall back to the activity log,\n  to be backfilled later. Projects with no `## OperationGuide` run exactly as before.\n\nuctm ships **no project-specific procedure** — only the discovery + overlay contract\n(`references/operation-guide.md`). Each project authors its own guide.\n\n---\n\n## 📄 License\n\nGPL-3.0 · [UCJung](https://github.com/UCJung/uc-taskmanager-claude-agent)\n"}