taste-skill-swiftui

Was macht taste-skill-swiftui?

Ein von einem Modell erstellter App-Bildschirm sieht aus wie der Durchschnitt aller App-Bildschirme, die das Modell je gesehen hat: ein TabView mit vier Tabs, ein großer Titel, eine List mit abgerundeten Karten, die jeweils ein SF Symbol in einem getönten Quadrat enthalten, ein blauer „Los geht's“-Button mit Farbverlauf, ein Onboarding mit drei Symbolseiten, ein Paywall mit einem Lichteffekt. Nichts davon ist falsch und nichts davon war eine Entscheidung.

Dieses Skill ersetzt diese Standardwerte durch Entscheidungen – auf vier Arten:

1. Ein Skript teilt die Richtungen aus, du wählst daraus. Wenn ein Modell aufgefordert wird, einen Look zu erfinden, wählt es jedes Mal die Kategorie-Standardoption. scripts/draw.mjs teilt drei von zwölf recherchierten Richtungen aus; du wählst diejenige, die die Idee des Themas trägt, und es verteilt dann Typografie, Palette, Form, Bewegung und Bildschirm-Blaupausen.
2. Die Idee kommt vom Thema. Die besten Apps basieren auf etwas, das der Sache selbst entnommen ist (ihre Ausgabe, ihr Objekt, ihr Ritual, ihr gedrucktes Artefakt), nicht auf Styling.
3. Native first, Custom zielgerichtet. Jedes Element erklimmt eine Leiter (unten). Eigene Komponenten sind erlaubt, und sogar erwünscht, wenn die Idee eine braucht, aber sie müssen jedes native Verhalten mitbringen.
4. Du siehst dir an, was du gemacht hast. scripts/capture.sh fotografiert die App auf einem Geräte-Matrix, hell und dunkel, in Standard- und Barrierefreiheitstyp; eine Bewertungsrubrik beurteilt die Bilder; korrigieren, nochmal ansehen.

Ornamente wegzunehmen ist nur die halbe Arbeit. Ein Bildschirm, der seine getönten Quadrate, Karten und Farbverläufe verloren hat und nichts gewonnen hat, ist dünn. Die andere Hälfte ist Substanz: größere Schrift, ganze Farbflächen, echte Bilder oder gezeichnete Objekte aus der Welt dieses Themas, jeder Bildschirm mit seinem vollständigen Inhalt, und eine Sache, die der Benutzer tun kann, die nur diese App hat.

In den folgenden Befehlen ist <skill> der Ordner dieses Skills. Führe sie vom Projektstamm aus aus; Arbeitsdateien landen in .taste-skill/. Die Skripte benötigen Node 18+. capture.sh benötigt Xcode und gestartete Simulatoren. Wenn ~/.claude/bin/devlock existiert, wickle jeden xcodebuild- und simctl-Lauf in devlock run ein (parallele Builds haben bereits das Prozesslimit ausgeschöpft).

Die native Leiter

Klettere nur so weit, wie die Idee es erfordert, und dokumentiere jede Stufe-3-Komponente im Bericht.

1. Systemkomponente, System-Look. NavigationStack, TabView, List, Form, Toggle, Picker, Menu, ContentUnavailableView, .sheet mit Detents, ShareLink, Chart, ProgressView. Kostenlos: Dynamic Type, VoiceOver, Reduce Motion, RTL, Liquid Glass, Tastatur und Zeiger. Verwende diese für jedes Steuerelement, dessen Aufgabe die der Plattform ist.
2. Systemkomponente, gestylt. Gleiche Komponente, deine Tokens: ButtonStyle, LabelStyle, ToggleStyle, ListRowBackground, scrollContentBackground(.hidden), tint, fontDesign, fontWidth, containerShape. Hier lebt der Großteil einer Richtung.
3. Eigene Komponente. Nur wenn keine Systemkomponente die Idee tragen kann (ein Zifferblatt, ein Lineal, eine Eintrittskarte, eine Bühne, eine Zeitleisten-Spine). Eine eigene Komponente muss mitgeliefert werden: Dynamic Type durch @ScaledMetric/Font.custom(relativeTo:), eine minimale Berührungsfläche von 44×44pt, accessibilityElement mit Label, Wert, Eigenschaften und anpassbaren Aktionen, einen Reduce Motion-Pfad, Haptik durch sensoryFeedback, Dark Mode, RTL (layoutDirection), Fokus- und Zeigerzustände auf iPad/Mac, und eine Vorschau für jeden Zustand. Ein Steuerelement, das einen Satz Anleitung benötigt, wird neu gestaltet, nicht beschriftet.

