heinzel
AGENTS.md2 starsChanged 14 days agoMITView on GitHub
- Pin actions to full SHAs with the tag as a comment (gh api repos/<o>/<r>/commits/<tag> --jq .sha). - Set permissions: {} at the top and least privilege per job; set persist-credentials: false. - Pass untrusted ${{ }} into run: only via env:. - Run scripts through an interpreter (bash scripts/x.sh, uv run --script scripts/x.py), never by path: plugins get them without the executable bit. - make lint runs actionlint and zizmor. - Workflows shared with plugins are symlinked into template/;…
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,439 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 repository18 other files it gives its agents.
- AGENTS.mdAGENTS.md
- tests/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/CLAUDE.mdCLAUDE.md
- starter/CLAUDE.mdCLAUDE.md
- template/CLAUDE.mdCLAUDE.md
- tests/CLAUDE.mdCLAUDE.md
- add-moduleSkill
- add-operationSkill
- codifySkill
- raise-the-barSkill
- releaseSkill
- reviewSkill
- scaffold-pluginSkill
- self-auditSkill
- ship-smallSkill
- write-adrSkill
- write-testsSkill
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: line 6
Run scripts through an interpreter (bash scripts/x.sh, uv run --script scripts/x.py), never by path: plugins get them without the …
≈ “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.
Files
AGENTS.md — CI/CD
- Pin actions to full SHAs with the tag as a comment (
gh api repos/<o>/<r>/commits/<tag> --jq .sha). - Set
permissions: {}at the top and least privilege per job; setpersist-credentials: false. - Pass untrusted
${{ }}intorun:only viaenv:. - Run scripts through an interpreter (
bash scripts/x.sh,uv run --script scripts/x.py), never by path: plugins get them without the executable bit. make lintruns actionlint and zizmor.- Workflows shared with plugins are symlinked into
template/; the template'sci.ymlis generated from ours (make fix).
macOS jobs use Apple-silicon ARM64 hosted runners only (macos-latest). Never add Intel macOS runner labels,
Intel large runners, or Intel self-hosted runners. Keep the shared bootstrap architecture check and the native
make ci-macos-arm check so an unexpected architecture fails closed. Preserve the full ARM Python-version,
native, browser, Electron and release-acceptance coverage and its limits. Linux coverage is unchanged.
Constraints per workflow:
ci.yml:CI OKgates merging. PR portable tests run on Linux with Python oldest and newest plus realmacOS smoke. Native/platform and unknown changes retain macOS setup, end-to-end and Electron checks, with failures blocking. The full matrix runs on main, daily and dispatch; every scheduled macOS job blocksCI OK. A failing cheap check cancels the rest of a same-repository pull request's run as soon as it completes; fork PRs finish normally with read-only tokens. Every main commit keeps its own CI run, and a release PR's (headrelease/*) run is never cancelled. Explicit queue proofs may delegate intermediate commits to one uncancellable final full run with the aggregate base. Unknown proof runs full CI; admissions never claim CI OK or full-suite greens.merge-gate.yml: runs onworkflow_runonce a PR's CI finishes (no runner held while CI runs) from the default branch, never checks out PR code, and reports the requiredmerge-gateandcoverage-floorcheck runs on the PR head; a gate that did not pass or did not run fails closed.update-prs.yml: core keeps tested PR heads for the merge queue; plugin repositories update behind branches and approve the resulting CI runs. Closed code-scanning threads are resolved in both.acceptance.yml:contents: read, no secrets, publishes nothing; uploadsresult.json, which promotion reads. A candidate run (release wheel URL + sha256 + profile URL) is labelledCANDIDATE_*, never a public-path pass.prepare-release.yml(make release): opens the release PRchore(release): vX.Y.Zand dispatches CI on it (token-made PRs trigger none). A maintainer reviews all checks before merging.edge.yml: dark untilvars.RELEASE_CHANNELSis set (ADR 0114); then publishes pre-releasesedge-v<version>, never latest, never on PyPI.pypi.yml: manual dispatch on a final version tag; verifies and promotes the exact signed official GitHub release wheel and sdist without rebuilding, uploads only core with isolated trusted publishing in environmentpypi.release.yml: manual dispatch for one optional plugin; never builds or tests core.source-review.yml: dispatch on the protected reftrusted/source-reviewonly (make review PR=<n>); paid, tool-free review of one PR's source; fails closed unless live head, base and protected ref equal the dispatch; core only.focused-job.yml: core only; manual dispatch of one e2e lane or test ids, pytest ids or vitest files on one hosted runner, testing only the dispatched branch (inputrefmust equal it);os,kindandselectorare validated byscripts/focused_job.pyand never pass through a shell.contents: read, no repository secrets (the read-only job token only, as in ci.yml's e2e), never writes the cache, 20 min; a diagnostic that gates nothing.fuzz.yml: core only.claude-review.yml: opt-in (vars.CLAUDE_REVIEW).docs.yml: deploys to GitHub Pages when the repository is public orvars.DOCS_PAGESistrue, else keeps an artifact (ADR 0082).
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.

