Communitygithub.com

Ajit-ApTech/premium-glass-android

Concevez et construisez des interfaces Android premium inspirées d'Apple, avec effet « verre liquide », en Jetpack Compose : navigation flottante translucide, feuilles et contrôles sur un contenu opaque et calme, avec jetons clair/sombre, vérifications de lisibilité, solutions de repli accessibles, limites de performance du flou, et prompts de génération d'images IA pour écrans de référence. Utilisez-le lorsqu'on vous demande un rendu premium, de type Apple, iOS 26, verre liquide, glassmorphism ou givré sur Android ou Compose, pour rédiger des prompts de maquette d'écran pour une telle application, ou pour examiner du code UI ou des designs en vue d'un usage abusif du verre. Ne convient pas pour un travail web uniquement ou SwiftUI uniquement, et jamais pour copier les polices, icônes ou logos Apple.

Qu'est-ce que premium-glass-android ?

Ce skill est conçu pour les développeurs Android qui utilisent Jetpack Compose et souhaitent créer des interfaces utilisateur premium, inspirées du style « verre liquide » d'Apple. Il fournit un cadre strict pour appliquer des effets de flou et de transparence uniquement sur la couche flottante (barre de navigation, barre d'outils, bouton d'action flottant, feuilles, menus) tout en gardant le contenu (cartes, listes, formulaires) opaque. Le skill inclut des règles de conception rigoureuses (cinq règles d'or) qui garantissent la lisibilité, l'accessibilité et la performance, avec des vérifications automatiques de contraste et d'audit du code Compose. Il repose sur des jetons de thème (assets/tokens.json), des composants standardisés (références/components.md) et des workflows précis (inspection, calques, jetons, construction, vérification). Il prend également en charge un mode « prompt d'image » pour générer des descriptions textuelles d'écrans de référence (mock-ups) destinées à des outils de génération d'images IA, ainsi qu'un mode de révision pour analyser des designs ou du code existants. Le skill est conçu pour être utilisé dans des environnements de développement (Claude Code, Cursor, etc.) et insiste sur l'absence de dépendances réseau, la manipulation de fichiers locaux uniquement, et le respect des marques Apple (interdiction de copier polices, icônes ou logos).

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Ajit-ApTech/Premium-liquid-glass/tree/main/premium-glass-android

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Premium Glass pour Android

Objectif : une interface qui semble calme, spatiale et chère. Le verre est un matériau pour les contrôles qui flottent au-dessus du contenu. Ce n'est pas un style à saupoudrer partout. Test de réussite : les gens disent « c'est propre et en couches », jamais « quelqu'un a ajouté du flou partout ».

Ce skill contrôle le matériau, la hiérarchie, la profondeur, le mouvement et l'accessibilité. La marque du projet contrôle l'identité et le texte. Les valeurs de marque par défaut se trouvent dans assets/tokens.json (palette Retain) et peuvent être remplacées.

0. Sécurité et périmètre

  • Travaillez uniquement à l'intérieur du projet sélectionné par l'utilisateur. Ne lisez pas de secrets, clés ou variables d'environnement. N'effectuez pas de requêtes réseau et n'installez pas de paquets ; si une bibliothèque est nécessaire, nommez-la et laissez l'utilisateur décider.
  • N'écrasez pas les fichiers existants sans y être invité ; proposez d'abord (section 2).
  • Utilisez uniquement du contenu d'exemple fictif.
  • N'utilisez jamais les polices Apple (San Francisco), les SF Symbols, les logos Apple ou le chrome iOS. Utilisez Inter et les icônes Material Symbols/Lucide.
  • Les faits marqués (VÉRIFIER) peuvent vieillir (API, versions). Demandez à l'utilisateur de les confirmer.

