c3

C3 — one model, three acts

C3 is your architecture's own vocabulary, frozen into shared truth, that work edits only through reviewed change-units.

1. Shape the model, freeze the facts. Descend the domain top-down — draft the facts the work needs and wire them as you go; the lean canvas (sections + typed columns each entity carries here) is already in place, taking a custom fact-type only where the domain needs one. Then flip the gate and the facts freeze: shared truth, never hand-edited again.
2. Change-units drive progress. Work advances by change-units — an ADR plus its patch folder, one atomic saga: declare intent, the tool keeps the result integral (membership, citations, gates), flip it all-or-nothing. Frozen facts change only through this merge.
3. The canvas grows — and evolves — with the need. When work outgrows the model, raise the canvas (climb a rung, additive) or morph it (reshape a mis-modeled type non-additively) and migrate every fact to fit — in one gated, atomic unit; completeness is never relaxed.

Build the model → freeze the facts → change-units drive the work → the canvas grows with the need.

CLI invocation

The packaged runtime is c3x, exposed through the skill-local wrapper at <skill-dir>/bin/c3x.sh. There is no c3 executable. Invoke the wrapper explicitly for every command:

# Template: resolve <skill-dir> to this skill's directory, then replace the command and args.
C3X_MODE=agent bash "<skill-dir>/bin/c3x.sh" check

For several commands in one shell, this helper is allowed, but it is only a shell function and does not install a c3 command:

c3local() { C3X_MODE=agent bash "<skill-dir>/bin/c3x.sh" "$@"; }

C3X_MODE=agent → TOON output (~40% fewer tokens) and help[] hints appended to each result — follow them. The packaged CLI is the single source; this skill is the router: classify the intent, load the reference, invoke the wrapper, follow the output. It names every gate and teaches no procedure — procedure lives in the references.