Referenz-in-Stil

Was macht Referenz-in-Stil?

Verwandelt Referenzen in einen Stil für die gesamte Website, dargestellt auf einer visuellen Tafel (board.html) und hinterlegt durch einen gemessenen Style-Guide (style.md). Der Look stammt aus den Referenzen; der Inhalt stammt vom Thema. Das Definieren eines Stils ändert niemals die App oder Website. Das Anwenden hingegen schon, aber nur, wenn der Benutzer einen gespeicherten Stil benennt (siehe Anwenden eines gespeicherten Stils).

Richte den Stil einmal aus, bevor du Seitenänderungen vornimmst. Der Guide ist die Quelle der Wahrheit: Baue jedes visuelle Element daraus auf und korrigiere darin zuerst jedes Detail, damit nichts, was daraus gebaut wurde, von dem abweicht, was du auf der Tafel gesehen hast.

Messen, nicht schätzen. Die Sehkraft ist gut darin zu sehen, was eine Referenz tut, aber schlecht bei genauen Farben, Größen und Abständen. Jeder Wert, den eine Referenz zeigt, stammt aus scripts/measure.py (alles andere wird daraus abgeleitet oder ist ausgewählt und wird entsprechend gekennzeichnet), und jedes Muster auf der Tafel wird auf die gleiche Weise von scripts/verify.py gerendert und gemessen, bis es übereinstimmt. Die Tafel bleibt visuell; die Zahlen leben im Guide und im Report.

Stille beginnen, dann justieren. Eine Referenz ist ihr Stil in voller Konzentration, und jedes Merkmal auf jedes Element zu verteilen, kann übertrieben wirken. Daher verwendet der erste Durchlauf jedes markante Merkmal nur dort, wo es am meisten bewirkt, mit seinen gemessenen Werten, und der Benutzer dreht einzelne Merkmale bei der Überprüfung hoch oder runter. Die Stärke ändert, wo ein Merkmal erscheint, niemals seine gemessenen Werte.

Wann nicht verwenden

• Der Benutzer möchte eine exakte Übereinstimmung mit seinem eigenen Figma-Frame. Baue den Frame.
• Das Projekt hat bereits einen Stil in design/styles/ gespeichert. Wende ihn stattdessen an (siehe Anwenden eines gespeicherten Stils).

Voraussetzungen

Führe vor Schritt 1 python3 <dieses-skill>/scripts/doctor.py aus (unter Windows py -3 anstelle von python3 überall). Es überprüft jede Abhängigkeit und gibt den genauen Installationsbefehl für jede fehlende aus.

• Exit 0: bereit.
• Exit 1: Python-Pakete fehlen. Zeige dem Benutzer die ausgegebenen Befehle und warte; ohne sie kann nichts gemessen werden.
• Exit 2: Der Browser kann nicht ausgeführt werden. Biete die ausgegebenen Installationsbefehle an. Wenn der Benutzer sie nicht installieren kann, arbeite nur mit Bildreferenzen (bitte um Screenshots von Live-Seiten), führe check.py mit --unverified aus und sage bei der Überprüfung, dass die Genauigkeit der Tafel nicht nachgewiesen ist.
• Kein Python vorhanden (python3 wird nicht gefunden, noch py -3 unter Windows): doctor.py kann nicht ausgeführt werden. Sage dem Benutzer, dass das Skill Python 3.9 oder höher benötigt, von python.org oder dem Paketmanager des Systems, und warte. Installiere Python nicht selbst.

Entscheidungen

Triff jede Entscheidung, die der Durchlauf benötigt, selbst und halte erst an: an der Tafel. Die Tafel zeigt dem Benutzer den gesamten Stil auf einen Blick, damit er ihn dort beurteilt, nicht als Liste von Fragen im Voraus.

• Entscheide, frage nicht: welche Merkmale übernommen und welche weggelassen werden, die Anfangsstärke jedes Merkmals, der Name und Slug des Stils, die Themenliste, die Richtung, wenn die Referenzen übereinstimmen, und wie man einem bestehenden Stil ausweicht. Halte jede Wahl im Guide fest (eine chosen: Quelle oder eine Übernehmen/Weglassen-Zeile), damit sie später geändert werden kann.
• Frage nur früh, wenn du nicht weitermachen kannst: eine Referenz lädt nicht oder ist nur ein Thumbnail, eine Abhängigkeit fehlt, oder die Referenzen weisen in entgegengesetzte Richtungen (wie blasses Transparentpapier und dunkler Blaupausen-Stil), die weder sie noch das Projekt klären. Dann stelle eine kurze Frage mit den Optionen, deine Wahl zuerst, und nichts weiter.
• Halte den Stopp kurz. Zahlen leben im Guide und in verify.md, daher enthält die Nachricht keine Tabellen oder Maße. Beende sie mit diesem Block und warte dann:

Deine Meinung: etwas zu ändern?

Tafel: <Pfad zu board.html> · Genauigkeit: 35 von 35 Messungen stimmen überein (verify.md) Für dich entschieden: Name und Slug; die Hauptmerkmale übernommen/weggelassen; die Richtung, falls es eine Wahl gab Stille gestartet: jedes stille Merkmal und wo es erscheint, in wenigen Worten

1. Drehe ein Merkmal hoch oder runter: benenne es, z. B. „mehr vom Raster“ oder „weniger Rot“
2. Ändere etwas anderes: sag was
3. Nichts: der Stil wird so gespeichert, wie er ist

Verwendung: Der Stil ist in design/styles/<slug>/ gespeichert. Benenne ihn, wenn du ihn verwendet haben möchtest, z. B. „wende <slug> überall an“. Bis dahin ändert sich die App oder Website nicht.

Mit einem Frage-Tool stelle die Frage dort auch, beginnend mit „Deine Meinung“. Nichts muss genehmigt werden: Jeder gespeicherte Stil ist einsatzbereit, und der Benutzer wählt einen später mit Namen aus.

Schritte

1. Siehe die Referenzen, dann messe sie. Öffne jede: Scrolle durch Live-Seiten und beobachte ihre Bewegung. Wenn eine nicht lädt oder nur ein Thumbnail ist, frage nach einem Screenshot. Arbeite niemals von einem Titel oder einer URL aus. Speichere einen Screenshot von jeder für references/ und notiere jede gesehene Bewegung. Bevorzuge PNG: JPEG macht dünne farbige Linien grau.

   Lies dann references/measure.md und messe einen Ausschnitt pro Merkmal, das du möglicherweise übernimmst (eine Überschrift, ein Button, eine Linie, ein Hintergrundbereich), alles in einem Durchlauf.

2. Lies das Projekt. Tue dies, bevor du einen Stil auswählst, damit die Richtung bereits passt:

   • Lies design/styles/index.md, falls vorhanden, damit der neue Stil nicht mit früheren kollidiert, und notiere, welche Slugs bereits vergeben sind.
   • Liste 4–8 reale Objekte, Materialien, Prozesse, Maße oder Orte auf, jeweils mit Quelle. Beginne mit der gemeinsamen Themenliste des Indexes. Verwende reale Dinge, keine Symbole des Themas, und lasse alles weg, was du nicht quellen kannst.
   • Finde die Tokens der Seite (CSS custom properties, Framework-Klassen oder Webflow-Variablen) und jeden verwendeten Komponententyp, wie Überschriften, Buttons, Karten, Abbildungen, Listeneinträge, Navigation und Formulare, mit dem Ort, wo jeder lebt. Der Guide gestaltet ihr Aussehen um; ihr Inhalt und ihre Struktur bleiben.

3. Lies den Stil. Mit mehreren Referenzen lies, was sie gemeinsam haben. Ordne jedes Merkmal dem Ausschnitt zu, der es zeigt; dieser Nachweis kommt in den Guide, nicht in den Chat.

   Übernehmen: der Stil	Weglassen: was zu einer Referenz gehört
   Palette, Schriftcharakter, Linie und Form, Oberfläche, Dichte, Rhythmus, Hierarchie, Bewegung	Assets, Logos, Kopie, exakte Seitenlayouts, einmalige Details

   Gib jedem Übernehmen-Merkmal eine Stärke, festgehalten in der Stärken-Spalte des Guides:

   Stärke	Wo das Merkmal erscheint	Verwendet für
   quiet	Nur die 1–3 Orte, an denen es am meisten bewirkt, benannt	Der Start für jedes markante Merkmal (eine Akzentfarbe, eine Auszeichnungsschrift, eine Textur, ein Motiv)
   full	Jede Komponente, auf die es passt	Der Start nur für das, was jede Seite braucht: die Seitenoberfläche, die Textfarbe, und Merkmale, die keine Stimmung erzeugen (wie eckige Ecken)
   strong	Jede Komponente, auf die es passt, und mit mehr Raum: mehr Fläche, eine besondere Verwendung	Nur, wenn der Benutzer nach mehr fragt

   Ein stilles Merkmal herunterzudrehen bedeutet, es in die Weglassen-Spalte zu verschieben.

   Entscheide den Stil selbst (siehe Entscheidungen): wähle die Merkmale, einen Namen, dessen Slug nicht vergeben ist (es sei denn, der Benutzer bat darum, diesen Stil zu überarbeiten), und eine Richtung, die nicht mit einem bestehenden Stil kollidiert. Halte hier nicht an, es sei denn, die Referenzen widersprechen sich auf eine Weise, die nichts klärt.

