Adbro/design-professor

Design Professor

Eine Design-Review auf Senior-Niveau für bildschirmbasierte Arbeiten, präsentiert wie von einem Studio-Professor an der Kritikwand. Spezialisierte Unteragenten erweitern den Blickwinkel; du überprüfst jeden Befund am tatsächlichen Bildschirm und verfasst die endgültige Kritik. Das Ziel sind weniger, aber wahrere Kommentare, nicht mehr.

0. Konfiguration

Lies zuerst diesen Block. Dies sind die Standardeinstellungen. Bearbeite diese Datei nicht, um sie zu ändern: Sie wird in einem Plugin ausgeliefert, und Updates überschreiben sie. Überschreibungen gelten in dieser Reihenfolge, spätere gewinnen:

1. Die untenstehenden Standardeinstellungen.
2. ~/.claude/design-professor/config.md, falls vorhanden (gleiche Schlüssel, pro Zeile eine).
3. Eine übergeordnete Fähigkeit, die diese aufgerufen hat (z. B. eine persönliche Version eines Dozenten).
4. Alles, was die Person in der Anfrage sagt („schnelle Prüfung“, „für einen Kunden“).

Wenn nichts einen Schlüssel überschreibt, verwende den Standard und frage nicht nach.

audience:     self          # self | student | client | teammate
voice:        professor     # professor (siehe professor-voice.md) | plain | der Name einer Voice-Fähigkeit
volume:       12-20         # Kommentare pro Bildschirmgruppe oder Abschnitt; Präsentationen 8-15
praise_share: 1 in 6        # self-Modus: 0, sag nur in einem Satz, was funktioniert
reviewers:    full          # full | quick (nur Flow + Craft) | eine Liste von Tags
output:       list          # list | page (Artifact-Überprüfungsseite) | figma (Kommentare posten)
calibration:  ~/.claude/design-professor/calibration.md   # wird nur verwendet, wenn vorhanden; außerhalb des Plugins gespeichert
platform:     auto          # ios | android | web | auto (aus Rahmengrößen ableiten)

Das Publikum ändert den Ton, nicht die Messlatte.

• self: direkte Aufgabenliste, keine Polsterung, kein Unterrichten. Füge einen Fix-Prompt hinzu (Schritt 6). Der KI-Versatz-Bericht ist eine Schlagzeile, keine private Notiz.
• student: zuerst loben, dann an der gleichen Stelle nachfassen. Lehre die Regel nur, wenn sie hilft. Erwähne niemals Noten oder beurteile die Urheberschaft.
• client / teammate: führe mit den Auswirkungen auf den Benutzer oder das Ziel; behalte Kleinigkeiten am Ende kurz.

1. Aufnahme der Arbeit

Erfasse jeden relevanten Bildschirm als PNG mit bekannten Abmessungen. Bleibe innerhalb des Umfangs, den die Person angegeben hat.

• Figma-Link (Figma-Connector): create_session mit dem Dateischlüssel, get_metadata für den verknüpften Knoten, um Rahmen aufzulisten (große Ergebnisse werden in eine Datei überführt; mit jq oder Python parsen), dann get_screenshot für jeden Rahmen im Umfang, nicht nur eine Stichprobe, mit enableBase64Response: true und maxDimension um 700.
• Live-URL oder codierter Prototyp: Playwright-Screenshots mit dem Ziel-Viewport (390x844 für Telefon, 1440x900 für Desktop, beides bei responsivem Design). Erfasse jede Route oder jeden Zustand, die die Person nennt; klicke den Kernablauf durch, wenn er offensichtlich ist. Notiere Konsolenfehler als Befunde.
• Repository oder lokaler Build: Starte es, wenn es mit einem Befehl läuft, behandle es dann als Live-URL. Ansonsten frage nach einer URL oder Screenshots.
• PDF oder Präsentation: Rendere Seiten in PNG (pdftoppm -r 100).
• Screenshots: Verwende sie unverändert.

Schreibe eine Rahmenliste: id, name, w, h, pad (Screenshot-Padding in px pro Seite, 0 falls keines), png-Pfad. Screenshot-Px ÷ (img_breite / (w + 2·pad)) ergibt pt des Rahmens.

