B-Riemer/claude-skills

Apple Design Pro (web)

Deux modes pour les sites web : Review (trouver ce qui ne va pas, le classer, dire comment le corriger) et Build (bien gérer l'animation et l'interaction en écrivant du code). Le niveau d'exigence est celui d'Apple : réactivité immédiate, retour continu, retenue, et des détails cohérents plutôt que décoratifs.

Périmètre : sites web et applications web. Les Human Interface Guidelines d'Apple sont conçues pour les applications natives : utilisez-les pour raisonner et traduisez-les pour le web ; ne copiez pas les motifs iOS à la lettre.

Choisir le mode

• L'utilisateur partage une URL, un dépôt, un fichier, une capture d'écran ou dit « review / audit / check / what's wrong / make it look better » : Mode Review.
• L'utilisateur construit ou modifie quelque chose (« ajoute un bottom sheet », « rends ceci natif », « anime ce menu ») : Mode Build.
• En cas de doute : posez une seule question courte. Si l'utilisateur veut les deux, faites d'abord la review, puis appliquez les corrections.

Fichiers de référence (chargez uniquement ce dont vous avez besoin)

Fichier	Quand le charger
references/web-lens.md	Review : toujours. Build : quand on touche à la mise en page, formulaires, polices, images, mode sombre ou accessibilité.
references/motion-principles.md	Review : dès que la page bouge ou superpose des couches (toute transition ou animation CSS, effets liés au scroll, animation canvas ou WebGL, superpositions, gestes, matériaux translucides backdrop-filter). Build : toujours, c'est le guide principal.
references/visual-craft.md	Review : toujours pour une demande « make it look better / less generic ». Build : quand on conçoit la mise en page, la typographie ou la couleur.
references/hig-links.md	Quand vous avez besoin des termes exacts d'Apple pour justifier ou citer. Ouvrez la page liée pour le sujet spécifique uniquement ; ne citez jamais de mémoire.

Ne chargez pas tous les fichiers par défaut. Seule une page vraiment statique (sans transitions, animations, canvas ni couches translucides) peut ignorer le fichier motion complet ; lisez alors au maximum motion-principles.md §14 (mouvement réduit) et §15 (typographie). Ne citez que les sections que vous avez réellement lues dans cette session.

Script de mesure

scripts/measure.mjs mesure un site en ligne avec Playwright : débordement horizontal avec responsables, cibles tactiles, CLS/LCP, erreurs console, inventaire des polices, contraste DOM, contraste pixel pour texte sur canvas/images/gradients, un test mouvement réduit et un test sans JavaScript, ainsi qu'un test de focus clavier. Lancez node scripts/measure.mjs --help pour l'utilisation. Utilisez-le plutôt que d'écrire un script de mesure de zéro ; étendez-le avec des sondes ciblées uniquement pour ce qu'il ne couvre pas. Si Playwright n'est pas installé, le script explique comment l'installer ; demandez avant d'installer quoi que ce soit dans le projet de l'utilisateur.

Mode Review

Étape 1 : Établir le contexte

Découvrez, en ne demandant que ce qui manque :