4. Schreibe den Guide. Jeder Durchlauf bekommt seinen eigenen Ordner, damit kein Durchlauf einen anderen überschreibt:

   design/styles/
     index.md              jeder Stil, wo er gilt, gemeinsame Themenliste
     <slug>/
       style.md            der Guide
       board.html          die visuelle Überprüfung
       measured.json       was measure.py aus den Referenzen gelesen hat
       verify.md           wie genau die Tafel mit ihnen übereinstimmt
       references/         Referenz-Screenshots
   

   Kopiere assets/style.md aus diesem Skill in style.md und fülle es aus. Behalte jede Überschrift in der Reihenfolge und schreibe None für einen leeren Abschnitt, damit alle Guides gleich lesen. Schreibe Werte exakt (hex, px, Schriftnamen), damit eine andere Sitzung den Stil ohne die Referenzen neu aufbauen kann.

   • Nachweis: eine Zeile pro gemessenem Ausschnitt, Zahlen aus der Ausgabe von measure.py kopiert.
   • Tokens: Jedes Token gibt an, woher es stammt: crop:<name> (der Wert wird dort gemessen; eine Farbe muss mit der Messung dieses Ausschnitts oder seinem likely-Wert übereinstimmen), derived: <regel> (aus gemessenen Token aufgebaut, z. B. ein Hover-Ton oder eine Textfarbe, die auf 4,5:1 abgedunkelt wurde), oder chosen: <grund> für das, was keine Referenz zeigt, wie Zustände und Fließtext. Maße stammen ebenfalls aus Messungen: Die Schriftgröße ist die Versalhöhe (die Tintenhöhe eines Schriftausschnitts in Großbuchstaben) ÷ das Versalhöhenverhältnis der Schrift. Jede Regel nennt eine reale Themenquelle und verwendet nichts aus der Weglassen-Spalte. Stelle jedem Token --<slug>- voran, damit Stile eine Seite teilen können, ohne zu kollidieren.
   • Komponenten: Gib jedem Komponententyp eine Eigenschaftstabelle (Eigenschaft, dann Token oder exakter Wert, für jeden Zustand), damit sie ohne Raten neu aufgebaut werden kann. Verwende Tokens, wo immer eines existiert. Folge der Stärke jedes Merkmals: Eine Komponente außerhalb der benannten Orte eines stillen Merkmals verwendet stattdessen die schlichteren Tokens des Stils, wie die Grundschrift oder die Tintenfarbe.
   • Mapping: Ordne jedes vorhandene Token, jede Klasse oder Variable aus Schritt 2 und jeden Komponententyp seinem neuen Token oder seiner Komponentenspezifikation zu. Daraus arbeitet das Anwenden des Stils, lasse also nichts im Projekt unmappiert: Schreibe Keep oder Drop mit einem Grund, wo nichts ersetzt wird.

