invar

Orchestration protocol for running multi-agent builds reliably — the conductor role. Use when coordinating a fork + builder agents (codex/claude/fable) across a backlog of tasks: delegating scoped work, keeping agents alive/visible, protecting merges, verifying by driving, and staying resilient across compaction. Covers when to delegate vs self-do, what to do when BLOCKED (bring in codex/fable before deferring to the user), and the merge-safety + liveness invariants that cost real time when missed. The running, append-only detail lives in the repo root at `project.conductor.md` (consolidated by rule) with the full log in `project.conductor.archive.md`; this file is the doctrine.

Drive an interactive CLI agent (claude / codex) inside tmux — launch it, send prompts/turns, ask whether its turn is really over, peek its output, steer it, resume it, reap it. Use this WHENEVER you need to run, watch, or converse with a nested claude/codex session (the fleet, cross-model review, or steering a long-running builder). Do NOT hand-roll `tmux send-keys`, and do NOT launch with `codex exec` / `claude -p` — both are encapsulated in scripts/agent-tmux.sh beside this file. Read this before driving any agent in tmux.

Read the conductor's own live context size mechanically — the speedometer. Use when you need the current context percentage, when a CTX or CHECKPOINT event names a number you want to re-verify, or when calibrating the gauge against the UI. The gauge is scripts/context-usage.sh; fleet-watch rides it on every event batch and fires CHECKPOINT at 85% (ANCHOR PROTOCOL trigger).

Operate the durable task system: one folder per task under .invar/tasks/, moved between active/in-progress/completed/retired and never deleted. Use when filing, dispatching, steering, landing, retiring, or auditing tasks. Each lifecycle step is a command. Every file is named number-first. The tracker (scripts/tasks/tasks-status.ts) reports drift and has a self-test. Built for the Invar repo and reusable by any repo that adopts the layout.

IBR invariant analysis of a posed change, question, or design against a project's recorded invariant contracts (*.invariants.md). Scope is DERIVED from the posed subject (touched paths + content-implication), never assumed. Use when asked to "check the invariants", "does this break/violate an invariant", "invariant-check this diff/merge/idea", BEFORE implementing a feature or design in a governed area (pose the plan — prevention is the cheapest use of this skill), to audit a merge against a subsystem's load-bearing rules, to validate a contract file, to audit the contract layer itself for staleness ("check the invariants", "is the contract still true?" — runs the checker + a freshness sweep against current code), or to bootstrap an invariants contract for a project or subsystem that has none. Verdicts distinguish violated vs stressed (holds only under a new unstated assumption) vs refines (the recorded statement itself should improve). Propose-only: never edits contracts or code without confirmation. Portable

Express yourself in Simplified Technical English (ASD-STE100, adapted for Invar). Applies to replies, briefs, task files, reports, and script messages — never to code. Use when writing any prose for this project, or when asked to make text plain.

Structural code search for this repo — parse-don't-grep. Use for ANY question about code structure (call sites, construction sites, member kinds, pattern censuses); grep stays for text, docs, and logs.

Reproducible independent-review procedure that finds structural bugs by auditing where generators live and whether consumers sit on them. Distilled from the 2026-07-24 codex review that predicted the provider-identity bug before the user hit it.