--- title: "KI-Agenten schreiben Flutter-Code, der hält: Skills, Hooks und Quality Gates" description: "Wie bekommst Du KI-Agenten dazu, Flutter-Code zu schreiben, der nicht nur kompiliert? Skills, Hooks, Very Good CLI und 100 % Testabdeckung. Meine Learnings von der FlutterCon 2026." canonical_url: "https://robocitrus.com/blog/flutter-ki-agenten-skills-hooks-quality-gates" --- > Index of every page on this site: [llms.txt](https://robocitrus.com/llms.txt) ## Der Code kompiliert. Und trotzdem ist er falsch. Lass einen KI-Agenten ohne Anleitung ein Flutter-Feature bauen und Du bekommst Code, der läuft. Meistens zumindest. Aber er sieht aus, als hätte ihn jemand geschrieben, der Dein Projekt nie gesehen hat. Hardcodete Farben im Widget. Strings direkt im Code statt Lokalisierung. Navigation über String-Pfade. Ein Cubit, das sein Repository selbst instanziiert, weil das der schnellste Weg ist. API-Keys in einer Dart-Datei. Nichts davon ist Quatsch. Es kompiliert, es funktioniert. Aber es ist nicht das, was Dein Team erwartet. Und genau darum ging es in einem Talk auf der FlutterCon 2026, der mich seitdem beschäftigt: Wie bringst Du Agenten dazu, Code zu schreiben, der in Deinem Projekt auch bleiben darf? ## Warum Agenten Durchschnittscode schreiben Die Erklärung im Talk war ziemlich simpel. Modelle haben aus dem Internet gelernt. Wenn Du nichts weiter sagst, bekommst Du den Durchschnitt des Internets. Und der Durchschnitt ist nicht schlecht, aber eben auch nicht Dein Standard. Ich glaube, das ist der wichtigste Denkschritt überhaupt. Das Problem ist nicht, dass die KI zu dumm ist. Sie weiß einfach nicht, wie Ihr Dinge macht. Also musst Du es ihr beibringen. Und zwar an mehreren Stellen, nicht nur in einem Prompt. Das Team hinter dem Talk, Very Good Ventures, hat dafür ein Plugin gebaut. Nach eigener Aussage ist es Open Source. Es besteht aus drei Teilen: Skills, Hooks und festen Tools. Das Prinzip dahinter lässt sich auf jedes Projekt übertragen. ## Skills: Dein Standard als Datei Ein Skill ist im Kern eine Datei mit Metadaten (Name, Beschreibung) und einem Textteil. Im Textteil stehen Standards, Ordnerstruktur, Codebeispiele, Teststrategie und Anti-Patterns. Der Clou: Die Beschreibung entscheidet, ob der Agent den Skill überhaupt zieht. Du schreibst einen Prompt, der Agent gleicht ihn mit den Beschreibungen aller Skills ab und lädt bei einem Treffer den passenden Inhalt in den Kontext. Vorher kostet der Skill kaum etwas. Erst wenn er gebraucht wird, landen ein paar tausend Tokens im Kontext. Alternativ rufst Du ihn direkt per Slash-Befehl auf. Das Plugin liefert 15 Skills, grob in vier Gruppen: - **Architektur:** [Bloc](https://bloclibrary.dev), Schichtenarchitektur, Navigation - **UI:** Material-Theming, UI-Packages, Accessibility, Internationalisierung, Animationen - **Qualität und Sicherheit:** Testing, Security, Lizenzprüfung - **Betrieb:** Projekt anlegen, SDK- und Analyse-Upgrades Die Beispiele aus dem Talk zeigen, was das konkret ändert. Ohne Skill: Cubit mit hartverdrahtetem Repository und mehreren Flags. Mit Skill: Sealed Classes für Events und States, Repository per Konstruktor injiziert, Tests mit [Mocktail](https://pub.dev/packages/mocktail). Ohne Skill: Strings und Farben im Widget. Mit Skill: Theme, `ColorScheme` und Lokalisierung. Bei der Navigation: typisierte Routen statt String-Pfade, die der Compiler prüft. Gerade Accessibility und Internationalisierung fallen unter Zeitdruck als Erstes hinten runter. Genau das ist ein guter Job für einen Skill. Der vergisst nichts, weil Deadline ist. ## Hooks: Nicht darauf hoffen, dass das Modell dran denkt Skills sind Anleitungen. Ob der Agent sie befolgt, bleibt trotzdem ein Stück weit Wahrscheinlichkeit. Der zweite Teil des Talks war deshalb für mich der interessantere: Hooks. Ein Hook ist ein Ereignis-Handler. Das Modell-Tooling feuert Events wie "Session startet", "gleich wird ein Tool benutzt" oder "Datei wurde bearbeitet", und Dein Hook kann darauf reagieren. Konfiguriert wird das über eine JSON-Datei. Die Idee dahinter: Verlass Dich nicht auf das Modell, sondern auf deterministische Schritte drumherum. Das Plugin bringt sechs Hooks mit. Drei Beispiele, die im Talk genannt wurden: 1. **Session-Start:** Fehlt das [Very Good CLI](https://cli.vgv.dev) oder ist es veraltet, kommt ein Hinweis. 2. **Vor einem Tool-Aufruf:** Greift der Agent zur CLI, obwohl ein MCP-Server verfügbar ist, wird er zurückgeschickt. Ähnlich bei `flutter test`: Das soll `very_good test` übernehmen, das laut Talk schneller ist. 3. **Nach einer Bearbeitung:** Analyse und Formatierung laufen automatisch. Das Modell muss nicht entscheiden, ob es daran denkt. Der letzte Punkt ist meiner Meinung nach der unterschätzte. Das Modell kennt Deine Lint-Regeln nur ungefähr. Ein Hook, der nach jeder Änderung den Analyzer laufen lässt, kennt sie genau. ## Feste Tools statt Token-Verbrennung Ein Gedanke zieht sich durch den ganzen Talk: Alles, was deterministisch sein kann, soll nicht das Modell erledigen. Beispiel Projekt-Setup. Das Very Good CLI erzeugt neue Projekte aus fertigen Templates ([Mason](https://pub.dev/packages/mason)). Du gibst Paketnamen und Organisation an, fertig. Wenn Du das stattdessen dem Modell überlässt, wartest Du länger, zahlst Tokens und bekommst vermutlich trotzdem nicht die Struktur, die Du wolltest. Beispiel Lizenzen. Du kannst das Modell bitten, die Lizenzen Deiner Abhängigkeiten zu prüfen. Es kann dabei etwas übersehen. Ein Tool, das alle Pakete durchgeht und das Ergebnis zurückmeldet, übersieht nichts. Dazu kommen zwei MCP-Server: der Dart-und-Flutter-MCP-Server und einer für das Very Good CLI. Analysefehler, pub.dev-Suche oder Paket-Scaffolding laufen darüber, nicht über das freie Raten des Modells. Die Mindestgrenze beim Testen ist bei VGV übrigens 100 Prozent Testabdeckung. Ein "Green Gate"-Skill läuft in einer Schleife über Analyse und Tests und beendet die Arbeit erst, wenn alles grün ist. ## Bloc oder Cubit? Eine Frage aus dem Publikum Aus dem Publikum kam die Frage, warum der Skill standardmäßig auf Bloc setzt, obwohl Cubit einfacher ist. Die Antworten fand ich gut, weil sie ehrlich waren: - Bloc ist leichter zu skalieren und vorherzusagen. Events lassen sich verfolgen. - Mit dem `BlocObserver` kannst Du Events und States automatisch tracken, zum Beispiel für Analytics. Bei einem Cubit ist das Event nur eine Methodensignatur, also baust Du den Tracker in die Logik. Dann steckt in Deiner Business-Logik Zeug, das keine Business-Logik ist. - Modelle machen laut Speaker bei Bloc weniger Fehler, weil die Struktur strenger vorgegeben ist. - Wenn Du dem Skill Kontext gibst (kein Analytics nötig, kein Rollback), kann er auch auf Cubit gehen. Ich finde die Haltung dahinter bemerkenswert: Mehr Code, dafür mehr Automatisierung. Wie ich selbst dazu stehe, steht in meinem Artikel zum [State Management in Flutter](https://robocitrus.com/blog/flutter-state-management-2026). Für kleine Apps reicht ein Cubit locker. Für große Codebasen verstehe ich das Bloc-Argument. ## Skills schreibt man nie fertig Drei Learnings zum Schreiben von Skills, die ich mitgenommen habe: **Lass das Modell den ersten Entwurf machen.** Mach ein Feature im normalen Prompt-Dialog fertig, dann bitte den Agenten, daraus einen Skill zu bauen. Skills werden für Modelle geschrieben, nicht für Menschen. Das Modell weiß, wie man sie für ein anderes Modell strukturiert. **Dein Code ist auch eine Referenz.** Der Agent schaut in die bestehende Codebasis. Und, Zitat sinngemäß: Schlechte Muster verbreiten sich schneller als gute. Wenn der Skill A sagt und Dein Code B vormacht, bekommst Du Spaghetti. Deshalb lohnt sich sauberes Scaffolding am Projektanfang. **Bei Legacy-Code sag explizit, was nicht kopiert werden soll.** Der Agent soll Dein neues Wissen befolgen und nicht die alten Bugs nachbauen. Und noch etwas: Der Skill ist nie fertig. Fällt im Team ein schlechtes Muster auf, geht das sofort in den Skill. ## Skills evaluieren, auch mal löschen Der Teil, den ich am meisten mitgenommen habe: Skills müssen gemessen werden. Das Team vergleicht die Ausgabe mit und ohne Skill. Fehlen ohne Skill die Sealed Events oder die Repository-Injection und mit Skill sind sie da, hat der Skill seinen Wert bewiesen. Kommt ohne Skill dasselbe heraus, kann der Inhalt raus und spart Tokens. Wichtig dabei: Modelle sind nicht deterministisch. Der Speaker empfahl, mindestens dreimal zu laufen, damit man einen Mittelwert sieht und nicht einen Zufallstreffer. Und bei jedem neuen Modell neu messen. Was heute nötig ist, kann das nächste Modell schon von allein. ## Was ich daraus mitnehme Ich sehe das als Gegenentwurf zum "Ich prompte einfach besser"-Denken. Bessere Prompts helfen. Aber ein Standard, der nur im Kopf oder im Chatverlauf existiert, überlebt keinen Teamwechsel und keine Modellversion. Mein Fazit in drei Stufen, wie ich sie aus dem Talk verstanden habe: Erst Standards aufschreiben. Dann das, was prüfbar ist, aus dem Modell herausziehen und in Hooks und Tools legen. Dann messen, ob das Modell den Skill überhaupt noch braucht. Passt auch gut zu dem, was ich über [KI in der App-Entwicklung](https://robocitrus.com/blog/ki-in-der-app-entwicklung) schreibe: Code erzeugen ist billig. Der Engpass ist, ihm trauen zu können. Und wer [schneller shippen statt perfektionieren](https://robocitrus.com/blog/schneller-shippen-statt-perfektionieren) will, braucht genau solche Leitplanken, damit Tempo nicht in Chaos kippt. Wie das mit [CI/CD](https://robocitrus.com/blog/was-ist-ci-cd) zusammenspielt, ist die logische Fortsetzung. Am Rande erwähnt wurde noch "Wingspan", ein Workflow obendrauf (Brainstorming, Planung, Build, Review), und der Plan, auch andere Agent-Umgebungen zu unterstützen. Dazu gab es keine Details im Talk, deshalb lasse ich es dabei. ## Fazit Ein Agent schreibt, was er im Internet gesehen hat. Wenn Du etwas anderes willst, brauchst Du drei Dinge: Skills, die Deinen Standard beschreiben. Hooks und feste Tools, die ihn durchsetzen. Und Messungen, die zeigen, ob beides noch etwas bringt. Ob Du dafür das VGV-Plugin nimmst oder Dir eigene Skills baust, ist zweitrangig. Wichtig ist das Prinzip: Vertrau dem Modell beim Schreiben, aber nicht beim Prüfen. --- ## Häufig gestellte Fragen (FAQ) Eine Datei mit Name, Beschreibung und Anleitung. Passt Dein Prompt zur Beschreibung, lädt der Agent den Inhalt in den Kontext und hält sich an die dort beschriebenen Standards und Beispiele. Du kannst ihn auch direkt per Slash-Befehl aufrufen. Skills sind Anleitungen, die das Modell lesen und befolgen soll. Hooks sind Ereignis-Handler, die automatisch laufen, zum Beispiel Analyse und Formatierung nach jeder Dateiänderung. Hooks hängen nicht davon ab, ob das Modell daran denkt. Laut Talk ist Bloc der robustere Default für große Codebasen. Die Events sind nachvollziehbar, Analytics lassen sich über den BlocObserver automatisieren, und Modelle machen bei der festen Struktur weniger Fehler. Für kleine Projekte ohne diese Anforderungen kann ein Cubit reichen. Templates sind schneller, kosten keine Tokens und liefern jedes Mal dieselbe Struktur. Das Very Good CLI erzeugt neue Projekte aus geprüften Vorlagen. Das Modell muss dafür nur das Tool aufrufen. Vergleiche die Ausgabe mit und ohne Skill, und zwar mehrfach, mindestens dreimal, weil Modelle nicht deterministisch sind. Kommt dasselbe heraus, ist der Skill überflüssig und kann gekürzt werden. Bei neuen Modellversionen wiederholen. --- *Dieser Artikel wurde inspiriert vom Talk des Very-Good-Ventures-Teams zum Flutter-AI-Plugin auf der FlutterCon 2026.* ## Sitemap See the full [sitemap](https://robocitrus.com/sitemap.md) for all pages.