# claude-code-plugins-plus-skills: a marketplace that separates plugins from skills

> An MIT-licensed marketplace of 442 catalog plugins and 3,067 skills for Claude Code, installed either through the built-in /plugin command or the ccpi CLI. The interesting part is the labeling discipline, not the raw counts.

**jeremylongshore/claude-code-plugins-plus-skills** — Project brief: 471 plugins, 3,069 skills, 347 agents for Claude Code. Open-source marketplace at tonsofskills.com with the ccpi CLI package manager.

- Repository: https://github.com/jeremylongshore/claude-code-plugins-plus-skills
- Website: https://tonsofskills.com
- Stars: 2,797 · Forks: 409
- Language: Python
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/jeremylongshore-claude-code-plugins-plus-skills

## What the marketplace is actually for

The README describes the project as "a model-agnostic agent-skills platform" whose canonical layer is harness-free by construction, with Claude Code as the currently verified-native harness. Everything else is framed as an engineering candidate until native-path integration is verified. That sentence does most of the positioning work: this is not a Claude Code feature, it is a corpus of skills and plugin definitions that Claude Code happens to consume natively today.

The audience follows from that. If you write Claude Code skills by hand, or you want a devops pack, a Klaviyo pack or an Intercom pack without authoring it yourself, this is a place to pull from. The repository layout backs the claim: plugins/, skills/, marketplace/, packages/, schemas/ and scripts/ sit side by side at the top level, so the catalog, the source corpus and the tooling that generates the catalog all live in one monorepo.

## Why the README publishes a counting method

The scale table is the most opinionated thing in the README. Each number names its cohort and the command that reproduces it, with the stated rationale that "an unlabeled count is how a corpus ends up with five contradictory answers to 'how many skills.'" Four counts are given: 442 catalog plugins, 3,067 marketplace-visible skills, 347 agent definitions, and 19 plugin categories.

The reproduction commands are plain shell and Node, not a bespoke tool:

```bash
node scripts/generate-readme-toc.mjs
node -e "import('./scripts/corpus-resolver.mjs').then(m=>console.log(m.resolveCorpus('marketplace-visible').length))"
git ls-files 'plugins/**' | grep '/agents/.*\.md'
ls -d plugins/*/
```

Two things are worth noting. First, the plugin count in the table is 442, while the repository description says 471 plugins and 3,069 skills. Those are different cohorts, and the README's own table is the narrower one. Second, the counts are generated, not typed: the blocks are wrapped in HTML comments that say not to edit them and to run a script instead. That is a real maintenance decision, and it means the numbers in the README can be stale relative to the catalog until the generator runs.

## Installing the marketplace inside Claude Code

The README gives one command for the whole marketplace, run inside Claude Code:

```bash
/plugin marketplace add jeremylongshore/claude-code-plugins
```

After that the marketplace is registered and you browse or install from it. Note the slug: the README carries an explicit comment calling it a frozen compatibility contract, hardcoded in the CLI, the website snippet and hundreds of downstream READMEs, with GitHub's redirect to the canonical repository name described as load-bearing. The comment states that no redesign may normalize it. If you see the slug differ from the repository name, that is intentional, not a typo to fix.

For a single pack without the interactive flow, the README shows the CLI path:

```bash
pnpm add -g @intentsolutionsio/ccpi
ccpi install devops-automation-pack
```

The package manager is pnpm, and package.json pins pnpm@9.15.9 with a lockfile hash, so the CLI is installed globally with pnpm rather than npm. The README does not document an uninstall command, a rollback path, or what ccpi does when a pack name does not exist. Verify those against the CLI's own help output before you put it in a script.

## What the release numbers do and do not tell you

The README is unusually explicit that version surfaces are decoupled. It states that the release badge is the marketplace's display version while npm packages, including the ccpi CLI and publishable plugins, keep their own package versions, and that they are "intentionally not expected to equal" the display version. A checker script governs the display surfaces without rewriting package semver.

So the VERSION file at the repository root and the version field in package.json, which reads 4.33.0, are not the version of any pack you install. Recent releases follow per-package semver instead: @intentsolutionsio/intent-labs-pack@0.1.0, @intentsolutionsio/klaviyo-pack@1.0.4 and @intentsolutionsio/intercom-pack@1.0.3. A pack at 0.1.0 and a pack at 1.0.4 are both current. If your upgrade policy keys off a single project version, this repository will not give you one.

The README also publishes npm download figures updated by a daily GitHub Action, broken out by 24-hour, 7-day and 30-day windows across 396 published packages, with an "established" column that excludes packages first published within the last 30 days. Treat that table as a description of the publish cadence, not as a measure of whether a given pack is any good. The repository's own top-level files include a CHANGELOG.md and RELEASING.md, which is where per-package change history actually lives.

## Plugins versus skills, and where the boundary breaks

