Dein erstes Claude Code Plugin in 60 Minuten, vom leeren Folder zum installierbaren Bundle

Du hast eine Slash-Command die nur Du brauchst. Eine Skill die Du auf drei Repos kopierst. Einen Hook der bei jedem Edit was prüft. Solo funktioniert das. Sobald Du das Setup an einen Kollegen weitergeben willst, kippt es. Sieben Files an drei Orten, jede Person installiert anders, niemand weiß welche Version aktuell ist.

Genau dafür sind Plugins da. Ein Plugin ist ein Container der Slash-Commands, Skills, Hooks, Sub-Agents, MCP-Server, LSP-Server und Themes in einem Unit packt. Du installierst es einmal, Du aktivierst es einmal, Du teilst es als ZIP, als Git-Repo oder über einen Marketplace. Anthropic hat das Plugin-System zum Standardweg gemacht alles zu verteilen was man früher per Copy-Paste verteilt hat.

Dieses Playbook geht den Weg von Null. Du kannst alle 10 Schritte in 60 Minuten durch, danach hast Du ein installierbares Plugin mit einer Slash-Command, einer Skill und einem Hook. Wer will, schaltet am Ende noch MCP-Server dazu.

Schritt 1, leerer Folder und das Manifest

Ein Plugin ist ein Folder mit einer festen Struktur. Leg den Folder irgendwo an, Name ist frei. Bei mir ist das ~/dev/plugins/dein-plugin-name. Wichtig ist dass innen drin ein verstecktes Verzeichnis .claude-plugin/ mit der Datei plugin.json liegt. Diese Datei ist das Manifest und der einzige Pflicht-Eintrag.

~/dev/plugins/dein-plugin-name/
└── .claude-plugin/
    └── plugin.json

Inhalt von plugin.json minimal:

{
  "name": "dein-plugin-name",
  "version": "0.1.0",
  "description": "Was Dein Plugin macht in einem Satz."
}

Mehr brauchst Du am Anfang nicht. Author, Homepage, License und so kommen später.

Schritt 2, die Component-Directories am Plugin-Root

Anfänger-Falle Nummer eins. Du legst alle Component-Folder NICHT in .claude-plugin/, sondern direkt am Plugin-Root daneben. Das .claude-plugin/ Verzeichnis ist nur für Manifest und Config. Alles andere lebt eine Ebene hoeher.

Diese Folder kennt Claude Code an der Plugin-Wurzel:

• commands/ für Slash-Commands
• skills/ für Skills mit SKILL.md
• agents/ für Sub-Agents
• hooks/hooks.json für Event-Hooks
• output-styles/ für eigene Antwort-Stile
• themes/ für Color-Themes
• monitors/ für Status-Line-Watcher
• .mcp.json für MCP-Server-Configs
• .lsp.json für Language-Server
• bin/ für Executables die automatisch in den PATH des Bash-Tools wandern wenn das Plugin aktiv ist

Du musst nicht alle anlegen. Für den ersten Wurf reichen commands/, skills/ und hooks/.

Schritt 3, erste Slash-Command

Leg commands/hello.md an. Slash-Commands sind einfache Markdown-Files mit YAML-Frontmatter. Der Filename wird zum Befehl, also wird das /hello in Claude Code.

---
description: "Sagt hallo und zeigt was diese Slash-Command macht."
---

Schreibe einen kurzen Hallo-Gruss und erkläre was die `dein-plugin-name` 
Plugin-Suite anbietet. Liste die wichtigsten Slash-Commands auf.

Das war es. Beim Aufruf von /hello rendert Claude Code das File als User-Prompt und schickt es ans Modell.

Schritt 4, erste Skill

Skills sind anders. Claude entscheidet selbst wann er eine Skill nutzt, basierend auf der Beschreibung in SKILL.md. Sie liegen in einem Unter-Folder mit dem Skill-Namen.

skills/
└── code-review/
    └── SKILL.md

