claude-skills
CLAUDE.md1 starsChanged 7 months agoMITView on GitHub
A public collection of skills for Claude Code. No application source — each skill is a single Markdown file. The repo is consumed by users who clone it and run ./install.sh to symlink skills into ~/.claude/skills/. Every skill lives in its own top-level directory and contains exactly one file, SKILL.md: The directory name must match the name field in the frontmatter. The installer (install.sh) discovers skills by iterating top-level directories that contain a SKILL.md, so adding a new one is…
In this repository6 other files it gives its agents.
- ai-slop-auditSkill
- end-sessionSkill
- repo-cleanupSkill
- rubber-duckSkill
- status-reportSkill
- structured-debuggingSkill
The file
We split this CLAUDE.md into the rules it gives an agent
7 rules. About 0 are common, 3 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 11
Every skill lives in its own top-level directory and contains exactly one file, SKILL.md:
- Very specific: line 22
Every SKILL.md starts with YAML frontmatter:
- Distinctive: line 33
Don't tack on a workflow summary after the trigger.
- Distinctive: line 38
Keep skills short: If a skill is longer than ~200 lines, it's probably two skills.
- Very specific: line 39
One skill per directory: Don't add supporting files, examples, or references next to SKILL.md unless a skill genuinely needs them.
- Very specific: line 45
Create <skill-name>/SKILL.md with the frontmatter above.
- Distinctive: line 46
Add a row to the skills table in README.md.
≈ “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
CLAUDE.md
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
What this repo is
A public collection of skills for Claude Code. No application source — each skill is a single Markdown file. The repo is consumed by users who clone it and run ./install.sh to symlink skills into ~/.claude/skills/.
Repo layout
Every skill lives in its own top-level directory and contains exactly one file, SKILL.md:
<skill-name>/
SKILL.mdThe directory name must match the name field in the frontmatter. The installer (install.sh) discovers skills by iterating top-level directories that contain a SKILL.md, so adding a new one is purely a matter of creating the directory and file.
Skill file format
Every SKILL.md starts with YAML frontmatter:
---
name: skill-name
description: When Claude should invoke this skill
---The description is the trigger — Claude sees it (not the body) when deciding whether a skill applies. Write it in terms of when a user or situation calls for the skill, with concrete trigger phrases. "Use when X happens" beats "A skill for X."
Don't tack on a workflow summary after the trigger. A description like "Use when X — walk through A, B, C" gives Claude a shortcut it will follow instead of reading the skill body; keep the description to triggering conditions only.
Conventions
- Rigid vs. flexible. State explicitly whether the skill is a strict checklist ("do not skip steps") or a loose set of principles. Mark it with
**Rigid.**or**Flexible.**on its own line at the top of the body, followed by a short clause explaining what that means for this skill. Ambiguity here causes misuse. - Keep skills short. If a skill is longer than ~200 lines, it's probably two skills.
- One skill per directory. Don't add supporting files, examples, or references next to
SKILL.mdunless a skill genuinely needs them. - No external dependencies. Skills should work out of the box — no scripts to run, no extra installs.
- Generic examples only. Skills live in a shared public collection — don't leave behind examples from whatever project the skill was born in (game mechanics, specific filenames, domain jargon). Use examples that could plausibly apply to any codebase.
Adding a skill
- Create
<skill-name>/SKILL.mdwith the frontmatter above. - Add a row to the skills table in
README.md. - (If the skill is already installed globally as a real directory) re-run
./install.sh— it will back up the existing directory and replace it with a symlink.
Install script
install.sh is idempotent. On re-run it refreshes existing symlinks. If it finds a real file/dir at a target path (e.g., a pre-existing hand-written skill), it moves that aside as <name>.bak.<timestamp> rather than deleting it. CLAUDE_SKILLS_DIR overrides the install destination.
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.

