Quattro-CommasQuattro-Commas/elohim/AGENTS.md

elohim

AGENTS.md0 starsChanged 44 days agoMITView on GitHub

elohim is a gate for numerical claims. Six instruments measure hard mathematics, pin every result, and refuse to pass if anything moved — including the instrument itself. Six specific failures produced a result that was internally consistent, readable, and wrong, and none of them announced itself. Each is now a check that runs on every invocation. 1. Never hand-edit plugins/ or adapters/. They are derived. Run python3 tools/sync_adapters.py and commit what it writes. 2. Never edit a pinned number to…

Reads credentials

Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,774 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository9 other files it gives its agents.
- claim-ledgerSkill
- elohim-harnessSkill
- elohimSkill
- estimator-biasSkill
- invariant-hunterSkill
- pay-signalSkill
- precision-budgetSkill
- reproducibilitySkill
- tolerance-proverSkill

The file

We split this AGENTS.md into the rules it gives an agent

1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Very specific:
When reality and a document disagree, fix the record, not the number.
line 53

≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md 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

AGENTS.md

Three rules

Never hand-edit plugins/ or adapters/. They are derived. Run python3 tools/sync_adapters.py and commit what it writes.
Never edit a pinned number to match a sentence. Fix the sentence. This repository shipped a ledger whose prose asserted the opposite of its own pinned numbers while every gate stayed green — that is the failure the whole project exists to catch.
Never add a dependency. Standard library only, enforced by the hygiene lint. CI's floor is Python 3.10, so tomllib is unavailable: extract structured data with regex.

Five gates, before you push

python3 tools/check_text.py            # shipped text is clean
python3 tools/sync_adapters.py --check # derived mirrors are byte-identical
python3 tests/test_all.py              # every gated skill is green
python3 skills/elohim-harness/scripts/claim_binding.py --root .  # claim sentences are bound to pinned values
python3 tools/verify_repo_state.py       # the repository's own state is re-measured (needs GITHUB_TOKEN for the visibility claim)
python3 tools/gate_liveness.py --check      # every gate has passed, or has a written reason
python3 tools/gate_liveness_record.py --job ci.yml:core  # CI-only: appends what a runner just proved to the liveness log
python3 -m pytest -q                   # the unit suite is green

tests/test_all.py is the gate that must print ALL_SKILLS_PASS. The fifth command is the only one needing a third-party package; CI installs its pinned version first. These five are exactly the gates .github/workflows/ci.yml runs in its core job, and tools/verify_agents_drift.py fails when this list and that job disagree — so if you add a gate to core, add it here.

Three further gates run in .github/workflows/matrix.yml, not above: tools/verify_interpreter_claim.py compares the six documented interpreter ranges against a real matrix run, tools/verify_skill_roots.py refuses a skill name two discovery roots can reach, and tools/verify_skill_frontmatter.py refuses a SKILL.md a loader cannot read.

A gate needs a proven negative control

A check that has never been observed to fail is not known to be a gate. Every new gate ships with a committed fixture the gate is tested against in both directions, and you should be able to state, in one sentence, the input that turns it red. If you cannot, you have written a decorator, not a check.

When reality and a document disagree, fix the record, not the number. A decline is recorded in docs/ROADMAP.md together with the measurement that produced it.

Where things are

path	what it is
`skills/<name>/instrument/`	the instrument — the only thing that measures
`skills/<name>/ledger.json`	the promoted facts, each with an `expect`
`skills/<name>/backlog.json`	every measurement, promoted or not
`skills/elohim-harness/`	the shared gate any skill runs through
`tools/`	repo-level gates; all stdlib-only
`docs/ROADMAP.md`	what is next, and what was declined and why

CONTRIBUTING.md holds the longer form: how to add a fact, how to add a trap, and how to regenerate a ledger without silently moving a pin.

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.

Check your setup, free