Awesome Agent Skills

Skills for AI coding agents: code review, test writing, design docs, debugging, security audits, refactoring, and cleaning up AI-written code and text. Each skill is a folder with a SKILL.md in the Agent Skills format — install by copying it into your agent's skills directory.

Distilled from widely-used public collections and the documented practice of large open-source projects, then sharpened over several rounds of use on real repositories.

Compatible with Claude Code, Claude.ai, OpenAI Codex, Gemini CLI, Cursor, GitHub Copilot, opencode, Amp, Windsurf, Antigravity, Kilo Code, Qwen Code, and any other agent that supports the standard. See Install for exact paths.

• Awesome Agent Skills
  • Contents
  • Quick start
  • Install as a plugin
  • Install
    • Copies or symlinks
  • Skills
    • Code review
    • Code quality and refactoring
    • Testing
    • Design and planning
    • Understanding a codebase
    • Debugging and reliability
    • Audits
    • Git and repository operations
    • Agent maintenance
    • Writing and text
    • Content marketing
      • Running them
      • How long a publishing run takes
  • Picking between similar skills
  • Usage examples
  • Skill format
  • Contributing
  • How these were built
  • Design principles
    • Which layer to install
  • Related
  • License

Clone once, then install every skill into your agents with one command:

git clone https://github.com/khasky/awesome-agent-skills.git
cd awesome-agent-skills
npx skills add ./skills -g -s "*" -a claude-code codex gemini-cli -y

The skills CLI installs all skills globally into Claude Code, Codex, and Gemini CLI. Change -a to pick agents (-a "*" installs to every detected agent); add --copy to force independent copies.

Then confirm what you got. The CLI may link an agent's directory into its own store at ~/.agents/skills/ rather than into your clone, so up to two hops sit between the clone and the agent, and any hop can be a copy:

A link names its target — an arrow in ls -l, a Target in PowerShell. An entry with no target is a copy, and a git pull in your clone will not reach it. Copies or symlinks has what to do about that.

Keep them current. Where the install linked through to your clone, one pull moves every skill:

cd awesome-agent-skills && git pull

Where it copied, npx skills update -g re-fetches instead. Either way, re-run the skills add command to pick up skills added since. Then ask the agent naturally ("review this diff against main") or invoke a skill explicitly (/awesome-code-review in Claude Code and Cursor, $awesome-code-review in Codex).

Prefer not to clone? npx skills add khasky/awesome-agent-skills installs straight from GitHub — but it won't auto-sync with git pull.

The plugin installs every skill at once and updates with the repository. Pick the plugin or the skills add install from the Quick start, not both: both put every skill in front of the agent twice.

• Invoke a plugin skill as usual: /awesome-code-review in Claude Code and Cursor, $awesome-code-review in Codex. Qwen Code prefixes it with the extension's name: awesome-agent-skills:awesome-code-review.
• Installed users get new work when the version in .claude-plugin/plugin.json changes, which every release bumps.
• CI installs the plugin into Claude Code, Codex, Copilot CLI and Gemini CLI on every push. The Antigravity CLI and Kilo Code rows were checked by hand (agy 1.2.14, kilo 7.8.1: all skills listed); the Qwen Code and Cursor rows follow each agent's documentation.
• Antigravity CLI installs from a folder only, and copies it: an owner/repo target is refused. Kilo Code has no plugin format for skills (kilo plugin installs npm code modules), so it reads the clone through skills.paths instead, and a git pull reaches it directly.
• Any other agent (opencode, Amp, Windsurf, Kiro, Grok Build, ...): use the Quick start or copy the folders by the table below.

The Quick start covers Claude Code, Codex, and Gemini CLI. For any other agent, or to install by hand without the CLI, a skill is a folder: copy it into the directory your agent reads. Most agents also read the shared .agents/skills/ path, so one copy can serve several tools at once. To stay in sync with git pull, link from your clone instead of copying — Copies or symlinks has the command and the way to tell the two apart.

• Claude.ai (web): zip a skill folder and upload it under Settings → Skills.
• Gemini CLI can also install straight from a repo URL: gemini skills install <repo-url> --consent.
• Restart or reload the agent afterwards so it picks up new skills.

