Anthropic's knowledge-work-plugins at 31,595 Stars: 123 Marketplace Entries, 11 in the README, and Only 2 of 17 Plugins Ship a Slash Command

The README of anthropics/knowledge-work-plugins opens with a promise and then makes four claims you can check against the files: “We’re open-sourcing 11 plugins”, “Each plugin bundles the skills, connectors, slash commands, and sub-agents for a specific job function”, “Every component is file-based — markdown and JSON, no code, no infrastructure, no build steps”, and “Plugins are just markdown files. Fork the repo, make your changes, and submit a PR.”

Every one of those sentences is contradicted by something inside the repository, and the contradictions are not subtle. The marketplace registry has 123 entries. There are 17 first-party plugins on disk, not 11. The repo ships 26 Python files, and GitHub’s own language bar for the repository reads Python 74.1%, HTML 25.9% — there is no markdown percentage, because GitHub does not count it. Slash commands exist in 5 files across 2 of 17 plugins. And the pull-request workflow closes external contributions automatically with a comment explaining that this repository only accepts contributions from Anthropic team members.

Everything below was measured on 23 October 2026 against a git clone --depth 1 of main (commit dated 2026-10-22), plus the GitHub REST API and live HTTP probes. No API keys were used, nothing was installed, and no model was called. All counts come from parsing the repository’s own files, so every number here is reproducible with git clone and a JSON parser. The one thing I executed was a Python script the repository ships — that test is in its own section and its output is quoted verbatim.

The registry is not the repository

The most misleading thing about this project is the gap between what the README describes and what .claude-plugin/marketplace.json actually is. The README documents a collection of plugin folders. The registry is a curated catalogue of 123 plugins across 93 external repositories owned by 90 different GitHub accounts, of which all but 22 are fetched from somewhere else.

That table is the honest core of the project, and it is better than the README makes it sound: 101 out of 101 external entries carry a full commit SHA, which is the correct way to run a catalogue that pulls code from 90 strangers. But the two facts side by side — 123 entries in the registry, 11 in the README table — tell you who the README is written for. The README is a landing page for knowledge workers. The registry is a supply-chain manifest for a marketplace that now lists more vendor plugins than first-party ones by a factor of 4.6.

The 22 local entries and the 101 external ones are not tagged the same way either. 87 of 123 entries have a category field and 36 do not — and all 22 first-party entries are in the 36. Every plugin added to the registry after position 48 has a category. The schema is enforced on vendors and skipped on themselves.

The ordering of the file is worth a glance too. Position 0 is noibu, a vendor plugin fetched from Noibu/ai-plugin; the eleven plugins the README documents begin at position 1. Whatever the sort order is meant to be, the first thing a user sees in Anthropic’s own marketplace file is somebody else’s product.

Someone else is doing the maintenance

knowledge-work-plugins is an open-source repository in the licence sense and not really in the contribution sense. The commit leaderboard explains it:

32 contributors total, and roughly three-quarters of the commits are a robot rewriting pinned SHAs. marketplace.json alone took more than 100 commits between 2026-09-18 and 2026-10-21 — about three registry edits a day. The workflow doing it is .github/workflows/bump-plugin-shas.yml, which runs on a schedule, and it is paired with revert-failed-bumps.yml, which reverts a bump when the security scan fails. There is also scan-plugins.yml, a 19 KB workflow that reviews every third-party entry with an Anthropic-hosted scanner using Workload Identity Federation.

That automation has a visible side effect. Six vendor repositories contribute more than one plugin, and four of them have their own plugins pinned to different commits simultaneously:

qodo-ai/qodo-skills and oracle/netsuite-suitecloud-sdk keep both of their plugins on one shared SHA, so the divergence is not a rule — it is what happens when each registry row is bumped independently. The practical consequence: installing two plugins from stackhawk/agent-skills gives you code from two different states of the same repository, and nothing in the registry says whether the difference was intentional.

Inside the in-repo plugins

Strip the registry away and look at what Anthropic actually ships in-tree. Seventeen plugin directories, plus five vendor plugins under partner-built/ — one of which, zoom-plugin at version 1.1.0, contains 30 skills by itself.