1. Ce qui est examiné : URL en ligne, code local, captures d'écran ou fichier de design. Notez ce que vous pouvez et ne pouvez pas voir.
2. Audience et objectif : qui visite, ce que la page doit faire faire, et sur quels appareils.
3. Stack : framework, approche CSS (Tailwind, CSS modules, CSS pur), bibliothèque d'animation. Les corrections doivent être écrites dans cette stack.
4. Périmètre : site entier, une page ou un composant.
5. Décisions délibérées : lisez les règles et décisions du projet avant de juger quoi que ce soit (CLAUDE.md, AGENTS.md, docs de design, page du design system, notes d'approbation, commentaires à côté du code). Un choix fait intentionnellement par le propriétaire (un effet hover, une animation approuvée, une couleur de marque) n'est pas un constat en soi. Ne signalez que ses effets concrets (par exemple « le hover lift reste après un tap sur les appareils tactiles »), et marquez ces constats comme touchant une décision approuvée pour que le propriétaire décide. Si vous ne pouvez pas dire si quelque chose est délibéré, dites-le dans le constat au lieu de l'appeler un signal de template.

Étape 2 : Mesurer, ne pas deviner

• Avec une URL en ligne et des outils navigateur disponibles (automatisation navigateur, DevTools, Lighthouse, session Playwright ou Chrome), chargez effectivement la page aux largeurs mobile (environ 390 px) et desktop et mesurez : rapports de contraste, tailles des cibles tactiles, débordement horizontal, décalages de mise en page, chargement des polices, tailles d'images, erreurs console, visibilité du focus au clavier. Préférez les chiffres réels. Commencez par scripts/measure.mjs.
• Texte sur canvas, images, vidéo ou dégradés : les outils de contraste DOM ne voient pas ce qui est dessiné derrière le texte, leur résultat n'est donc ni un succès ni un échec. Mesurez les pixels à la place : capturez d'écran de la boîte de texte, capturez-la à nouveau avec le texte rendu transparent, et calculez le contraste de la couleur du texte par rapport aux pixels d'arrière-plan les plus sombres (measure.mjs le fait ; méthode dans web-lens.md §4). Pour les arrière-plans animés, prenez plusieurs échantillons et signalez le pire. Laissez le contraste comme une évaluation seulement si la mesure pixel est impossible, et dites pourquoi.
• Avec uniquement du code, lisez les fichiers pertinents et dites quels constats proviennent de la lecture du code et n'ont pas pu être confirmés à l'exécution.
• Avec uniquement des captures d'écran, vous pouvez juger approximativement du savoir-faire visuel, de la hiérarchie et du contraste ; vous ne pouvez pas juger de l'animation, du focus, des performances ou de la réactivité. Dites-le, et ne rapportez pas ces lentilles comme propres.
• Si vous ne pouvez pas exécuter un outil dont vous auriez besoin (pas d'accès navigateur, pas de réseau), dites-le et marquez les constats dépendants comme non vérifiés au lieu de substituer une supposition.

Étape 3 : Appliquer les lentilles dans cet ordre

Parcourez-les dans l'ordre. Sautez une lentille seulement quand elle ne s'applique vraiment pas, et dites que vous l'avez sautée.

1. Accessibilité. Contraste, visibilité du focus, chemin clavier, taille des cibles, mouvement réduit, zoom texte, étiquettes, texte alternatif, éléments sémantiques. Les échecs ici sont les plus graves et les plus objectifs. Détails : web-lens.md sections 1 à 4, 9 et 10, et motion-principles.md §14.
2. Lentille web. Réactivité, pas de scroll horizontal, tactile vs. survol, Core Web Vitals, décalages de mise en page, images, polices, mode sombre, formulaires. Détails : tout web-lens.md.
3. Savoir-faire visuel et aspect template. Hiérarchie typographique, rythme d'espacement, discipline des couleurs, retenue, élément signature, signaux de template générique, checklist de suppression. Détails : visual-craft.md.
4. Mouvement et interaction. Latence de réponse, suivi 1:1, interruptibilité, ressorts vs. easings fixes, symétrie entrée/sortie, rubber-banding, matériaux, feedback, états de pression. Vérifiez chacun par rapport aux 17 principes dans motion-principles.md ; citez comme « motion-principles.md §N ». N'évaluez que ce qui existe ; une page sans gestes n'obtient pas de constats sur les gestes. Mais si quelque chose sur la page bouge ou est translucide, cette lentille est obligatoire : chargez motion-principles.md avant d'écrire les constats, et vérifiez au moins la réponse, l'interruptibilité, le choix d'easing, le mouvement réduit et, pour backdrop-filter, les matériaux et prefers-reduced-transparency (§12, §14).
5. Contenu et microcopie. Étiquettes de boutons qui nomment l'action, titres spécifiques, messages d'erreur qui disent comment corriger, états vides et de chargement, remplissage marketing vague, terminologie incohérente, texte d'espace réservé laissé.

Sévérité

Niveau	Signification	Exemples
Critique	Bloque les utilisateurs ou échoue à une exigence légale/d'accessibilité ; à corriger avant publication	Contenu illisible ou inaccessible au clavier, zoom désactivé, formulaire impossible à soumettre sur mobile, texte en dessous de 3:1 de contraste, page inutilisable à 320 px
Élevé	Nuit clairement à l'expérience, à la confiance ou à la conversion pour de nombreux utilisateurs	Styles de focus manquants, texte de corps en dessous de 4.5:1, décalage de mise en page pendant la lecture, image hero beaucoup trop lourde, éléments cliquables sous 24 px, absence de gestion du mouvement réduit pour un grand mouvement
Moyen	Écart de finition notable ou incohérence	Tailles de police et espacements ad hoc, easing à durée fixe sur un élément déplaçable, affordance uniquement au survol, cluster de template générique
Faible	Petite amélioration ou amélioration de goût	Ajustements de tracking, léger décalage, petite microcopie, retouches optionnelles du mode sombre

Classez par impact utilisateur, pas par facilité de correction. Ne gonflez pas la sévérité pour remplir une section ; un niveau de sévérité vide est acceptable.

Règles pour les constats

• Examinez seulement ce qui est réellement présent. Pas de constat sans quelque chose observé sur la page ou dans le code. Pas de listes de conseils génériques.
• Preuve ou étiquette. Chaque constat est soit Vérifié (mesuré ou vu directement, avec la valeur) soit Évaluation (jugement ou inférence, avec comment le vérifier).
• Citez toujours le nom du fichier : « web-lens.md §4 », « motion-principles.md §11 », « CLAUDE.md du projet §7 ». Jamais un « §N » nu, car la compétence et le projet numérotent tous deux leurs sections.
• Citez les chiffres : « texte de corps #8a8a8a sur #ffffff donne 3.4:1, besoin de 4.5:1 », « CTA fait 32x32 px ».
• Créditez ce qui fonctionne. Mentionnez jusqu'à trois choses réellement bonnes, pour que l'utilisateur sache quoi garder.
• Une cause racine, un constat. Regroupez les répétitions (« 12 boutons manquent de styles de focus ») avec un compte et des exemples.
• Ne corrigez pas sans qu'on vous le demande. En mode review, rapportez ; ne modifiez le code que si l'utilisateur le demande. Mentionnez brièvement les observations annexes hors périmètre à la fin.
• Ne faites pas du copier-coller d'Apple. Si une convention web est meilleure qu'un motif Apple pour ce contexte, dites-le.

Format du rapport

Commencez par un résumé de 3 à 5 lignes : impression générale, la ou deux choses les plus importantes, ce qui a été vérifié et ce qui ne l'a pas été. Ensuite, les constats groupés par sévérité (Critique en premier). Pour chaque constat :

### [Sévérité] Titre court
**Problème :** ce qui ne va pas, où (sélecteur, composant, URL ou région de capture d'écran), avec valeurs mesurées. Vérifié / Évaluation.
**Pourquoi c'est important :** la raison, avec une source : references/web-lens.md §N, motion-principles.md §N, visual-craft.md §N, ou un lien HIG depuis hig-links.md.
**Correction :** changement concret dans la stack de l'utilisateur (extrait de code ou valeurs CSS/JS exactes).

Terminez par :

1. Victoires rapides : les constats qui prennent quelques minutes et améliorent visiblement la page.
2. Non vérifié : chaque lentille ou élément sauté ou partiellement exécuté, et pourquoi (pas d'accès navigateur, capture d'écran seulement, fichier de référence non chargé, etc.). Une lentille absente des constats ET absente de cette liste compte comme une erreur de rapport.
3. Observations annexes : choses remarquées hors périmètre, non traitées.

Mode Build

Utilisez references/motion-principles.md comme guide de travail. Valeurs par défaut à appliquer sans qu'on vous les demande :

• Répondre sur l'appui, suivre 1:1, rester interruptible. Feedback sur pointerdown, le contenu suit le pointeur depuis l'endroit où il a été saisi, rien ne bloque l'entrée pendant une transition (§1 à §3).
• Ressorts pour tout ce que l'utilisateur touche, easing fixe uniquement pour les transitions passives. Amorti critique par défaut ; n'ajoutez du rebond que lorsque le geste transporte de l'élan (§4).
• Transmettre la vitesse de relâchement à l'animation et projeter l'élan pour les flicks, sheets et carrousels (§5, §6).
• Entrée et sortie le long du même chemin, depuis l'origine du déclencheur (§7). Frontières douces au lieu d'arrêts brusques (§9).
• Animer uniquement transform et opacity pour le mouvement, et garder le travail de premier rendu hors du chemin critique (§11 et web-lens.md sections 5 et 6).
• Toujours fournir les fallbacks : prefers-reduced-motion, prefers-reduced-transparency, prefers-contrast (§14), :focus-visible visible, fonctionnement clavier, cibles tactiles de 44 px (web-lens.md).
• Préférer les bibliothèques existantes déjà utilisées par le projet (Motion/Framer Motion, GSAP, Vaul, Embla, View Transitions CSS natives) plutôt que de réinventer la physique, sauf si le projet n'en a aucune et que l'interaction le nécessite.

Workflow de construction :

1. Lisez comment le projet anime aujourd'hui (bibliothèque, conventions CSS, tokens) et adaptez-vous.
2. Nommez l'interaction en une phrase : ce que l'utilisateur touche, ce qui bouge, ce qui peut l'interrompre.
3. Implémentez-la en utilisant la section de principe correspondante ; gardez les paramètres de ressort dans une configuration partagée plutôt que de disperser des littéraux.
4. Testez : interrompez-la en plein vol, inversez-la, faites-la glisser au-delà du bord, utilisez uniquement le clavier, activez le mouvement réduit, réduisez la vitesse du CPU dans DevTools.
5. Rapportez ce que vous avez changé et ce que vous n'avez pas pu tester.

Principes qui s'appliquent aux deux modes

• Dites ce qui est vérifié et ce qui est un jugement ; nommez le moyen de vérifier tout ce qui n'est pas vérifié.
• Signalez les bloqueurs (pas d'accès à l'URL, outil manquant, fichier illisible) plutôt que de les contourner en silence.
• Restez dans la demande : signalez les constats annexes plutôt que de les corriger sans qu'on vous le demande.
• Préférez des constats peu nombreux, bien étayés, à une longue liste de constats génériques.