1. Les cinq règles absolues

  1. Le contenu n'est jamais en verre. Les cartes, lignes de liste, formulaires, arrière-plans de page et médias restent opaques ou en surface douce.
  2. Le verre uniquement sur la couche flottante : pilule de navigation inférieure, barre supérieure au-dessus du contenu défilant, bouton d'action flottant, feuilles inférieures et menus, champ de recherche, toasts/snackbars, petits chips flottants.
  3. Jamais de verre sur du verre. À l'intérieur d'une surface en verre, séparez les éléments avec des remplissages, des séparateurs ou de l'opacité.
  4. La lisibilité prime sur l'esthétique. Le texte du corps nécessite 4,5:1 (texte volumineux et icônes 3:1) par rapport à l'arrière-plan le plus défavorable. Exécutez scripts/contrast_check.py.
  5. Chaque surface en verre a un repli solide (ancien Android, réduire la transparence, contraste élevé, économie d'énergie, flou désactivé par l'appareil).

Question préalable avant d'appliquer le verre à un élément : « Quel rôle fonctionnel ce matériau communique-t-il ? » Réponses valables : il flotte au-dessus du contenu défilant ; il est temporaire ou contextuel ; il doit rester accessible pendant que le contenu se déplace en dessous. Pas de réponse = pas de verre.

