Skills Marketplace: 312 Claude Code Skills, Curated

The skill discovery problem nobody is talking about

Claude Code skills are good. The discovery story for them is not.

If you have spent any time in the ecosystem this year, you know the loop. Someone posts a skill in a Discord. Someone else screenshots it into an X thread. A third person forks a gist, renames it, and pushes a slightly different version to their dotfiles. By the time you find the skill you actually want, you are reading a six-month-old README that references a deprecated SDK version and a hook format that changed two minor releases ago.

There is no canonical index. There is no version pinning. There is no signal for which skills are maintained, which are abandoned, and which are just somebody's afternoon experiment that got 80 stars and never shipped a v1.

We have been collecting skills internally for the DD app portfolio for about a year. The internal index started as a flat JSON file. It became a search UI. It became a thing other people wanted access to. So we shipped it.

Skills Marketplace is live. 312 skills indexed at launch. Curated, versioned, searchable, and free to browse.

What is in the directory

The 312 skills at launch are everything we could verify works against the current Claude Code release. That number is the result of ingesting a much larger pile and dropping anything that failed our smoke test.

The directory breaks skills into the categories we actually use:

Engineering is the biggest bucket. Code review skills, refactor skills, test generation, security audit, dependency triage, migration helpers. If you have ever wanted a skill that does the boring half of a PR before you read the diff, this is where to look.

Content and marketing is the second-biggest. Blog drafting, video script outlining, distribution pack generation, newsletter drafts, social copy. We use most of these on this site daily.

Workflow and ops covers the meta-skills. Schedulers, loops, handoff generators, prune tools for archiving stale skills, audit tools that count tokens across your install. Less glamorous, more load-bearing than people give them credit for.

Domain-specific is everything else. Browser automation, scraping pipelines, image generation, audio transcription, vault management for Obsidian users, deploy helpers for Coolify and Vercel. Long tail by design.

Every skill page has the same shape. Description. Trigger phrases. Required tools and permissions. Last-updated date. Source repo. Install command. A version selector if the skill has tagged releases. A small graph showing install count over the last 30 days for skills that opted into telemetry.

Search is fast because the index is small and pre-built. Filters stack. You can ask for engineering skills updated in the last 14 days, with no MCP dependencies, that work on the current Claude Code version, and get a result list in under 200ms.

Skills Pro: the part for authors

Browsing is free and stays free. The paid tier is for people who write skills and want to treat that as a real activity instead of a hobby.

Skills Pro gives authors an actual dashboard. You see install counts per skill, per version, per day. You see which trigger phrases are firing in the wild and which ones nobody uses. You see the geographic split if you care about it. You see version adoption curves so you know when it is safe to deprecate v1.

There is a verified-author badge. The verification flow is light: confirm a GitHub identity, point at a repo, sign one commit. The badge is not a quality signal, it is an identity signal. It tells installers that the skill they are about to drop into their global config came from the person they think it came from.

Pro authors get version pinning that actually works. Push a new version, mark it stable, and existing installers get an update prompt instead of a silent overwrite. Roll back from the dashboard if the new version breaks. We learned this one the hard way shipping our own skills.

There is a private skills tier for teams who want to share internal skills across a team without making them public. Same install flow, same version model, just gated to a workspace. This is the part that pays for the rest.

Submitting a skill

The submission flow is the thing we spent the most design time on, because the failure mode for marketplaces is always "the submission queue is a graveyard and nothing ships."

Submit a skill at /submit. Paste a GitHub URL. The form pulls metadata, runs a static lint pass on the SKILL.md frontmatter, and shows you a preview of how the directory page will render before you commit to publishing. If the lint fails, it tells you exactly which field is wrong and links to the spec.

After preview, the skill enters a review queue. Review is currently human, currently us, currently fast. Median review time at launch is under 24 hours. We are not gatekeeping on quality, we are gatekeeping on "does this skill do what its description says." The bar is low and clear.

Once approved, the skill is live and the author gets an authorship record they can claim with a verified-author flow later. If you submitted skills before the verified-author flow existed, you can retroactively claim them by signing a commit on the source repo.

If you have written a tutorial showing how to build a skill, point at it from the submission. We highlight skills that come with real tutorials. Two examples worth reading: the Hookyard tutorial on shipping hook-based skills and the SkillForge build log from earlier this month. Both walk through a real skill from idea to publish.

Roadmap

The launch directory is the floor, not the ceiling.

Community curation. Right now review is centralized. The plan is to move to a trust-graded curator model where established authors can approve submissions in their category. The infrastructure for that is half-built, the policy questions are still open. Expect this in the next 60 days.

Paid skill marketplace. Some skills are worth paying for. A skill that wraps a non-trivial pipeline, ships with hosted infrastructure, or includes a dataset belongs behind a price tag. We are building a Stripe-backed transactions layer with revenue split for authors. Free skills stay free, paid skills are opt-in only, and the directory will always show free alternatives next to paid ones so the comparison is honest.

Skill bundles. Most people do not install one skill, they install a stack. Bundles let an author or curator group skills into a starter pack, version it, and let installers pull the whole thing. Useful for onboarding, useful for opinionated workflows, useful for the agentfs filesystem-as-skills pattern we wrote up last week.

Cross-tool indexing. Skills are a Claude Code concept today, but the same metadata model fits Codex prompts, Cursor rules, and Augment commands. The directory will eventually index across all of them with a clear filter, so you can see the full landscape and not just the Claude slice. If you want a head-to-head view of the underlying tools, the comparison page covers that.

Telemetry the user controls. Install counts are opt-in. We are adding finer-grained controls so authors can request specific telemetry and installers can grant or deny it per skill. The default will always be off.

Honest constraints

A few things the launch directory does not do, in case you came in expecting them.

It does not run skills in a sandbox. The directory hosts metadata, not execution. When you install a skill, it lands in your local Claude config and runs with whatever permissions you give it. Read the SKILL.md before you install. The verified-author badge is not a substitute for that.

It does not currently dedupe forks. If somebody forks a popular skill and republishes it under a different slug, you will see both. We have a clustering plan but it is not in the launch build.

It does not solve the "skill conflicts with another skill" problem. Two skills can claim the same trigger phrase, and Claude Code picks one with rules that are not always obvious. The directory shows trigger phrases on every page so you can spot a conflict before installing, but the resolution is on you.

It does not have a real moderation policy yet. We have an acceptable-use list and we will reject skills that exfiltrate data, ship malware, or scrape protected APIs. The full policy will land before we open community curation, because community curation without a clear policy is how you end up with a marketplace nobody trusts.

It is a directory. The hard parts of the skill ecosystem (versioning at scale, signed manifests, deterministic installs, conflict resolution) are still hard. We are not pretending to have solved them. We are pretending to have indexed the ones that exist so you can find them faster.

Try it

The directory is live. Browse 312 skills, filter by category, install with one command. If you write skills, the Pro tier is open for early access. If you have a skill we missed, submit it and we will review within a day.

The whole point of skills is that the boring parts of the work get cheaper every week. A directory of 312 of them, with version pinning and an honest submission flow, is the smallest thing we could ship that makes that compounding go faster.

That is the bet.