Why I Built This
The reason I created a sub-agent called uc-taskmanager was simple: when I just gave instructions and handed off requirements, the only thing left after development was the code itself. There was no trace of what was analyzed, what decisions were made, or what was modified. Nothing was recorded.
So I built a sub-agent that runs inside Claude Code, broke the process into stages, and made each stage produce deliverables as output.
Then I realized — if this workflow only runs through the Claude Code CLI, it wouldn't be accessible to most people. So I thought: what if you could just enter a requirement, review it, approve it, and hit execute — and the sub-agent would run automatically, with all results recorded? That's how UC TeamSpace was born.
There's still a long road ahead. I've already added a Specifier agent to uc-taskmanager that takes requirements written in plain human language and turns them into detailed specifications for review. But I haven't integrated that into UC TeamSpace yet.
I'm the kind of person who wants to be lazy. But every time I save some time by building something like this, I end up thinking of the next thing to build. When will I finally get to be lazy? When I'm in the grave, maybe?
Register a single requirement, and AI agents automatically handle analysis → planning → implementation → verification.
This post walks through the entire process of handling REQ-133 in a live UC TeamSpace instance, with screenshots.
Background: Why This Pipeline Exists
The most time-consuming phase in software development is the transition from "interpreting requirements → design → implementation." Reading requirement documents, identifying the scope of impact, decomposing work, and writing code demands significant time and focus — even from senior developers.
UC TaskManager automates this transition with a 6-Agent SDD (Spec-Driven Development) pipeline:
Specifier → Planner → Scheduler → Builder → Verifier → Committer
UC TeamSpace integrates this pipeline with a web-based requirements management system, enabling the entire lifecycle — from requirement registration to code commit — to be managed within a single UI.
In this post, we'll show how a single functional requirement (REQ-133) flows from registration to completed implementation, illustrated with 10 screenshots.
Demo Target: REQ-133
| Field | Value |
|---|---|
| REQ ID | REQ-133 |
| Title | Added individual REQ execution timeout settings and unlimited options |
| Project | DX Common |
| Priority | P1 |
| Category | Functional requirements |
| Author | UC Jung |
| Date written | 2026-03-23 |
Requirement summary: Currently, execution timeouts can only be set at the CliProfile level (default 30 minutes), and it is not possible to specify different timeouts per individual REQ or run them indefinitely. For large-scale WORKs such as KPI calculations, execution cannot complete within 30 minutes, causing repeated timeout failures.
Step 1. Requirement Registration — Draft
REQ-133 is authored in the Requirements Management screen. The status is Draft.
The requirement body is written in a structured markdown format:
- Outline: Overall summary
- Current problem: Current issues (4 specific problems listed)
-
Requirements: 3 concrete requirements
- Individual REQ Timeout Settings — Add a
timeoutMinutesfield per REQ - Unlimited Option — Execute without timeout when
timeoutMinutes = 0ornull - Priority System — REQ individual setting > CliProfile setting > Default (30 min)
- Individual REQ Timeout Settings — Add a
This structured requirement becomes the direct input for the AI agents. The quality of the requirement directly determines the quality of the auto-generated code.
Step 2. Managing Requirements in the List View
This is the requirements list screen. Requirements from REQ-141 to REQ-130 are displayed, with each item's status (situation), priority, and classification visible at a glance.
REQ-133 is currently in Draft status, assigned to the "DX Common" project. Most other REQs are already in complete status — items that have been processed through this pipeline.
Step 3. Review Request and Approval — Waiting for Execution → Approved
From the Draft state, submitting a Request for review transitions the status to Waiting for execution. A reviewer checks the completeness and feasibility of the requirement.
Once the review passes, the status changes to Approved, and the ▶ Execution Request button becomes active in the top bar. The requirement is now ready for AI pipeline execution.
Step 4. Execution Settings — Specifying the Project Root Path
Clicking the ▶ Execution Request button opens the execution settings dialog.
The key setting is the Project root path. This path (/home/pntadmin/rnd/uc-teamspace) points to the actual project directory where Claude Code CLI will operate. All pipeline agents read, analyze, and modify source code relative to this path.
Clicking ▶ Execution Request starts the pipeline.
Step 5. Pipeline Execution — Execution Monitor
5-1. Start: SPECIFIER Phase
The Execution Monitor displays the pipeline progress in real time.
0000 [2026-03-30 13:39:51] CLAIM START
0001 [RUNNER] Start Claude Code auto-run
The system claims the requirement, and Claude Code begins auto-execution. The [RUNNER] Delivery prompt includes the full requirement body, list of files to modify, execution environment info, and callback API details.
The Execution Information section at the bottom shows execution metadata:
-
Execution ID:
cmncp8juo000... - Performer: UC Jung
- Start time: March 30, 2026, 1:39:51 PM
-
Project path:
/home/---------/rnd/uc-teamspace - Maximum turns: 50
- Timeout: 180 minutes
5-2. Progress: SPECIFIER DONE → PLANNER START
Once the SPECIFIER finishes analyzing the requirement (SPECIFIER DONE), the PLANNER phase starts automatically.
0005 [2026-03-30 13:43:16] [SPECIFIER][REQ-133] DONE
0006 PLANNER REQ-133 START
At each stage transition, progress is reported back to UC TeamSpace in real time via the callback API:
POST http://192.168.0.101/api/v1/cli-executions/{id}/callback
SCHEDULER → BUILDER → VERIFIER → COMMITTER then execute sequentially, with each agent receiving the previous agent's output as input.
Step 6. Execution Results — Result Document
When the pipeline completes, the Result document tab displays all deliverables.
The right panel shows the result document tree:
WORK-148 (2026. 3. 30. 1:51:30 PM)
├── PLAN.md
├── TASK-00 (Plan) / TASK-00 (Result)
├── TASK-01 (Plan) / TASK-01 (Result)
└── TASK-02 (Plan) / TASK-02 (Result)
The current view shows the details of TASK-01: Modify Backend Logic:
Scope:
-
DTO modification — Add
timeoutMinutesfield toCreateRequirementDto/UpdateRequirementDto -
Execution service logic — Apply REQ > DTO > CliProfile > default (30 min) priority in
cli-execution.service.ts -
Cleanup Service — Exclude executions with
timeoutMinutes=0from stuck checks inexecution-cleanup.service.ts -
Runner — Skip timer registration when
timeoutMinutes=0inrunner.ts, null-safeclearTimeouthandling
The Files table shows each target file with its action (MODIFY) and description in a structured format. The AI agents automatically modify code according to this plan, verify it, and commit the changes.
Step 7. Result Review — Awaiting Review
After pipeline execution completes, the status transitions to Awaiting review. Three action buttons appear at the top:
- Review rejected — Reject if the deliverables are insufficient
- Review and approval — Approve the review, authorize code merge
- Forced completion — Force-complete the process
The reviewer examines the PLAN and each TASK Result in the Result document, reviews the actual code changes, and decides to approve or reject.
REQ-133 also appears as Awaiting review in the requirements list, giving the entire team visibility into its progress.
When Review and approval is selected, the corresponding WORK automatically performs a git push and its status transitions to COMPLETED. In other words, a single approval from the reviewer pushes the code to the repository and finalizes the work.
Complete Workflow Summary
[Draft] → [Request for Review] → [Waiting for Execution]
↓
[Approved]
↓
[Execution Request]
↓
┌─── Execution Monitor ───┐
│ SPECIFIER → PLANNER │
│ → SCHEDULER → BUILDER │
│ → VERIFIER → COMMITTER │
└──────────────────────────┘
↓
[Awaiting Review]
↓ ↓
[Approved] [Rejected]
↓
[Complete]
Key Takeaways
1. The Requirement IS the Design Document
Structured requirements registered in UC TeamSpace become the direct input for AI agents. There is no need for separate design documents or manual work decomposition. Since the clarity of the requirement directly determines the quality of the output, writing a good requirement becomes the most important development activity.
2. Real-Time Monitoring with Callback-Based Tracking
The Execution Monitor lets you see the start/completion of each agent phase in real time. Callback APIs enable integration with external systems. If execution stalls or something goes wrong, you can immediately identify it and halt with Stop execution.
3. Structured Deliverables with Full Traceability
All pipeline deliverables (PLAN.md, per-TASK Plan/Result) are stored linked to their originating requirement. You get complete traceability: who, when, for which requirement, and what code changes were made.
4. Human Judgment Where It Matters
The pipeline automates "analysis → planning → implementation → verification," but final approval remains a human decision. The Awaiting review stage, where a reviewer checks the code and decides to approve or reject, maintains the balance between AI automation and human judgment.
Results by the Numbers (It's guessing.)
| Metric | Before (Manual) | After (Pipeline) | Improvement |
|---|---|---|---|
| Team size | 3 people | 1 (senior) | 67% reduction |
| Duration | 2.5–3.5 weeks | 3–5 days | 80%+ shorter |
| Cost | ~11.9M KRW | ~1.9M KRW | 84% reduction |
| M/M | Baseline | — | 90% reduction |
Based on senior developer rate premium of 1.5–1.8×, including 3–5 verification cycles
Closing Thoughts
What this demo shows is not just automated code generation. It's the automation of the entire development lifecycle: requirement management → AI pipeline execution → code review → approval.
UC TeamSpace manages "what to build," and UC TaskManager executes "how to build it." Developers focus on improving the quality of requirements, and AI faithfully implements them.
Vibe Coding is fast and intuitive, but it has fundamental limitations: no artifact management, skipped quality verification, and zero reproducibility. UC TeamSpace × UC TaskManager addresses these problems head-on. On top of an automated development process, anyone can perform development through a web service alone — without ever knowing Claude Code CLI — and every development artifact is stored without exception, linked to its originating requirement.
Found errors in the results? Test during the review stage, register the discovered issues as new requirements, and run the pipeline again. Sure, complex requirements may produce many errors in a single execution. But the same thing happens when human developers do it too. The difference is that in this pipeline, bug fixes follow the exact same automated process, and even that process is recorded as deliverables.
Do you really need to learn Claude CLI or the terminal? Just a browser — write a requirement, click a button, review the results. What do you think?
UC TeamSpace is currently in use internally but has not been open-sourced yet. There are still rough edges from all the experimental development, so it needs more polish. I plan to open-source it once things are more settled.
Author: UC Jung (mykumi@gmail.com)
Top comments (0)