justin-figma-design

Justin Figma Design (/jfd)

Dieser Workspace ist ein Figma-zentrierter Kollaborations-Workspace, keine Anwendungs-Codebasis. Diese Fähigkeit ist die Orchestrierungsschicht: Workspace Memory, der Figma Console Workflow, Design-System-Disziplin und evidenzbasierte visuelle QA. Generiere kein React, HTML oder CSS, es sei denn, der Benutzer fordert explizit Design-to-Code an.

Erforderlicher MCP-Begleiter

Die gesamte Figma-Arbeit basiert auf Figma Console MCP (user-figma-console): figma_execute für Inspektion und Mutation, figma_take_screenshot für Belege, figma_get_status und figma_reconnect für die Desktop-Bridge-Verbindung. Schreibarbeit erfordert den lokalen/NPX-Server mit verbundener Desktop Bridge; der gehostete Remote-Modus ist schreibgeschützt. Lese references/figma-execute.md vor dem Schreiben eines Skripts und die Workspace-Datei docs/tools/figma-console.md (im Workspace-Root) für Verbindungsdetails. Behandle /jfd nicht als eigenständigen Figma-Editor ohne diese MCP-Verbindung.

Fakten aus dem Design ermitteln, nicht aus dieser Fähigkeit

Diese Fähigkeit liefert Prozeduren, keine Fakten. Gerätegrößen, Schriftarten, Abstände und Stilpräferenzen ändern sich im Laufe der Zeit; die Zieldatei ist immer aktuell. Löse jeden benötigten Wert – eine Abmessung, Schriftart, Abstandsschritt, Farbe, Namen oder Konvention – in dieser Reihenfolge:

1. Die Zieldatei. Messe den tatsächlichen Frame, Text, Token oder die Komponente.
2. Die Familie. Geschwister-Frames, -States und -Bildschirme im selben Abschnitt.
3. Workspace Memory. Die Dateien docs/files/<alias>/design.md und docs/preferences.md, unter Beachtung ihrer „Zuletzt verifiziert“-Daten.
4. Der Benutzer oder eine aktuelle Recherche. Frage nach oder suche aktuelle plattformspezifische Richtlinien. Vertraue niemals auf gespeicherte Gerätegrößen oder alte Standardwerte.
5. Rückmeldung. Schreibe den ermittelten Wert mit dem heutigen Datum in das entsprechende design.md, damit die nächste Sitzung darauf vertrauen kann.

Löse niemals einen Projektwert aus dem eigenen Text dieser Fähigkeit.

Zwei Workflows

• Bearbeiten einer vorhandenen Datei (Standard): Es gibt etwas zu messen. Befolge die vollständige Schleife unten und nimm niemals eine Root-Frame-Größe an – messe das tatsächliche Root der zu bearbeitenden Familie.
• Neuanfang: Es existiert nichts zu messen, daher läuft die Auflösungsreihenfolge über die Schritte 3–5. Lese references/starting-from-scratch.md. Bestätige Root-Frame-Größe, Typografie und Theme-Unterstützung mit dem Benutzer, bevor du baust, und erstelle dann sofort das design.md der Datei, damit jede spätere Sitzung messen statt raten kann.

Initialisiere einen leeren Workspace

Verwende den init-Modus, wenn dem Workspace docs/preferences.md und docs/FILES.md fehlen. Init ist ein lokales, idempotentes Grundgerüst; es öffnet nie Figma, ruft das MCP auf oder mutiert eine Canvas.

1. Behandle jfd init gleich wie /jfd init, wenn der Host keine Slash-Aliase unterstützt.
2. Liste fehlende Grundgerüstpfade vor dem Schreiben auf. Frage in einem nicht-leeren Workspace zuerst nach Bestätigung. Überschreibe niemals eine vorhandene Datei, ein Verzeichnis, einen Symlink oder eine Skill-Installation.
3. Kopiere nur die fehlenden Dateien aus den assets/templates/ dieser Fähigkeit.
4. Installiere eine fehlende Skill-Kopie unter .agents/skills/justin-figma-design/ (kanonisch) und .cursor/skills/justin-figma-design/, wenn angemessen.
5. Führe optional scripts/init_project.py (Python 3, nur Stdlib) für einen Massendurchlauf aus; Agent-Dateiwerkzeuge bleiben der primäre Pfad.
6. Überprüfe das Grundgerüst, frage dann nach einem Figma-Link oder Datei-Key. Erfinde niemals Anmeldeinformationen oder Dateidaten.

