Claude Code Prompt-Bibliothek pflegen: Team-Prompts als Assets

Gute Prompts gehören nicht nur in den Chatverlauf

Teams starten mit Claude Code oft sehr pragmatisch. Ein guter Prompt liegt in Slack, einer in einem Pull-Request-Kommentar, einer in privaten Notizen und einer in Notion. Kurzfristig ist das schnell. Nach einigen Wochen gibt es fünf Varianten, niemand kennt die freigegebene Version, und jede Review beginnt wieder von vorn.

Eine Prompt-Bibliothek ist keine Sammlung schöner Sätze. Sie ist ein Betriebs-Asset. Sie braucht Versionierung, Owner, Review-Gates, Deprecation-Regeln und Metriken. Die offizielle Claude Code Prompt library liefert Muster; ein Team muss diese Muster aber mit eigenem Repository, Produktseiten, Preisen, CTA-Flows und Training verbinden. Ergänzend sind die offiziellen Seiten zu CLAUDE.md und memory, Skills, Subagents und Hooks wichtig.

Dieser Artikel baut auf der Claude Code Review-Checkliste und der 30-Minuten-Checkliste auf. Er richtet sich an Teams, die wiederverwendbare Prompts nicht nur für interne Effizienz, sondern auch für Produkte, bezahlte Templates und Training nutzen wollen.

Erst ein Register, dann Feinschliff

Versionierung bedeutet, Änderungen am Prompt nachvollziehen zu können. Owner bedeutet, dass eine Person oder Funktion verantwortlich ist. Review-Gate bedeutet, dass ein Prompt vor dem aktiven Einsatz eine Prüfung besteht. Deprecation bedeutet, alte Versionen mit Ersatzpfad auslaufen zu lassen. Metriken zeigen, ob der Prompt Risiko senkt, Conversion verbessert oder Zeit spart.

Speichere den Einstieg als prompt-library.json.

[
  {
    "id": "review-risk-finder",
    "version": "1.2.0",
    "owner": "platform",
    "status": "active",
    "useWhen": "A pull request changes behavior, data flow, pricing, or CTA routing.",
    "inputs": ["goal", "diff", "riskAreas", "expectedTests"],
    "output": "Findings ordered by severity with evidence and smallest fix.",
    "reviewGate": "Owner approval plus one successful run on a known risky diff.",
    "deprecates": ["review-risk-finder@1.1.0"],
    "metrics": ["reuse_count", "accepted_findings", "false_positive_rate"],
    "officialDocs": [
      "https://code.claude.com/docs/en/prompt-library",
      "https://code.claude.com/docs/en/memory"
    ]
  }
]

Das Register macht den Prompt nicht automatisch besser. Es macht ihn steuerbar. Wenn die Ausgabe zu viel Rauschen erzeugt, gibt es einen Owner. Wenn eine Produktseite geändert wird, kann das Team entscheiden, ob der CTA-Review-Prompt eine Minor-Version braucht. Wenn der Prompt in einem Workshop genutzt wird, ist klar, welche aktive Version gilt.

Ein Template, ein Ergebnis

Der teure Fehler ist ein All-in-one-Prompt: Review, Tests, Dokumentation, Refactor und CTA-Verbesserung in einer Anfrage. Das klingt effizient, mischt aber Verantwortlichkeiten und macht Fehler schwer analysierbar. In einer Team-Bibliothek sollte ein Prompt ein klares Artefakt liefern.

# review-risk-finder

You are reviewing a production change for business and user risk.

Context:
- Goal: {{goal}}
- Diff or changed files: {{diff}}
- Risk areas: {{riskAreas}}
- Expected tests: {{expectedTests}}

Return findings first. For each finding include:
1. Severity
2. Evidence from the diff
3. User or revenue impact
4. Smallest safe fix
5. Verification command

If there are no findings, list what you checked and what remains unverified.

Das Format sagt Claude Code, was als Risiko zählt und welche Belege zurückgegeben werden müssen. Engineering bewertet den Verifikationsbefehl. Product bewertet den Umsatzimpact. Training kann denselben Aufbau als Übung verwenden.

Use case: drei kommerzielle Workflows

Use case 1 ist Pull-Request-Review. Statt “schau mal drüber” bekommt Claude Code Ziel, Diff, erwartete Tests und Risikobereiche wie Billing, Auth, Rechte, Datenlöschung oder CTA-Routing. Die Ausgabe wird dadurch handlungsfähig.

Use case 2 ist Produktseitenpflege. Für products prüft der Prompt Nutzenversprechen, Zielgruppe, Kauferwartung, Preisformulierung, Beweise und Links. Der Owner ist hier oft Product oder Marketing, nicht nur Engineering.

Use case 3 ist Training und Beratung. Für training sollte der Prompt Team-Schmerz, aktuellen Reifegrad, Einführungsrisiken und Workshop-Artefakte abfragen. Die Metrik ist nicht nur Traffic, sondern qualifizierte Anfragen und weniger wiederholte Onboarding-Fragen.

Use case 4 ist Artikelpflege. Veröffentlichte Artikel altern, wenn offizielle Docs, Commands, interne Links oder Beispiele sich ändern. Ein Refresh-Prompt prüft official links, updatedDate, ausführbare Beispiele, Bilder und die Erfahrungssektion.

Gates vor dem Status active

Drei Statuswerte reichen: draft, active, deprecated. Draft wird getestet. Active darf in Dokumentation, Produkte und Training. Deprecated bleibt mit Migrationshinweis sichtbar.

