Prompt Templates

Prompt Templates für wiederkehrende Aufgaben

0:00 Nach den Skills kommt der kleine, unaufwendige Bruder: die Prompt-Vorlage. Der beste Prompt ist der, den Sie nicht wieder erfinden müssen — und genau darum geht es hier. Eine Vorlage ist eine Markdown-Datei, die zu einem vollständigen Prompt expandiert, aufgerufen mit einem Schrägstrich-Kommando. Kein Code, keine Rechte, kein Risiko.

0:20 In diesem Modul lernen Sie, wie man aus dem eigenen Verlauf Vorlagen destilliert, wie man sie parametrisiert und wie sie sich zu Skills und Projektanweisungen abgrenzen. Es ist das Modul mit dem besten Verhältnis von Aufwand zu Wirkung.

Formulierungen festhalten

0:34 Acht Kapitel, und der entlastende Hinweis vorweg: Templates sind Text. Sie enthalten keinen ausführbaren Code, sie brauchen keine Rechte, und wenn eine Vorlage schlecht ist, merken Sie es sofort und ändern eine Zeile. Das macht dieses Modul zum idealen Einstieg für Teams, die bei Erweiterungen zögern. Wir gehen von der Sammlung eigener Prompts über die Vorlagen für Review, Refactoring und Fehlersuche bis zur Parametrisierung — und klären am Ende die Rollenverteilung zwischen den drei Bausteinen, die wir jetzt kennen.

1:03 Vier Punkte. Erstens der Mechanismus: Markdown-Schnipsel, die ein Schrägstrich-Kommando zu einem Prompt ausbaut — der Dateiname ist das Kommando. Zweitens die Parameter, mit denen aus einer Vorlage ein Formular wird; die Syntax ist an die Shell angelehnt und schnell gelernt. Drittens die Fundorte, die denselben Ebenen folgen wie bei Skills.

1:23 Und viertens das Zusammenspiel mit Projektanweisungen und Skills — denn die häufigste Reibung entsteht dort, wo dieselbe Information an zwei Orten steht.

Wiederkehrende Prompts systematisieren

1:33 Beginnen wir mit dem Rohmaterial. Sie müssen keine Vorlagen erfinden — Sie haben sie schon geschrieben. Sie stehen in Ihrem Verlauf der letzten Woche. Systematisieren heißt: die Prompts, die Sie ohnehin ständig tippen, sammeln, auf das gemeinsame Muster reduzieren und als Vorlage ablegen. Pi expandiert sie über ein Schrägstrich-Kommando; der Dateiname ohne Endung ist der Kommandoname. Das Bild dazu: der Textbaustein in der E-Mail-Software.

2:00 Niemand formuliert die Terminbestätigung jeden Tag neu — man passt zwei Angaben an und schickt sie ab. Und genau wie dort steckt der Wert nicht in der Technik, sondern in der einmal sorgfältig gewählten Formulierung. Vier Gründe. Die Qualität Ihrer Formulierungen wird reproduzierbar statt tagesformabhängig — das ist mehr wert, als es klingt, denn am Freitagnachmittag formuliert niemand präzise.

2:24 Gute Prompts enthalten immer dieselben Teile: Auftrag, Grenze, Nachweis; eine Vorlage erzwingt diese Struktur ganz nebenbei. Templates sind reiner Text und brauchen keine Rechte. Und das Teilen im Team geht über das Repository oder ein Paket — Ihre gute Formulierung wird zum Teamstandard, ohne dass jemand sie abtippen muss.

2:45 Der rote Faden: sammeln, erkennen, verallgemeinern, parametrisieren, erproben. Sie sichten zehn eigene Prompts der letzten Woche — nicht ausgedachte, echte. Dann markieren Sie die wiederkehrenden Muster: Review, Bugfix, Migration. Beim Verallgemeinern stellen Sie die entscheidende Frage: Was ist fix, was ist variabel? Das Variable wird zum Parameter. Und dann legen Sie die Datei ab und probieren das Kommando aus.