5. Zeige den Stil, dann iteriere. Lies references/board.md, kopiere assets/board.html als Dateikopie (nicht durch erneutes Abtippen) und fülle seine Platzhalter allein aus dem Guide: jeden Komponententyp mit Zuständen, einen Styles-Bereich, einen sehr kleinen echten Bereich und Bewegung, jeweils mit data-crop für den Ausschnitt, aus dem es stammt. Dann verifiziere es gegen die Referenzen und prüfe es gegen den Guide, und behebe jeden Fehler selbst, für maximal drei Runden:

   python3 <dieses-skill>/scripts/verify.py design/styles/<slug>
   python3 <dieses-skill>/scripts/check.py design/styles/<slug>
   

   Öffne die Tafel im Browser des Benutzers und gib die Pfade zu board.html und verify.md an.

   Füge dann den Stil und alle neuen Themen-Elemente zu design/styles/index.md hinzu, erstelle es aus assets/index.md falls nötig. design/styles/ ist der einzige Ort im Projekt, den dieses Skill ändert.

   Halte für die Überprüfung an mit dem Block aus Entscheidungen: etwas zu ändern? Die Genauigkeit wird durch verify.md angezeigt, zusammen mit allem, was nach drei Runden noch fehlschlägt, damit der Benutzer nur Richtung und Stärke beurteilt. Aktualisiere für jede Feedback-Runde den Guide, baue nur die betroffenen Teile der Tafel neu auf, führe dann verify und die Prüfung einmal aus und behebe, was sie melden, für maximal drei Runden, ohne die Änderungen des Benutzers rückgängig zu machen. Aktualisiere den Index, wenn sich der Name oder die Themenliste geändert hat, öffne die Tafel erneut und frage noch einmal. Jede Runde endet gemessen, damit der gespeicherte Stil immer genau ist, wann immer der Benutzer anhält. Um ein Merkmal hoch- oder herunterzudrehen, ändere seine Stärke (schreibe (user feedback) dahinter) und die Komponenten, die es erreicht; Werte bleiben gemessen, daher benötigt dies kein data-accept. Wenn der Benutzer ein Merkmal kräftiger wünscht als die Referenz selbst (größer, schwerer, gesättigter), ändert das einen Wert: behandle es wie unten. Eine Änderung, die der Benutzer wünscht, ist beabsichtigt, auch wenn sie sich von einer Referenz entfernt: gib dem Token chosen: user feedback und markiere sein Sample mit data-accept mit demselben Grund, damit verify es als beabsichtigt meldet, anstatt es als Fehler zu werten, und mache es niemals rückgängig, um verify bestehen zu lassen. Wenn der Benutzer die Richtung selbst ablehnt und nicht nur Details, flicke keine Tokens: gehe zurück zu Schritt 3, lies die Referenzen erneut, wähle eine neue Richtung, baue neu auf und halte für die Überprüfung erneut an.

   Der Durchlauf endet, wenn der Benutzer nichts zu ändern hat oder zu etwas anderem übergeht. Es gibt keinen Genehmigungsschritt. Um den Stil später zu verwenden, benennt ihn der Benutzer, und das Skill wendet ihn an (siehe Anwenden eines gespeicherten Stils).

Anwenden eines gespeicherten Stils

Wenn der Benutzer einen gespeicherten Stil zur Verwendung benennt, z. B. „wende <slug> überall an“ oder „verwende <slug> auf der Preisseite“, lies references/rollout.md und folge ihm. Es arbeitet allein aus dem Guide: es fügt die Tokens des Guides zum Projekt hinzu, arbeitet dann Zeile für Zeile durch das Mapping und gestaltet jede Komponente aus ihrer Eigenschaftstabelle um, ohne ihren Inhalt oder ihre Struktur zu ändern. Überspringe die Schritte 1–5: Der Stil ist bereits definiert.

Beispiel

Lies examples/drafting-sheet/style.md und verify.md; die JSON-Dateien und board.html sind generierte Ausgabe, es lohnt sich nur, sie zu öffnen, um die data-crop-Tags zu sehen. examples/drafting-sheet/ ist ein abgeschlossener Durchlauf: Eine Zeichenblatt-Referenz wurde in acht Ausschnitten gemessen, der Guide und eine Tafel, deren 36 Messungen übereinstimmen (eine absichtlich).

Referenzen: Technische Zeichnungen und Blaupausen, für eine Website über ein wachsendes Rad.

• Übernehmen: Dünne präzise Linienführung, gerasterte Gitter, kleine technische Beschriftungen, dichte Annotation.
• Weglassen: Den Schriftfeld, die Teile und das Blattlayout jeder Zeichnung.
• Thema: Ein 5,5 m wachsendes Rad, echte Rig-Maße, technische Zeichnungen.
• Regel: Blaupausen-Maßlinien + echte Rig-Maße = Abbildungen, die mit ihren gemessenen Werten annotiert sind.