Baue niemals etwas nach, das die Plattform bereits besitzt: keine handgezeichnete Tab-Leiste, Navigationsleiste, Schalter, Alert, Sheet oder Tastatur-Zubehör, es sei denn, die Idee kann nicht ohne sie leben. Verwende niemals handgemachte Blur-Panels; Liquid Glass stammt von System-Leisten, Symbolleisten und den System-Glas-APIs auf schwebenden Steuerelementen.

Web zu Mobil: Wie die ursprünglichen Regeln abgebildet werden

Taste-skill (Web)	Hier (nativ)
Seite vs. App-Bildschirm	Eine App ist fast immer die zweite Art. Der Bildschirm beim ersten Start, Onboarding und Paywall sind komponierte Bildschirme (folge dem Ablauf). Listen, Einstellungen, Formulare und Detailbildschirme sind Arbeitsbildschirme (folge references/screens.md).
Hero	Der erste Bildschirm nach dem Start (oder der Home-Tab). Er beantwortet „Was ist das, was mache ich“ in drei Sekunden, in großer Schrift oder einem großen Objekt.
Überschriften maximal zwei Zeilen bei jeder Breite	Zwei Zeilen in Standardgröße auf der Breite eines iPhone SE und iPad, und umbrechend (niemals abschneidend) bei Barrierefreiheitsgrößen.
Gleiche äußere Ränder, keine gedrängten Abschnitte	Verwende die System-Layout-Ränder (16/20pt); iPad und Querformat erhalten ihre eigene Komposition (Split View, Seitenleiste, zwei Spalten), niemals eine zentrierte Telefonspalte.
Echte Bilder Mindestanzahl (vier)	Ein echtes oder handgemachtes visuelles Element pro Hauptbildschirm. SF Symbole sind funktionale Glyphen, niemals das Bild.
Scroll-Szenen	scrollTransition, visualEffect, matchedGeometryEffect, navigationTransition(.zoom), KeyframeAnimator, PhaseAnimator, TimelineView.
Das Live-Ding	Der Wow-Moment: eine Interaktion, die nur diese App hat, mit Haptik, einhändig bedienbar.
inspect.mjs in einem echten Browser	capture.sh in Simulatoren plus lint.mjs auf Swift-Quellcode.
Bewegung Mindestanforderung	Mindestens sechs gezielte Bewegungsmomente beim ersten Durchlauf und im Kernablauf; jeder mit einem Reduce Motion-Fallback.
Kein Glas	Keine handgebauten Unschärfe-Karten. System-Glas auf System-Oberflächen ist in Ordnung.
Keine Monospace	.monospacedDigit() nur für ausgerichtete Zahlen. Niemals design: .monospaced außerhalb von Code.
Keine dünnen Linien	Vom System gezeichnete Listentrenner sind in Ordnung. Keine dekorativen Divider, keine 1pt umrandeten Karten.
Footer = gestalteter Abschluss	Die letzte Zeile eines langen Bildschirms oder der Endzustand eines Ablaufs ist gestaltet, kein nachfolgender Leerraum.

Der Ablauf

Führe diese in der Reihenfolge aus. Die Schritte 1–5 dauern ein paar Minuten und entscheiden, ob die App gut ist.

1. Lies das Briefing und das Projekt

Finde heraus, was real ist: das Thema, die Zielgruppe, die eine Sache, die ein Benutzer in der ersten Minute tun muss, die Plattformen und das Bereitstellungsziel, ein vorhandenes Designsystem oder Tokens, die Assets, die tatsächlich existieren (Fotografie, Produktaufnahmen, Illustrationen, Filmmaterial, ein Bildwerkzeug), und was in einem Redesign erhalten bleiben muss (Modelle, Intents, Widgets, Käufe, Lokalisierungen). Plane nicht um Assets herum, die du nicht hast. Wenn die Anfrage vage ist, entscheide und formuliere deine Lesart in einer Zeile; frage nur, wenn eine fehlende Tatsache die Arbeit blockiert.

Bestandsaufnahme des Themas: acht bis zwölf Dinge, die zu diesem Kunden und zu keinem Konkurrenten gehören. Sein Name und was er bedeutet; die Zahlen im Briefing (Minuten, Gramm, der Preis, die Serie); die Einschränkung, mit der er lebt (einmal am Tag, offline, ein Tipp); seine Materialien und Farben; seine Rituale und Stunden; die gedruckten Dinge seiner Welt (eine Eintrittskarte, ein Etikett, eine Quittung, ein Fahrplan, ein Reisepassstempel); sein Klang; seine physische Geste (schütteln, blasen, drücken und halten). Die Idee in Schritt 4 stammt aus dieser Liste.

2. Schreibe das Argument

Liste die App als Behauptungen mit ihrem Beweis auf, eine Zeile pro Bildschirm des Erststart- und Kernablaufs:

