Awesome Claude Skills: an index of instruction folders, and a gateway pitch attached

A skill is a SKILL.md file, and the description is all that loads first

A Claude Skill is a folder containing a `SKILL.md` file with YAML frontmatter carrying a name and a description, followed by Markdown instructions, and optionally bundled with scripts, references and assets. Loading is progressive, and this is the design decision that makes large collections workable. At session start the agent sees only each skill's name and description, roughly 100 tokens per skill. The full body, typically under 5,000 tokens, arrives only once the agent decides the skill is relevant, and anything in `scripts/` and `references/` loads on demand.

The consequence falls on the description rather than the instructions. A hundred tokens is the entire budget your skill gets for being noticed, so a vague description means a well-written body that never runs, and no error is raised when that happens. A single agent can host hundreds of skills without its context window swelling, which is what makes a list of this size possible at all.

Skills are not tools, so a skill cannot reach anything on its own

The clearest paragraph in this README separates three layers that are easy to conflate. MCP defines how an agent connects to external systems, covering authentication, transport and tool discovery. Tools are the individual functions an agent invokes. Skills define the workflow, meaning what to do, in what order, with what guardrails, once the connections and tools are already in place. In production all three run together: MCP for access, tools for actions, skills for behaviour.

That division has a blunt consequence for anyone reading a list like this one. Installing a skill adds no new capability to your agent. A skill that instructs the agent to post to Slack is a procedure, and without an MCP server providing that connection and a tool exposing that action, the procedure has nothing to call. The list therefore cannot deliver on its own what it advertises, and the gap is filled by choosing and operating an integration layer yourself.

The list is an index, but about thirty skill folders live in this repository

The README advertises over a thousand production-ready Claude Skills and Plugins, grouped under ten headings that run from Document Processing and Development & Code Tools through to Security & Systems and App Automation via Composio. Alongside the index, the top level of the repository holds roughly thirty directories of its own, including `changelog-generator/`, `skill-creator/`, `mcp-builder/`, `document-skills/`, `webapp-testing/` and `template-skill/`.

Two kinds of link sit side by side in those lists, and they carry different risks. Some entries point at a relative path such as `./changelog-generator/`, which is a folder in this repository and moves or disappears if the maintainers reorganise. Others point at somebody's GitHub repository, credited in the entry text with an author handle, which is a separate project on its own release cycle and its own standards. Nothing in the list marks which entries have been reviewed, so a reader has to treat a first-party folder and an outside pull request as equally unvetted.

The fastest route in the README asks for a Composio API key

The quickstart at the top of the file is not a tour of the list. It installs a bundled plugin and connects Claude to external applications:

claude --plugin-dir ./connect-apps-plugin

Then run the setup command inside the session:

/connect-apps:setup

The setup step asks you to paste an API key, obtained from the Composio dashboard, after which the session is restarted:

exit
claude

That path exists to let Claude send emails, create issues and post to Slack, and the plugin handles authentication and connects to over a thousand apps using Composio underneath, with the supported set enumerated on the Composio toolkits page. The cost of that convenience is concrete: the shortest route in this README requires an account with a third party, and the outbound actions of your agent are routed through a gateway that somebody else operates. Every other entry in the list has no such requirement.

Chrome Relay puts your logged-in browser session in scope

One entry is worth reading closely because of what it reaches rather than what it writes. Chrome Relay drives the Chrome session you already have open, including cookies, single sign-on, installed extensions and localhost, through a local command line bridge. It installs with `npx skills add chrome-relay` plus a Chrome Web Store extension, and is described as a real-Chrome counterpart to Playwright browser automation, with no remote relay component.

The appeal is obvious, since an agent that can use the browser you are already signed into skips the login flows that break automated tests. The consequence is that the skill's scope is your authenticated identity across every site you have a session for, not one application. A skill that writes a file and a skill that drives a signed-in browser look identical in a list, and they differ by roughly the value of your accounts. This is the clearest example of why the guardrails inside a SKILL.md deserve the same attention as the instructions.

No license file at the top level and no releases to pin

The repository's top-level entries are directories, `CONTRIBUTING.md`, `README.md` and `.github/`, with no LICENSE file among them, and the license field for the project comes back unknown, even though the README's badge row links the text of the Apache License 2.0. There are no GitHub releases either. The last push was 2026-09-18, so the index is being touched, but nothing announces a version.

Two consequences follow for anyone who copies from it. A skill is a set of instructions you may run with your own credentials against your own systems, and a list that links the Apache 2.0 text without shipping the license leaves you to decide for yourself what the grant covers, entry by entry, especially for the folders authored by people credited only with a handle. And with no tags, there is no commit to record as the state you reviewed, so the exact contents of any skill you depend on can change without your noticing.

Guardrails are prose in a Markdown file, not something a runtime enforces

The README's own framing is that skills define what to do, in what order, with what guardrails, and that framing deserves pressure. A guardrail written in Markdown is a sentence the model reads, not a permission the system checks, so its strength depends on how the instruction is phrased and how much context surrounds it. Nothing in the skill format stops a body from instructing the agent to send data somewhere.

The compensating control is the integration layer rather than the skill. Composio's MCP Gateway is described as a single endpoint for over a thousand integrations with built-in authentication, team-based access controls and audit logs, and those are the properties that hold when the instruction itself is only a suggestion: who may call what, and a record of what was actually called. Teams that need to know what their agent did get that from the gateway, and lose it when a skill is wired to a home-grown script instead. Budget for the audit trail, not just for the skill.

Editorial conclusion

This repository is worth treating as a directory rather than a dependency. The format is a plain file convention, so a skill you copy keeps working across Claude Code, Claude.ai, the Claude API, Codex, Cursor, Gemini CLI, Antigravity and Windsurf, and the progressive loading design means adding skills costs roughly a hundred tokens each until one is actually used. Two cautions decide whether it fits. A skill gives your agent instructions, never reach, so anything that touches an external system needs an MCP connection and tools you supply separately. And the entries arrive without a license file in this repository, third-party authorship, and no releases to pin. Before you install one, read its SKILL.md in full, confirm who wrote it, and work out where the actions it describes will actually execute.

Frequently asked questions

Official sources

1. Official README
2. Project repository