cc-master

MISSION CONTROL FOR LONG-HORIZON AGENTS

Give it a big goal —
and a budget.
Then go do something else.

cc-master turns the main agent of any supported coding-agent session into a master orchestrator — a project lead that decomposes your goal into a dependency graph, runs the independent pieces in parallel, paces quota against your real limits, and knows exactly when to stop and ask you.

terminal

installs the ccm engine + the plugin — two independent version lines

Claude Code · Codex · Cursor · kimi-code

goal → dagdonein flightcritical path

a goal, decomposed — the amber chain is the critical path

WHY IT EXISTS

A plain agent dies five deaths on a big job

Hand a multi-day goal to a stock coding agent and you already know how it ends. cc-master is the point-by-point negation of these five deaths.

death 01

It forgets.

Mid-conversation it loses the plot; one context compaction and the mission is gone.

the board — a durable plan that outlives memory

death 02

It serializes.

One thing at a time, spoon-fed. You bought parallelism; you got a queue.

dataflow dispatch — whatever is ready, runs

death 03

It burns.

Head-down into the work, it can torch your quota window in a single afternoon.

pacing — quota is sensed, priced, and budgeted

death 04

It nags — or it wanders.

Pestering you every three sentences, or quietly making the calls that were yours.

a HITL boundary with judgment about which side a call belongs on

death 05

It declares "basically done".

Gate-green ≠ passed. "Looks done" is not done — and it always shows up later.

endpoint verification, by the conductor, in person

Every discipline in cc-master is one of these deaths, answered.

THE PHILOSOPHY

Seven lenses of a master orchestrator

Not rules to obey — the definition of a role, unfolded. A method that any agent, on any harness, can be initialized into.

01

Conduct, don’t play

The orchestrator decomposes, dispatches, verifies, integrates — and never implements. Every beat you spend playing an instrument is the scarcest resource — the attention that holds the whole map — spent on the cheapest work.

“The conductor never plays an instrument.”

02

The goal is a dependency graph

A goal becomes a contract, then a DAG. Every dependency edge is a debt and must justify itself; everything else runs in parallel. Resources lean on the critical path; float is free parallelism.

“Every dependency edge is a debt, guilty until proven innocent.”

03

Dispatch on ready

The moment a dependency is satisfied, the work runs. Never idle at a barrier while the ready set is non-empty. A note on the board is not a dispatch — a real handle is.

“Users buy parallelism.”

04

Be proactive, never idle-wait

Waiting is only legal when every path is suspended on a background task or a pending human answer — and before that, drain the pool of useful work. Arm a watchdog over the silent-failure blind spot.

“Calm now is a scheduling achievement, not slacking’s fig leaf.”

05

Work within capacity

Little’s Law and the utilization cliff: aim for the corridor’s edge, not 100%. Quota signals fail closed. The budget is an asset held in trust, not fuel to burn.

“Budget is an asset held in trust, not your fuel.”

06

Trust only endpoint verification

Self-reports are not evidence; green gates are not proof. The conductor verifies at the endpoint — reads the diff, runs the gate — so that “done” is worth trusting.

“Gate-green ≠ passed.”

07

Ask when you should

The user is a special asynchronous worker. When a call is genuinely theirs, surface it immediately — with a prepared decision package — and keep every independent thread running.

“Judgment is layered; the user never handed over their layer.”

Eight skills, one orchestrator

Each skill owns one plane; none repeats another. Progressive disclosure keeps the soul thin.

master-orchestrator-guide

the soul — decisions, scheduling, red lines

slicing-goals-into-dags

how to cut a goal into a DAG

authoring-workflows

how to write deterministic workflow scripts

using-ccm

the ccm CLI and board operation manual

dev-as-ml-loop

the shape of the execution loop, per task

engineering-with-craft

the craft inside the loop — DDD/OOP/TDD

pacing-and-estimation

reading advisory verdicts, pacing, estimates

distilling-lessons-into-assets

routing lessons into durable assets

THE HUMAN ↔ AGENT PARADIGM

Attention, reallocated

There is no neutral injection: every token in an agent’s context steers the next one. So cc-master treats context as a scarce channel, and labels every message by two axes — who decides, and how hard it should pull on your attention.

<ambient>low

Background. Update your world model and move on — not a to-do. Honest that it still primes you.

<ambient source="usage-pacing">5h window at 62%, reset in 1h 40m</ambient>
<advisory>weak | strong

Advice. Weigh it, reason about its premises — the final call is still yours. Most hook traffic lives here.

<advisory source="usage-pacing" strength="strong">verdict: throttle — burn rate projects a 5h window breach</advisory>
<directive>full

A gate. Obey it — and understand the why it carries, so you can spot a misfire. Reserved for hard constraints; kept rare on purpose.

<directive source="board-guard">board writes go through ccm only — use `ccm task update` (why: the lock + 82 invariants keep the plan trustworthy)</directive>

When a call is genuinely yours, it comes prepared

A decision package arrives with everything you need to decide once, at your convenience: the context, what’s needed from you, why it matters, the options with their tradeoffs — and a freshness check, so you never answer a question the world has already moved past.

