taste-skill-swiftui

Que fait taste-skill-swiftui ?

Un écran d'application construit par un modèle ressemble à la moyenne de tous les écrans d'application que le modèle a vus : une TabView de quatre onglets, un grand titre, une List de cartes arrondies chacune avec un symbole SF dans un carré teinté, un bouton bleu dégradé « Commencer », un onboarding de trois pages symboles, un paywall avec un halo. Rien n'y est faux et rien n'y a été décidé.

Ce skill remplace ces valeurs par défaut par des décisions, de quatre façons :

1. Un script distribue les directions, vous choisissez parmi elles. Quand on lui demande d'inventer un look, un modèle choisit systématiquement le choix par défaut de la catégorie. scripts/draw.mjs distribue trois des douze directions de recherche ; vous choisissez celle qui porte l'idée du sujet, puis il distribue la typographie, la palette, la forme, le mouvement et les plans d'écran.
2. L'idée vient du sujet. Les meilleures applications sont construites sur quelque chose tiré de la chose elle-même (son résultat, son objet, son rituel, son artefact imprimé), pas sur le style.
3. Nativer d'abord, personnalisé à dessein. Chaque élément monte une échelle (ci-dessous). Les composants personnalisés sont autorisés, et encouragés quand l'idée en a besoin, mais ils doivent intégrer tous les comportements natifs.
4. Vous regardez ce que vous avez fait. scripts/capture.sh photographie l'application sur une matrice d'appareils, en mode clair et sombre, avec la police par défaut et la police d'accessibilité ; une grille d'évaluation juge les images ; corrigez, regardez à nouveau.

Supprimer les ornements ne représente que la moitié du travail. Un écran qui a perdu ses carrés teintés, ses cartes et ses dégradés sans rien gagner est vide. L'autre moitié est la substance : une typographie plus grande, des champs de couleur entiers, de vraies images ou des objets dessinés du monde de ce sujet, chaque écran avec son contenu complet, et une chose que l'utilisateur peut faire que seule cette application possède.

Dans les commandes ci-dessous <skill> désigne le dossier de ce skill. Exécutez-les depuis la racine du projet ; les fichiers de travail atterrissent dans .taste-skill/. Les scripts nécessitent Node 18+. capture.sh a besoin de Xcode et de simulateurs lancés. Quand ~/.claude/bin/devlock existe, encadrez chaque exécution de xcodebuild et simctl avec devlock run (les constructions parallèles ont déjà épuisé la limite de processus).

L'échelle native

Ne montez que jusqu'à ce que l'idée exige, et enregistrez chaque composant de l'échelon 3 dans le rapport.

1. Composant système, aspect système. NavigationStack, TabView, List, Form, Toggle, Picker, Menu, ContentUnavailableView, .sheet avec détentes, ShareLink, Chart, ProgressView. Gratuit : Dynamic Type, VoiceOver, Reduce Motion, RTL, Liquid Glass, clavier et pointeur. Utilisez-les pour tous les contrôles dont le travail est celui de la plateforme.
2. Composant système, stylisé. Même composant, vos jetons : ButtonStyle, LabelStyle, ToggleStyle, ListRowBackground, scrollContentBackground(.hidden), tint, fontDesign, fontWidth, containerShape. C'est là que vit la majeure partie d'une direction.
3. Composant personnalisé. Uniquement lorsqu'aucun composant système ne peut porter l'idée (un cadran, une règle, un ticket, une scène, une épine de frise chronologique). Un composant personnalisé doit inclure : Dynamic Type via @ScaledMetric/Font.custom(relativeTo:), une zone de contact minimale de 44×44 points, accessibilityElement avec étiquette, valeur, traits et actions ajustables, un chemin Reduce Motion, des haptiques via sensoryFeedback, le mode sombre, RTL (layoutDirection), les états de focus et de pointeur sur iPad/Mac, et un aperçu pour chaque état. Un contrôle qui nécessite une phrase d'instructions est reconçu, pas légendé.

Ne reconstruisez jamais ce que la plateforme possède : pas de barre d'onglets, barre de navigation, interrupteur, alerte, feuille ou accessoire de clavier dessiné à la main, sauf si l'idée ne peut pas vivre sans. Ne fabriquez jamais un panneau de flou à la main ; Liquid Glass provient des barres système, des barres d'outils et des API de verre système uniquement sur les contrôles flottants.

Du web au mobile : correspondance des règles originales

