Plugins and skills

Claude Code offers two extension layers. If you are choosing between CLAUDE.md, a skill, subagent, MCP, hook or plugin, start with how it works and the extension map. For official, community and internal marketplaces, version constraints, recommendations and security governance, see plugin marketplaces and distribution.

For a command needed only in this project, begin with .claude/commands or .claude/skills. Package it as a plugin when it needs to be shared or reused.

#What a plugin can contain

#Minimal plugin structure

my-plugin/
├── .claude-plugin/
│   └── plugin.json
└── skills/
    └── review-api/
        └── SKILL.md

plugin.json:

{
  "name": "my-plugin",
  "description": "Team workflows for API review",
  "version": "1.0.0",
  "author": {
    "name": "Your Team"
  }
}

skills/review-api/SKILL.md:

---
description: Review API changes for compatibility, auth, pagination, errors, and observability.
---

Review the API change in $ARGUMENTS.
Check request/response compatibility, auth boundary, pagination, error codes, and logs.
Return findings first, then suggested fixes.

Enable it for testing:

claude --plugin-dir ./my-plugin

Invoke it in the session:

/my-plugin:review-api src/routes/billing.ts

#Skill names and arguments

Namespaces prevent collisions when several plugins define commands such as /deploy or /review.

#When to migrate from .claude/

A practical progression is standalone configuration, then a stable plugin, then marketplace or internal-repository distribution.

#Plugins and caching

With many plugins, check whether MCP tools are deferred. Otherwise changing the toolset can cause a cache miss.

#Official references

• Create plugins
• Plugins reference
• Extend Claude with skills
• How Claude Code uses prompt caching