skills
CLAUDE.md4 starsChanged 4 months agoMITView on GitHub
Agent skills for Claude Code and Codex. Local-only by design: every skill here reads and writes files on the runner's machine, and nothing is uploaded. AGENTS.md is a symlink to this file, so both agents read the same rules. One skill is one folder: SKILL.md is runtime-neutral prose. Where a runtime genuinely differs — config paths, a missing capability — name both cases inline (~/.claude/settings.json or ~/.codex/config.toml). A divergence too big to write that way earns its own section in…
In this repository4 other files it gives its agents.
- ai-usage-cardSkill
- ingestSkill
- keep-aliveSkill
- sitrepSkill
The file
We split this CLAUDE.md into the rules it gives an agent
7 rules. About 0 are common, 2 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
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
- Very specific: line 29
Every skills/<name>/ has a SKILL.md whose frontmatter name equals the folder name.
- Very specific: line 32
Every skill has agents/openai.yaml.
- Very specific: line 34
Every skill is listed in .claude-plugin/plugin.json's skills array, with no stale entries.
- Very specific: line 41
Run the check before every push.
- Distinctive: line 61
Don't install both into the same runtime — you get every skill twice.
- Very specific: line 77
Add ./skills/<name> to .claude-plugin/plugin.json's skills array and bump its version — Claude uses that version to decide when installed …
- Distinctive: line 80
Add a row to the README table.
≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.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
Agent skills for Claude Code and Codex. Local-only by design: every skill here reads and writes files on the runner's machine, and nothing is uploaded.
AGENTS.md is a symlink to this file, so both agents read the same rules.
Layout
One skill is one folder:
skills/<name>/
├── SKILL.md # the skill; Claude Code reads its YAML frontmatter
├── agents/openai.yaml # Codex reads this: display name, one-liner, policy
└── scripts/ # optional; anything the skill shells out toSKILL.md is runtime-neutral prose. Where a runtime genuinely differs —
config paths, a missing capability — name both cases inline
(~/.claude/settings.json or ~/.codex/config.toml). A divergence too big
to write that way earns its own section in the skill.
Invariants
Enforced by python3 tools/check_skills.py, not by discipline:
- Every
skills/<name>/has aSKILL.mdwhose frontmatternameequals the folder name. The frontmatter name is the invocation name — it is resolved from there, never from the directory. - Every skill has
agents/openai.yaml. Without it Codex falls back to the raw folder name and has no invocation policy. - Every skill is listed in
.claude-plugin/plugin.json'sskillsarray, with no stale entries. That array is exactly what the plugin publishes. - Invocation policy matches across the pair of files: user-invoked means
disable-model-invocation: truein the frontmatter andpolicy.allow_implicit_invocation: falseinopenai.yaml. Model-invocable means neither.
Run the check before every push. After touching a manifest under
.claude-plugin/, also run claude plugin validate . --strict.
Installing
Plugin — managed, updates when the repo ships:
/plugin marketplace add silouone/skills
/plugin install silouone-skills@silouoneSkills arrive namespaced — /silouone-skills:ingest.
skills.sh — editable files the user owns, on any agent:
npx skills@latest add silouone/skillsDon't install both into the same runtime — you get every skill twice.
Working on this repo: scripts/link-skills.sh symlinks every skill into
~/.claude/skills and ~/.codex/skills, so an edit here is live immediately.
It refuses to replace a real directory (someone's own copy) and only ever
clobbers a symlink. scripts/list-skills.sh prints the inventory. Both are
maintainer tools, not the supported installer.
Adding a skill
skills/<name>/SKILL.mdwith frontmattername+description. The description is what makes the model reach for it: say what it does and when to use it.skills/<name>/agents/openai.yamlwithinterface.display_name,interface.short_description, andpolicy.allow_implicit_invocationmatching the frontmatter.- Add
./skills/<name>to.claude-plugin/plugin.json'sskillsarray and bump itsversion— Claude uses that version to decide when installed users see an update. - Add a row to the README table.
python3 tools/check_skills.pyandclaude plugin validate . --strict.
The release checklist, the sanitization gate, and the local-only guarantee live in PUBLISHING.md. Read it before pushing.
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.

