jamesonedge/senior-design-review

Was macht senior-design-review?

Verwandle ein vages „mach das besser” in eine falsifizierbare Designentscheidung. Das Ergebnis ist eine strukturierte Kritik, die echte Dateien, Tokens und Referenzmuster zitiert, gefolgt von einer Spezifikation, die ein Entwickler umsetzen kann.

Wann verwenden

Verwende diese Fähigkeit, wenn der Benutzer darum bittet:

• einen bestehenden Bildschirm, Ablauf oder eine Komponente zu überprüfen, zu kritisieren oder einem „Belastungstest” zu unterziehen;
• einen Vorschlag einer anderen Person (z. B. eines Junior-Designers oder eines anderen Agenten) zu bewerten;
• zu entscheiden, was vor der Implementierung gestrichen, hinzugefügt, überarbeitet oder behalten werden soll;
• einen mobilen Ablauf anhand von Screenshots zu korrigieren.

Wann nicht verwenden

• Kleine, lokale Korrekturen wie „vergrößere den Abstand auf dieser Karte” oder „ändere diese Beschriftung in 'Speichern'”. Nimm die Änderung direkt vor; eine vollständige Überprüfung ist überflüssig.
• Erstellung eines interaktiven Prototyps. Verwende einen interaktiven Mockup-Workflow; diese Fähigkeit kann diesen zwar speisen.
• Nicht-UI-Code-Review, Leistungsoptimierung oder Backend-Design.
• Marken- oder Marketingstrategie ohne konkrete Benutzeroberfläche.

Eingaben

Sammle, was das Repository oder der Benutzer sicher bereitstellen kann. Fehlende Eingaben werden als offene Fragen aufgeführt, niemals erfunden.

1. Design-Tokens (Farbe, Schriftart, Abstand, Radius, Bewegung) – Dateipfade.
2. Die kanonische(n) vorhandene(n) Komponente(n), der/denen das Ziel ähneln soll.
3. Ein zuvor genehmigtes Beispiel ähnlicher Arbeit, falls vorhanden (optional, nützlich).
4. Die Zielimplementierung und/oder Screenshots.
5. Bekannte Plattformbeschränkungen (Navigationsmodell, OS-Konventionen, Mindestziele).
6. Die Beschwerde des Benutzers, nach Möglichkeit wörtlich zitiert.

Ein ausfüllbares Kontextformular befindet sich in templates/context.md.

Arbeitsablauf

1. Erstelle einen expliziten ersten Vorschlag

Schreibe den Vorschlag vor jeder Kritik mit templates/proposal.md auf: Problem, zitierte Schmerzpunkte, Designprinzipien, eine Informationsarchitektur-Skizze, Aktionen und offene Fragen. Wenn der Benutzer einen Vorschlag geliefert hat, verwende diesen unverändert als Eingabe.

2. Führe die Überprüfung als neuen Durchgang durch

Der Prüfer liest in dieser Reihenfolge: Tokens, kanonische Komponente, vorheriges Beispiel, Zielimplementierung/Screenshots, Plattformbeschränkungen und erst dann den Vorschlag. Das Lesen der Beweise zuerst verhindert eine Verankerung an der Rahmung des Vorschlags.

• Wenn deine Laufzeitumgebung einen wirklich separaten Kontext starten kann (einen Unter-Agenten oder eine neue Sitzung ohne gemeinsamen Verlauf), verwende diesen und teile dies mit.
• Wenn nicht, führe selbst einen separaten Durchgang durch und kennzeichne ihn ehrlich: „Einzelagenten-Separatdurchgang – keine unabhängige Peer-Review.”

Die Prüfer-Persona ist eine Qualitätslinse (ein anspruchsvoller Senior-Produktdesigner). Gib niemals Berufserfahrung, Qualifikationen oder Jahre Erfahrung im Namen der Persona an.

3. Schreibe die Überprüfung

Verwende templates/review.md. Abschnitte:

• TL;DR – drei bis fünf Zeilen: Urteil und die wichtigste Änderung.
• A. Strukturelle Kritik – ist dies überhaupt der richtige Bildschirm/Ablauf?
• B. Informationsarchitektur und Hierarchie
• C. Aktionssemantik – primär, sekundär, destruktiv, rückgängig, Benennung.
• D. Mechanik und Gesten – Tippen, Wischen, Ziehen, Tastatur, Auffindbarkeit.
• E. Visuell und Bewegung – Tokens, Rhythmus, Dichte, Übergänge.
• F. Barrierefreiheit und Internationalisierung
• G. Fehlende Fragen – fünf anstreben, aber nur sinnvolle aufnehmen.
• H. Verfeinerte Spezifikation plus das Streichen / Hinzufügen / Überarbeiten / Behalten-Verzeichnis.

Detaillierte Anleitung für jede Linse befindet sich in references/review-lenses.md. Die Checkliste für Barrierefreiheit und i18n befindet sich in references/accessibility-i18n.md.

Regeln, die die Überprüfung lesenswert machen

• Belastungstest; kein Abnickverfahren. Jede Behauptung benötigt einen spezifischen Verweis: einen Dateipfad, Token-Namen, Komponentennamen, Screenshot-Bereich oder ein benanntes Referenzmuster (z. B. „iOS Mail Wischen zum Archivieren”).
• Keine Floskeln. „Visuelle Hierarchie verbessern” ist kein Befund. „Das Fälligkeitsdatum verwendet text.secondary in derselben Größe wie der Titel, daher ist die Frist auf den ersten Blick unsichtbar” ist einer.
• Keine erzwungenen Streichungen. Wenn die aktuelle Struktur richtig ist, sag es und dokumentiere ein begründetes Behalten. Veränderung um der Veränderung willen ist ein Fehler.
• Keine erfundenen Messungen. Gib keine Kontrastverhältnisse, WCAG-Bestehen/Nichtbestehen-Werte oder Leistungsdaten an, es sei denn, du hast sie berechnet oder gemessen, und zeige, wie. Schreibe andernfalls „nicht gemessen – mit einem Kontrastwerkzeug überprüfen”.
• Zustände abdecken. Leer, lädt, Fehler, offline, langer Inhalt und sehr kurzer Inhalt.
• Nicht-Farbsignale. Der Status darf niemals allein auf Farbe beruhen.
• Tastatur- und Screenreader-Pfade für jede Aktion, einschließlich benutzerdefinierter Gesten.
• Texterweiterung (für viele Sprachen etwa 30–40 % längere Zeichenfolgen einplanen) und gegebenenfalls Rechts-nach-links-Layout.
• Alternative mit reduzierter Bewegung für jede Animation.

Optional: Vergleich mit vorheriger Arbeit

Wenn ein zuvor genehmigtes Beispiel existiert, füge unter E oder H eine kurze Notiz „Konsistenz mit vorheriger Arbeit” hinzu. Dies ist nützlich, aber nicht zwingend.

Ausgaben

• proposal.md (falls du es erstellt hast)
• review.md mit TL;DR, A–H und dem Verzeichnis
• Eine kurze Zusammenfassung für den Benutzer: Urteil, die drei wichtigsten Änderungen und die offenen Fragen, die die Implementierung blockieren

Akzeptanzprüfungen

Siehe references/review-lenses.md#acceptance-checks. Eine Überprüfung ist nicht bestanden, wenn einer Verzeichniszeile ein Grund und ein Verweis fehlt oder wenn nicht gemessene Zahlen als Tatsache angegeben werden.

Lizenzhinweis

Der folgende Hinweis begleitet diese eigenständige Fähigkeit und ihre begleitenden Dateien.

MIT License

Copyright (c) 2026 jamesonedge

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.