home / skills / outfitter-dev / agents / claude-plugins

claude-plugins skill

/plugins/outfitter/skills/claude-plugins

This skill helps you create and publish Claude Code plugins, guiding initialization, validation, and distribution across marketplaces.

npx playbooks add skill outfitter-dev/agents --skill claude-plugins

Review the files below or copy the command above to add this skill to your agents.

Files (7)
SKILL.md
11.1 KB
---
name: claude-plugins
description: This skill should be used when creating plugins, publishing to marketplaces, or when "plugin.json", "marketplace", "create plugin", or "distribute plugin" are mentioned.
metadata:
  version: "1.0.0"
  related-skills:
    - claude-plugin-audit
    - claude-agents
    - claude-commands
    - claude-hooks
    - skills-dev
    - claude-rules
    - claude-config
---

# Claude Plugin Development

Complete lifecycle for developing, validating, and distributing Claude Code plugins.

## Steps

1. Define plugin scope and components needed
2. Initialize plugin structure with `plugin.json`
3. If adding commands, load the `outfitter:claude-commands` skill
4. If adding agents, load the `outfitter:claude-agents` skill
5. If adding hooks, load the `outfitter:claude-hooks` skill
6. If adding skills, load the `outfitter:skills-dev` skill
7. Delegate by loading the `outfitter:claude-plugin-audit` skill for validation
8. Fix issues and distribute

## Quick Start

```bash
# 1. Scaffold plugin
./scripts/scaffold-plugin.sh my-plugin --with-commands

# 2. Add components (commands, agents, hooks, skills)
# 3. Test locally
/plugin marketplace add ./my-plugin
/plugin install my-plugin@my-plugin

# 4. Distribute
git push origin main --tags
```

## Lifecycle Overview

```
Discovery -> Init -> Components -> Validate -> Distribute -> Marketplace
    |         |          |            |            |             |
    v         v          v            v            v             v
 Purpose   Scaffold   Commands    Structure    Package      Catalog
  Scope    plugin.json  Agents     Testing     Version      Publish
  Type      README      Hooks      Quality     Release       Share
```

## Stage 1: Discovery

Before creating a plugin, clarify:

| Question | Impact |
|----------|--------|
| What problem does this solve? | Plugin scope and features |
| Who will use it? | Distribution method |
| What components are needed? | Commands, agents, hooks, MCP servers |
| Where will it live? | Personal, project, or marketplace |

## Stage 2: Initialization

### Standalone Plugin

Standalone plugins need their own `.claude-plugin/plugin.json`:

```
my-plugin/
├── .claude-plugin/
│   └── plugin.json      # Required for standalone
├── README.md            # Required for distribution
├── commands/            # Optional components
├── agents/
├── skills/
└── hooks/
```

### plugin.json (Standalone)

```json
{
  "name": "my-plugin",
  "version": "1.0.0",
  "description": "Brief description of what this plugin does",
  "author": {
    "name": "Your Name",
    "email": "[email protected]"
  },
  "license": "MIT"
}
```

### Marketplace with Local Plugins (Consolidated)

For marketplaces where all plugins live in the same repo, use `strict: false` to consolidate metadata. Plugins don't need their own manifests:

```
my-marketplace/
├── .claude-plugin/
│   └── marketplace.json # All metadata here (strict: false)
├── plugin-a/
│   └── commands/
├── plugin-b/
│   └── skills/
└── README.md
```

### marketplace.json (Consolidated)

```json
{
  "name": "my-marketplace",
  "owner": {
    "name": "Team Name",
    "email": "[email protected]"
  },
  "strict": false,
  "plugins": [
    {"name": "plugin-a", "source": "./plugin-a", "version": "1.0.0", "description": "Plugin A", "license": "MIT"},
    {"name": "plugin-b", "source": "./plugin-b", "version": "1.0.0", "description": "Plugin B", "license": "MIT"}
  ]
}
```

**Benefits:** Single source of truth, no version drift between marketplace and plugin manifests.

For external plugins (GitHub repos), use minimal entries and let the external repo own its manifest.

See [structure.md](references/structure.md) for complete plugin.json schema.

## Stage 3: Components

Add components based on plugin needs. See Steps section for which skills to load.

### Slash Commands

Create custom commands in `commands/` directory:

```markdown
---
description: "Review code for quality issues"
---

Review the following code: {{0}}

Check for: code style, bugs, performance, security
```

For complex commands, load the `outfitter:claude-commands` skill.

### Custom Agents

Define specialized agents in `agents/` directory:

```markdown
---
name: security-reviewer
description: "Security-focused code reviewer"
---

You are a security expert. When reviewing code:
1. Check for vulnerabilities
2. Verify input validation
3. Report issues with severity levels
```