See a real one in the viewer
ccm web-viewer · read-only
a decision card in the ccm web-viewer: question, context, options and tradeoffs
D1 — “Split the PR into two?” · context · options · tradeoffs

Explainable by construction

one source of truth

the board is the plan, the memory, and the audit trail — any session can pick it up and resume

read-only mission control

the ccm web-viewer renders the whole operation without touching it

a second verifier, from a different family

high-leverage calls get reviewed by a model of another lineage — same-family echo doesn’t count

the stop-time ledger

wrapping up requires written evidence, path by path — "looks done" cannot close a run

WATCH IT THINK

A mission control for the plan it keeps for you

Every run keeps a live board. The ccm web-viewer renders it read-only on your machine — the graph, the critical path, the decisions waiting on you, the agents in flight.

ccm web-viewer · live
a live board: pan the DAG, open the decision waiting on you
ccm web-viewer · read-only
the dependency DAG — amber marks the critical path
the dependency DAG — amber marks the critical path
ccm web-viewer · read-only
a decision card — question, context, options, tradeoffs
a decision card — question, context, options, tradeoffs
ccm web-viewer · read-only
kanban — what’s awaiting you surfaces first
kanban — what’s awaiting you surfaces first
ccm web-viewer · read-only
timeline — durations, overlaps, the long poles
timeline — durations, overlaps, the long poles
ccm web-viewer · read-only
the agent roster — who is running what, where
the agent roster — who is running what, where
ccm web-viewer · read-only
every board in your home, one click apart
every board in your home, one click apart

ONE GOAL, START TO FINISH

“Translate my app into 6 languages.” Then go to sleep.

01 · you

One line

/cc-master:as-master-orchestrator — that’s the whole briefing. You bring the idea; it does not ask you for a spec.

your harness
/cc-master:as-master-orchestrator Internationalize the app to 6 locales

i18n framework + per-locale translation + locale routing

02 · contract

It frames a Goal Contract

Your words are evidence, not the goal. It rewrites them into a short, testable contract and asks only about ambiguities that would change the outcome.

ccm web-viewer · read-only
It frames a Goal Contract
03 · the plan

Foundation first, then fan-out

The strings must be extracted and the framework wired before any language can start — so it builds the groundwork, then fans out all six locales at once. Groundwork gets the steadier model; translations get the cheap one.

ccm web-viewer · read-only
Foundation first, then fan-out
04 · your one call

A question only you can answer

“Product terms — translate, or keep in English?” It packages the context, options, and tradeoffs, notes it for you — and every other locale keeps moving.

ccm web-viewer · read-only
A question only you can answer
05 · done means done

Verified at the endpoint

Before wrap-up it checks the contract point by point: every piece actually done, every question asked, nothing quietly dead in the background. You come back to a decision, not a surprise.

ccm web-viewer · read-only
Verified at the endpoint

Start to finish: you said one sentence, and made one decision.

THE EVOLUTION

From a workflow plugin to a meta-harness

It started as a Claude Code plugin that taught agents to write dynamic workflows. Each era generalized the one before — today it is the meta-harness of our own harness: any agent, initialized into the same conductor.

the cc-master evolution timeline: plugin era, engine era, meta-harness era
ACT I · 2026-06 · v0.1–v0.9

The plugin era

One Claude Code plugin. The inventions that last: the board as a durable plan, hooks that sleep until armed, cross-session resume, the first pacing.

ACT II · 2026-06/07 · v0.10–v0.11

The engine era

Board logic leaves the plugin and becomes ccm — one binary, the single source of truth — and grows an OR/ML estimation & pacing engine. Plugin and engine version independently from here.

ACT III · 2026-07 · v0.12 →

The meta-harness era

Source-to-adapter projection carries the same soul into Codex, Cursor, and kimi-code; N-host parity becomes a mechanism, not a promise. With ccm worker, the orchestrator commands a machine-wide pool of headless agents — its origin only decides where it sits, not what it can command.

ARCHITECTURE

One orchestrator, one engine, every harness

The plugin is a thin projection — commands, skills, hooks — into each harness. The engine, ccm, is the single source of truth for state, quota, estimation, and the worker pool. They meet at a process boundary: shell + JSON, never imports.

cc-master architecture: four harnesses, the plugin adapter, the master orchestrator, the ccm engine, boards, and the read-only web-viewer
cc-master plugin

initializes the session’s main agent into a master orchestrator — the adapter only carries host-native differences

ccm engine

board · goal contracts · quota & pacing · Monte Carlo estimation · worker pool · agent registry — 82 invariants guard every write

ccm web-viewer

read-only mission control for every board on the machine

QUICK START

One command, then one sentence

terminal

The installer puts the ccm engine on your PATH first — it’s a hard prerequisite — then distributes the adapter to each supported harness it finds. Two version lines, resolved independently; SHA256-verified.

Read the getting-started guide

Then hand it a goal, from your harness:

Claude Code/cc-master:as-master-orchestrator <your goal>
Codex$cc-master-as-master-orchestrator <your goal>
Cursor/as-master-orchestrator <your goal>
kimi-codecc-master:as-master-orchestrator <your goal>