Why component count misleads
Install leaders often ship skills plus commands, agents, hooks, and sometimes MCP. A large inventory can be a real toolkit — or a folder of empty names and overlapping procedures.
Ask whether each skill states when it applies, what it reads before work, and what it leaves untouched. Empty triggers are selection blockers, not features.
Five scorecard rows
1. Job fit — Does the bundle solve a repeated job, or demo everything once?
2. Routing — Can an installer predict which skill fires without reading a novel?
3. Standing context — What tokens are paid on selection vs on rare paths?
4. Trust surface — Hooks and local MCP documented with events and commands?
5. Evidence — Outputs cite paths and diffs, or invent confident claims?
How to compare two toolkits fairly
Pick one real repo and the same three tasks. Prefer the plugin that finishes with less standing context and clearer permissions, even if it ships fewer skills.
Break one small thing (wrong file name, blocked host) and see which suite fails loudly. Silent wrong answers are worse than a refused job.
Where AuditHQ fits
AuditHQ reads the published plugin inventory — skills, context cost, tools, hosts, hooks — without executing the plugin. Use that scorecard beside your own evals when you choose or ship a multi-component bundle.