Claude Skills on GitHub: Where to Find Them and How to Install Them Safely

Almost every Claude skill in existence lives on GitHub. That is the good news and the problem: the supply is enormous, entirely unreviewed, and sorted by nothing more useful than star count. This is a practical guide to sourcing skills from GitHub — what is worth looking at, how to install a folder, how to tell a good skill from an abandoned one, and the safety rules that matter more than people admit.

Why GitHub is the distribution channel

A skill has no registry, no versioning, and no build artifact. It is a directory containing a SKILL.md file and, optionally, scripts and reference documents. Distributing one means distributing a folder — and the place the world keeps folders is git. So there is no npm-for-skills, and there does not need to be.

Two consequences follow. Installing is trivially easy: copy the directory. And nothing has been checked by anyone: no review, no signing, no quality bar. Both are worth holding in your head at the same time.

What is actually on GitHub

Anthropic's open-source skills. The document skills — PDF, Word, Excel, PowerPoint — are published by Anthropic and are the best-written examples of the format available anywhere. Even if you never install them, read one: they demonstrate the core pattern of routing logic in markdown and mechanical work in bundled scripts.

Awesome-lists and collections. Big aggregator repos listing hundreds of community skills. Useful for discovering that a category exists; useless as a quality signal, since inclusion usually means someone opened a pull request and nobody objected.

Individual developers' dotfiles. An underrated source. When an engineer publishes their .claude/ directory, you get skills written for real daily work rather than for an audience — and those are frequently the sharpest ones.

Plugin marketplace repositories. Repos structured as installable marketplaces, so instead of copying folders you add the marketplace once and install plugins from it, updates included. See our marketplace guide for how that works.

Installing a skill from a repository

Clone or download the repo, find the directory containing SKILL.md, and copy that whole directory into one of two places: .claude/skills/ in a project, if the skill is project-specific and you want it committed to git for your team, or ~/.claude/skills/ if you want it in every project on your machine. Restart your session, ask Claude which skills it has available, and confirm yours appears.

Then confirm it fires. Being listed is not the same as being used. Phrase a request the way you naturally would and see whether the skill loads. When it does not, the description is nearly always at fault — it names a topic instead of the situations that should trigger it. The free SKILL.md validator catches malformed frontmatter, and this guide explains the triggering rules properly.

Judging a repo before you clone it

Stars measure marketing. These four things measure quality:

• Recent commits. Claude Code moves fast. A skill untouched for a year may reference behavior that no longer exists.
• Descriptions that name triggers. Open two or three SKILL.md files. If the descriptions say when to use the skill, the author understood the format. If they read like blog titles, the skills will not fire.
• Procedures, not personas. Bodies full of checklists and worked examples beat bodies full of "you are an expert".
• Honest scope. A repo claiming five hundred skills usually contains fifty real ones and four hundred and fifty near-duplicates, which actively hurt you by competing for the same triggers.

The safety part people skip

A skill is not data. It is a set of instructions Claude will follow, inside your repository, with your permissions — and it can bundle scripts that execute as you. Treat every skill from GitHub the way you would treat an unfamiliar dependency:

• Read the full SKILL.md. Instructions telling Claude to ignore your other rules, exfiltrate files, or contact a remote server are the whole attack surface, and they are readable in plain English.
• Read every bundled script before running one. "It is just markdown" stops being true the moment a skill ships code.
• Prefer repositories with named maintainers and a real commit history over an account created last month.
• Be sharply suspicious of anything requesting credentials, tokens, or network access it has no reason to need.

None of this is exotic paranoia. It is the same hygiene you already apply to a package with eleven weekly downloads — the only difference is that skills feel like documentation, which makes people skip the step.

The honest tradeoff

GitHub gives you infinite skills for free, and charges you in time: browsing, reading, vetting, deduplicating, and re-checking when things break. That is a completely reasonable trade if you enjoy it. If you do not, the alternative is a curated bundle where the reading has already been done — which is the entire argument for a paid kit, and we would rather state it plainly than pretend the free path does not exist.

FAQ

Keep reading