theme-review

ultrahand: theme-review

Prüft, wie gut ein Projekt sein Theme einhält: ob die Theme-Datei selbst solide ist und ob die Designs und der Code es tatsächlich verwenden. Die Ausgabe ist eine bewertete Liste von Befunden plus eine Liste vorgeschlagener Theme-Änderungen. Der Prüfer baut auf dem Theme des Projekts auf; es erfindet niemals ein neues. Eine Lücke im Theme wird zu einem vorgeschlagenen Zusatz für den theme-Skill, nicht zu einer neuen Palette.

Die Regeln stehen in shared/theme/rules.md (Nicht-Verhandelbares NN-n, kreative Achsen CR-n, Evolutionsregeln EV-n); jede Prüfung ist in references/checklist.md aufgeführt, und beide zitieren shared/theme/sources.md. Für UX-Probleme, die über das Theme hinausgehen (Abläufe, Labels, Plattformkonventionen), verweise auf den review-Skill.

Die folgenden Skripte befinden sich in ${CLAUDE_PLUGIN_ROOT}/shared/theme/.

1. Theme und Ziel ermitteln

• Das Theme: Finde design/THEME.md und die Token-Datei (Suche wie Schritt 1 des theme-Skills). Lies THEME.md: seine Persönlichkeit, welche Entscheidungen festgelegt sind, sein Komponenteninventar und sein Änderungsprotokoll. Daran wird das Ziel gemessen.
• Kein Theme vorhanden: Erfinde keins. Führe node scan.mjs <src dir> aus, um die Werte anzuzeigen, die der Code heute verwendet, und prüfe nur gegen die Nicht-Verhandelbarkeiten. Empfehle den theme-Skill, daraus ein Theme zu extrahieren, und füge die wichtigsten Cluster des Scans als Ausgangspunkt in den Bericht ein.
• Das Ziel: Code (ein Quellordner, ein Diff oder ein PR), ein Canvas-Artefakt oder ein Screenshot. Sage wie bei review, welches du hast, und markiere jeden Befund als Bestätigt (im Code, der Token-Datei oder dem Canvas gemessen) oder Wahrscheinlich (anhand eines Bildes beurteilt). Bei einem Diff überprüfe, was geändert wird, und notiere jede hinzugefügte Abweichung.

2. Prüfungen durchführen

1. Theme-Datei: node check.mjs design/theme.tokens.json --json. Jeder Fehler ist ein Befund; lies die Kontrasttabelle für beide Farbschemata.
2. Token-Nutzung im Code: node scan.mjs <src dir> --theme design/theme.tokens.json.
   • Rohwerte, die einem Token entsprechen: eine hartcodierte Kopie eines Theme-Werts. Wenn sich das Theme ändert, werden diese nicht aktualisiert [HIG-COLOR] [PRIMER-LINT].
   • Werte ohne Token: Abweichung vom Theme. Jeder ist entweder ein Fehler (an den nächsten gezeigten Token anpassen) oder ein echtes Bedürfnis (einen Token vorschlagen).
   • Tokens, die keine Datei erwähnt: möglicherweise ungenutzt. Vor einem Löschvorschlag bestätigen; der Scan gleicht Namen nach Muster ab.
   • Fast identische Farben und Abstände außerhalb des Rasters: ein Befund pro Cluster, nicht pro Zeile. Suche auch nach primitiven Token, die direkt im Code verwendet werden (primitive. oder das plattformspezifische Äquivalent), was die Rolle überspringt (NN-1).
3. Auf dem Canvas oder einer Live-Seite: Lese die berechneten Styles für die zu prüfenden Elemente aus. Das Kompositions-Audit (shared/composition/audit.mjs, ausgeführt über shared/input/drive.mjs) meldet Steuerelement-Styles, Schriftgrößen und Abstände pro Abschnitt, was sofort einen zweiten Button-Stil oder eine abweichende Schriftgröße aufzeigt.
4. Arbeite die Durchgänge in references/checklist.md ab: Theme-Gesundheit, Token-Nutzung, Komponenten-Wiederverwendung, Konsistenz über Bildschirme hinweg, beide Farbschemata und Charakter.

Die Skripte finden Muster, keine Beweise. Verfolge jeden Hinweis und bestätige ihn, bevor er zu einem Befund wird.

3. Bewerten und berichten

Bewerte mit derselben 0–4-Skala wie review (siehe Schweregrad-Leitfaden in dessen Checkliste), unter Verwendung der Anker in der Checkliste dieses Skills. Ein Problem an vielen Stellen ist ein Befund mit einer Anzahl und seinen Hauptfundorten.

## Fazit
<Theme-Version und Ziel, Belege, Anzahl nach Schweregrad, die größte einzelne Abweichungsquelle.>

## Befunde
### T1 · 3 Schwerwiegend · <kurzer Titel>
- **Wo:** <Datei:Zeile, Bildschirm › Element oder Token-Pfad>; ×<Anzahl>
- **Beleg:** Bestätigt | Wahrscheinlich
- **Problem:** <Was abweicht und was es kostet: Inkonsistenz, die auffällt, oder ein Wert, der der nächsten Theme-Änderung nicht folgt>
- **Regel:** <NN-n / EV-n / CR-n> [<Quellschlüssel>]
- **Korrektur:** <Konkret: "Ersetze #8e3f27 durch var(--color-primary) an 3 Stellen">

## Vorgeschlagene Theme-Änderungen
<Für den theme-Skill anzuwenden. Jeweils: hinzufügen / als veraltet markieren / festlegen, der Token oder die Entscheidung, sein Wert als Alias, warum und welche Befunde ihn benötigen. Alles weglassen, was bereits von vorhandenen Token abgedeckt wird.>

## Was funktioniert
## Nicht geprüft

Halte Korrekturen innerhalb des Themes: Gleiche zuerst einem vorhandenen Token an, schlage als Zweites einen Token vor und schlage niemals einen Wert vor, der eine Nicht-Verhandelbarkeit verletzt. Biete an, die Code-Korrekturen anzuwenden und den theme-Skill für die vorgeschlagenen Änderungen auszuführen.