Wolkenkunde
← Blog
AI & Agents·22. August 2026·9 min Lesezeit

Skills und Agenten im Team teilen — mit einem eigenen Claude-Code-Marketplace

Jeder im Team baut sich seine eigenen Claude-Code-Skills und Subagenten — und niemand hat die der anderen. Copy-Paste per Slack ist keine Verteilung. Der saubere Weg ist ein Plugin-Marketplace: zwei kleine JSON-Dateien in einem Git-Repo, und über die eingecheckte .claude/settings.json sind Skills, Agenten, Slash-Commands, Hooks und MCP-Server bei allen automatisch bekannt und aktiv. Hands-on mit echtem JSON und offiziellen Quellen.

Kennst du das? Eine Kollegin hat einen richtig guten Claude-Code-Skill für eure Deploy-Checkliste gebaut. Ein Kollege hat einen Subagenten, der Pull Requests gegen euren Coding-Standard prüft. Und du selbst hast drei Slash-Commands, die keiner sonst kennt. Alles liegt lokal in irgendwelchen ~/.claude/-Ordnern — geteilt wird per Slack-Schnipsel, Copy-Paste und „schick mir mal deine SKILL.md”.

Das ist keine Verteilung, das ist Verfall. Sobald zwei Leute dieselbe Fähigkeit brauchen, driften die Kopien auseinander. Der saubere Weg ist der Claude-Code-Plugin-Marketplace: ein Git-Repo mit zwei kleinen JSON-Dateien, das Skills, Subagenten, Slash-Commands, Hooks und MCP-Server als Plugins bündelt — und über eine eingecheckte Settings-Datei bei allen im Team automatisch bekannt und aktiv ist. Dieser Beitrag zeigt die Notation und den Weg dorthin, mit echtem JSON.

Zuerst die zwei Begriffe sauber trennen

Fast alle Missverständnisse kommen daher, dass „Marketplace” und „Plugin” durcheinandergehen. Es sind zwei Ebenen:

  • Ein Plugin ist das Paket, das die eigentlichen Fähigkeiten enthält — ein oder mehrere Skills, Subagenten, Slash-Commands, Hooks, ein MCP-Server. Definiert durch .claude-plugin/plugin.json.
  • Ein Marketplace ist nur ein Katalog, der auf Plugins zeigt. Definiert durch .claude-plugin/marketplace.json. Er hostet die Plugins nicht zwingend selbst — er kann auf Unterverzeichnisse im selben Repo oder auf ganz andere Repos verweisen.
Marketplace (Katalog: marketplace.json)
  ├── Plugin A   → ./plugins/deploy-kit          (gleiches Repo)
  ├── Plugin B   → github: team/pr-reviewer      (anderes Repo)
  └── Plugin C   → git-URL: gitlab.com/…/mcp     (selbst gehostet)

Der Ablauf im Team ist entsprechend zweistufig: Man macht Claude Code einen Marketplace bekannt und installiert daraus Plugins. Beides lässt sich später automatisieren — dazu unten mehr.

Das Plugin: was es bündelt und wie es aufgebaut ist

Ein Plugin ist ein Verzeichnis mit einer festen Struktur. Die Komponenten liegen in konventionellen Ordnern, das Manifest im Unterordner .claude-plugin/:

deploy-kit/
├── .claude-plugin/
│   └── plugin.json          # das Manifest
├── skills/
│   └── deploy-checklist/
│       └── SKILL.md         # ein Skill
├── agents/
│   └── pr-reviewer.md       # ein Subagent
├── commands/
│   └── release.md           # ein Slash-Command
├── hooks/
│   └── hooks.json           # Hooks
└── .mcp.json                # ein MCP-Server

Wichtig: Die Komponenten-Ordner liegen im Plugin-Root, nicht in .claude-plugin/. In .claude-plugin/ gehört nur das Manifest.

Das Manifest ist erstaunlich schlank. Minimal reicht ein Name:

{
  "name": "deploy-kit"
}

