alirezarezvani/claude-skills: a 388-skill library for Claude Code and 12 other agents

What problem the skill library solves, and for whom

An AI coding agent starts each session with general knowledge and no house rules. If you want it to run a security audit in a fixed order, write a grant proposal in a fixed structure, or follow your team's frontend conventions, you either restate that context every time or you give the agent a file it can load on demand. This repository is a large collection of those files.

The README defines a skill as a modular instruction package containing a SKILL.md with instructions, workflows and decision frameworks, Python tools, and reference docs. It draws a distinction between three artefacts that are easy to conflate. A skill answers how to execute a task and is scoped to one domain with a neutral voice. An agent answers what task to do. A persona answers who is thinking, is cross-domain, and carries a personality. The README's own examples are "Follow these steps for SEO", "Run a security audit" and "Think like a startup CTO".

The audience is broad by design. The domain table spans engineering, DevOps, marketing including Answer Engine Optimization, security with PreToolUse hooks, compliance, C-level advisory personas, productivity, an academic research stack, and enterprise research operations. That breadth is the product. It is also the main thing to interrogate, because a catalogue this wide is unlikely to be uniformly deep.

How a SKILL.md, its Python tools and the per-tool mirrors fit together

The repository is a source tree plus a set of generated trees. The source of truth is the domain folders at the top level: engineering, marketing, product-team, c-level-advisor, research, compliance-os, finance and the rest. Alongside them sit pre-generated mirror directories for specific tools, including .codex/, .gemini/, .hermes/ and .vibe/. The README states that the Hermes and Mistral Vibe trees are BYO-sync tier: the repository ships a pre-generated tree, but you run a sync script once locally to install it into the user's home directory. It also states there is no format conversion for those two, because they use the same agentskills.io SKILL.md standard.

Conversion is a separate path. The README describes scripts/convert.sh as generating tool-specific outputs locally, and scripts/install.sh as copying them into a target project with a confirmation prompt that --force skips. The table maps each tool to a format: Cursor takes .mdc rules, Aider takes CONVENTIONS.md, Kilo Code takes .kilocode/rules/, Windsurf takes .windsurf/skills/, OpenCode takes .opencode/skills/, Augment takes .augment/rules/, and Antigravity takes ~/.gemini/antigravity/skills/.

The Python side is deliberately plain. The README says the tools are CLI scripts, all stdlib-only, with zero pip installs, and that they run anywhere Python runs. The pyproject.toml in the repository contains only pytest configuration, with testpaths set to tests and test file and function patterns of test_*. That file does not declare a package, dependencies or an entry point, which is consistent with the scripts being run directly rather than installed.

Installing through the Claude Code plugin marketplace

The README marks the Claude Code route as recommended. It is a marketplace install, so the commands run inside Claude Code rather than in a shell. You add the marketplace, then install per domain, and the README lists the domains with their skill counts in comments.

/plugin marketplace add alirezarezvani/claude-skills

/plugin install engineering-skills@claude-code-skills
/plugin install engineering-advanced-skills@claude-code-skills
/plugin install product-skills@claude-code-skills
/plugin install marketing-skills@claude-code-skills
/plugin install ra-qm-skills@claude-code-skills
/plugin install pm-skills@claude-code-skills

After the install completes, the skills in the named domain should be available to the agent in that session. The README does not document an uninstall, a version pin or a rollback for this route, so treat the domain names as the unit you can control. Note that the comments in the README's own snippet give counts for these domains (24, 25, 12, 43, 12, 6) that do not match the 388-skill headline, which suggests the snippet predates the current release.

Converting the library for Cursor, Aider or another non-Claude tool

For the nine tools in the multi-tool table, the flow is convert then install. The README says conversion of all skills to all tools takes roughly 15 seconds, and that install.sh prompts for confirmation unless --force is passed. The verification step in the README counts generated rule files and states the expected result.

./scripts/convert.sh --tool all
./scripts/install.sh --tool cursor --target /path/to/project
./scripts/install.sh --tool aider --target . --force
find .cursor/rules -name "*.mdc" | wc -l

That final count is the useful part of the tutorial, because it is the only end-to-end check the README offers. Be careful with the number: the README says the count should show 346 in the command comment, while the same section says each tool gets all 345 skills, and the release notes for v2.12.0 describe 380 skills while the README headline says 388. Pick the figure from the release you actually cloned and compare against that, not against the prose.

