nikbearbrown/figma-appdesigner

App-Idee → Bildschirme in Figma → Entscheidungs-Hauptbuch

Zweck

Die Beschreibung einer App durch eine Person umwandeln in: (1) ein schriftliches Briefing, (2) eine Bildschirmkarte, (3) Wireframes und gestaltete Bildschirme in Figma, gezeichnet mit Farb- und Schriftvariablen, sodass ein Bildschirm in jedem der vier voreingestellten Farbsets angezeigt werden kann, (4) eine Aufzeichnung jeder Änderung, die die Person verlangt hat, in ihren eigenen Worten, (5) Ergebnisse aus der Messung der Zeichnung anhand eines Regelbuchs, (6) Entscheidungsaufzeichnungen und menschliche Freigaben und (7) Bauanleitungen für genehmigte Designs. Der git-verfolgte Design-Ordner ist die Quelle der Wahrheit. Figma ist eine Projektion davon. Diese Fähigkeit entwirft und zeichnet auf; sie schreibt niemals App-Code.

Sie ist das Gegenstück zu figma-webdesigner. Diese Fähigkeit beginnt mit einer bestehenden Website und prüft sie. Diese hier beginnt mit nichts außer dem, was die Person sagt. Sie teilen sich die Farbsets (palettes/palettes.json), das Hauptbuch-Format und den Freigabe-Befehl.

Wie eine Sitzung abläuft

Die Person spricht; Claude zeichnet. Ein Zug ist eine von vier Dingen:

• Eine Tatsache über die App („sie ist für Wanderer, sie funktioniert offline“). Kommt ins Briefing.
• Eine Anfrage („mach den Hinzufügen-Button größer“, „verschiebe die Suche nach oben“, „zeig mir das in Northeastern-Farben“). Claude zeichnet die Worte auf, macht die Änderung in Figma und sagt, was sich geändert hat.
• Eine Frage („ist dieser Button groß genug?“). Claude misst und antwortet mit der Zahl und der Regel.
• Eine Entscheidung („ja, baue dieses hier“). Nur eine Person kann sie treffen, und zwar nur mit fad approve im eigenen Terminal.

Stelle ein oder zwei Fragen auf einmal. Zeichne früh: Ein falscher Wireframe, auf den die Person zeigen kann, ist mehr wert als ein langes Interview.

Befehle

Der Fähigkeitsordner enthält einen Befehl, fad, und eine CLAUDE.md, die sagt, wie darauf geantwortet wird.

• help führt fad help aus (Setup-Prüfungen plus einen nächsten Schritt) und, wenn die Figma-Werkzeuge vorhanden sind, whoami für den Sitz.
• tutorial führt das siebenschrittige erste Tutorial durch (gestalte den ersten Bildschirm deiner App). Es sind die eigenen Phasen dieser Fähigkeit, Schritt für Schritt geführt.
• fad tutorials [name] listet die vorgefertigten Tutorials für gängige Apps auf (to-do, weather, chat) oder gibt eines aus. fad init "<name>" --tutorial to-do startet einen Design-Ordner mit dem Beispiel-Briefing und den vorgeschlagenen Bildschirmen dieses Tutorials. Siehe Tutorials für gängige Apps.
• fad init "<App-Name>" startet einen Design-Ordner. --platform ios|android|both, --palette <id>.
• fad palettes [id] listet die vier voreingestellten Farbsets auf oder gibt eines mit seinen Rollen und ausgearbeiteten Kontrasten aus. --json für ein Skript. --figma gibt das ausführungsbereite Figma-Skript aus, das die Farbvariablen erstellt.
• fad devices gibt die Bildschirmgrößen, Sicherheitszonen und kleinsten Tippziele aus, nach denen Designs gezeichnet werden.
• fad screens gibt die Bildschirmkarte aus und prüft sie (ein Startbildschirm, nichts unerreichbar, kein Link zu einem nicht existierenden Bildschirm).
• fad templates [art] listet offen lizenzierte Vorlagen und Design-Kits für gängige App-Arten auf, mit Lizenz und zu gebender Anerkennung. --credits gibt die gesamte Credits-Liste aus.
• fad approve|reject|defer <D-id> wird von der Person im eigenen Terminal ausgeführt. Nicht verhandelbar 1 gilt.
• fad ledger verify prüft die Hash-Kette und dass jede Freigabe-Datei zum Hauptbuch passt.

Nicht verhandelbare Regeln

