UI-Redesign mit Claude Code und impeccable: Prompts und Ergebnisse

Zwischen 27. September und 12. Oktober haben wir vier Oberflächen mit dem Agent-Skill impeccable in Claude Code überarbeitet:

• timecockpit.com: Astro, MDX, Bootstrap-SCSS
• software-architects.com: Astro, MDX, Bootstrap-SCSS
• den Zeitbuchungskalender der Angular-Webanwendung von time cockpit
• time cockpit sidekick: eine Electron-App, die lokale Arbeitssignale sammelt (aktive Fenster, Git, Dateiänderungen, KI-Sessions)

Gearbeitet haben wir mit dem Modell Claude Opus 5.5, in einem Teil der Sessions zu timecockpit.com und time cockpit zusätzlich mit Claude Fable 5.1. Ein Designer war nicht beteiligt.

impeccable ergänzt den Agenten um Designwissen und um Befehle wie critique (Bewertung mit Punkten), generate (Varianten eines Elements) und polish (Feinschliff). Wie der Skill aufgebaut ist, steht weiter unten. Dieser Artikel zeigt zuerst den Ablauf und die Ergebnisse, dann die Grenzen. Alle Prompts sind im Original zitiert, inklusive Tippfehlern.

Der Ablauf

Fast jede Änderung lief nach demselben Muster.

1. critique auf den Ist-Zustand.
   • Die Startseite von timecockpit.com bekam 21 von 36 Punkten. Befund: generisches SaaS-Template, das Hauptversprechen kommt sechsmal vor, der Hero zeigt kein Produkt.
   • Der Footer bekam 24 von 40 Punkten: 45 gleichwertige Links und auf dem Handy 1.720 px hoch.
2. Varianten erzeugen, meist mit /impeccable generate 3 Entwürfe für <Bereich>.
3. Auswählen. Die Rückmeldung ist meist eine Nummer mit Korrektur:
   • „Nimm 2a“
   • „nimm Variante 2 aber in Farbe“
   • für sieben Funktionsseiten auf einmal: „A, B, C, A, A, A, A“
4. Einbauen, dann polish. In unseren Sessions griff polish die offenen Prioritäten der letzten Kritik auf. Danach folgten Screenshots bei 390, 768, 1024 und 1440 px, nach größeren Änderungen eine neue critique.

timecockpit.com

Hero der Startseite

Der Hero ging durch drei Stände. Am 29. September bestand er nur aus Text; die Kritik bemängelte, dass er kein Produkt zeigt. Als Antwort darauf kam ein echter Screenshot des Kalenders neben die Überschrift, doch auf dem Handy war er unlesbar. impeccable ging dann über Skizzen-Varianten. Mit diesem Prompt entstand schließlich eine eigene SVG-Komponente mit Demodaten:

/impeccable generate 3 versionen einer vereinfachten Produktgrafik als Vektorgrafik. gleiche Struktur und echte Daten, aber mit weniger Details, größerer Schrift und in den Markenfarben. Auf dem Handy bleibt sie lesbar, was beim echten Screenshot nicht gelingt, und sie wirkt ruhiger als die Skizzen.

Funktionsseiten

Die Texte der Funktionsseiten waren bereits für Suchmaschinen optimiert. Damit sie unverändert bleiben, haben wir das in jedem Prompt ausdrücklich vorgegeben:

/impeccable generate 3 Entwürfe für einen Hero Bereich einer Funktionen Seite. Nimm als Beispiel /de/mcp-server-ki-assistenten/. Die Texte sind schon SEO optimiert und sollen nicht mehr geändert werden. Grafiken dürfen gerne geändert werden.

Preisseite

Die Preisseite zeigt, wie man auf einer Variante weiterarbeitet. Der erste Prompt deckte drei Bereiche ab:

/impeccable generate 3 Vorschläge für den Hero Bereich, die Preis Kacheln und die Features Tabelle auf /de/preis/

Von Variante C gefiel uns der dunkle Hintergrund, die Kacheln noch nicht. Der zweite Prompt baute darauf auf:

/impeccable generate noch 3 Vorschläge nur für die Preiskacheln auf dunklem Hintergrund wie in C

Mobiles Menü

Hier ging der Prompt von einem konkreten Fehler aus:

/impeccable generate 3 Entwürfe für das Menü in der mobilen Ansicht. Im Moment kann man die Sprache schlecht umschalten weil das Cookie Icon die Buttons verdeckt. Und scrollen geht nur manchmal.

Regeln und Punkte

Regeln, die wir mehrfach korrigieren mussten, haben wir einmal allgemein formuliert. Ein Beispiel: „Wenn danach oder davor ebenfalls ein farbiger Hintergrund ist, dann soll dazwischen kein weißer Streifen sein.“

Die Kritik-Punkte nach dem Umbau:

So kommen die Punkte zustande:

• critique bewertet die Usability nach den zehn Heuristiken von Nielsen mit je 0 bis 4 Punkten.
• Heuristiken, die für eine Seite nicht passen, zählen als n/a. Deshalb sind die Höchstwerte verschieden (40, 36, 32 …).
• Dazu kommen ein Design-Review und automatische Prüfungen mit dem Detector und im Browser.

Die Punkte vergibt das Modell. Sie eignen sich zum Priorisieren und zum Vergleich desselben Bereichs vorher und nachher, nicht als objektive Messung.

software-architects.com

Zwischen dem ersten und dem letzten Prompt lagen rund 27 Stunden (7. Oktober, 15:35 Uhr, bis 8. Oktober, 19:00 Uhr). Aktiv waren die Sessions davon rund neun bis zehn Stunden, mit etwa 100 Prompts. Gemessen haben wir das an den Session-Protokollen, gezählt sind Abschnitte ohne Pause über 15 Minuten. Wie viel davon Laufzeit des Agenten und wie viel unsere eigene Arbeit war, lässt sich daraus nicht sauber trennen.

Palette

Den Anfang machte eine Bestandsaufnahme: /impeccable was ist das aktuelle farbschema?. Auf die Antwort folgte die eigentliche Vorgabe:

primary, secondary and tertiary behalten wir, aber flächen hätte ich gern in grau Schattierungen, fast schwarz für header und footer, mach mir dafür eine palette

impeccable schlug eine Palette vor und wies zusätzlich auf Kontrastprobleme der Markenfarben hin, die schon vorher bestanden: Das Primärblau #25a0da erreicht auf Weiß nur 2,95:1, das Grün #72bf44 2,3:1, das Violett auf dunklem Grund 3,8:1. Die Korrekturen hätten verändert, wo und wie die Markenfarben eingesetzt werden, etwa Links im dunkleren Blau. Weil wir die Markenfarben in diesem Schritt unverändert lassen wollten, haben wir nur die Palette umgesetzt („ja, setz es um exklusive Kontrast-Korrekturen“):

• Primär-, Sekundär- und Tertiärfarbe bleiben.
• Flächen werden zu einer neutralen Grauskala.
• Header und Footer werden fast schwarz.

Geprüft wurde danach das Erscheinungsbild im Browser, nicht der Kontrast. Die Kontrastprobleme der Markenfarben sind bisher nicht behoben; sie stehen unter „Was wir als Nächstes ändern“.

Hero der Startseite

Er brauchte drei Runden:

1. Die ersten Entwürfe stellten .NET in den Mittelpunkt.
2. Nach dem Prompt „stell .NET nicht so in den Vordergrund, wir machen auch andere Sachen, Azure und AI ist wichtiger“ entstand eine overdrive-Variante mit Azure und KI als Umlaufbahnen.
3. Diese haben wir am nächsten Tag durch einen zweispaltigen Hero ersetzt („ohne die kreise mit etwas weniger höhe“).

Restliche Seiten

Die übrigen Seiten liefen im Live-Modus, gesteuert mit einem einzigen Satz pro Seite: „Jetzt mach das selbe für /de/vortraege-und-trainings/ - impeccable für jeden block.“ Von 34 Live-Sessions haben wir 22 übernommen und 12 verworfen.

Auf der Seite Individualprojekte haben wir die Illustrationen gestrichen („Nimm 1, aber die Graphiken verwenden wir nicht weiter. Sollen wir neue bolder Graphiken machen, oder können wir textuell noch Farbe reinbringen?“). Die Farbe steckt jetzt in der Schrift, dazu kommt eine Sprungliste zu den Leistungen.