Three things jump out of that table. First, the README’s documented structure includes a commands/ directory, and 15 of 17 plugins do not have one. Repo-wide there are 15 command files: 4 in pdf-viewer, 1 in product-management, and 9 in the partner-built plugins. The README even advertises the pattern with examples — “slash commands are available in your session (e.g., /sales:call-prep, /data:write-query)” — but /sales:call-prep resolves to sales/skills/call-prep/SKILL.md, a skill, not a command. That works because Claude Code lets you invoke a skill as a command; it just means the commands/ layer in the documentation is vestigial, and the repository’s own users have noticed. Open issue #1283 is titled “finance: skills document slash commands the plugin doesn’t ship (/je, /sox, /flux)”.

Second, “sub-agents” appear exactly once: partner-built/brand-voice/agents/ with 5 files, 22,883 bytes. No first-party plugin ships an agent. And there are zero hooks/ directories and zero hooks.json files anywhere in the repository — which is worth remembering in the next section, because the repository’s own security policy is largely a document about hooks.

Third, the skill counts are wildly uneven in a way that tracks versions. small-business is at 1.35.1 with 44 skills and no per-plugin LICENSE; sales is at 2.1.0 with 36; everything else sits between 0.2.0 and 1.3.1. The six directory names missing from the README table — design, engineering, human-resources, operations, pdf-viewer, small-business — are also, with one exception, the directories with no per-plugin LICENSE file (design, engineering, human-resources, operations, small-business). The correlation between “added later” and “skipped the LICENSE copy” is close to perfect, and it is a cheap way to date a directory in any repo that follows this pattern.

What 181 skills cost before you type anything

Claude Code’s own documentation states the mechanism plainly: “for each skill, agent, and command that Claude can invoke on its own, the name and description are in Claude’s context on every turn so that Claude knows it exists. Those tokens count toward your usage and leave less room in the context window even in sessions where nothing from the plugin runs.”

So the frontmatter is not free. Summing the name and description of every skill in the repository:

Two plugins — sales and small-business — account for 80 of the 181 first-party skills, 44.2% of the surface. Enabling everything the repository ships puts roughly 23,500 tokens of tool descriptions in front of every prompt, forever: about 12% of a 200k window, or 2.4% of a million-token window, spent before the user says anything. The full bodies are much larger — 1.64 MB of SKILL.md, ≈ 409k tokens — but those load only when used.

This is not a knock on the repo; it is the price of the design, and Anthropic’s docs say the official marketplace shows a context-cost estimate in /plugin before you install. The finding is narrower and more useful: small-business is a 44-skill monolith whose description cost alone exceeds the entire data, legal and bio-research plugins combined, and it is one of the plugins with no per-plugin licence file. If a rollout plan says “install the small-business plugin for the ops team”, the plan is really saying “and 8,600 tokens on every turn for everyone it is enabled for”.

Here is the per-turn table for every plugin, sorted:

174 connector declarations, 30 with an empty URL

The 14 plugins that ship a .mcp.json declare 174 MCP server entries. Thirty of them are placeholders with "url": "".

That leaves 144 declarations pointing at a real endpoint — but only 80 distinct endpoints, because the same ones are copy-pasted across plugins:

An average of 2.2 declarations per distinct endpoint. Open issue #1031, filed 2026-08-31, is titled “Shared connectors (Gmail, Google Calendar, Slack) are redeclared per-plugin instead of shared” — a user spotted the duplication seven weeks earlier and it is still the structure of the repo, which is what makes the CONNECTORS.md category abstraction so odd in retrospect: skills are written to be connector-agnostic, and the connector list is then pasted into every plugin. The 13 Slack declarations all carry an oauth block, and all 13 carry the identical client ID 1601185624273.8899143856786 and the identical callbackPort: 3118. I could not establish from any source whether Claude Code multiplexes those into one connection or starts thirteen, and whether the shared callback port is honoured per plugin or per session — the docs do not say. What is documented is that “MCP servers the plugin defines run alongside each session where it’s enabled”. If that sentence is literal, installing six plugins with a Slack connector is a configuration question nobody has answered in public.

