16 agents. 4 features. 131 tests. 13 minutes.
Command Claude Code. Conquer.
CommandCC is a military-grade orchestration system for Claude Code. One human commands 16 to 128 AI agents from a single terminal. You type objectives. The system deploys a coordinated fleet of specialized agents across parallel waves. You read the battle map when it is done.
This is not a framework. This is a doctrine.
The operator typed four sentences. The system deployed 16 agents across 4 phases. When the operation completed 13 minutes later, 4 features had been implemented with 131 tests, all passing. Human cognitive load compression: 200x.
| Metric | Value |
|---|---|
| Human input | ~4 sentences |
| Agents deployed | 16 |
| Features implemented | 4 |
| Tests written | 131 |
| Tests passing | 131 |
| Wall clock time | 13 minutes |
| Cognitive load compression | 200x |
See BATTLE-MAP-OPBLITZ3.md for the full record. See examples/OPBLITZ3/ for the complete walkthrough.
Nine sequential phases. Each phase fans out into parallel agents, then collapses into a shared artifact before the next phase begins. The arms of the octopus are your agents. The spine is the artifact chain.
OPERATOR
|
_______________v_______________
| |
| Phase 0: RECON |
| [scout] [scout] [scout] ... | <- Haiku, READ-ONLY, 30s
|_______________________________|
|
RECON-REPORT.md
|
_______________v_______________
| |
| Phase 1: STRATEGY |
| [strategist] | <- Opus, 2 min
|_______________________________|
|
OPERATION-PLAN.md
|
_______________v_______________
| |
| Phase 2: DECOMPOSE |
| [decomposer] | <- Opus, THE MULTIPLIER
|_______________________________|
| | | |
_____| | | |_____
| | | |
ARCH-1 ARCH-2 ARCH-3 ARCH-4
|
__________v__________
| Phase 3: ARCH |
| [arch][arch][arch] | <- Opus parallel, 3 min
|_____________________|
|
__________v__________
| Phase 4: BUILD |
| [bld] [bld] [bld] | <- Sonnet parallel, 5 min
|_____________________|
|
__________v__________
| Phase 5: WIRE |
| [wire][wire][wire] | <- Sonnet parallel, 3 min
|_____________________|
|
__________v__________
| Phase 6: TEST |
| [tst] [tst] [tst] | <- Sonnet parallel, 3 min
|_____________________|
|
__________v__________
| Phase 7: REVIEW |
| [rev] [rev] [rev] | <- Opus parallel, 2 min
|_____________________|
|
__________v__________
| Phase 8: INTEGRATE |
| [integrator] | <- Opus, 2 min
|_____________________|
|
BATTLE-MAP.md
|
OPERATOR
Three tiers. Each tier has a defined role, model, and access profile. Agents do not improvise outside their tier.
| Tier | Model | Role | Access | Agents | Count |
|---|---|---|---|---|---|
| COMMAND | Opus | Think, strategize, design, review | READ-ONLY | strategist, decomposer, integrator, architects, reviewers | 2-6 per op |
| OPERATIONS | Sonnet | Build, wire, implement, test | FULL R/W | builders, wirers, testers | 4-64 per op |
| RECON | Haiku | Scan, check, report | READ-ONLY | scouts | 4-16 per op |
Command tier never writes application code. It writes plans. Operations tier never modifies plans. It executes them. Recon tier never writes anything. It observes and reports.
The Decomposer is the key innovation in CommandCC. It is a single Opus agent that sits between strategy and architecture and turns sequential work into massively parallel work.
One objective becomes four independent sub-objectives. Four independent sub-objectives become four architect tracks. Four architect tracks become sixteen builder slots.
The Decomposer's only job is to find the natural fault lines in a problem and split along them, guaranteeing that no two sub-objectives share a file, a component, or a dependency. Downstream agents can run fully in parallel because the Decomposer has already proven they cannot interfere with each other.
Human types 4 objectives (4 sentences)
|
v
Decomposer produces 3 sub-objectives per objective = 12 sub-objectives
|
v
Each sub-objective gets:
- 1 architect = 12 architects
- 1 builder = 12 builders
- 1 wirer = 12 wirers (some shared)
- 1 tester = 12 testers
- 1 reviewer = 12 reviewers
|
v
12 x 5 roles = 60 execution agents
+ recon scouts (4) + strategist (1) + decomposer (1) + integrator (1) = overhead 7
|
v
TOTAL: ~67 agents from 4 sentences
At maximum decomposition (4 sub-objectives per objective, 16 input objectives), CommandCC deploys 128+ agents from a single operation trigger.
# Clone the repo
git clone https://github.com/axlprotocol/commandcc
cd your-project
# Copy agent definitions
mkdir -p .claude/agents
cp -r /path/to/commandcc/agents/* .claude/agents/mkdir -p .claude/commands
cp /path/to/commandcc/operations/feature-deploy.md .claude/commands/feature-deploy.mdOpen Claude Code in your project:
claudeThen trigger the operation:
/feature-deploy Add user authentication, payment processing, email notifications, and admin dashboard
That is it. The fleet deploys. Read the battle map when it is done.
Eight operations ready to use. Copy any to .claude/commands/.
| Command | Pattern | Purpose | Time |
|---|---|---|---|
/feature-deploy |
9-phase octopus | Deploy 1-8 features in parallel | ~22 min |
/feature-deploy-lite |
4-phase | 1-2 features, faster path | ~10 min |
/security-audit |
6-phase | Full OWASP security sweep | ~18 min |
/codebase-migration |
7-phase | Migrate framework X to Y | ~25 min |
/research-sprint |
4-phase | Research N topics, synthesize | ~12 min |
/test-blitz |
5-phase | Comprehensive test coverage | ~15 min |
/documentation-sprint |
5-phase | Document all modules | ~15 min |
/refactor-sweep |
6-phase | Refactor N modules in parallel | ~20 min |
/incident-response |
FAST TRACK | Diagnose and fix production incident | ~8 min |
Agents organized into 7 categories. Drop any into .claude/agents/.
COMMAND
command/strategist-- Operation planning from reconcommand/decomposer-- The Multiplier. Breaks objectives into parallel sub-objectivescommand/integrator-- Assembles BATTLE-MAP.md from all review outputs
ARCHITECT
architect/system-architect-- Full system design documentsarchitect/security-architect-- Threat model and security designarchitect/data-architect-- Schema, migration, and data flow designarchitect/api-architect-- API contract and interface design
BUILDER
builder/backend-builder-- Server-side implementationbuilder/frontend-builder-- UI and client-side implementationbuilder/api-builder-- API endpoints and middlewarebuilder/database-builder-- Schema and migration executionbuilder/infra-builder-- Infrastructure, Docker, CI/CD
WIRER
wirer/import-wirer-- Resolves import paths after parallel buildswirer/config-wirer-- Merges config files and env variableswirer/startup-wirer-- Service registration and startup ordering
TESTER
tester/unit-tester-- Unit test suites per sub-objectivetester/integration-tester-- Cross-service integration teststester/security-tester-- Vulnerability and auth testingtester/load-tester-- Performance and load testing
REVIEWER
reviewer/code-reviewer-- Code quality and correctnessreviewer/security-reviewer-- Security posture reviewreviewer/architecture-reviewer-- Architecture conformancereviewer/compliance-reviewer-- Compliance and standards
SCOUT (Haiku, READ-ONLY)
scout/codebase-scout-- File structure and code mapscout/dependency-scout-- Dependency versions and conflictsscout/security-scout-- Quick vulnerability scanscout/test-scout-- Existing test coverage map
For multi-server deployments, the C2 (Command and Control) server acts as the REST backbone for your agent fleet. Units check in from separate machines, receive orders, and submit reports through a shared file-based message store.
The C2 server provides 6 MCP tools to every connected unit:
c2_checkin-- Register unit and receive current operation ordersc2_sitrep-- Submit a situation reportc2_receive_orders-- Pull latest FRAGO or updated objectivesc2_submit_report-- Push completed artifacts to the C2 storec2_request_resource-- Request a file or artifact from another unitc2_broadcast-- Send a message to all units in the fleet
See docs/c2-setup.md for installation and configuration.
| Document | What It Covers |
|---|---|
| docs/getting-started.md | Step-by-step setup with a concrete example |
| docs/writing-operations.md | How to write custom operations |
| docs/writing-agents.md | How to write custom agents |
| docs/c2-setup.md | C2 server for multi-machine deployments |
| doctrine/ | The full doctrine manual: chain of command, wave structure, message types |
| examples/OPBLITZ3/ | Full walkthrough of the first operation |
| BATTLE-MAP-OPBLITZ3.md | The actual battle map from OPBLITZ3 |
Most multi-agent systems fail at scale because they treat agents as peers that coordinate with each other. Coordination between agents creates latency, confusion, and compounding failures.
CommandCC borrows from military doctrine: agents do not coordinate with each other. They coordinate through artifacts. Every agent reads a file, produces a file, and exits. The next agent reads that file. There is no runtime coupling, no message passing, no shared state that can deadlock.
The result is a system that is:
- Auditable. Every decision is a file. The operator can read the entire operation history in order.
- Restartable. If an agent fails, the file it was supposed to produce is absent. The orchestrator re-runs that agent. No lost state.
- Interruptible. The operator can edit any plan file between phases and inject updated orders. The next wave reads the updated file.
- Scalable. Adding more objectives scales linearly. The decomposer adds more sub-objectives. The build phase adds more agents. The 10-agent parallel limit is handled by batching.
Apache 2.0. See LICENSE.
Built by AXL Protocol. CommandCC built itself using its own pattern. See examples/OPBLITZ3/BATTLE-MAP.md for the GENESIS battle map.
