CTO
Executor.
Five-phase team-lead orchestrator that runs multi-agent project execution under a strict audit gate — with a worker compliance covenant, task-graph watchdog, and a 4-cycle circuit breaker.
A CTO that delegates and never touches the code.
Per stage, a fresh five-agent team. The CTO orchestrator is strictly a team lead — it dispatches tasks, reads reports, makes decisions, and does no donkey work. Implementation is by Workers (constrained by a verbatim Compliance Covenant); verification is by the Tester; logging is by the Scribe; quality is by the Auditor whose binary verdict is the only authority that can declare a contract complete.
Spawn order: Scribe → Auditor → Workers → Tester · watchdog runs continuous · rules layer scoped per role
The CTO's only job is to delegate, audit, and stay out of the way. Every donkey task it does is context it can never reclaim.
Pre-flight, then spawn order matters.
Phase 0 reads the active stage contract, project_summary.md, and CLAUDE.md (specifically the TELEMETRY: classification). It pre-validates every required artefact — if a contract is missing, a batch isn't defined, or the telemetry classification isn't set, the CTO STOPs and escalates rather than improvising. Phase 1 spawns the team in a specific order designed to prevent a real race that once produced a premature GREEN verdict on an empty TaskList.
Scribe first, Auditor second, Workers third, Tester last.
The spawn order isn't arbitrary. Scribe goes first because the rest of the team will start writing events the moment they spawn — the log needs a ready writer. Auditor goes second because it needs the full contract loaded before workers produce any output — spawning workers and auditor in parallel once produced a race where the auditor saw an empty TaskList and verdicted GREEN. Workers third with the Compliance Covenant block in every spawn prompt. Tester last because it only matters once implementation exists.
Each teammate gets only its applicable rule files — the worker gets worker/*.md, the auditor gets auditor/*.md + the full contract, the scribe gets scribe/*.md. Context windows stay clean inside the 400K budget per role.
Every batch is a small DAG.
Per batch: implementation tasks first, then a test task that blockedBy them all, then a scribe-update task with the same blockers, then an audit task that blocks on test + scribe. Across batches: every Batch K+1 implementation task is blockedBy Batch K's audit. This is how the audit gate gets mechanical enforcement — workers literally cannot start the next batch until the previous one is GREEN.
Per batch: impl → test + scribe (parallel) → audit · cross-batch: next impl blockedBy current audit
Single-batch authorisation when workers are autonomous.
For high-autonomy worker subagents (the default), the CTO uses single-batch authorisation: it creates only the CURRENT batch's tasks at any time, not the full stage. Future-batch tasks are created after the current batch's audit returns GREEN. This removes the temptation surface entirely — there are no future-batch tasks visible in TaskList to pre-claim.
Workers will steamroll gates without active enforcement.
The earliest version of this system trusted workers to respect blockedBy. They didn't. A worker that finishes its current task, looks at the TaskList, sees an unblocked-looking next task and just claims it — bypassing the audit that's supposed to gate the batch — is the default failure mode of an autonomous subagent. The fix is mechanical, not motivational: a verbatim spawn-prompt block plus a watchdog that resets violators on every monitor tick.
The Compliance Covenant ships verbatim in every worker spawn prompt.
Five rules, repeated verbatim. Mailbox-first checking before every tool call. Pre-claim verification of blockedBy before any status flip. No autonomous batch chaining. No file work outside the authorized batch. Ack-required STOP. Repeated violations = termination + respawn with a hardened prompt.
==== COMPLIANCE SECTION (NON-NEGOTIABLE) ==== 1. MAILBOX-FIRST — Before EVERY tool call (every TaskUpdate, every Edit, every Write, every Bash, every PowerShell), check your inbox for new messages from team-lead. Process them BEFORE continuing. 2. PRE-CLAIM VERIFICATION — Before changing ANY task status to in_progress: - Call TaskList. Read the task's blockedBy field. - If blockedBy is non-empty (any pending/in_progress blocker), DO NOT CLAIM. Stay idle. - If blockedBy is empty AND owned by you, only THEN flip to in_progress. 3. NO AUTONOMOUS BATCH CHAINING — After marking any batch task complete, IDLE explicitly. Do NOT look for next work. Do NOT claim the next batch. Wait for an explicit team-lead message ("Batch X is now ready") before claiming the next task. 4. NO FILE WORK OUTSIDE THE CURRENT AUTHORIZED BATCH — Only edit files belonging to the batch I have explicitly authorized. 5. ACK-REQUIRED STOP — If team-lead sends "STOP" or "HOLD", reply with "ACK STOP" via SendMessage and IDLE before any other action. Repeated violations = termination + respawn with hardened prompt. ====
The CTO complements the spawn-prompt rule with a runtime check. The task-graph watchdog scans the TaskList on every monitor tick — every team event, every idle notification, every message arrival — and immediately resets any task in in_progress whose blockedBy is non-empty. The worker that did it gets a violation message. Two violations and the CTO terminates the worker and respawns it with a prefix noting the prior termination. Empty blockedBy is the only authorisation for in_progress — period.
Binary verdicts, four-cycle circuit breaker.
The Auditor is the sole authority that can declare a contract complete. Verdicts are binary — GREEN (every checklist item passes, every verification command succeeds) or RED (a numbered list of failures with the contract item each one violates). No caveated approvals. No "good enough." On the fourth consecutive RED for the same batch, the CTO stops the feedback loop and escalates to the human — the contract itself is probably wrong, not the implementation.
Per-batch loop: impl → test → scribe → audit · GREEN unblocks · RED re-loops · 4× RED escalates
The auditor reports findings, never fixes code.
The Auditor's rules are absolute. It grades only against the contract checklist, not against worker explanations. It re-runs every verification command the worker already ran (trust but verify). It never fixes code — mixing finding-problems and fixing-problems would erase the independence the audit gate exists to provide. Reports list every failure with the contract item it violates.
Test files are immutable milestones — workers caught editing them to make tests pass are flagged with a "test file tampering" finding, which is an automatic RED. Tests are the contract's enforcement mechanism; modifying them is changing the contract after signing.
On the 4th RED, the CTO invokes /cto-html-renderer:red-escalation to produce a Paper/ink-aesthetic page with the cycle history, the auditor's final-verdict pullquote, what remains unfixed, the contract items violated, and tailored intervention options for the human.
Stage integration audit, then a fresh team.
When every batch in a stage has reached GREEN, the CTO triggers a stage integration audit covering the cross-batch criteria from the contract. If GREEN, the stage is complete; the CTO sends shutdown messages, verifies the scribe wrote the final entry to project_summary, and creates a brand-new team for the next stage. No worker from Stage N carries context to N+1 — the only continuity is the contracts, rules, and project_summary.
A briefing page closes every stage.
The CTO invokes /cto-html-renderer:stage-briefing after the stage integration audit returns GREEN. The Editorial-aesthetic page is the closing artefact for the human and for any future reader returning to the project: shipped batches with audit history (and collapsible RED cycle detail for batches that hit RED), blockers resolved, integration test results, and a transition block describing what the next stage will do and why it depends on what just finished.
Four layers, all in version control.
Every layer lives under ~/.claude/ and is editable as markdown / inline HTML. No managed services, no external dashboards.
Skill layer
- SKILL.mdFive-phase workflow
- Spawn protocolOrder + telemetry signal
- Task templatesPer-batch DAG
- Watchdog logicResets on every tick
Rules · 28 files
- team/Shared by every role
- cto/No donkey work, audit gate
- worker/Compliance Covenant
- tester/Contract-only tests
- auditor/Independence, verdict protocol
- scribe/Append-only, crash markers
Renderers
- status-snapshotBlueprint operations
- red-escalationPaper/ink cycle history
- stage-briefingEditorial recap
- design-system.mdShared rule file
Coordination
- Agent toolSpawn teammates
- TaskListblockedBy chains
- SendMessageBlockers, STOP, RED feedback
- project_summary.mdAppend-only session log
Every rule encodes a past failure mode.
The non-negotiable rules are not preferences — each one is a fence around a specific way the system has failed at least once.
What this build taught me.
project_summary.md. Snapshot-on-demand beats live auto-refresh at this scale; live would need state-mirror infrastructure that isn't earning its keep yet.