This skill should be used when the user asks to "create a plugin", "scaffold a plugin", "understand plugin structure", "organize plugin components", "set up plugin.json", "use ${CLAUDE_PLUGIN_ROOT}", "add commands/agents/skills/hooks", "configure auto-discovery", or needs guidance on plugin directory layout, manifest configuration, component organization, file naming conventions, or Claude Code plugin architecture best practices.
72
57%
Does it follow best practices?
Impact
100%
1.96xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/plugin-dev/skills/plugin-structure/SKILL.mdQuality
Discovery
72%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description excels at trigger term coverage and distinctiveness, providing an extensive list of natural phrases that would help Claude select this skill accurately. However, it is structurally imbalanced — it reads almost entirely as a 'Use when...' clause without first establishing what the skill actually does (e.g., 'Guides creation and scaffolding of Claude Code plugins, including manifest configuration, directory layout, and component organization'). Adding a clear capability statement would significantly improve it.
Suggestions
Add a leading capability statement before the trigger phrases, e.g., 'Scaffolds Claude Code plugins, generates plugin.json manifests, organizes plugin components (commands, agents, skills, hooks), and provides guidance on directory layout and architecture best practices.'
Restructure to separate 'what it does' from 'when to use it' — start with concrete actions the skill performs, then follow with 'Use when...' trigger guidance.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (Claude Code plugins) and references several actions like 'create a plugin', 'scaffold a plugin', 'set up plugin.json', 'add commands/agents/skills/hooks', but these are embedded within trigger phrases rather than stated as concrete capabilities the skill performs. It lacks a clear 'what this does' statement listing specific actions. | 2 / 3 |
Completeness | The description has a strong 'when' clause with explicit trigger phrases, but the 'what does this do' part is essentially missing — it never clearly states what the skill actually does or produces. It's almost entirely trigger-focused without describing the skill's capabilities or outputs. | 2 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms users would say: 'create a plugin', 'scaffold a plugin', 'plugin structure', 'plugin.json', '${CLAUDE_PLUGIN_ROOT}', 'auto-discovery', 'commands/agents/skills/hooks', 'plugin directory layout', 'manifest configuration'. These are highly specific and natural phrases a user would use. | 3 / 3 |
Distinctiveness Conflict Risk | The description is highly specific to Claude Code plugin architecture, with distinct terms like 'plugin.json', '${CLAUDE_PLUGIN_ROOT}', 'auto-discovery', and 'Claude Code plugin architecture'. This creates a very clear niche that is unlikely to conflict with other skills. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is highly actionable with excellent concrete examples for every component type, but suffers significantly from verbosity and poor progressive disclosure. It reads as a complete reference manual crammed into a single file rather than a concise skill overview with links to detailed references. Much of the content (naming conventions, best practices, maintenance tips, basic concept explanations) is either common knowledge for Claude or should be in separate reference files.
Suggestions
Reduce content by ~60%: Remove explanations of basic concepts (kebab-case, semver, what markdown frontmatter is), trim best practices to only plugin-specific guidance, and cut the naming conventions section which largely states obvious conventions.
Split into multiple files: Move component-specific details (commands, agents, skills, hooks, MCP servers) into separate reference files and link from a concise overview in SKILL.md.
Add an explicit plugin creation workflow with validation steps: e.g., '1. Create directory structure → 2. Write plugin.json → 3. Validate with [command] → 4. Add components → 5. Enable and test'.
Create the referenced 'references/' and 'examples/' directories with actual content, or remove the dangling reference at the end of the file.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~350+ lines. Extensively explains concepts Claude already knows (what kebab-case is, what semantic versioning is, what markdown frontmatter is, basic file organization principles). The best practices, naming conventions, and maintenance sections are largely common knowledge padding. Could be reduced to ~30-40% of current size without losing actionable information. | 1 / 3 |
Actionability | Provides concrete, copy-paste-ready directory structures, JSON configurations, and file format examples for every component type. The plugin.json examples, hooks configuration, MCP server configuration, and path reference examples are all executable and specific. | 3 / 3 |
Workflow Clarity | The auto-discovery mechanism section provides a clear sequence, and the troubleshooting section helps with error recovery. However, there's no explicit step-by-step workflow for creating a plugin from scratch (e.g., 'Step 1: Create directory, Step 2: Create manifest, Step 3: Validate...'), and no validation checkpoints are provided to verify the plugin is correctly structured before enabling. | 2 / 3 |
Progressive Disclosure | Monolithic wall of text with everything inline. References 'references/' and 'examples/' directories at the end but no bundle files exist. Content like the full metadata schema, all component types, naming conventions, best practices, and troubleshooting could easily be split into separate reference files. The skill tries to be a comprehensive reference document rather than an overview with pointers. | 1 / 3 |
Total | 7 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
76b35e9
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.