Design-UAT (Design-Abnahmeprüfung)
Überprüfe die visuelle Implementierung einer Website gegenüber ihren Designreferenzen. Standardmäßig wird ein englischer, problemorientierter HTML-Bericht erstellt; eine angeforderte Sprache oder ein anderes Berichtsformat wird berücksichtigt. Das Skill ist projektübergreifend wiederverwendbar. Projekt-URLs, Frame-Zuordnungen, akzeptierte Abweichungen, Anmeldeinformationen und Ausführungsnachweise gehören nicht in diesen Skill-Ordner.
Beginne mit dem Umfang des Benutzers
Verwende bereitgestellte Website- und Figma-Links als anfänglichen Umfang. Verwende ein vorhandenes, passendes Projektprofil wieder; beginne andernfalls mit der Erkundung, ohne eine vorbereitete Routenliste oder Konfiguration zu verlangen. Wenn eine Figma-Seite eine Versionsübergabe darstellt, erfasse die gesamte Seite und entdecke den eigenen Testpfad jedes Moduls. Die bereitgestellte Website-URL ist ein Einstiegspunkt, keine Routeneinschränkung. Berücksichtige einen expliziten, vollständigen Seitenumfang; zeichne Ausschlüsse und blockierte Zustände auf, anstatt stillschweigend eine Stichprobe zu verwenden. Gib bei einem nicht näher bezeichneten großen Umfang eine sinnvolle Überprüfungsgrenze an. Die Stichprobenentnahme eines Bildschirms akzeptiert nicht ein ganzes Modul.
Halte Projektdaten im beschreibbaren Arbeitsbereich des aktuellen Projekts, unter Beachtung der Repository-Anweisungen. Ein sinnvoller Standard ist design-uat/<projekt>/project.json und runs/<run-id>/, aber bewahre einen etablierten Speicherort. Siehe project-data.md beim Erstellen von Zuordnungen, beim Aufbau von Berichtseingaben oder beim Aufzeichnen einer Wiederholung.
Entdecke die tatsächlich verfügbaren Werkzeuge. Bevorzuge einen Figma-Connector für Designstruktur und -maße und eine Browsersteuerung für die Live-UI. Verwende die relevanten Werkzeuganweisungen und erforderlichen Skills, wenn nötig; dieses Skill stellt diese Werkzeuge nicht bereit. Verwende nach Möglichkeit eine bestehende, autorisierte Anmeldung erneut. Wenn der Zugriff blockiert ist, setze die nützliche unabhängige Arbeit fort und berichte genau, welche Zustände nicht überprüft werden konnten.
Entdecke die Design-zu-Seite-Zuordnung
Überprüfe die Designhierarchie und die Live-Navigation, bevor du Bilder vergleichst. Eine Zeichenfläche kann Modulcontainer, Bildschirmframes, lokale Zustandsbeispiele, Notizen, Anmerkungen und alternative Vorschläge enthalten. Identifiziere das visuelle Ziel innerhalb dieser Struktur, anstatt das gesamte Dokumentationsboard als Bildschirm zu exportieren.
Lies die zugehörigen Notizen und lokalen Zustandsbeispiele. Sie können responsives Verhalten, Eingabemaße, Textabschneidungen oder Komponentendetails angeben, die der Hauptframe nicht zeigt. Verwende sichtbaren/effektiven Knoteninhalt; ausgeblendeter Komponenten-Hilfe-/Fehlertext ist keine aktive Anforderung, nur weil er im Baum vorhanden ist.
Unterscheide eine tatsächliche Seitenspezifikation von einer Illustration allgemeiner Interaktionen. Ein generisches Drawer-Beispiel kann eine Abweichung in einem bestehenden Modul aufdecken, legt aber nicht die erforderlichen Felder jeder Kategorie fest. Behalte einen nützlichen, modulübergreifenden Befund mit seinem tatsächlichen Pfad, Navigationskontext und Baseline-Einschränkung; kennzeichne einen vermuteten Legacy-Status als unbestätigt, es sei denn, seine Historie ist bekannt.
Ordne anhand der kombinierten Evidenz aus Modulkontext, Route, sichtbarem Seitentitel, Feldbezeichnungen, UI-Struktur und gerendertem Erscheinungsbild zu. Zeichne Frame-IDs, Seite/Zustand, Vergleichsregion, Konfidenz und Zuordnungsstatus in den Projektdaten auf. Eine URL kann viele visuelle Zustände haben. Vermische nicht eine Liste, einen geöffneten Drawer, ein fokussiertes Eingabefeld und einen leeren Zustand.
Fahre mit gut gestützten Zuordnungen fort, die als „inferiert“ (geschlussfolgert) markiert sind, wenn sie nicht vom Menschen bestätigt wurden. Bündele wirklich mehrdeutige Entscheidungen für den Benutzer, während du mit unblockierten Fällen fortfährst. Zeichne alternative/Backup-Designs als außerhalb des ausgewählten Umfangs liegend auf, mit einem Grund; die bloße Benennung etabliert nicht die akzeptierte Version. Überprüfe zuvor gespeicherte Zuordnungen gegen das aktuelle Design und die Live-Seite, bevor du sie wiederverwendest.
Behalte bei großen Figma-Dateien die rohen Metadaten lokal und gib kompakte, flache Zusammenfassungen an den Kontext zurück. Schränke durch bekannte Vorfahren ein, bevor du detaillierte Unterbäume oder Screenshots extrahierst. Vermeide es, wiederholt die gesamte Datei zu laden.
Erfasse vergleichbare Evidenz
Lies evidence-workflow.md vor der ersten Erfassung oder bei der Diagnose eines Vergleichsproblems. Es deckt Artboard-Überlauf, Zustandsabgleich, Annotationsausschluss, dynamische Inhalte, lokale Ausschnitte und Screenshot-Akzeptanz ab.
Lege die benötigten visuellen Zustände durch Navigation, Fokussierung und reversible Eingabeänderungen offen. Nimm keine Geschäftsänderungen vor, nur um einen Screenshot zu erhalten, ohne Autorisierung für diese Änderungen. Wenn ein Zustand nicht verfügbare Daten oder einen Schreibzugriff erfordert, zeichne diese Einschränkung auf, anstatt sie zu erfinden.
Erfasse die exakte Designregion und den Browserzustand bei kompatiblen Viewport, Skalierung und Theme. Überprüfe, ob Schriftarten/Inhalte geladen sind und das Ziel stabil ist. Lehne vorübergehende Ladeaufnahmen ab, es sei denn, das Laden selbst ist der überprüfte Zustand. Überprüfe gespeicherte Screenshots, bevor du sie in einem Bericht verwendest. Bewahre originale Aufnahmen zusammen mit etwaigen Ausschnitten, Überlagerungen und Anmerkungen auf.
Begründe Unterschiede mit beiden Bildern zusammen und, wo sinnvoll, mit Figma-Geometrie und Browser-Elementgrenzen. Weise gemessenen Werten ihre Quelle zu. Verwende scripts/compare_regions.py für optionale native skalierte gepaarte Ausschnitte und Markierungen, wenn Pillow verfügbar ist. Der Berichtsrenderer selbst benötigt nur die Python-Standardbibliothek.
Überprüfe Beziehungen über eine Steuerungszeile hinweg sowie einzelne Dimensionen: benachbarte Abstände, Ausrichtung, verbleibender Aktionsraum und Änderungen, wenn aktiv-Filter-Steuerelemente erscheinen. Gruppiere eine gemeinsame Layoutkorrektur und ihre visuellen Konsequenzen unter einem stabilen Issue, wenn dies durch Evidenz oder explizites Reviewer-Feedback gestützt wird. Unterscheide diese Gruppierung von einer Code-Ebene-Ursachendiagnose.
Unterscheide Kontext von Defekten: Beispieldaten, Kontoidentität, erweiterte Navigation, globale Ankündigungen und spätere Komponentenversionen können einen Screenshot verändern. Zeichne sie auf; verwerfe ihre Layout-Effekte nicht stillschweigend. Textwerte können vom Textabgleich ausgeschlossen sein, während ihr Umbruch, Überlauf und ihre Ausrichtung überprüfbar bleiben. Ziehe niemals Screenshots, um Unterschiede zu verbergen oder erfinde einen Ganzseiten-Ähnlichkeitswert.
Erstelle umsetzbare Befunde
Klassifiziere jeden Befund nach dem, was seine Evidenz unterstützt:
visual-defect(visueller Defekt): ein reproduzierbarer visueller Fehler wie Beschneidung, Überlappung oder eine bestätigte Implementierungsverletzung. Gib die Bedingungen und die Quelle der Erwartung an.baseline-mismatch(Baseline-Abweichung): eine nachgewiesene Abweichung von der gelieferten Referenz, deren aktuell akzeptiertes Design/Version möglicherweise bestätigt werden muss.design-clarification(Design-Klärungsbedarf): eine beobachtete Bedingung mit unzureichender oder widersprüchlicher Designanleitung, um die Akzeptanz zu entscheiden.
Halte Beobachtungskonfidenz, vorgeschlagene Priorität und Folgestatus getrennt. Bezeichne eine Screenshot-Differenz mit hoher Konfidenz nicht als akzeptierten Defekt, nur weil der Unterschied offensichtlich ist. Verwende das Prioritätsschema des Projekts; kennzeichne Vorschläge als solche und lasse die Priorität ungesetzt, wo die Entscheidung ungeklärt ist. Erfinde keine Besitzer, Ziel-Releases, genehmigte Abweichungen, Implementierungsabschluss oder erfolgreiche Wiederholungstests.
Jeder Befund benötigt eine stabile ID, Seite/Zustand, präzisen Titel, tatsächliches Ergebnis, erwartetes Ergebnis oder explizite Unsicherheit, Evidenzbasis, empfohlene Aktion und Reproduktionsschritte. Füge gezielte Vergleichsevidenz und die vollständige Aufnahme des aktuellen Zustands bei. Füge relevante Figma-Referenzen hinzu. Befunde ohne visuelle Evidenz sind Einschränkungen oder Fragen, keine bestätigten visuellen Defekte.
Zeichne geprüfte Prüfpunkte (Checks) und blockierte/nicht überprüfte Zustände getrennt auf. Behalte bei einer Wiederholung dieselben Issue-IDs bei. Schließe einen Befund nur dann oder markiere ihn als gelöst, wenn übereinstimmende neue Evidenz vorliegt; behalte die vorherige Beobachtung bei und erläutere geänderte Akzeptanzkriterien.
Design-Review einbeziehen
Standardmäßig wird ein Review-Entwurf erstellt, dann werden die Entscheidungen des Designers einbezogen, bevor eine Entwicklerübergabe erstellt wird. Lies review-workflow.md beim Erhalten von Feedback, Überarbeiten einer Design-Baseline oder Vorbereiten des formellen Berichts. Explizites, bereits im Gespräch gegebenes Review und Genehmigung sind ausreichend; fordere nicht dieselbe Bestätigung erneut an.
Zeichne Entscheidungen zu „Behalten“, „Ausschließen“, „Akzeptieren“, „Zusammenführen“, „Verschieben“ und „Designaktualisierung“ in den Projektdaten auf, mit ihrer Quelle und ihrem Umfang. Eine Korrektur der Designreferenz ist keine Implementierungskorrektur. Reviewer-Feedback zu einer Designänderung autorisiert nicht selbst die Bearbeitung von Figma. Behalte den Entwurf und die Entscheidungshistorie bei; die Entwicklerübergabe enthält nur beibehaltene Aktionspunkte, einschließlich aller explizit beibehaltenen Klärungsbedarfe oder Nachverfolgungen bestehender Module. Mache nicht aus nicht zugewiesenen Prioritäts-, Eigentümer-, Release- oder Wiederholungstestfeldern bestätigte Werte.
Liefere den Bericht
Lies report-format.md beim Verfassen des Berichts. Bewahre die bewährte Lesereihenfolge: Umfangskontext → präzises Issue-Register → ausgewählte Issues mit tatsächlichem/erwartetem visuellem Nachweis → Abdeckungs- und Überprüfungsnotizen. Mache die visuellen Nachweise zum Kern des Berichts, nicht zu einem losgelösten Anhang. Vermeide es, große Screenshots für jedes Issue und für jeden bestandenen Check zu wiederholen.
Schreibe die strukturierten Ausführungsdaten, die in project-data.md beschrieben sind, und rendere dann:
python3 <skill-verz>/scripts/render_report.py <ausfuehrungs-verz>/report.json
Dies erzeugt eine eigenständige report.html, issue-register.csv und, wenn Kriterien angegeben sind, eine acceptance-checklist.csv. In einer Entwicklerübergabe benötigt jedes beibehaltene Element eine direkte Test-URL, Navigation/Kontext, Entwickleraktion und beobachtbare Abnahmekriterien. Der Renderer unterstützt diese Felder direkt; patche kein generiertes HTML, um sie hinzuzufügen. Der Renderer benötigt Python 3.9+ und keine Drittanbieterpakete. Er validiert Eingabe/Evidenz, trifft aber keine Review-Entscheidungen, greift nicht auf externe Systeme zu und sendet den Bericht nicht an Entwickler.
Überprüfe den gerenderten Bericht, seine Issue-Umschaltung/-Filterung, Bildvergrößerung und etwaige Vergleichssteuerelemente. Öffne das Ergebnis mit den verfügbaren lokalen Vorschauwerkzeugen und befolge deren Browserregeln. Verwende falls nötig eine nicht kollidierende lokale Vorschau, gebunden an Loopback; veröffentliche oder schreibe nicht auf externe Systeme, es sei denn, dies wurde angefordert. Setze temporäre Browser-Viewport-Überschreibungen und Testeingaben nach Möglichkeit zurück und melde alle Zustände, die geändert bleiben.
Liefere den Berichtslink, die präzise Abdeckung und die wichtigsten Ergebnisse in der Sprache des Gesprächs. Erläutere materielle Einschränkungen. Fordere keine Genehmigung nur um den bereits angeforderten Bericht zu erstellen. Eine Bitte um Diskussion des Ansatzes ist keine Bitte um die Durchführung eines UAT-Durchlaufs.