What "compatible" means here: the skills are plain SKILL.md folders under the open standard, and the Quick start (Claude Code, Codex, Gemini CLI) is the path they are used through day to day. The other rows are the paths each agent's own documentation gives; installs there have not been exercised for every release, and whether a skill then behaves as documented is not checked agent by agent. If an agent trips on a skill, file an issue with the agent and its version. The store-and-link behavior described below was confirmed on Windows with a local clone as the source — other systems, and installs from a repo URL, may link where that one copied, so run the check and trust its output over this paragraph.

A copy never breaks and never announces itself stale. It stays the version you installed, and you learn that from a skill behaving like an old one rather than from an error. That is the argument for linking, and it is worth verifying rather than assuming, because several of the paths here yield copies:

• Installing straight from GitHub (npx skills add khasky/awesome-agent-skills) and --copy both copy by design.
• A shell may answer a link request with a copy instead. Git Bash on Windows does that for ln -s, silently and with exit code 0, unless MSYS=winsymlinks:nativestrict is set.
• With a local path as the source, skills add has been seen writing copies into the store even without --copy.

Linking a skill by hand, once the copy is out of the way:

Some systems restrict who may create a link, and some filesystems have none at all — Windows wants Developer Mode or an elevated prompt, and FAT32 volumes, certain network shares and container mounts will refuse. Where linking is unavailable, npx skills update -g refreshes the copies instead: it re-fetches the source, it does not follow your clone.

To clear an install, npx skills remove -g -s <name> takes explicit skill names, one per skill (-s "*" removes every CLI-installed skill, including ones from other repos). Every skill here is prefixed awesome-, so one glob covers them when you delete the folders yourself.

These five chain, and the publisher needs a browser bridge set up before its first run. The step-by-step guide covers installing the Playwright MCP extension, reading the per-profile token, the MCP server entry that pairs them, running each skill alone, and running the whole chain:

• Content skills guide — English
• Руководство по content-навыкам — Russian

Measured from the publisher's own ledger timestamps on a 25-platform run. The figure is the full cycle per platform: open the composer, fill it, attach the image, submit, read back the permalink, diff it against the source file, write the ledger.

15 platforms took 73 minutes of uninterrupted work — about 5 minutes each, which is the number to plan with. The first platform of a session costs more, because the bridge gate, the login preflights and the source scan all land on it: budget 15–20 minutes before the first post goes out. Posts to different platforms follow each other immediately; two posts to the same platform stay at least 2 hours apart.

Some skills sit next to each other on purpose: they share a file format, a target, or a vocabulary. The overlap is real — what separates them is one question, in the last column. Names are shortened there; every skill links from the tables above.

Skills trigger on intent — plain requests work. Explicit mentions make the choice deterministic:

• "Use awesome-code-review on the diff against main: Critical / Suggestions / Nice to have, with file:line references."
• "Here are the review comments — use awesome-code-review-feedback: agree, clarify, or push back with evidence."
• "awesome-bug-fix for this error: reproduce first, root cause before any fix — [paste logs]."
• "awesome-security-audit the files touched by this change (auth, injection, secrets)."
• "Audit this repo with awesome-leak-audit before we open-source it."
• "awesome-humanize-en: remove the AI voice from this draft."
• "awesome-translate-ru-en: mirror docs-ru/ into docs-en/ — same structure, translate each file."

They also chain: implement → awesome-code-cleanup in audit mode (read-only findings) → apply the cleanup → awesome-code-review before merge. Or: awesome-content-campaign from your repo and site → review the drafts → awesome-content-publisher ships them on schedule.

The four skills that rewrite a published history or post to live accounts (awesome-git-history-reset, awesome-git-history-rebuild, awesome-git-author-rewrite, awesome-content-publisher) set disable-model-invocation: true: in Claude Code and Cursor they run only when you name them (/awesome-content-publisher), never on a matching request alone.

Each skill follows the Agent Skills specification:

skills/<skill-name>/
├── SKILL.md          # required: YAML frontmatter (name, description) + instructions
└── references/       # optional: detailed docs the agent loads on demand

No README.md inside a skill folder. A skill folder holds only what the agent reads: SKILL.md and the files it names. What each skill is for and when to reach for it belongs here in the root README (the tables above), so a reader compares skills in one place instead of opening every folder. Where a skill ships references/, SKILL.md itself maps them: an agent that skips the map skips the files.

