Der Prompt-Fixer, der erst diagnostiziert, dann umschreibt

Füge einen fehlerhaften Prompt in fast jeden „Prompt-Optimizer“ ein, und du bekommst immer denselben Move: Dein Prompt wandert in eine magische Vorlage – 4-D-Framework! 27 Muster! – und kommt länger zurück, von vorn bis hinten umstrukturiert, ohne jede Aufzeichnung, welche Änderung wichtig war oder ob er noch dieselbe Aufgabe erfüllt. Er liest sich besser. Ob er auch funktioniert, ist eine andere Frage, und das Tool prüft das nie.

Wir betreiben ein Verzeichnis, das Claude-Skills beruflich benchmarkt, und wir wollten das Gegenteil davon. Also haben wir prompt-discipline gebaut, und es behandelt einen Prompt wie du einen Bug-Report behandeln würdest: erst das Fehlermuster benennen, dann die kleinstmögliche Korrektur anwenden, dann genau sagen, wie man die Änderung im A/B-Test prüft. Kostenlos und MIT-lizenziert: github.com/Skillproofdev/prompt-discipline.

Die Lücke: Umschreiber diagnostizieren nicht, Diagnostiker brauchen Infrastruktur

Bevor wir eine Regel geschrieben haben, haben wir 43 Prompt-Engineering-Skills in unserem Katalog gesichtet, plus die eigenständigen Tools – Anthropics eigenen Console-Prompt-Improver, PromptPerfect, DSPy, getsentrys prompt-optimizer. Das Feld teilt sich in zwei Lager, die sich nie überschneiden.

Vorlagen-Umschreiber transformieren jeden Input auf dieselbe Weise. Es gibt keinen Schritt, der fragt, was hier eigentlich falsch ist – ein vager Prompt und ein widersprüchlicher Prompt bekommen dieselbe Behandlung, und der Output ist zuverlässig länger. Das ist kein Strohmann: Anthropics eigener Console-Improver warnt offen, dass seine Umschreibungen länger und langsamer herauskommen. Länger ist das Produkt.

Eval-first-Pipelines – DSPy, Trace-gestützte Optimierer – haben die richtige Epistemologie. Sie messen tatsächlich. Aber sie brauchen Infrastruktur: Produktions-Traces, einen MCP-Server, einen Worktree-Harness, einen gelabelten Datensatz, den du erst zusammenstellen musst. Zu denen greifst du nicht, um den Prompt zu fixen, den du gerade bearbeitest.

Niemand liefert das Mittelding: ein abhängigkeitsfreies Skill, das Diagnose-zuerst → Minimal-Diff → A/B-Testplan macht, ohne Traces und ohne Server aufzusetzen. Genau diese Lücke ist das ganze Skill.

Neun Regeln, drei davon der Kern

Das Skill ist ein Satz harter Regeln in fester Reihenfolge (vollständige SKILL.md). Die bekannten Teile sind da – Output-Format als positiver Vertrag (eine Schlüsselliste mit Typen, nicht „antworte in JSON“), Beispiele statt Adjektive, Verbotslisten umgeschrieben als Handlungsanweisungen, Reihenfolge Rolle→Daten→Anweisungen→Beispiele→Anfrage. Die drei, die es ausmachen:

1. Erst diagnostizieren, bevor irgendetwas angefasst wird. Klassifiziere, was tatsächlich falsch ist – Mehrdeutigkeit, fehlender Kontext, kein Output-Vertrag, widersprüchliche Anweisungen, Format-Drift-Risiko, Über-Prompting oder „gar kein Prompting-Problem“ – und zitiere für jeden Fund die betroffene Textstelle. Keine Diagnose, keine Umschreibung. „Dieser Prompt ist in Ordnung“ ist ein gültiger, vollständiger Output.
2. Minimaler Diff, eine Änderung pro Fehler. Jede Änderung bildet genau einen diagnostizierten Fehler ab, gezeigt als alt → neu mit einer einzeiligen Begründung. Funktionierende Teile bleiben wortgetreu. Wo der Console-Improver aufbläht, kommt dieses Skill meist kürzer heraus – tote Beschwörungsformeln („du bist der weltbeste …“, „atme tief durch“, veraltete „denk Schritt für Schritt“-Gerüste) werden gestrichen.
3. Ein Testplan, kein Versprechen. Jede Umschreibung kommt mit 2–3 konkreten Testeingaben inklusive Edge Case, was ein Bestehen bedeutet, und dem A/B-Ablauf: gleiche Eingaben, gleiches Modell, 3–5 Durchläufe je Variante, Erfolgsquoten vergleichen. Wurden Änderungen gestapelt, wird benannt, welche zuerst rückgängig gemacht werden sollte. Es verspricht nie „das wird es fixen“ – du hast Variablen geändert, der Test entscheidet.