Ohne weitere Angaben findet Claude Code die Standard-Ordner (skills/, agents/, commands/, hooks/, .mcp.json) automatisch. Ein realistisches Manifest ergänzt Metadaten und — falls nötig — abweichende Pfade:

{
  "name": "deploy-kit",
  "version": "1.2.0",
  "description": "Deploy-Checkliste, PR-Review-Agent und Release-Command",
  "author": { "name": "Platform Team", "email": "platform@example.com" },
  "homepage": "https://github.com/example/team-plugins",
  "keywords": ["deploy", "review", "alm"]
}

Die Komponenten selbst sind die vertrauten Bausteine, nur eben verpackt:

  • Skill — skills/deploy-checklist/SKILL.md mit Frontmatter name + description. Im Plugin bekommt er einen Namespace: /deploy-kit:deploy-checklist. 
    ---
name: deploy-checklist
description: Führt die Team-Deploy-Checkliste vor jedem Release durch
---

Prüfe vor dem Deploy: Migrationsskripte, Feature-Flags, Rollback-Plan …
  • Subagent — agents/pr-reviewer.md mit Frontmatter name, description und optional tools/model. 
    ---
name: pr-reviewer
description: Prüft Pull Requests gegen unseren Coding-Standard
tools: Read, Grep, Glob
---

Du bist ein PR-Reviewer. Achte auf Namenskonventionen, Testabdeckung …
  • Slash-Command — commands/release.md wird zu /release.
  • Hooks — hooks/hooks.json, z. B. ein PostToolUse-Hook, der nach jedem Edit ein Format-Skript startet.
  • MCP-Server — .mcp.json mit command/args (stdio) oder url (HTTP).

Für Pfade in Hooks und MCP-Konfiguration gibt es die Variable ${CLAUDE_PLUGIN_ROOT} — sie zeigt auf das Installationsverzeichnis des Plugins, egal wo es lokal landet. So bleiben Skript- und Server-Pfade portabel:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": "${CLAUDE_PLUGIN_ROOT}/scripts/format.sh" }
        ]
      }
    ]
  }
}

Der Marketplace: der Katalog, der auf die Plugins zeigt

Jetzt der Katalog. Er liegt als .claude-plugin/marketplace.json im Root des Marketplace-Repos. Minimal braucht er einen Namen, einen Owner und ein Plugin:

{
  "name": "wolkenkunde-tools",
  "owner": { "name": "Wolkenkunde Team" },
  "plugins": [
    { "name": "deploy-kit", "source": "./plugins/deploy-kit" }
  ]
}

Der name ist die Marketplace-ID — sie taucht später als @wolkenkunde-tools in den Install-Befehlen auf. Interessant wird das source-Feld je Plugin, denn hier entscheidet sich, wo ein Plugin liegt:

  • Relativer Pfad — das Plugin liegt im selben Repo: 
    { "name": "deploy-kit", "source": "./plugins/deploy-kit" }
  • GitHub-Repo — das Plugin liegt woanders: 
    {
  "name": "pr-reviewer",
  "source": { "source": "github", "repo": "example/pr-reviewer", "ref": "v2.0.0" }
}
  • Git-URL — für GitLab, Bitbucket oder selbst gehostet: 
    {
  "name": "secrets-mcp",
  "source": { "source": "url", "url": "https://gitlab.com/example/secrets-mcp.git", "ref": "main" }
}

Ein Marketplace kann also ein zentraler Einstiegspunkt sein, der Plugins aus verschiedenen Team-Repos zusammenführt — ohne alles in ein Monorepo zu zwingen. Das ist die eigentliche Stärke der Notation: ein Katalog, viele Quellen.

Der manuelle Weg — einmal, um es zu verstehen

Bevor wir es automatisieren, lohnt der Blick auf die zwei Handgriffe, die im Hintergrund passieren. Im Terminal macht man den Marketplace bekannt und installiert daraus:

/plugin marketplace add example/team-plugins
/plugin install deploy-kit@wolkenkunde-tools

/plugin marketplace add nimmt ein GitHub-owner/repo, eine Git-URL oder einen lokalen Pfad. /plugin install referenziert das Plugin dann als plugin-name@marketplace-name. Die reine UI-Variante — Marketplaces durchsehen, Plugins an-/abschalten — öffnet der Befehl /plugin.

