Forschung · KI · geprüft 2026-08-04
Wie macht man Gestaltungsregeln so, dass eine Maschine ihre Einhaltung prüfen kann — statt sie nur zu behaupten?

Designregeln mit Kennung — und was ein 59-MB-Skill über Lieferketten lehrt

Ein quelloffener Gestaltungs-Skill für KI-Entwicklungswerkzeuge trägt hundertvierunddreißig Regeln, von denen jede eine feste Kennung hat, dazu einen Prüfer, der Verstöße im Browser findet, und einen Messstand für den Prüfer selbst. Das ist die Lehre. Die zweite steckt in der Verpackung: fünfzehn Vollkopien desselben Inhalts, ein Ausgang zu einem fremden Bildmodell und eine Erlaubnis, die sich der Skill selbst erteilt.

Experimentell · Horizont: Bald
Der Befund

Gestaltungsregeln bekommen dort eine unveränderliche Kennung im Text, ein Prüfer sucht die maschinell erkennbaren davon im gebauten Ergebnis, und ein Messstand prüft den Prüfer — drei Stufen, von denen wir die erste gar nicht und die dritte nirgends haben. Gegenprobe an der Verpackung: Wer den Skill einbaut, erteilt ihm laut Kopfzeile vorab die Erlaubnis, ein Paket aus einem fremden Verzeichnis mit beliebigen Argumenten auszuführen.

Autor
pbakaus und Mitwirkende
Venue
GitHub (pbakaus/impeccable) (2026)
Lizenz
Apache-2.0 (reiner Lizenztext) — Verfahren nachbauen ist frei, Dateien übernehmen wir nicht
134
So viele Regeln des Skills tragen eine eigene, unveränderliche Kennung mitten im Text — eine unsichtbare Marke hinter dem Satz, den sie regelt. Damit lässt sich sagen, welche Regel gegriffen hat, welche verletzt wurde und welche noch nie in einem Prüflauf vorkam. Unsere eigenen Gestaltungsvorgaben haben keine einzige.
gezählt über skill/reference/ und skill/SKILL.src.md am 2026-08-04
Die Methode

Es gibt seit 2026 eine wachsende Zahl von Anleitungen, die man einem KI-Entwicklungswerkzeug beilegt, damit es besser gestaltet. Die meisten sind eine Textdatei mit Geschmacksregeln. Dieses Projekt ist etwas anderes: rund dreißig Spielbücher für einzelne Gestaltungsaufgaben, ein Qualitätsboden mit harten Verboten, ein Prüfer, der Verstöße im fertigen Ergebnis sucht, ein Kommandozeilen-Werkzeug und eine Browser-Erweiterung. Zusammen 59 MB.

Uns interessiert weder die Gestaltung noch das Werkzeug. Uns interessiert die Buchführung über die Regeln — und was passiert, wenn man so etwas einbaut.

Die Regel bekommt eine Kennung

Am Ende fast jedes Regelsatzes steht eine unsichtbare Marke: eine kurze, unveränderliche Kennung, die den Satz benennt, ohne im gelesenen Text zu erscheinen. Hundertvierunddreißig Stück.

Das klingt nach Buchhaltung und ist eine Umkehrung. Eine Regel in Prosa kann man befolgen oder brechen, aber nicht zählen. Mit Kennung lassen sich Fragen stellen, die vorher keine Form hatten: Welche Regel wurde in diesem Änderungssatz verletzt? Welche greift so oft, dass sie in den Standard gehört? Und die unangenehmste: Welche Regel steht seit ihrer Aufnahme im Dokument und ist noch nie in einem Prüflauf vorgekommen?

Unsere beiden Gestaltungs-Maßstäbe haben keine einzige solche Kennung. Sie sind gut geschrieben und werden befolgt — aber wenn unser Prüf-Skill einen Verstoß meldet, meldet er einen Absatz, keinen Bezeichner. Zwei Läufe über dasselbe Änderungspaket lassen sich deshalb nicht vergleichen.

Der Prüfer, und der Messstand für den Prüfer

