Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/affaan-m/ECC/llms.txt

Use this file to discover all available pages before exploring further.

Running one agent in one terminal is the baseline. ECC’s orchestration layer lets you run many agents in parallel — each scoped to its own git worktree, coordinated through tmux panes, and supervised by PM2 process management. The goal is not to add arbitrary parallelism, but to make the right amount of parallelism trivial to set up and safe to run.

​
What the Orchestration Module Provides

The orchestration module (installed via --profile developer or --modules orchestration) adds four categories of capability:
  1. The orch-* command family — gated, multi-phase pipelines for common engineering workflows
  2. The multi-* command family — multi-agent task decomposition and parallel execution
  3. The epic-* command family — GitHub-coordinated epic lifecycle management
  4. CLI tools — npx ecc orchestrate:status and npx ecc orchestrate:tmux for worktree state inspection
The multi-* commands (/multi-plan, /multi-execute, /multi-backend, /multi-frontend, /multi-workflow) also require the ccg-workflow runtime. Initialize it with npx ccg-workflow before using these commands. Without it, the commands will not run correctly.

​
The orch-* Command Family

The orch-* commands are orchestrated, gated pipelines. Each one runs a fixed sequence of phases — Research → Plan → TDD → Review → Commit — and stops at explicit gates before proceeding. Gates require your approval before the pipeline writes implementation code (Gate 1) or commits (Gate 2).
CommandPurpose
/orch-add-feature <description>Adds a new feature end-to-end: research, plan, TDD, review, gated commit
/orch-build-mvp <description>Scaffolds and builds an MVP from a description
/orch-change-feature <description>Modifies an existing feature with the same gated pipeline
/orch-fix-defect <description>Orchestrated bug fix: write a failing test first, then fix, review
/orch-refine-code <description>Code refinement pass: refactor, simplify, remove dead code
/orch-review <description>Orchestrated review without code changes
All orch-* commands run through the shared orch-pipeline engine. They classify the request size, state the tier, and enforce both gates before writing a single line of implementation. 
# Example: add OAuth2 login
/orch-add-feature add OAuth2 login with Google provider

# The pipeline will:
# 1. Classify size (small/medium/large) and state the tier
# 2. Research existing patterns → produce a task list
# ── GATE 1: approve the plan before any implementation ──
# 3. TDD each task (red → green), then run code-reviewer
# 4. Produce conventional feat: commits
# ── GATE 2: confirm before committing ──

​
The multi-* Command Family

The multi-* commands coordinate multiple agents working in parallel on decomposed tasks. Each command focuses on a specific dimension of a project:
CommandPurpose
/multi-plan <objective>Decompose a task into parallel sub-tasks for multiple agents
/multi-execute <plan>Execute a multi-agent plan with coordinated agents
/multi-backend <objective>Backend-focused multi-service orchestration
/multi-frontend <objective>Frontend-focused multi-service orchestration
/multi-workflow <objective>General multi-service workflow across the full stack
/pm2 <service>Auto-generate PM2 service lifecycle commands

​
The Epic Workflow

For larger units of work tracked in GitHub issues, ECC provides a epic-* lifecycle:
CommandPurpose
/epic-decompose <issue>Break an epic into task children without creating task branches
/epic-claim <issue>Claim an epic issue, stamp coordination state, and sync local ownership
/epic-validate <issue>Validate epic completion criteria
/epic-publish <issue>Publish the epic result
/epic-review <issue>Review an epic in progress
/epic-sync <issue>Sync local coordination state with GitHub
/epic-unblock <issue>Resolve blockers on a claimed epic
The epic workflow stores decomposition and coordination state in the local SQLite state store and appends audit comments to the GitHub issue. Use ecc work-items sync-github --repo owner/repo to pull GitHub issue and PR state into the state store for ecc status to surface.

​
Worktree Lifecycle

Git worktrees let multiple Claude Code instances work on different branches of the same repository simultaneously without conflicts. ECC’s tmux-worktree-orchestrator.js manages the lifecycle: creating worktrees, launching Claude instances in the right panes, and tearing down cleanly when work completes.

