infinite-system

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.

Use when a docs_v2 blog post needs its 1200x630 banner image — compose an in-brand HTML file in this skill's banners/ directory and render it deterministically with npm run render:banner. Covers the design language, the pipeline, and the verification loop.

Use when writing or editing ivue `Reactive()` classes, converting a Vue component or composable to ivue, or resolving any `.value`-in-template, `defineExpose`/`reactive()` instance-typing, `ReactiveInstance`/`Instance`, `$watch`/`$watchEffect`, or namespace-export question, or any `Static()` capability-class / `$`-cached-static / anchor question — the operating manual for Vue 3 class-based reactivity where state is ref-getters, derived values are plain getters, and Refs/Computeds are `.value` everywhere.

Use when bumping the ivue package version, tagging a release, or preparing an npm publish — the repo's versioning/tagging conventions and the gates that must pass before a version is stamped.

Use right after the user publishes ivue to npm — installs the just-published version into a throwaway consumer repo and smoke-tests the runtime, the skill installer, and the tarball contents against the registry artifact, not the local build.

Author and refactor TypeScript Node.js backends around static capability classes, mutable class namespaces, late dependency getters, lazy-bound static methods, native inheritance, and boot-time composition. Use for backend modules, circular imports, route or queue callbacks, plugin kernels, test doubles, and designs that would otherwise introduce DI tokens, decorators, forwardRef, or service instances that only hold methods.

Use when writing or editing any documentation in this repo — docs_v2 guide pages, README, invariants docs, sketch DESIGN/RESULTS files, or doc comments meant for readers. Encodes the house documentation style — timeless present tense with no edit-history residue, unpacked concepts over compressed jargon, ivue-standard code examples, and verified claims.

Load Invariant-Based Reasoning (IBR) as the session's reasoning engine. Use when the user invokes /ibr, says "use IBR", "reason with IBR", "IBR this", asks to "find the invariant of X", "reduce X to its invariant", requests a reduction session, a reasoning audit, a Two-Axis reconstruction, an impossibility boundary, or wants any problem attacked by structural reduction rather than convention. Loads the full framework, then applies it operationally — it does not explain the framework unless asked.

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