uc-taskmanager
Universal Claude Task Manager — A 6-agent pipeline that turns a single []-tagged request into planned, built, tested, and committed code.
You type one request. Six agents handle the rest:
requirement analysis → task decomposition → dependency DAG → code implementation → verification → git commit
[new-feature] Build a user authentication feature with JWT
→ specifier analyzes complexity → planner creates WORK with 5 TASKs
→ scheduler dispatches by dependency order
→ builder implements → verifier checks → committer commits
→ 5 tasks, 5 commits. Done.
No runtime dependencies. No external services. Pure prompt engineering.
Why This Exists
Claude Code is powerful, but for complex multi-file tasks it tries to do everything in one shot. Context grows, quality degrades, and there's no way to resume after a failure.
uc-taskmanager solves this with context isolation — each agent runs in its own subagent session, so a 50-file builder session compresses to a 3-line summary for the next agent. After 10 TASKs, your pipeline uses ~3K tokens of context instead of 50K–100K.
| Single Session | uc-taskmanager | |
|---|---|---|
| Context per TASK | All code + logs stacked | Summary only (~200 tokens) |
| After 10 TASKs | 50K–100K tokens, quality degrades | ~3K tokens, quality stable |
| Failure recovery | Start over | Resume from last result file |
| Tracking | Scroll chat history | File-based (PLAN.md, result.md) |
| Verification | Manual | Automated (build/lint/test) |
Quick Start
npm install -g uctm
cd your-project
uctm init --lang en # English agents
# uctm init --lang ko # Korean agents
# uctm init # Interactive selection
claude --dangerously-skip-permissions
# Type: [new-feature] Add a REST API for user management
# → Pipeline runs automatically
What uctm init does: copies 12 agent files to .claude/agents/, creates .agent/router_rule_config.json, updates CLAUDE.md with agent invocation rules, and creates works/ directory.
The 6 Agents
User Request → Main Claude (orchestrator)
│
┌──────────────────┼───────────────────────────┐
│ │ │
specifier planner scheduler builder → verifier → committer
(analyze + (decompose (DAG + (implement (test (result +
route) into TASKs) dispatch) code) verify) git commit)
| Agent | What it does | Model |
|---|---|---|
| specifier | Analyzes []-tagged requests, selects execution mode, creates PLAN, manages WORK-LIST |
opus |
| planner | Decomposes into TASKs with dependency DAG (full mode) | opus |
| scheduler | Manages DAG ordering, dispatches TASKs with sliding window context | haiku |
| builder | Implements code, writes progress checkpoints | sonnet |
| verifier | Independent build/lint/test verification (read-only) | haiku |
| committer | Writes result report, git commits, triggers next TASK | haiku |
Every agent is a .md file — pure prompt definitions. No runtime code.
3 Execution Modes
The specifier auto-selects the right level of effort:
| Mode | When | Pipeline |
|---|---|---|
| direct | No build/test needed (config edits, text changes) | specifier → builder → committer |
| pipeline | Build/test required, single domain | specifier → builder → verifier → committer |
| full | Multi-domain, complex DAG, 5+ tasks | specifier → planner → scheduler → [builder → verifier → committer] × N |
All three modes output to works/WORK-NN/ with identical artifact structure.
Token Economy
Four strategies keep costs down:
1. Serena MCP for codebase analysis — Reads symbols instead of entire files. 30–50% fewer read tokens on large codebases. (Thanks to the Oraios/Serena team.)
2. Three execution modes — A typo fix doesn't need 6 agent sessions. Direct mode uses 3 calls; full mode uses all 6.
3. Structured XML messaging — Agents communicate via typed XML, not free-form text. Parseable, validatable, no clarification rounds.
4. Sliding window context transfer — Each TASK only receives full context from the immediate predecessor, a summary from two back, and nothing from three+ back. Constant ~200 tokens per handoff regardless of pipeline length.
| Distance | Detail | Tokens |
|---|---|---|
| Previous (n-1) | FULL — what, why, caution, incomplete | ~150 |
| Two back (n-2) | SUMMARY — what only | ~50 |
| Three+ back | DROP | 0 |
How to Use
Tag your request with [] to trigger the pipeline:
| Tag | Meaning |
|---|---|
[new-feature] |
New feature |
[enhancement] |
Enhancement |
[bugfix] |
Bug fix |
[new-work] |
Always create new WORK (skip complexity check) |
No [] tag = Claude handles it directly, no pipeline.
Simple fix (direct mode)
> [bugfix] Fix typo in login error message
Medium task (pipeline mode)
> [bugfix] Fix the login button not responding on mobile
Complex feature (full mode)
> [new-feature] Build a comment feature for the blog system
The pipeline runs with approval checkpoints:
-
Requirement analysis → review
Requirement.md→ approve - WORK plan + TASK decomposition → review PLAN.md + DAG → approve
- Per-TASK execution → builder → verifier → committer (automatic)
- Done → verify via result files, then push
Skip approvals? Add "auto":
> [new-feature] Build a comment feature — auto
Resume after failure?
> Resume WORK-02 from where it stopped
Rollback a WORK?
> WORK-02 rollback
Example Session
User: [new-feature] Build a comment feature for the blog system.
Claude: [specifier → full mode]
Complexity: 4+ files, DB schema change, multiple modules → WORK
Claude: [planner]
WORK-03: Comment Feature
TASK-00: Comment model + migration ← no dependencies
TASK-01: Comment CRUD API ← TASK-00
TASK-02: Nested comments (self-relation) ← TASK-01
TASK-03: Frontend comment component ← TASK-00 (parallel with 01/02)
TASK-04: Integration + notifications ← TASK-02, TASK-03
DAG:
TASK-00 ─┬→ TASK-01 → TASK-02 ─┐
└→ TASK-03 ────────────┴→ TASK-04
Approve?
User: Approve. Run automatically.
Claude: [scheduler → auto mode]
TASK-00 → builder → verifier ✅ → committer [a1b2c3d]
TASK-01 → builder → verifier ✅ → committer [d4e5f6g]
TASK-02 → builder → verifier ✅ → committer [h7i8j9k]
TASK-03 → builder → verifier ✅ → committer [l0m1n2o]
TASK-04 → builder → verifier ✅ → committer [p3q4r5s]
🎉 WORK-03 completed! 5 tasks, 5 commits
Design Principles
Specification-Driven Development (SDD)
Requirements → Architecture → Design are the real assets. Code is just output.
The pipeline formalizes user requirements into specifications, builds execution plans from those specs, then decomposes and executes. Every step produces traceable artifacts — from requirement to delivery.
Context Isolation
Each subagent runs in an independent context window. Even if builder creates 50 files using 20K tokens, the scheduler only receives a 3-line summary. Context stays flat regardless of pipeline length:
scheduler's context after 5 TASKs:
PLAN.md (loaded once) ~500 tokens
TASK-00 result: "20 files, PASS" ~200 tokens
TASK-01 result: "15 files, PASS" ~200 tokens
...
Total: ~1,500 tokens (stays flat)
ref-cache
First agent reads shared reference files and returns <ref-cache> in its result XML. Subsequent agents use cached content instead of re-reading from disk. Measured: -64% file reads, -15% tokens in direct mode.
File Structure
works/
├── WORK-LIST.md ← Master index (managed by specifier)
├── WORK-01/
│ ├── Requirement.md ← Requirement specification
│ ├── PLAN.md ← Plan + dependency DAG
│ ├── PROGRESS.md ← Auto-updated progress tracking
│ ├── TASK-00.md ← Task specification
│ ├── TASK-00_progress.md ← Real-time checkpoint (builder)
│ ├── TASK-00_result.md ← Completion report (committer)
│ └── ...
└── _COMPLETED/ ← Archived WORKs (moved on push)
Installation
npm CLI
npm install -g uctm
cd your-project
uctm init --lang en # English agents
uctm init --lang ko # 한국어 에이전트
uctm init # Interactive language selection
Manual
git clone https://github.com/UCJung/uc-taskmanager-claude-agent.git /tmp/uc-tm
mkdir -p .claude/agents
cp /tmp/uc-tm/agents/en/*.md .claude/agents/ # or agents/ko/ for Korean
rm -rf /tmp/uc-tm
git add .claude/agents/ && git commit -m "chore: add uc-taskmanager agents"
Verify
claude
> /agents
# specifier, planner, scheduler, builder, verifier, committer → confirm all 6

Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.