Listing Criteria
What we test, what fails,
and why breadth is not the goal.
Every listing in this directory has been tested against the same checklist, 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.
The install check
We clone the repo, add it as a plugin 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. If the plugin later ships a breaking change, the audit date tells you exactly which version we tested.
For plugins that require Node or Python, we verify the declared runtime is available in a standard environment. Plugins that silently degrade without stating so are flagged.
The risk scan
We read every hook script that fires at runtime (SessionStart, SubagentStart, UserPromptSubmit, PostToolUse, Stop). We look for outbound network calls, filesystem writes outside the plugin's own directory, and any exec or eval patterns that could run attacker-controlled code.
"Clean" means none of the above. "Flagged" means something is present but disclosed — documented in the README, gated on an env var the user sets, or limited to a specific opt-in command. Flagged is not excluded; it is disclosed. Silent telemetry or undisclosed network calls that we cannot attribute to disclosed behavior result in exclusion.
Prose-to-code ratio
We count lines in .md/.txt files (prose) and lines in .ts/.js/.py/.sh files (code). This number is not a quality gate — it is a signal. High ratios often indicate prompt-heavy plugins with little backing behavior; low ratios often indicate code-backed plugins that do real work in the runtime. We publish the number and let the verdict explain it.
Benchmark claims
We read the README for quantitative claims. If a plugin claims a specific improvement — tokens saved, lines reduced, tasks completed — we check whether the baseline and methodology are stated. We note retractions prominently. A retraction that is honest and well-documented is a positive signal, not a negative one.
Our research background influences what we look for: ensemble signals, technical audit pipelines, cluster verification. We apply those methods to the plugins themselves.
Tiers
Tiers are derived from the audit fields, not hand-waved. We do not award Excellent to a plugin with a failed install check or an undisclosed network call.
Excellent ◆
Clean install, clean or flagged-and-disclosed risk scan, code-backed behavior, honest benchmark claims, actively maintained.
Strong ●
Clean install, disclosed risk signals if any, useful backing behavior, reliable maintenance signal.
Promising ▲
Installs, passes the risk scan, shows a clear use case — but early, limited scope, or lighter documentation.
Tiers coexist with shape + label in every display. The greyscale gate: desaturate any page and tiers must still be distinguishable by shape.
What fails outright
These are automatic exclusions — no tier, no listing:
Why breadth is not the goal
The large Claude plugin directories index tens of thousands of repos. The claim is 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 three entries and three 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 that you believe should be listed, we will audit it on the same criteria and publish the results either way.
bear@bearbrown.co — submit for audit