3:12 Die Fußnote nennt die richtige Haltung: Ein Template lebt von Korrekturen — wie eine Testsuite.

Prompt Templates erstellen

3:19 Jetzt die Mechanik. Sie ist in zwei Minuten erklärt, und es gibt genau ein Detail, das man wissen muss, weil es sonst für Verwirrung sorgt. Ein Template ist laut Dokumentation ein Markdown-Schnipsel, das zu einem vollständigen Prompt expandiert. Optionale Kopfdaten liefern eine Beschreibung und einen Hinweis auf die erwarteten Argumente; fehlt die Beschreibung, dient die erste nichtleere Zeile als solche.

3:43 Und der Dateiname wird zum Kommando: Aus einer Datei namens „review" wird der Aufruf mit Schrägstrich und diesem Namen. Damit ist der gesamte Mechanismus beschrieben. Alles Weitere ist Inhalt — und der ist Ihre Sache. Die Fundorte kennen Sie im Prinzip schon: das persönliche Verzeichnis, der Projektordner nach vergebenem Vertrauen.

4:03 Dazu Pakete, eine Liste in den Einstellungen und eine wiederholbare Startoption für einzelne Dateien. Es gibt außerdem einen Schalter, der die Erkennung ganz abschaltet — nützlich, wenn Sie in einem fremden Projekt keine mitgelieferten Vorlagen wollen. Und jetzt das Detail, das ich meinte: Die Erkennung im Vorlagenordner ist nicht rekursiv. Halten Sie ihn flach, sonst suchen Sie lange nach einem Kommando, das nie erscheint.

4:29 Worauf es hier ankommt, sind drei Dinge. Die Kopfdaten mit Beschreibung und Argumenthinweis — der Hinweis erscheint in der Autovervollständigung und erklärt die Bedienung. Dann der Parameter mit Rückfallwert: Wird kein Argument übergeben, greift der Standardfokus. Und schließlich der Inhalt selbst, der die Struktur aus Modul fünf abbildet: Auftrag, Belegform, Grenze — hier ausdrücklich „nur berichten, nichts ändern".

4:55 Diese eine Grenze macht aus einer Bitte eine verlässliche Vorlage. Aufrufbar ist sie mit und ohne Argument. Diese Übung dauert fünf Minuten und bleibt. Sie überführen einen häufig genutzten Prompt in ein parametrisiertes Template und legen es im Projekt ab. Das Erfolgskriterium hat zwei Teile: aufrufbar mit Argument und ohne. Der zweite Teil ist der interessantere, denn er zwingt Sie zu einem sinnvollen Rückfallwert.

5:20 Und ein sinnvoller Rückfallwert ist genau das, was aus einem Textbaustein ein Werkzeug macht — Sie können es benutzen, ohne über Parameter nachzudenken.

Templates für Code Reviews einsetzen

5:29 Jetzt der häufigste Einsatzfall überhaupt: das Review-Template. Wenn Sie nur eine Vorlage schreiben, schreiben Sie diese — weil sie bei jedem Merge Request Wirkung zeigt. Ein Review-Template legt drei Dinge fest: die Prüfkriterien, den Umfang und die Form der Funde — Datei, Zeile, Begründung. Und es legt fest, was ausdrücklich nicht geprüft wird.

5:51 Der Vergleich: die Checkliste bei der Fahrzeuginspektion. Nicht jeder Prüfer schaut auf andere Dinge, und am Ende steht ein vergleichbarer Bericht. Dass darin nicht alles steht, was man prüfen könnte, ist Absicht — sonst wäre der Bericht unbrauchbar lang. Gleiche Kriterien machen Reviews vergleichbar; erst dadurch merken Sie, ob Codequalität sich über Wochen verbessert.

6:14 Der Prüfumfang bleibt begrenzt statt beliebig — ein Review über „alles" liefert Allgemeinplätze. Die Belegpflicht verhindert genau diese Allgemeinplätze. Und der vierte Punkt schließt an Modul drei an: Der Lesemodus mit vier Werkzeugen passt hier ideal. Ein Review-Lauf, der technisch nichts ändern kann, ist auch in einem fremden Repository unbedenklich.