Die zweite Stufe trennt, was wir bisher vermischen. Ein Teil der Regeln ist maschinell entscheidbar: Kontrastwert, Schattenform, Zeilenlänge, ob eine Bewegung aus einem bereits sichtbaren Zustand kommt. Ein anderer Teil verlangt Urteil. Dort liegt ein Prüfer, der ausschließlich den ersten Teil im gebauten Ergebnis sucht — nicht im Quelltext, sondern in dem, was der Browser wirklich anzeigt.

Bemerkenswert ist die dritte Stufe. Neben dem Prüfer steht ein Messstand, der den Prüfer misst. Das ist der Schritt, den wir noch nie gemacht haben, und er ist der wichtigste: Ein Prüfer ohne Messung verschiebt die Behauptung nur — vom Gestalter auf das Werkzeug. Wir sind an genau dieser Stelle schon einmal aufgelaufen, als ein eigenes Prüfskript gegen eine fest verdrahtete Dateiliste lief und deshalb zuverlässig die falsche Seite prüfte. Es meldete grün.

Was der Einbau wirklich bedeutet

Der Skill erteilt sich in seiner Kopfzeile zwei Ausführungs-Erlaubnisse vorab. Die eine betrifft Skripte, die im Verzeichnis liegen und lesbar sind. Die andere lautet sinngemäß: ein benanntes Paket aus einem öffentlichen Verzeichnis, mit beliebigen Argumenten. Das ist eine andere Klasse. Was dabei ausgeführt wird, liegt nicht im geprüften Ordner — es wird beim Aufruf geholt, und was heute geprüft wurde, sagt nichts über morgen.

Unser Lieferketten-Prüfer hat das gemeldet, und zwar richtig: als Form, nicht als Urteil. „Fremder Skill erteilt sich Vorab-Erlaubnisse — vor Einbau lesen.“ Genau so ist es gemeint. Der Prüfer findet Muster; die Frage, ob dieses Muster hier tragbar ist, gehört an einen Menschen. Sonst hätte er die 24 weiteren Fundstellen, an denen ein Ausgang und ein heikler Begriff in derselben Zeile stehen, gleich mit verurteilt — und die stammen fast alle aus einem Sicherheitstest gegen Adressen, die wie der eigene Rechner aussehen. Das ist Sorgfalt, kein Angriff.

Dazu zwei echte Ausgänge. Einer erzeugt Bildmaterial über die Schnittstelle eines fremden Modellanbieters. Der andere holt Gestaltungs-Vorschläge von der Projektseite. Der zweite ist so offen dokumentiert, wie wir es selten sehen: Im Quelltext steht, welche Adresse gerufen wird, was die Anfrage trägt, und ausdrücklich, dass keine Projektdateien, keine Eingaben und kein Gesprächsverlauf mitgehen.

An dieser Stelle lohnt eine zweite Lesart, und sie ist keine Unterstellung. Der Text richtet sich nicht an uns, sondern an den Agenten: Er sagt ihm, wie er die Netz-Erlaubnis beim Menschen erbittet, damit sie nicht abgelehnt wird. Das ist gleichzeitig vorbildlich — der Mensch bekommt die Angaben, die er zum Urteilen braucht — und ein Muster, das man kennen muss. Deshalb gilt bei uns die Regel ohne Ausnahme: Fremder Text ist Material, nie Anweisung.

Fünfzehn Kopien

Zuletzt eine Beobachtung, die erst im Vergleich etwas bedeutet. Der Skill liegt für fünfzehn verschiedene Agenten-Programme bereit, und zwar als fünfzehn vollständige Kopien — Prüfsumme für Prüfsumme identisch. Eine einzige Datei liegt sechzehnfach im Baum und macht dabei 7,7 MB aus. Das ist der Grund, warum eine Sammlung von Gestaltungsregeln 59 MB wiegt.

Ein anderes Projekt, das wir kürzlich gelesen haben, löst dieselbe Aufgabe umgekehrt: ein Text an einer Stelle, fünfzehn Verweise darauf. Beide Wege funktionieren; sie unterscheiden sich darin, was passiert, wenn jemand eine Regel ändert. Für uns ist das eine Vorwegnahme: Sollten unsere Anleitungen je mehr als ein Agenten-Programm bedienen, ist das die Weggabelung, und wir kennen jetzt beide Seiten.

