DEV Community

UC Jung
UC Jung

Posted on

uc-taskmanager: Updates to my dev WORK-PIPELINE agent for Claude Code

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.
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Medium task (pipeline mode)

> [bugfix] Fix the login button not responding on mobile
Enter fullscreen mode Exit fullscreen mode

Complex feature (full mode)

> [new-feature] Build a comment feature for the blog system
Enter fullscreen mode Exit fullscreen mode

The pipeline runs with approval checkpoints:

  1. Requirement analysis → review Requirement.md → approve
  2. WORK plan + TASK decomposition → review PLAN.md + DAG → approve
  3. Per-TASK execution → builder → verifier → committer (automatic)
  4. Done → verify via result files, then push

Skip approvals? Add "auto":

> [new-feature] Build a comment feature — auto
Enter fullscreen mode Exit fullscreen mode

Resume after failure?

> Resume WORK-02 from where it stopped
Enter fullscreen mode Exit fullscreen mode

Rollback a WORK?

> WORK-02 rollback
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

Verify

claude
> /agents
# specifier, planner, scheduler, builder, verifier, committer → confirm all 6
Enter fullscreen mode Exit fullscreen mode

Top comments (1)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.