Ein Problem: Das Übernehmen einer Variante per Klick funktionierte bei MDX-Seiten nicht. Claude hat die gewählte Variante dann von Hand in die MDX-Datei übertragen.

Das Stylesheet

Die zentrale Datei _user.scss wuchs in diesen 27 Stunden von 1.358 auf 5.089 Zeilen. Der Zuwachs besteht fast nur aus neuen Abschnitten für einzelne Seiten und Blöcke: 21 Commits brachten zusammen 4.171 neue und 440 gelöschte Zeilen. Nur zwei Commits haben unterm Strich Zeilen entfernt, der Austausch des Orbit-Heros und der ruhigere Footer.

Erwartbar war das insofern, als jeder Block ein eigenes Layout bekam. Eine systematische Durchsicht auf doppelte Regeln, ungenutzte Selektoren und Überschreibungen hat aber noch nicht stattgefunden. Sie steht auf unserer Liste für die nächsten Schritte.

Mobiles Menü

Am mobilen Menü sieht man den Ablauf im Kleinen. Prompt: /impeccable generate vorschläge für das mobile menu. Die Auswahl mit einer Korrektur: „nimm Variante 3, aber zeig es oben an weil das burger menu ja auch oben ist“.

time cockpit sidekick

sidekick war Ende September ein Prototyp für Entwickler:

• Reiter oben, ein „TEST“-Badge
• Version, API-URL und Temp-Pfad in der Kopfzeile
• neun gleich gewichtete Einstellungskarten

Die erste critique für Einstellungen und Koppeln ergab 19 von 40 Punkten. impeccable stuft Befunde dabei in vier Stufen ein, P0 bis P3; die Einstufung nimmt das Modell vor. P0 heißt, die Aufgabe lässt sich gar nicht erledigen, P1 heißt, sie wird erheblich erschwert und soll vor einem Release behoben werden. Die P1-Befunde waren funktional:

• Änderungen gingen beim Reiterwechsel verloren.
• Das Koppeln wurde nie abgeschlossen.
• Kontrast nur 3,2:1.

Behoben haben wir die ersten beiden im Code, nicht nur in der Darstellung:

• Die Einstellungen merken ungespeicherte Änderungen je Bereich und markieren sie mit einem farbigen Punkt.
• Das Koppeln ist jetzt ein Ablauf in drei Schritten mit einer Statuszeile bis zum ersten Lesen durch den Kalender. Das Zugriffsprotokoll steht daneben in ganzen Sätzen statt als technische Liste.

Die Shell (Navigation und Rahmen um die Inhalte) entstand aus zwei Prompts:

/impeccable generate 3 Vorschläge für das generelle Look & Feel des Signal Trackers passend zur https://www.timecockpit.com. $primary: #25a0da;$secondary: #72bf44;$tertiary: #ab4a9c; Es geht noch nicht um die Details innerhalb der Tabs sondern um die Shell außen herum.

/impeccable generate 3 Varianten der Shell in der das Menü links und der rechte Bereich einheitlicher wirken. Durch das grau rechts sieht es aus als ob es ein anderes Fenster wäre als der dunkelblaue Bereich.

Spätere Prompts wurden konkreter, zum Beispiel: „Die Signaldetails sollten über die ganze Höhe gehen und ganz rechts abschließen. Können wir die Kästchen mit abgerundeten Ecken vermeiden?“

Vor der Freigabe des Downloads lief am 11. Oktober noch eine critique über alle Teile der App: 27 von 40 Punkten. Die vier P0-Befunde betrafen keine Optik mehr. Stand 13. Oktober:

Die vier P1-Befunde dieser Kritik sind ebenfalls seit dem 12. Oktober behoben: Entwicklertexte vor Endnutzern, immer offene Feineinstellungen, kein Hinweis beim Schließen des Fensters und ein Token, das beim Reiterwechsel verschwand.

Angular-App

Der Zeitbuchungskalender zeigt dieselben Signale wie sidekick. Nachdem sidekick überarbeitet war, sollte die Angular-App dieselbe visuelle Sprache übernehmen, ohne ihr eigenes Theme zu verlieren:

/impeccable generate entwürfe für die signal detail spalte in der Angular App. Die Bereichsüberschriften wie KI und Dateien sollen ähnlich wie in sidekick sein. Versuchen wir einen weißen Hintergrund mit linke links wie in sidekick für die lane. Aber es soll trotzdem zum Design der Angular App passen.