Details: references/getting-started.md.

Wähle den Betriebsmodus

Non-YOLO ist die Voreinstellung.

• Non-YOLO für Produktionsarbeit: gemeinsame Patterns, Bildschirme, Komponenten, Variablen, Themes, reaktive Änderungen und jeder Umfang, der nicht explizit wegwerfbar ist.
• YOLO nur, wenn der Benutzer explizit „YOLO“, „Quick Demo“, „Rapid Prototype“ oder gleichwertiges sagt und der Umfang ein einzelnes benanntes Board oder einen State umfasst.
• „Erstelle eine Komponente“, „aktualisiere eine Bibliothek“, „unterstütze Hell und Dunkel“ oder eine Shared-Chrome-Änderung ist nie YOLO, nur weil sie klein ist.
• Bleibe im Plan-Modus, bis der Benutzer klar um Implementierung oder Ausführung bittet.

YOLO reduziert den Bibliotheks-Overhead; es entfernt keine Sicherheit oder visuelle QA. Eskaliere zu Non-YOLO bei Entdeckung von Shared Chrome, einem wiederverwendbaren Pattern, mehreren verwandten States, Light/Dark- oder responsive-Propagation, einer Master-Komponentenänderung, einem Auto-Layout-Refaktor, einer Geschäftsregeländerung oder einem zweiten Board. Vollständiger Router und Checklisten: references/modes-and-workflow.md.

Vor jeder Figma-Mutation

1. Lese docs/preferences.md und docs/FILES.md im Workspace-Root.
2. Löse das Ziel-Datei-Alias auf und lese dessen docs/files/<alias>/design.md; lies screens.md für Bildschirm-, Flow- oder zusammengesetzte Oberflächenarbeit.
3. Lese die neueste relevante Sitzungsnotiz. Das lebende design.md und die aktuelle Autorität haben Vorrang vor veralteten historischen Notizen.
4. Bestätige die aktive Figma-Datei, Seite, Abschnitt/Frame und Autorität. Suche Node-IDs, Komponenten, Variablen und Styles in der verbundenen Datei; IDs aus früheren Sitzungen sind veraltete Belege, keine Autorisierung.
5. Inventarisiere die gesamte gleiche-Frame/State-Familie vor einer gemeinsamen Änderung: Hell/Dunkel, aufgeklappt/zugeklappt, verschachtelte aktive Routen, Overlays, responsive Varianten und absichtlich entfernte States.
6. Messe die Root-Frames der zu bearbeitenden Familie. Gehe niemals von einer Gerätegröße aus.
7. Vor Textmutation: Untersuche stilisierte Schriftsegmente und lade die aktuellen Schriftarten. Wähle jede Ersatzschriftart über die Auflösungsreihenfolge – gemessener Text, dann design.md, dann der Benutzer – niemals aus dieser Fähigkeit.

Wenn die Zieldatei kein design.md hat, erstelle zuerst eine reine Leseuntersuchungs-Baseline. Wenn die aktive Datei oder Autorität nicht verifiziert werden kann, stoppe und frage nach.

Übliche Grafiken

Vor dem Platzieren von Icons oder importierten Bildern lese docs/assets/README.md und docs/assets/icons.md im Workspace-Root. Bevorzuge vorhandene Dateikomponenten und die genehmigten Icon-Quellen des Projekts; überprüfe Vektorgrenzen, Größe und Theme-Kontrast, bevor du eine neue Grafik akzeptierst. Avatare werden nur vom Benutzer bereitgestellt; generiere sie niemals.

Non-YOLO-Vertrag

