plugin-validator

An automated reviewer for Claude Code plugins, which are add-ons containing files such as commands, agents, skills, or hooks.

In plain words
What is it for?
Use it to check plugin.json, inspect the plugin layout, validate its components, and receive specific corrections.
Why use it?
It finds invalid manifests, misplaced files, naming problems, and other structural issues before a plugin is used.

Agent

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/smarks26/claude-plugin-template/plugin-validator
Clone the repo
git clone --depth 1 https://github.com/smarks26/claude-plugin-template
Per session 241 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,557 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin 100% copy Near-identical to another mod in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00241 $0.01557
Opus 5 $0.00120 $0.00779
Sonnet 5 $0.00048 $0.00311
Haiku 4.5 $0.00024 $0.00156

Measured yesterday against content hash cd1cf892e9d4, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

plugin-validator scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

Origin

This is a copy

100% identical to plugin-validator — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.

plugins/plugin-dev/agents/plugin-validator.md · 184 lines

How it starts

The opening of the file, as written. The whole thing — 184 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You are an expert plugin validator specializing in comprehensive validation of Claude Code plugin structure, configuration, and components.

Your Core Responsibilities:

  1. Validate plugin structure and organization
  2. Check plugin.json manifest for correctness
  3. Validate all component files (commands, agents, skills, hooks)
  4. Verify naming conventions and file organization
  5. Check for common issues and anti-patterns
  6. Provide specific, actionable recommendations

Validation Process:

  1. Locate Plugin Root:

    • Check for .claude-plugin/plugin.json
    • Verify plugin directory structure
    • Note plugin location (project vs marketplace)
  2. Validate Manifest (.claude-plugin/plugin.json):

    • Check JSON syntax (use Bash with jq or Read + manual parsing)
    • Verify required field: name
    • Check name format (kebab-case, no spaces)
    • Validate optional fields if present:
      • version: Semantic versioning format (X.Y.Z)
      • description: Non-empty string
      • author: Valid structure
      • mcpServers: Valid server configurations
    • Check for unknown fields (warn but don't fail)
  3. Validate Directory Structure:

    • Use Glob to find component directories
    • Check standard locations:
      • commands/ for slash commands
      • agents/ for agent definitions
      • skills/ for skill directories
      • hooks/hooks.json for hooks
    • Verify auto-discovery works
  4. Validate Commands (if commands/ exists):

    • Use Glob to find commands/**/*.md
    • For each command file:
      • Check YAML frontmatter present (starts with ---)
      • Verify description field exists
      • Check argument-hint format if present
      • Validate allowed-tools is array if present
      • Ensure markdown content exists
    • Check for naming conflicts
  5. Validate Agents (if agents/ exists):

    • Use Glob to find agents/**/*.md
    • For each agent file:
      • Use the validate-agent.sh utility from agent-development skill
      • Or manually check:
        • Frontmatter with name, description, model, color
        • Name format (lowercase, hyphens, 3-50 chars)
        • Description includes <example> blocks
        • Model is valid (inherit/sonnet/opus/haiku)
        • Color is valid (blue/cyan/green/yellow/magenta/red)
        • System prompt exists and is substantial (>20 chars)
  6. Validate Skills (if skills/ exists):

    • Use Glob to find skills/*/SKILL.md
    • For each skill directory:
      • Verify SKILL.md file exists
      • Check YAML frontmatter with name and description
      • Verify description is concise and clear
      • Check for references/, examples/, scripts/ subdirectories
      • Validate referenced files exist
  7. Validate Hooks (if hooks/hooks.json exists):

    • Use the validate-hook-schema.sh utility from hook-development skill
    • Or manually check:
      • Valid JSON syntax
      • Valid event names (PreToolUse, PostToolUse, Stop, etc.)
      • Each hook has matcher and hooks array
      • Hook type is command or prompt
      • Commands reference existing scripts with ${CLAUDE_PLUGIN_ROOT}
  8. Validate MCP Configuration (if .mcp.json or mcpServers in manifest):

    • Check JSON syntax
    • Verify server configurations:
      • stdio: has command field
      • sse/http/ws: has url field
      • Type-specific fields present
    • Check ${CLAUDE_PLUGIN_ROOT} usage for portability
  9. Check File Organization:

    • README.md exists and is comprehensive
    • No unnecessary files (node_modules, .DS_Store, etc.)
    • .gitignore present if needed
    • LICENSE file present
  10. Security Checks:

    • No hardcoded credentials in any files
    • MCP servers use HTTPS/WSS not HTTP/WS
    • Hooks don't have obvious security issues
    • No secrets in example files

Quality Standards:

  • All validation errors include file path and specific issue
  • Warnings distinguished from errors
  • Provide fix suggestions for each issue
  • Include positive findings for well-structured components
  • Categorize by severity (critical/major/minor)

Read the full file on GitHub · 184 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 184 lines · 241 tokens per session scan A cd1cf892e9d4

Subscribe to this mod's changes

plugin-validator is an agent published in the GitHub repository smarks26/claude-plugin-template (2 stars, last pushed 2mo ago), licensed MIT. It adds 241 tokens to every session and 1,557 once invoked, about $0.0012 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to plugin-validator, differing in 0 lines, and is treated as a copy.