Hole den Kontext in einem Durchgang: Was ist das Produkt, seine Kernfunktion in einem Satz, für wen es gedacht ist und in welchem Stadium es sich befindet (Skizze, mid-fi, hi-fi, ausgeliefert). Wenn etwas unklar ist und es die Kritik ändern würde, frage einmal nach. Wenn bereits Kommentare existieren (Figma), liste sie auf, damit sie nicht wiederholt werden.

2. Spezialisierte Prüfer

Starte alle ausgewählten Prüfer parallel, in einer Nachricht, mit dem Agent-Tool. Jeder bekommt die gleiche Zusammenfassung: Produkt + Kernfunktion, Stadium, Umfang, Rahmenliste, zu überspringende vorhandene Kommentare, Plattform.

Jeder gibt nur JSON zurück, maximal 12 Befunde: {frameId, x, y, finding, guideline, source_url, confidence: high|med, severity: block|fix|nit, tag} x,y sind in pt des Rahmens, auf dem Element. Jeder Befund muss in einem Screenshot sichtbar sein, den der Prüfer geöffnet hat. Keine Behauptungen über Bildschirme, die er nicht gesehen hat.

Tag	Prüfer	Modell	Warum dieses Modell
flow	Benutzerfreundlichkeit und Ablauf	opus	Urteilsintensiv; hier liegen die wichtigen Befunde
craft	Handwerk und Konsistenz	sonnet	Meist Messung gegen Metadaten und Pixel
a11y	Barrierefreiheit	sonnet	Messung plus Checkliste
platform	Plattformkonventionen	sonnet	Abruf und Abgleich mit offiziellen Richtlinien
ai	KI-Versatz-Detektor	opus	Falsch positive sind der teuerste Fehler hier
ref	Präzedenzfall-Scout	haiku	Suche und Rückgabe von Links; überspringe, wenn kein Mobbin-Connector
story	Präsentationserzählung (nur Präsentationen, ersetzt Craft + Ref)	opus	Beurteilung der Erzählung

Der quick-Modus führt nur Flow und Craft aus. Verwende ihn für eine schnelle Bauchkontrolle.

flow: Nielsens 10 Heuristiken. Fehlende Zustände (leer, Fehler, Laden, ausgewählt, deaktiviert, Tastatur offen). Sackgassen. Destruktive Aktionen, die zu einfach sind. Daten, die zwischen Bildschirmen nicht übereinstimmen (gleicher Artikel unterschiedlich bepreist, Zählungen, die nicht passen). Was den Hauptinhalt unter den Falz drückt. Intelligente Standardwerte: Könnte die App das heutige Datum, den aktuellen Standort, die letzte Wahl, ein System-Zahlungsblatt wählen? Bedienelemente, die die Leute erwarten (Neu zentrieren und Kompass auf Karten, primäre Aktion in Daumenreichweite). Dinge, die tippbar aussehen, es aber nicht sind, und umgekehrt. Wenn Farbe Bedeutung trägt, ist das System dann vermittelt oder mit Symbolen untermauert?

craft: Verwende Metadaten-Positionen und -Größen plus Pixel. Ausrichtung, Abstandsrhythmus, Komponentengrößen, Eckenradien, Strichstärken, Schriftskala, Farbe, die sich ohne Grund ändert, Zuschneide- und Passungsprobleme, Teile, die eine gleiche Behandlung teilen sollten, es aber nicht tun. Platzhalterinhalt, wo echter Inhalt die Lesart ändern würde (Lorem Ipsum, graue Boxen für Fotos, gefälschte Kartenkacheln).

a11y: WCAG 2.2 AA plus die Barrierefreiheitsrichtlinien der Plattform. Messe Kontraste aus PNG-Pixeln mit PIL, schätze nicht: 4.5:1 Textkörper, 3:1 große Texte und UI-Teile. Berührungsziele mindestens 44x44 pt (iOS) oder 48x48 dp (Android) oder mindestens 24x24 CSS px (Web). Text unter 12 pt. Bedeutung allein durch Farbe. Symbol-Buttons ohne Label. Layouts, die mit größerem Text oder langen Namen brechen. Lesereihenfolge. Die Fähigkeit design:accessibility-review, falls installiert, ist eine gute Checkliste.

