How we review Claude mods for inclusion
A listing needs a public repository, plugin manifest, hooks configuration, and a real registered JavaScript or TypeScript function module. Skills-only packages, MCP-only tools, shell hooks, empty templates, and official built-in examples do not count as third-party mods. The repository plus plugin path identifies an entry.
Descriptions and configuration notes are editorial explanations of those sources. Statements about a pinned version do not establish current upstream behavior. We distinguish a source-verified module, a successful validation inventory, source-matched install commands, and an actually installed session. This directory has not installed or run its listings.
Read permission states without assuming safety
The six capabilities are file reads, file writes, network access, environment reads, prompt changes, and tool interception. Yes means a capability was found with source evidence. Not declared means no matching capability appears in a successful modern validator inventory with complete hooks/calls lists. Not found requires complete static evidence at that SHA. Not verified means the evidence is incomplete; Outdated review means the source SHA differs.
On directory cards, + indicates found evidence, – indicates absence from the recorded inventory, ? means unverified, and ! means an outdated review. Each icon has an accessible capability name and exact state; open the detail page for the full six-row table and pinned evidence. The symbol does not grant or revoke a system permission.
Not listed by claude plugin validate is not a guarantee. A Yes means capability, not that every session uses it. Processes, MCP, custom APIs, downstream tool changes, sensitive settings, cross-session communication, and model costs require separate review. Validation does not create a sandbox.
Snapshots, repository metrics, and install evidence
Every listing retains its source SHA, snapshot date, plugin path, and links to manifest, hooks, and module files. Stars and commit dates belong to the captured repository, not an individual mod. A popular repository can contain unrelated packages. License evidence is separate from public availability and does not authorize reuse of screenshots.
The maintainer aims to review updates weekly when a complete new snapshot is available. Failed collection retains the previous snapshot; no browser-side API silently updates the facts. A changed SHA invalidates its earlier capability review. Missing marketplace or plugin names do not produce guessed commands. A known validation failure withholds installation until a repaired source SHA passes. Copying commands is not installation.
Previews and runtime limits
Illustrative preview labels mark terminal concepts based on source-described purpose. They are not running sessions, screenshots, benchmarks, compatibility tests, or proof of delivery. A schematic can be shared across a category; the listing’s configuration and evidence provide the entity-specific information.
Review registered modules and dependencies before enabling a plugin with your user permissions. Terminal features, service accounts, credentials, and charges may impose further requirements. We do not guarantee compatible execution, security, uninterrupted maintenance, billing accuracy, or outcomes.
Frequently asked questions
Does a successful validation mean a mod is safe?
No. It provides an inventory for a particular source SHA and CLI version. Indirect behavior and dependencies need separate review; validation is not a sandbox or security certification.
How should I compare entries without treating stars as a ranking?
Start with the task, inspect the module’s concrete behavior and prerequisites, then review its permission evidence and configuration. Stars describe a repository snapshot, not individual mod quality.