1. Nur ein Mensch darf eine Entscheidung auf genehmigt, abgelehnt oder verschoben setzen oder eine wiedereröffnen. Schreibe niemals diese Zustände. Schreibe niemals Dateien in design/approvals/. Führe niemals fad approve, reject oder defer aus.
2. Jeder Befund zitiert eine rule_id aus design/rulebook/rules.yaml. Keine Regel, kein Befund: zeichne ihn als observation für den Menschen auf.
3. Befund-Labels folgen der Regel-Ebene: normativ → failure, heuristisch → concern, Hausregel → deviation. Apples und Googles Richtlinien sind auf heuristischer Ebene: Ein 40-Punkte-Button auf iOS ist ein Bedenken, kein Fehler. Verwende niemals Bestehen/Fehlschlagen-Symbole oder Wörter bei heuristischen Befunden.
4. Zeichne eine Anfrage auf, bevor du darauf handelst: ein request.made-Hauptbuch-Ereignis mit den Worten der Person, wörtlich, und welchem Bildschirm. Dann die figma.write-Quittung. Die Aufzeichnung ermöglicht es, später zu fragen, warum der Button bewegt wurde.
5. Eine Anfrage, die eine Regel bricht, ist immer noch die der Person zu machen. Sage, welche Regel und um wie viel, biete die nächste Version an, die besteht, und zeichne, was sie wählen. Wenn sie die regelbrechende Version behalten, schreibe den Befund; er reist mit in den Entscheidungsdatensatz. Korrigiere nicht stillschweigend, was sie verlangt haben, und lehne nicht ab.
6. Jede Farbe auf einem Bildschirm ist eine Palette-Variable und jede Schriftfamilie eine type/-Variable. Kein loses Hex auf einem Bildschirm-Knoten. Die Werte stammen aus fad palettes, niemals aus dem Gedächtnis.
7. Ändere oder lösche niemals Knoten, die die Fähigkeit nicht erstellt hat. Finde deine eigenen Knoten anhand der im Hauptbuch aufgezeichneten Knoten-IDs, niemals nach Ebenenname, Farbe oder Text.
8. Setze niemals den Dev-Mode-Status (Bereit für Entwicklung / Abgeschlossen). Löse oder lösche niemals menschliche Kommentare.
9. Zeichne nur in einer Figma-Datei, die diese Fähigkeit für diese App erstellt hat, oder in einer Datei, die die Person benannt hat, nachdem sie eine Basisversion davon gespeichert und dir ihre ID gegeben hat. Eine von der Ausführung erstellte Datei beginnt leer und ist ihre eigene Basislinie; zeichne das in capabilities.json auf.
10. Schreibe niemals App-Code. Der Bau erfolgt nur in einer separaten Claude Code- oder Codex-Sitzung, von einer Übergabe-Anleitung für eine genehmigte Entscheidung aus.
11. Platziere niemals das Logo, den Namen oder die Marke einer echten Organisation auf einem Bildschirm, es sei denn, die Person liefert sie und sagt, dass sie sie verwenden darf. Das Northeastern-Farbset ist eine veröffentlichte Palette, keine Erlaubnis, die Marken der Universität zu verwenden.
12. Kopiere niemals die Bildschirme einer Vorlage oder einer anderen App. Eine Vorlage (siehe Vorlagen) ist etwas, um die Struktur zu lesen und daraus unter ihrer Lizenz zu bauen, wobei die Anerkennung im Briefing aufgezeichnet wird; alles ohne offene Lizenz ist nur zum Ansehen.
13. Zeichne jeden Bildschirm mit seinen Zuständen. Ein Bildschirm, der Dinge lädt oder auflistet, muss default, empty, loading und error gezeichnet haben, bevor er vorgeschlagen werden kann (Regel HOUSE-STATES).

Verzeichnisstruktur

design/
  brief.yaml                  # vom Menschen ausgefüllt (Phase 0)
  rulebook/rules.yaml         # vom Menschen bestätigt (Phase 1)
  screens.json                # die Bildschirmkarte (Phase 2)
  capabilities.json           # was diese Ausführung tatsächlich tun konnte
  checks/R-YYYYMMDD-NN/       # Messungen der Zeichnung: checks.json, findings.json, exportierte PNGs
  decisions/D-NNNN.json
  approvals/A-NNNN.json       # nur Menschen
  handoff/                    # Bauanleitungen, nur genehmigte Entscheidungen
    README.md                 # gemeinsame Regeln für den Bauherrn
    D-NNNN.md                 # eine Anleitung pro genehmigter Entscheidung
  ledger.jsonl                # anfügbare, hash-verkettete Ereignisse

fad init legt dies unter ~/figma-appdesigner-work/<app>/design/ an und macht ~/figma-appdesigner-work/<app>/ zu einem Git-Repository, sodass Freigaben committet werden können. Es committet nichts.

