KIberblick
Inhaltsverzeichnis

Workflow

Vom Prompt zum Skill: besser als Copy-Paste

Die Geschichte eines Prompts der immer wieder angepasst wird, bis ein eigener Skill daraus entsteht. Praktische Anleitung mit dem skill-creator.

24. März 20268 Min. Lesezeit

Es fängt immer mit einem guten Prompt an

Du kennst das: Du schreibst einen Prompt, testest ihn, passt ihn an, testest wieder. Nach ein paar Wochen hast du etwas das wirklich funktioniert. In diesem Fall geht es um Code Reviews. Dein Team arbeitet mit Vue 3 und TypeScript, ihr committed auf Deutsch und schreibt Tests mit Vitest. Du hast einen Prompt gebaut, der all das berücksichtigt.

PromptClaude Code · Code Review Prompt

Prüfe den folgenden Code auf unsere Team-Konventionen:

  1. TypeScript strict mode: Keine any-Types, alle Funktionen typisiert, Interfaces statt Types wo möglich
  2. Vue Composition API: Kein Options API, script setup bevorzugt, Composables für geteilte Logik
  3. Tests: Jede exportierte Funktion braucht mindestens einen Vitest-Test, describe/it Blöcke auf Deutsch
  4. Commit-Messages: Deutsch, format "type(scope): beschreibung"
  5. Error Handling: Keine stillen catch-Blöcke, Fehler loggen oder weiterwerfen

Gib für jeden Fund an:

  • Severity: blocker / warning / hint
  • Datei und Zeile
  • Was falsch ist und warum
  • Konkreter Vorschlag zur Behebung

Am Ende eine Zusammenfassung: Anzahl Blocker, Warnings, Hints. Gesamtbewertung ob der PR mergebar ist.

Dieser Prompt funktioniert. Er findet die richtigen Probleme, gibt strukturiertes Feedback, und dein Team bekommt konsistente Reviews. Du bist zufrieden.

Dann teilst du ihn

Du postest den Prompt in euren Slack-Kanal. "Hey Leute, nutzt den hier für Code Reviews, funktioniert super." Zwei Wochen später sieht die Realität anders aus.

Lisa hat eine ältere Version aus dem Slack-Verlauf kopiert. Die ohne den Security-Check den du letzte Woche ergänzt hast. Markus hat "seinen eigenen Touch" drangehängt und das Ausgabeformat geändert, jetzt bekommt er Bullet Points statt strukturierte Severity-Level. Das neue Teammitglied, seit Montag dabei, hat den Prompt nie gesehen weil er in einer Nachricht von vor drei Wochen begraben liegt. Und du selbst hast mittlerweile drei Versionen in verschiedenen Notizen, eine in Apple Notes, eine in Notion, eine im Slack-Thread.

Das Ergebnis: Lisa bekommt ein Review das den offensichtlichen SQL-Injection-Vektor übersieht.

Chat mit Claude Code
DU

Prüfe den folgenden Code auf unsere Team-Konventionen:

  1. TypeScript strict mode: Keine any-Types
  2. Vue Composition API: script setup bevorzugt
  3. Tests: Vitest-Tests vorhanden

Gib Feedback als Liste.

CLAUDE CODE

Hier mein Feedback:

  • fetchUser nutzt any als Rückgabetyp, sollte typisiert werden
  • Die Komponente nutzt script setup, passt
  • Keine Tests gefunden, bitte ergänzen
  • Insgesamt: Code sieht gut aus, kleinere Verbesserungen nötig

Vergleich das mit dem vollständigen Review weiter oben. Kein Severity-Level, keine Zeilen-Referenzen, keine Gesamtbewertung, kein Security-Check. Derselbe Prompt in einer abgespeckten Version liefert ein deutlich oberflächlicheres Ergebnis.

Die Erkenntnis kommt schleichend

Irgendwann merkst du: Dieser Prompt ist eigentlich kein Prompt. Er ist eine Arbeitsanweisung. Eine Checkliste. Ein Standard. Und Standards gehören nicht in Slack-Nachrichten. Standards gehören versioniert, an einem Ort, zugänglich für alle. Sie gehören ins Repo.

Genau dafür gibt es Skills. Ein Skill ist eine Markdown-Datei mit Anweisungen, die Claude automatisch lädt wenn sie relevant sind. Der Skill lebt im Repo, wird mit Git versioniert und steht dem ganzen Team zur Verfügung. Keine Slack-Suche, keine veralteten Kopien, kein "Hast du die neue Version?"

Vom Prompt zum Skill mit dem skill-creator

Anthropic hat einen Skill gebaut, der dir hilft andere Skills zu erstellen: den skill-creator. Du installierst ihn einmal:

PromptTerminal · skill-creator installieren

npx skills add https://github.com/anthropics/skills --skill skill-creator

Danach beschreibst du Claude einfach, was dein Skill können soll. Claude stellt dir Rückfragen zu Edge Cases, Formaten und Erfolgskriterien und erstellt dann die SKILL.md.

Chat mit Claude Code
DU

/skill-creator Erstelle einen Skill der bei Code-Reviews unsere Team-Konventionen prüft. Wir nutzen TypeScript strict mode, bevorzugen Composition API bei Vue, schreiben Tests mit Vitest und committen auf Deutsch. Der Review soll auf diese Punkte prüfen und ein strukturiertes Feedback geben mit Severity (blocker, warning, hint).

