Microck/ordinary-claude-skills: a local library of 600+ Claude Skills

What ordinary-claude-skills collects, and who it is for

Claude Skills are prompt packages plus scripts that teach Claude a task without restating context every time. The README frames them plainly: "skills are basically fancy prompt packages and scripts." Individually they live in scattered repositories. This project gathers hundreds of them, from Anthropic, composiohq, k-dense-ai and unnamed contributors, into one cloneable tree organized by category.

The intended reader is someone who already knows what a Skill is and does not want to open twenty browser tabs to find one. The README lists two consumption paths: a static site with search and categories, or a raw git clone for mapping skills into MCP servers and agents. Categories span science and academia (protein folding, astronomy, lab automation), software engineering, infrastructure (Kubernetes, Docker, Terraform), data and AI (vector databases, LLM evaluation, RAG), business, creative work, and web3. If your work sits in one of those buckets, there is probably a folder for it.

How skills load, and how the repository is laid out

The mechanism that matters is lazy loading. According to the README, skills load only when needed, which saves context window space and keeps Claude from reading instructions it does not need yet. That is the reason to keep skills as separate folders rather than pasting all of them into a system prompt.

The tree separates raw aggregation from organization. skills_all holds everything with no sorting. skills_categorized holds the same content under category folders, with paths like backend/api-design-principles and web3-tools/solidity-security. docs/ contains the static site. The README states the folder structures are only "somewhat consistent," which is the honest description of a bulk import: expect naming drift between contributors.

The README also notes that Claude will not use a skill it does not know exists. You have to tell it, either in the system prompt or by attaching the folder to project context. Nothing in the repository auto-registers skills.

Installing ordinary-claude-skills and running a first skill

There is no package to install. The README gives one setup step, a clone, and then a choice of how to consume the files.

git clone https://github.com/Microck/ordinary-claude-skills.git
cd ordinary-claude-skills

After the clone you should see skills_all/, skills_categorized/, docs/ and README.md at the top level. For claude.ai, the README says to open your profile, go to custom skills, and upload the folder for the skill you want. For API or agent work, point an MCP client at the directory. The README's config example wires the filesystem MCP server to the whole skills_all directory:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/path/to/ordinary-claude-skills/skills_all"
      ]
    }
  }
}

Mapping the entire skills_all folder exposes every skill to the client at once. A narrower option the README shows is pointing the same server at one category directory, replacing the path with /path/to/ordinary-claude-skills/skills_categorized/[category]. Verification is a single question: ask Claude "can you use the [skill name] skill now?" and check the answer. If it says no, the README's troubleshooting section says the usual cause is that the skill was never attached or declared.

The non-curated selection is the real limitation

The README's own feature list leads with "non-curated selection: i dumped everything in here. if it doesnt work i probably havent noticed." That sentence should govern how you use the repository. There is no test suite, no per-skill compatibility matrix, and no indication of which skills were written against which Claude surface. A folder existing in skills_categorized means someone put it there, nothing more.

The practical failure modes follow from that. Skills can contradict each other, and the README's troubleshooting section begins to address this before the text cuts off. Loading all of skills_all into one client maximizes the chance of conflicting instructions. Skills with heavy dependency folders can also trip file size limits; the README advises ignoring node_modules inside skill folders and copying only source scripts and instructions.

This is the wrong tool if you need a vetted catalog, a security review of third-party scripts, or someone to answer when a skill breaks. It is also the wrong tool if you only need one or two skills, since cloning hundreds of folders to use two is wasted effort. In that case, go to the original source repository.

ordinary-claude-skills compared with the official Anthropic skills repository

The obvious alternative is Anthropic's own skills repository, which the README names as one of the aggregated sources. The difference is scope and accountability. Anthropic's repository publishes a smaller set of skills that the vendor maintains and documents. ordinary-claude-skills is a mirror plus community submissions, and its README states outright that it does not track whether entries work.

So the trade is breadth against provenance. If you want one skill that does a known thing and you want the upstream to fix it when it breaks, use the vendor repository. If you want to scan what the wider community has built across protein folding, Solidity security and Terraform before deciding what to install, this index is faster than searching repository by repository. The two are not mutually exclusive: clone this for discovery, then pull the specific skill from its original source when you commit to it.

Maintenance, licence and upgrade cost

The last push to the default branch was on 2026-09-06, and the repository is not archived. The README's own badge describes maintenance as passive, which matches a project whose stated policy is to fix things only if the maintainer notices and chooses to. There are no releases, so upgrades mean pulling the branch again.

That has a concrete cost. Because skills_all and skills_categorized both hold the same content, a pull can change files in two places, and any skill you have already wired into an MCP config may shift path or content without a version number to pin. If you depend on a specific skill, copy it out of the clone and keep it under your own version control.

On licensing, the repository's own LICENSE file and badge point to MIT, but the top-level metadata reports the licence as NOASSERTION, and the aggregated skills come from multiple upstream authors with their own terms. The README's license and credits section is the place to check, and individual skill folders may carry their own licence files. That is a per-skill question, not a repository-wide one, and it is worth resolving before redistributing anything from the tree.

Editorial conclusion

Adopt it if you want a local, searchable pool of Claude Skills to map into an MCP filesystem server instead of hunting individual GitHub repos. Skip it if you need vetted, tested skills or a support commitment: the README calls the selection non-curated and the maintenance badge passive. Before pointing anything at skills_all, open the individual skill folder and read its SKILL.md and scripts, because the repository does not verify that any of them work.

Frequently asked questions

Official sources

1. Issues
2. Microck/ordinary-claude-skills on GitHub
3. Project website
4. README