Eine Idee in Code zu verwandeln, dauert mit einem guten KI-Agenten oft nur noch einen Bruchteil der früheren Zeit. Langsam bleibt die Arbeit davor: Was soll entstehen, für wen und woran erkennen wir, dass es fertig ist? Fehlen diese Antworten, füllt der Agent die Lücken mit plausiblen Annahmen.

Bei fehlerhaftem Code meldet sich der Compiler. Eine falsche Produktentscheidung kann dagegen tagelang ordentlich aussehen. Erst spät fällt auf, dass der Ablauf am Nutzer vorbeigeht oder jeder Screen wie eine generische Vorlage wirkt. Ohne dokumentierte Entscheidung lässt sich kaum feststellen, an welcher Stelle das Vorhaben abgebogen ist.

Die sechs hier vorgestellten Angebote sind deshalb keine gewöhnliche Tool-Liste. Es sind Methoden, Spezifikationen und Schnittstellen rund um Coding-Agenten. Einige erzwingen bessere Fragen, andere halten Entscheidungen fest oder liefern Designregeln und Komponenten. Grundlage dieser Einordnung sind die offiziellen Repositories und Dokumentationen mit Stand 7. August 2026, nicht ein künstlicher Leistungsvergleich.

Methode übernehmen, nicht den ganzen Werkzeugschrank

Interviews, Anforderungskataloge, Architekturentscheidungen und Designsysteme enthalten jahrelange Erfahrung. Dass Agenten dieses Wissen heute direkt lesen können, ist nützlich. Alle sechs Werkzeuge gleichzeitig zu installieren, wäre trotzdem ein Fehler.

Fehlende Ebene Werkzeuge Gewünschtes Ergebnis
Fragen, Scope und Ausführungsweg Superpowers, Spec Kit, BMAD Entwurf, Spezifikation, Aufgabenfolge und Prüfpunkte
Gemeinsame visuelle Identität DESIGN.md, taste-skill Farben, Typografie, Abstände, Dichte und No-Gos
Verlässliche UI-Bausteine im Projekt shadcn/ui MCP Auffindbarer und anpassbarer Komponentencode

Meist reichen ein Planungswerkzeug und ein Designwerkzeug. Eine weitere Schicht sollte erst hinzukommen, wenn ein konkretes Koordinationsproblem dafür existiert.

Drei Werkzeuge für belastbare Planung

1. Superpowers: erst fragen, dann bauen

Superpowers ist eher eine Entwicklungsmethode in Form von Agent-Skills als eine Sammlung hübscher Prompts. Der offizielle Ablauf umfasst Brainstorming, eine getrennte Worktree-Umgebung, einen Arbeitsplan, aufgeteilte Umsetzung sowie Tests und Review.

Das hilft bei Anforderungen wie „Bitte Dark Mode ergänzen“. Statt sofort CSS zu ändern, kann der Agent zuerst klären, wer die Funktion braucht, welche bestehenden Themes erhalten bleiben und wie die Abnahme aussieht. Für eine grobe Idee ohne Dokumentation ist das wertvoll.

Für einen Tippfehler wäre das gesamte Verfahren Unsinn. Mehrere Subagenten verbrauchen Kontext und erzeugen zusätzliche Prüfarbeit. Ein Mensch muss weiterhin festlegen, wann eine Änderung echte Gestaltung und wann sie nur Mechanik ist.

Offizielles GitHub-Repository von Superpowers

Superpowers verbindet Fragen, Planung, Tests und Review zu einer Arbeitsweise. Screenshot: offizielles GitHub-Repository.

2. GitHub Spec Kit: von der Anforderung bis zur Aufgabe

Spec Kit ist GitHubs Toolkit für Spec-driven Development. Der Kern lautet Specify, Plan, Tasks und Implement. Eine Constitution kann dauerhafte Projektprinzipien festhalten; Clarify, Checklist und Analyze werden dort ergänzt, wo Unsicherheit besteht. Eine starre Fünf-Schritte-Methode ist es nicht.