CLAUDE CODE

Ich erstelle den Code Review Skill für euer Team. Zuerst ein paar Rückfragen:

  1. Soll der Skill automatisch bei "review", "pr" und "code review" Anfragen aktiv werden?
  2. Gibt es ein Minimum an Testabdeckung das ihr erwartet?
  3. Soll der Skill auch auf Accessibility und Performance prüfen?

Basierend auf deiner Beschreibung erstelle ich folgende Struktur:

.claude/skills/team-code-review/
  SKILL.md

Die SKILL.md enthält:

  • Frontmatter mit Name, Beschreibung und wann der Skill triggern soll
  • Prüfkriterien für TypeScript, Vue, Tests und Commit-Messages
  • Ausgabeformat mit Severity-Leveln und Zusammenfassung
  • Kontext zu euren spezifischen Konventionen

Der Skill wird automatisch aktiv wenn jemand im Team "review diesen Code" oder "/team-code-review" eingibt. Soll ich die Datei erstellen?

Nach wenigen Minuten liegt die fertige SKILL.md im Repo. Du committed sie, und ab sofort hat jeder im Team denselben Standard.

Das Ergebnis: Konsistenz ohne Aufwand

Jetzt nutzt Lisa denselben Skill. Automatisch, ohne Slack-Suche, ohne Copy-Paste.

Chat mit Claude Code
DU

Review bitte den letzten Commit in feature/user-dashboard.

CLAUDE CODE

Code Review: feature/user-dashboard (3 Dateien)

Blocker (1)

  • src/api/users.ts:24 Kein Error Handling im catch-Block. Die Funktion fängt den Fehler ab, loggt ihn aber nicht und gibt undefined zurück. Das verursacht stille Fehler im Frontend. Vorschlag: throw new ApiError('User fetch failed', { cause: error })

Warning (2)

  • src/components/UserCard.vue:8 Prop "userData" ist als any typisiert. Nutze das bestehende Interface UserProfile aus types/user.ts.
  • src/composables/useDashboard.ts:31 Fehlender Test für calculateStats(). Die Funktion ist exportiert und sollte einen Vitest-Test haben.

Hint (1)

  • src/components/UserCard.vue:1 Die Komponente nutzt Composition API, aber die computed Property könnte als Composable extrahiert werden, da sie auch in AdminPanel.vue vorkommt.

Zusammenfassung: 1 Blocker, 2 Warnings, 1 Hint. PR ist nach Behebung des Blockers mergebar.

Jedes Teammitglied bekommt jetzt dasselbe strukturierte Feedback. Mit Severity-Leveln, mit Zeilen-Referenzen, mit konkreten Vorschlägen. Nicht weil alle denselben Prompt aus Slack kopiert haben, sondern weil der Standard im Repo liegt und Claude ihn automatisch nutzt.

Die Vorteile liegen auf der Hand: Alle im Team haben dieselbe Version weil der Skill Git-versioniert ist. Änderungen am Standard sind ein Commit, und alle haben es sofort. Neue Teammitglieder bekommen den Standard automatisch wenn sie das Repo klonen. Und der Skill kann getestet und iteriert werden wie Code, inklusive Evaluations über den skill-creator.

Das Prinzip funktioniert überall

Code Reviews sind nur ein Beispiel. Das gleiche Muster funktioniert für alles, was du immer wieder gleich machen willst:

Sprint-Retrospektiven immer im gleichen Format, mit denselben Kategorien, und Claude sammelt die Punkte automatisch aus euren Tickets. Release Notes die automatisch das Changelog-Format eurer Firma nutzen, mit den richtigen Abschnitten und der richtigen Tonalität. Onboarding-Checklisten für neue Projekte, damit kein Setup-Schritt vergessen wird. Bug-Report-Templates die alle relevanten Infos abfragen: Reproduktionsschritte, erwartetes Verhalten, tatsächliches Verhalten, Environment.

In jedem Fall ist der Ablauf derselbe: Du hast einen Prompt der funktioniert, du merkst dass andere ihn auch brauchen, du machst einen Skill daraus.

Die Dreier-Regel

Wenn du einen Prompt öfter als dreimal anpasst und teilst, mach einen Skill daraus. Der Aufwand ist minimal, zehn Minuten mit dem skill-creator. Der Nutzen ist enorm: konsistente Qualität, automatische Versionierung, kein Onboarding-Aufwand für neue Teammitglieder.

Der Weg vom Copy-Paste-Prompt zum eigenen Skill ist kein großes Refactoring-Projekt. Es ist ein kleiner Schritt, der einen überraschend großen Unterschied macht.

Wusstest du eigentlich: Du kannst Claude auch bitten, bestehende Skills zu verbessern. Wenn dir auffällt, dass der Review-Skill ein bestimmtes Pattern übersieht oder die Severity-Stufen zu grob sind, sagst du einfach "Schau dir den Review-Skill an, er übersieht async/await Fehler in Error-Handlern. Ergänze das." Claude liest die SKILL.md, versteht die Struktur und passt sie an. Skills sind lebende Dokumente, kein einmal-und-fertig.

Weiterführend: