Subagents

CurdX Flow ships nine specialist subagents. Each one has a narrow responsibility, runs in its own context window, and is invoked automatically by the coordinator commands. You do not call them directly — but understanding what they do helps you write better goals and review their output.

Why Specialist Subagents

Most multi-agent frameworks layer many generic agents over a single conversation. The result is more tokens, longer waits, and a pipeline that is hard to audit when something goes wrong.

Flow makes a different bet: one specialist per phase, fresh context each time. Each subagent gets only the inputs it needs (goal, prior artifacts, relevant skills), produces exactly one output, and then exits. No multi-agent orchestration salad.

Subagent Pipeline

The Nine Subagents

Phase Owners

These five own a phase end-to-end and produce a canonical artifact.

Subagent	Phase	Output
research-analyst	Research	research.md
product-manager	Requirements	requirements.md
architect-reviewer	Design	design.md
task-planner	Tasks	tasks.md
spec-executor	Implement	code, tests, commits

Auxiliary

These four support the pipeline at quality gates and during epic decomposition.

Subagent	Role
spec-reviewer	Read-only reviewer that validates artifacts against type-specific rubrics. Outputs REVIEW_PASS or REVIEW_FAIL.
qa-engineer	Runs verification commands at quality gates. Outputs VERIFICATION_PASS or VERIFICATION_FAIL.
refactor-specialist	Updates spec files section-by-section after execution surfaces design drift. Used by /curdx-flow:refactor.
triage-analyst	Decomposes a large feature into multiple dependency-aware specs (an epic graph). Used by /curdx-flow:triage.

Recommended Mental Model

Think of the pipeline like a small team:

1. The research analyst reads everything and writes the briefing.
2. The product manager turns the briefing into testable requirements.
3. The architect decides how the requirements will be built.
4. The task planner breaks the design into a checklist with verification gates.
5. The executor runs the checklist and commits the code.

The auxiliary agents are quality and process — they review, verify, and reshape the spec when reality intervenes.

Common Workflows

A normal spec walkthrough

/curdx-flow:start         # interview + research-analyst (parallel team)
/curdx-flow:requirements  # product-manager
/curdx-flow:design        # architect-reviewer
/curdx-flow:tasks         # task-planner
/curdx-flow:implement     # spec-executor (autonomous loop with qa-engineer at every VERIFY gate)

When the spec needs revision after execution starts

/curdx-flow:cancel        # halt the loop
/curdx-flow:refactor      # refactor-specialist walks requirements → design → tasks
/curdx-flow:implement     # resume

Decomposing a feature too big for one spec

/curdx-flow:triage        # triage-analyst produces epic.md and child specs
/curdx-flow:start         # work the first child spec normally

Power User Tips

• Ask for the outcome in plain English. The coordinator picks the right subagent.
• If a subagent's output disappoints, the issue is usually upstream. Bad research → bad requirements → bad design.
• Use /curdx-flow:refactor rather than editing artifacts by hand. The auxiliary refactor-specialist walks the chain consistently.
• Keep tasks fine-grained. The spec-executor is happiest when each task maps to a single, verifiable change.