The Agent Skill Marketplace — What Skills 2.0 Actually Unlocked, How To Evaluate A Skill Before Installing, And When To Publish Your Own

Part of the Claude Code workflow series. Start with the install primer; then what to do after install; then this post once you've got the hang of writing your own skills and want to plug into the broader ecosystem.

The skills ecosystem in 2026 is what the npm ecosystem was around 2012 — real but early, full of legitimate community value, occasionally sketchy, and worth learning to navigate now because it's only going to get more important. Skills 2.0 (shipped early 2026) turned skills from "custom instruction fragments" into programmable agents with inputs, outputs, composition, and publishable packaging. That's the shift that made a marketplace possible.

Below: what actually changed with 2.0, where to find skills worth installing, how to evaluate one before you trust it with your repo, and the short version of how to publish your own.

What Skills 2.0 changed

Before 2.0 (Skills "1.x"): a skill was a named Markdown file with instructions the model would read and follow. Useful but limited — a skill couldn't take arguments, couldn't return structured output, couldn't reliably call other skills.

After 2.0: skills have defined:

• Inputs — typed arguments you pass when invoking (e.g., /skill audit-deploy url=https://example.com strict=true).
• Outputs — structured data other skills or code can consume (JSON, tables, files).
• Composition — skills can invoke other skills. A high-level /skill ship-feature can internally call /skill run-tests, /skill update-changelog, /skill deploy.
• Versioning — skill packages carry version strings; you can pin a skill to a known-good version.
• Permissions — a skill declares which tools it needs (Bash, Edit, Web, MCP servers). You approve at install time, not per-invocation.

That last one is the security-relevant upgrade. Before 2.0, a skill could quietly ask Claude to run any tool mid-execution and you'd only notice when the approval prompt fired. After 2.0, skill permissions are declared up front; if a skill declares only Read and tries to run Bash, the harness blocks it regardless of how the skill was written.

Where the skills actually live

Three places worth knowing:

1. claude-plugins-official — the Anthropic-curated set

The official collection, shipped directly by Anthropic. Covers the things you'd expect: /simplify, /batch, /debug, /claude-api, plus channel transports (imessage, telegram, discord). Low risk. Install freely.

2. skilz — the universal installer

Created by Rick Hightower, supports 30+ coding agents including Claude Code, Gemini CLI, Copilot, and Cursor. The pitch: one installer, one catalog, one install command across any agent CLI. Useful if you're running multi-model workflows and want the same skill to work regardless of which CLI you happen to be in at the moment.

Find it via Rick's writing and the skilz marketplace writeup that covers the ecosystem.

3. Community GitHub repos

The long tail. Searching GitHub for claude-code-skills or agent-skills surfaces dozens of community-curated collections. Quality varies wildly. A few that showed up as credible during research:

• VoltAgent / awesome-claude-code-subagents — categorized collection of subagent patterns + skills. Good starting point.
• RiyaParikh0112 / claude-code-playbook — the security-best-practices skill set.
• Various single-author packages around specific workflows (TypeScript migration, Django ops, front-end design).

The rule for community skills: treat them like npm packages from a new maintainer. Read the code before installing. Which is the next section.

How to evaluate a skill before installing

Four things I actually check, in order:

1. Permissions declared. Open the skill's manifest (usually skill.json or frontmatter in the markdown). Look at its permissions array. Does it need exactly what you'd expect, or is it asking for Bash and Web and Edit when the README says it only summarizes files? Over-broad permissions are the single biggest red flag.

2. The skill's actual instructions. Read the skill file, top to bottom. Two questions: does the prompt match the README's claims, and does it reference any external URLs or APIs you didn't expect? A "CSS linter" skill that also pings attacker.example.com on each run is exactly the shape of a supply-chain attack.

3. The maintainer's other work. Skill marketplaces are small; maintainer reputations are legible. A skill published by an anonymous GitHub account with one repo and three commits is higher-risk than one published by someone who maintains six other widely-used skills. Check their profile, commit history, and any linked identity (LinkedIn, website, published writing).

4. Version and changelog. A 1.0.0 skill with no version history has been stable for zero hours. A 3.2.1 skill with a real changelog has survived real usage. Prefer the latter. If the skill has no version string at all, that's 2.0-pre and the install process won't pin it — reconsider.

Pragmatic test: would you install this skill on a client repo? If not, don't install it on yours either.

What a real skill installation looks like

The common flow (syntax varies by installer, concept is constant):

/plugin install <skill-package>

The harness:

1. Fetches the package from the declared source.
2. Shows you the declared permissions and asks for approval.
3. Installs into ~/.claude/skills/ (or a project-scoped location).
4. Registers the skill with whatever invocation syntax the manifest declares (/skill <name>, /<custom-slash>, etc.).

Uninstall:

/plugin uninstall <skill-package>

Skills installed this way are pinned at install time. Updates don't happen automatically; you explicitly run /plugin update <name> when you want the latest version. This is the right default — silent updates of tooling-that-can-touch-your-files is an obvious supply-chain attack vector.

Publishing your own skill

If you've built something you use daily and others might want:

Step 1 — structure the skill properly. A publishable skill has:

• A skill.md (or skill.json) with manifest metadata: name, description, version, permissions, inputs, outputs, author.
• The actual instruction content — parameterized, self-contained, with invocation examples.
• A README that a user installing the skill will read before approving.
• Tests or at least worked examples.

Step 2 — declare permissions precisely. Don't ask for ["*"] if you only need ["Read", "Edit"]. Broad permissions scare careful users away.

Step 3 — pick a distribution channel.

• GitHub — easiest. Publish the skill repo publicly, reference it in the install instructions. Works today.
• skilz / plugins marketplace — higher visibility if accepted. Review process varies by marketplace.
• Internal to your team — if the skill is for your company's workflow, keep it in a private repo and install via the private URL.

Step 4 — version it. Semver. Every breaking change bumps major. Every new feature bumps minor. Bug fixes bump patch. Skip this and your skill stays at 0.1.0 forever and nobody trusts it.

Step 5 — advertise where it's useful. Post on relevant Reddit threads, Discord servers, LinkedIn. Tag the ecosystem maintainers if the skill is a generalizable pattern. A good skill with zero discoverability is still zero skills.

Skills worth installing right now (for most people)

A safe starter pack:

• The official /simplify, /batch, /debug, /claude-api — ship with Claude Code; no install needed.
• The official Channel plugins if you're setting up iMessage/Telegram/Discord dispatch.
• One or two workflow-specific skills from the awesome-claude-code-subagents catalog, chosen to match your actual repetitive tasks (front-end design, backend linting, infra).
• Your own first skill — the one you write by extracting the procedure you currently type manually twice a week.

Avoid, until you've developed taste:

• Skills that claim to do everything ("the ultimate developer workflow"). Narrow skills are better.
• Skills without version history or declared permissions.
• Skills from single-post accounts on any platform.

The shape of the ecosystem in six months

Best-guess projection, based on where other ecosystems (npm, brew, crates, CRAN) were at comparable maturity:

• More marketplaces, more fragmentation. Expect 3–5 competing registries before one consolidates.
• Paid skills. Some vendors will package their product integrations as installable skills and sell them. The business model works; some of them will be worth it.
• Malicious skills. Inevitable. Keep reading permissions and source before installing — same hygiene as npm packages.
• Standards for skill manifests. The current informal skill.json shape will get formalized, probably by a working group that includes Anthropic + community maintainers.
• Tighter IDE integration. Skills showing up inline in Cursor, Zed, VS Code extensions without needing to leave the editor.

None of this is speculative — all of it is how every developer ecosystem that's had five successful years has evolved. Skills 2.0 is at year one.

Related reading

• AI Terminal Kickstart — install prereq.
• CLI installed — now what? — where skills first appear in this series.
• Skills vs Rules vs Memory — when a task warrants a skill in the first place.
• Multi-model routing — skills often wrap model delegation; this is the companion piece.
• Adversarial subagents + worktrees — review roles are the most reusable skill pattern.

Fact-check notes and sources

• Anthropic: Equipping agents for the real world with Agent Skills — the canonical Skills 2.0 essay.
• Julian Goldie: Claude Skills — ecosystem survey including skilz.
• GitHub: VoltAgent / awesome-claude-code-subagents — community skill catalog.
• GitHub: RiyaParikh0112 / claude-code-playbook — security-focused skill set.
• MCP Market: Advanced Prompt Engineer — an example of a paid / promoted skill.
• Reddit: Claude Code creator: introducing /simplify and /batch — launch-era discussion.
• Paddo: From Ralph Wiggum to /loop: The Absorption Continues — context on how community skills become official bundled commands.

Informational, not engineering consulting advice. The skills ecosystem is early and moving quickly; specific package names, installation paths, and manifest formats will evolve. Always read skill source and declared permissions before installing, regardless of who the maintainer is. Mentions of Anthropic, Rick Hightower (skilz), VoltAgent, RiyaParikh0112, and all linked publications are nominative fair use. No affiliation is implied.