devAlice
← AI Agents

Prompt-Templates — täglich wiederkehrende KI-Aufgaben wiederverwenden

Nicht jedes Mal neu briefen — Templates für Code-Review, Debugging, Refaktorierung, Tests, Dokumentation.

Nach einer Woche mit einem KI-Agenten wiederholen sich täglich dieselben Anfragen — „Review diesen Code", „Verfolge diesen Bug", „Schreibe Tests". Statt den Kontext jedes Mal neu zu formulieren, sparen wiederverwendbare Prompt-Templates Zeit, steigern die Konsistenz und verbessern die Ausgabequalität.

Dieser Leitfaden behandelt fünf täglich nützliche Templates (Code-Review, Debugging, Refaktorierung, Tests, Dokumentation) und erklärt, wie man sie am besten speichert und verwaltet.

TL;DR

  1. Template = Kontext + Aufgabe + Ausgabeformat + Einschränkungen
  2. Speicherung: ~/.prompts/ oder chezmoi-verwaltet
  3. Makro-Tools: Raycast Snippets, Cursor @docs, Claude Code Slash-Commands
  4. Vier Elemente eines guten Prompts: Rolle / Eingaben / Ausgabeformat / Verbote

1. Vier Elemente eines guten Prompts

Platzhalter als [...] dargestellt (um MDX/JSX-Konflikte zu vermeiden).

Du bist ein [Rolle].

Kontext: [Kontext]

Aufgabe: [Was zu tun ist]

Ausgabeformat: [Wie zu antworten]

Einschränkungen:

  • [Verbot 1]
  • [Verbot 2]

Vier klare Abschnitte helfen dem Modell, das Relevante vom Irrelevanten zu trennen.

2. Template 1 — Code-Review

Du bist ein erfahrener Code-Reviewer für [Sprache]-Projekte.

Kontext:

  • Zu reviewender Code: [Code einfügen oder @Datei]
  • Projektkonventionen: [Link oder relevanten Stil-Guide / .cursorrules einfügen]
  • Review-Fokus: [Korrektheit | Sicherheit | Performance | Lesbarkeit]

Aufgabe: Den Code reviewen. Identifizieren:

  1. Bugs oder Logikfehler (Schweregrad: kritisch / schwerwiegend / gering)
  2. Sicherheitsprobleme (Eingabevalidierung, Secrets, Auth)
  3. Performance-Bedenken (nur bei offensichtlichem O(n^2) oder Speicher)
  4. Stilabweichungen gegen Projektkonventionen
  5. Vorschläge zur Klarheit

Ausgabeformat: ZUSAMMENFASSUNG: [ein Absatz Gesamtbewertung] [KRITISCH] (Zeile N): [Problem] -> [Lösung] [SCHWERWIEGEND] ... [GERING] ... [STIL] ... [VORSCHLAG] ...

Einschränkungen:

  • Gesamte Datei nicht neu schreiben. Hinweisen und vorschlagen.
  • Stil nicht kleinlich kritisieren, wenn .cursorrules es nicht erzwingen.
  • Wenn auf einem Level keine Probleme gefunden wurden, diesen Abschnitt weglassen.

Verwendung

Cursor-Seiten-Chat — @code-review.md + @src/auth/login.ts + Fokus: Sicherheit anhängen.

Claude Code: Template unter .claude/commands/review.md speichern, dann per Slash-Command /review src/auth/login.ts aufrufen.

3. Template 2 — Bug-Debugging

Du bist ein Debugging-Assistent.

Kontext:

  • Fehlermeldung: [vollständigen Stacktrace einfügen]
  • Code wo er auftritt: [minimale Reproduktion oder @Datei einfügen]
  • Was ich versucht habe: [ausgeschlossene Hypothesen]
  • Erwartetes Verhalten: [was passieren sollte]

Aufgabe:

  1. Die wahrscheinlichste Grundursache identifizieren (nicht nur Symptome)
  2. Eine Lösung vorschlagen
  3. Einen Test zur Regressionsverhinderung vorschlagen

Ausgabeformat: GRUNDURSACHE: [ein Satz] ERKLÄRUNG: [2–3 Absätze warum] LÖSUNG: [gepatchter Code] REGRESSIONSTEST: [Testcode]