Bildschirm: Behauptung -> was der Benutzer als Beweis sieht oder tut.

Lösche jeden Bildschirm ohne Behauptung. So vermeidest du die Standardabfolge von Splash, drei Onboarding-Seiten, Berechtigungsanfrage, Paywall, Tab-Leiste mit vier Tabs. Onboarding verdient seinen Platz nur, wenn es den Benutzer das Kernding einmal tun lässt.

3. Zeichne die Richtung

node <skill>/scripts/draw.mjs --kind <kind> --brief "<eine Zeile über das Thema>" \
  --screens <Rollen in der Reihenfolge deines Arguments> [--tone <Ton>] [--have <Assets>] \
  [--keep Palette,Schriftart] [--platform ios|ipad|watch|mac|vision] --options 3

Dies verteilt drei Richtungen. Halte jede gegen deine Bestandsaufnahme: Welche kann etwas tragen, das nur dieser Kunde hat? Wähle diese, nicht die vertrauteste, und schreibe eine Zeile, warum. Verteile dann das vollständige Blatt:

node <skill>/scripts/draw.mjs <gleiche Argumente ohne --options> --direction <gewählte ID>

• --kind: node <skill>/scripts/draw.mjs --list kinds (Dienstprogramm, Gesundheit, Finanzen, Spiel, Kinder, Soziales, Medien, Produktivität, Lifestyle, Kreativ, Handel, Sonstiges).
• --screens: Rollen aus --list roles (Onboarding, Home, Detail, Erstellen, Ergebnisse, Einstellungen, Paywall, Leer).
• --tone: ruhig, kühn, warm, technisch, verspielt, luxuriös, redaktionell. Nur wenn das Briefing es verlangt.
• --have: Assets, die vorhanden sind: photography, product-photo, illustration, video, 3d. Lasse es weg, wenn keine vorhanden sind; der Wurf vermeidet dann Kompositionen, die davon abhängen.
• --keep Palette,Schriftart: wenn die Marke oder das Designsystem sie bereits festlegt. Der Wurf verteilt nur Komposition, Form und Bewegung; du weist die Werte des Systems den Rollen zu.
• --seed <n> macht einen Wurf wiederholbar; das Blatt gibt den verwendeten Seed aus.

Übernimm das Blatt. Mische es nicht mit dem Layout, das du ohnehin gemacht hättest. Zeichne einen Slot neu (--redraw typ|palette|shape|motion|screen:<role>|direction) nur aus einem Grund, den du nennen kannst: es widerspricht einer Markenvorgabe, benötigt ein nicht vorhandenes Asset, oder kann den echten Inhalt nicht aufnehmen. Zeichne niemals neu, um etwas Bequemeres zu erhalten. Dokumentiere jede Neuziehung im Bericht. Drucke erneut mit --show.

Überprüfe die Palette am Thema. Eine verteilte Palette ist ein Satz Proportionen (ein Grund, eine Tinte, ein Akzent, optionale Felder) ebenso wie Farben. Wenn sie mit dem eigenen Material des Themas kämpft, zeichne einmal neu, oder behalte die Proportionen und nimm die Farben vom Thema, und sage dies.

4. Finde die Idee

Die Richtung ist eine Art zu komponieren. Die Idee macht die App zu dieser Sache gehörig. Fülle beide Lücken aus dem Thema selbst, bevor du baust:

In dieser App wird [etwas, das zum Thema gehört] zu [dem Gerät, das die Richtung erfordert].

Suche in: seiner Ausgabe (was es produziert, als Material gezeigt), seinem Objekt (seiner Form, in Silhouette), seinem Namen (Buchstaben, die ein Bild halten), seinem Ort, seinem Ritual (eine Sequenz, die die App ausführt), seinem Artefakt (eine Eintrittskarte, ein Etikett, eine Quittung), seinem Gegenteil.

Der Wettbewerber-Test: setze den nächsten echten Wettbewerber in den Satz ein. Wenn es immer noch funktioniert, gehört die Idee zur Kategorie. „Sauber und modern“ ist keine Idee.

Der Wow-Moment (das Live-Ding). Gib der App eine Interaktion, die bei jeder Nutzung anders ist, gemacht aus der Idee: ins Mikrofon blasen und die Kerze flackert; die Dosis einstellen und die reale Halbwertszeitkurve ablesen; das Telefon falten und das Band läuft. Sie verwendet echte Inhalte, funktioniert einhändig mit dem Daumen, hat Haptik durch sensoryFeedback, einen Reduce Motion-Pfad und blockiert nie die Aufgabe. Es ist eine Sache, kein Spielplatz. Sie wird in Schritt 6 gebaut, nicht als Bewegung am Ende hinzugefügt.