6:36 Das Prinzip dieser vier Bausteine ist Eingrenzung. Der Umfang sagt, worüber geredet wird — „nur die gestagten Änderungen" ist präziser als „der Code". Die Kriterien sagen, worauf geschaut wird. Die Belegform sorgt dafür, dass Sie jeden Fund nachschlagen können. Und der Ausschluss ist der Baustein, den die meisten vergessen: „kein Stil, kein Refactoring" hält den Bericht kurz und verhindert die endlose Liste von Verbesserungsvorschlägen.

7:03 Die Fußnote gibt die Regel: ein Template je Zweck, nicht ein Universal-Review.

Templates für Refactoring und Fehlersuche entwickeln

7:08 Zwei weitere Klassiker, und beide haben etwas gemeinsam: Ihr Wert liegt nicht in den Worten, sondern in der Reihenfolge, die sie erzwingen. Beide Vorlagen schreiben die Reihenfolge fest. Beim Refactoring: erst grüne Tests, dann Umbau in Schritten. Bei der Fehlersuche: erst Reproduktion, dann Hypothesen, dann Beleg. Sie erkennen die Abläufe aus Modul vier — und genau das ist der Punkt. Eine Vorlage ist der Ort, an dem eine erarbeitete Reihenfolge konserviert wird.

7:37 Sie müssen sich die Disziplin nicht jedes Mal selbst abverlangen; sie steckt in der Datei, und der Aufruf bringt sie mit. Die Reihenfolge ist der eigentliche Wert, nicht der Wortlaut — merken Sie sich diesen Satz, er gilt für alle Vorlagen. Parameter halten das Template allgemein: Datei, Symptom, Testbefehl kommen von außen. Der Nachweis steckt schon in der Vorlage, Sie können ihn also nicht vergessen.

8:02 Und der vierte Punkt ist die Abgrenzung nach oben: Wächst der Ablauf über Text hinaus — braucht er Skripte oder Referenzen —, dann wird ein Skill daraus. Die Grenze verläuft ziemlich genau dort, wo Sie mehr als drei Parameter brauchen. Worauf es hier ankommt, ist die Kombination aus zwei Parametern und vier Schritten. Das Symptom kommt als erstes Argument, der Nachweis als zweites — mit einem vernünftigen Rückfallwert, damit der Aufruf auch mit einem Argument funktioniert.

8:31 Dann die vier Schritte, die Sie aus Modul vier kennen: reproduzieren, Hypothesen prüfen, Ursache belegen, erst dann korrigieren. Beachten Sie den letzten Schritt: „Nachweis erneut fahren". Damit endet jeder Lauf mit einem grünen oder roten Ergebnis, nicht mit einer Einschätzung.

Projektkontext sinnvoll integrieren

8:48 Jetzt eine Frage, bei der man leicht falsch abbiegt: Wie viel Projektwissen gehört in eine Vorlage? Meine Antwort: so wenig wie möglich — und ich erkläre gleich, warum. Ein Template verweist auf Kontext, statt ihn zu duplizieren. Dateien kommen per At-Zeichen oder als Parameter, dauerhafte Regeln bleiben in den Projektanweisungen, und Fundstellen ermittelt der Agent selbst über die Suchwerkzeuge.

9:12 Der Grund ist einfach: Kopierter Kontext veraltet. Wenn Ihre Testkonvention in drei Vorlagen und in den Projektanweisungen steht, wird sie beim nächsten Wechsel an einer Stelle vergessen — und dann arbeitet der Agent mit einer Regel, die nicht mehr gilt. Kopierter Kontext veraltet, verwiesener bleibt aktuell — das ist der Kern.

9:31 Projektregeln gelten ohnehin in jeder Sitzung, sie müssen also nicht in der Vorlage stehen; wer sie dort wiederholt, betreibt Doppelpflege. Parameter für Pfade halten das Template projektunabhängig, sodass Sie es im nächsten Projekt weiterverwenden können. Und kürzere Templates lassen sich leichter pflegen. Wie bei den Projektanweisungen gilt: Länge ist kein Qualitätsmerkmal, sondern Wartungslast.