Taste-skill (web)	Ici (natif)
Page vs écran d'application	Une application est presque toujours du second type. L'écran de premier lancement, l'onboarding et le paywall sont des écrans composés (suivez le run). Les listes, paramètres, formulaires et écrans de détail sont des écrans de travail (suivez references/screens.md).
Hero	Le premier écran après le lancement (ou l'onglet Accueil). Il répond à « qu'est-ce que c'est, que dois-je faire » en trois secondes, en grands caractères ou avec un grand objet.
Titres de deux lignes maximum à toutes les largeurs	Deux lignes à la taille par défaut sur la largeur de l'iPhone SE et de l'iPad, et avec retour à la ligne (jamais tronqué) aux tailles d'accessibilité.
Marges extérieures égales, pas de sections serrées	Utilisez les marges de mise en page du système (16/20 points) ; l'iPad et le paysage ont leur propre composition (vue partagée, barre latérale, deux colonnes), jamais une colonne centrée façon téléphone.
Plancher d'images réelles (quatre)	Un visuel réel ou fait main par écran clé. Les symboles SF sont des glyphes fonctionnels, jamais l'image.
Scènes défilantes	scrollTransition, visualEffect, matchedGeometryEffect, navigationTransition(.zoom), KeyframeAnimator, PhaseAnimator, TimelineView.
La chose vivante	Le moment « wow » : une interaction que seule cette application possède, avec haptiques, utilisable d'une seule main.
inspect.mjs dans un vrai navigateur	capture.sh dans les simulateurs plus lint.mjs sur le code source Swift.
Plancher de mouvement	Au moins six moments de mouvement intentionnels répartis sur le premier lancement et le flux principal ; chacun avec un recours Reduce Motion.
Pas de verre	Pas de cartes floues faites à la main. Le verre système sur la chrome système est acceptable.
Pas de monospace	.monospacedDigit() pour les nombres alignés uniquement. Jamais design: .monospaced en dehors du code.
Pas de règles fines	Les séparateurs de liste que le système dessine sont acceptables. Pas de Divider décoratif, pas de cartes contournées de 1 point.
Pied = conclusion conçue	La dernière ligne d'un écran long, ou l'état final d'un flux, est conçue, pas un espace vide.

Le run

Faites ces étapes dans l'ordre. Les étapes 1 à 5 prennent quelques minutes et décident si l'application est bonne.

1. Lire le brief et le projet

Trouvez ce qui est réel : le sujet, le public, la seule chose qu'un utilisateur doit faire dans la première minute, les plateformes et la cible de déploiement, un système de design ou des jetons existants, les ressources qui existent vraiment (photographie, photos de produits, illustrations, séquences, un outil d'image), et ce qui doit survivre lors d'une refonte (modèles, intentions, widgets, achats, localisations). Ne planifiez pas en fonction de ressources que vous n'avez pas. Si la demande est vague, décidez et énoncez votre interprétation en une ligne ; ne demandez que lorsqu'un fait manquant bloque le travail.

Inventaire du sujet : huit à douze choses qui appartiennent à ce client et à aucun concurrent. Son nom et ce qu'il signifie ; les chiffres du brief (minutes, grammes, le prix, la série) ; la contrainte avec laquelle il vit (une fois par jour, hors ligne, une seule tape) ; ses matériaux et couleurs ; ses rituels et heures ; les objets imprimés de son monde (un ticket, une étiquette, un reçu, un horaire, un tampon de passeport) ; son son ; son geste physique (secouer, souffler, appuyer et maintenir). L'idée à l'étape 4 vient de cette liste.

2. Écrire l'argumentation

Listez l'application sous forme d'affirmations avec leurs preuves, une ligne par écran du premier lancement et du flux principal :

Écran : affirmation -> ce que l'utilisateur voit ou fait comme preuve.

Supprimez tout écran sans affirmation. C'est ainsi que vous évitez la séquence standard de splash, trois pages d'onboarding, demande d'autorisation, paywall, barre d'onglets de quatre. L'onboarding mérite sa place uniquement s'il permet à l'utilisateur de faire la chose principale une fois.

3. Tirer la direction

node <skill>/scripts/draw.mjs --kind <genre> --brief "<une ligne sur le sujet>" \
  --screens <rôles dans l'ordre de votre argumentation> [--tone <ton>] [--have <ressources>] \
  [--keep palette,type] [--platform ios|ipad|watch|mac|vision] --options 3

Cela distribue trois directions. Confrontez chacune à votre inventaire : laquelle peut porter quelque chose que seul ce client possède ? Choisissez celle-là, pas la plus familière, et écrivez une ligne expliquant pourquoi. Ensuite, tirez la fiche complète :

node <skill>/scripts/draw.mjs <mêmes arguments sans --options> --direction <id choisi>