Semantische Versionierung reicht in einfacher Form. Eine brechende Änderung am Ausgabeformat erhöht major. Ein neuer Input erhöht minor. Formulierungen und Beispiele sind patch. Ziel ist nicht Bürokratie, sondern Verlässlichkeit.

flowchart LR
  Draft["draft prompt"] --> Owner["owner review"]
  Owner --> Gate["known-risk gate"]
  Gate --> Active["active library"]
  Active --> Metrics["monthly metrics"]
  Metrics --> Deprecate["deprecate or improve"]

Das known-risk gate ist der wichtigste Realitätscheck. Bewahre pro wichtigem Prompt einen echten Fehlschlag auf: ein verpasster Risk-Diff, ein kaputter Checkout-CTA, ein Build-Log mit verstecktem ersten Fehler oder ein Artikel mit alter offizieller URL. Wenn der Prompt diesen Fall nicht schafft, ist er nicht active.

Agents nur mit engem Auftrag

Ein Agent ist nützlich, wenn die Aufgabe eng ist und das Ergebnis klar zusammengefasst werden kann. Offizielle Subagents arbeiten in eigenem Kontext; genau deshalb muss die Delegation präzise sein. Für eine Prompt-Bibliothek helfen drei Rollen: librarian für Metadaten, reviewer für Testausgaben, owner für Freigabe.

Beispiel für .claude/agents/prompt-librarian.md:

---
name: prompt-librarian
description: Maintains prompt library metadata, ownership, versions, metrics, and deprecation notes.
tools: Read, Grep
---

You audit prompt library entries. Do not rewrite product copy.
Check that each prompt has id, version, owner, status, useWhen, inputs, output,
reviewGate, deprecation note, and metrics. Report missing fields first.

Dieser Agent sollte lesen und prüfen, nicht heimlich Produkttexte ändern. Regeln, die wirklich blockieren sollen, gehören in Hooks, Berechtigungen oder CI. Prompts geben Urteilsrahmen; Gates erzwingen Prozesse.

Pitfall: typische Verfallsstellen

Pitfall 1 sind vage Namen. good-review, debug-helper und marketing-check findet nach einem Monat niemand mehr. Besser sind Namen wie checkout-cta-risk-review, build-log-first-failure oder training-page-objection-check.

Pitfall 2 ist das Speichern nur erfolgreicher Beispiele. Erfolg zeigt nicht die Grenze des Prompts. Halte mindestens einen Fehlschlag fest: “alten Preislink übersehen” oder “nur Testnamen gelesen, nicht Implementierung”.

Pitfall 3 ist alles in CLAUDE.md zu packen. CLAUDE.md ist wertvoller Kontext, aber keine harte Policy. Blockierende Regeln gehören in Hooks, Berechtigungen oder CI.

Pitfall 4 ist der CTA als Nachtrag. Wenn Produkte und Training erst am Ende angeklebt werden, wirkt es wie Werbung. Plane den Pfad vorher: kostenlos lernen, Template kaufen, Team-Governance im Training einführen.

Kleines Audit-Skript

Ab mehr als zehn Einträgen sollte das Minimum automatisiert werden.

import fs from "node:fs";

const file = process.argv[2] ?? "prompt-library.json";
const entries = JSON.parse(fs.readFileSync(file, "utf8"));
const required = [
  "id",
  "version",
  "owner",
  "status",
  "useWhen",
  "inputs",
  "output",
  "reviewGate",
  "metrics"
];

let failed = false;
for (const entry of entries) {
  const missing = required.filter((key) => !entry[key]);
  if (!/^\\d+\\.\\d+\\.\\d+$/.test(entry.version ?? "")) {
    missing.push("version must be semver");
  }
  if (!["draft", "active", "deprecated"].includes(entry.status)) {
    missing.push("status must be draft, active, or deprecated");
  }
  if (missing.length > 0) {
    failed = true;
    console.error(`${entry.id ?? "(missing id)"}: ${missing.join(", ")}`);
  }
}

if (failed) process.exit(1);
console.log(`OK: ${entries.length} prompt entries checked`);

Das Skript bewertet nicht den Stil. Es verhindert aber, dass ownerlose oder ungeprüfte Prompts in bezahlte Materialien gelangen.

Wenige Metriken, klare Entscheidungen

Metrik	Warum	Aktion
reuse_count	Wird der Prompt gefunden?	Umbenennen oder verschieben
accepted_findings	Führt er zu echten Fixes?	Ausgabeformat schärfen
false_positive_rate	Kostet er Review-Zeit?	riskAreas konkretisieren
time_to_fix_minutes	Wird der Fix kleiner?	smallest safe fix verlangen
cta_click_rate	Hilft er Produkt oder Training?	CTA-Kontext überarbeiten

Ein monatlicher Blick reicht. Wenn ein Prompt nicht genutzt, nicht vertraut oder nicht entscheidungsrelevant ist, sollte er deprecated werden.

Produkte und Training verbinden

Eine gepflegte Bibliothek schafft eine klare Umsatzleiter. Kostenlose Artikel erklären das Denken. ClaudeCodeLab products liefern Templates für Einzelne. Claude Code training and consultation hilft Teams, Owner, Gates, Hooks, Metriken und Rollout-Material im echten Repository zu verankern.

Masa startete mit über dreißig Prompts. Das fühlte sich vollständig an, war aber langsamer. Die bessere Struktur waren vier Kategorien: review, debug, product page und training page, mit höchstens drei aktiven Prompts pro Kategorie. Besonders die gespeicherten Fehlschläge machten jede neue Version besser.