Getting Started with cAgents

Most AI tools give you one assistant for one task. You describe what you want, it produces something, you edit it yourself. That model works fine for simple requests. It starts breaking down when tasks are genuinely complex — when "build me a feature" really means plan, design, implement, test, and document, where each phase depends on the last.

cAgents is a multi-agent orchestration plugin for Claude Code that handles this kind of work. Instead of one AI doing everything, cAgents coordinates specialized agents — planners, controllers, executors, validators — each focused on one slice of the work. You describe the outcome you want. cAgents figures out which agents to involve, in what order, and coordinates the work through a five-state pipeline.

That coordination is not free. A single request fans out to 3–10 or more subagents, and a single /run can burn 10–50× the tokens a direct Claude Code prompt would. That is the trade you are making: more agents, more checking, more cost, in exchange for work that holds up on genuinely complex tasks. For a quick single-file edit, skip all of this and talk to Claude Code directly — cAgents is the wrong tool when the job is small.

By the end of this article you've installed the plugin, authored a CLAUDE.md for your project, learned what the four commands do, and picked your first task. The panel on the right carries the copy-pasteable steps; the prose here covers the why.

Install the plugin

cAgents runs on top of Claude Code, Anthropic's CLI for running AI agents in your terminal. Install that first (see Claude Code Quickstart in the official docs), then install the plugin itself — it ships through the Claude Code plugin marketplace (see Plugins in the official docs). The panel on the right has the exact /plugin command and a verification step that reads the install output back to you.

Two requirements decide whether the plugin will register at all:

• Claude Code 2.1.69 or later — plugin support landed in that release, so an older Claude Code will not load cAgents. claude --version tells you where you are.
• Node.js — the hooks that fire before and after every task are .cjs scripts, so Node is what powers cAgents' validation, convention-enforcement, and safety layer (see Hooks in the official docs). The slash commands run without it, but you give up the part of cAgents that catches mistakes for you.

Under the hood, cAgents routes controllers through Opus 4.6, execution through Sonnet 4.6, and support work through Haiku 4.5 — you do not configure any of this, but it is why a /run costs what it costs.

Author your CLAUDE.md

Before you run a single command, give your project a CLAUDE.md at its root. This is the standing memory Claude Code reads on every session (see Memory in the official docs, or claude-code-guide Part 1 for the in-series treatment) — cAgents inherits it for free, because every agent it spawns starts from the same file. Without one, agents infer your project from whatever files they happen to read; with one, they start from a description you wrote.

The file earns its keep on five anchors: what the project is, where things live, what conventions to follow, what stack or medium it uses, and what's off-limits without asking. The test for any line is whether removing it would let an agent make a mistake — if not, it's filler.

A CLAUDE.md for a Next.js app and one for a content-marketing strategy look different, but they hit the same five anchors. The panel on the right runs this as an interview: it scans your project root, picks a technical or non-technical shape from what it finds, drafts the file from your answers, and writes it only when you approve. You don't need it perfect on day one — start with purpose, structure, and conventions, and let it thicken as you work.

The four commands

cAgents adds exactly four slash commands to Claude Code. Two of them do work, one helps you think before the work, and one helps you pick between the other three.

/run is wider than it looks. Past a plain /run <task>, it also carries the review and optimize work as first-class modes — /run review src/auth/ audits a path and reports findings without changing anything, /run optimize <path> benchmarks before and after and rolls back on a regression, and /run --mode debug runs the same pipeline with verbose tracing. Part 3 covers those modes; for now, know that "execute a single task" is one command, not five.

/team is the other end. When the work breaks into independent pieces, /team fires them in waves and validates each wave before the next starts. When the work spans two or more business domains, its strategic mode auto-engages — C-suite agents frame the problem before per-domain dispatch begins. Part 4 covers both shapes.

When you can't decide, ask

/helper is the command you reach for when you don't know which command to reach for. Describe the task in plain language — "I have five blog posts to write that share a style guide," or "I need to fix a flaky test and I've tried twice" — and it points you at the right one, with the reasoning, instead of making you memorize a decision tree. It runs an interactive decision tree by default, or hands you the full catalog with --all. Use it freely; it's cheap, it touches nothing, and it's the fastest way out of "which command was that again."

The panel on the right turns this section into a working interview: it walks the four commands, checks that you can match a task to a command, then applies a four-question rubric to your actual next task and routes you to /designer or /run.

What's next

This series covers each command in depth, following the same two projects through every stage:

1. Getting Started ← you are here
2. /designer — Design Before You Build — Interactive Q&A that turns vague requirements into an implementation-ready spec. Start here before any non-trivial task.
3. /run — Execute Tasks with Agents — The workhorse. Give it a task, it plans and executes. The full pipeline, the review and optimize modes, key flags, and follow-up patterns.
4. /team — Parallel & Cross-Domain Execution — Wave-based parallel execution and the strategic mode for work that spans domains. When and why to use it over /run.
5. Sessions — Under the Hood — How cAgents records every pipeline run on disk, and how --resume picks up where it left off.
6. Hooks — The Event System — The event-driven machinery behind every pipeline.

Next: Part 2 — /designer: Design Before You Build walks the four phases of a design session. If your next task is already clear and you want to skip ahead, the four-question rubric in the panel on the right will tell you whether to go straight to Part 3: /run instead.