A catalog of 93 plugins turns discovery into an audit job
wshobson/agents packages reusable coding-agent instructions into installable plugins. The README lists 93 plugins, 202 agents, 181 skills, 105 commands, and 16 orchestrators. Coverage includes programming languages, architecture, infrastructure, security, data, machine learning, documentation, business, and SEO. A user selects a focused plugin and lets the coding client discover its parts from the expected directory structure, instead of dropping the entire collection into one context window.
That breadth is both the attraction and the warning. A developer can find a Python or incident-response workflow quickly. A security team must decide which of 93 packages is approved, what commands each introduces, which tools an agent may call, and whether external content is pinned. GitHub showed 5 open issues and pull requests combined after an August 26, 2026 push, but returned no latest release. Commit review matters because there is no release tag to anchor an internal rollout.
Claude Code is native, while five clients receive adapted files
Claude Code uses the source marketplace directly through /plugin marketplace add and /plugin install. Codex and Cursor read committed registries that point back to source plugins. OpenCode and Antigravity generate transformed trees after cloning. GitHub Copilot receives Markdown agent profiles, skills, and commands converted into skills. The source stays in plugins/, while each adapter tries to speak its client's native format.
The README names 6 clients, despite one line calling them five harnesses. Their output differs in consequential ways: Codex enforces an 8 KB skill cap, OpenCode derives a permission block from tool allowlists, and Antigravity maps model tiers to its own aliases. A plugin verified in Claude Code is therefore not verified in Codex or Copilot. Test the installed result in every client your team supports, especially where commands and permissions are translated.
Tool-enabled commands make Markdown part of the trust boundary
These files are instructions and manifests, yet they influence an agent that may have shell, browser, repository, or cloud tools. Open issue #688 gives a concrete example: some command templates place raw $ARGUMENTS inside a tool-enabled prompt. If that text came from an untrusted source, it could carry instructions for the agent to act on. The issue proposes documentation and automated checks, but it remained open when fetched.
Issue #643 records another maintenance risk. Same-named agent definitions appeared in multiple plugins with different content, so a fix in one copy could miss another. Its original catalog counts have since changed, but the report's duplication examples and requested consistency check remain relevant. With 1,155 files in our measured checkout, this is exactly the sort of drift that needs a canonical source or a CI rule, not a reviewer remembering every copy.
External marketplace entries add more trust decisions. The README describes Pensyve as a git-subdirectory integration and HOL Guard as a pinned payload. It names 1 commit and 2 pinned CLI packages for HOL Guard, and says that runtime may change supported client settings when protection is requested. Before installation, inspect the source, manifest, commands, permissions, external URLs, and generated form. Pin the revision used by the team and trial it without production credentials.
What happened when we ran it
Our sandbox cloned commit 367cb6a into a 7.8 MB checkout with 1,155 files and about 16,900 source lines. The measured Python project was plugins/plugin-eval/, not the whole marketplace running inside 6 coding-agent clients. Installation took 33 seconds, pulled 42 packages, and occupied 47 MB. Its build succeeded in 6 seconds. The repository exposed 5 CI workflow files, a tests directory, and no Dockerfile.
Pytest completed in 12 seconds with 111 passed, 0 failed, and 2 skipped out of the reported 111-test total. Pip-audit found 0 known vulnerabilities. That is a clean result for the pinned evaluator on Python 3.12 Bookworm. It does not certify the safety, factual quality, model behavior, or cross-client output of every plugin. Each installed unit still needs content and permission review.
PluginEval has 3 layers. Its static checks are deterministic and local. The LLM judge assesses semantic quality across 4 dimensions, while Monte Carlo mode runs 50 to 100 simulations. Those counts describe documented modes, not work our lab performed. We ran the project's build, tests, and package audit. A paid certification across the full catalog would be a separate exercise with its own model cost.
Structural scores cannot prove a safe production edit
Static checks can catch malformed manifests, missing fields, dead links, drift, and client size limits. Semantic judging may find vague instructions that syntax cannot. Repeated simulation can estimate whether an agent follows a task consistently. None of these proves that a plugin will make correct changes in an unfamiliar production repository, because results also depend on the model, context, client, permissions, and target code.
The model-tier table also encodes cost choices. Some profiles inherit the user's model, while architecture or security work may select more expensive classes. Review those defaults before rollout. This matters more when an evaluation can request 50 to 100 simulations. A useful workflow should earn that spend on a known task instead of consuming it because the catalog assigned a tier.
One-plugin trials are safer than marketplace-wide installation
Anthropic Skills is a smaller reference set. Superpowers suits teams wanting one opinionated software workflow. VoltAgent's collection focuses on subagent roles rather than a portable marketplace. wshobson/agents has the widest client coverage of these choices and puts serious work into adapters and validation.
Start with one job the team already understands, install only its plugin, and compare the edits with an unassisted baseline. Record the commit and inspect changes when updating. Keep consequential commands behind confirmation. Our 111 passing tests make PluginEval worth using, while issues #688 and #643 explain why its checks should be one layer in review rather than the final word.