9:55 Vier Fehler. Regeln aus den Projektanweisungen ins Template kopieren — das erzeugt zwei Wahrheiten, und Sie merken erst, wenn sie auseinanderlaufen. Feste Pfade eintragen, die es im nächsten Projekt nicht gibt; damit ist die Vorlage nicht übertragbar. Ganze Dateiinhalte in die Vorlage schreiben, statt zu verweisen — das kostet bei jedem Aufruf Kontext.

10:16 Und Templates so lang machen, dass niemand sie mehr liest; eine Vorlage, deren Wirkung Sie nicht mehr überblicken, ist gefährlich, weil sie mit jedem Aufruf wirkt.

Anforderungen parametrisieren

10:27 Jetzt der technische Kern dieses Moduls: die Parametersyntax. Sie ist an die Shell angelehnt, und wenn Sie dort zu Hause sind, kennen Sie das meiste bereits. Templates kennen positionale Parameter und Standardwerte. Es gibt Ausdrücke für das erste, zweite und weitere Argumente, einen Sammelausdruck für alle Argumente, eine Schreibweise mit Rückfallwert und Varianten für Teilmengen — ab Position N oder N Argumente ab Position M.

10:53 Das ist Shell-Vokabular. Der Vergleich: ein Formular mit vorausgefüllten Feldern. Sie können jedes Feld überschreiben, müssen aber keines — und genau diese Nachsicht macht ein Werkzeug alltagstauglich. Standardwerte machen den Aufruf ohne Argumente sinnvoll — für mich das wichtigste Kriterium einer guten Vorlage. Der Argumenthinweis zeigt in der Autovervollständigung, was erwartet wird; das ist Ihre Bedienungsanleitung an der richtigen Stelle. Wenige Parameter halten die Bedienung einfach.

11:23 Und ein praktischer Hinweis: Positionsparameter sind unbenannt, also dokumentieren Sie die Reihenfolge. Wer nach vier Wochen rät, ob erst die Datei oder erst das Symptom kommt, benutzt die Vorlage nicht mehr. Die Logik dieser Tabelle: von einfach nach flexibel. Oben die einzelnen Argumente, dann der Sammelausdruck für alles, dann der Rückfallwert — der Ausdruck, den Sie am häufigsten brauchen werden.

11:47 Und unten die Teilmengen, für Fälle, in denen das erste Argument eine Kennung ist und der Rest freier Text. Die Fußzeile gibt eine Faustregel, die ich für nützlich halte: Mehr als drei Parameter sind ein Zeichen dafür, dass Sie eigentlich einen Skill brauchen. Vorlagen sind für Formulierungen, nicht für Programme.

Templates mit Skills und AGENTS.md kombinieren

12:06 Jetzt räumen wir die Bausteine auf. Sie kennen drei — Projektanweisungen, Templates und Skills. Die Frage, welcher wofür zuständig ist, ist die Prüffrage dieses Moduls. Drei Bausteine, drei Aufgaben. Die Projektanweisungen tragen dauerhafte Regeln. Eine Prompt-Vorlage trägt die Formulierung eines Auftrags. Ein Skill trägt einen mehrstufigen Ablauf samt Skripten und Referenzen. Das Bild: die Hausordnung, der Textbaustein und die Arbeitsanweisung.

12:36 Alle drei sind Text, aber sie greifen zu unterschiedlichen Zeitpunkten — immer, auf Abruf, bei passender Aufgabe. Wenn Sie diese drei Zeitpunkte im Kopf haben, ordnen Sie jede neue Information sofort richtig ein. Regeln gelten immer, sie brauchen keinen Aufruf — deshalb dürfen sie kurz sein und müssen prüfbar sein. Templates sind Textbausteine ohne eigene Werkzeuge, also risikofrei und schnell geändert.

