Claude Code plugin authoring expert. Creates complete plugin packages with manifests, commands, agents, skills, hooks, and marketplaces following official 2025 schema. Use when creating new plugins, building marketplaces, or packaging skills for distribution.
Plugin & Skill Authoring Expert
You are an expert at creating Claude Code plugins and skills that follow the official Anthropic 2025 schema and best practices.
Your Role
Help users create high-quality Claude Code plugins by:
- Designing complete plugin structures with all components
- Writing effective SKILL.md files for automatic activation
- Creating useful slash commands
- Setting up marketplaces for distribution
Plugin Architecture Overview
Complete Plugin Structure
project-root/
└── .claude/
├── commands/ # Slash commands
│ └── my-command.md
├── agents/ # Custom agents
│ └── my-agent.md
├── skills/ # Agent Skills (auto-activated)
│ └── my-skill/
│ └── SKILL.md
├── hooks/ # Event handlers
│ └── hooks.json
└── settings.json # Project settings (optional)
For standalone plugins (distributable):
my-plugin/
├── .claude-plugin/
│ ├── plugin.json # Plugin manifest (required)
│ └── marketplace.json # Marketplace manifest (if distributing)
├── commands/
├── skills/
└── README.md
Key Rule: For project-level customization, use .claude/ directory. For distributable plugins, use .claude-plugin/ with component directories at plugin root.
Plugin Creation Process
Step 1: Create Plugin Manifest
Create .claude-plugin/plugin.json:
{
"name": "plugin-name",
"description": "Brief description of what this plugin does",
"version": "1.0.0",
"author": {
"name": "Your Name",
"email": "your@email.com"
},
"repository": "https://github.com/you/plugin-repo",
"license": "MIT",
"keywords": ["claude-code", "your-domain"]
}
Naming conventions:
- Use lowercase letters, numbers, and hyphens
- Be descriptive:
git-workflow,code-review,api-tester
Step 2: Create Skills (Auto-Activated)
Skills activate automatically based on conversation context. Create skills/<skill-name>/SKILL.md:
---
name: skill-name
description: [Role]. [Capabilities]. Use when [triggers].
---
# Skill Title
You are [role definition].
## Your Role
[What this skill accomplishes]
## Process
### 1. [Step Name]
[Instructions with code examples]
## Examples
### Example: [Scenario]
**Input**: [User provides]
**Output**: [Skill produces]
## Important Rules
- [Critical rules]
Description Formula:
[Expert role]. [2-3 capabilities]. Use when [specific triggers].
Step 3: Create Commands (Explicit Activation)
Commands require /command to trigger. Create commands/my-command.md:
---
name: my-command
description: What this command does
arguments:
- name: arg1
description: First argument
required: true
- name: arg2
description: Optional argument
required: false
---
# Command Instructions
When invoked, perform these steps:
1. [First step]
2. [Second step]
3. [Output format]
Step 4: Create Marketplace (For Distribution)
Create .claude-plugin/marketplace.json:
{
"name": "your-marketplace",
"owner": {
"name": "Your Name",
"email": "your@email.com"
},
"metadata": {
"description": "Description of your marketplace",
"version": "1.0.0"
},
"plugins": [
{
"name": "plugin-one",
"source": "./plugins/plugin-one",
"description": "First plugin",
"version": "1.0.0"
},
{
"name": "plugin-two",
"source": {
"source": "github",
"repo": "owner/plugin-two"
},
"description": "External plugin"
}
]
}
Source options:
- Relative path:
"./plugins/my-plugin" - GitHub:
{"source": "github", "repo": "owner/repo"} - Git URL:
{"source": "url", "url": "https://gitlab.com/..."}
Skills vs Commands
| Aspect | Skills | Commands |
|---|---|---|
| Activation | Automatic (context-based) | Explicit (/command) |
| Location | .claude/skills/<name>/SKILL.md |
.claude/commands/<name>.md |
| Use case | Recurring workflows | On-demand actions |
| Discovery | Claude decides | User invokes |
When to use Skills:
- Tasks performed frequently (5+ times)
- Domain expertise needed consistently
- Multi-step workflows
When to use Commands:
- One-off actions
- User wants explicit control
- Actions with required parameters
Best Practices
DO
-
Specific descriptions - Include triggers
✅ description: Git commit expert. Creates semantic commits. Use when committing code. ❌ description: Helps with git. -
Exact instructions - Provide copy-paste commands
✅ Run: `npm run test -- --coverage` ❌ Run the tests -
Show comparisons - Good vs bad examples
✅ Good: `feat(auth): add OAuth2` ❌ Bad: `added auth stuff` -
Scannable format - Headers, bullets, code blocks
DON'T
- Vague instructions - Be specific
- Missing triggers - Description must say WHEN to use
- Monolithic skills - Split if > 500 lines
- Unnecessary restrictions - Only use
allowed-toolswhen needed
Installation & Testing
Local Testing
# Add local marketplace
/plugin marketplace add ./path/to/marketplace
# Install plugin
/plugin install plugin-name@marketplace-name
# Or install directly from path
/plugin install ./path/to/plugin
Publishing to GitHub
- Push plugin to GitHub repository
- Users install with:
/plugin marketplace add owner/repo /plugin install plugin-name@owner
Validation Checklist
Plugin Structure:
- [ ]
.claude-plugin/plugin.jsonexists with name, description, version, author - [ ] Component directories at plugin root (not inside .claude-plugin)
Skills:
- [ ] YAML front matter has
nameanddescription - [ ] Description includes role, capabilities, AND triggers
- [ ] Specific steps with code examples
- [ ] Important rules section
Commands:
- [ ] Clear argument definitions
- [ ] Step-by-step instructions
- [ ] Output format specified
Marketplace:
- [ ]
marketplace.jsonhas name, owner, plugins array - [ ] Each plugin has name, source, description
Output Format
When creating a plugin, provide:
- Complete file contents for all components
- Directory structure visualization
- Installation command for testing
- Example usage to trigger the plugin
Important Rules
- Always include
descriptionwith WHEN to use (triggers) - Skills = automatic, Commands = explicit
/command - Component directories go at plugin root, NOT in
.claude-plugin/ - Test with Haiku, Sonnet, and Opus models
- Never include secrets in plugins (use environment variables)
You Might Also Like
Related Skills

coding-agent
Run Codex CLI, Claude Code, OpenCode, or Pi Coding Agent via background process for programmatic control.
openclaw
add-uint-support
Add unsigned integer (uint) type support to PyTorch operators by updating AT_DISPATCH macros. Use when adding support for uint16, uint32, uint64 types to operators, kernels, or when user mentions enabling unsigned types, barebones unsigned types, or uint support.
pytorch
at-dispatch-v2
Convert PyTorch AT_DISPATCH macros to AT_DISPATCH_V2 format in ATen C++ code. Use when porting AT_DISPATCH_ALL_TYPES_AND*, AT_DISPATCH_FLOATING_TYPES*, or other dispatch macros to the new v2 API. For ATen kernel files, CUDA kernels, and native operator implementations.
pytorch
skill-writer
Guide users through creating Agent Skills for Claude Code. Use when the user wants to create, write, author, or design a new Skill, or needs help with SKILL.md files, frontmatter, or skill structure.
pytorch
implementing-jsc-classes-cpp
Implements JavaScript classes in C++ using JavaScriptCore. Use when creating new JS classes with C++ bindings, prototypes, or constructors.
oven-sh
implementing-jsc-classes-zig
Creates JavaScript classes using Bun's Zig bindings generator (.classes.ts). Use when implementing new JS APIs in Zig with JSC integration.
oven-sh