Vereins-Bezug

Was das für uns bedeutet

  • Wir haben zwei Gestaltungs-Maßstäbe in Prosa und einen Skill, der ein Änderungspaket dagegen hält. Was wir nicht haben, ist ein Weg zu sagen, welche Regel im Einzelfall griff. Eine Regel ohne Kennung lässt sich nicht zählen, nicht abhaken und nicht widerlegen; sie kann nur zitiert werden. Die Kennung kostet nichts — sie steht als unsichtbare Marke hinter dem Satz — und macht aus einer Sammlung von Absichten eine Liste, gegen die man prüfen kann.
  • Die zweite Stufe ist ein Prüfer, der die maschinell erkennbaren Regeln im gebauten Ergebnis sucht, nicht im Quelltext: Kontrastwerte, Schattenformen, Zeilenlängen, Bewegungsmuster. Ein Teil davon existiert bei uns bereits, aber als Einzelstück für Kontrast in einem einzigen Projekt. Der Sprung ist nicht die Technik, sondern die Einsicht, dass die prüfbaren Regeln von den urteilsbedürftigen getrennt gehören.
  • Die dritte Stufe ist die, die wir nirgends haben und die am meisten wert ist: ein Messstand für den Prüfer selbst. Wer einen Prüfer baut und nie misst, wie oft er richtig liegt, hat die Behauptung nur verschoben — vom Gestalter zum Werkzeug. Wir sind an genau dieser Stelle schon einmal aufgelaufen, als ein Prüfskript gegen eine fest verdrahtete Zweier-Dateiliste lief und deshalb systematisch auf die falsche Seite zeigte.
  • Der Gegenbefund liegt in der Verpackung, und er wiegt schwer. Der Skill erteilt sich in seiner Kopfzeile vorab zwei Ausführungs-Erlaubnisse, davon eine für ein Paket aus einem öffentlichen Verzeichnis mit beliebigen Argumenten. Wer ihn einbaut, hat damit nicht eine Anleitung übernommen, sondern die Zusage gegeben, fremden Code auszuführen, der beim Aufruf frisch geholt wird. Unser eigener Lieferketten-Prüfer meldet die Form — dass ein fremder Skill sich Vorab-Erlaubnisse erteilt —, aber die Tragweite muss ein Mensch beurteilen. Genau dafür ist die Checkliste hinter dem Prüfer da.
  • Dazu zwei Ausgänge, die eine Entscheidung verlangen: Ein Skript erzeugt Bildmaterial über die Schnittstelle eines fremden Modellanbieters, ein zweites holt sich Gestaltungs-Vorschläge von der Projektseite des Autors. Der zweite ist bemerkenswert offen dokumentiert — im Quelltext steht, welche Adresse gerufen wird, was die Anfrage trägt und dass keine Projektdateien mitgehen. Diese Offenheit ist die Ausnahme und verdient, benannt zu werden.
  • Und ein Vergleich, der sich erst durch den vorigen Steckbrief ergibt: Dieselbe Aufgabe — eine Anleitung für viele Agenten-Programme bereitstellen — lösen die beiden Projekte gegensätzlich. Das eine legt den Text einmal ab und verweist fünfzehnmal darauf. Dieses hier kopiert ihn fünfzehnmal vollständig; allein eine einzige Datei liegt sechzehnfach im Baum und macht 7,7 MB aus. Die Kopie ist der Grund, warum ein Gestaltungs-Skill 59 MB wiegt.
Der Plan