Windows, symlinks and the console encoding trap

The README's Windows note is the most concrete failure mode it documents, and it is worth reading before you clone. It states that Windows users should clone with core.symlinks enabled and Developer Mode turned on, because otherwise the .gemini/, .codex/, .vibe/ and .hermes/ mirror trees check out as one-line pointer text files instead of skills. The symptom is quiet: the directory exists, the files exist, and the content is a pointer string rather than a skill.

git clone -c core.symlinks=true https://github.com/alirezarezvani/claude-skills.git

The same note says to set PYTHONUTF8=1 so that tools printing Unicode do not crash on legacy-codepage consoles. Both points are environment setup, not bugs in the skills, and both are easy to skip on a machine that already has a working checkout from a different project. If your team is mixed-platform, this is the first thing to standardise.

Where the library is the wrong tool

The repository is a catalogue, and it does not publish per-skill maturity signals. There is no indication in the README that individual skills are versioned, tested or reviewed independently, and the pytest configuration in pyproject.toml points at a tests directory without any statement of what those tests cover. If your adoption process requires a provenance record for each instruction set that reaches an agent, this repository does not supply one.

There is also a maintenance surface question. The README references a SKILL-AUTHORING-STANDARD.md and a SKILL-PIPELINE.md at the top level, which implies an internal standard, but the README does not describe how a skill is validated against it. In a library of this size, the practical risk is not that a skill is wrong but that it is stale relative to the tool it targets, and nothing in the README lets you tell which ones are.

Finally, count drift is a real signal. The README headline says 388 skills, the multi-tool section says 345, and the v2.12.0 release note says 380. Those numbers may all be correct for different things (total skills, converted skills, skills after a triage sweep), but the README never says which is which, so any automated check you build on those figures will be fragile.

How it differs from an MCP server or a rules file

The closest alternative most teams already have is a hand-written rules file, and the difference is scope and structure. A single CONVENTIONS.md or .cursorrules file is one flat document that the agent reads in full. This repository instead produces one file per skill, so Cursor gets a directory of .mdc rules and Aider gets a CONVENTIONS.md assembled from the same source. The trade-off is real: a rules file is trivially reviewable and versioned with your code, while a converted skill tree is generated output that you must regenerate when the upstream repository changes.

The other comparison is an MCP server, which exposes tools the agent calls at runtime. Skills are instructions loaded into context, not callable endpoints. The repository does ship a .mcp.json at the top level, which indicates MCP is part of the picture somewhere, but the README's install paths do not describe an MCP server as the way to consume the skills. If your requirement is runtime tool execution rather than prompt-time guidance, this is the wrong layer.

Licence, upgrade cost and what to check before adopting

The licence is MIT, and the README carries the MIT badge. For a library that is copied into agent context and, in the conversion path, written into your project tree, a permissive licence removes the redistribution question. It does not remove the attribution question: MIT requires the copyright notice and permission notice to be preserved in copies or substantial portions, so if you vendor the converted output into a repository, keep the LICENSE file with it. This is a description of the licence text, not legal advice.

Upgrade cost is dominated by the conversion step, not the clone. The README's flow is convert then install, and the install step copies into a target with a confirmation prompt. That means an upgrade is a re-run of convert.sh followed by a re-install, and the generated files under .cursor/rules or .windsurf/skills/ will change wholesale. If you committed those generated files, every upgrade is a large diff. The alternative is to run the install step in a setup script and keep the generated tree out of version control, which the README does not describe but the layout supports.

The repository is not archived, and the last push was on 2026-08-25, which is the same timestamp as the v2.12.0 release. That release describes a consolidated sweep of 20 domains and 380 skills. There is no published cadence, so the honest position is that the project has shipped recently and you should check the CHANGELOG.md at the top level before pinning to a tag.

Editorial conclusion

Adopt it if you want a broad, MIT-licensed skill catalogue that installs through the Claude Code plugin marketplace and converts to nine other tools with one script, and if you are comfortable that the marketplace route and the convert.sh route produce different file layouts you must verify yourself. Skip it if you need per-skill provenance, pinning or independent testing before a skill reaches an agent, because the repository does not publish that. Before rolling it out, run the convert step for one tool, count the generated rule files against the documented figure, and confirm the Windows symlink caveat does not apply to your checkout.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes