agentleFS
tamesystemstamesystems/intent-engineering-skills/skills/create-check/SKILL.md

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.

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
  1. Very specific:

    Read references/ratchets.md and references/mechanism-ladder.md.

    line 10
  2. Distinctive:

    State the invariant and counterexample: Write one sentence describing what must hold and one minimal representative violation that must …

    line 14
  3. Distinctive:

    Inspect existing mechanisms first: Check compiler options, existing lint rules/plugins, restricted-import support, architecture tooling, …

    line 15
  4. Distinctive:

    Select the narrowest adequate mechanism: Prefer compiler/type constraints, then existing static policy, then a small custom lint/check, …

    line 16
  5. Distinctive:

    Prove the check bites: Run the clean check and observe PASS.

    line 18
  6. Very specific:

    Expose the command: Ensure the check has a stable command or entry point.

    line 19

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. State the invariant and counterexample. Write one sentence describing what must hold and one minimal representative violation that must fail.
  2. 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.
  3. 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.
  4. Implement repository-owned enforcement. Give diagnostics enough context to identify the invariant and preferred corrective path. Preserve local configuration and unrelated policy.
  5. 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.
  6. 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-check when 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.