charliesbot/android-design-explore

Exploration de conception visuelle

Suivez la compétence android-design pour chaque décision de conception : sa section 0 répond, composants, thème, mise en page et les questions de la vérification d'écran. Cette compétence gère le flux de travail. Chaque exécution est un tir unique : une idée en entrée, une proposition écrite, vérifiée, montrée, puis arrêt. Les écrans d'application pour téléphone, pliable, tablette, bureau et Wear OS sont dans le périmètre ; les tuiles Wear, les cadrans de montre et les widgets ne le sont pas. Là où Wear diffère, la section Wear OS ci-dessous l'indique.

Une proposition est un fichier de données que l'application de prévisualisation, une fenêtre macOS native, dessine avec de vrais composants Compose Material 3 et redessine à chaque sauvegarde. Vous la vérifiez via l'arbre de mise en page de l'application ; l'utilisateur juge le goût dans la fenêtre.

Prérequis

macOS, avec l'application de prévisualisation installée et enregistrée en tant que serveur MCP nommé android_design_preview. Appelez d'abord son outil status. Lorsque ses outils ne sont pas disponibles, arrêtez-vous et indiquez à l'utilisateur les deux étapes, puis attendez :

1. Construisez et installez l'application à partir d'un checkout du dépôt android-design : cd app && ./gradlew :app:installApp, ce qui installe ~/Applications/AndroidDesignPreview.app.
2. Enregistrez-la pour leur environnement, puis redémarrez la session (<binary> est ~/Applications/AndroidDesignPreview.app/Contents/MacOS/AndroidDesignPreview, écrit comme un chemin absolu là où l'environnement n'expand pas ~) :
   • Claude Code : claude mcp add --scope user android_design_preview -- <binary>
   • Codex : une table [mcp_servers.android_design_preview] dans ~/.codex/config.toml avec command = "<binary>" et default_tools_approval_mode = "approve"
   • Antigravity : agy mcp add android_design_preview <binary>

Idée

Lorsqu'il y a une application, lisez d'abord ses écrans pertinents, son thème, ses ressources et tout DESIGN.md et proposition design/ existant. Répondez à la section 0 de android-design dans la réponse.

• Choisissez une seule graine : la couleur de la marque, ou une couleur de contenu du sujet (un plat, un album, un voyage), jamais la valeur par défaut de l'application #6750A4.
• Lorsque l'écran est un moment héroïque (question 3 de la section 0), superposez trois tactiques ou plus (section 3) et nommez-les.
• Ne modifiez pas le code de l'application ni les dépendances.
• Utilisez des données et ressources représentatives et non sensibles. Utilisez la génération d'images uniquement pour les ressources à l'intérieur d'une proposition, jamais comme substitut à celle-ci.

Réalisez plusieurs propositions uniquement lorsque l'utilisateur le demande. Chacune est son propre fichier, une composition distincte (pas un recolorage) avec sa propre graine dans son theme, et au moins une est un héro.

Fichiers

Travaillez dans la racine du dépôt de l'application, ou le dossier que l'utilisateur nomme. N'écrivez jamais dans le dépôt de cette compétence elle-même.

• DESIGN.md à la racine contient le système de conception partagé. Créez-le s'il manque, avec la graine choisie, les polices et les styles nommés. Modifiez-le uniquement lorsque la direction change ce que toutes les propositions partagent ; l'apparence d'une direction propre va dans le theme de sa proposition.
• design/<slug>.proposal.json contient une proposition.

Les deux sont des fichiers suivis ordinaires ; les commiter suit le flux de travail du projet. Indiquez à l'utilisateur le chemin absolu de la proposition.

Écrire

1. Appelez get_catalog (sa description d'outil indique ce qu'il retourne). C'est le seul vocabulaire de composants : un composant qu'il ne contient pas est hors de portée, donc construisez l'idée à partir de Box, Row, Column, Text et Shape, ou laissez-le de côté.
2. Lisez references/proposal-format.md, puis écrivez DESIGN.md et la proposition, de manière compacte comme le dit sa section "Écrire de manière compacte".

La proposition porte ces règles de conception ; proposal-format.md donne la syntaxe pour chacune, et sa section Règles des composants contient les règles pour les onglets, les carrousels, les superpositions, les choix, les barres d'outils, les menus, les barres d'applications et les badges :

• L'écran a une action principale, marquée comme principale, et elle mène ses pairs comme le décrit la section 2 de android-design.
• Il s'adapte à 600 et 840 dp : une barre de navigation en mode compact devient un rail à partir de medium, et l'écran de détail d'une liste s'ouvre à côté de la liste aux largeurs étendues.
• Le texte se tronque intentionnellement, avec des points de suspension. Les étiquettes des boutons, des chips et de la navigation tiennent sur une ligne.

Vérifier

