Lesson 48: Plugin Development

Day 48 of 50 · ~7 min read · Phase 6: Mastery

The Opening Question

You've built agents with the Agent SDK. You've created skills in Claude Code. You've written CLAUDE.md files and configured hooks.

But here's the thing: you've been building for yourself. Your agent lives on your machine. Your skill works in your project. Your configuration is personal.

Here's the question: What if you wanted to share a skill, an agent, or a custom tool with your entire team? Or with the world? How do you package it so others can install and use it?

That's what plugins are for.

Discovery

Question 1: What is a plugin, really?

A plugin is a packaging mechanism. It's a way to bundle skills, agents, hooks, and MCP servers into a single installable unit that others can use.

Think of it this way:

Without plugins:

• You create a skill in .claude/skills/myskill/SKILL.md
• It only works in your project
• To share it, you copy the file manually
• Everyone who uses it has to maintain their own copy
• When you update it, everyone has to update manually

With plugins:

• You create a skill and wrap it in a plugin manifest
• You publish the plugin to a marketplace or GitHub
• Others install it with one command
• Everyone gets updates automatically
• Namespacing prevents conflicts

Here's the anatomy of a plugin:

my-plugin/
├── .claude-plugin/
│   └── plugin.json          ← Plugin metadata
├── skills/                   ← Skills (optional)
│   └── my-skill/
│       └── SKILL.md
├── agents/                   ← Custom agents (optional)
│   └── my-agent.json
├── hooks/                    ← Event handlers (optional)
│   └── hooks.json
├── .mcp.json                 ← MCP servers (optional)
├── bin/                      ← Executables (optional)
├── settings.json             ← Default settings (optional)
└── README.md                 ← Documentation

The key file is .claude-plugin/plugin.json:

{
  "name": "my-plugin",
  "description": "Does something useful",
  "version": "1.0.0",
  "author": {
    "name": "Your Name",
    "email": "you@example.com"
  },
  "homepage": "https://github.com/user/my-plugin",
  "repository": {
    "type": "git",
    "url": "https://github.com/user/my-plugin.git"
  }
}

When someone installs your plugin, Claude Code reads this manifest and knows:

• What the plugin is called
• What version they're getting
• What components to load (skills, agents, MCP servers, etc.)

Question 2: What's the difference between standalone configuration and plugins?

This matters because you need to know when to use each.

Standalone configuration (.claude/ in your project):

• Lives in your project
• Only available in that project
• Skill names are simple: /hello
• Perfect for personal customizations
• Shared by copying files

Plugins:

• Packaged in a directory with plugin.json
• Can be installed globally or per-project
• Skill names are namespaced: /my-plugin:hello
• Perfect for sharing and distributing
• Shared through marketplaces or git repos

When to use standalone:

• You're customizing Claude Code for one project
• The skill is project-specific and won't be reused
• You're experimenting

When to use plugins:

• You want to share with teammates
• The tool is general-purpose or domain-specific (but not project-specific)
• You want versioning and easy updates

Pause and think: Should your "code review" skill be standalone or a plugin?

If only you use it: standalone. If your team wants it: plugin. If the world might want it: plugin.

Question 3: How do you actually create and publish a plugin?

Let's walk through the practical steps.

Step 1: Create the plugin directory structure:

mkdir my-awesome-plugin
mkdir my-awesome-plugin/.claude-plugin
mkdir -p my-awesome-plugin/skills/awesome-skill

Step 2: Create the manifest:

cat > my-awesome-plugin/.claude-plugin/plugin.json << 'EOF'
{
  "name": "my-awesome-plugin",
  "description": "An awesome plugin that does cool things",
  "version": "1.0.0",
  "author": {
    "name": "Your Name"
  }
}
EOF

Step 3: Add a skill:

cat > my-awesome-plugin/skills/awesome-skill/SKILL.md << 'EOF'
---
description: Do something awesome
---

You are an awesome assistant. Help the user with awesome tasks.
EOF

