Claude Code skills are not subscription products. The SKILL.md format is open — a YAML frontmatter block on top, prose underneath, dropped into ~/.claude/skills/ or ./.claude/skills/, and Claude picks it up at the next session start. There is no marketplace gate, no entitlement check, no paid tier that unlocks a different file format. Effectively every skill in the open catalog is free to install.
That means the useful question isn't "what's free?" — it's "what's worth installing first?" What follows is a curator's pick of skills I'd put on a fresh laptop on day one, grouped by what they do for me in practice. Each cluster has 5–6 picks. For each pick, I explain what it does in one line, give the install command, and tell you when it earns its slot in your global toolkit versus when you should keep looking.
The SKILL.md format is intentionally open. A skill is a single markdown file with a YAML frontmatter block at the top — a name, a description that Claude reads to decide when to invoke it, optionally a model hint, allowed-tools, tags, and a license field — followed by prose instructions for the agent. You don't need a SaaS account to read one, write one, or run one. Claude Code's loader scans your skills folders, parses the frontmatter, and registers each skill into its own internal index. No network call, no licence server, no DRM.
So when I say a skill is "free" in this guide, I mean three things stacked together: free to install (drop the file in your skills folder and restart), free to inspect (the markdown is right there — read it before you run it), and free to modify (fork it for your project, tighten the description, strip sections you don't need). What varies skill-by-skill is the licence attached to the file. Most catalogue skills are MIT, Apache-2.0, or unlicensed-public-domain-style — fine for personal and commercial use. A handful carry copyleft licences like GPL-3.0 or AGPL, and a small minority carry custom terms. None of that affects your right to install and use them privately; it affects what happens when you redistribute, embed in a product, or share a modified version downstream.
Three practical rules I follow. One: before running a skill in a sensitive context — a client codebase, a production-adjacent project — open the file and skim it. The prose is the prompt. If something says "always commit and push without asking," you want to know before you wire it up. Two: if you plan to ship a derivative work (a paid bundle, an internal tool that calls the skill, a public fork), check the licence field in the frontmatter or, if absent, the upstream repo. Three: keep a record of where each installed skill came from. The catalogue's /learn/installing-claude-code-skills/ walks through the install mechanics; I treat that page as the canonical reference and don't reinvent it here.
Everything below is install-ready under those terms. None of the picks require an external account, a paid API beyond the one your Claude session already uses, or a special build step. If a skill needs an outside service — say, an MCP server for a specific database — I'll flag it inline so you can decide whether to wire it up.
This is where most practitioners feel the first measurable lift. A well-tuned writing skill takes the awkwardness out of Claude's default voice and gives you a consistent house style without re-prompting every session. The picks below are role-generic — you'll find specific authors and variants by browsing /category/content/.
What it does: sweeps a draft for passive voice, hedging, unnecessary qualifiers, repeated openings, and AI-tell phrasing. Returns a marked-up diff rather than a full rewrite.
cp editorial-copyedit/SKILL.md ~/.claude/skills/editorial-copyedit/SKILL.mdWhen it earns its place: if you ship any prose externally — blog posts, customer emails, technical writing — this is the first global skill I'd install. Browse /category/content/ for the strongest variants.
What it does: takes a topic and a rough word target, returns an outline with H2/H3 headings, key claims per section, and the rhetorical beats. Doesn't draft the prose; gives you the skeleton to draft against.
When it earns its place: for any piece over 1,500 words. Stops you mid-draft realising the argument doesn't hold.
What it does: takes a function, module, or API surface and produces a docs page in your project's existing voice — usage example, edge cases, error states, links to related pages.
When it earns its place: project-local, not global. Drop it in ./.claude/skills/ of any repo where docs lag the code. The project-local version learns your voice from neighbouring docs.
What it does: given a sample of your existing writing (paste 500 words inline or point at a file), rewrites incoming text to match cadence, vocabulary range, and sentence-length distribution.
When it earns its place: if you write under a brand voice or collaborate with editors who flag drift. Less useful for technical writing where the convention is its own voice.
What it does: takes a paragraph and tightens it to 60–70% of its length while preserving every concrete claim. Surgical, not generative.
When it earns its place: emails, release notes, landing-page copy, anything where length is the enemy. I use it constantly; pairs well with the copyedit skill.
What it does: scans a draft for quoted material and unsourced statistical claims, lists them with line numbers, and asks you to confirm each. Doesn't fabricate citations.
When it earns its place: editorial workflows where you can't ship an unsourced number. Particularly valuable when you're synthesising from multiple research drops.
Engineering is the densest cluster in the catalogue. The risk here is installing too many overlapping skills and watching Claude get confused about which one to invoke. Pick one or two per concern, install globally, and add project-local overrides where the convention differs.
What it does: reviews a diff or PR for correctness bugs, security issues, missed edge cases, and obvious refactor opportunities. Returns prioritised findings, not noise.
cp code-review/SKILL.md ~/.claude/skills/code-review/SKILL.mdWhen it earns its place: this is the single most-installed engineering skill for a reason. Browse /category/engineering/code-quality/ for variants tuned to specific languages or stacks. The good ones explicitly opt out of style nits and focus on substantive issues.
What it does: reads a function and produces a test file covering the happy path, boundary cases, and the failure modes that aren't obvious from the signature alone.
When it earns its place: if you ship libraries or backend code with non-trivial logic. Less useful for UI-heavy work where the right test surface is integration, not unit.
What it does: given a target file or function and a one-line intent ("extract the validation logic," "split this into two responsibilities"), produces a minimal diff that achieves the goal without drive-by changes.
When it earns its place: when you'd otherwise burn a session arguing about scope. The discipline of forcing a one-line intent up front is the value.
What it does: takes a natural-language question and your schema (paste or auto-discovered via an MCP database server) and returns a parameterised query plus the assumptions it made about your data.
When it earns its place: if you regularly write ad-hoc analytics queries. Pairs with one of the database MCP servers for live schema introspection.
What it does: takes an error and a brief description of what you were doing, returns the most likely root cause plus the two or three next investigation steps, ranked.
When it earns its place: debugging sessions where you'd otherwise flail. Browse /category/engineering/observability/ for tighter variants.
What it does: takes a decision you've made or are weighing, produces an Architecture Decision Record in the standard format: context, decision, alternatives considered, consequences.
When it earns its place: teams that commit ADRs alongside code. The discipline of writing the ADR catches bad decisions before they ship.
Ops skills sit on a different risk profile than writing or code-review skills. A bad ops skill can produce a plausible-looking kubectl command that wrecks staging. Read these before installing, and prefer skills with explicit "dry-run first" discipline in their prose.
What it does: guides you through triage during a live incident — severity assessment, comms templates, log-pulling commands, and the postmortem stub at the end. Optimised for a calm checklist, not creative problem-solving.
When it earns its place: if you carry pager rotation. Project-local versions can encode your team's runbook URLs and on-call roster references.
What it does: walks the pre-deploy gates — CI status, migration safety, feature-flag posture, rollback triggers, approvals required. Refuses to confirm "ready" without checking each item.
cp deploy-checklist/SKILL.md ~/.claude/skills/deploy-checklist/SKILL.mdWhen it earns its place: any environment where a bad deploy costs more than your worst hour. Browse /category/engineering/devops/ for stack-specific variants.
What it does: given a recurring ops task ("rotate the database password," "failover to the warm standby"), produces a step-by-step runbook with verification commands between each step and a rollback path.
When it earns its place: team that captures institutional knowledge in repos rather than heads. The bigger your team, the higher the ROI.
What it does: reads a cost report (CSV export from your cloud's billing console) and identifies the top spend categories, anomalies, and the three actionable cuts you could make this week.
When it earns its place: quarterly cost reviews or when finance asks where the bill went. Not a daily-driver.
What it does: reviews Terraform, Pulumi, or CloudFormation for safety issues — wildcard IAM, public buckets, unencrypted volumes, missing tags — and proposes fixes.
When it earns its place: if you write infrastructure code. Browse /category/engineering/cloud-platforms/ for stack-specific ones; the generic ones are weaker.
What it does: takes current utilisation numbers and a growth assumption, returns a 6–12 month capacity model with the inflection points where you'll need to scale.
When it earns its place: when budget season hits or you're sizing infrastructure for a roadmap. Niche but valuable when needed.
Research skills are where I'm pickiest. The wrong skill will confidently fabricate citations or paper over uncertainty. The good ones surface what they don't know and refuse to guess.
What it does: takes a research question and a batch of source links, ranks each by relevance and reliability, flags duplicates, and tells you which to read first.
When it earns its place: any time you're drowning in tabs. Doesn't summarise the sources — that's a separate skill.
What it does: reads N sources and produces a synthesis that explicitly marks where sources agree, disagree, or have gaps. Inline citations to the source you fed it; no hallucinated URLs.
When it earns its place: literature reviews, competitive analyses, anything where you need provenance. Browse /category/science/ for academic-research-tuned variants.
What it does: given a competitor's public surface (website, docs, blog), produces a structured brief: positioning, messaging pillars, pricing posture, recent moves, gaps you could exploit.
When it earns its place: product or marketing roles. Quarterly cadence rather than daily.
What it does: takes a dataset and a natural-language question, walks through the analysis plan, runs it (via attached tools or by writing the script), and returns the answer with the caveats.
When it earns its place: regular ad-hoc analytics. The good ones show their working — the bad ones just hand you a number.
What it does: scans a document for statistical claims, checks the underlying calculation where possible, flags claims that can't be verified, and suggests how to source the rest.
When it earns its place: editorial or analyst work where a wrong number is a credibility hit. Pairs with the citation checker from the writing cluster.
What it does: takes raw notes from user interviews or stakeholder conversations and produces a structured themes-and-quotes document, with quote provenance preserved.
When it earns its place: UX research, product discovery, or any qualitative-evidence workflow. Browse /category/product/ for variants.
These are the skills that make using Claude faster, rather than producing a specific artefact. They're the smallest cluster by volume but disproportionately useful day-to-day.
What it does: reads your recent commits, PRs, and ticket activity, produces a yesterday/today/blockers update in your team's format.
When it earns its place: if you do async standups. Saves five minutes per day and surfaces work you forgot you'd done.
What it does: reviews your CLAUDE.md or memory files, merges duplicates, prunes stale entries, surfaces conflicts. Run it monthly.
cp consolidate-memory/SKILL.md ~/.claude/skills/consolidate-memory/SKILL.mdWhen it earns its place: anyone running long-lived memory files. The longer they live, the more this earns.
What it does: reviews a SKILL.md you're writing for anti-patterns — vague triggers, missing scope discipline, overlong context, ambiguous tool usage.
When it earns its place: when you write skills. Especially valuable for project-local skills meant to encode team knowledge. The /learn/skill-md-anti-patterns/ guide pairs with this.
What it does: takes a feature idea and produces a structured spec — problem statement, success metrics, scope, non-goals, open questions. Refuses to fill in details you haven't decided.
When it earns its place: product, engineering planning, anything that needs alignment before code lands. Browse /category/product/ for role-specific variants.
What it does: takes a stream-of-consciousness paragraph and produces a structured list of decisions, tasks, open questions, and parking-lot items.
When it earns its place: end-of-meeting notes, end-of-week reflections, any moment when raw thinking needs structure.
What it does: at the end of a long session, produces a handoff doc — what was done, what's open, what the next session needs to know. Refuses to drop context silently.
When it earns its place: if you context-switch heavily or work across long-running projects. Cheaper than re-explaining context every session.
The niche clusters are where the catalogue's breadth shines. You don't install these by default — you install them when you need them, then keep them around. Many of these have specialist authors who maintain a small set of related skills.
What it does: reviews a contract draft (MSA, vendor agreement, SaaS terms) for unusual clauses, missing protections, and the rough negotiation surface. Not legal advice — a triage tool.
When it earns its place: founders, ops leads, anyone who sees more contracts than their legal counsel can turn around in the same week. Browse /category/general/legal-compliance/.
What it does: reads an inbound NDA and flags the half-dozen clauses that vary (term length, jurisdiction, residuals, non-solicit) so you can compare against your standard posture.
When it earns its place: if you sign NDAs more than monthly. Cuts the read down to thirty seconds.
What it does: takes a P&L or balance sheet (CSV or pasted) and produces a plain-language narrative — what's growing, what's compressing, what to ask about.
When it earns its place: board prep, investor updates, due-diligence work. Browse /category/general/finance-personal/ for adjacent personal-finance variants.
What it does: takes an inbound support ticket and your tone guide, produces a draft response with the right warmth, factual content, and next-step. Refuses to commit to deadlines you haven't authorised.
When it earns its place: CS, founder-led support, or anyone in the loop on customer comms. Browse /use-case/customer-support/.
What it does: takes an artefact (a privacy policy, a marketing claim, a security posture statement) and checks it against a named framework (SOC 2 controls, GDPR Art. X, HIPAA).
When it earns its place: regulated environments. Read the prose carefully — the framework definitions need to be current.
What it does: takes a target and your value proposition, produces a personalised cold email that doesn't read like a cold email. The good ones explicitly refuse generic phrasing.
When it earns its place: founder sales, BD, anyone doing direct outbound. Browse /use-case/cold-outreach/ for tuned variants.
The picks above are a starting kit. The catalogue grows daily — skills get added, refined, and occasionally retired. Three ongoing-discovery surfaces are worth knowing.
/category/ — the top-level index by domain. Pick a category, then narrow by sub-category. Engineering breaks into code-quality, devops, observability, data-engineering, and a dozen more. General covers everything that doesn't fit a vertical — automation, personal productivity, knowledge management. Each category page lists the skills sorted by name, with one-line descriptions you can scan in under a minute.
/best/ — a hand-curated editor's selection. Not algorithmic, not popularity-sorted. The point is a short list of skills I'd point a new practitioner at without hesitation. When I'm trying a new domain — say, I haven't written much SQL recently and want to see what's new — this is where I start.
/recent/ — the freshest additions. New skills land daily. Browsing recent is how you spot patterns: when three new code-review skills appear in a week, that's a signal the underlying convention is still settling. When you see five new "sub-agent" skills, the meta-pattern is hardening.
Beyond those three, there are a couple of habits worth forming. Follow authors. A handful of practitioners maintain coherent multi-skill toolkits — a writing kit, an engineering kit, an analyst kit. If you find one skill that matches your taste, the author's other skills will often match too. Read the prose, not the description. The description: field is what Claude reads to decide invocation; the body is what you read to decide whether to install. A skill with a tight description but a sprawling, contradiction-filled body is a worse pick than a skill with a verbose description and clear, disciplined prose.
And uninstall regularly. The friction with a large global skills folder isn't disk — it's Claude's invocation cost. With sixty installed skills, every session start does sixty frontmatter reads, and Claude's decision about which to invoke gets noisier. Trim to the ones you've actually used in the last month. The catalogue isn't going anywhere; re-installing is one cp away.
One closing point that's worth more than any individual pick above: where you install matters as much as what you install.
Global (~/.claude/skills/) is for general-purpose tools you'll use across projects. The copyedit skill, the code-review skill, the standup synthesiser, the memory consolidator. Tools that have nothing to do with any particular codebase. Keep this folder lean — I'd suggest twenty skills as a soft ceiling for most practitioners. Once you cross thirty, the invocation noise floor rises and Claude's decisions about which skill to invoke get less reliable.
Project-local (./.claude/skills/) is for skills that encode this-repo-specific knowledge. A test-generation skill that knows your testing framework conventions. A docs writer that has learned your voice. A pre-deploy checklist that references your team's runbooks. These should live in the project and ideally be committed to git — they're institutional knowledge, and the highest-leverage use of the skills format is distributing that knowledge automatically to every teammate on clone.
The installing-claude-code-skills guide covers the precedence rules: project-local always wins over global for same-named skills. That's the override pattern. Keep a generic code-review globally; override it with a Rust-aware code-review in your Rust repo's ./.claude/skills/. The agent picks the right one based on context.
One more habit. Every quarter or so, run a global-folder sweep. ls ~/.claude/skills/ and ask, for each entry: did I use this in the last three months? If no, archive it. Move it to ~/.claude/skills-archive/ and keep the file around for fast re-install. The folder you keep active is what shapes your sessions — make it the toolkit you actually reach for, not the toolkit you once meant to learn.
That's the entire discipline. Pick from the curator's list above as a starting kit, install lean, override locally where projects need it, prune quarterly, and use /category/, /best/, and /recent/ as your ongoing discovery surfaces. The catalogue does the breadth; you do the curation.
Found a bug or want a topic covered? Email [email protected] or open an issue via GitHub.
SKILL.md files, not affiliated with, endorsed by, or sponsored by Anthropic.