The naming in the repository is the useful part for a newcomer. A plugin is the installable unit: it has a directory under plugins/, it can carry agent definitions, and it can be published to npm under the @intentsolutionsio scope. A skill is the smaller authored artifact, and the README counts marketplace-visible skills separately from catalog plugins, which is why the two numbers differ by an order of magnitude. Agents are counted a third way, by globbing for markdown files under an agents/ directory inside plugins.

That three-way split is a design choice with a cost. A skill can be visible in the marketplace without belonging to any plugin, so "what do I install to get this skill" is not always answerable from the skill's own page. The README provides a corpus resolver script that answers the counting question, not the packaging question. Expect to read the plugin directory listing when you want to know what a single install brings with it.

The other boundary is harder. The README says the canonical layer is harness-free by construction and that Claude Code is "currently the verified-native harness," with other harnesses remaining engineering candidates until their native-path integration is verified, and source research alone never presented as public support. Read that as a statement about verification, not about architecture: the files may well be portable, but the project will not claim a harness works until someone has checked the native path. If you run a different agent harness, you are on your own.

## The maintenance picture and what an upgrade costs

The repository is not archived, and the last push was on 2026-07-23. There are release entries from 2026-07-18 and 2026-07-23, so the publish cadence was live through late July. The README's npm table is described as updated daily by a GitHub Action, which implies automation that keeps running independently of hand edits.

The upgrade cost is mostly the version decoupling described above. Because each npm package carries its own semver, upgrading a pack is a per-package decision, and the marketplace display version gives you no signal about it. The monorepo also carries a heavy tooling surface: husky hooks, lint-staged, commitlint, markdownlint, prettier, eslint, ruff, gitleaks and a set of validate: scripts in package.json. That matters if you plan to fork or contribute, because a pull request is expected to pass generated-artifact checks, not just tests.

On licensing, the repository is MIT. That covers the code and definitions in the repository. It does not automatically cover the third-party skills the marketplace points at: the README's own spotlight entry for no-ai-slop describes that project as MIT-licensed and separately maintained by Peter Yang, and the previous-picks list links to other repositories entirely. Check each upstream project's licence before you ship its content. This is not legal advice.

## When to reach for something else

If you want a single skill rather than a catalog, the marketplace is the wrong shape. The README's own spotlight section points at standalone repositories, and installing one of those directly gives you the skill and its licence without the plugin layer, the pack naming and the CLI. The marketplace's value is discovery and packaging across many packs, and that value is zero when you already know which one file you want.

If your harness is not Claude Code, the README's own verification language is your answer. It declines to present other harnesses as supported until native-path integration is verified, so a project that needs the same skills under a different agent runtime should treat this repository as a source of definitions to port, not as a drop-in dependency.

And if you need a stable, single-version dependency to pin in CI, the decoupled versioning works against you. The ccpi CLI is a global pnpm install, packs version independently, and the display version is explicitly not expected to match them. A team that needs one number to pin should pin the individual @intentsolutionsio packages and ignore the marketplace version entirely.

## Conclusion

Adopt it if you already run Claude Code and want a catalog you can install per pack rather than hand-writing skills. Skip it if you need a harness other than Claude Code, since the README only calls Claude Code verified-native. Before installing anything, run the reproduced counts yourself and check the VERSION file, which the README says is deliberately out of step with package semver.

## FAQ

### What's the difference between plugins and skills in Claude Code?

In this repository the two are counted separately: the README lists 442 catalog plugins and 3,067 marketplace-visible skills. A plugin is the installable unit with its own directory under plugins/ and its own npm package, while skills are the smaller authored artifacts counted by the corpus resolver. Agents are a third cohort, counted by globbing markdown files under plugins/**/agents/.

### What are Claude skills in Claude Code?

The README treats skills as the canonical, harness-free layer of the platform, with Claude Code named as the currently verified-native harness. It counts 3,067 distinct marketplace-visible skills and provides a resolver script that reproduces that count. The README does not define the skill file format itself.

### Do you need coding skills for Claude Code?

The repository does not address this question. Its install path assumes you can run a slash command inside Claude Code or install a global CLI with pnpm, and its contribution path assumes familiarity with husky, commitlint and the validate scripts in package.json. The README states no required skill level.

### Does Claude have a plugin creation skill?

The README does not document a plugin-authoring skill. It does list skill-creator among the previous Killer Skill picks, which points at a separate repository rather than something bundled here. For authoring guidance inside this project, the repository carries a CLAUDE.md and a STANDARDS.md at the top level.

## Sources

- [Official documentation](https://tonsofskills.com)
- [Official README](https://github.com/jeremylongshore/claude-code-plugins-plus-skills#readme)
- [Project repository](https://github.com/jeremylongshore/claude-code-plugins-plus-skills)
- [Release notes](https://github.com/jeremylongshore/claude-code-plugins-plus-skills/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jeremylongshore-claude-code-plugins-plus-skills