Instructions only, no code. A skill is Markdown and nothing else: no scripts, no templates, no fixtures, no binaries. A check is written as what to look for, what counts as a pass and what evidence to report, and the agent writes whatever it needs in whatever language fits its own environment — which is also the one that knows the platform, the shell and the project in front of it. Nothing here runs the author's code on your machine.

The frontmatter description tells the agent when to activate the skill; the body loads only after activation, and references/ files only when needed — so a large skill still costs little context until used.

The collection shares 2 rating vocabularies, so reports never mean different things by the same word:

• Findings — Critical / High / Medium / Low / Informational, rated on impact and reachability. A skill may truncate the scale from the bottom: top 4 where Informational carries no meaning (architecture, database), top 3 where Low doesn't either (accessibility, copy-editing, landing mechanics), and its output section states which tiers it uses. Never reorder or rename tiers.
• Verdict — SHIP / FIX / BLOCK, for the read-only audits that gate a release, always paired with NOT ASSESSED for anything that could not be checked.

awesome-code-review keeps its own reviewer-comment buckets (Critical / Suggestions / Nice to have) because those are addressed to an author, not to a release gate.

The repository has one gate, and it is the same one locally and in CI:

python3 scripts/lint.py          # run the gates by hand
python3 scripts/install-hooks.py # once per clone: run them before every commit

The installer writes a pre-commit hook that calls scripts/lint.py. Where core.hooksPath points outside the repository — a tool that manages git identities, say — it says so: git runs that directory's hooks instead, and the gate fires only if they chain through to the repository's own.

3 passes per skill:

1. Survey — the widely-used public skill and prompt collections, plus the documented practice of projects that do the job at scale: kernel and git patch-series rules, OpenStack's commit guide, Conventional Commits, OWASP, WCAG, PTES, NIST SP 800-115.
2. Distill — keep what changes an agent's output, drop what it already does untold. A rule that survives is one an agent gets wrong without it. Borrowed material is cited where it is used.
3. Iterate on real work — every skill is run on real repositories, revised from what it got wrong, and run again. The phases, stop gates and output formats here are what survived those rounds.

• Self-contained — every skill is complete in this repo; no chasing external links or docs.
• A small set — enough skills to cover repeated engineering work, few enough to remember.
• Portable — plain SKILL.md per the open spec, stack-agnostic, nothing vendor-specific baked in.
• Verification-first — skills end with the check that proves the claim: run the command, read the output, then say "done".

A rule is a standing constraint the agent honors without being asked; a skill is a procedure you invoke, with phases and an output contract. The two layers overlap by design: rules/code-review.md in Awesome AGENTS.md sets the bar every review must meet, awesome-code-review here runs the review and produces the report. Install both: rules keep everyday work in line, skills handle the jobs you name.

Part of a set of agent tooling — pick the layer you need:

• Awesome Agent Skills — this repo: portable SKILL.md skills every agent loads — code review, debugging, security and leak audits, code and text cleanup.
• Awesome AGENTS.md — the base, tool-agnostic ruleset every agent imports (one AGENTS.md).
• Agent MCP Integrations — MCP servers that connect agents to browsers, cloud, databases, infra, and domain APIs.
• Claude Code Token Optimization — the token-efficiency layer (RTK, LSP, Context7, codebase-memory-mcp, claude-mem, Caveman, Ponytail).
• Claude Code Security Audit — the layered security-audit workflow (deep audit, continuous guardrails, scanners).

Released under the MIT license. The awesome-humanize-en skill adapts material from humanizer-ru and, for its venue rules, editing-trace tests and evidence ledger, from sepia; awesome-seo-audit cross-checked its Google-policy detail against claude-seo, from which it also took the falsifiability line on every recommendation, the fix-ordering rule and the refusal of unsafe fetch targets, and took its collection mechanics from on-page-seo; its two-axis verdict follows claude-seo-ai and its evidence-and-confidence contract follows Agentic-SEO-Skill. awesome-agents-md-generator takes its section set and its differences-only nested files from agentseed, and its file format from agents.md. awesome-code-explainer takes its signals-first method, its input forms and its reading-path and open-questions sections from ExplainThisRepo. awesome-code-docs takes its dependency-graph method — symbol resolution, topological order, bottom-up summaries — from AutoDocs.