agentleFS
ghuntleyghuntley/loom/.agents/skills/covenant/SKILL.md

covenant

Skill1.6k starsChanged todayMITView on GitHub

Add, maintain, and verify Covenant contracts for this repository's Elixir Mix applications.

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 1 is distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when changing Covenant configuration, contract obligations, contract tests, or the contract verification gates for an Elixir …

    line 8
  2. Very specific:

    Read the root AGENTS.md, the application's local guidance, existing CONTRACTS files, and relevant ADR evidence before editing.

    line 12
  3. Very specific:

    Keep Covenant in only: [:dev, :test] with runtime: false.

    line 13
  4. Very specific:

    Use the pinned Hex release already adopted by the repository (~> 0.2.0).

    line 14
  5. Very specific:

    Put obligations under the application's contracts/ tree and executable tests under test/contract/.

    line 15
  6. Very specific:

    Run mix covenant.conditions --verbose when changing contract conditions.

    line 34

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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

Covenant contracts

Use this skill when changing Covenant configuration, contract obligations, contract tests, or the contract verification gates for an Elixir application in this repository.

Repository workflow

  • Read the root AGENTS.md, the application's local guidance, existing CONTRACTS files, and relevant ADR evidence before editing.
  • Keep Covenant in only: [:dev, :test] with runtime: false; never add it to production runtime dependencies.
  • Use the pinned Hex release already adopted by the repository (~> 0.2.0). Preserve existing test-helper callbacks and append Covenant.Formatter rather than replacing formatters.
  • Put obligations under the application's contracts/ tree and executable tests under test/contract/. Use stable IDs of the form <mix_app>.<component>.I<n> and tag every contract test with its obligation ID.
  • Preserve the existing @cc code-contract system. Run the code-contracts workflow for code changes; Covenant does not replace CONTRACTS or architectural evidence.

Evidence discipline

Write obligations that are specific and evidence-backed. A BEAM contract test may establish behavior observable in the test VM, such as a codec invariant, privacy rule, accounting transition, or module loadability. It must not claim native Rust/KVM behavior, physical isolation, multi-host recovery, browser behavior, or production deployment evidence unless the test actually exercises that boundary. Link those claims to the existing ADR, machine, native, or integration evidence instead.

Generated module-loadability obligations are a valid bootstrap baseline, but label them as such and expand them with meaningful subsystem behavior when practical. Do not describe 100% Covenant coverage as complete system verification.

Verification

From an application directory, run the relevant checks with the pinned runtime:

mix covenant.check --static --contracts contracts --test-path test/contract --root .
mix test test/contract --warnings-as-errors
mix covenant.check --no-run

Run mix covenant.conditions --verbose when changing contract conditions. Commit deterministic contracts/coverage.json and contracts/coverage.static.json when produced and valid; do not commit _build/covenant/results or temporary mutation matrices. Run the application's normal mix precommit; shared protocol changes also require Marshall and Lilly consumer checks.

For architecture, behavior, configuration, or verification changes, update the relevant ADR and run the repository's ADR checks. Review mutation survivors where mutation testing is available, recording surviving obligations honestly rather than weakening them silently.

Download now (ZIP)

Trending

Quiet since January.thin dataabout the whole repository

Dec 2025: 0 mentionsJan 2026: 14 mentionsFeb 2026: 0 mentionsMar 2026: 0 mentionsApr 2026: 0 mentionsMay 2026: 0 mentionsJun 2026: 0 mentionsJul 2026: 0 mentionsAug 2026: 0 mentionsSep 2026: 0 mentionsOct 2026: 0 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the ghuntley/loom repository that our weekly crawl found: only 14 in all, so this is a hint, not a trend. There is no adoption data for this file yet.

Who's talking about ghuntley/loom

The biggest 5 of 14 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 14

Talked about on GitHub and Hacker News (14 times).

On GitHub · 13

8 more on GitHub

On Hacker News · 1

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

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.