5. Schreibe die Texte

Schreibe das gesamte Text-Deck (Klartext) vor den Ansichten, folge references/copy.md, und lege jeden String in den String-Katalog (Localizable.xcstrings) ab dem ersten Commit. Jeder Titel passt auf zwei Zeilen in Standardgröße; eine primäre Aktion pro Bildschirm, benannt nach dem, was sie tut (niemals „Los geht's“, „Weiter“ mit nichts dahinter, „Mehr erfahren“); leere, Fehler- und Berechtigungstexte jetzt schreiben, nicht später. Beweise werden nie erfunden: keine gefälschten Bewertungen, Benutzerzahlen, Auszeichnungen oder Presse.

6. Baue es – trotzdem

Baue mit Bewegung, die in deinem Kopf ausgeschaltet ist. Arbeitsreihenfolge:

1. Tokens. Palette/Theme aus dem Blatt als Asset-Katalog-Farben mit hellen und dunklen Varianten (oder ein ShapeStyle-Token-Enum), ein Typography-Enum, ein Metrics-Enum (Abstände, Radius, eine Formregel). Alles nachgelagerte referenziert nur Tokens. Kein Color(red:), kein .font(.system(size: 17)) in Ansichten.
2. Der erste Bildschirm, genau wie seine Blaupause es beschreibt, bei SE-Breite, Standard, Pro Max und iPad. Mach das große Ding groß und die kleinen Dinge klein, bevor irgendetwas anderes existiert.
3. Jeder Bildschirm gemäß seiner Blaupause mit dem Inhalt dieses Projekts. Benachbarte Bildschirme dürfen kein gemeinsames Layout haben. Trage die Idee in jeden Bildschirm, Einstellungen, Paywall und leere Zustände eingeschlossen; der häufigste Fehler ist ein unverwechselbarer Home-Bildschirm, gefolgt von Standard-Forms.
4. Bildmaterial, nach Präferenz: das eigene des Projekts; generiert (wenn du ein Bildwerkzeug hast); echte Bilder aus der Welt des Themas aus offenen Sammlungen mit lizenzierten Aufzeichnungen (references/imagery.md); in Code gezeichnet (Shape, Canvas, Path) als eine konsistente flache Grafiksprache in der Palette; Schrift und Farbe allein. SF Symbole nur als funktionale Glyphen.
5. Der Wow-Moment aus Schritt 4, im Bildschirm, wo er die Behauptung beweist.
6. Fülle. Betrachte jeden Bildschirm als Poster: eine dominierende Sache und den Inhalt, den sie trägt. Ein Bildschirm, der meist leerer Grund ist, ist unterdimensioniert. Fließtext in der vollen Tinte bei body oder größer.
7. Der Rahmen. Ein Rand-System. Jeder Bildschirm hat einen Titel (Navigationstitel oder einen großen Anzeigetitel) und jeder Listenabschnitt eine Kopfzeile, die ihn benennt.
8. Zustände und Semantik. Alle: Laden, Leer, Fehler, Offline, Berechtigung verweigert, Erfolg, deaktiviert, erster Start, langer Inhalt, Barrierefreiheitsgrößen, RTL. Echte Buttons, sichtbarer Fokus, Labels, accessibilityHint nur dort, wo das Label es nicht tragen kann, VoiceOver-Reihenfolge, Reduce Motion und Kontrast erhöhen respektiert.
9. Plattform-Baseline (aus den globalen Regeln): String-Katalog mit en-US, en-GB, en-AU, en-CA und es-MX; requestReview nur nach einem positiven Moment, gesteuert durch Zähler und Tage seit Installation, einmal pro Version; Haptik; Dunkel und Hell; App Intents, wo die App eine Kernaktion hat.

Lies references/type.md, colour.md, layout.md und components.md, wenn du die Details hinter einer Entscheidung benötigst; die Gesetze unten sind die Kurzform.

7. Gate

node <skill>/scripts/lint.mjs <Swift-Dateien oder Ordner>
<skill>/scripts/capture.sh <Bundle-ID> .taste-skill/capture   # gestartete Simulatoren

lint.mjs durchsucht Swift-Quellcode nach verbotenen Mustern, Standardphrasen und fehlenden Baselines (String- Katalog, Reduce Motion, Haptik). capture.sh startet die installierte App auf jedem gestarteten Simulator in hell und dunkel sowie in Standard- und Barrierefreiheitsgrößen und speichert die Screenshots. Behebe jedes FAIL; behandle jedes WARN als falsch, es sei denn, du kannst es einem Designer in einem Satz verteidigen. Führe erneut aus, bis kein FAIL mehr vorhanden ist. Eine Zeile kann mit einer T…

…[aus Platzgründen gekürzt für die Übersetzung]