• --kind : node <skill>/scripts/draw.mjs --list kinds (utilitaire, santé, finance, jeu, enfants, social, média, productivité, style de vie, création, commerce, autre).
• --screens : rôles de --list roles (onboarding, accueil, détail, création, résultats, paramètres, paywall, vide).
• --tone : calme, audacieux, chaleureux, technique, ludique, luxe, éditorial. Uniquement si le brief le demande.
• --have : ressources existantes : photography, product-photo, illustration, video, 3d. Omettez-le si aucune ; le tirage évite alors les compositions qui en dépendent.
• --keep palette,type : quand la marque ou le système de design les fixe déjà. Le tirage ne distribue que la composition, la forme et le mouvement ; vous mappez les valeurs du système sur les rôles.
• --seed <n> rend un tirage reproductible ; la fiche imprime la graine utilisée.

Adoptez la fiche. Ne la mélangez pas avec la mise en page que vous auriez faite de toute façon. Re-tirez un emplacement (--redraw type|palette|shape|motion|screen:<rôle>|direction) uniquement pour une raison que vous pouvez énoncer : il contredit une contrainte de marque, a besoin d'une ressource qui n'existe pas, ou ne peut pas contenir le contenu réel. Ne re-tirez jamais pour obtenir quelque chose de plus confortable. Enregistrez chaque re-tirage dans le rapport. Réimprimez avec --show.

Vérifiez la palette par rapport au sujet. Une palette distribuée est un ensemble de proportions (un fond, une encre, un accent, des champs optionnels) autant que des couleurs. Si elle entre en conflit avec le matériau propre du sujet, re-tirez une fois, ou conservez les proportions et prenez les couleurs du sujet, et dites-le.

4. Trouver l'idée

La direction est une façon de composer. L'idée est ce qui rend l'application propre à ce sujet. Remplissez les deux blancs à partir du sujet lui-même avant de construire :

Dans cette application, [quelque chose qui appartient au sujet] devient [le dispositif que la direction appelle].

Cherchez dans : son résultat (ce qu'il produit, présenté comme matériau), son objet (sa forme, en silhouette), son nom (des lettres qui contiennent une image), son lieu, son rituel (une séquence que l'application exécute), son artefact (un ticket, une étiquette, un reçu), son contraire.

Le test du concurrent : mettez le concurrent réel le plus proche dans la phrase. Si elle fonctionne encore, l'idée appartient à la catégorie. « Propre et moderne » n'est pas une idée.

Le moment « wow » (la chose vivante). Offrez à l'application une interaction qui est différente à chaque utilisation, fabriquée à partir de l'idée : soufflez dans le micro et la bougie vacille ; réglez la dose et lisez la courbe de demi-vie réelle ; pliez le téléphone et la cassette joue. Elle utilise du contenu réel, fonctionne d'une seule main avec le pouce, a des haptiques via sensoryFeedback, un chemin Reduce Motion, et ne bloque jamais la tâche. C'est une chose, pas un terrain de jeu. Elle est construite à l'étape 6, pas ajoutée comme mouvement à la fin.

5. Écrire les mots

Écrivez l'ensemble du texte (en texte brut) avant les vues, en suivant references/copy.md, et mettez chaque chaîne dans le catalogue de chaînes (Localizable.xcstrings) dès le premier commit. Chaque titre tient sur deux lignes à la taille par défaut ; une action principale par écran, nommée pour ce qu'elle fait (jamais « Commencer », « Continuer » sans rien après, « En savoir plus ») ; le texte vide, d'erreur et d'autorisation écrit maintenant, pas plus tard. La preuve n'est jamais inventée : pas de faux avis, de comptes d'utilisateurs, de récompenses ou de presse.

6. Construire, quand même

Construisez avec le mouvement désactivé dans votre tête. Ordre de travail :