Inhalt von SKILL.md:

---
name: code-review
description: "Wird automatisch genutzt wenn der User um ein Code-Review bittet, einen Pull Request reviewen will, oder fragt was an einem Code-Snippet auffällt. Prüfe immer auf Sicherheit, Lesbarkeit und Tests."
---

# Code Review Skill

Bei jedem Review prüfe der Reihe nach:

1. Sicherheit: Injection-Vektoren, Hardcoded-Secrets, unvalidated Input.
2. Lesbarkeit: Variable-Namen, Function-Length, Komplexitaet.
3. Tests: Coverage für den Happy-Path und für mindestens zwei Edge-Cases.

Schreibe das Review als Markdown mit drei Headlines.

Der description-Block ist das Wichtigste. Claude liest ihn beim Routing und entscheidet ob die Skill zum aktuellen Request passt. Schreib ihn so dass klar ist wann die Skill helfen soll.

Schritt 5, erste Hook

Hooks sind kleine Scripts die bei bestimmten Events feuern. Sehr nuetzlich für Lint-Checks, für Audit-Logs, für Memory-Updates. Im Plugin liegen sie in hooks/hooks.json oder direkt im Manifest.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"$(date +%H:%M:%S) edit by $CLAUDE_USER\" >> ~/.claude/edits.log"
          }
        ]
      }
    ]
  }
}

Das logt jeden File-Edit mit Timestamp in eine lokale Log-Datei. Klein, aber zeigt das Pattern. Komplexere Hooks rufen Bash-Scripts auf die in bin/ liegen.

Schritt 6, MCP-Server optional dazu

Wenn Dein Plugin einen MCP-Server bringen soll, leg .mcp.json am Plugin-Root an. Format ist identisch zum projekt-lokalen .mcp.json das Du vielleicht schon kennst.

{
  "mcpServers": {
    "dein-tool": {
      "command": "node",
      "args": ["./bin/dein-mcp-server.js"]
    }
  }
}

Der Pfad ist relativ zum Plugin-Root. Das bin/-Verzeichnis wird automatisch zum PATH hinzugefuegt sobald das Plugin aktiv ist, also funktioniert auch ein blanker Command-Name ohne ./bin/-Prefix.

Schritt 7, lokal aktivieren und testen

Bevor Du an Distribution denkst, teste lokal. In Claude Code geht das über den Slash-Befehl /plugin. Im Discover-Tab kannst Du Plugins aus aktivierten Marketplaces installieren. Für Dein noch-nicht-veroeffentlichtes Plugin nimmst Du den Manage-Tab und addest es als Filesystem-Source.

Alternativ via CLI:

claude plugin install --source ~/dev/plugins/dein-plugin-name

Im Hintergrund schreibt Claude Code Deine Aktivierung in ~/.claude/settings.json unter enabledPlugins. Eintrag sieht so aus:

{
  "enabledPlugins": {
    "local/dein-plugin-name": true
  }
}

Reload, dann tipp /hello ein. Wenn die Slash-Command erscheint, lebt das Plugin.

Schritt 8, Marketplace anlegen oder URL-Distribution

Zwei Wege das Plugin zu verteilen. Erste Option, Du baust einen eigenen Marketplace. Das ist ein Git-Repo mit einer .claude-plugin/marketplace.json die alle Plugins listet die der Marketplace anbietet.

Minimale Marketplace-Struktur:

mein-marketplace/
├── .claude-plugin/
│   └── marketplace.json
└── plugins/
    └── dein-plugin-name/
        ├── .claude-plugin/plugin.json
        ├── commands/
        ├── skills/
        └── hooks/

marketplace.json listet welche Plugin-Folder im Repo verfügbar sind. Andere User adden Deinen Marketplace dann mit /plugin marketplace add github:dein-handle/mein-marketplace.