Pour une proposition, cette étape remplace le rendu dans la vérification d'écran de android-design. Répondez à ses questions à partir des résumés de mise en page et des erreurs de check_proposal (et de get_tree lorsqu'ils ne suffisent pas), jamais à partir d'un rendu ou de pixels. Les captures d'écran restent en dehors de cette boucle : n'en prenez jamais et n'en demandez jamais.

1. Appelez open_proposal avec le chemin absolu de la proposition. Il charge le fichier, le surveille, affiche la fenêtre et retourne les erreurs de validation. Corrigez-les et appelez status jusqu'à ce qu'il n'en signale aucune.
2. Appelez check_proposal. Un appel vérifie chaque écran dans chaque vue et retourne les erreurs et le résumé layout de chaque vue ; sa description d'outil donne le format.
3. Corrigez chaque erreur une fois, puis appelez check_proposal à nouveau. Une erreur overflow nomme un nœud disposé plus large que son parent ou la vue (une ligne qui a besoin de plus de largeur que sa cellule) ; rétrécissez-la, enveloppez-la ou laissez-la défiler. Signalez tout ce qui échoue encore au lieu de boucler.
4. Confirmez l'adaptation à partir des résumés layout : chaque vue plus grande révèle ce que votre réponse d'adaptation de la section 0 promettait, comme un deuxième panneau, un rail ou plus de régions. Google : "L'espace supplémentaire ne signifie pas simplement agrandir la même chose." Une vue plus grande avec seulement les régions du téléphone étalées plus largement échoue.
5. Appelez get_tree uniquement lorsqu'un résumé ou une erreur ne suffit pas ; sa description d'outil indique ce qu'il retourne.

L'étape est terminée lorsque check_proposal réussit ou que chaque erreur restante figure sur la liste que vous rapportez, et que l'adaptation est confirmée.

Montrer

Appelez show_preview. Dites en une ligne ce qu'est la proposition, nommez les tactiques qu'un héro superpose, listez les éventuels problèmes non résolus et rapportez "qualité visuelle jugée uniquement à partir de l'arbre de mise en page". Arrêtez-vous ensuite et attendez la réponse de l'utilisateur.

Réviser

Modifiez la même proposition avec les commentaires de l'utilisateur ; la fenêtre se redessine à la sauvegarde. Répétez la vérification sur les écrans que vous avez modifiés. La révision remplace l'ancienne version ; ne conservez pas de copies.

Approuver et porter

L'approbation est le fait que l'utilisateur le dise dans le chat. Signalez le chemin de la proposition approuvée et que references/compose-mapping.md est la table de portage. Une demande d'exploration uniquement se termine là : n'implémentez pas. Une demande de construction (la compétence android-design envoie d'abord les constructions axées sur la conception de nouvelles applications, écrans et refontes ici) continue vers le portage. L'approbation n'autorise jamais les modifications de version de bibliothèque.

Le portage suit les règles de planification, de branche, de vérification et de révision du projet demandeur :

1. Appelez export_kotlin pour les écrans à porter. Son Kotlin est la première ébauche, pas du code fini.
2. Adaptez-le aux conventions de l'application et aux versions de bibliothèque avec references/compose-mapping.md.
3. Rendez le résultat avec la compétence compose-preview et comparez-le aux arbres de la proposition dans les mêmes vues.

Signalez les composants que le mapping marque comme non vérifiés, et tout ce qu'il manque, au lieu d'inventer un équivalent Compose. Si la conception ne peut pas être préservée avec les dépendances de l'application, demandez.

Wear OS

Une proposition Wear suit le même flux de travail. android-design references/wear-os.md gère les règles de conception, et proposal-format.md gère le format de fichier (identifiant de catalogue, vues, Screen, primary, large).

• Son propre fichier. Une surface par proposition : écrivez design/<slug>-wear.proposal.json à côté de celle du téléphone.
• Vérification de l'adaptation : le remplacement de taille Wear s'applique à partir de 225 dp, donc la vérification est "tient et se lit aux deux tailles de montre, et la grande montre plus de valeur, jamais moins".
• DESIGN.md partagé : sa graine et ses rôles de couleur s'appliquent à Wear ; sa typographie est remplacée par Roboto Flex.
• Problèmes : corrigez round-edge-clipped (contrôle ou texte coupé par le bord arrondi sur un écran fixe) avec des marges en pourcentage ou une mise en page plus petite.
• Portage : les trois mêmes étapes. export_kotlin écrit du Compose Wear : un thème WearAppTheme avec les couleurs exactes du prévisualiseur, AppScaffold et ScreenScaffold, et Navigation 3 avec balayage pour fermer. Rendez le portage aux deux tailles rondes (204 et 227 dp).

Supprimer

Lorsque l'utilisateur le demande, supprimez design/<slug>.proposal.json. Conservez DESIGN.md sauf si l'utilisateur demande également de le supprimer.