Model-invoked discipline for spec-driven development — no code without a spec, openspec-style change contracts without the openspec dependency. Fire when a feature, fix, or refactor is about to be built without a written spec, when scope is agreed and needs freezing before implementation, when implementation reveals the spec was wrong (drift), or on "spec this", "write the spec first", "spec contract". Scaffold with `cto-brain spec init <change-id>`; lint with `cto-brain spec check`. Not for exploratory spikes or one-line fixes.
Use FIRST on any ambiguous intent — the router that maps the user's request to the right downstream skill(s). Fires on session start, on intent shifts mid-conversation, when the user mentions something the model doesn't have a clear single-skill home for, when multiple skills could fire, when the user asks "what skills do I have" / "what can the brain do", when a new project domain enters, or when you need to know whether to load CTO vs domain vs maintenance trio vs a brand-new skill. The brain's switchboard. Knows the catalog, the precedence order, the maintenance cadence, and the "if unsure" fallback.
Use when reasoning about HOW this brain learns — not what it should do, but the mechanism by which it gets better over time. Fires on questions about the round-close ritual, feedback file shape, the replay buffer, the policy update rule, exploration vs exploitation calibration, the always-running guarantee, periodic optimization cadence, or "is this thing actually learning or are we just writing docs?" Also fires when designing a new sub-skill that needs to plug into the loop, when debugging why a lesson isn't sticking, when the growth ledger shows a plateau, or when adapting the loop to a new domain. The formal description of the learning system that the cto-orchestration skill is the lead policy of.
Use when acting as the CTO / engineering lead orchestrating a multi-day or multi-week build with one human and many parallel agents, OR as the LEAD-CTO orchestrator-of-orchestrators that deploys and monitors subordinate CTOs across multiple parallel projects, OR when the round needs a lead skill to route between sub-skills, learn from what just happened, and enable the rest of the brain to grow. Fires on scope assessment, decomposition, dispatch, integration, reviewer-trio gating, tool selection, focused search, self-critique, mentorship, operationalization, pre-handover discipline, the round-close learning ritual that writes lessons to memory and updates downstream skills, AND the lead-CTO tier behaviors — subordinate-CTO deployment (charter, scope, reporting cadence), cross-project monitoring (per-project growth-ledger reads, status digest, blocker triage), cross-project synthesis (promoting project-level lessons to brain-policy), and portfolio-level authority/escalation. Covers prompt eng, context eng, fil
Model-invoked discipline for debugging without guessing. Fire when something is broken and the cause is not obvious. Reproduce, minimize, hypothesize, instrument, then fix — and lock the fix with a regression test. Read the FIRST error in the chain, not the last. Stops the flailing-edit anti-pattern. Inspired by mattpocock/skills `/diagnosing-bugs`.
Model-invoked discipline for building and maintaining a project's shared vocabulary in CONTEXT.md. Fire when a project keeps re-explaining the same concept, when a new load-bearing noun appears, or at the start of a build to name the domain. One agreed word replaces a 20-word paragraph every round — cutting tokens and speeding navigation. Inspired by mattpocock/skills `/domain-modeling`.
Fire BEFORE building anything non-trivial, or whenever a request is vague, broad, or likely to grow. A structured interview that surfaces the real scope — deploy target, distribution, proof bar, docs/media, design bar, positioning — and gets explicit sign-off before any brief is written. The front-end mirror of the close-out report. Model- or user-invocable. Inspired by mattpocock/skills `/grill`.
Model-invoked discipline for writing code against a fast feedback loop — red, green, refactor. Fire when building or changing logic that has a definable correct answer (parsers, calculations, state machines, API handlers, bug fixes). Write the failing test first, make it pass with the least code, then refactor on green. Not for exploratory spikes or pure UI styling. Inspired by mattpocock/skills `/tdd`.