Contributions
Fork it, change it, send it back.
Every fork and every contribution is welcome — a whole new skill, a fix to one of mine, a reworded sentence, a typo. Nothing here is precious, and none of it is finished.
The repository is MIT licensed, so you never need permission. Send a pull request when the change would help somebody other than you; keep it in your own fork when it wouldn’t. Both are the point.
Three ways in
In ascending order of effort. The first one takes a click.
01
Fork it
Press fork and it is yours. Rename the skills, rewrite the procedures, delete the ones you never invoke. Nothing has to come back here, and nobody has to be told.
02
Open an issue
A skill that fires when it shouldn't, a step that reads two ways, a task you wish were covered. An issue with no fix attached is still worth opening — most of the work is noticing.
03
Send a pull request
Edit the SKILL.md and open it. There is no build to run and no test suite to pass, so the diff is Markdown and can be read on GitHub exactly as it is.
The short version
Fork, branch, write the Markdown, push. GitHub offers the pull request itself once the branch lands.
# fork on GitHub, then clone your fork
git clone https://github.com/<you>/Claude-skills.git
cd Claude-skills
git checkout -b my-skill
# a skill is one folder with one SKILL.md in it
mkdir my-skill && $EDITOR my-skill/SKILL.md
git commit -am "Add my-skill"
git push -u origin my-skillA few things that help
None of these are requirements. They are the things that make a skill behave once it is installed, learned mostly by getting them wrong first.
- One change per PRA new skill and a rewrite of an old one are two pull requests. Not a rule — it just makes each one quick enough to read in a sitting, which is usually the difference between merged this week and merged eventually.
- A narrow descriptionThe front-matter description is what Claude Code reads to decide whether the skill applies. Say what the skill is for and what it is not for; a description that covers everything gets invoked for everything.
- Steps, not adviceThe skills that hold up are the ones written as a procedure with checks at the end. “Be thoughtful about naming” does nothing; “name it after what it returns, then reread the call site” does.