Der Benchmark – und ein Vorbehalt, den du zuerst brauchst

Zehn wirklich fehlerhafte Prompts, jeder gepaart mit einer Aufgabe mit mechanisch prüfbarer Antwort: Extraktion gegen bekannte Ground Truth, Formatierung, die parsen muss (json.loads / csv.reader), Klassifikation gegen gelabelte Beispiele. Drei Arme pro Fall – der Original-Prompt, eine Base-Umschreibung (Claude ohne Skill, schlicht gebeten „verbessere diesen Prompt“) und eine Skill-Umschreibung (identische Session mit dieser SKILL.md geladen). Alle Umschreibungen laufen dann als Aufgaben auf demselben Modell.

Lies das vor der Tabelle: Der Lauf hat n=1 pro Fall pro Arm, nicht das vorregistrierte n=5. Stichprobenvarianz ist ungemessen. Jede Einzelfall-Lücke (0,1) liegt im Rauschen. Behandle jede Zahl hier als vorläufig bis zu einer n=5-Replikation – das tun wir auch.

Arm	Aufgabenerfolg	Formatkonformität	Median Prompt-Längenänderung
A – Original-Prompt	0,70 (7/10)	0,70 (7/10)	—
B – Base-Umschreibung („verbessere diesen Prompt“)	0,80 (8/10)	0,70 (7/10)	+99,5 Wörter
C – Skill-Umschreibung (diese SKILL.md)	0,90 (9/10)	0,80 (8/10)	+44,5 Wörter

Gegen den vorregistrierten Test besteht das Skill: Es zieht mit der Base-Umschreibung gleich oder schlägt sie beim Erfolg (0,90 ≥ 0,80) und bei der Konformität (0,80 ≥ 0,70), überspringt die +15-Prozentpunkte-Schwelle gegenüber dem Original (+20 pp) und tut das bei weniger als halb so viel Prompt-Aufblähung – Median +44,5 Wörter gegen die +99,5 der Base-Umschreibung. Das ist der robusteste Befund im ganzen Lauf: C ist bei allen zehn Fällen schlanker, und es ist der einzige Arm, der jemals negativ wird (Fall 10, −10 Wörter, ein Verbots-Stapel wird aus einem System-Prompt gestrichen). Sowohl naives als auch diszipliniertes Umschreiben blähen knappe Prompts auf; das naive verdoppelt die Kosten ungefähr.

Wo es dünn ist, und wo es verloren hat

Die Erfolgs- und Konformitätsvorsprünge sind real, aber fragil, und das verschweigen wir nicht.

Bei 7 von 10 Fällen liegen alle drei Arme gleichauf. Der Erfolgsvorsprung beruht fast vollständig auf Fall 6 (Ticket-Klassifikation), dem einzigen Fall, den das Skill klar gewinnt: C lieferte korrekte, pro Eintrag parsbare Labels (15/15), während die Base-Umschreibung 13/15 in einem Format lieferte, das nicht parsen würde. Nimm diesen einen Fall raus, und die Spitzenlücke verdampft weitgehend. Genau so sieht n=1 mit vielen Unentschieden aus – ehrlich, nicht verdammend, aber du solltest es wissen.

