Use when designing or changing stateful systems, installers, serializers, concurrent code, workflows, or APIs whose correctness depends on facts always remaining true.
Installs into .claude/skills of the current project.
Are you the author of Invariant Driven Design?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/shugokifable-invariant-driven-design)
---
name: invariant-driven-design
description: Use when designing or changing stateful systems, installers, serializers, concurrent code, workflows, or APIs whose correctness depends on facts always remaining true.
---
# Invariant-Driven Design
## Core rule
Define what must always remain true before choosing implementation details.
Write each important **invariant** as a checkable statement: one active registration per provider, manifest hashes match final bytes, a failed install never prints success, user config survives repair, or a lock has one owner.
Place enforcement at the narrowest **boundary** where invalid state can enter or leave. Tests should attempt a direct **violation** and prove it is rejected or repaired.
Prefer a small number of strong invariants over many procedural reminders. If correctness requires every caller to remember five steps in order, move those steps behind an interface or automated gate that preserves the invariant by construction.