Einschränkungen:

  • Nicht raten. Wenn mehr Infos benötigt werden (Logs, ganze Datei), fragen.
  • Wenn 2+ Hypothesen gleich wahrscheinlich sind, beide mit unterscheidenden Signalen präsentieren.
  • Nicht nur „X versuchen" sagen — das Modell erklären.

Der Abschnitt „Was ich versucht habe" ist entscheidend — er verhindert, dass das Modell bereits ausgeschlossene Ansätze erneut vorschlägt.

4. Template 3 — Refaktorierung

Du bist ein Refaktorierungs-Assistent für [Sprache].

Kontext:

  • Aktueller Code: [einfügen oder @Datei]
  • Problem: [Lesbarkeit | Duplizierung | Testbarkeit | Performance]
  • Einschränkungen:
    • Öffentliche API muss erhalten bleiben
    • Bestehende Tests dürfen nicht brechen

Aufgabe: Refaktorieren unter Verhaltenserhaltung. Zeigen:

  1. Den refaktorisierten Code
  2. Diff vs. Original
  3. Abwägungen dieses Ansatzes vs. maximal 1 Alternative

Ausgabeformat: REFAKTORIERUNG: [neuer Code] DIFF:

  • Entfernt: [was]
  • Hinzugefügt: [was]
  • Umbenannt: [alt -> neu] ABWÄGUNG: [dieser Ansatz]: [Vor-/Nachteile] [Alternative]: [Vor-/Nachteile] EMPFEHLUNG: [welcher und warum]

Einschränkungen:

  • Verhalten nicht ändern. Wenn das Verhalten geändert werden sollte, separat markieren.
  • Testkompatibilität beibehalten — zeigen wie bestehende Tests noch bestehen.
  • Keine neuen Abhängigkeiten ohne explizite Anfrage einführen.

5. Template 4 — Tests schreiben

Du bist ein Test-Autor für [Sprache] (Vitest, Jest, Pytest usw.).

Kontext:

  • Zu testender Code: [einfügen oder @Datei]
  • Bestehender Test-Stil: [Beispieltest oder @Datei einfügen]
  • Abdeckungsfokus: [Happy Path | Grenzfälle | Fehlermodi | alle]

Aufgabe: Tests schreiben, die:

  1. Den Happy Path abdecken
  2. Mindestens 3 Grenzfälle abdecken (Grenzwerte, leere Eingabe, Fehlerfälle)
  3. Deterministisch sind (kein flüchtiges Zeit/Netzwerk ohne Mock)
  4. Dem bestehenden Test-Stil folgen

Ausgabeformat: eine einzelne Testdatei in [Sprache].

Einschränkungen:

  • Dieselbe Assertion-Bibliothek wie bestehende Tests verwenden
  • Externe Abhängigkeiten mocken (kein echtes Netzwerk/DB treffen)
  • Jeden Test fokussiert halten (ein Assertion-Thema pro Test)
  • Tests beschreibend benennen: „gibt X zurück wenn Y"
  • KEINE Tests schreiben, die nur die Implementierung spiegeln. Verhalten testen.

6. Template 5 — Dokumentation

Du bist ein technischer Redakteur.

Kontext:

  • Code: [einfügen oder @Datei]
  • Zielgruppe: [Einsteiger | Fortgeschrittene | Experten]
  • Dokumentationstyp: [README-Abschnitt | JSDoc | Tutorial | Referenz]

Aufgabe: Dokumentation schreiben, die:

  1. Den Zweck in 1 Satz angibt
  2. Ein minimales Verwendungsbeispiel zeigt
  3. Parameter/Rückgaben mit Typen auflistet
  4. Grenzfälle oder Fallstricke anmerkt (falls vorhanden)

Ausgabeformat: Markdown oder spezifisches JSDoc/TypeDoc-Format.

Einschränkungen:

  • Kein Füllmaterial. Direkt sein.
  • Code-Beispiele müssen ausführbar / einfügbar sein
  • Wenn die API komplex ist, auf tiefere Referenz verlinken statt alles dumpen
  • Für Bibliotheks-/Framework-Spezifika offizielle Terminologie bevorzugen

7. Speicherung / Verwaltung

Option A — Claude Code Slash-Commands