Step 4: Test it locally:

claude --plugin-dir ./my-awesome-plugin

Then in Claude Code:

/my-awesome-plugin:awesome-skill

Step 5: Publish to a marketplace:

You can publish through:

• GitHub — Create a repo, others can install via URL
• Anthropic's official marketplace — Submit via platform.claude.com/plugins/submit
• Community marketplaces — Many third-party plugin registries exist

Step 6: Others install:

/plugin install https://github.com/yourname/my-awesome-plugin

Or if it's in a marketplace:

/plugin install my-awesome-plugin

Question 4: What can you package in a plugin?

You can include multiple types of components. Here's what's possible:

Skills — The most common. Reusable workflows Claude can invoke:

skills/code-review/SKILL.md
skills/documentation/SKILL.md

Agents — Custom agents with their own system prompts:

agents/security-reviewer.json
agents/performance-analyzer.json

Hooks — Automation that triggers on events (file change, tool use, etc.):

hooks/hooks.json

MCP servers — Integration with external services:

.mcp.json

Executables — Tools added to bash's PATH:

bin/deploy
bin/lint-check

Default settings — Activate specific agents or apply config when the plugin loads:

settings.json

Example: A comprehensive plugin

team-developer-plugin/
├── .claude-plugin/
│   └── plugin.json
├── skills/
│   ├── code-review/SKILL.md
│   ├── test-generator/SKILL.md
│   └── documentation/SKILL.md
├── agents/
│   └── frontend-specialist.json
├── hooks/
│   └── hooks.json
├── .mcp.json                 ← Connect to Jira, GitHub
├── bin/
│   ├── deploy
│   └── rollback
├── settings.json             ← Activate frontend-specialist by default
└── README.md

When your team installs this plugin, they get:

• Three ready-to-use skills
• A frontend specialist agent
• Automation hooks
• Integrations with their tools
• Custom commands in bash
• A preconfigured default agent

The Insight

Plugins are the distribution mechanism for Claude Code extensions. They package skills, agents, hooks, and MCP servers into versioned, installable units that can be shared with teams or published to marketplaces. Plugins enable reuse across projects, automatic updates, and community-driven tool building.

The mental model: Plugins are like VS Code extensions. You build something useful. You package it. You publish it to the VS Code marketplace. Now thousands of developers can install and use it. Same idea with Claude Code plugins — build once, share with many.

Try It

Create a plugin and share it with a colleague.

1. Create the plugin structure:

   mkdir my-test-plugin
   mkdir -p my-test-plugin/.claude-plugin
   mkdir -p my-test-plugin/skills/hello
   

2. Create the manifest:

   cat > my-test-plugin/.claude-plugin/plugin.json << 'EOF'
   {
     "name": "my-test-plugin",
     "description": "My first plugin",
     "version": "1.0.0"
   }
   EOF
   

3. Add a skill:

   cat > my-test-plugin/skills/hello/SKILL.md << 'EOF'
   ---
   description: Greet the user
   ---
   
   Greet the user warmly. Ask their name if you don't know it.
   EOF
   

4. Test it:

   claude --plugin-dir ./my-test-plugin
   /my-test-plugin:hello
   

5. Add to git and push:

   cd my-test-plugin
   git init
   git add .
   git commit -m "Initial plugin"
   git push origin main
   

6. Share with a colleague:

   • Give them the GitHub URL
   • They can install: /plugin install https://github.com/yourname/my-test-plugin

7. Iterate: Add more skills, version your plugin, publish to a marketplace.

Key Concepts Introduced

Bridge to Lesson 49

You now know how to build and package agents, skills, and plugins for sharing. But the real test is building something useful from scratch.

Tomorrow's question: Can you bring together everything you've learned — the Agent SDK, tools, the agentic loop, error handling, testing — and build a real agent that solves a practical problem?

Lesson 49 is the lab where you'll do exactly that.

← Back to Curriculum · Lesson 49 →