audit-plugin

Audit Plugin Skill

Audit the content quality of a Claude Code plugin through multiple independent review rounds, fix only what the user approves, and loop until convergence. The target is the plugin path passed as the skill argument (<plugin-path>); if no argument was given — or the path does not exist, or it contains no .claude-plugin/plugin.json (not a plugin) — stop and ask the user before proceeding.

Core principles: every claim must carry a verbatim quote + file:line; finders maximize coverage, a validator filters false positives afterward; whoever fixes never signs off on their own fixes; the user approves the scope and every design decision.

Stage 0 — Scope

1. List 100% of the plugin's files (plugin.json, README, SKILL.md, references/, examples/, hooks/, commands/, agents/). Print the list so the user sees the audit scope.
2. Classify the plugin to decide whether Stage 6 applies:
   • Executable workflow (a skill that drives a pipeline, has hooks/scripts) → benchmark applies.
   • Content-only (output style, rules, pure reference) → skip Stage 6 and say why.
   • Agents/commands-only (ships agents or commands but no pipeline-driving skill) → treat as content-only for Stage 6, unless a command is itself an executable pipeline — then benchmark that command.
3. Check the plugin is reachable through EVERY loading mechanism the repo actually uses — .claude-plugin/marketplace.json, enabledPlugins in settings, sync configs (e.g. a load list consumed by a sync script), junctions/symlinks. Marketplace registration alone proves nothing if the repo loads skills another way; a gap in any one mechanism is a structural finding — record it now and carry it into the Stage 1 findings list (it enters the ledger with everything else). ALWAYS diff the installed-cache copy (~/.claude/plugins/cache/...) against the repo copy of the target plugin — even when the plugin is disabled; a stale cache is a single USER ACTION here instead of a recurring finding in every fresh round.
4. Tell the user the expected cost BEFORE Stage 1 begins: ~80–95k tokens per fresh-review round (up to 4 rounds), plus the benchmark figures in references/benchmark-guide.md §4 if Stage 6 may apply.
5. Apply pending self-updates — read THIS plugin's own improvement-proposals.md; if criteria-update proposals are marked PROPOSED, ask the user once whether to apply them to the canonical block before this audit begins, then mark each APPLIED or DECLINED (dated). This step is the trigger that closes the self-update loop — without it the loop only ever writes.