| name | ibr |
| description | 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 [problem]
Load the IBR framework and operate with it.
Load
First check whether the framework is already in context. It often is: injected via
--append-system-prompt-file, loaded by an earlier /ibr this session, or pasted into the
conversation. Telltales: the "Invariant-Based Reasoning (IBR) — Framework" document with its
axioms (Reality Has Invariants, The Breaking Principle, Scope…), the Wielder Principle, the
Truth-Over-Self-Protection Invariant. If present, do not read the file again — a second
copy pollutes context and adds nothing. Confirm in one line that the framework is already
loaded and proceed to Operate.
Otherwise, read IBR.md from this skill's directory — the framework travels with the
skill. If the user supplies a path explicitly, read that instead (even if a copy is already
in context — an explicit path means they want that specific version).
Read it completely. It is the method authority; this file only governs invocation.
Operate
- With a target (
/ibr <problem>, or /ibr invoked while work is in flight — the
work is the target): apply the framework to it immediately — frame audit and bottleneck
first, then the reduction cycle, then the generation/impossibility tests. Deliver the
result, not a tour of the method.
- Bare invocation: confirm the framework is loaded in one line, then: "What's on your mind?"
- Reason with IBR internally; speak natural language by default. Surface axioms, operators,
audit labels, or IBR vocabulary only when the user asks for the structure (a proof, a Two-Axis
reconstruction, an audit trail) or when a framework term is genuinely the clearest way to say
the thing.
- Apply the framework; do not analyze, summarize, or propose improvements to it unless that is
the task.
- Honor the Objection Severity tiers in all critique: tag findings fatal / scoping / flag, and
never present a flag with fatal rhetoric.
- The Wielder Principle applies to you: state how far your reduction actually reached, hold
results as provisional, and mark what would falsify them.
Companion
/invariants — IBR operationalized for codebases: audits changes against a project's
recorded invariant contracts (*.invariants.md), with its own checker, annotation, and
audit machinery. Route by target: a codebase or architecture → /invariants;
anything else → /ibr.- The handoff runs both ways.
/invariants names this skill as its method authority for
contested verdicts and deep reductions. In the other direction: when an /ibr reduction
lands on a load-bearing rule about code, do not leave it in conversation — switch to
/invariants and propose it as a discovered contract record, where it gains
enforcement instead of evaporating when the session ends.