Die Stärke liegt in der Spur, die eine Entscheidung hinterlässt. Ändert sich eine Anforderung, lässt sich erkennen, welche Planung und welche Aufgaben ebenfalls angepasst werden müssen. Das passt zu neuen Produkten, Teamprojekten und Vorhaben, deren Entscheidungen später nachvollziehbar sein sollen.

Bei einer kleinen Funktion in einer gewachsenen Anwendung kann der Aufwand größer sein als der Nutzen. Wenn die Pflege der Dokumente länger dauert als das Review, ist ein schlankeres Verfahren wie OpenSpec oft die bessere Wahl.

Offizielles GitHub-Repository von Spec Kit

Spec Kit trennt Prinzipien, Anforderungen, Plan und Aufgaben. Screenshot: offizielles GitHub-Repository.

3. BMAD Method: fehlende Rollen sichtbar machen

BMAD verteilt Produktarbeit auf Rollen wie Analyst, Product Manager, Architekt, Entwickler und QA. Die dokumentierte Methode umfasst eine optionale Analysis sowie Planning, Solutioning und Implementation. Für kleinere Aufgaben gibt es einen eigenen Quick Flow.

Der eigentliche Nutzen ist nicht das Etikett „KI-Team“, sondern die zusätzliche Perspektive. Der Analyst hinterfragt Problem und Zielgruppe, der PM Scope und Abnahme, der Architekt technische Grenzen und QA die Fehlerfälle. Bei einem komplexen Produkt mit mehreren Beteiligten können diese Rollen blinde Flecken aufdecken.

Sie erzeugen aber auch Dokumente, Kontextverbrauch und Review-Aufwand. Ein kurzer Installationsbefehl macht die Methode nicht leichtgewichtig. Sobald die Artefakte größer werden als das Produkt, ist Quick Flow oder ein einfacheres Werkzeug angemessener.

Offizielles GitHub-Repository der BMAD Method

BMAD verteilt Produktfragen auf klar benannte Rollen und Phasen. Screenshot: offizielles GitHub-Repository.

Drei Werkzeuge für Designregeln und Umsetzung

Planung hält fest, was und warum gebaut wird. Design bestimmt, wie der nächste Screen weiterhin nach demselben Produkt aussieht. Viele generierte Oberflächen ähneln sich nicht nur wegen des Modells, sondern weil Angaben zu Marke, Dichte, Interaktion und verbotenen Mustern fehlen.

4. DESIGN.md: Designidentität in einer agentenlesbaren Datei

DESIGN.md von Google Labs ist ein Alpha-Format für eine Designidentität, die Agenten lesen können. Im YAML-Frontmatter stehen strukturierte Werte wie Farben, Typografie und Abstände. Der Markdown-Teil erklärt Gründe, Einsatzbereiche und Grenzen.

Damit müssen Regeln nicht für jeden Screen neu erzählt werden. Das Format ersetzt jedoch kein gestalterisches Urteil. Ton, Kontrast und Rhythmus müssen weiterhin von Menschen festgelegt werden. Auch der Alpha-Status ist ernst zu nehmen: Schema und Werkzeuge können sich ändern.

Offizielles Google-Labs-Repository von DESIGN.md

DESIGN.md speichert visuelle Werte und ihre Begründung gemeinsam. Screenshot: offizielles Google-Labs-Repository.

5. shadcn/ui MCP: Komponenten finden statt erfinden

Der shadcn/ui MCP Server verbindet einen Agenten mit Komponenten-Registries. Er kann verfügbare Bausteine durchsuchen, einen passenden finden und dessen Code direkt ins Projekt installieren. Das ist ein Beschaffungsweg, kein Art Director.

