/run — Execute Tasks with Agents

A one-shot prompt asks the model in one turn and ships whatever comes back. /run runs the same task through a pipeline, because four agents reading a single brief produce more reliable work than one agent guessing from a chat scrollback. You describe one deliverable. They figure out how to produce it.

/run is the command you reach for most. It handles the full lifecycle from "here's what I need" to "here's the finished work" without making you babysit each step — and the same pipeline runs whether you're building something new, auditing something finished, measuring something slow, or root-causing something broken. Those last three are not separate commands. They are modes of /run, selected by a flag or by the first word of your request.

What /run does by default

Type /run <task> with no mode flag and you get the standard pipeline. cAgents moves your request through five stages, and you configure none of them.

1. Orchestrator reads your task and enriches it with context — your CLAUDE.md (see Memory in the official docs), the current state of the project, anything downstream agents need to understand the job.

2. Planner decomposes the request into an ordered task list with acceptance criteria. Even a simple-sounding request breaks into dozens of work items with a dependency graph; independent items run in parallel.

3. Controller coordinates execution. It never writes code or content itself — it questions specialist agents, hands each one the slice of context it needs, and synthesizes the results in dependency order.

4. Two-stage review runs on every work item. Stage 1 checks spec compliance and cites file:line without judging quality; Stage 2 grades code quality and only sends an item back when it finds a CRITICAL issue or two or more HIGH ones. Each item carries a confidence score from 0.0 to 1.0; anything below 0.7 triggers stricter review.

5. Validator checks the finished work against the plan's acceptance criteria and returns PASS, FAIL, or REVISE before the result reaches you.

The panel on the right has the prompt that scopes a single deliverable into a brief, dry-runs the plan, and runs the pipeline end to end.

When /run standard is the right call

Standard /run fits single-scope tasks with a clear output:

• Implement a specific feature or component
• Write one piece of content — an article, a report, a spec, an email
• Fix a bug whose fix you can already describe
• Refactor or clean up a module
• Generate tests for an existing file
• Build a configuration or scaffolding

Reach for /team instead when you have three or more independent items that could run at the same time — three separate pages, five blog posts. Standard /run handles them sequentially; /team runs them in parallel and adds wave-based quality gates. /team also owns cross-domain work that spans engineering and marketing and legal. When in doubt, start with /run — it is the right call far more often than not.

/run Build the homepage and navigation from the design spec in design-spec.md

The keyword router and the four modes

The first word of your request can set the mode for you. Lead with review, audit, optimize, or improve and /run switches to the matching mode automatically — /run review src/auth/ is identical to /run src/auth/ --mode review. You can always be explicit with --mode instead.

The rest of this article walks each mode. They share the standard pipeline's plumbing — orchestrator, controller, validator, sessions on disk — so once you understand standard /run, each mode is a different lens on the same machine.

Review mode: audit without touching anything

A passing test tells you the code runs. /run review tells you whether it's good, because running is a lower bar than secure, accessible, consistent, maintainable — and the gap between the two is where most projects rot in their second year.

Review mode spawns specialist reviewers in parallel — a security-engineer, a code-reviewer or qa-lead, a performance-analyzer, plus whatever else the artifact calls for — and consolidates their findings into one report ordered by severity. The defining constraint is that review mode makes no changes. It reads, grades, and reports. Each finding carries a severity tag (CRITICAL, HIGH, LOW) and a file:line location so you can act on it without hunting.

Reach for review mode anywhere you need external eyes on finished or near-finished work: before merging a significant change, after a large refactor, as the gate before a launch, or when auditing an area you're not confident in. The simplest pairing in the whole toolset is /run to build it, /run review to check it.

When you pass --auto-fix, review mode resolves the findings it is confident about — usually CRITICAL and HIGH patches like a missing security header, a vulnerable dependency, or missing alt text — and flags the rest for manual attention. The panel on the right has the full arc: scope the review, run it, triage the report by severity, auto-fix the confident findings, and route the manual ones back through /run or /run optimize.

/run review Run a comprehensive quality audit of the portfolio site — security, accessibility, SEO, and code quality