Fall 9 ist eine Niederlage für das Skill nach seinen eigenen Maßstäben. Ein Tonalitäts-Fix-Prompt mit fehlender Zielgruppe – genau die Situation, für die Regel 2 existiert („nenne deine Annahme, wenn die Absicht unentscheidbar ist“). Die Regel griff nicht. Die Umschreibung des Skills verlor das Problem der fehlenden Zielgruppe aus den Augen, und C scheiterte zusammen mit A und B. Ein Skill, das an genau dem verliert, wofür es speziell gebaut wurde, ist die nützlichste Art negatives Ergebnis, also bleibt es in der Tabelle.

Fall 2 hat bei der Konformität 0 über alle drei Arme. Ein Prompt mit widersprüchlichen Anweisungen: Jeder Arm löste den Widerspruch inhaltlich auf (fand die richtige Zahl), aber keiner erzwang einen einzelnen Output-Wert, also scored alle drei 0 beim Format. Weder der disziplinierte noch der undisziplinierte Umschreiber dachte daran, den Vertrag durchzusetzen. Gemeinsamer blinder Fleck, gemeldet, nicht versteckt.

Wir testen Skills anderer Leute beruflich, und unsere Methodik verlangt, die Verluste neben die Gewinne zu stellen. Das sind die Verluste.

Installation

git clone https://github.com/Skillproofdev/prompt-discipline ~/.claude/skills/prompt-discipline

Claude Code neu starten. Es greift bei „improve this prompt“, „why does my prompt fail“, „optimize prompt“ und wenn du System-Prompts und Agenten-Anweisungen schreibst oder überarbeitest – und lehnt Jailbreak-/Safety-Bypass-Anfragen sowie Bild-/Video-Generierungs-Prompts ab, die ihre eigene Grammatik haben. Es reiht sich in unsere Discipline-Serie ein: token-discipline senkt, was eine Session kostet, research-discipline senkt, was Recherche falsch macht, und dieses hier kürzt Prompt-Umschreibungen auf die Änderung, die wirklich zählte.

FAQ

Wie unterscheidet sich das von Anthropics Console-Prompt-Improver? Der Console-Improver ist ein Vorlagen-Umschreiber – er strukturiert den ganzen Prompt um und warnt offen, dass das Ergebnis länger und langsamer herauskommt. prompt-discipline diagnostiziert zuerst den konkreten Fehler, ändert nur, was zu diesem Fehler passt, und fügte in unserem Benchmark weniger als halb so viel Länge hinzu, während es meist kürzer herauskam. Anderes Ziel: Das Console-Tool liefert einen polierten Prompt; dieses hier liefert den kleinsten vertretbaren Diff plus eine Methode, ihn zu beweisen.

Warum einen Benchmark veröffentlichen, den ihr selbst n=1 nennt? Weil die Alternative in dieser Nische ist, gar keine Zahlen zu veröffentlichen – genau die Norm, gegen die wir reagieren. n=1 mit klar genanntem Vorbehalt ist ehrlicher als eine selbstsichere Behauptung ohne jede Messung dahinter. Der Median-Längen-Befund ist über alle zehn Fälle solide; die Erfolgs- und Konformitätsvorsprünge sind vorläufig und so gekennzeichnet, bis eine n=5-Replikation vorliegt.

Schreibt es meinen Prompt immer um? Nein. Ist der Prompt in Ordnung, sagt das Skill das und hört auf – „dieser Prompt braucht keine Änderungen; hier ist das eine Risiko, das du testen solltest“ ist ein gültiger, vollständiger Output. Es weigert sich auch, eine Diagnose aufzublähen, nur um eine Vorlage anzuwenden, und lehnt Jailbreak-Anfragen rundweg ab, statt sie zu „verbessern“.

Wird das meinen Prompt fixen? Das verspricht es nicht, und das sollte auch kein Tool, das deine Aufgabe nicht selbst ausgeführt hat. Das Skill ändert Variablen und gibt dir ein konkretes A/B-Verfahren mit – gleiche Eingaben, gleiches Modell, 3–5 Durchläufe – sodass der Test entscheidet, nicht das Bauchgefühl bei einem sauberer aussehenden Prompt.