1. Jetons. Palette/Theme depuis la fiche comme couleurs du catalogue de ressources avec variantes claires et sombres (ou une énumération ShapeStyle de jetons), une énumération Typography, une énumération Metrics (espacement, rayon, une règle de forme). Tout ce qui est en aval ne fait que référencer les jetons. Pas de Color(red:), pas de .font(.system(size: 17)) dans les vues.
2. Le premier écran, exactement comme son plan le décrit, à la largeur SE, standard, Pro Max et iPad. Obtenez la grande chose grande et les petites choses petites avant que quoi que ce soit d'autre n'existe.
3. Chaque écran selon son plan avec le contenu de ce projet. Les écrans voisins ne doivent pas partager une mise en page. Portez l'idée dans chaque écran, y compris les paramètres, le paywall et les états vides ; l'échec le plus courant est un Accueil distinctif suivi de Form standards.
4. Imagerie, par préférence : les ressources du projet ; généré (si vous avez un outil d'image) ; de vraies photos du monde du sujet provenant de collections libres avec licences enregistrées (references/imagery.md) ; dessiné en code (Shape, Canvas, Path) comme un langage graphique plat cohérent dans la palette ; la typographie et la couleur seules. Les symboles SF uniquement comme glyphes fonctionnels.
5. Le moment « wow » de l'étape 4, dans l'écran où il prouve l'affirmation.
6. Plénitude. Regardez chaque écran comme une affiche : une chose dominante et le contenu qu'elle porte. Un écran principalement vide est sous-construit. Texte courant dans l'encre pleine en body ou plus grand.
7. Le cadre. Un système de marges. Chaque écran a un titre (titre de navigation ou grand titre d'affichage) et chaque section de liste un en-tête qui la nomme.
8. États et sémantique. Tous : chargement, vide, erreur, hors ligne, autorisation refusée, succès, désactivé, premier lancement, contenu long, tailles d'accessibilité, RTL. De vrais Buttons, focus visible, étiquettes, accessibilityHint uniquement là où l'étiquette ne peut pas le porter, ordre VoiceOver, Reduce Motion et Increase Contrast respectés.
9. Base de plateforme (depuis les règles globales) : catalogue de chaînes avec en-US, en-GB, en-AU, en-CA et es-MX ; requestReview après un moment positif uniquement, limité par compteur et jours depuis l'installation, une fois par version ; haptiques ; mode sombre et clair ; App Intents là où l'application a une action principale.

Consultez references/type.md, colour.md, layout.md et components.md quand vous avez besoin du détail derrière une décision ; les règles ci-dessous sont la forme courte.

7. Contrôle qualité

node <skill>/scripts/lint.mjs <fichiers ou dossier Swift>
<skill>/scripts/capture.sh <identifiant du bundle> .taste-skill/capture   # simulateurs lancés

lint.mjs analyse le code source Swift à la recherche de motifs interdits, d'expressions toutes faites et de bases manquantes (catalogue de chaînes, Reduce Motion, haptiques). capture.sh lance l'application installée sur chaque simulateur lancé en mode clair et sombre et aux tailles de police par défaut et d'accessibilité, et enregistre les captures d'écran. Corrigez chaque FAIL ; traitez chaque WARN comme une erreur sauf si vous pouvez le défendre devant un designer en une phrase. Réexécutez jusqu'à ce qu'il n'y ait plus de FAIL. Une ligne peut être exclue avec un commentaire // taste-skill:off et réactivée avec // taste-skill:on.

8. Boucle de critique

Ouvrez les captures dans le dossier et jugez chacun contre la grille de la fiche : est-ce que le premier écran le démontre ? Est-ce que chaque écran porte l'idée ? Le type est-il plus grand qu'avant ? L'image est-elle réelle, dessinée ou absente ? Y a-t-il un moment non standard qui vient de l'idée ? Les ombres, recadrages et bords sont-ils intentionnels ? Si un correctif peut être fait en une minute, appliquez-le et re-capturez. Si un écran a besoin d'être reconstruit, notez FIX ME et l'étape du run à laquelle revenir. Ne passez pas un écran qui ressemble à une moyenne.

Règles globales

Celles-ci s'appliquent à chaque écran de chaque application native construite avec ce skill. Tout écart doit être enregistré et défendu.

Typographie

• Dynamic Type à toutes les échelles. headline à title3, body à body, caption à caption, jamais .fixed.
• Tailles de police : un système, pas de combinaisons. Une enum Typography avec .largeTitle, .display, .heading, .body, .caption, .label ; chacun avec une famille, un poids, un suivi et un leading. Trois tailles maximum qui ne sont pas celles du système : grande (le premier écran des écrans de contenu), lecture (le corps), petite (étiquettes et légendes) ; la navigation et les listes utilisent les tailles système.
• Toujours plus grand, jamais plus petit pour le contenu primaire que la taille système par défaut.
• Largeur de police : défaut (standard), pas de condensation. .fontWidth(.compressed) uniquement pour les nombres monétaires ou les horodatages.
• Pas d'italique sauf pour les citations ou les légendes ; pas de soulignement ; pas de barré ; pas de couleurs différentes dans un même bloc de texte, sauf pour le texte fonctionnel cliquable.
• Pas d'ombré. Pas d'ombre portée sur le texte, pas de relief, pas de lueur, pas de texte avec un fond dégradé.

Couleur

• Couleurs de la palette uniquement. Une couleur d'encre (le texte et les icônes, fond clair ou fond foncé), un fond (le fond de l'écran, blanc ou avec une teinte de la palette), un accent (un bouton, un lien), des champs optionnels (une couleur de surface secondaire, une couleur de bordure, un succès, une erreur). Pas de couleurs de tableau de bord en dehors de celles-ci.
• Un accent, pas un dégradé. LinearGradient, RadialGradient, ellipticalGradient et meshGradient sont autorisés sur un seul objet héroïque, un seul par écran. Pas de dégradés sur les boutons, les arrière-plans, les légendes, les icônes ou le texte, sauf si c'est la lettre d'un mot qui porte l'image.
• Le fond est un écran de couleur. Pas d'image de fond, pas de motif, pas de répétitions. Le fond de l'écran est soit le fond de la palette, soit un champ unicolore allant jusqu'au bord de l'écran (pas de carte). Une bande de champ secondaire est autorisée en bas ou en haut, pas au milieu.
• SF Symbols en couleur d'accent ou d'encre uniquement, jamais en couleur de tableau de bord. Jamais deux symboles dans la même couleur sur le même écran. Aucun symbole ne remplace une image. Aucun symbole dans les onglets de navigation avec un fond teinté.

Mise en page

• Marges système, pas de colonne étroite. iPad et paysage : deux colonnes, une vue partagée ou une barre latérale, jamais une colonne centrée de la largeur d'un téléphone.
• Pas de cartes. Un fond d'écran. Pas d'élément enveloppé dans une couleur de surface secondaire, sauf si cette couleur touche un bord de l'écran. Les exceptions : les pickers et les menus en ligne dans un formulaire ; et une seule tuile d'action par écran (le moment de l'application qui est différent).
• Pas d'icônes dans les listes. Les listes de paramètres n'ont pas d'icône avant le texte de la ligne. Les listes de contenu (fichiers, messages, contacts) peuvent avoir un mini-thumbnail avant le texte, mais de la même taille que la ligne, pas plus grande.
• Deux lignes maximum par élément de liste. La ligne de titre et une ligne de sous-titre ; pas d'extrait, pas de métadonnées, pas d'icône sur la droite. Les métadonnées et l'action secondaire sont sur l'écran de détail.
• Une action principale par écran. Un objet, une action. Les actions secondaires sont dans un menu ou sur un écran de détail. L'action principale est soit un bouton ancré en bas, soit l'objet principal de l'écran, soit le geste principal sur l'objet principal.

Composants

• Navigation : NavigationStack avec .navigationTitle. Pas de NavigationView. TabView avec les onglets nommés, jamais de CustomTabView avec des icônes de marque. Pas de page d'accueil avec des barres d'onglets. Pas de ToolbarItem(placement: .navigation) sauf pour l'annulation et la fermeture. Pas de barre d'onglets sans badge d'icône.
• Formulaires : Form avec des sections et des en-têtes. Pas de List pour les formulaires. Pas d'écran de paramètres sans Form.
• Listes : List avec ForEach et des identifiants stables. Pas de List pour une seule section. Pas de List sans Section et en-tête.
• Alertes et feuilles : .alert pour les confirmations destructrices uniquement. .sheet pour les formulaires et les détails. Pas de UIAlertController, pas de UIViewController pour les alertes.
• Boutons : Button avec ButtonStyle. Pas de Text cliquable sans ButtonStyle, pas de NavigationLink avec un titre de navigation, pas de geste onTapGesture sur le contenu.
• Images : Image avec resizable, aspectRatio, scaledToFit/scaledToFill. Pas d'images sans dimensions, pas de Image(uiImage:) en ligne, pas d'images de remplissage (SF Symbols uniquement pour les icônes).
• Animations : .animation sur le contenu modifié, pas la vue entière. .matchedGeometryEffect pour les transitions d'états de liste. Pas d'animations inutiles, pas d'animations qui bloquent l'interface utilisateur.
• Accessibilité : accessibilityLabel, accessibilityValue, accessibilityTraits sur les éléments interactifs. accessibilityAction pour les actions personnalisées. VoiceOver ordre de lecture. Pas de accessibilityElement(children: .ignore) sans accessibilityLabel.

Références

• references/screens.md : plans d'écran pour les écrans de travail (formulaires, listes, détails, paramètres)
• references/copy.md : règles pour le texte de l'application
• references/type.md : détails de la typographie
• references/colour.md : détails de la couleur
• references/layout.md : détails de la mise en page
• references/components.md : détails des composants
• scripts/draw.mjs : script d'aide aux directions
• scripts/lint.mjs : linter pour le code source Swift
• scripts/capture.sh : script de capture sur simulateurs