A clean report is not a guarantee. Review mode catches what it knows to look for; it does not replace manual security testing for high-stakes systems, accessibility testing with real assistive-technology users, or domain review by someone who understands your code. Use it to catch the systematic and the obvious, and layer human judgment on top of anything critical.

Optimize mode: measure, change, prove

Standard /run does the work. /run optimize does the work and proves it, because the difference between "I think that fixed it" and "LCP dropped from 4.8s to 1.9s" is a number on the table.

Optimize mode runs a measured loop. It detects issues across the relevant surface, captures a baseline before touching anything, applies fixes from highest expected impact to lowest, verifies by re-measuring after each one, and rolls back any fix that fails to improve the metric — automatically, before moving on. What you get is a before/after report showing exactly what changed and by how much. You don't have to take the agent's word for it; the numbers are in the report.

Reach for optimize mode when the problem is real but diffuse — a page that loads slowly without one obvious cause, a bundle that grew, queries running long, engagement that's underperforming — or when you need to show measurable improvement to someone else. Reach for standard /run instead when the fix is obvious and you don't need before/after proof: a typo in a query, a known dependency to drop, one config value to change.

The most important thing optimize mode does is refuse a fix that would move the number while breaking what the number is for. A metric win that fabricates evidence, undermines a learning objective, or breaks a brand promise gets rolled back the same way a CSS change that spikes layout shift does — the rollback works on integrity, not just on code metrics. The panel on the right walks the optimize brief, the dry-run, the verified deltas, and the rollback audit that confirms your principle constraints held.

Optimize mode changes local files and measures what it can measure locally; it does not push or publish, and deployment is a separate step. For code and assets it can measure the improvement immediately. For content — headlines, CTAs, email copy — the before/after is about quality signals, not live campaign data; you still run the next campaign and compare, and the panel's last step plans that next-round measurement.

Debug mode: root cause before fix

Some bugs are obvious — read the error, find the line, fix it. Standard /run handles those. Then there are the bugs that resist a first attempt: no useful error message, intermittent failures, a symptom you can describe but a cause you can't. That is /run --mode debug.

A good rule of thumb decides the mode for you: if you can describe the fix you'd make, use standard /run; if you can only describe the symptom, use debug mode. Debug mode is slower and more thorough, and that thoroughness has a cost — don't reach for it first on every bug.

Debug mode works root cause before solution, in four phases. It maps the failure surface and reads logs before touching anything, looks for the pattern in when the failure happens, forms and tests a ranked list of hypotheses rather than stopping at the first guess, and only then implements a fix and verifies it against the original symptom. Front-load the prompt with everything you know — what you tried, when it started, what changed, any logs — and the investigation moves past its first phase faster.

The move that cracks most cases is a comparison: the same system working in one place and failing in another, with one variable different between them. The panel on the right walks a full debug session — decide whether the bug warrants debug mode, write a context-loaded prompt, read the four phases as they stream, find the diagnostic comparison, name what the investigation could and couldn't see, and verify the fix while writing a lessons-learned note.

Improve mode: review then optimize, one report

/run improve <path> runs review mode and optimize mode back to back and hands you a unified report — the quality findings from the audit and the measured deltas from the optimization in one place. Reach for it when you want both a graded picture of an artifact and proof that the changes you made actually moved the numbers, without running two passes yourself.

Flags worth knowing

These flags apply across the modes; the mode each one belongs to is noted where it matters.

What to watch for

When you're done

Standard /run built the thing. /run review graded it, /run optimize proved the numbers moved, and /run --mode debug traced the failure that no error message explained. One command, four lenses, the same pipeline underneath each.

The tasks here were single deliverables, handed one at a time. But most real work fans out: the homepage needs an about page and a blog, the audit surfaces five fixes that don't depend on each other, the launch needs engineering and marketing and ops moving together. Multiple independent pieces, all ready at once — that is parallel execution.

Next: Part 4 — /team covers running many tasks at once with wave-based quality gates, and the strategic mode that coordinates work across business domains.