create-plugins

<quick_start>

1. Ask what the plugin should do and which component types it needs (commands, agents, skills, hooks, MCP)
2. Create .claude-plugin/plugin.json manifest
3. Scaffold component directories with starter files
4. Validate structure and test with Claude Code </quick_start>

<phase_2_component_planning> Based on requirements, determine:

• Which slash commands to create (user-initiated actions)
• Which agents to create (autonomous background work)
• Which skills to create (domain knowledge that auto-activates)
• Which hooks to configure (event-driven automation)
• Which MCP servers to integrate (external service connections)

Rule: Only create directories for components the plugin actually uses. </phase_2_component_planning>

<phase_3_design> Design component interactions:

• Commands that invoke agents for complex subtasks
• Skills that provide knowledge agents and commands leverage
• Hooks that validate or enhance command/agent operations
• MCP servers that expose external tools used by commands and agents

Map the data flow between components before creating files. </phase_3_design>

<phase_4_structure_creation> Create the directory structure and manifest.

Manifest file: .claude-plugin/plugin.json

{
  "name": "plugin-name",
  "version": "1.0.0",
  "description": "What this plugin does",
  "author": {
    "name": "Author Name"
  }
}

Then create component directories as needed. See references/directory-patterns.md for complete examples of minimal, standard, and advanced layouts. </phase_4_structure_creation>

<phase_5_implementation> Create component files in order:

1. Commands first -- these are the user-facing entry points

   • YAML frontmatter with description, allowed-tools, argument-hint
   • XML-structured body with objective, process, success_criteria

2. Agents second -- these handle autonomous subtasks

   • YAML frontmatter with name, description (with <example> blocks), model, color, tools
   • System prompt in body

3. Skills third -- these provide domain knowledge

   • YAML frontmatter with name and rich description
   • XML body under 500 lines, references/ for overflow

4. Hooks fourth -- event-driven automation

   • hooks/hooks.json with plugin wrapper format: {"hooks": { ... }}
   • Use ${CLAUDE_PLUGIN_ROOT} for all script paths

5. MCP servers last -- external integrations

   • .mcp.json at plugin root
   • Use ${CLAUDE_PLUGIN_ROOT} for portable paths
   • Environment variable expansion for secrets: ${VAR_NAME}

Every intra-plugin path reference MUST use ${CLAUDE_PLUGIN_ROOT}. </phase_5_implementation>

<phase_6_validation> Validate the plugin:

• plugin.json has required name field in kebab-case
• All component directories are at plugin root (NOT inside .claude-plugin/)
• All .md files have valid YAML frontmatter
• All .json files are valid JSON (test with jq .)
• Hook scripts have executable permissions
• No hardcoded absolute paths -- all use ${CLAUDE_PLUGIN_ROOT}
• File naming follows kebab-case convention </phase_6_validation>

<phase_7_testing> Test the plugin:

1. Install locally: copy to or symlink from .claude/plugins/
2. Restart Claude Code
3. Run /help to verify commands appear
4. Test each command with representative inputs
5. Verify agents trigger on expected prompts
6. Check hooks fire with claude --debug
7. Confirm MCP servers connect with /mcp </phase_7_testing>