create-check
Skill0 starsChanged 39 days agoMITView on GitHub
Turn a mechanically expressible engineering invariant into the smallest deterministic repository-owned check that rejects violations. Use for lint rules, static checks, contract tests, generated-state checks, or tiny verification scripts.
In this repository16 other files it gives its agents.
- decideSkill
- design-changeSkill
- design-moduleSkill
- groundSkill
- harden-boundarySkill
- harden-checkSkill
- intentSkill
- investigateSkill
- learnSkill
- pave-pathSkill
- ratchetSkill
- realizeSkill
- specifySkill
- validateSkill
- verifySkill
- wire-checkSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 10
Read references/ratchets.md and references/mechanism-ladder.md.
- Distinctive: line 14
State the invariant and counterexample: Write one sentence describing what must hold and one minimal representative violation that must …
- Distinctive: line 15
Inspect existing mechanisms first: Check compiler options, existing lint rules/plugins, restricted-import support, architecture tooling, …
- Distinctive: line 16
Select the narrowest adequate mechanism: Prefer compiler/type constraints, then existing static policy, then a small custom lint/check, …
- Distinctive: line 18
Prove the check bites: Run the clean check and observe PASS.
- Very specific: line 19
Expose the command: Ensure the check has a stable command or entry point.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Create Check
Compile an engineering invariant into executable rejection. Prefer the repository's existing verification substrate and build the smallest check that proves the property.
Read references/ratchets.md and references/mechanism-ladder.md.
Work
- State the invariant and counterexample. Write one sentence describing what must hold and one minimal representative violation that must fail.
- Inspect existing mechanisms first. Check compiler options, existing lint rules/plugins, restricted-import support, architecture tooling, test framework, package scripts, and repository-local checks. Reuse before inventing.
- Select the narrowest adequate mechanism. Prefer compiler/type constraints, then existing static policy, then a small custom lint/check, then a deterministic test/script. Do not create a general policy framework for one invariant.
- Implement repository-owned enforcement. Give diagnostics enough context to identify the invariant and preferred corrective path. Preserve local configuration and unrelated policy.
- Prove the check bites. Run the clean check and observe PASS. Introduce the representative violation in an isolated fixture or safe temporary mutation and observe FAIL for the intended diagnostic. Revert and observe PASS again.
- Expose the command. Ensure the check has a stable command or entry point. If it is not already part of the authoritative repository check, route to
wire-checkwhen the invariant is important enough to gate changes.
Return
- Invariant
- Mechanism
- Files/command
- Clean proof
- Negative proof
- Final proof
- Wiring status
- Known analysis limits
Failure signals
A check that only passes existing code, snapshots implementation trivia instead of the invariant, silently ignores relevant files, depends on agent cooperation, weakens types/tests to get green, or emits a diagnostic with no corrective path.
Done when
The smallest adequate deterministic check exists in repository-owned machinery, a representative violation is observed failing for the intended reason, clean state passes again, and its execution path is explicit.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