The empty-URL entries are explained in some CONNECTORS.md files: “Google Calendar, Gmail and Google Drive are listed in .mcp.json without a URL. Connect them in Claude’s connector settings.” That is a disclosure, but it is only in 6 of the 14 plugins that ship the stubs — customer-support, design, engineering, enterprise-search, marketing, productivity and finance ship the stub without the note. And snowflake/databricks/benchling are stubs with no explanation at all.

One thing deserves credit: no file in the repository contains an API key or token. All 174 declarations authenticate through OAuth at connect time. For a repo that vendors 90 third parties, zero committed secrets is a real result.

What the endpoints say when you knock

I sent an unauthenticated MCP initialize POST to 17 of the declared endpoints. Sixteen answered 401 — alive, gated, correct. One answered 404:

POST https://api.definite.app/v3/mcp/http
→ HTTP 404  {"detail":"Not Found"}

That URL is in data/.mcp.json, shipped in data version 1.1.0, and it is the connector the README’s own table advertises for the data plugin (“Snowflake, Databricks, BigQuery, Definite, Hex, Amplitude, Jira”). Open issue #1357 reports the same thing, filed five days before this measurement — “data plugin: Definite MCP endpoint returns 404 (api.definite.app/v3/mcp/http)”. The repo contains a check-mcp-urls.yml workflow, but it triggers on pull_request paths, so an endpoint that dies after merge stays dead in main.

The other connector worth flagging is not dead, just pointed somewhere temporary. engineering/.mcp.json declares Datadog at https://mcp.datadoghq.com/api/unstable/mcp-server/mcp. It returns 401, so it works today. Issue #1279 — “engineering: Datadog MCP URL uses the /unstable endpoint, which Datadog shuts off on Dec…” — points out that “works today” is the entire problem with pinning a production plugin to a path segment literally named unstable.

The script that prints “Successfully packaged” and writes 22 bytes

data/skills/data-context-extractor/scripts/package_data_skill.py packages a skill folder into a distributable ZIP. It validates the skill, then walks the folder and adds every file. Here is the line that matters, from the middle of the walk:

for file_path in skill_path.rglob('*'):
    if file_path.is_file():
        # Skip hidden files and common junk
        if any(part.startswith('.') for part in file_path.parts):
            continue

file_path.parts is the absolute path, split into components — not the path relative to the skill folder. So the filter does not skip hidden files inside the skill; it skips every file whose absolute path contains any dot-prefixed directory anywhere. And the documented install location for a Claude skill is ~/.claude/skills/<name>.

I ran it on a skill placed at .claude/skills/acme-analyst:

$ python3 package_data_skill.py .claude/skills/acme-analyst out2
Packaging skill: .claude/skills/acme-analyst
   Output directory: out2

Validating skill...
Validation passed


Successfully packaged skill to: /opt/data/cache/scratch/skilltest/out2/acme-analyst.zip
EXIT=0

The output file is 22 bytes and zipfile.ZipFile(...).namelist() returns [] — zero entries. Exit status 0. No warning. The same script on a skill at a path without a dot-segment (skm) produced a single-entry, 2,412-byte archive as expected, which isolates the cause to the path filter rather than to the skill’s contents.

This is the same defect reported in open issue #1298, “package_data_skill.py reports success with an empty ZIP under .claude” — filed 2026-10-10, still open, in the one script that exists to hand a finished skill to someone else. It is a two-character bug class (parts versus relative_to(skill_path).parts) with a silent-failure signature: the user gets “Successfully packaged” and a file they will email to a colleague, and the colleague gets nothing.

Anthropic’s own Software Directory Policy, which this repository enforces on third-party vendors, says: “Instructional Software tool or capability descriptions must precisely match actual functionality… Descriptions must not include unexpected functionality or promise undelivered features.” A packaging script announcing success while producing an empty artefact is the same category of mismatch, one layer down.

The README says fork it; the CI closes it

The README’s contribution section is two sentences: “Plugins are just markdown files. Fork the repo, make your changes, and submit a PR.”

.github/workflows/close-external-prs.yml runs on pull_request_target for every opened PR and closes it unless the author is a repo member, the automation bot, or the PR adds only marketplace.json entries whose source repo already backs a live plugin. The comment it posts:

