Was wir bei der Entwicklung der Scoville Skills über überprüfbare Regeln, Personas und zuverlässige AI-Arbeit gelernt haben.
AI-Agenten untersuchen heute Dateien, ändern Code, führen Tests aus, bedienen Browser und arbeiten über mehrere Gespräche hinweg an einer Aufgabe. Damit wächst auch das Risiko, eine überzeugende Antwort mit einem nachgewiesenen Ergebnis zu verwechseln.
Skills geben solchen Agenten einen wiederverwendbaren Arbeitsrahmen. Laut Agent-Skills-Spezifikation bestehen sie aus Anweisungen, Referenzen und optionalen Hilfsskripten. Ein Skill ersetzt kein Modelltraining. Er kann aber festlegen, welche Informationen der Agent braucht, wie er vorgeht und woran sich das Ergebnis prüfen lässt.
Viele Skills beginnen mit einer Rolle: „Du bist ein Senior-Softwareentwickler“, „Du bist ein professioneller Werbetexter“, „Du bist ein erfahrener UI-Designer“.
Die Idee ist nachvollziehbar. Wer Expertenarbeit will, lässt das Modell wie ein Experte auftreten. Eine Rolle kann Ton, Perspektive oder Format beeinflussen. Fachwissen beweist sie nicht. Fünfzehn Jahre Berufserfahrung entstehen nicht dadurch, dass man sie in einen Prompt schreibt.
Das war eine der wichtigsten Erkenntnisse aus der Entwicklung der Scoville Skills: Zuverlässiges Verhalten braucht Regeln, deren Ergebnis sich überprüfen lässt.
Die Skills unterstützen Planung, Umsetzung, Oberflächenarbeit und die Fortsetzung längerer Aufgaben. Für Codex kommen ein koordinierter Workflow, unabhängige Modellmeinungen und gemeinsame Projekteinstellungen dazu:
- Scoville Code richtet Entwicklung, Diagnose und Review auf das gewünschte Verhalten und eine passende Prüfung aus.
- Scoville Plan hält Ziele, Arbeitspakete, Entscheidungen und den nächsten Schritt im Repository fest.
- Scoville UI setzt Oberflächen mit dem vorhandenen Framework und Designsystem um und prüft sie. Für WordPress-Adminseiten von Plugins bringt der Skill passende Plattformregeln mit.
- Scoville Handoff übergibt den tatsächlichen Arbeitsstand kompakt an einen anderen Agenten oder eine neue Session.
- Scoville Workflow for Codex koordiniert Umsetzung, unabhängige Reviews und Kontextübergaben anhand eines Plans.
- Scoville Ask for Codex holt unabhängige Einschätzungen anderer Modelle ein und bringt sie in den ursprünglichen Chat zurück.
- Scoville Setup zeigt die Ask- und Workflow-Einstellungen eines Projekts und speichert gewünschte Änderungen.
Der Name kommt von der Scoville-Skala, deren ursprüngliches Verfahren Schärfe durch Verdünnung bestimmte. Bei den Skills geht es um das, was auch nach vielen Arbeitsschritten und langen Gesprächen nicht verwässern soll: das gewünschte Verhalten, die Richtung eines Plans und der Kontext, den ein Nachfolger wirklich braucht.
Als der Prozess selbst zum Produkt wurde
Scoville Code begann als Sammlung vernünftiger Entwicklungsregeln: planen, testen, dokumentieren, prüfen, sauber abschließen. Jede Regel war für sich sinnvoll. Zusammen erzeugten sie einen neuen Fehler.
Ein Agent konnte jeden vorgesehenen Schritt erledigen, ohne das eigentliche Ziel zu erreichen. Es gab einen Plan, also galt die Aufgabe als geplant. Die Tests waren grün, also galt die Änderung als bewiesen. Die Dokumentation war da, also wirkte die Arbeit fertig. Und trotzdem konnte genau das Verhalten fehlen, um das es ursprünglich ging.
Der Anti-Slop-Skill hatte angefangen, seinen eigenen Prozess-Slop zu produzieren.
Deshalb steht das beobachtbare Ergebnis wieder am Anfang. Welches Verhalten muss erreicht werden? Welche Komponente ist dafür zuständig? Was darf sich nicht verändern? Und welche Prüfung zeigt, ob die Änderung funktioniert?
Das heißt nicht, möglichst wenig zu testen. Es heißt, nicht fünfmal dieselbe Eigenschaft zu prüfen, während das entscheidende Nutzerverhalten ungeprüft bleibt. Umfang ersetzt keine Aussagekraft.
Auch Absicherungen müssen zu den möglichen Folgen passen. Wenn in einem seltenen Fall ein Chat offen bleibt, rechtfertigt das keine aufwendige Überwachungslogik. Wenn dagegen Daten verloren gehen oder Änderungen unkontrolliert veröffentlicht werden könnten, braucht es eine wirksame Absicherung. So einfach wie möglich, aber ausreichend.
Das Projekt bestimmt die Designsprache
Viele UI-Skills bringen unbemerkt ihr eigenes Designsystem mit: bestimmte Schriften, Rundungen, Schatten, Verläufe, Kartenlayouts oder Breakpoints. Das Ergebnis sieht für sich modern aus und passt trotzdem nicht zur vorhandenen Anwendung.
Scoville UI folgt dem Designsystem des Projekts. Ein Framework wie Mantine bringt Themes, Tokens und Varianten mit, die wiederverwendet werden sollten. Radix Primitives liefert dagegen weitgehend ungestylte Komponenten und kümmert sich vor allem um Semantik, Fokus und Interaktion. Das Aussehen muss dann trotzdem zum Projekt passen.
Dazu kommen allgemeine UI-Prinzipien wie klare Hierarchie, verständliche Gruppierung, gute Lesbarkeit, vollständige Zustände, Tastaturbedienung, Anpassung an unterschiedliche Bildschirmgrößen und Barrierefreiheit nach WCAG 2.2. Für WordPress-Adminseiten von Plugins berücksichtigt der Skill außerdem die WordPress-Konventionen, ohne eine bestehende PHP-Oberfläche plötzlich zur React-Anwendung zu machen.
Die wichtigste praktische Erkenntnis war aber einfacher: Ein erfolgreicher Build beweist keine gute Oberfläche. Er zeigt nicht, ob eine Überschrift auf einem schmalen Display sinnvoll umbricht, ob ein Dialog auf dem Smartphone bedienbar bleibt oder ob der Fokus sichtbar ist. Dafür muss der Agent die Oberfläche ansehen und tatsächlich bedienen.
Längere Aufgaben brauchen einen nachvollziehbaren Arbeitsstand
Ein langer Chat ist kein zuverlässiger Projektspeicher. Entscheidungen verteilen sich über Nachrichten, Änderungen werden unterbrochen, und irgendwann muss ein neuer Agent übernehmen.
Scoville Plan hält deshalb Ziele, Arbeitspakete, Schritte und Entscheidungen im Repository fest. Ein Arbeitspaket beschreibt ein Ergebnis, das sich prüfen und nach einer Unterbrechung fortsetzen lässt. Der nächste Schritt muss aus den Aufzeichnungen hervorgehen.
Scoville Handoff ergänzt das, wenn ausdrücklich ein Sessionwechsel gewünscht ist. Die Übergabe enthält Ziel, Entscheidungen, Änderungen, Belege, Blocker und die nächste Handlung, ohne die Aufgabe auf dem Weg noch schnell weiterzubearbeiten.
Scoville Workflow for Codex aus der Scoville Suite for Codex verbindet das mit getrennten Chats für Umsetzung und Review. Ein Koordinator wählt einen Abschnitt des Plans, ein Worker setzt ihn um, ein unabhängiger Reviewer prüft das Ergebnis, und der Koordinator hält den akzeptierten Stand fest.
Dabei braucht nicht jeder kleine Schritt einen eigenen Worker. Zusammengehörige Schritte können denselben Kontext nutzen und gemeinsam ein prüfbares Ergebnis liefern. Die Reihenfolge des Plans bleibt erhalten.
Der Auftrag an einen Worker darf aber auch nicht so knapp werden, dass er erst alte Chats zusammensuchen muss. Er braucht den Auftrag, die relevanten Ziele und Entscheidungen, die erledigte Arbeit und den nächsten Schritt. Alles andere kostet nur Kontext.
Auch ein Skill muss seinen Nutzen zeigen
Nicht alle ursprünglichen Scoville Skills werden weiter gepflegt. Scribe, Design, Research und Brainstorm haben wir eingestellt. Die Vergleiche zeigten zu wenig zusätzlichen Nutzen, die Qualität stimmte nicht, oder es gab bereits bessere Alternativen.
Bei Scribe, unserem Skill für Texte, lernten wir trotzdem etwas Wichtiges: „Erhalte die Bedeutung des Autors“ lässt zu viel Spielraum. Ein Modell machte aus „I had enough information“ ein eleganteres „I knew enough“ und damit aus ausreichend Informationen eine Behauptung über Wissen. Erst konkrete Gegenbeispiele haben geholfen. Einen verlässlichen Mehrwert konnten unsere Vergleiche am Ende aber nicht belegen, die getestete Fassung führte sogar unbelegte Aussagen ein.
Ein Skill muss die Arbeit verbessern. Eine plausible Regel, eine gute Erklärung oder viel investierte Zeit reichen nicht.
Leistungsfähige Modelle wie Fable, Astra, SOL oder Opus liefern mit den Skills die besten Ergebnisse und sind unsere Empfehlung. Sie sind aber keine Voraussetzung: Wir haben die Skills auch mit Luna getestet, einem schnellen, leichteren Modell. Deshalb müssen die Anweisungen kurz, verständlich und ohne verborgenes Vorwissen ausführbar sein.
Wenn ein kleineres Modell scheitert, lohnt sich zuerst ein Blick auf Test und Auftrag. War der nötige Kontext da? Waren die Erwartungen eindeutig? Hat der Test wirklich die vorgesehene Aufgabe geprüft? Erst dann lässt sich sagen, ob das Modell nicht gereicht hat.
Die Tests zeigten auch Grenzen, etwa beim Befolgen komplexer Workflow-Anweisungen. Ein bestandener Test macht einen Skill nicht allgemein zuverlässig. Er zeigt, dass dieser Ablauf unter diesen Bedingungen funktioniert hat.
Dasselbe gilt für die Rollenbeschreibungen, mit denen viele Skills beginnen. „Du bist ein Senior-Softwareentwickler“ klingt nach einer klaren Anweisung. Ob daraus tatsächlich bessere Arbeit entsteht, zeigt aber nicht die Rolle, sondern das Ergebnis.
Eine Persona kann helfen, aber sie beweist nichts
Die Forschung zu Personas ist nicht eindeutig. Eine EMNLP-Studie fand bei Faktenfragen insgesamt keine Verbesserung durch Rollenbeschreibungen. Eine NAACL-Studie berichtete dagegen Verbesserungen auf Reasoning-Benchmarks durch eine gezielt entwickelte Role-Play-Methode.
Das ist kein Widerspruch. Aufgaben, Modelle und Verfahren unterscheiden sich. Eine Rolle kann in einer bestimmten Anordnung ein nützlicher Hinweis sein. Daraus folgt nicht, dass eine beliebige Expertenpersona Fachkompetenz erzeugt.
Auch bei unseren Skills war deshalb die entscheidende Frage, welches Verhalten eine Anweisung tatsächlich auslöst. Mehr Text heißt nicht mehr Kontrolle. Zusätzliche Regeln können sich widersprechen, den eigentlichen Auftrag überlagern oder Arbeit auslösen, die niemand braucht.
Wahrheit, Fiktion und Halluzination
Man hört oft, Halluzinationen seien einfach ein Feature, so wie menschliche Fantasie. Das trifft nur einen Teil des Problems. Neue Inhalte zu erzeugen kann genau der Auftrag sein. Eine erfundene Aussage als geprüfte Tatsache auszugeben, ist etwas anderes.
Wenn ein Modell für eine Star-Trek-Geschichte einen Warp-Antrieb erfindet, erfüllt es einen kreativen Auftrag. Spricht es über ein hypothetisches Raumzeitmodell, spekuliert es. Behauptet es, funktionierende Warp-Antriebe seien experimentell nachgewiesen, ist das schlicht falsch. Ein mathematisches Modell, eine technische Möglichkeit und ein experimenteller Nachweis sind nicht dasselbe.
OpenAI erklärt in seinem Beitrag zu Halluzinationen, warum Modelle auch bei Unsicherheit Antworten erzeugen. Für die Praxis heißt das: Ein Agent muss Unsicherheit benennen dürfen, statt eine fehlende Grundlage mit einer plausiblen Behauptung zu füllen.
„Sei wahrheitsgemäß“ reicht dafür als Anweisung nicht. Fakten, Schlussfolgerungen und Annahmen müssen unterscheidbar bleiben. Quellen und vorhandener Code müssen tatsächlich untersucht werden. Wer einen bestandenen Test behauptet, muss ihn ausgeführt haben. Kreative Erfindung bleibt erlaubt, wo sie zum Auftrag gehört.
Was ein guter Skill leisten sollte
Ein guter Skill braucht genug Regeln, um die Aufgabe verlässlich zu erledigen, und wenig genug, damit sie verständlich bleiben. Dazu gehören:
- das beobachtbare Ziel der Aufgabe,
- die Quellen, Komponenten und Projektentscheidungen, die zu beachten sind,
- das Verhalten, das bei einer Änderung erhalten bleiben muss,
- die Informationen, die vor dem nächsten Schritt nötig sind,
- der Umgang mit fehlenden Belegen und Unsicherheit,
- eine aussagekräftige Prüfung des Ergebnisses,
- eine klare Bedingung für den Abschluss,
- realistische Aufgaben, an denen sich der Nutzen des Skills messen lässt.
Code muss das gewünschte Verhalten liefern. UI muss zum Projekt passen und bedienbar sein. Plan muss Entscheidungen und Fortschritt nachvollziehbar halten, Handoff eine Fortsetzung ermöglichen. Workflow muss die Arbeit sinnvoll verteilen, Ask brauchbare unabhängige Einschätzungen liefern und Setup die geltenden Einstellungen verständlich machen.
Eine Persona kann diesen Rahmen sprachlich ergänzen. Ob er etwas taugt, zeigt sich am Ergebnis.
Die Scoville Skills im eigenen Workflow testen
Die Scoville Suite enthält Code, Plan, UI und Handoff für kompatible Agent-Skills-Umgebungen. Die Scoville Suite for Codex ergänzt Workflow, Ask und Setup. Code, Plan, UI, Handoff und Ask gibt es auch einzeln.
Alle Projekte sind auf meinem GitHub-Profil zu finden. Die Skills sollten an echten Aufgaben getestet und mit der bisherigen Arbeitsweise verglichen werden. Interessant sind konkrete Beobachtungen: Welche Fehler wurden vermieden? Wo fehlte Kontext? Welche Regel hat geholfen, und welche hat nur Zeit und Tokens gekostet?