designloop

Was macht designloop?

Eine Schleife, die die Qualität eines bestehenden Interfaces (oder der darin und darum herum geschriebenen Texte) durch Messen und nicht durch Raten verbessert. Jede Runde: die UI erfassen (oder einen Text-Snapshot erstellen) auf die gleiche Weise, frische Bewerter nach einem festen Kriterienraster bewerten lassen, die gefundenen Probleme beheben, wiederholen. Es ist modelliert nach der Bewertungsmethode von dream-loop (frischer Bewerter pro Runde, pingelig, Regressionen werden niedriger bewertet), angewandt auf UI-Politur anstatt auf das Erreichen eines Zielbildes, und auf Theos (t3.gg) Hill-Climbing-Ansatz für UI-Design in Agents Sucked At UI (Until Today).

Die Schleife funktioniert aufgrund von drei Trennungen. Halte sie ein:

• Bewerter setzen nie um und Umsetzer bewerten nie. Ein Agent, der die Korrektur geschrieben hat, bewertet sie zu großzügig.
• Bewerter sind jede Runde frisch. Ein Bewerter, der die vorherige Runde gesehen hat, verankert seine Bewertung an seinem eigenen früheren Urteil. Gib einem neuen Bewerter das Kriterienraster, die neuen Erfassungen und das vorherige Urteil (damit die Bewertung konsistent bleibt und Regressionen benannt werden), nicht das Gespräch.
• Der Erfassungssatz ist festgelegt. Punkte sind nur vergleichbar, wenn Runde N dieselben Oberflächen, Zustände und Themen zeigt wie Runde 0.

Drei Modi

Die Schleife ist in allen drei Modi gleich; was die Bewerter messen, unterscheidet sich. Lege zuerst den Modus fest, denn er bestimmt das Kriterienraster, die relevanten Fragen und wie viel Veränderung erwartet wird.

• Professionelle Politur — ein objektiver Durchgang, die Dinge, die ein Senior Product Designer prüft: einheitliche Verwendung eines Token-Sets und von Oberflächen, weniger Schriftgrößen und -gewichte, eine konsistente Abstandsskala, Lesbarkeit und Kontrast, Trefferzonen und Cursorbereiche, Zustandsabdeckung, Light/Dark-Parität, Bewegungsqualität. Das Ziel ist das bestmögliche Selbst der App; Geschmacksänderungen sind ausgeschlossen. Lese references/mode-polish.md.
• Künstlerische Ausrichtung — ein subjektiver Durchgang hin zu einem bestimmten Look & Feel: einem benannten Stil ("grafischer Realismus", "Neon-Pop mit ASCII-Kunst und brutalen, dynamischen Layouts"), einer Reihe von Referenzen, einem generierten Zielbild oder einem Figma-Design, das es zu erreichen gilt. Die Bewerter bewerten, wie gut die UI diese Richtung ausdrückt. Es werden größere visuelle Veränderungen erwartet, daher sind Schriftarten, Farben und Layout-Charakter im Spiel. Lese references/mode-art-direction.md.
• Schreiben — die Schleife, angewandt auf Wörter: UI-Texte (Labels, Fehlermeldungen, Leerzustände, Onboarding), Dokumentationen und Produktseiten oder eigenständige Texte. Bewerter bewerten Klarheit, Prägnanz, Ton, Konsistenz und Genauigkeit für einen benannten Leser, untermauert durch Lesertests (ein frischer Agent liest den Text kalt und sagt, was er tun würde). Der Inhalt bleibt fest; die Worte werden besser. Lese references/mode-writing.md, das beschreibt, wie sich jeder der folgenden Schritte ändert (Texte statt Oberflächen, Snapshots statt Erfassungen, ein Glossar statt Token).

Leite den Modus aus der Anfrage ab, wenn er klar ist ("straffen", "konsistent", "schlampig" → Politur; "mach es wie", "künstlerischer", ein Stilname, ein Figma-Link → künstlerische Ausrichtung; "Text", "Formulierung", "Doku", "Fehlermeldungen", "dieser Beitrag" → Schreiben), frage andernfalls nach. Ein Benutzer kann mehr als einen wollen: führe zuerst die künstlerische Ausrichtung durch, um den Look festzulegen, dann einen Politurdurchgang zur Konsistenzsicherung und einen Schreibdurchgang für die Texte, jeweils als eigene Schleife mit eigenem Kriterienraster. Vermische sie nicht in einem Kriterienraster, sonst handeln Bewerter Konsistenz gegen Stil aus und die Bewertungen werden bedeutungslos.