Der echte Round-Trip im Terminal: zwei Befehle — Marketplace hinzufügen, Plugin installieren — und danach sind der deploy-checklist-Skill, der release-Command und der pr-reviewer-Subagent für alle im Team verfügbar. (Genau dieser Marketplace, wolkenkunde-tools, steckt hinter diesem Artikel.)

Gleich ausprobiert: der geteilte Agent findet echte Fehler

Genau das haben wir für diesen Beitrag gemacht — der Marketplace oben ist echt. Kaum war deploy-kit installiert, haben wir den mitgelieferten Subagenten pr-reviewer auf das frisch angelegte Marketplace-Repo selbst losgelassen: „Review die Manifeste und die README gegen unseren Standard.”

Und das war der eigentliche Beweis, worum es geht: Der Agent lief nicht nur, er fand zwei echte Ungenauigkeiten — beide in unserer eigenen README:

  • Ein Skill war dort wie ein Slash-Command annotiert (/deploy-kit:deploy-checklist), obwohl Plugin-Skills modell-invoziert über ihre description laufen.
  • Ein Command stand als /release statt korrekt namespaced als /deploy-kit:release.

Beides haben wir sofort korrigiert und committet. Das ist der Kern der ganzen Übung: Ein geteilter Agent bringt den Team-Standard mit — und wendet ihn an, ohne dass jemand die Regeln im Kopf haben muss. Nicht „schön, dass es installiert ist”, sondern sofort nützlich.

Das funktioniert — aber bis hierhin ist es Handarbeit: Jeder im Team müsste die beiden Befehle selbst ausführen, und neue Kolleginnen wissen gar nicht, dass es den Marketplace gibt. Genau das lösen wir jetzt.

Der eigentliche Punkt: automatisiert im Team ausrollen

Die beiden Handgriffe von oben lassen sich in die eingecheckte .claude/settings.json des Team-Repos schreiben. Dann ist der Marketplace bei jedem, der das Repo auscheckt, automatisch bekannt — und die gewünschten Plugins sind aktiv, ohne dass jemand einen Befehl tippt.

Zwei Felder tragen das:

  • extraKnownMarketplaces — macht Marketplaces bekannt (ersetzt das manuelle /plugin marketplace add).
  • enabledPlugins — aktiviert konkrete Plugins (ersetzt das manuelle /plugin install).
{
  "extraKnownMarketplaces": [
    {
      "name": "wolkenkunde-tools",
      "source": { "source": "github", "repo": "example/team-plugins" }
    }
  ],
  "enabledPlugins": {
    "deploy-kit@wolkenkunde-tools": true,
    "pr-reviewer@wolkenkunde-tools": true
  }
}

Der Schlüssel in enabledPlugins folgt dem Muster plugin-name@marketplace-name, der Wert ist true (aktiv) oder false. Weil diese Datei im Git liegt, gilt sie für alle im Repo: git pull, Claude Code starten — die Team-Skills und -Agenten sind da. Beim ersten Bekanntmachen einer neuen Marketplace-Quelle fragt Claude Code einmal nach Vertrauen (dazu gleich mehr); danach läuft es still.

Wichtig ist die Scope-Hierarchie der Settings, damit klar ist, was wo hingehört:

ScopeDateiFür wen
User~/.claude/settings.jsonnur du, alle Projekte
Project.claude/settings.jsonalle im Repo (eingecheckt)
Local.claude/settings.local.jsonnur du, dieses Projekt (gitignored)

Für den Team-Rollout ist Project die richtige Ebene: eingecheckt, versioniert, für alle gleich. Wer lokal noch ein privates Plugin dazunimmt, tut das in settings.local.json, ohne den Rest zu stören.

Ein sauberes Bündel: ein Plugin, das nur Abhängigkeiten hat

Sobald mehrere Plugins zusammengehören („alles, was ein Backend-Entwickler braucht”), muss nicht jeder jedes einzeln aktivieren. Ein Plugin kann Abhängigkeiten deklarieren und so als kuratiertes Bündel dienen:

{
  "name": "backend-standard",
  "version": "1.0.0",
  "description": "Standard-Set für Backend-Entwickler",
  "dependencies": [
    "deploy-kit",
    "pr-reviewer",
    { "name": "secrets-mcp", "version": "^1.0" }
  ]
}

Wer backend-standard aktiviert, bekommt die drei enthaltenen Plugins mit. Im Team-enabledPlugins steht dann nur noch eine Zeile statt vieler — und das Bündel wächst zentral, nicht in jeder Settings-Datei einzeln.

Versionierung und Governance — der ehrliche Teil

Ein paar Dinge, die man vor dem produktiven Einsatz wissen sollte:

  • Versionen kommen aus dem version-Feld (semver) in plugin.json bzw. dem Marketplace-Eintrag. Bei git-basierten Quellen kann man über ref (Branch/Tag) und optional einen exakten sha pinnen — das ist die verlässlichste Art, im Team auf einem definierten Stand zu bleiben. Ohne Pin zieht man den Default-Branch, also einen beweglichen Stand.
  • Updates prüft und zieht man über die /plugin-UI. Es gibt keinen Auto-Update-Zwang; ein gepinnter ref/sha bleibt stabil, bis ihr ihn bewusst anhebt.
  • Vertrauen: Ein Marketplace ist am Ende fremder Code, der bei euch Hooks, Commands und MCP-Server mitbringt. Beim ersten Hinzufügen fragt Claude Code nach. Für Organisationen gibt es zusätzlich zentrale Managed Settings (managed-settings.json), mit denen ein Admin erlaubte Marketplaces auf eine Allowlist beschränken kann — dann können Team-Mitglieder nur genehmigte Quellen hinzufügen.
  • Private Repos: Zeigt euer Marketplace auf ein privates Repo, braucht die lokale Git-Authentifizierung Zugriff (z. B. via gh auth setup-git oder ein Token im Git-Credential-Helper). Ohne Zugriff scheitert das Bekanntmachen still.

Und zwei ehrliche Einschränkungen: Die Plugin-Notation entwickelt sich schnell weiter — einige Quell-Typen und Felder (etwa npm- oder Archiv-Quellen, oder feinere Governance-Optionen) sind neu und je nach Claude-Code-Version unterschiedlich weit. Im Zweifel gilt die verlinkte Referenz, nicht dieser Artikel. Und: Ein Marketplace-Katalog selbst wird nicht wie ein Plugin versioniert — die Versionierung sitzt an den einzelnen Plugin-Quellen.

Der Weg in Kürze

  • Marketplace-Repo anlegen mit .claude-plugin/marketplace.json (name, owner, plugins[]).
  • Je Plugin ein Verzeichnis mit .claude-plugin/plugin.json und den Komponenten-Ordnern (skills/, agents/, commands/, hooks/, .mcp.json).
  • Pfade in Hooks/MCP über ${CLAUDE_PLUGIN_ROOT} portabel halten.
  • Im Team-Repo die eingecheckte .claude/settings.json mit extraKnownMarketplaces + enabledPlugins füllen.
  • Versionen über ref/sha pinnen; Updates bewusst über /plugin.
  • Für größere Organisationen Marketplaces per managed-settings.json auf eine Allowlist setzen.

Unterm Strich: Skills und Agenten im Team zu teilen ist kein Copy-Paste-Problem, sondern ein Verteilungsproblem — und das löst der Plugin-Marketplace sauber. Zwei JSON-Dateien in einem Git-Repo, zwei Felder in der eingecheckten Settings-Datei, und aus verstreuten Einzelkämpfer-Skripten wird eine gepflegte, versionierte Team-Werkbank, die bei jedem Checkout einfach da ist.

Stand: August 2026. Die Claude-Code-Plugin- und Marketplace-Notation wird laufend erweitert; Feldnamen und Quell-Typen können sich je nach Version unterscheiden — im Zweifel die verlinkte offizielle Referenz prüfen.

Offizielle Quellen

Siehe auch