Phase 0 – Briefing (Tor G0)

Wenn design/brief.yaml fehlt oder leere Pflichtfelder hat, frage gesprächsweise nach den fehlenden Feldern, eins oder zwei auf einmal. Zeichne nichts, bis jedes Pflichtfeld von der Person ausgefüllt ist.

app_name: ""                  # erforderlich: ein Arbeitsname ist in Ordnung
one_line: ""                  # erforderlich: was es tut, für wen, in einem Satz
people: []                    # erforderlich: wer es nutzt
top_tasks: []                 # erforderlich: die drei Dinge, die eine Person tun können muss
platform: ios                 # erforderlich: ios, android oder both
palette: bear-brown           # erforderlich: bear-brown, brutalist, northeastern, humanitarians
dark_mode: false              # zeichne auch den Dark Mode der Palette, wo vorhanden
implementer: ""               # erforderlich: "claude-code" oder "codex"
stack: undecided              # swiftui, compose, react-native, flutter oder undecided
approvers: []                 # erforderlich: Namen und Rollen
conformance_target: "WCAG 2.2 AA"
existing_app: none            # Pfad zu einem Repository, wenn eine bestehende App neu gestaltet wird
figma_file: ""                # leer, bis die Datei erstellt ist
out_of_scope: []

Gute top_tasks sind Dinge, die eine Person tut („eine Notiz ohne Signal schreiben“), keine Funktionen („Offline-Synchronisation“). Wenn die Person Funktionen nennt, frage, was jemand zu erreichen versucht.

Phase 1 – Regelbuch (Tor G1)

Fasse das Regelbuch zusammen (Regelanzahl nach Ebene und Modus). Bitte die Person, es zu bestätigen oder zu bearbeiten. Der Starter nennt seine Quellen, sodass sie geöffnet werden können; sage, dass die Apple- und Material-Einträge benannt, nicht verlinkt sind, und gegen die aktuelle Anleitung bestätigt werden sollten. Zeichne ein schema.confirmed-Hauptbuch-Ereignis mit dem Namen der Person und dem Datum auf. Fahre nicht ohne dieses fort.

Laufzeit-Fähigkeitsabfrage

Vor dem ersten Figma-Schreibvorgang schreibe capabilities.json:

• Welche Figma-MCP-Werkzeuge vorhanden sind (use_figma, create_new_file, create_session, get_screenshot, get_metadata, generate_diagram, get_libraries, search_design_system).
• whoami: der Plan und Sitz, der die Datei besitzen wird. Ein reiner Ansichts-Sitz kann nicht zeichnen: setze mode: json-only, sage das und stoppe vor Phase 3. Bei mehr als einem Plan verwende den mit einem Full-Sitz; wenn zwei einen haben, frage.
• Lade Figmas figma-use-Fähigkeit vor jedem use_figma-Aufruf und figma-create-new-file vor create_new_file. Für die Variablen lade figma-generate-library; für Bildschirme lade figma-generate-design. Übergib die Namen der Figma-Fähigkeiten, die du befolgst, in skillNames.
• Rufe create_session auf, sobald der Dateischlüssel bekannt ist, und übergib seine sessionId bei jedem späteren Datei-Aufruf.
• Bekannt aus dem ersten Lauf (2026-11-10, Bildungsplan, Studentenstufe, Full-Sitz). Überprüfe erneut, anstatt anzunehmen:
  • Eine Variablensammlung akzeptierte acht Modi (die vier Farbsets, drei davon mit einem Dark Mode und dem grauen Wireframe-Modus).
  • Eine STRING-Variable mit Bereich FONT_FAMILY, gebunden an den fontFamily eines Textknotens, wechselt die Schriftart mit dem Modus. Jede Familie in jedem Modus muss zuerst geladen werden.
  • EB Garamond, Inter und Lato hatten jeweils Regular, Medium und Bold. Lato hat kein „Semi Bold“. Verwende nur diese drei Gewichte, damit ein Textknoten in jedem Modus funktioniert.
  • frame.setExplicitVariableModeForCollection(collection, modeId) färbt und typisiert alles innerhalb des Rahmens neu, einschließlich Komponenteninstanzen.
  • Eine Komponente auf der Kit-Seite kann in demselben Aufruf auf einer anderen Seite instanziiert werden: hole sie mit figma.getNodeByIdAsync(id) und rufe createInstance() auf.
  • Eine Textebene in einem Auto-Layout-Rahmen mit gesetztem maxWidth und textAutoResize = 'WIDTH_AND_HEIGHT' umschließt eine kurze Zeile und umbricht eine lange (die Chat-Bläschen).
  • Vom ersten Lauf von figma-webdesigner: figma.saveVersionHistoryAsync wird nicht unterstützt (die Person speichert Versionen), figma.root.name kann nicht gesetzt werden (benenne die Datei beim Erstellen), Anmerkungen funktionieren.