• Durchsuche zuerst autoritative lokale Instanzen/Komponenten, dann aktivierte Bibliotheken, dann breitere Bibliothekssuche. Erstelle nur nach Dokumentation der Lücke.
• Baue das minimale kohärente Design-System für den genehmigten Umfang: Variablen und Modi zuerst, dann Styles und Komponenten, dann Bildschirm-Instanzen.
• Verwende Varianten für strukturelle/visuelle States und Komponenteneigenschaften für Inhaltsflexibilität. Bevorzuge Instanzen, Instanzwechsel und kontrollierte Wrapper gegenüber losgelösten Neuzügen.
• Mache Layout-Intention lesbar: semantische Namen, sinnvolle Hierarchie, Auto Layout, wo Kinder in Beziehung stehen, Token-Bindungen, Komponentenbeschreibungen und dokumentierte Barrierefreiheits-/State-Informationen.
• Behandle Hell/Dunkel als Variablen-Mode-Matrix, nicht als zwei hartcodierte Bildschirme. Siehe references/variables-and-theming.md.
• Wende gemeinsame Änderungen auf die vollständige verwandte-Bildschirm-Familie in einem Durchgang an und QA dann jedes Mitglied. Eine Einzelframefix ist nicht vollständig, während Geschwister veraltet sind.

Lese references/components-and-design-system.md und references/layout-and-autolayout.md vor komplexer Arbeit.

Layout-Regeln

Wähle Hug, Fill, Fixed und min/max unabhängig pro Achse: Hug für inhaltsgetriebene Stapel und Steuerelemente; Fill nur für ein Kind mit sinnvollem verfügbarem Platz in einem Auto-Layout-Elternelement; Fixed für beabsichtigte strukturelle Grenzen (gemessene Bildschirm-Roots, Icon-Boxen, CTAs, kalibrierte Hüllen); min/max für genehmigte responsive Grenzen. Kodiere Beziehungen mit verschachteltem Auto Layout, Padding und Abstand – niemals unsichtbare Spacer-Frames, die alte Koordinaten bewahren. Behalte Ebenen mit Absolute / Ignore-auto-layout nur für begründete Overlays, Chrome, Dekoration oder Ausnahmen, die im Ziel-design.md dokumentiert sind. Nach der Größenänderung eines Containers prüfe breitenbesitzende Nachkommen; ein breiteres Elternelement ist kein vollständiger Reflow. Details: references/layout-and-autolayout.md.

Ausführen und überprüfen

Inspiziere, führe ein kleines gezieltes figma_execute aus, gib jede mutierte ID und nützliche Geometrie zurück, mache dann sofort einen Screenshot mit figma_take_screenshot. Halte Schreibvorgänge und Screenshots sequenziell, wenn das Routing von der aktiven Datei abhängt. QA kombiniert gemessene Struktur mit visuellen Belegen – erfasse, je nach Anwendungsfall: (1) einen fokussierten Komponentenausschnitt, (2) das gesamte Board, (3) die verwandte Familien- oder Abschnittsübersicht. Überprüfe gemeinsame Kanten, Abstände, Clipping, Überlauf, Langtextverhalten, Icon/Vektorgrenzen, Kontrast, Typografie, versteckte Steuerelemente, semantische States, verwandte State-Parität, hartcodierte Werte, ungelöste Bindungen und Light/Dark-Auflösung. Verwende Figma Check-Designs, wenn verfügbar; führe andernfalls äquivalente strukturelle und manuelle Prüfungen durch.

Behandle ein fehlgeschlagenes figma_execute als potenziell teilweise, bis das Ziel inspiziert ist; führe niemals blind ein fehlgeschlagenes Erstellungs- oder Neuzuordnungsskript erneut aus. Wiederherstellungsvertrag: references/figma-execute.md. Vollständige Checklisten: references/qa-and-recovery.md.

Abschluss

• Mache finale Screenshots von jedem mutierten Board und erforderlichen Familienmitglied.
• Halte beabsichtigte Ausnahmen, Platzhalter, ungelöste Probleme und Umfangsgrenzen fest.
• Aktualisiere das Ziel-design.md und screens.md, wenn sich Autorität, Komponenten, Variablen, Bildschirme, Root-Größen oder Abweichungen geändert haben – einschließlich jedes während der Sitzung gelösten Werts.
• Schreibe eine datierte Notiz unter docs/sessions/ für bedeutungsvolle Arbeit.

Ehre die dokumentierten Schutzmaßnahmen der Zieldatei in ihrem design.md: gesperrte oder geschützte Originale, Stile oder States, die entfernt bleiben müssen, und Kopie und Sprache, die erhalten bleiben müssen. Speichere niemals Anmeldeinformationen oder private Token im Projektgedächtnis.

Für externe Anleitung hinter dieser Fähigkeit lese references/research-sources.md.