Hier haben wir ausdrücklich Elemente aus einer anderen App verlangt; der letzte Satz begrenzt, wie viel davon übernommen wird. Übernommen wurden die Bänder, die aufklappbaren Zeilen und die Spaltenköpfe aus sidekick. Farben, Schrift und Abstände blieben die der Angular-App; die Akzentfarbe kommt weiterhin aus dem jeweiligen Mandanten.

Wie impeccable technisch arbeitet

impeccable ist ein Agent-Skill von Paul Bakaus (Quellcode auf GitHub, Doku auf impeccable.style/docs). Installiert wird er mit npx impeccable install, aktualisiert mit npx impeccable update. Die Angaben beziehen sich auf die bei uns installierte Version 4.3.1 und die Online-Doku vom Oktober 2026.

Der Skill besteht aus drei Teilen:

• SKILL.md und Referenzdateien: je Befehl eine Referenzdatei unter reference/. Claude lädt nur die Datei des aufgerufenen Befehls, zum Beispiel critique.md oder polish.md.
• Ein kleines Binary (scripts/impeccable): Es lädt zu Beginn den Projektkontext (siehe unten).
• Ein Detector-Hook: Er läuft nach jeder Änderung an UI-Dateien und meldet Anti-Patterns, etwa zu geringen Kontrast, zu wenig Innenabstand oder Großbuchstaben im Fließtext. In Claude Code steht er in .claude/settings.local.json und gilt damit nur auf dem eigenen Rechner. Ausnahmen für einzelne Werte trägt der Agent mit Begründung in .impeccable/config.json ein.

Die Doku teilt die Befehle in diese Gruppen:

Kontextdateien

Wie gut die Ergebnisse zum Projekt passen, hängt vom Kontext ab. Der ist laut Doku auf drei Orte verteilt:

Bei uns ist das unvollständig. timecockpit.com und sidekick haben eine PRODUCT.md, software-architects.com hat keine Kontextdatei, und eine DESIGN.md gibt es nirgends. Die Gestaltungsregeln von timecockpit.com stehen in .impeccable/design.json, etwa „Green Means Go“ (pro Band genau eine grüne Aktion) und „Lift the Evidence“ (Schatten nur für echte Inhalte wie Screenshots und Porträts). Laut Doku ist design.json aber generierte Metadaten, die document neben DESIGN.md schreibt und die man nicht von Hand pflegt.

Varianten: generate und live

generate und live erzeugen Varianten eines Elements direkt in der laufenden Seite. Der Live-Modus ist laut Doku noch Beta. Sie blättern durch die Varianten und übernehmen eine mit „Accept“ in den Quellcode.

• generate: Sie nennen im Chat Element, Richtung und Anzahl, zum Beispiel /impeccable generate 3 bold variants of the pricing cards. Erlaubt sind 1 bis 8 Varianten, ohne Angabe sind es drei.
• live: Sie wählen das Element selbst im Browser aus und können Kommentare oder Striche dazu zeichnen.

Varianten behalten die bestehende Gestaltung der Oberfläche bei, in der sie stehen. Wer davon abweichen will, muss ausdrücklich ein Redesign verlangen. Einen eigenen Befehl dafür gibt es nicht: Man schreibt es als freie Anfrage an /impeccable, im Beispiel der Doku etwa /impeccable redesign the marketing site. Keep the product facts and signup flow, but replace the current visual style. Das startet einen eigenen Ablauf mit Richtungswahl und, wenn Bildgenerierung verfügbar ist, Mockups vor dem Code.

generate war unser häufigster Einstieg: 93 der 114 Aufrufe auf timecockpit.com. Dort entstanden die Varianten allerdings meist nicht in der Seite, sondern als HTML-Entwurfsdateien mit Playwright-Screenshots für Desktop und Handy. Auf software-architects.com lief dagegen alles im Live-Modus. Dass das Übernehmen per Klick bei MDX scheiterte, passt zu einem Hinweis der Doku: Bei Seiten, die aus einer anderen Datei erzeugt werden, muss die Änderung die eigentliche Quelle erreichen.

Grenzen

• Logo: Für software-architects.com entstanden drei Verfeinerungen des bestehenden Logos und drei neue Konzepte. Übernommen haben wir keines.
• Saldo-Balken: Im Angular-Kalender haben wir eine von fünf Varianten umgesetzt und wieder zurückgenommen.
• Inhaltliche Fragen: Fragen wie „Schrecken wir damit kleinere Kunden ab?“ beantwortet der Skill nicht verlässlich. Was impeccable über Zielgruppe und Positionierung weiß, kommt aus PRODUCT.md. Marktwissen ersetzt das nicht.
• Zahlen in generierten Grafiken: Eine critique fand im Hero von timecockpit.com Stunden, die in der Summe nicht aufgingen. Die Grafik hatte impeccable selbst erzeugt. Zahlen in generierten SVGs müssen Sie prüfen.
• Regeln nur im Prompt: Die Regel „kein weißer Streifen zwischen farbigen Bändern“ haben wir nur im Chat formuliert, nicht in einer Kontextdatei. impeccable kennt sie in der nächsten Session nicht.
• Live-Modus und MDX: Der Live-Modus ist Beta. Das Übernehmen per Klick funktionierte bei MDX-Seiten nicht.

Was sich bewährt hat

Diese Punkte haben wir selbst so gemacht, und sie haben funktioniert:

• Varianten statt einer Lösung. Drei Entwürfe nebeneinander klären schneller, was wir wollen, als eine lange Beschreibung. Bei Bedarf arbeitet man auf einer Variante weiter, wie bei den Preiskacheln.
• Kurz und konkret antworten. Nummer plus Korrektur reicht, etwa „Nimm 2 ohne der blauen Striche über den Überschriften“.
• Element und Richtung benennen. Eine URL oder CSS-Klasse plus eine Richtung, etwa „5 bold versions of the menu bar, keep the dark background“.
• Nennen, was bleiben muss, zum Beispiel „ohne Texte zu ändern“, „kein weißer Streifen“, „nicht pastell“, „ohne die Kreise“.
• Erst critique, dann polish. Die Kritik liefert die Reihenfolge, und polish griff ihre offenen Prioritäten in unseren Sessions auf.
• Begrenzt prüfen. Playwright-Screenshots bei 390, 768, 1024 und 1440 px nach jedem Umbau. Die Doku empfiehlt dasselbe Maß: Desktop und Handy in einem Durchgang, alles auf einmal beheben, höchstens eine weitere Runde.

Was wir als Nächstes ändern

Folgende Empfehlungen aus der Doku haben wir bisher nur teilweise umgesetzt:

• Kontextdateien vollständig anlegen. init für PRODUCT.md auf software-architects.com, document für eine DESIGN.md auf allen Projekten. /impeccable doctor findet veralteten Kontext und kaputte Hooks.
• Wiederkehrende Korrekturen in die Kontextdateien schreiben statt in den Prompt: Gestaltungsregeln nach DESIGN.md, Zweck und Richtung einer Seite nach .impeccable/surfaces/.
• Den Detector-Hook fürs Team einrichten. Entweder schaltet ihn jedes Teammitglied mit /impeccable hooks on ein, oder er kommt in die geteilte .claude/settings.json.
• Vor der Veröffentlichung audit laufen lassen, für Barrierefreiheit, Performance und Responsive-Verhalten. Wir haben es kaum verwendet.
• Den Kontrast der Markenfarben auf software-architects.com beheben, vor allem Primärblau und Grün als Text auf Weiß.
• Das Stylesheet von software-architects.com durchsehen auf doppelte Regeln und Überschreibungen.

Fazit

Bewährt haben sich bei uns drei Dinge: Varianten zum Vergleichen statt einer einzigen Lösung, kurze konkrete Rückmeldungen und Screenshots auf allen Breiten als Kontrolle. Die Kontextdateien, die impeccable vorsieht, haben wir nur teilweise angelegt. Sie sind unsere nächste Verbesserung, damit Regeln nicht in jedem Prompt neu stehen müssen und auch in der nächsten Session gelten.

Kontext, Skills, Hooks sowie Tests und Review-Schleifen sind die Bausteine, die wir als Harness Engineering für Entwicklungsteams einrichten, die Coding-Agenten wie Claude Code, GitHub Copilot oder OpenAI Codex in ihrer eigenen Codebasis einsetzen.