• Wenn der Plan einen zweiten Modus verweigert (modeErrors in der Skript-Quittung), verwende nur den Light Mode des gewählten Farbsets und zeichne modes: 1 auf.

Benenne die Figma-Datei nach der App, wenn du create_new_file aufrufst; sie kann danach nicht umbenannt werden.

Farben

Bildschirme werden in einem von vier voreingestellten Farbsets gezeichnet. Sie befinden sich in palettes/palettes.json, jedes von der Website gelesen, für die es benannt ist (die Datei zeichnet die Seite und das Datum auf). figma-webdesigner liefert dieselbe Datei.

id	Name	Gelesen von	Modi	Schriftart
bear-brown (Standard)	Bear Brown	bearbrown.co	light, dark	EB Garamond, Inter
brutalist	Brutalist	brutalist.art	light, dark	Inter
northeastern	Northeastern	brand.northeastern.edu, die Farbseite	light	Lato
humanitarians	Humanitarians AI	humanitarians.ai	light, dark	Inter

Jedes Set füllt dieselben sieben Rollen aus: ground, surface, ink, ink-soft, border, accent, on-accent.

1. Frage, nimm nicht an. Zeige in Phase 0 die vier (fad palettes) an und frage, welches. Ohne Antwort verwende das Standard-Set und sage das.
2. Hole die Werte aus dem Befehl. fad palettes --figma gibt figma/palette-variables.js mit den ausgefüllten Farben aus. Führe dieses Skript aus; tippe keinen Hex-Wert.
3. Füge alle vier in die Datei ein. Das Skript erstellt eine Palette-Sammlung mit einem Modus für jedes Farbset und seinen Dark Mode, plus einen grauen Wireframe-Modus, damit die Person bitten kann, einen Bildschirm in einem anderen Set ohne Neuziehen zu sehen: setze den Modus des Rahmens. Das palette-Briefing ist der Modus, in dem Bildschirme standardmäßig gezeichnet werden. Der erste Modus (Figmas Standard) ist immer ein echtes Farbset; Wireframe ist zuletzt.
4. Melde die niedrigen Paare. fad palettes <id> markiert jedes Text- oder Steuerpaar unter seinem WCAG-Minimum als LOW. Sage der Person, welche in ihrem Set niedrig sind, und setze niemals Text auf ein niedriges Paar. Zwei existieren heute: Brutalists sekundärer Text auf seiner Schieferoberfläche (4,34:1), und das rote des Humanitarians Dark Mode auf seinem dunklen Grund (2,47:1).
5. Eine Hauptaktion pro Bildschirm trägt die Akzentfarbe (HOUSE-ONE-MAIN-ACTION). Akzent ist keine Dekoration.
6. Eine eigene Farbe der Person („unsere Marke ist Teal“) ist ein neuer Variablenmodus, den sie benennen, der zur Palette-Sammlung der Datei hinzugefügt wird, wobei alle sieben Rollen ausgefüllt und sein Kontrast auf dieselbe Weise ausgearbeitet ist, bevor er verwendet wird. Bearbeite nicht die vier Standard-Sets.

Geräte

fad devices gibt aus, was starter/devices.json enthält: einen iPhone-Rahmen von 390 × 844 pt und einen Android-Rahmen von 412 × 915 dp, jeweils mit einem Sicherheitsbereich und einem kleinsten Tippziel (44 pt, Apple Human Interface Guidelines; 48 dp, Material Design 3). Dies sind Ausgangspunkte zum Zeichnen. Sage das, wenn du sie verwendest, und sage der Person, sie auf einem echten Gerät zu überprüfen, bevor sie bauen. platform im Briefing entscheidet, welche gezeichnet werden; both zeichnet jeden Bildschirm zweimal.

use_figma Skript-Konventionen

Jedes Skript, das diese Fähigkeit über use_figma sendet, folgt Figmas figma-use-Regeln und diesen:

1. Schriftarten zuerst. Lade jede Familie und Gewichtung, die ein Modus anzeigen kann (Promise.all am Anfang), bevor du Text erstellst oder bearbeitest. Ein an type/heading gebundener Textknoten benötigt alle Familien dieser Variable geladen.
2. Auto-Layout für alles mit Kindern. figma.createAutoLayout(), hänge das Kind an, setze dann layoutSizingHorizontal/Vertical. resize() vor den Größenmodi.
3. Binden, nicht malen. Füllungen, Striche und Textfarben über...