plugin-structure
Skill0 starsChanged 4 months agoMITView on GitHub
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.
- Reads credentials
14 other projects use a version of this, 13 of them edited.
Adopted by
Most recently taken up by
- AnyOrgName/php-skillstheir own version, first seen Nov 8, 2026
- shkodnik1917/claude-brainlabedited, first seen Nov 8, 2026
- Vepricov/claude-brainlabedited, first seen Nov 1, 2026
- davidanthonyn/claude-skillsedited, first seen Oct 20, 2026
- anthropics/claude-plugins-officialedited, first seen Oct 13, 2026
- nek1987/auto-agent-harnessedited, first seen Oct 11, 2026
Used with
Projects with it also use results-report, daily-coding and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
Galaxy-DawnSkillresults-report
This skill should be used when the user asks to "write an experiment report", "summarize experimental results", "do experiment retrospection", "write a results report", "写实验总结报告", "写实验复盘", or mentions turning completed experiment artifacts into a structured, decision-oriented research report. It assumes strict analysis should come from `results-analysis` first.
Also in 3 projects that use this
Clay-HHKSkilldaily-coding
Daily coding assistant that auto-triggers when writing/modifying code, providing a core checklist.
Also in 3 projects that use this
Clay-HHKSkillkaggle-learner
This skill should be used when the user asks to "learn from Kaggle", "study Kaggle solutions", "analyze Kaggle competitions", or mentions Kaggle competition URLs. Provides access to extracted knowledge from winning Kaggle solutions across NLP, CV, time series, tabular, and multimodal domains.
Also in 3 projects that use this
kharlamenkodevSkillbug-detective
Also in 3 projects that use this
indranilbanerjeeSkillreview-response
Draft a reply to one customer review, voice-scored, with escalation flags. \"reply to this 1-star review\"
Also in 3 projects that use this
Google CloudSkillcitation-verification
Verify that citations in a document resolve to real records and that claimed titles match. Use before trusting a document's reference list.
Also in 3 projects that use this
- +2 more from Clay-HHK
Other versions14 projects use a version of this.
Word for word · 0
None found.
Edited · 13
- anthropics/claude-plugins-official★ 46k99% same
- Galaxy-Dawn/claude-scholar★ 5.9k99% same
- shkodnik1917/claude-brainlab★ 3596% same
- Vepricov/claude-brainlab★ 3596% same
- jorgeasaurus/agent-skills★ 1499% same
- tstapler/dotfiles★ 898% same
- HK-hub/AgentSkills★ 699% same
- nek1987/auto-agent-harness★ 499% same
- kvivek0591/claude-code-skills★ 299% same
- Airmomo/skills★ 199% same
3 more not listed
Wrote their own version · 1
- AnyOrgName/php-skills★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository23 other files it gives its agents.
- AGENTS.mdAGENTS.md
- apple-mail-mcpb/CLAUDE.mdCLAUDE.md
- CLAUDE.mdCLAUDE.md
- .claude-plugin/CLAUDE.mdCLAUDE.md
- docs/CLAUDE.mdCLAUDE.md
- tasks/CLAUDE.mdCLAUDE.md
- tests/CLAUDE.mdCLAUDE.md
- tools/CLAUDE.mdCLAUDE.md
- apple-mail-archive-exportSkill
- context-guidance-auditSkill
- cowork-plugin-customizerSkill
- create-cowork-pluginSkill
- finalize-apple-mail-mcpSkill
- find-skillsSkill
- mail-scripting-dictionarySkill
- marketplace-release-handoffSkill
- mcp-builderSkill
- plugin-creatorSkill
- plugin-settingsSkill
- python-performance-optimizationSkill
- reviewing-codeSkill
- testing-pythonSkill
- thermo-nuclear-code-quality-reviewSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
43 rules. 29 are common, 0 are distinctive, and 14 are very specific to this project.
29
Common
Most of the 14 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
14
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Common: line 21
Every Claude Code plugin follows this organizational pattern:
- Very specific: line 41
Component locations: All component directories (commands, agents, skills, hooks) MUST be at plugin root level, NOT nested inside …
- Common: line 42
Optional components: Only create directories for components the plugin actually uses
- Common: line 43
Naming convention: Use kebab-case for all directory and file names
- Common: line 58
Use kebab-case format (lowercase with hyphens)
- Common: line 59
Must be unique across installed plugins
- Common: line 60
No spaces or special characters
- Common: line 82
Version format: Follow semantic versioning (MAJOR.MINOR.PATCH)
- Common: line 83
Keywords: Use for plugin discovery and categorization
- Common: line 102
Must be relative to plugin root
- Very specific: line 103
Must start with ./
- Very specific: line 259
Use ${CLAUDE_PLUGIN_ROOT} environment variable for all intra-plugin path references:
- Very specific: line 306
Commands: Use kebab-case .md files
- Very specific: line 311
Agents: Use kebab-case .md files describing role
- Common: line 316
Skills: Use kebab-case directory names
- Common: line 323
Scripts: Use descriptive kebab-case names with appropriate extensions
- Common: line 328
Documentation: Use kebab-case markdown files
- Common: line 333
Configuration: Use standard names
- Common: line 361
Put test-related commands, agents, and skills together
- Very specific: line 362
Create subdirectories in scripts/ for different purposes
- Very specific: line 364
Minimal manifest: Keep plugin.json lean
- Common: line 365
Only specify custom paths when necessary
- Common: line 367
Use inline configuration only for simple cases
- Common: line 376
Consistency: Use consistent naming across components
- Very specific: line 377
If command is test-runner, name related agent test-runner-agent
- Common: line 380
Clarity: Use descriptive names that indicate purpose
- Very specific: line 382
Avoid: utils/, misc.md, temp.sh
- Very specific: line 391
Always use ${CLAUDE_PLUGIN_ROOT}: Never hardcode paths
- Common: line 392
Test on multiple systems: Verify on macOS, Linux, Windows
- Common: line 394
Avoid system-specific features: Use portable bash/Python constructs
- Very specific: line 398
Version consistently: Update version in plugin.json for releases
- Common: line 401
Test thoroughly: Verify all components work after changes
- Common: line 450
Verify file is in correct directory with correct extension
- Common: line 451
Check YAML frontmatter syntax (commands, agents, skills)
- Very specific: line 452
Ensure skill has SKILL.md (not README.md or other name)
- Very specific: line 457
Verify paths are relative and start with ./ in manifest
- Common: line 458
Check that referenced files exist at specified paths
- Very specific: line 459
Test with echo $CLAUDE_PLUGIN_ROOT in hook scripts
- Common: line 463
Check file naming follows conventions (kebab-case, correct extensions)
- Common: line 464
Verify custom paths in manifest are correct
- Common: line 468
Use unique, descriptive component names
- Common: line 470
Document potential conflicts in plugin README
- Common: line 471
Consider command prefixes for related functionality
“Common” is measured: kept by at least 6 in 10 of the 14 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Plugin Structure for Claude Code
Overview
Claude Code plugins follow a standardized directory structure with automatic component discovery. Understanding this structure enables creating well-organized, maintainable plugins that integrate seamlessly with Claude Code.
Key concepts:
- Conventional directory layout for automatic discovery
- Manifest-driven configuration in
.claude-plugin/plugin.json - Component-based organization (commands, agents, skills, hooks)
- Portable path references using
${CLAUDE_PLUGIN_ROOT} - Explicit vs. auto-discovered component loading
Directory Structure
Every Claude Code plugin follows this organizational pattern:
plugin-name/
├── .claude-plugin/
│ └── plugin.json # Required: Plugin manifest
├── commands/ # Slash commands (.md files)
├── agents/ # Subagent definitions (.md files)
├── skills/ # Agent skills (subdirectories)
│ └── skill-name/
│ └── SKILL.md # Required for each skill
├── hooks/
│ └── hooks.json # Event handler configuration
├── .mcp.json # MCP server definitions
└── scripts/ # Helper scripts and utilitiesCritical rules:
- Manifest location: The
plugin.jsonmanifest MUST be in.claude-plugin/directory - Component locations: All component directories (commands, agents, skills, hooks) MUST be at plugin root level, NOT nested inside
.claude-plugin/ - Optional components: Only create directories for components the plugin actually uses
- Naming convention: Use kebab-case for all directory and file names
Plugin Manifest (plugin.json)
The manifest defines plugin metadata and configuration. Located at .claude-plugin/plugin.json:
Required Fields
{
"name": "plugin-name"
}Name requirements:
- Use kebab-case format (lowercase with hyphens)
- Must be unique across installed plugins
- No spaces or special characters
- Example:
code-review-assistant,test-runner,api-docs
Recommended Metadata
{
"name": "plugin-name",
"version": "1.0.0",
"description": "Brief explanation of plugin purpose",
"author": {
"name": "Author Name",
"email": "author@example.com",
"url": "https://example.com"
},
"homepage": "https://docs.example.com",
"repository": "https://github.com/user/plugin-name",
"license": "MIT",
"keywords": ["testing", "automation", "ci-cd"]
}Version format: Follow semantic versioning (MAJOR.MINOR.PATCH) Keywords: Use for plugin discovery and categorization
Component Path Configuration
Specify custom paths for components (supplements default directories):
{
"name": "plugin-name",
"commands": "./custom-commands",
"agents": ["./agents", "./specialized-agents"],
"hooks": "./config/hooks.json",
"mcpServers": "./.mcp.json"
}Important: Custom paths supplement defaults—they don't replace them. Components in both default directories and custom paths will load.
Path rules:
- Must be relative to plugin root
- Must start with
./ - Cannot use absolute paths
- Support arrays for multiple locations
Component Organization
Commands
Location: commands/ directory
Format: Markdown files with YAML frontmatter
Auto-discovery: All .md files in commands/ load automatically
Example structure:
commands/
├── review.md # /review command
├── test.md # /test command
└── deploy.md # /deploy commandFile format:
---
name: command-name
description: Command description
---
Command implementation instructions...Usage: Commands integrate as native slash commands in Claude Code
Agents
Location: agents/ directory
Format: Markdown files with YAML frontmatter
Auto-discovery: All .md files in agents/ load automatically
Example structure:
agents/
├── code-reviewer.md
├── test-generator.md
└── refactorer.mdFile format:
---
description: Agent role and expertise
capabilities:
- Specific task 1
- Specific task 2
---
Detailed agent instructions and knowledge...Usage: Users can invoke agents manually, or Claude Code selects them automatically based on task context
Skills
Location: skills/ directory with subdirectories per skill
Format: Each skill in its own directory with SKILL.md file
Auto-discovery: All SKILL.md files in skill subdirectories load automatically
Example structure:
skills/
├── api-testing/
│ ├── SKILL.md
│ ├── scripts/
│ │ └── test-runner.py
│ └── references/
│ └── api-spec.md
└── database-migrations/
├── SKILL.md
└── examples/
└── migration-template.sqlSKILL.md format:
---
name: Skill Name
description: When to use this skill
version: 1.0.0
---
Skill instructions and guidance...Supporting files: Skills can include scripts, references, examples, or assets in subdirectories
Usage: Claude Code autonomously activates skills based on task context matching the description
Hooks
Location: hooks/hooks.json or inline in plugin.json
Format: JSON configuration defining event handlers
Registration: Hooks register automatically when plugin enables
Example structure:
hooks/
├── hooks.json # Hook configuration
└── scripts/
├── validate.sh # Hook script
└── check-style.sh # Hook scriptConfiguration format:
{
"PreToolUse": [{
"matcher": "Write|Edit",
"hooks": [{
"type": "command",
"command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/validate.sh",
"timeout": 30
}]
}]
}Available events: PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification
Usage: Hooks execute automatically in response to Claude Code events
MCP Servers
Location: .mcp.json at plugin root or inline in plugin.json
Format: JSON configuration for MCP server definitions
Auto-start: Servers start automatically when plugin enables
Example format:
{
"mcpServers": {
"server-name": {
"command": "node",
"args": ["${CLAUDE_PLUGIN_ROOT}/servers/server.js"],
"env": {
"API_KEY": "${API_KEY}"
}
}
}
}Usage: MCP servers integrate seamlessly with Claude Code's tool system
Portable Path References
${CLAUDE_PLUGIN_ROOT}
Use ${CLAUDE_PLUGIN_ROOT} environment variable for all intra-plugin path references:
{
"command": "bash ${CLAUDE_PLUGIN_ROOT}/scripts/run.sh"
}Why it matters: Plugins install in different locations depending on:
- User installation method (marketplace, local, npm)
- Operating system conventions
- User preferences
Where to use it:
- Hook command paths
- MCP server command arguments
- Script execution references
- Resource file paths
Never use:
- Hardcoded absolute paths (
/Users/name/plugins/...) - Relative paths from working directory (
./scripts/...in commands) - Home directory shortcuts (
~/plugins/...)
Path Resolution Rules
In manifest JSON fields (hooks, MCP servers):
"command": "${CLAUDE_PLUGIN_ROOT}/scripts/tool.sh"In component files (commands, agents, skills):
Reference scripts at: ${CLAUDE_PLUGIN_ROOT}/scripts/helper.pyIn executed scripts:
#!/bin/bash
# ${CLAUDE_PLUGIN_ROOT} available as environment variable
source "${CLAUDE_PLUGIN_ROOT}/lib/common.sh"File Naming Conventions
Component Files
Commands: Use kebab-case .md files
code-review.md→/code-reviewrun-tests.md→/run-testsapi-docs.md→/api-docs
Agents: Use kebab-case .md files describing role
test-generator.mdcode-reviewer.mdperformance-analyzer.md
Skills: Use kebab-case directory names
api-testing/database-migrations/error-handling/
Supporting Files
Scripts: Use descriptive kebab-case names with appropriate extensions
validate-input.shgenerate-report.pyprocess-data.js
Documentation: Use kebab-case markdown files
api-reference.mdmigration-guide.mdbest-practices.md
Configuration: Use standard names
hooks.json.mcp.jsonplugin.json
Auto-Discovery Mechanism
Claude Code automatically discovers and loads components:
- Plugin manifest: Reads
.claude-plugin/plugin.jsonwhen plugin enables - Commands: Scans
commands/directory for.mdfiles - Agents: Scans
agents/directory for.mdfiles - Skills: Scans
skills/for subdirectories containingSKILL.md - Hooks: Loads configuration from
hooks/hooks.jsonor manifest - MCP servers: Loads configuration from
.mcp.jsonor manifest
Discovery timing:
- Plugin installation: Components register with Claude Code
- Plugin enable: Components become available for use
- Changes take effect on the next Claude Code session: restart Claude Code to reload plugin configuration
Override behavior: Custom paths in plugin.json supplement (not replace) default directories
Best Practices
Organization
- Logical grouping: Group related components together
- Put test-related commands, agents, and skills together
- Create subdirectories in
scripts/for different purposes
- Minimal manifest: Keep
plugin.jsonlean- Only specify custom paths when necessary
- Rely on auto-discovery for standard layouts
- Use inline configuration only for simple cases
- Documentation: Include README files
- Plugin root: Overall purpose and usage
- Component directories: Specific guidance
- Script directories: Usage and requirements
Naming
- Consistency: Use consistent naming across components
- If command is
test-runner, name related agenttest-runner-agent - Match skill directory names to their purpose
- If command is
- Clarity: Use descriptive names that indicate purpose
- Good:
api-integration-testing/,code-quality-checker.md - Avoid:
utils/,misc.md,temp.sh
- Good:
- Length: Balance brevity with clarity
- Commands: 2-3 words (
review-pr,run-ci) - Agents: Describe role clearly (
code-reviewer,test-generator) - Skills: Topic-focused (
error-handling,api-design)
- Commands: 2-3 words (
Portability
- Always use ${CLAUDE_PLUGIN_ROOT}: Never hardcode paths
- Test on multiple systems: Verify on macOS, Linux, Windows
- Document dependencies: List required tools and versions
- Avoid system-specific features: Use portable bash/Python constructs
Maintenance
- Version consistently: Update version in plugin.json for releases
- Deprecate gracefully: Mark old components clearly before removal
- Document breaking changes: Note changes affecting existing users
- Test thoroughly: Verify all components work after changes
Common Patterns
Minimal Plugin
Single command with no dependencies:
my-plugin/
├── .claude-plugin/
│ └── plugin.json # Just name field
└── commands/
└── hello.md # Single commandFull-Featured Plugin
Complete plugin with all component types:
my-plugin/
├── .claude-plugin/
│ └── plugin.json
├── commands/ # User-facing commands
├── agents/ # Specialized subagents
├── skills/ # Auto-activating skills
├── hooks/ # Event handlers
│ ├── hooks.json
│ └── scripts/
├── .mcp.json # External integrations
└── scripts/ # Shared utilitiesSkill-Focused Plugin
Plugin providing only skills:
my-plugin/
├── .claude-plugin/
│ └── plugin.json
└── skills/
├── skill-one/
│ └── SKILL.md
└── skill-two/
└── SKILL.mdTroubleshooting
Component not loading:
- Verify file is in correct directory with correct extension
- Check YAML frontmatter syntax (commands, agents, skills)
- Ensure skill has
SKILL.md(notREADME.mdor other name) - Confirm plugin is enabled in Claude Code settings
Path resolution errors:
- Replace all hardcoded paths with
${CLAUDE_PLUGIN_ROOT} - Verify paths are relative and start with
./in manifest - Check that referenced files exist at specified paths
- Test with
echo $CLAUDE_PLUGIN_ROOTin hook scripts
Auto-discovery not working:
- Confirm directories are at plugin root (not in
.claude-plugin/) - Check file naming follows conventions (kebab-case, correct extensions)
- Verify custom paths in manifest are correct
- Restart Claude Code to reload plugin configuration
Conflicts between plugins:
- Use unique, descriptive component names
- Namespace commands with plugin name if needed
- Document potential conflicts in plugin README
- Consider command prefixes for related functionality
For detailed examples and advanced patterns, see files in references/ and examples/ directories.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

