Was wir bei der Entwicklung der Scoville Skills über überprüfbare Regeln, Personas und zuverlässige AI-Arbeit gelernt haben.
AI wird zunehmend nicht mehr nur als Chat verwendet. Je nach Umgebung können AI-Agenten Dateien untersuchen, Code durchsuchen, Tests ausführen, Browser bedienen, Oberflächen verändern und Aufgaben über mehrere Schritte hinweg bearbeiten. Damit wächst aber auch das Risiko, dass eine überzeugende Antwort mit einem nachgewiesenen Ergebnis verwechselt wird.
Eine Möglichkeit, das Verhalten solcher Agenten zu beeinflussen, sind Skills. Die OpenAI-Dokumentation beschreibt sie als wiederverwendbare Pakete aus Anweisungen, Referenzen und optionalen Hilfsskripten. Ein Skill ersetzt kein Modelltraining. Er gibt dem Agenten einen überprüfbaren Arbeitsrahmen für bestimmte Aufgaben.
Viele Skills beginnen stattdessen mit einer Rollenbeschreibung: „Du bist ein Senior-Softwareentwickler“, „Du bist ein professioneller Werbetexter“ oder „Du bist ein erfahrener UI-Designer“.
Die Logik dahinter ist verständlich. Wenn ausgezeichnete Arbeit gewünscht ist, soll das Modell eben wie ein Experte handeln. Eine solche Rolle kann Ton, Perspektive oder Ausgabeformat beeinflussen. Sie ist aber kein Nachweis von Fachwissen. Fünfzehn Jahre Berufserfahrung entstehen nicht dadurch, dass sie in einem Prompt behauptet werden.
Das war eine der wichtigsten Erkenntnisse aus der Entwicklung der Scoville-Familie: Zuverlässiges Verhalten sollte nicht gespielt, sondern durch Regeln beschrieben werden, deren Ergebnis überprüft werden kann.
- Scoville Code Anti-AI-Slop behandelt Umsetzung, technische Zuständigkeit und geeignete Verifikation.
- Scoville Scribe Anti-AI-Slop schützt Bedeutung, Fakten, Terminologie und die Wirkung auf Leser.
- Scoville UI Anti-AI-Slop behandelt Informationsdesign, Lesbarkeit, Bedienbarkeit, Responsiveness und die gerenderte Oberfläche.
- Der ergänzende Fable-kalibrierte Systemprompt für GPT-5.6 Sol überträgt dieselbe Idee auf die Zusammenarbeit mit dem Agenten.
Als der Prozess selbst zum Produkt wurde
Scoville Code begann als klassische Sammlung vernünftiger Entwicklungsregeln: planen, testen, dokumentieren, prüfen und sauber abschließen. Jede dieser Anforderungen war für sich sinnvoll. Zusammen erzeugten sie jedoch einen neuen Fehlermodus.
Ein Agent konnte alle vorgesehenen Prozessschritte erledigen, ohne das eigentliche Ziel zu erreichen. Es gab einen Plan, also galt die Aufgabe als geplant. Tests liefen erfolgreich, also galt die Änderung als bewiesen. Dokumentation war vorhanden, also wirkte die Arbeit abgeschlossen. Dabei konnte weiterhin genau das Verhalten fehlen, um das es ursprünglich ging.
Der Anti-Slop-Skill hatte begonnen, eigenen Prozess-Slop zu produzieren.
Die Goal-first-Neufassung stellte deshalb das beobachtbare Ergebnis wieder an den Anfang. Der Agent soll bestimmen, welches Verhalten erreicht werden muss, wo dieses Verhalten tatsächlich verantwortet wird, welche angrenzenden Verträge erhalten bleiben müssen und welche Prüfung das Ergebnis wirklich belegen oder widerlegen kann. Sobald die relevante Evidenz vorliegt, endet die Prüfung.
Das bedeutet nicht, möglichst wenig zu testen. Es bedeutet, nicht fünfmal dieselbe Eigenschaft zu prüfen, während das entscheidende Nutzerverhalten ungeprüft bleibt. Umfang ist kein Ersatz für Aussagekraft.
„Bedeutung erhalten“ war nicht genau genug
Scoville Scribe zeigte ein ähnliches Problem bei Texten. Die Anweisung „Erhalte die Bedeutung des Autors“ klingt eindeutig. In der Praxis lässt sie jedoch zu viel Interpretationsraum.
Ein Modell kann „I had enough information“ zu „I knew enough“ verkürzen und die neue Formulierung für eleganter halten. Inhaltlich wurde aber aus dem Besitz ausreichender Informationen plötzlich eine Behauptung über Wissen. Auch „whether I should accept“ und „whether I accept“ beschreiben nicht dieselbe Entscheidung.
Die Lösung bestand nicht darin, aus einem „professionellen Autor“ einen „weltbesten Lektor“ zu machen. Stattdessen wurden verschiedene Arten von Entscheidungen getrennt:
- Fakten und beschriebenes Verhalten müssen aus überprüfbarer Realität stammen.
- Terminologie folgt dem Projekt, dem Fachgebiet und bereits festgelegten Produktbegriffen.
- Form, Zielgruppe und Stimme folgen dem konkreten Auftrag.
- Stil darf diese Zuständigkeiten nicht überschreiben.
Konkrete Gegenbeispiele wurden Teil des Skills, weil die abstrakte Regel zuvor in Tests nicht ausgereicht hatte. Auch die Quellen folgen dieser Trennung: Das WCAG-Kriterium „Label in Name“ behandelt die Beziehung zwischen sichtbarer und zugänglicher Beschriftung. ICU MessageFormat beschreibt strukturierte dynamische und lokalisierte Texte. Der Microsoft Writing Style Guide fordert unter anderem konsistente technische Begriffe.
Die entscheidende Frage lautet damit nicht mehr nur, ob ein Text besser klingt. Sie lautet: Hilft die Änderung beim Verstehen, ohne Fakten, Bedingungen, Beziehungen oder die Haltung des Sprechers zu verändern?
Das Projekt bestimmt die Designsprache
Viele UI-Skills bringen unbemerkt ein eigenes Designsystem mit. Sie bevorzugen bestimmte Schriften, Rundungen, Schatten, Verläufe, Kartenlayouts oder Breakpoints. Das Ergebnis kann isoliert modern aussehen und trotzdem nicht zur vorhandenen Anwendung gehören.
Scoville UI verfolgt deshalb einen anderen Ansatz. Das Projekt und sein kanonisches Designsystem bestimmen die visuelle Sprache. Ein gestyltes Komponentenframework wie Mantine besitzt Themes, Tokens und Komponentenvarianten, die wiederverwendet werden sollten. Radix Primitives liefert dagegen weitgehend ungestylte Komponenten und verantwortet vor allem Semantik, Fokusverhalten und Interaktion. Daraus entsteht keine Erlaubnis, dem Projekt eine beliebige neue Ästhetik überzustülpen.
Allgemeine UI-Prinzipien füllen nur die Lücken, die diese Zuständigkeiten offenlassen: klare Informationshierarchie, verständliche Gruppierung, gute Lesbarkeit, vollständige Zustände, Tastaturbedienung, sinnvolle Anpassung an unterschiedliche Viewports und Barrierefreiheit.
Zu den Grundlagen gehören WCAG 2.2 sowie die Theming- und Komponentenmodelle von Material UI, Mantine und Radix. Zusätzlich dienten Fluent 2, Carbon, das Atlassian Design System und Apples Human Interface Guidelines als Referenzen für wiederverwendbare Produkt- und Plattformkonventionen.
Die wichtigste praktische Erkenntnis war jedoch einfacher: Ein erfolgreicher Build beweist keine gute Oberfläche. Er zeigt nicht, ob eine Überschrift auf einem schmalen Display sinnvoll umbricht, ein Dialog auf dem Smartphone bedienbar bleibt oder ein Fokusindikator sichtbar ist. Visuelle Aussagen benötigen gerenderte Evidenz. Aussagen über Interaktion benötigen ausgeführte Interaktion.
Eine Persona kann helfen, sich aber nicht selbst bestätigen
Der Fable-kalibrierte Systemprompt enthält weiterhin eine Rollenbeschreibung. Er beschreibt den Agenten als direkten, kompetenten Mitarbeiter und Senior Engineer im Pairing mit einem Teamkollegen. Diese Formulierung legt Beziehung und Kommunikationsniveau fest. Die eigentliche Arbeit wird aber durch konkrete Verhaltensregeln gesteuert.
Dafür wurde eine feste Vergleichssuite mit 40 Fragen sowie zusätzlichen fokussierten Tests verwendet. Beobachtbare Eigenschaften aus Fable-5-Ausgaben wurden einzeln formuliert: mit dem Ergebnis beginnen, den Mechanismus erklären, ein Beispiel bis zur Konsequenz durchführen, entscheidungsrelevante Grenzen nennen und fehlgeschlagene oder ausgelassene Prüfungen offen berichten.
Die Forschung zu Personas ergibt kein einheitliches Bild. Eine EMNLP-Studie untersuchte 162 Rollen, vier Modellfamilien und 2.410 Faktenfragen. Personas verbesserten die Leistung gegenüber der Kontrollbedingung insgesamt nicht. Die automatisch beste Persona für eine Frage zu finden, war häufig nicht erfolgreicher als eine zufällige Auswahl.
Eine andere NAACL-Studie testete eine gezielt entwickelte Role-Play-Methode auf zwölf Reasoning-Benchmarks. Bei ChatGPT stieg die Genauigkeit auf AQuA von 53,5 auf 63,8 Prozent und bei Last Letter von 23,8 auf 84,2 Prozent. In dieser Versuchsanordnung wirkte das Role-Play-Prompting als stärkerer Auslöser für Chain-of-Thought als der verwendete Zero-Shot-CoT-Vergleich.
Das widerspricht sich nicht. Eine Rolle kann in bestimmten Aufgaben als nützlicher Hinweis funktionieren. Daraus folgt aber nicht, dass eine beliebige Expertenpersona allgemeine Fachkompetenz erzeugt.
Auch die aktuelle OpenAI Model Guidance empfiehlt schlankere Prompts. In einer Stichprobe interner Coding-Agent-Evaluationen verbesserten vereinfachte Systemprompts die Bewertung um ungefähr 10 bis 15 Prozent und reduzierten die Tokenmenge um 41 bis 66 Prozent. OpenAI bezeichnet diese Werte ausdrücklich als richtungsweisend und empfiehlt eine Prüfung mit repräsentativen Aufgaben der eigenen Anwendung.
Mehr Anweisungen bedeuten also nicht automatisch mehr Kontrolle. Manchmal sind sie nur mehr Text, dessen Regeln miteinander konkurrieren.
Wahrheit, Fiktion und Halluzination
Die Aussage, Halluzinationen seien einfach ein Feature wie menschliche Fantasie, trifft nur einen Teil des Problems. Die Fähigkeit, neue Inhalte zu erzeugen, ist beabsichtigt. Eine erfundene Aussage als überprüfte Tatsache auszugeben, ist es nicht.
Wenn ein Modell einen Warp-Antrieb für eine Star-Trek-Geschichte erfindet, erfüllt es einen kreativen Auftrag. Wenn es über ein hypothetisches Raumzeitmodell spricht, spekuliert es. Wenn es behauptet, experimentell funktionsfähige Warp-Antriebe seien bereits demonstriert worden, behauptet es etwas Falsches.
Auch „Warp-Antriebe sind physikalisch unmöglich“ wäre zu absolut. Die allgemeine Relativitätstheorie erlaubt mathematische Raumzeitmodelle für überlichtschnelle Bewegung. Untersuchungen zu Alcubierre- und Natário-Geometrien zeigen jedoch erhebliche Anforderungen an negative Energie. Eine untersuchte Modifikation des Alcubierre-Modells ermöglicht außerdem geschlossene Kausalschleifen. Daraus ergibt sich kein technisch realisierbarer Antrieb, aber auch kein Beweis gegen jede denkbare mathematische Variante.
OpenAI weist in seiner Erklärung zu Halluzinationen ebenfalls auf eine wichtige Unterscheidung hin: Halluzinationen sind nicht in jeder Antwort unvermeidbar, weil ein Modell bei Unsicherheit auf eine konkrete Antwort verzichten kann. Gleichzeitig lässt sich für offene Fragen keine fehlerfreie Genauigkeit garantieren.
Ein guter Skill fordert deshalb nicht nur „Sei wahrheitsgemäß“. Er macht Wahrheit operativ: Fakten, Schlussfolgerungen und Annahmen werden getrennt; aktuelle Quellen und echter Code werden untersucht; überprüfbare Behauptungen erhalten Evidenz; Unsicherheit wird benannt; kreative Erfindung bleibt dort erlaubt, wo sie tatsächlich Teil der Aufgabe ist.
Was ein moderner Skill leisten sollte
Das Gegenstück zu „Du bist ein Experte“ ist kein möglichst langes Regelwerk. Ein guter Skill benötigt einen kompakten, überprüfbaren Vertrag:
- das beobachtbare Ziel der Aufgabe,
- die zuständige Quelle oder Komponente für jede Entscheidung,
- Eigenschaften und Verträge, die erhalten bleiben müssen,
- Behauptungen, die externe Evidenz benötigen,
- Unsicherheit, die offengelegt werden muss,
- die kleinste aussagekräftige Prüfung, die einen Fehler sichtbar machen kann,
- eine klare Bedingung, nach der die Arbeit beendet ist,
- repräsentative Aufgaben, mit denen sich der Nutzen des Skills prüfen lässt.
Eine Persona kann weiterhin einen Kommunikationsrahmen setzen. Sie darf nur nicht als eigener Qualitätsnachweis dienen. Code muss beobachtbares Verhalten liefern. Scribe muss Bedeutung und Fakten erhalten. UI muss sein Framework respektieren und in der gerenderten Oberfläche funktionieren. Der Systemprompt muss gewünschte Eigenschaften in nachvollziehbare Arbeitsweisen übersetzen.
Expertise sollte nicht behauptet werden. Der Arbeitsprozess sollte Ergebnisse erzeugen, an denen sie sich prüfen lässt.
Die Scoville Skills im eigenen Workflow testen
Alle Projekte und weitere Arbeiten befinden sich auf meinem GitHub-Profil. Alle sind willkommen, die Skills im eigenen Workflow mit realen Aufgaben zu testen, mit der bisherigen Arbeitsweise zu vergleichen und Beobachtungen über die jeweiligen Repositories zu teilen.
Ergänzend steht auch der Fable-kalibrierte Systemprompt für GPT-5.6 Sol im Repository zur Verfügung.