Schritt 1: Befrage den Benutzer

Lege den Modus fest, frage dann den Rest mit AskUserQuestion (zwei Aufrufe; es dauert bis zu vier Fragen pro Aufruf). Überspringe jede Frage, die die Nachricht des Benutzers bereits beantwortet hat, und biete zuerst eine empfohlene Option an. Die Antworten kommen in die Brief-Datei (Schritt 3), die jeder Subagent liest.

1. Ziel — Was soll am Ende besser sein, in seinen eigenen Worten? ("Chrome fühlt sich inkonsistent an", "Menüs sind schlampig", "fühlt sich ruckelig an".) Frage auch, was tabu ist: Oberflächen, die sie selbst bearbeiten wollen, und wie viel Veränderung sie akzeptieren werden (straffen vs. umstylen vs. neugestalten). Die meisten Benutzer wollen Straffen, kein Neudesign; sag das in jedem Brief, sonst übertreiben die Umsetzer.
2. Schwerpunkt (Mehrfachauswahl) — welche Dimensionen am wichtigsten sind; dies setzt die Gewichtung des Kriterienrasters. Die Optionen hängen vom Modus ab und sind in der entsprechenden Referenzdatei aufgeführt (Politur: Konsistenz und Token, Typografie, Abstand und Layout, Lesbarkeit, Interaktion und Trefferzonen, Bewegung, Performance; künstlerische Ausrichtung: die Merkmale des gewählten Looks und welche Teile der UI ihn tragen sollen; Schreiben: Klarheit, Prägnanz, Struktur, Stimme und Ton, Konsistenz, Nützlichkeit, Genauigkeit). Frage im Schreibmodus auch die zusätzlichen Fragen aus references/mode-writing.md (Leser und Zweck, Stimmproben, was festgelegt ist, Längen- und Lokalisierungsbeschränkungen).
3. Ausgangsbasis — Wo steht die UI heute? Entweder gibt der Benutzer eine Bewertung von 10 Punkten, oder die Bewerter bewerten sie zuerst. Empfehle beides, wenn der Benutzer eine Meinung hat: Seine Zahl kalibriert die Bewerter (wenn er 6 sagt und die Bewerter sagen 8, ist das Kriterienraster zu weich — straffe es vor Runde 1).
4. Abbruchbedingung — eine Zielpunktzahl (z. B. ≥9/10 in jeder Gruppe und jedem Thema), eine Anzahl von Runden oder beides, je nachdem, was zuerst eintritt. Empfehle "Zielpunktzahl, gedeckelt auf N Runden". Warne, dass eine unbegrenzte Schleife viele Token verbrauchen kann.
5. Intelligenz der Subagenten — welches Modell und welcher Aufwand für Bewerter und Umsetzer verwendet werden. Biete an: bestes verfügbares (langsamstes, gründlichstes), ausgewogen (Modell und Aufwand der Sitzung selbst), schnell (günstigeres Modell für Erfassung und mechanische Korrekturen, starkes Modell für die Bewertung). Die Bewertung ist der Bereich, in dem sich Intelligenz am meisten auszahlt; wenn der Benutzer sparen will, spare zuerst bei der Erfassung und der mechanischen Umsetzung.
6. Referenzen — Hat der Benutzer Designs, die ihm gefallen oder die er erreichen muss? Websites, Apps, Screenshots, ein Figma-Link, ein Designsystem oder eine benannte Richtlinie oder Fähigkeit (eine Plattform-HIG, eine Design-Engineering-Fähigkeit). Frage, was ihm an jeder gefällt (die Dichte, die Menüs, die Bewegung), denn "wie diese Seite" ohne Grund wird vollständig kopiert. Im Poliermodus sind Referenzen optional und normalerweise Richtlinien. Im Modus für künstlerische Ausrichtung benötigt die Schleife ein Ziel: eine Stilbeschreibung, Referenzen, ein Figma-Design oder ein generiertes Bild; wenn der Benutzer keines hat, biete an, welche zu sammeln oder zu generieren (siehe „Referenzen und Ziele").
7. Lieferung — nur ein Branch, ein PR (nicht gemerged) und/oder ein Build, den sie ausführen können. Standard: Branch + nicht gemergter PR. Merge oder veröffentliche niemals, es sei denn, sie bitten darum.

Lege alles, was der Benutzer dir gegeben hat, in .designloop/references/ ab (Schritt 3) und liste es im Kriterienraster auf, damit jeder Bewerter und Umsetzer aus denselben Quellen arbeitet.

Schritt 2: Studiere die Einrichtung des Projekts

Bevor du irgendwelche Regeln schreibst, finde heraus, wie dieses Projekt tatsächlich ausgeführt, getestet und ausgeliefert wird, damit die Schleife den Gewohnheiten des Benutzers folgt, anstatt ihre eigenen aufzuzwingen. Schaue zuerst, frage dann: Lese, was dir das Repository und der Rechner sagen können, und frage nur nach Dingen, die noch unklar sind oder eine Frage der Präferenz darstellen.

Suche nach:

• Bereits vorhandene Anweisungen: CLAUDE.md / AGENTS.md, README und CONTRIBUTING, Memory-Notizen und alle früheren Agenten-Regeldateien. Diese haben Vorrang vor allem, was abgeleitet wird.
• Wie die App läuft und wie sie gesteuert werden kann: Package-Scripts, Makefile, Dev- vs. Production-Builds und was sie erfassen kann (Browser/CDP, Playwright, Simulator oder Device-Tooling, eine vorhandene Screenshot- oder e2e-Einrichtung). Wenn nichts die App automatisch steuern kann, sag das und frage, wie der Benutzer die Erfassungen haben möchte.
• Die Checks, denen das Projekt vertraut: Type Check, Lint, Tests, Build und ob sie heute bestehen.
• Git-Gewohnheiten: Standard-Branch, Branch-Namenskonventionen, ob Worktrees bereits verwendet werden, Commit-Message-Konventionen, ob Arbeit über PRs läuft.
• Alles, was ein Lauf außerhalb des Repos berühren könnte: echte Konten, kostenpflichtige APIs oder AI-Backends, Messaging, Produktionsdaten, das eigene App-Profil oder die Geräte des Benutzers. Finde heraus, ob es einen Mock-, Demo- oder Sandbox-Modus gibt.
• Ob ein Design-Tool angeschlossen ist: Wenn der Benutzer einen Figma-Link (oder einen anderen Design-Tool-Link) angegeben hat, suche nach einem Connector oder MCP-Server, der ihn lesen kann, und ob er angemeldet ist.
• Ob hier Bilder generiert werden können: Überprüfe, was diese Sitzung tatsächlich aufrufen kann, anstatt es anzunehmen. Einige Harnesses haben eine integrierte Bildgenerierung (Codex hat das); bei anderen kommt sie von einer installierten Fähigkeit, einem Plugin oder MCP-Server (Higgsfield oder jedes andere Bildmodell). Durchsuche die verfügbaren Tools und Fähigkeiten nach einem. Wenn es keinen gibt, funktioniert die Schleife trotzdem; Zielbilder sind optional.
• Rechnerlimits, die für parallele Arbeit wichtig sind: Freier Festplattenspeicher, bereits verwendete Ports, andere laufende Agenten oder Dev-Server.

Bestätige dann mit dem Benutzer in einem einzigen AskUserQuestion-Aufruf nur die Entscheidungen, die du nicht aus dem Gefundenen ableiten konntest. Typische sind:

• Wo gearbeitet werden soll: der aktuelle Branch, ein neuer Branch oder separate Worktrees pro Umsetzer (erforderlich, wenn Umsetzer parallel arbeiten).
• Wie getestet werden soll: nur Dev-Server oder auch der Production/Packaged-Build vor dem Abschluss; welche Themes, Fenstergrößen oder Geräte zählen.
• Was nicht berührt oder ausgegeben werden darf: Echte Konten und kostenpflichtige Dienste und ob ein Mock-Modus für Erfassungen akzeptabel ist.
• Wie viel gleichzeitig laufen soll: Parallele Umsetzer oder nacheinander.

Gib in der Frage an, was du abgeleitet hast ("Ich habe X gefunden, also plane ich Y"), damit der Benutzer es schnell korrigieren kann. Schreibe das Ergebnis in RULES.md (nächster Schritt) und notiere, welche Regeln vom Benutzer stammen und welche du abgeleitet hast.

Schritt 3: Einrichtung

Erstelle einen Arbeitsordner außerhalb des Quellbaums oder einen git-ignorierten .designloop/-Ordner im Repository:

.designloop/
  BRIEF.md        # die Interview-Antworten: Ziel, Umfang in/aus, Änderungstoleranz, Schwerpunkt, Abbruchbedingung
  RUBRIC.md        # aus references/rubric.md, gewichtet für den gewählten Schwerpunkt
  RULES.md         # die Arbeitsregeln dieses Projekts aus Schritt 2 (siehe references/briefs.md)
  references/     # was dem Benutzer gefällt und alle Zielbilder (siehe unten)
  capture/        # die Erfassungsskripte und die Oberflächenliste
  round-0/ …      # pro Runde: Standbilder pro Thema, videos/, index.json, judge-*.md

Schreibe diese, bevor du irgendetwas spawnst. Subagenten beginnen ohne Kontext, daher sind die Dateien der Kontext: Weise Briefe darauf hin, anstatt sie neu zu tippen.

• RUBRIC.md — Beginne mit dem Kriterienraster aus der Referenzdatei des Modus (references/mode-polish.md oder references/mode-art-direction.md), mit dem gemeinsamen Header und dem Ausgabeformat des Bewerters aus references/rubric.md. Passe die Gewichtungen an den Fokus des Benutzers an, schreibe die IN- und OUT-Bereichslisten explizit und definiere, was die volle Punktzahl bedeutet.
• RULES.md — Was Schritt 2 ermittelt hat: wie die App ausgeführt und gesteuert wird, wo in Git gearbeitet wird, die auszuführenden Checks, was nicht berührt oder ausgegeben werden darf und wie aufgeräumt wird. references/briefs.md enthält die Liste der Dinge, die es abdecken sollte.
• Oberflächenliste — Jede Oberfläche im Umfang, jeweils mit den zu bewertenden Zuständen (Ruhe, Hover, Offen, Ausgewählt, Leer, Fehler, Beschäftigt) und jedem Theme. Teile sie in zwei oder drei Gruppen verwandter Oberflächen auf, damit jeder Bewerter genau hinschauen kann; ein Bewerter über fünfzig Screenshots überfliegt nur.

Überprüfe, ob die Checks des Projekts bestehen, bevor du beginnst, damit ein späterer Fehler deiner ist.

Referenzen und Ziele

Ein Kriterienraster sagt, was gut im Allgemeinen ist; Referenzen sagen, was gut für diesen Benutzer aussieht. Der Modus für künstlerische Ausrichtung hat immer ein Ziel irgendeiner Art. Der Poliermodus kann allein mit dem Kriterienraster laufen, wobei die besten eigenen Oberflächen der App als Standard dienen.

Es gibt drei Arten von Zielen, und sie haben unterschiedliche Autorität. Sage, welche Art jede Datei in references/README.md ist, denn Bewerter und Umsetzer müssen sie unterschiedlich behandeln:

• Eine Spezifikation (ein Figma-Design, das der Benutzer erreichen möchte): maßgeblich. Erreiche es.
• Eine Referenz (Websites, Apps, Screenshots, die dem Benutzer gefallen): Erreiche die benannten Merkmale, nicht das Ganze.
• Ein generiertes Bild: eine Richtung nur für das Gefühl.

Vom Benutzer gegebene Referenzen. Speichere sie in .designloop/references/ mit einer kurzen README.md: für jede, was sie ist und was dem Benutzer daran gefällt. Für eine Website oder App erfasse Screenshots der relevanten Teile (und einen Clip, wenn die Anziehungskraft die Bewegung ist), damit Bewerter in jeder Runde dasselbe betrachten, anstatt eine Seite erneut abzurufen, die sich ändern könnte. Wandle die Vorlieben in konkrete, überprüfbare Merkmale im Kriterienraster um ("Zeilenhöhe ca. 28px", "eine Akzentfarbe", "Menüs blenden in unter 200ms ein"), da ein Bewerter ein Merkmal, aber keine Stimmung bewerten kann.

Von dir gesammelte Referenzen. Wenn der Benutzer eine Richtung möchte, aber keine Beispiele hat, schlage drei oder vier bekannte Produkte vor, deren Oberfläche zu seinem Ziel passt, zeige sie und lasse den Benutzer wählen. Wähle nicht für ihn.

Ein Figma-Design. Wenn der Benutzer einen Figma-Link angibt, überprüfe, ob in dieser Sitzung ein Figma-Connector oder MCP-Server verfügbar ist (Schritt 2). Wenn ja, lade seine eigene Fähigkeit oder Anweisungen zuerst, hole dann für jeden verlinkten Frame: eine Wiederholung...