“Thanks for your interest! This repo only accepts contributions from Anthropic team members. If you’d like to submit a plugin to the marketplace, please submit your plugin here.”

Open issue #1181 is titled “README invites external PRs that CI closes automatically.” The real contribution channel for outsiders is a directory-submission form, not a pull request, and the README does not mention it. This is not a scandal — a curated marketplace has to gate its catalogue — but it changes the correct mental model completely. You are not contributing to this repository. You are asking to be a listed entry, and if you are listed, your code is fetched from your own repo at a SHA Anthropic’s bot chooses.

The most valuable file in the repository is the one nobody links to. .github/policy/prompt.md is the review prompt that scan-plugins.yml feeds Claude to vet every third-party plugin. It is 8 KB of unusually specific instructions, and it discloses more about the ecosystem’s real failure modes than any of the docs:

• “The bar here is ‘handles user data responsibly,’ not merely ‘isn’t malicious.’ A plugin can be non-malicious and still fail this review if it observes more than its stated purpose justifies.”
• “Read the WHOLE shipped payload, not only the loaded surface. A plugin installed from a git source clones the ENTIRE repo to the user’s disk… Glob and grep broadly, including hidden directories — ’not a loaded surface’ is NOT a reason to skip a file.”
• On credentials: “The red flag is the cross-service hop: e.g. reading Anthropic’s ANTHROPIC_AUTH_TOKEN (an account/OAuth token) and sending it to a non-Anthropic endpoint — the vercel-style misuse.”
• The reviewer must set has_broad_scope_hooks, has_undisclosed_telemetry and description_matches_behavior, and telemetry fails “unless the plugin.json description or top-level README explicitly discloses the call AND documents an opt-out.”

That paragraph about cloning the entire repo is the single most useful sentence for anyone adopting this marketplace: enabling a plugin is not loading a markdown file, it is vendoring a repository onto a laptop. Which is also why the “no code” claim in the README matters beyond pedantry — the policy exists because the payload can contain anything, and the README is telling knowledge workers the payload is prose.

What is genuinely well built

An audit that only lists defects is lazy, and this repository does several things better than most projects of its size:

• 252 of 252 SKILL.md files have valid name and description frontmatter, and in all 181 first-party skills the skill name matches its directory name exactly. Zero descriptions exceed 1,024 characters. There is no drift between metadata and layout.
• 909 relative markdown links resolved, zero broken. Documentation hygiene at this scale is rare.
• 101 of 101 external entries pin a commit SHA, 93 of 93 vendor repos still exist, and 0 plugin names collide. The catalogue is well-formed.
• Zero committed secrets across 174 connector declarations, all OAuth.
• The CONNECTORS.md abstraction is a good idea. Skills refer to ~~CRM, ~~chat, ~~project tracker instead of naming HubSpot, Slack and Jira; 166 placeholder occurrences across 54 distinct categories, and 15 of 17 plugins only use placeholders their own CONNECTORS.md defines. It is what lets a company swap in its own stack without editing 44 skill files. The two exceptions are bio-research (uses genomics platform and tool database, neither defined in its CONNECTORS.md) and cowork-plugin-management (7 placeholders including the template forms ~~your-team-channel, and no CONNECTORS.md at all).
• The scan-then-revert loop — scheduled bump, LLM review, automatic revert of a failed bump — is a pattern most plugin registries do not have at all.

What a team should verify before enabling any of it

The documentation cannot answer these questions for you. All five checks are one-liners against a fresh clone.