​
Inspect Orchestration State

# Check active orchestration sessions and worktree state
npx ecc orchestrate:status

# Show the tmux layout for active orchestrated sessions
npx ecc orchestrate:tmux

​
Manual Worktree Setup

For manual parallel work before using the orchestrator: 
# Create separate worktrees for parallel features
git worktree add ../project-feature-a feature-a
git worktree add ../project-feature-b feature-b

# Run a separate Claude Code instance in each worktree
cd ../project-feature-a && claude
When multiple Claude Code instances work on overlapping code, always use git worktrees and define a clear scope for each. Use /rename <name> to label your chat sessions. The most common orchestration mistake is running two instances on the same working tree — they will conflict on file edits.

​
PM2 for Parallel Agents

PM2 manages long-running Node.js processes and is the recommended way to run persistent multi-agent workflows. The /pm2 command auto-generates PM2 service lifecycle commands from a natural language description of your services. 
# Example: start a three-service stack under PM2
/pm2 start frontend on port 3000, API on port 8000, worker queue

# PM2 generates:
# pm2 start "npm run dev" --name frontend
# pm2 start "npm run api" --name api
# pm2 start "npm run worker" --name worker
# pm2 save

​
DevFleet MCP for Multi-Agent Coordination

For advanced multi-agent worktree coordination, the devfleet MCP server dispatches parallel Claude Code agents in isolated worktrees from a single orchestrator session: 
{
  "devfleet": {
    "type": "http",
    "url": "http://localhost:18801/mcp"
  }
}
DevFleet exposes tools for planning projects, auto-chaining agent missions, and reading structured reports from each worker. See the MCP Servers guide for setup details.

​
Complete Orchestrated Feature Workflow

1

Consult ECC to find the right components

Before starting, verify ECC has the right skills installed for your task:
npx ecc consult "add OAuth2 login" --target claude
2

Decompose the work (optional, for large features)

For features that span multiple subsystems, decompose into tasks first:
/multi-plan "Add OAuth2 login with Google, GitHub, and email providers"
This produces a task breakdown you can assign to parallel agents or use as the input to an orch-* command.
3

Launch the orchestrated pipeline

Start the orch-add-feature pipeline with your feature description:
/orch-add-feature add OAuth2 login with Google provider
The pipeline classifies the request size and begins the research phase.
4

Approve Gate 1 (the plan)

Review the task list and implementation plan the pipeline produces. This is your last chance to correct scope before any code is written.Approve or request changes. The pipeline waits for explicit confirmation.
5

TDD phase runs automatically

Once you approve Gate 1, the pipeline writes failing tests for each task, implements the minimum code to make them pass, then runs the code-reviewer agent (and security-reviewer if security surfaces are touched).
6

Approve Gate 2 (the commit)

Review the implementation and review comments. Approve Gate 2 to produce conventional feat: commits. You can request changes before committing.
7

Monitor orchestration state

At any point, check the state of active orchestration sessions:
npx ecc orchestrate:status
npx ecc status --markdown

​
Control Pane

ECC 2.0 ships an operator control pane — a local dashboard for monitoring session state, work items, skill-run health, and install health across all active sessions: 
npx ecc control-pane
# or with a custom port:
npx ecc control-pane --port 8765
The control pane exposes the same data surfaced by npx ecc status but as a live web UI. It is part of the ECC2 substrate (the Rust control-plane, session adapters, and MCP inventory) introduced in v2.0.0.

​
Parallelization Guidelines

The addition of a new agent terminal should be out of true necessity — not habit. Start with the minimum viable amount of parallelism. Add an instance only when a specific task is genuinely independent and blocked by waiting.Main chat: code changes and implementation
Forks / additional instances: questions about the codebase, research on external services, parallel independent feature branches
When running three or more instances, use the cascade pattern: open new tasks in new tabs to the right, sweep left to right (oldest to newest), and focus on at most three to four tasks at a time. Use /rename <name> to keep your sessions identifiable.

Build docs developers (and LLMs) love

Get started for freeTalk to us