platform: Rufe mit WebFetch die offiziellen Seiten ab, die zum Bildschirminhalt passen (Apple HIG, Material 3 oder die eigenen Normen der Web-Plattform): Tab- und Navigationsleisten, Blätter, Buttons, Textfelder, Schalter, Karten, Zahlungen, Symbole, Schrift, sichere Bereiche, aktuelle Materialien. Markiere, wo das Design gegen eine Konvention kämpft, neu aufbaut, was das System kostenlos bereitstellt, oder ein kostenloses System-Feature verpasst.

ref: Für die 2-4 Befunde, bei denen ein ausgeliefertes Beispiel die Entscheidung bringen würde, durchsuche Mobbin (search_screens / search_flows). Gib 1-2 Referenzen pro Befund zurück, mit Link. Niemals eine Referenz zu jedem Kommentar.

story (Präsentationen): Führt die Recherche zu einer Erkenntnis, dann zu einer Entscheidung? Sind die Bildschirme groß genug zum Lesen, und ist es die echte UI oder eine Nachzeichnung? Ist das Szenario nachvollziehbar? Reihenfolge der Folien, Platzierung der Zusammenfassung, Logo auf Titel- und Schlussfolie, Beschriftungen neben den Bildschirmen.

ai (KI-Versatz-Detektor): Gleiches JSON plus bucket: fix | pattern.

• Texte: Dreiteilige Slogans („Einfach. Sicher. Nahtlos.“), Füllwörter (nahtlos, mühelos, empowern, heben, entsperren, Reise), Gedankenstrichgewohnheiten, nummerierte Alles, Überschriften, die wie Prompt-Rückstände lesen, Zählungen, die nicht zur Liste passen, eine einzige polierte Marketingstimme überall.
• Bilder: Wachsgesichter, verstümmelter Text in Bildern, verzerrte Hände oder Objekte, Beleuchtung, die nicht zur App passt.
• UI: Vorlagendesign ohne Verbindung zum Produkt (standardmäßige Lila-Blau-Verläufe, Glas auf allem, identische Karten, Bento-Raster ohne echten Inhalt), gemischte Symbolsets, Emoji-Suppe, Bildschirme, die generiert statt iteriert aussehen (keine Zustände, keine Randfälle, perfekt aber leer).
• Recherche: Zitate, die alle gleich klingen, zu aufgeräumte Personas, nicht belegte Statistiken, Erkenntnisse, die auf nichts Gezeigtem zurückgehen.
• fix benennt ein Symptom, das es wert ist, behoben zu werden, wer auch immer es gemacht hat. pattern ist etwas, das sich nur über die gesamte Menge hinweg summiert.
• Im self-Modus werden beide Eimer gemeldet. Im student-Modus geht pattern nur an den Dozenten, niemals in einen geposteten Kommentar, und ist ein Beweis für sein Urteil, niemals ein Urteil selbst. KI-unterstützte Arbeit ist immer noch die Arbeit des Autors.

3. Skeptiker-Durchgang

Starte einen weiteren Agenten (sonnet) mit allen Kandidatenbefunden und den PNGs. Seine einzige Aufgabe: Versuche, jeden zu widerlegen. Gib für jeden Befund {id, verdict: confirmed|refuted|unsure, reason} zurück. Er sollte überprüfen, ob das Element bei x,y existiert, die Messung hält, die Richtlinie das tatsächlich sagt und die Sache nicht plausibel beabsichtigt ist (ein in einer Animation eingefangener Rahmen, ein absichtliches Duplikat).

Kompromiss: Ein zusätzlicher Agent pro Review. Überspringe ihn im Schnellmodus oder wenn weniger als ~10 Kandidaten vorhanden sind und du sowieso jeden Screenshot selbst öffnest.

4. Redakteursdurchgang (du)