Templates in ~/.claude/commands/review.md speichern. In der CLI fügt /review src/foo.ts den System-Prompt automatisch ein.

Option B — Cursor @docs

Cursor → Einstellungen → Funktionen → Docs → Hinzufügen → URL/lokaler Pfad. Im Chat: @mein-review-template.

Option C — Raycast Snippets

Via mac/productivity's Raycast Snippets:

  • Snippet hinzufügen: vollständiges Template einfügen
  • Schlüsselwort: !review
  • In jedem Textfeld !review → expandiert

Option D — Einfaches Verzeichnis + Alias

Jedes Template als .md in ~/.prompts/ speichern. In .zshrc:

alias prompt='ls ~/.prompts'

prompt → Liste ausgeben → cat ~/.prompts/review.md | pbcopy → überall einfügen.

chezmoi-Integration

~/.prompts/ dem dotfiles-chezmoi-Baum hinzufügen — sofort auf jedem neuen Rechner verfügbar.

8. Template-Evolution

Das erste Template liegt bei ca. 70 % Qualität. Mit der Zeit verbessern:

  1. Ergebnisse oft zu lang → „Unter N Zeilen halten" oder „Nur den Diff ausgeben" hinzufügen
  2. KI driftet ständig → Einschränkungen verschärfen (konkrete Verbote)
  3. Kontext fehlt → explizite Eingabe-Slots ergänzen, z. B. „Was ich bereits versucht habe"
  4. Ausgaben inkonsistent → ein Beispiel im Ausgabeformat zeigen
  5. Zu konservativ → „Die beste Option empfehlen, nicht alle Optionen auflisten"

Einzeiliges Memo nach jeder Nutzung. Über ein Jahr hinweg codifizieren sich die Muster zu einem echten Asset.

9. Anti-Muster

Zu abstrakt

❌ „Sei ein guter Code-Reviewer." ✅ „Du bist ein erfahrener Reviewer. Bugs / Sicherheit / Stil identifizieren. Ausgabe in Format X."

Vages Ziel

❌ „Mach das besser." ✅ „Mach das lesbarer. Verhalten nicht ändern. Diff zeigen."

Ausgabeformat fehlt

Jedes Modell erzeugt eine andere Form; Vergleich/Automatisierung leidet.

Zu lang — „Versicherungs"-Einschränkungen

„Und auch X. Und vielleicht Y. Vergiss Z nicht." → Modell verliert Priorität. 3–5 Wesentliches behalten.

Immer Koreanisch

Koreanische Prompts auf einer englischen Codebase sind token-ineffizient. Wenn der Code-Kontext auf Englisch ist, erzeugen englische Prompts bessere Ergebnisse.

Überprüfung

  1. Denselben Code mit und ohne Template reviewen — Konsistenz / Vollständigkeit vergleichen
  2. chezmoi auf einem neuen Computer anwenden → ~/.prompts/ sofort verfügbar
  3. Raycast !review-Auslöser → expandiert überall
  4. Claude Code /review file.ts → gleiche Antwortform
  5. Nach einer Woche Nutzung ein Template pro Woche weiterentwickeln (einzeilige Notiz)

Fehlerbehebung

KI ignoriert das Template

  • Lange Templates lassen das Modell die Mitte der Anweisungen vergessen. Unter 200 Zeilen halten
  • Die wichtigste Einschränkung am Ende wiederholen (Recency Bias)
  • Cursor @docs kann Kontext komprimieren — das Wesentlichste extrahieren

Slash-Command funktioniert nicht

  • Claude Code: Dateiname/-ort unter ~/.claude/commands/foo.md
  • Cursor: Slash-Commands hängen vom Modell ab

Ausgabeformat bricht

Ein explizites Format-Beispiel zeigen. „Dieses genaue Format verwenden:" oder ähnlich starke Formulierung.

Antworten zu lang

„Maximal N Zeilen." oder „Nur der Diff, keine Erklärung."

Sprache gemischt

Sowohl Prompt- als auch Ausgabesprache angeben. „Auf Deutsch antworten." oder „Auf Englisch antworten."

Referenzen

Changelog

  • 2026-05-12: Erster Entwurf. Fünf Templates + vier Speicheroptionen + Evolution + fünf Anti-Muster + fünf Fehlerbehebungsfälle.