Why “stars” are not an audit
Marketplace popularity and GitHub stars measure distribution, not blast radius. A skill can look helpful and still load unbounded tools, start local MCP processes, or burn a large standing context on every selection.
Treat a new Claude Code plugin like a dependency: stage it, read the published files, score the risk, then pin a version.
Five surfaces to read before install
1. Skill applicability — Does each SKILL.md say when it applies, or is selection guesswork?
2. Standing context — What does the body force Claude to read before work starts?
3. Tools and hosts — Which tools are granted, and which outbound hosts appear in published config?
4. Hooks — What events fire on the installer’s machine, and is that documented for humans?
5. Secrets — Are tokens or keys embedded in repo files that ship with the plugin?
A 20-minute gate for teams
Require a named reviewer for any plugin that adds hooks or MCP. Run the plugin’s documented hello-world on a throwaway repo. Capture permissions prompted. Reject anything that needs home-directory write “for convenience” without a file-scope story.
If the author cannot point to a changelog and a clear uninstall path, do not put it on a shared engineer laptop.
Where a scheduled scorecard helps
A one-time skim goes stale when the plugin updates. AuditHQ scores the published Claude plugin surface — routing, context cost, permissions — and can re-run on a schedule so peer plugins and your own listing do not drift unnoticed.
Pair the scorecard with your internal allow-list. The audit names what changed; policy decides what stays installed.