Prompts — wiederverwendbare Templates

Prompts sind die dritte Säule: parametrisierte Texte, die ein Server anbietet. Sie sind nutzergetriggert (oft als Slash-Command in der Chat-UI), nicht modellgetriggert wie Tools.

Kurzfassung: Der Server pflegt eine Bibliothek von Prompt-Templates mit benannten Argumenten. Der Client zeigt sie z.B. als „/review-pr“ in der Slash-Command-Liste. Beim Aufruf fragt der Client die Argumente ab, schickt sie an den Server, und der Server liefert den fertigen Prompt-Text zurück — der dann ins LLM geht.

Template-Player

Wähl ein Template, fülle die Argumente aus, sieh das Ergebnis live.

Strukturierter Pull-Request-Review nach Hausstandards. Server liefert vorgefertigte Sektionen.
📤 Ergebnis (geht ins LLM)Pflichtfelder noch leer
Du bist Senior-Reviewer für das Repo .

Review PR #. Strukturiere die Antwort wie folgt:
1. KORREKTHEIT — Bugs, Edge-Cases
2. STRUKTUR — Layering, Naming
3. TESTS — Coverage, Edge-Cases abgedeckt?
4. STIL — Konsistenz mit Codebase

Fokus diesmal: 

Sei direkt, lobe nicht reflexartig.

Drei Lebenszyklus-Stufen

  • prompts/list — der Client fragt zu Beginn nach allen verfügbaren Templates. Der Server liefert Name, Beschreibung und Argument-Schema.
  • prompts/get — der Client fragt nach dem fertigen Prompt mit konkreten Argumenten. Der Server rendert das Template und gibt eine Message-Liste zurück (mit Rollen: user/assistant).
  • Senden — das LLM bekommt diese Messages als Konversation und antwortet. Der Server ist danach raus.
Warum eigentlich?Warum auf dem Server, nicht in der Chat-Anwendung?
Weil der Server die Hausstandards kennt: das Postgres-Server-Team weiß am besten, wie ein guter Query-Review-Prompt für ihr Datenmodell aussieht. Statt jeden Chat-Client zu zwingen, all diese Prompts nachzubauen, pflegt der Server sie — ein zentraler Ort, alle Clients profitieren. Faktor: Wenn das Team den Prompt verbessert, müssen die Clients nichts updaten.
Häufiger DenkfehlerPrompts ≠ Tools mit Text als Argument
Klar, technisch könntest du einen review_pr-Tool bauen, das einen vorgefertigten Prompt zurückgibt — und das Modell ruft es auf. Aber: Prompts sind nutzer-initiiert. Der Nutzer tippt /review-pr 23 und weiß explizit, welche Aktion folgt. Ein Tool-Aufruf passiert dagegen mitten in einer LLM-Antwort, oft ohne dass der Nutzer es aktiv anfordert — anderes UX-Vertrauensmodell.
Tiefer reinMulti-Message-Prompts
Ein Prompt kann mehrere Messages zurückgeben — z.B. eine simulierte Konversation (system → user → assistant → user) als Few-Shot-Beispiel. Auch Resources einbetten ist möglich: ein Prompt-Result kann einen resource-Block enthalten mit URI; der Client liest die Resource und hängt sie der Konversation an. So baut man z.B. einen Prompt „Reviewe die Datei X“ ohne dass der Nutzer die Datei manuell anhängen muss.