Zweite Option ist --plugin-url. Du packst das Plugin als ZIP, lädst es irgendwo hoch, und Kollegen starten Claude Code mit claude --plugin-url https://example.com/dein-plugin-0.1.0.zip. Das lädt für eine Session, kein permanentes Setup. Details dazu im separaten Playbook plugin-bundle-via-url-distribution.

Für die meisten Teams ist Marketplace die richtige Wahl. URL-Distribution ist gut für einmalige Tests oder für Leute die nichts dauerhaft installieren wollen.

Schritt 9, Trust-Boundaries verstehen

Wichtige Sache die viele am Anfang uebersehen. Plugins können Hooks ausführen und Bash-Scripts in bin/ aufrufen. Das ist Macht und das ist Risiko. Anthropic hat zwei Schutzmechanismen eingebaut.

Der erste, Plugins können NICHT die volle settings.json kontrollieren. Erlaubt sind nur die zwei Keys agent und subagentStatusLine. Alles andere wird ignoriert wenn ein Plugin es zu setzen versucht. Heißt, ein boeses Plugin kann nicht ungefragt MCP-Server für Dich registrieren oder Permissions umbiegen.

Der zweite, Trust-Prompts. Beim ersten Aktivieren fragt Claude Code ob Du dem Plugin vertraust. IT-Admins können das über strictKnownMarketplaces als Managed-Setting hart beschränken. Mit pluginTrustMessage kann ein Custom-Trust-Prompt gesetzt werden, etwa für Compliance-Hinweise.

Für eigene Plugins die Du selber baust ist das alles transparent. Sobald Du Plugins von Dritten installierst, lies vorher das Plugin-Source. Hooks die curl | bash machen sind Red Flags.

Schritt 10, versionieren und committen

Letzter Schritt. Dein Plugin lebt jetzt. Bevor Du es teilst, mach das Versioning sauber. Bump die version in plugin.json auf 1.0.0 sobald die erste stabile Variante fertig ist. Tag den Git-Commit mit dem gleichen Wert.

Was im Repo committed werden sollte: alles außer User-spezifischen Logs. Was raus muss: API-Keys in Hook-Commands, persönliche Pfade, lokale Test-Outputs. Plugins sind genau wie Code, lies einmal kritisch durch bevor Du push.

Empfehlung für das Versioning, Semantic Versioning ist ueberkill für Solo-Plugins. Reicht wenn Du 0.1.0 für Erste-Variante, 0.2.0 für "neue Skill dazugekommen", 1.0.0 für "habe ich seit zwei Wochen täglich genutzt und nichts ist kaputt" nimmst.

Was als nächstes

Wenn Dein Plugin steht und drei Leute es nutzen, kommt der nächste Schritt. Wer das Plugin per ZIP-URL verteilen will, springt zu plugin-bundle-via-url-distribution. Wer einen vollen Marketplace bauen will mit eigenem Repo und Plugin-Auswahl, schaut in die Anthropic-Doku zu Plugin-Marketplaces (Link unten). Wer das Plugin in eine CI integrieren will, kombiniert es mit claude-code-headless-in-ci-cd.

Eine Sache die ich gelernt habe nach dem dritten eigenen Plugin: Halt die Plugins klein. Ein Plugin pro Use-Case, nicht ein Mega-Plugin mit allem drin. Wenn ein Plugin sieben Skills und zwoelf Slash-Commands hat, splitt es. Kollegen installieren lieber drei kleine Plugins mit klarer Funktion als ein grosses das halb passt.

Source

Quellen aus der offiziellen Claude Code Doku:

• Plugin Manifest, Component-Directories, Hook-Format, Trust-Boundaries: https://code.claude.com/docs/en/plugins-reference
• Marketplace-Aufbau und CLI-Befehle (/plugin marketplace add etc): https://code.claude.com/docs/en/plugin-marketplaces

Stand der Verifikation: 2026-05-08. Wenn Du nach Plugin-Features suchst die hier nicht stehen, prüf beide Pages bevor Du Dich auf Drittquellen verlaesst.