Bekannte Zustände und zugängliche Interaktionen müssen so nicht jedes Mal neu gebaut werden; der Code bleibt trotzdem im eigenen Projekt veränderbar. Wer die Standardkomponenten unverändert zusammensetzt, erhält allerdings schnell eine austauschbare Oberfläche. DESIGN.md gibt die Regeln vor, MCP beschafft nur die Teile.

Offizielle Dokumentation des shadcn/ui MCP Servers

Der MCP Server lässt Agenten Komponenten in konfigurierten Registries suchen und installieren. Screenshot: offizielle shadcn/ui-Dokumentation.

6. taste-skill: schlechte Gewohnheiten vorher benennen

taste-skill ist eine Sammlung von Frontend-Heuristiken für Coding-Agenten. Sie warnt vor typischen generierten Mustern: automatische Zentrierung, immer gleiche Karten, unbelegte Hero-Aussagen, monotone Farbwelten und Bewegung ohne Funktion. Werte wie visuelle Dichte und Bewegungsintensität sollen ausdrücklich festgelegt werden.

Das ist hilfreicher als ein spätes Review mit dem Satz „Es wirkt billig“. Objektiver Designstandard ist die Sammlung dennoch nicht. Version 2 gilt als experimentell, und manches Verbot ist Geschmackssache. Eine Marke mit bewusstem Serifensystem sollte eine pauschale Serif-Regel löschen. Für einen schnellen Themewechsel ist das Paket überdimensioniert.

Offizielles GitHub-Repository von taste-skill

taste-skill setzt Leitplanken für den Agenten, garantiert aber kein gutes Endergebnis. Screenshot: offizielles GitHub-Repository.

Sinnvolle Kombinationen

Situation Erste Kombination Begründung
Nur eine grobe Idee, kein Dokument Superpowers + DESIGN.md Fragen reduzieren Unklarheit; eine Datei hält die ersten Designregeln fest
Neues Produkt im Team Spec Kit + DESIGN.md + shadcn/ui MCP Anforderungen, Gestaltung und Komponentenbeschaffung bilden eine sichtbare Kette
Komplexes Produkt mit mehreren Prüfern BMAD + DESIGN.md, danach taste-skill Perspektiven kommen früh, visuelle Anti-Patterns spät in die Prüfung
Eine Funktion im bestehenden Produkt Ein Planungswerkzeug + vorhandenes Designsystem Die Änderung erhält eine Begründung, ohne ein zweites Betriebssystem einzuführen

Mit jedem Werkzeug wächst auch das Konfliktpotenzial. Constitution, BMAD-Plan und Superpowers-Entwurf können gleichzeitig den aktuellen Stand beanspruchen. Der Agent löst das nicht zuverlässig. Es sollte eine Quelle für Prinzipien und eine für die Ausführung geben.

Vier Prüfungen vor der Installation

  1. Fehlt eine Frage, eine Entscheidungsspur, eine Designregel oder eine Komponente? Ein MCP Server hilft nicht gegen einen unklaren Auftrag.
  2. Welche Datei gewinnt bei Widersprüchen? Constitution, DESIGN.md oder ein anderes Dokument muss ausdrücklich maßgeblich sein.
  3. Mit einer reversiblen Änderung beginnen. Ein Registrierungsformular ist ein besserer Versuch als der komplette Umbau der Startseite.
  4. Menschliche Lesezeit mitzählen. Wenn der Agent mehr Dokumente erzeugt, als das Team prüfen kann, spart der Prozess keine Arbeit.

Keines dieser Werkzeuge entscheidet, für wen ein Produkt gedacht ist und warum diese Person es nutzen sollte. Sie können unausgesprochene Annahmen aber in Fragen, Dateien, Regeln und Komponenten verwandeln, die sich prüfen lassen.

Der Ausgangspunkt bleibt der Nutzer. Wer ist er, was will er erledigen und wo darf der Ablauf nicht scheitern? Ohne diese drei Sätze füllen sechs ausgefeilte Werkzeuge nur die falschen Lücken etwas ordentlicher.

Quellen und Berichte