invariant-guard — Correctness-First Coding

The model knows what a loop invariant is. It knows recursion needs a base case. It knows about empty lists, integer overflow, and the difference between < and ≤. It just does not write these down before producing code, so it ships subtle correctness bugs that tests do not catch.

invariant-guard fixes the behavior. State the invariants. State the base case. State the termination argument. State the edge cases. Then write the code — and verify that the code maintains what you stated.

Violating the letter of these rules is violating the spirit of the skill. "I know this algorithm" is the exact rationalization that ships off-by-one and missing-postcondition bugs.

When to Use This Skill

Use invariant-guard when writing or reviewing algorithms where the obvious implementation is subtly wrong:

• Postcondition stronger than the loop's natural invariant: Boyer–Moore majority, Floyd's cycle detection, leftmost vs any binary search, QuickSelect partition.
• In-place mutation with read+write pointers: dedup-in-place, partition, rotate.
• Recursion with multiple parameters or accumulator state.
• Off-by-one suspects with duplicates, empty inputs, boundary values.
• Iterative refinements that must terminate: fixed-point, Newton, EM.
• Any function where you catch yourself thinking "I know this algorithm" — the trap is usually in the contract, not the loop body.