Ccg Workflow

CCG workflow

Seven role tools are available, each running a child agent on its own model with its own expert persona. This is how to chain them so the work converges instead of sprawling.

Skip all of this for small, obvious work. A one-line fix, a rename, a question you can answer by reading two files — do it yourself. Delegation buys depth, and it costs a round trip and a fresh context. Spend it only where depth is the thing you lack.

Picking a gear

Four modes. The user should not have to name one: read what they asked for, pick, say which you picked in a line, and — for anything past Direct — say what it costs and wait for a yes. They are paying per model call.

A role holding several models answers with all of them at once, so Deep costs more than its phase count suggests — quote the real number of model calls, not the number of phases. If the user names a mode, run that one. If a phase changes what you believe, say so and re-pick rather than finishing a plan you no longer believe in.

Deep and Team are not a ranking. Deep buys certainty about one thing by asking several models about it. Team buys throughput on several things by running colleagues at once. A hard question is Deep even if it is small; a wide job is Team even if every part is easy. Something both hard and wide is Deep first — settle the design and the contracts — then Team to build it.

The loop

Diagnose before you build when the cause is unknown (ccg_debug), and treat ccg_optimize and ccg_test as phases of their own when the task is performance or coverage rather than a feature.

Not every task needs four phases. A well-understood change is design → build → review. An investigation may be analyze → debug and stop there, with no code at all.

Writing a brief

A child sees none of this conversation. It gets your prompt and nothing else, so an under-specified brief is the main way this goes wrong. Every brief carries:

• The goal — one sentence on what the child must produce.
• The anchors — the exact files, symbols and commands it should start from. Paths, not descriptions.
• The constraints — what it must not change, the conventions to follow, the decisions already made (and by whom).
• The shape of the answer — a diff, a report, a ranked list. Say which.

Bad: "look at the auth code and improve it." Good: "In src/auth/session.ts, the refresh path drops the CSRF token when a retry follows a 401 (see refreshSession, lines 40-80). Diagnose the root cause. Do not change code. Report ranked hypotheses with the minimal test that would confirm each."

The quality gates

Bundled beside this skill, each runnable through the shell and each documenting its own arguments:

They are deterministic scanners, not opinions: run them before ccg_review so the reviewer spends its turn on judgement rather than on what a script already knows. A gate's findings are input to your decision, not a verdict — a flagged line can still be correct.

What stays with you

Delegate the turn, never the decision.

• Choosing between options is yours. A child ranks; you pick, and you own the reason.
• Acceptance is yours. Never let a child's "looks good" close a task. Read what came back and judge it — children are confident about work they cannot see the context of.
• Integration is yours. Children work in isolation; nothing but you is watching how the pieces meet.
• Contradictions are signal. When the analyzer and the reviewer disagree, that disagreement is the most valuable thing you have. Resolve it explicitly instead of averaging it away.

Running them in parallel

Independent delegations can run at once — a review of one module and tests for another have nothing to say to each other. Wait (run_in_background: false) only when your next move depends on the answer.

Do not parallelise work that writes to the same files. Two builders editing one module will produce a conflict nobody asked for; sequence those, or split the work along file boundaries first.