For agent design patterns, load the `outfitter:claude-agents` skill.

### Event Hooks

Two ways to define hooks:

**File-based** (auto-discovered from `hooks/hooks.json`):

```json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [{"type": "command", "command": "${CLAUDE_PLUGIN_ROOT}/scripts/validate.sh"}]
      }
    ]
  }
}
```

**Inline in plugin.json** - same structure, add `"hooks"` key directly.

Hook types: PreToolUse, PostToolUse, UserPromptSubmit, Stop, SessionStart, SessionEnd

For hook implementation, load the `outfitter:claude-hooks` skill. See [structure.md](references/structure.md) for hook JSON format and script interface.

### Skills

Add reusable methodology patterns in `skills/` directory. For skill authoring, load the `outfitter:skills-dev` skill.

### MCP Servers

```json
{
  "mcpServers": {
    "my-server": {
      "command": "${CLAUDE_PLUGIN_ROOT}/servers/my-server",
      "args": ["--config", "${CLAUDE_PLUGIN_ROOT}/config.json"],
      "env": {"API_KEY": "${MY_API_KEY}"}
    }
  }
}
```

Path variables: `${CLAUDE_PLUGIN_ROOT}` (plugin directory), `${VAR_NAME}` (env var)

## Plugin Caching

When plugins are installed, Claude Code copies them to a cache directory. This has implications:

- **Path traversal breaks**: `../../shared/file.md` will not work after install
- **Keep resources inside plugin**: Shared scripts, rules, and assets must be within plugin directory
- **Cross-plugin dependencies**: Use skill invocation (`plugin:skill-name`) instead of file references

See [caching.md](references/caching.md) for workarounds and best practices.

## Stage 4: Validation

Before distribution, validate the plugin.

### Checklist

**Structure:**
- [ ] Standalone: plugin.json exists and is valid JSON
- [ ] Marketplace (consolidated): metadata in marketplace.json with `strict: false`
- [ ] Required fields present (name, version, description)
- [ ] Plugin name matches directory name (kebab-case)

**Components:**
- [ ] Commands have YAML frontmatter with description
- [ ] Agents have YAML frontmatter with name and description
- [ ] Hook scripts are executable (`chmod +x`)
- [ ] Hook matchers are valid regex

**Documentation:**
- [ ] README.md with installation instructions
- [ ] LICENSE file included

### Local Testing

```bash
# Add as local marketplace
/plugin marketplace add ./my-plugin

# Install and test
/plugin install my-plugin@my-plugin

# Test commands
/my-command arg1 arg2
```

See [structure.md](references/structure.md) for validation commands and detailed component schemas.

## Stage 5: Distribution

### Semantic Versioning

Follow semver (MAJOR.MINOR.PATCH):
- **MAJOR**: Breaking changes
- **MINOR**: New features (backward compatible)
- **PATCH**: Bug fixes

### Release Workflow

```bash
# 1. Update version in plugin.json
# 2. Update CHANGELOG.md
# 3. Commit and tag
git add plugin.json CHANGELOG.md
git commit -m "chore: release v1.0.0"
git tag v1.0.0
git push origin main --tags

# 4. Create GitHub release
gh release create v1.0.0 --title "v1.0.0" --notes "Initial release"
```

### Distribution Methods

| Method | Best For | Setup |
|--------|----------|-------|
| GitHub repo | Public/team plugins | Push to GitHub |
| Git URL | GitLab, Bitbucket | Full URL in source |
| Local path | Development/testing | Relative path |

See [distribution.md](references/distribution.md) for packaging, CI/CD, and release automation.

## Stage 6: Marketplace

A marketplace catalogs plugins for discovery and installation.

### Creating a Marketplace

Create `.claude-plugin/marketplace.json`:

```json
{
  "name": "my-marketplace",
  "owner": {"name": "Team Name", "email": "[email protected]"},
  "plugins": [
    {"name": "my-plugin", "source": "./plugins/my-plugin"}
  ]
}
```

### Plugin Sources

```json
// Relative path
{"source": "./plugins/my-plugin"}

// GitHub
{"source": {"source": "github", "repo": "owner/plugin-repo", "ref": "v1.0.0"}}

// Git URL
{"source": {"source": "url", "url": "https://gitlab.com/team/plugin.git"}}
```

### Commands

```bash
/plugin marketplace add owner/repo       # Add marketplace
/plugin marketplace list                  # List available
/plugin install plugin-name@marketplace  # Install from marketplace
/plugin marketplace update marketplace   # Update
```

