Listing Criteria
What we test, what fails, and why breadth is not the goal.
Every listing is tested against the same checks, at a recorded commit sha, before it goes up. The criteria are public so you can reproduce any audit yourself — and so we have nowhere to hide when we're wrong. We record which checks ran, against which pinned commit, and what they found. We do not claim a plugin is safe — only that it cleared these checks as of that sha, on that date. Human review and curation stay separate gates.
How an audit runs
The auditor is a credential-free machine that clones each repo into a sandbox and works through the same sequence. Which checks fire depends on what the repo turns out to contain.
- Inventory. Detect every component by its file convention — skills, agents, commands, hooks, MCP servers, LSP servers, output styles, themes, monitors, workflows. A plugin is a bundle of these. Anything the detector can't classify is marked not-assessed, never waved through.
- Eligibility. The repo has to install from a published marketplace source or a documented path. Archived, deleted, or long-abandoned repos are excluded.
- Route & test. Each component runs the checks that fit its kind — prose components get an injection scan, code components get static and sandbox checks, config gets validity checks. External scanners run alongside, pinned and disclosed.
- Verdict with disclosed coverage. We record what ran, what it found, and what was not assessed. Then the record and a human-readable report are pushed to a public trace repository.
The checks
Install & eligibility
We clone the repo, add it as a marketplace source, and run the install. An entry that cannot be installed does not ship, regardless of how interesting the idea is. We record the HEAD sha at install time, so the audit date tells you exactly which version we tested. Declared Node/Python runtimes must be stated in the README.
Risk scan — static
We read every hook and script that fires at runtime (SessionStart, UserPromptSubmit, PostToolUse, Stop, and the rest) and look for outbound network calls, filesystem writes outside the plugin's own directory, and exec/eval patterns that could run attacker-controlled code.
Risk scan — behavioral
For code that is committed-only and dependency-free, we go further than reading it: we run it in a gVisor sandbox with the network disabled and watch what it actually does — egress attempts, files touched, processes spawned. When behavior can't be run safely (it needs install, network, or credentials), we say so and mark it deferred — never assumed clean.
Prose-to-code ratio
We count prose lines (.md/.txt) against code lines (.ts/.js/.py/.sh). This is a signal, not a gate: high ratios often mean prompt-heavy plugins with little backing behavior; low ratios often mean code-backed plugins doing real runtime work. We publish the number and let the verdict explain it.
Benchmark claims
We read the README for quantitative claims — tokens saved, lines reduced, tasks completed — and check whether the baseline and methodology are stated. An unbacked headline number is an exclusion. A retraction that is honest and well-documented is a positive signal, not a negative one.
The verdict is the coverage — not a grade
We do not award a quality tier. A tier is an opinion; coverage is a fact. The record says what was tested, at which sha, and what it found — and that is the verdict. Four outcomes, all disclosed:
What fails outright
Automatic exclusions — no listing:
Why breadth is not the goal
The large Claude plugin directories index tens of thousands of repos and call it discovery by volume. Our claim is different: we will list fewer things, and we will be correct about the ones we list. A curated directory with a few completed audits is more useful than an index of fifty thousand repos with no verification. We grow the list when we have time to audit properly — not to fill a grid. If you have a plugin you believe should be listed, we will audit it on the same criteria and publish the results either way.
The tests, and the tools behind them
A short account of each check — and the honest part: who actually ran it in the record you're reading. We name a tool here only when the trace shows it ran.
- Component detection — inventory what's in the repo so the right tests fire and nothing is silently missed; a miss degrades to not-assessed, never a silent pass. ours
- Eligibility & structure — is it a real, installable Claude plugin, well-formed and honest about what it declares. ours
- Prompt-injection scan — prose components are instructions to a model, and instructions can carry injection. ours
- Secrets scan — committed credentials and tokens, filtered for real hits over lockfile noise. ours
- Static exec / egress — subprocess, eval, and network patterns in code that could run or leak. ours
- Behavioral sandbox — run committed-only zero-dep code in gVisor with no network, and record what it does. ours
- Prose-to-code ratio — line counts of prose vs code, published as a signal (not a gate). Uses cloc.
bear@bearbrown.co — submit for audit
Bear Brown, LLC · every listing tested, every verdict shown · bearbrown.co