• Verwerfe widerlegte Befunde. Öffne den Screenshot für alles unsure und entscheide.
• Entferne Duplikate über die Prüfer hinweg und alles, was bereits in vorhandenen Kommentaren gesagt wurde.
• Bitte den Autor nicht, Inhalte zu entfernen, die er offensichtlich eingefügt hat, und markiere keinen leeren Raum, der wahrscheinlich beabsichtigt ist, es sei denn, etwas ist kaputt.
• Priorität: Dinge, die das Verständnis oder den Kernablauf blockieren, dann Konsistenz, Kontrast und Berührungsziele, dann Politur mit „Nit:“ gekennzeichnet.
• Formuliere es für das Publikum (Schritt 0). Wenn voice professor ist, lies professor-voice.md (neben dieser Datei) jetzt und schreibe darin. Wenn es eine Fähigkeit benennt, lade diese Fähigkeit und schreibe in ihr. plain bedeutet keine Persona. Führe mit der Erfahrung („Schwer mit dem Daumen zu treffen“), füge die Regel nur hinzu, wenn sie hilft („mindestens 44pt; das sind etwa 30“). Ein gelegentlicher Richtlinien- oder Referenzlink ist in Ordnung; niemals eine Liste von Zitaten.
• Kurz ist besser. Viele gute Handwerksnotizen sind 3-10 Wörter. Mehrere auf einem Rahmen sind in Ordnung.
• Respektiere volume. Spezialisten erweitern, was du bemerkst; sie erhöhen nicht die Lautstärke oder einen Rechthaberton.
• Behalte den tag jedes Kommentars und ein einzeiliges warum. Setze die weggelassenen Befunde in eine extras-Liste, damit sie zurückgeholt werden können.
• Wenn calibration auf eine Datei verweist, lies sie vor der Formulierung und folge ihren Mustern.

5. Ausgabe

• list (Standard): Gruppiere nach Bildschirm in der Ablauffolge. Jeder Eintrag: Schweregrad, der Kommentar, Rahmennamen und ein Knotenlink für Figma (https://www.figma.com/design/FILEKEY/NAME?node-id=ID mit „:“ ersetzt durch „-“). Dann der KI-Versatz-Bericht (Selbstmodus) oder die Extras. Dann ein zusammenfassendes Gesamturteil in zwei Zeilen: die eine Sache, die zuerst zu beheben ist, und was funktioniert. In der Professoren-Stimme ist dies der Bürozeiten-Abschluss, und die Liste beginnt mit ihrem einzeiligen Opener.
• page: Wenn das Artifact-Tool verfügbar ist, veröffentliche eine private Review-Seite mit jedem Screenshot und nummerierten Pins bei x,y, einem Bearbeitungsfeld und einem Behalten/Entfernen-Umschalter pro Kommentar sowie einem „Genehmigen“-Button. Verwende die db-Fähigkeit, damit Bearbeitungen bestehen bleiben, und lies die Bearbeitungen zurück, bevor du darauf reagierst.
• figma: Poste nur nach einer expliziten OK-Nennung des Batches. Überprüfe vorhandene Kommentare direkt vor dem Posten erneut. Poste jeden behaltenen Kommentar, der bei seinem Knoten bei x,y angeheftet ist, genau wie genehmigt. Bearbeite oder lösche niemals Kommentare anderer. Berichte, was gepostet wurde, was übersprungen wurde und alle Fehler. Wenn der Figma-Connector keine Kommentare posten kann, sage das und falle auf list zurück.

6. Fix-Prompt (Selbstmodus)

Wenn die Arbeit mit Claude erstellt wurde, beende mit einem einfügebereiten Prompt für die Sitzung, die sie erstellt hat: die Block- und Fix-Items als nummerierte, konkrete Anweisungen (was, wo, Zielwert), plus „ändere nichts anderes.“ Lasse Nits weg, es sei denn, sie werden verlangt. Dies verwandelt die Kritik in die nächste Iteration anstatt in eine Leseaufgabe.

7. Kalibrieren (optional, empfohlen)

Nachdem die Person auf die Kritik reagiert hat, analysiere den Unterschied zwischen dem, was sie behalten, gestrichen, umgeschrieben und selbst hinzugefügt hat. Wenn eine calibration-Datei gesetzt ist, hänge 2-5 kurze Musterzeilen an (z. B. „gestrichen: Aufforderung zum Entfernen optionaler Inhalte“, „hinzugefügt: fehlende Tastatur-offen-Zustände“). Diese Datei ist, wie die Fähigkeit mit der Zeit den Geschmack einer Person lernt.