See [marketplace.md](references/marketplace.md) for full schema, team configuration, and hosting strategies.

## Best Practices

### Naming Conventions

- **Plugin name**: kebab-case (e.g., `dev-tools`)
- **Commands**: kebab-case (e.g., `review-pr`)
- **Agents**: kebab-case (e.g., `security-reviewer`)

### Security

- Never hardcode secrets in plugin files
- Use environment variables for sensitive data
- Validate all user inputs in hooks
- Document security requirements

### Documentation

- **README.md**: Overview, installation, usage examples
- **CHANGELOG.md**: Version history with semver
- **LICENSE**: Appropriate license file

## Troubleshooting

**Plugin not loading:**
- Standalone: verify plugin.json syntax: `jq empty .claude-plugin/plugin.json`
- Marketplace: verify marketplace.json syntax and `strict: false` if no plugin.json
- Check plugin name matches directory
- Ensure required fields present (name, version, description)

**Commands not appearing:**
- Verify YAML frontmatter exists
- Check files in `commands/` directory

**Hooks not executing:**
- Check scripts executable: `chmod +x`
- Verify matcher regex correct
- Test hook script independently

**MCP servers failing:**
- Verify server binary exists
- Check environment variables set
- Review logs: `~/Library/Logs/Claude/`

<references>

- [structure.md](references/structure.md) - Directory layout, plugin.json schema, component formats
- [distribution.md](references/distribution.md) - Packaging, versioning, CI/CD, release automation
- [marketplace.md](references/marketplace.md) - Marketplace schema, hosting, team configuration
- [caching.md](references/caching.md) - Plugin caching behavior and cross-plugin dependencies

</references>

<rules>

ALWAYS:
- Standalone plugins: create `.claude-plugin/plugin.json`
- Marketplace local plugins: use `strict: false` and consolidate metadata in marketplace.json
- External plugins: let the external repo own its manifest
- Keep plugin resources within plugin directory (caching limitation)
- Use kebab-case for all names
- Include README.md and LICENSE for distribution
- Follow semantic versioning

NEVER:
- Hardcode secrets in plugin files
- Use path traversal (`../`) for cross-plugin resources
- Skip validation before distribution
- Omit description (in plugin.json or marketplace entry)

</rules>

## Related Skills

- **claude-commands** - Slash command development
- **claude-agents** - Custom agent design
- **claude-hooks** - Event hook implementation
- **skills-dev** - Skill creation patterns

Overview

This skill guides the complete lifecycle for creating, validating, and distributing Claude Code plugins. It covers manifest formats for standalone plugins and marketplaces, component patterns (commands, agents, hooks, skills, MCP servers), caching implications, validation checklists, and release practices. Use it as a reference when scaffolding, testing, or publishing plugins.

How this skill works

The skill inspects project layout and manifest files (.claude-plugin/plugin.json or marketplace.json) and enforces required fields, naming conventions, and component schemas. It outlines component locations (commands/, agents/, hooks/, skills/), hook formats and types, MCP server config, and local testing commands. It also provides validation steps, packaging and semantic versioning guidance, and marketplace integration instructions.

When to use it

  • Scaffolding a new plugin or marketplace package
  • Adding commands, custom agents, event hooks, or MCP servers
  • Preparing a plugin for distribution or publishing to a marketplace
  • Validating plugin structure, metadata, and executables before release
  • Troubleshooting plugin installation, command visibility, or hook execution

Best practices

  • Use kebab-case for plugin, command, and agent names
  • Keep all resources inside the plugin directory to avoid cache/path issues
  • Do not hardcode secrets; reference environment variables instead
  • Include README.md, LICENSE, and CHANGELOG.md before distribution
  • Follow semantic versioning and tag releases (MAJOR.MINOR.PATCH)
  • Validate manifests and component schemas before publishing

Example use cases

  • Scaffold a standalone plugin with .claude-plugin/plugin.json and commands/
  • Create a consolidated local marketplace using .claude-plugin/marketplace.json with strict: false
  • Add a security-reviewer agent and load claude-agents patterns for consistent behavior
  • Define PreToolUse hooks that run validation scripts and ensure hooks are executable
  • Package an MCP server with command, args, and env entries for runtime integration

FAQ

Do standalone plugins require a plugin.json?

Yes. Standalone plugins must include .claude-plugin/plugin.json with name, version, and description.

Can marketplace repositories omit plugin manifests?

Yes. Use marketplace.json with strict: false to consolidate metadata and avoid per-plugin manifests.

Why do my hooks fail after install?

Installed plugins are cached; ensure hook scripts are inside the plugin, executable (chmod +x), and regex matchers are valid.