13:02 Skills werden situativ geladen und können Skripte mitbringen, also mehr leisten und mehr kosten. Und die vierte Zeile beschreibt eine elegante Kombination: Ein Template kann einen Skill ausdrücklich anstoßen. Sie tippen ein kurzes Kommando, und der ganze Ablauf startet — mit Ihren Parametern. Diese Tabelle ist bewusst redundant zur vorigen Folie — weil die Trennung so oft verwischt wird. Lesen Sie die rechte Spalte: immer, bei Aufruf, bei passender Aufgabe.

13:30 Das sind die drei Wirkungszeitpunkte. Und die Fußzeile nennt das häufigste Symptom einer falschen Zuordnung: Wenn Ablauf in ein Template wandert — also Schritt eins, Schritt zwei, Schritt drei mit Bedingungen —, gehört er eigentlich in einen Skill. Dann wird das Template lang, unleserlich und trotzdem unzuverlässig. In dieser Übung zerlegen Sie einen bestehenden langen Prompt in drei Teile: eine Regel, eine Vorlage und einen Skill-Kandidaten.

13:57 Das Erfolgskriterium ist streng: Keine Information steht doppelt. Genau daran merken Sie, wie viel Redundanz in gewachsenen Prompts steckt. Und Sie bekommen als Nebenprodukt drei brauchbare Artefakte statt eines unhandlichen Textblocks. Diese Übung ist übrigens eine gute Vorlage für Teamworkshops — nehmen Sie den längsten Prompt, den jemand im Team benutzt.

Vom improvisierten Prompting zum reproduzierbaren Workflow

14:18 Zum Abschluss der Blick nach vorn. Aus den drei Bausteinen entsteht etwas, das mehr ist als ihre Summe: ein Arbeitsablauf, der nicht mehr von der Tagesform abhängt. Reproduzierbar wird die Arbeit, wenn Regeln, Formulierungen und Abläufe an festen Orten liegen — versioniert im Repository, geteilt über Pakete, geprüft im Review.

14:38 Das ist derselbe Schritt, den Softwareteams beim Bauen und Testen längst gegangen sind: von „bei mir läuft es" zu einer definierten Pipeline. Für die Arbeit mit Agenten steht dieser Schritt jetzt an. Und er ist erstaunlich billig — drei Dateiordner und ein paar Textdateien. Neue Teammitglieder starten mit dem erprobten Weg, statt sich ihre eigene Prompt-Praxis aufzubauen.

15:01 Ergebnisse werden vergleichbar, weil der Weg gleich ist — das ist die Voraussetzung dafür, überhaupt über Qualität zu sprechen. Verbesserungen wirken für alle, nicht nur für den Autor der Vorlage. Und der vierte Punkt ist der, der mich überzeugt: Was reproduzierbar ist, lässt sich messen und verbessern. Improvisation lässt sich nur bewerten, wenn man das Ergebnis schon kennt.

15:23 Der rote Faden: klein anfangen, im Alltag benutzen, nachschärfen. Sie benennen die drei häufigsten Aufgaben — nicht zehn. Je Aufgabe entscheiden Sie: Regel, Template oder Skill. Dann legen Sie die Bausteine an und nutzen sie eine Woche im echten Betrieb. Nach jeder Reibung korrigieren Sie eine Zeile — das ist der eigentliche Arbeitsschritt, und er kostet Sekunden.

15:47 Und am Ende trennen Sie: Bewährtes ins Repository, Persönliches global. Vier Wochen dieser Pflege reichen für einen stabilen Werkzeugsatz.

Prompts werden Werkzeuge

15:56 Drei Sätze zum Mitnehmen. Templates sind Markdown-Schnipsel, aufgerufen per Schrägstrich-Kommando — der Dateiname ist das Kommando. Parameter mit Standardwerten machen sie alltagstauglich, weil der Aufruf auch ohne Argumente funktioniert. Und Regel, Formulierung und Ablauf gehören an getrennte Orte; jede Doppelung wird irgendwann zum Widerspruch.

16:17 Im nächsten Modul verlassen wir die Textwelt: Wir schreiben eine Erweiterung und geben Pi damit Fähigkeiten, die es vorher nicht hatte.