Layer 5 — Plugins (The Distribution Layer)

What plugins solve

Plugins are the distribution mechanism. You've built CLAUDE.md files, skills, hooks, and subagents. Without plugins, every new team member has to manually set up each piece. With a plugin, they run one install command and get everything.

Creating a network operations plugin

Structure:

network-ops-plugin/
├── manifest.json
├── CLAUDE.md
├── skills/
│   ├── bgp-troubleshoot/
│   │   └── SKILL.md
│   └── generate-switch-config/
│       ├── SKILL.md
│       └── scripts/
│           └── access-switch-template.j2
├── agents/
│   ├── network-auditor.md
│   └── path-tracer.md
├── hooks/
│   └── settings.json
└── commands/
    ├── health-check.md
    ├── config-audit.md
    └── change-prep.md

The manifest.json:

{
  "name": "network-ops",
  "version": "1.0.0",
  "description": "Network operations toolkit — health checks, audits, troubleshooting, and config generation for multi-vendor environments",
  "skills": ["skills/bgp-troubleshoot", "skills/generate-switch-config"],
  "agents": ["agents/network-auditor.md", "agents/path-tracer.md"],
  "hooks": "hooks/settings.json",
  "commands": ["commands/health-check.md", "commands/config-audit.md", "commands/change-prep.md"]
}

Installing the plugin

For a teammate joining the network automation team:

cd ~/network-automation
claude

/plugin install ./network-ops-plugin

Or from a git repository:

/plugin marketplace add https://github.com/your-org/network-ops-plugin

One command. The new engineer gets every skill, hook, subagent, and custom command that the team has built. Their Claude Code session behaves identically to every other team member's. The config audit checks the same 12 items. The health check collects the same metrics. The safety hooks block the same dangerous commands.

This is how institutional knowledge scales. Not through documentation that nobody reads. Not through onboarding sessions that people forget. Through executable configuration that enforces itself.