agentleFS
vanillagreencomvanillagreencom/kendex/skills/AGENTS.md

kendex / skills

AGENTS.md76 starsChanged 2 months agoMITView on GitHub

The catalog's skills, one directory per skill, each rendered under .agents/skills/<name>/ for this repository's own install. The same render rule covers agents/<n>.md (one render per harness directory) and hooks/<n> (the harness hook directories that already track it).

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

    Every skill suite runs on the pull request and in the merge queue through .github/workflows/skill-tests.yml.

    line 11

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

skills/

The catalog's skills, one directory per skill, each rendered under .agents/skills/<name>/ for this repository's own install. The same render rule covers agents/<n>.md (one render per harness directory) and hooks/<n> (the harness hook directories that already track it).

  • A change to a source with a tracked render lands the render in the same commit; a tools/guard lane checks presence, not bytes, because a render may carry an injected instructions block the source has no copy of. A source with no tracked render has nothing to land.
  • Sync a render by replaying the source diff onto the render, never by copying the source file over it.
  • Shell stays Bash 3.2 compatible; tools/bash32-lint names Bash 4+ constructs in the guard, tools/bash32-parse parses the same tree and tools/ with a real Bash 3.2 under tools/guard --full and the guards shard, and the macOS leg of the skill suites shard runs every shell suite but linear's, whose CLI has its own Bash 4 contract, on the runner's /bin/bash 3.2.
  • A script that sources another skill's lib declares that skill required under dependencies in its own SKILL.md, and every fixture that copies a skill into an isolated project installs the required sibling beside it; a copy parked outside that layout refuses at startup rather than running the case.
  • A package change feature-detects every dependency and never names one machine's directory layout.
  • A test that shells out to git clears GIT_DIR, GIT_COMMON_DIR, GIT_WORK_TREE and GIT_INDEX_FILE together. Under orch/tests/ that clearing is skills/orch/tests/lib/git-env.sh, sourced on the line under each suite's set -...o pipefail.
  • Every skill suite runs on the pull request and in the merge queue through .github/workflows/skill-tests.yml.

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.