2. Flux de travail

  1. Inspectez : plateforme, SDK min/cible, thème/jetons existants, structure de navigation, besoins d'accessibilité, objectifs de performance. Listez les questions ouvertes au lieu de deviner.
  2. Carte des couches (avant tout code) : tableau des éléments -> couche (contenu / structure / flottant) -> verre oui/non -> niveau -> raison. Présentez-la avec le plan.
  3. Jetons : partez de assets/tokens.json ; ajustez les couleurs de la marque ; relancez la vérification de contraste pour chaque niveau dans les deux modes.
  4. Construisez avec les modèles dans assets/GlassTheme.kt et les conseils de references/compose-implementation.md.
  5. Vérifiez avec references/review-checklist.md et scripts/audit_compose.py. Fournissez des preuves (valeurs de contraste, nombre de couches de verre par écran, captures d'écran de repli). N'affirmez pas qu'une vérification a réussi sans preuve.

3. Niveaux de matériau (valeurs de départ, dp)

NiveauUtilisationFlouRemplissage (sombre)Remplissage (clair)
aucuncontenu, cartes, listes, arrière-plans---
fincontrôles à icône seule ou à grande étiquette16encre @ 0,55blanc @ 0,55
régulierpilule de navigation, barre supérieure, recherche, FAB, toasts24encre @ 0,66blanc @ 0,70
épaisfeuilles, menus, dialogues, superpositions textuelles32encre @ 0,78blanc @ 0,82
voileatténuation derrière les feuilles modales0-8noir @ 0,20-0,45noir @ 0,20-0,45
Détails et nombres de contraste vérifiés : references/tokens.md. Les remplissages sont teintés avec la couleur d'encre de surface, pas du blanc pur, de sorte que le texte en mode sombre survive aux arrière-plans lumineux.

4. Réalité Android (à lire avant de promettre quoi que ce soit)

  • Modifier.blur() / RenderEffect floute le propre contenu de l'élément, pas ce qui se trouve derrière. Un vrai flou d'arrière-plan nécessite une bibliothèque (Haze est sous licence Apache-2.0 et supporte Compose sur Android) ou un flou de fenêtre pour les dialogues. Les noms d'API de bibliothèque changent entre les versions : lisez le README de la version installée (VÉRIFIER).
  • Les effets de flou nécessitent Android 12 (API 31) ou supérieur (VÉRIFIER). En dessous, utilisez la surface de repli solide.
  • Les feuilles inférieures modales et les dialogues vivent dans une fenêtre séparée, donc le flou d'arrière-plan dans la composition peut ne pas voir le contenu derrière eux. Utilisez le flou d'arrière-plan de fenêtre là où il est supporté et vérifiez WindowManager.isCrossWindowBlurEnabled (VÉRIFIER), sinon une feuille épaisse presque opaque avec un voile.
  • Le flou sur un dégradé plat est invisible ; le verre a besoin de structure derrière lui (contenu, imagerie, ou une lueur douce délibérée). Sinon, il coûte des performances pour rien.
  • Budget : au maximum 2-3 couches floutées simultanées par écran (1-2 sur les téléphones bas de gamme). Ne floutez jamais les éléments de liste ou des écrans entiers. N'animez pas le rayon de flou sur de grandes surfaces ; animez l'alpha ou la transformation.
  • Testez sur un téléphone bas de gamme (3-4 Go de RAM) dans une construction de type release.

5. Modes d'accessibilité (implémentez tous)

  • Réduire la transparence (paramètre dans l'application + signaux système « supprimer les animations »/contraste élevé) : remplacez le verre par des jetons de surface solide avec une bordure visible de 1 dp.
  • Grande police (200 %) et TalkBack : aucune information uniquement en couleur ; étiquettes sur les contrôles à icône seule ; ordre de focus cohérent.
  • Mouvement réduit : remplacez les mouvements par des fondus ; conservez le retour d'état.
  • Cibles tactiles d'au moins 48 dp. Les gestes (balayage) ont toujours un bouton ou une alternative customActions.

6. Composants

Spécifications pour la pilule de navigation, la barre supérieure, le FAB, les feuilles, le champ de recherche, les chips, les cartes, les lignes à balayer, la pile de triage, la saisie de chat, les chips à valeur masquée : references/components.md. Utilisez un rayon par rôle (chip 999, contrôle 16, carte 24, pilule de navigation 28, feuille 32) ; rayon imbriqué = rayon externe - padding.

7. Mouvement

Ressorts 250-350 ms, fondus courts 150 ms, pas de rebond excessif. Clic haptique au seuil de balayage. État pressé : échelle 0,97 plus une surbrillance douce. Respectez le mouvement réduit.

8. Mode prompt d'image (écrans de référence)

Lorsqu'on vous demande des prompts de maquette, suivez references/image-prompts.md : un écran par prompt, bloc de style autonome, texte exact à l'écran, verre uniquement sur la couche flottante, « les cartes sont opaques », barre d'état Android, pas d'éléments Apple. Six prompts d'écran travaillés se trouvent dans la référence. Rappelez à l'utilisateur que les générateurs brouillent les petits textes et le devanagari ; utilisez les sorties comme références de mise en page et d'ambiance, puis reconstruisez dans Figma/Compose.

9. Mode révision

Lorsqu'on vous demande de réviser un design ou du code : classez chaque élément par couche, comptez les couches de verre par écran, exécutez le script d'audit (python scripts/audit_compose.py <src>), exécutez le script de contraste, puis listez les constatations par sévérité avec le correctif de references/review-checklist.md.

10. Attentes de sortie

Pour toute tâche, indiquez : ce qui est en verre et pourquoi ; quel niveau ; preuve de contraste ; replis ; tout ce qui est approximatif ou non vérifié. Gardez les changements ciblés : ne reconcevez pas l'UX non connexe ; listez les problèmes non connexes séparément.

Références et fichiers

  • references/principles.md - Principes et sources dérivés d'Apple
  • references/tokens.md - Tableaux de jetons et résultats de contraste vérifiés
  • references/compose-implementation.md - Architecture Compose, extraits, replis, performances
  • references/components.md - Spécifications des composants et états
  • references/image-prompts.md - Modèle de prompt et flux de travail
  • references/review-checklist.md - Portes de qualité et anti-patrons
  • scripts/contrast_check.py, scripts/audit_compose.py - Vérificateurs locaux (pas de réseau)
  • assets/tokens.json, assets/GlassTheme.kt (optionnel : ajoutez le jeu de prompts Retain 45 écrans en tant que assets/retain-screen-prompts.md)

Skills associés