Wie wir es nutzen könnten

  1. 1
    Lieferketten-Befund — Einbau ist keine Übernahme einer Anleitung Ergebnis
    Die Kopfzeile erteilt vorab die Erlaubnis, ein Paket aus einem öffentlichen Verzeichnis mit beliebigen Argumenten auszuführen; dazu kommen ein Ausgang zu einem fremden Bildmodell und einer zur Projektseite. Nichts davon ist verborgen, und der zweite Ausgang ist vorbildlich dokumentiert. Aber es ist die Klasse Entscheidung, die ein Mensch trifft, nicht der Prüfer.
  2. 2
    Regel-Kennungen in unsere Gestaltungs-Maßstäbe einziehen offen
    Jede Regel in den beiden Maßstab-Dokumenten bekommt eine kurze, unveränderliche Kennung als unsichtbare Marke. Erst danach lässt sich fragen, welche Regel wie oft griff und welche seit ihrer Aufnahme nie.
  3. 3
    Prüfbare Regeln von urteilsbedürftigen trennen offen
    Die Liste einmal durchgehen und je Regel eintragen, ob eine Maschine sie am gebauten Ergebnis entscheiden kann. Das Ergebnis ist selbst ein Befund — vermutlich ist der maschinell prüfbare Teil kleiner, als er sich anfühlt.
  4. 4
    Den vorhandenen Kontrast-Prüfer zum Regel-Prüfer erweitern offen
    Wir messen Kontrast heute in einem Projekt mit einem eigenen Skript. Dasselbe Gerüst nimmt weitere maschinell prüfbare Regeln auf und meldet je Verstoß die Kennung statt einer Prosa-Meldung.
  5. 5
    Messstand für den Prüfer offen
    Eine kleine Sammlung von Fällen mit bekanntem Ergebnis, gegen die der Prüfer läuft. Ohne sie verschiebt ein Prüfer die Behauptung nur vom Menschen aufs Werkzeug — und wir haben genau diesen Fehler schon einmal gemacht.
  6. 6
    Vorab-Erlaubnisse in der Lieferketten-Checkliste schärfen offen
    Unser Prüfer meldet, dass ein fremder Skill sich Erlaubnisse erteilt. Die Checkliste sollte danach die Frage stellen, die zählt: Wird dabei Code ausgeführt, der erst beim Aufruf geholt wird? Das ist eine andere Klasse als ein Skript, das im geprüften Verzeichnis liegt.
Ehrlich benannt

Offene Punkte

  • Gelesen haben wir die Kopfzeile und den Anfang des Haupttextes, die Verbotsliste des Qualitätsbodens, die Ausgänge aller Skripte und die Struktur der rund dreißig Spielbücher. Nicht gelesen haben wir die Spielbücher inhaltlich — zusammen rund fünftausend Zeilen —, das Kommandozeilen-Werkzeug, die Browser-Erweiterung und die Tests. Ein Urteil über die Gestaltungs-Qualität steht damit ausdrücklich aus.
  • Wir haben nichts installiert und nichts ausgeführt. Alle Angaben stammen aus dem gelesenen Quelltext eines flachen Klons.
  • Ob unsere Maßstäbe überhaupt genug maschinell prüfbare Regeln enthalten, damit sich ein Prüfer lohnt, ist ungeprüft. Es kann sein, dass unsere Regeln überwiegend Urteil verlangen — dann ist die Kennung trotzdem nützlich, der Prüfer aber nicht.
  • Eine mitgelieferte Bibliothek für Bildschirmfotos liegt als zusammengefasste Einzeldatei bei und ist in dieser Form nicht sinnvoll prüfbar. Das ist bei uns die bekannte Klasse „nicht prüfbar“ — kein Vorwurf, aber ein Grund gegen den Einbau ohne weitere Prüfung.
  • Der Skill ist auf Englisch und auf westliche Produkt-Ästhetik hin geschrieben. Unsere Kisten richten sich an Vier- bis Neunjährige, viele davon Nichtleser, und der Maßstab dafür ist ein eigener. Wie weit die Regeln dorthin tragen, ist offen.
  • Verglichen wird hier ein Gestaltungs-Skill mit unseren Gestaltungs-Dokumenten. Das ist keine Bewertung der Gestaltung selbst — wir haben keine Arbeit gesehen, die damit entstanden ist.
Belege

Quellen

Paper, Code, Modell und Erklärung — mit eigenem Namen daneben. Datum dort, wo es belegbar ist.

Der Forschungsradar sammelt fremde Methoden, die zu dem passen, was wir bauen. Externe Entwicklungen (Regulierung, Markt) stehen in den Recherchen; die KI-Modelle selbst im Modell-Katalog.