1. Find the code. The README says there is none. Count it yourself and read the biggest file: find . -name '*.py' -o -name '*.sh' -o -name '*.mjs' | xargs wc -c | tail -1. Then look at bio-research/skills/*/SKILL.md for python3 invocations — 27 of them across 4 skills — and decide whether your laptops have the runtime and the packages.
2. Find the dead connectors. grep -c '"url": ""' */.mcp.json for the stubs, then probe the rest with an unauthenticated initialize POST and treat anything but 401 as a finding. The one 404 in this repo shipped for at least five days before anyone filed it.
3. Price the context before you enable it. wc -c */skills/*/SKILL.md is not the right measure; the per-turn cost is the sum of name + description in the frontmatter. For this repo that is 19,409 tokens for the first-party plugins and 8,603 for small-business alone. Compare against the context-cost estimate /plugin shows for official-marketplace plugins before installing, and use the Installed tab’s “Not used recently” group to turn things off.
4. Check the collisions. grep -h '^name:' */skills/*/SKILL.md | sort | uniq -d returns start, competitive-brief and lead-triage. Whether two plugins with a skill called start resolve predictably is not documented anywhere; issue #1306 shows the adjacent case (a plugin skill and a built-in skill firing on the same requests) is already a real user complaint.
5. Constrain the blast radius at the platform layer, not the trust layer. Managed settings can allowlist or block marketplaces, force-install plugins, and turn off session-only loading; project-scope installation writes the plugin into the repo’s .claude/settings.json so 500 people get the same thing. “A plugin you install can run code with your user privileges” is the docs’ own sentence. Treat a marketplace entry like a dependency, not like a document.

FAQ

Is knowledge-work-plugins the same thing as Claude Marketplace? No. Claude Code’s docs are explicit: a marketplace is “a repository or directory with a .claude-plugin/marketplace.json file that lists plugins and where to fetch each one. It’s a catalog, not a hosted store”, and “a plugin marketplace isn’t Claude Marketplace” — the latter is the website at claude.com/marketplace. This repo is a catalogue file plus 17 local plugins.

Why does the README say 11 plugins when there are 17 directories and 123 registry entries? Because the README was written when 11 shipped and was never updated. The 6 later additions (design, engineering, human-resources, operations, pdf-viewer, small-business) are absent from the table, and the registry has since grown to 101 third-party entries that the README does not mention at all.

Do the plugins really ship no code? bio-research ships 25 of the repo’s 26 Python files, including a 36,719-byte validate_asm.py and a 24,982-byte sra_geo_fetch.py, and its skills call python3 27 times across 4 skills; its README mentions pip four times and nextflow once. GitHub scores the repository at Python 74.1%, HTML 25.9%. The other 16 plugins are markdown and JSON.

Why are 30 connectors declared with an empty URL? Google Calendar, Gmail and Google Drive are placeholders — some CONNECTORS.md files say to “connect them in Claude’s connector settings”; snowflake, databricks and benchling are stubs with no explanation in the file that ships them. Whether the runtime ignores an empty URL or refuses to start is not documented.

Can I pin a version of a first-party plugin? Not in the usual sense. The repository has 0 releases and 0 tags. What you can pin is the registry’s SHA for third-party entries; for first-party plugins the only version marker is the version field in each plugin.json, which spans 0.2.0 (pdf-viewer) to 1.35.1 (small-business) with no changelog tying them together.

Is it safe to install a third-party entry? Safer than most marketplaces, with a specific caveat. Every entry is SHA-pinned, reviewed by an LLM scanner against a written policy, and re-scanned on every scheduled bump with automatic revert on failure. The caveat is the one the policy prints in capitals: a git-sourced plugin “clones the ENTIRE repo to the user’s disk”, so what you are trusting is not the skill files, it is everything in that repository.

The summary

anthropics/knowledge-work-plugins is a well-formed registry wrapped in a README that describes a different, smaller, simpler thing. The registry itself is the strongest part: 123 entries, 101 of them pinned to specific commits in 93 live vendor repositories, reviewed by a written policy that is genuinely good, maintained by a scheduled bot that accounts for about three-quarters of the commits. The in-repo surface is thinner than advertised — 17 plugins, 181 skills, 5 slash-command files in 2 plugins, zero hooks, one partner plugin with agents — and it is not codeless: 26 Python files sit behind bio-research’s six skills, which is 74.1% of the repository by GitHub’s own arithmetic.

The defects that matter are all of one kind: surfaces that report success while delivering something else. A registry whose README advertises 11 of 123. A commands/ layer documented as universal and present in 2 of 17. A data connector advertised in the README table that returns 404. A packaging script that prints “Validation passed” and “Successfully packaged” and writes a 22-byte ZIP with nothing in it. None of these break the concept; all of them are the reason to run five checks against a clone before you enable any of it for a team.

The number to remember is 19,409: the tokens of skill descriptions a first-party-only installation puts in front of every prompt, forever, before the user has typed anything.