Complete AI Training
Sign inGet started

Skill · Mcp

Plugin structure

Scaffolds and explains Claude Code plugin structure, manifest, and component organization. Use when creating a new plugin, configuring plugin.json, organizing commands/agents/skills/hooks/MCP servers, fixing intra-plugin paths, or validating kebab-case naming.

Complete AI SkillsLicense: MITAdded Sep 29, 2026
AI & Automation
Use it in my AI View on TemplatesGrokBot

How to use it

  1. Start your plan and connect your AI once
  2. Ask for the task in your own words, or say it directly:
Use the Plugin structure skill to help me with this.

Without a connection: copy the SKILL.md below into your AI's project instructions.

SKILL.md

Claude Code Plugin Structure

This skill helps users create, understand, and organize Claude Code plugins following the official directory layout and manifest conventions. It covers scaffolding the directory tree, configuring the manifest, placing components, using portable paths, and validating naming.

When to use

  • Creating a new Claude Code plugin or scaffolding its directory tree.
  • Configuring or reviewing .claude-plugin/plugin.json manifest fields.
  • Deciding where commands, agents, skills, hooks, or MCP servers live.
  • Fixing intra-plugin path references to use ${CLAUDE_PLUGIN_ROOT}.
  • Checking that directory and file names follow kebab-case.

Workflows

Scaffold plugin directory

Inputs: Plugin name (kebab-case) and which components the plugin uses (commands, agents, skills, hooks, MCP, scripts).

  1. Create the standard tree: .claude-plugin/plugin.json, plus commands/, agents/, skills/, hooks/, .mcp.json, and scripts/ as needed.
  2. Only create directories for components the plugin actually uses.
  3. Use kebab-case for all names.
  4. Present the tree and explain each part.

Check: Every created directory corresponds to a component the user requested; no unused directories exist; all names are kebab-case. Output: The directory tree plus a short explanation of each part.

Configure plugin.json manifest

Inputs: Plugin name and any metadata the user wants to include.

  1. Require the name field in kebab-case.
  2. Offer recommended metadata: version, description, author, homepage, repository, license, keywords.
  3. Explain custom path configuration using relative paths starting with ./.
  4. Note that custom paths supplement the defaults rather than replace them.

Check: name is present and kebab-case; custom paths are relative and start with ./. Output: The manifest fields with an explanation of each.

Organize components

Inputs: The list of components the plugin uses.

  1. Place commands and agents as .md files with YAML frontmatter in their directories (commands/, agents/).
  2. Place skills as subdirectories each containing a SKILL.md.
  3. Place hooks in hooks.json.
  4. Place MCP servers in .mcp.json.
  5. Show example file formats and the auto-discovery rules for each component type.

Check: Each component sits in its correct location with the correct file format and naming. Output: Location, example format, and auto-discovery rule per component.

Use portable paths

Inputs: Every intra-plugin path reference in the plugin.

  1. Reference all intra-plugin paths with ${CLAUDE_PLUGIN_ROOT}.
  2. Apply it in hook commands, MCP server arguments, script execution, and resource files.
  3. Warn against hardcoded absolute paths, working-directory relative paths, and home shortcuts.

Check: No hardcoded absolute paths, working-directory relative paths, or home shortcuts remain. Output: Corrected path references with the ${CLAUDE_PLUGIN_ROOT} form.

Validate naming conventions

Inputs: All directory and file names in the plugin.

  1. Check that all directory and file names follow kebab-case.
  2. Confirm commands map to slash commands, agents to role names, and skills to directory names.
  3. Confirm supporting scripts and docs also use kebab-case.
  4. Confirm configuration files use standard names such as hooks.json and .mcp.json.

Check: Every name passes kebab-case; config files use the standard names. Output: A list of naming issues with the corrected names.

Tools and data

  • Use file and directory tools when available to create and inspect the plugin tree.
  • If a tool is not available, ask the user to provide the file contents or connect it.

Guardrails

  • Do not write or modify plugin code beyond directory scaffolding and configuration guidance.
  • Do not assume a specific installation path; always use ${CLAUDE_PLUGIN_ROOT} for intra-plugin references.
  • Do not create directories or files for components the plugin does not use.
  • Do not invent plugin features or manifest fields not described here.

Getting started

Ask the user what plugin they want to create or understand. If creating, request the plugin name and which components (commands, agents, skills, hooks, MCP) they need. Then scaffold the structure and explain each part.

Credits

Adapted from an open-source original (MIT): https://www.aitmpl.com/component/skills/development/plugin-structure

More mcp skills

All mcp skills

Prompts that go with Plugin structure

All prompts