Team UI

Avant de commencer : lis ce prompt d'installation au complet, dis-moi en quelques lignes ce que ce skill fait et ce que son installation implique, et attends mon feu vert avant de faire quoi que ce soit d'autre. Prérequis — SYSTÈME INTÉGRÉ D'ABORD : ce skill est une pièce du template complet « Claude Code Game Studios » (49 agents, 74 skills, templates de studio et un CLAUDE.md de studio, selon le README du dépôt). Chaque skill suppose ce template installé, avec ses conventions, sa configuration project.yaml / project.local.yaml, ses documents de modes .claude/docs/, ses hooks (par exemple hooks/yaml-helper.sh, hors du dossier de ce skill) et ses scripts d'aide .claude/scripts/. Installer cette fiche seule copie seulement le dossier de ce skill, sans le reste du système : le skill peut référencer des agents, fichiers, hooks ou scripts du template absents hors du template complet, et il peut ne pas fonctionner comme prévu seul. Aucun compte, aucune clé ni aucun paiement n'est requis pour copier les fichiers, et rien n'est exécuté pendant l'installation. Installe-moi « Team UI ». Le skill lui-même orchestre l'équipe UI via la pipeline UX complète — rédaction, design visuel, implémentation, revue, polissage — pour une fonctionnalité UI, en utilisant les skills /ux-design et /ux-review du template et les templates de studio ; sans argument, il affiche l'usage et sort sans lancer aucun agent ni lire aucun fichier de design. Il résout d'abord review_mode, automation et team.size en lançant le hooks/yaml-helper.sh du template, hors du dossier de ce skill, et annonce l'ensemble actif : au team.size individual par défaut, l'ui-programmer et l'ux-designer roulent ; à small, l'accessibility-specialist et l'art-director se joignent ; à studio, le spécialiste UI moteur aussi, avec une passe de revue adversariale. La Phase 1a rassemble le contexte — le concept de jeu ou le brief en rigueur minimale, le parcours joueur, les exigences UI des GDD, les patterns d'interaction et le palier d'accessibilité engagé dans design/accessibility-requirements.md — et rapporte chacun de ces cinq intrants comme présent ou ABSENT avant que quoi que ce soit soit conçu : un fichier accessibility-requirements manquant signifie qu'il n'y a aucun palier engagé, l'ux-designer déclare le palier qu'il suppose, la Phase 4 devra plus tard rapporter l'accessibilité comme NOT ASSESSED plutôt que réussie, et /ux-design accessibility est recommandé ; un fichier interaction-patterns manquant est signalé immédiatement et l'utilisateur choisit de lancer /ux-design patterns d'abord ou de continuer avec chaque pattern traité comme nouveau et un nouveau fichier de bibliothèque écrit à la fin — les patterns ne sont jamais inventés depuis le nom de la fonctionnalité. La Phase 1b rédige la spec UX (design/ux/[feature-name].md, depuis le template ux-spec, ou le template hud-design pour un HUD) en invoquant le sous-skill /ux-design ou en déléguant à l'ux-designer, et la Phase 1c ferme sur /ux-review : aucune Phase 2 avant APPROVED, une spec NEEDS REVISION est révisée sur place et re-revue, et passer outre un NEEDS REVISION ou un NOT ASSESSED est une décision consciente de l'utilisateur consignée dans le rapport final. La Phase 2 délègue le design visuel à l'art-director (traitement de la bible d'art, contraste et jamais la couleur seule pour l'état, exigences d'assets). La Phase 3 lance le spécialiste UI moteur nommé par specialists.ui dans project.yaml (explicitement : une valeur null y signifie UNSET, sauter le spécialiste, ne jamais lancer « null » ; sans moteur configuré, l'étape est sautée et consignée comme validation moteur NOT ASSESSED) pour le guidage de framework moteur, puis délègue l'implémentation à l'ui-programmer — l'UI ne possède ni ne modifie jamais l'état du jeu, tout le texte destiné aux joueurs passe par le système de localisation sans chaînes codées en dur, clavier/souris et manette sont tous deux supportés, l'accessibilité est implémentée contre le palier engagé, et tout nouveau pattern d'interaction est ajouté à design/ux/interaction-patterns.md avant que l'implémentation soit complète. La Phase 4 exécute les revues de l'ux-designer, de l'art-director et de l'accessibility-specialist en parallèle ; les violations d'accessibilité sont des bloqueurs, et sans palier engagé cette porte rapporte NOT ASSESSED et n'est jamais rapportée comme réussie. La Phase 5 polit (animations sautables respectant les préférences de réduction de mouvement, sons UI seulement via le système d'événements audio, toutes les résolutions et ratios, vérifications de la bibliothèque de patterns et du budget visuel du HUD). Les sous-agents écrivent des artefacts de travail sous production/ui/[feature-name]/ sans demande par écriture, sous une exception bornée que le fichier documente (chemin nommé par l'orchestrateur, artefact nouveau sous production/, docs/ ou tests/, phase fermée par un AskUserQuestion) ; le code d'implémentation est hors de cette exception et suit une demande pour l'ensemble des fichiers, et les sous-skills /ux-design et /ux-review ne sont pas couverts par l'exception du tout et demandent avant d'écrire — la spec UX elle-même vit sous design/ pour cette raison. Cet orchestrateur n'écrit aucun fichier directement. Son frontmatter épingle model: sonnet. Dépôt : https://github.com/Donchitos/Claude-Code-Game-Studios (le skill est tout le dossier .claude/skills/team-ui/ au commit épinglé : 1 fichier en tout) Version épinglée : installe le code au commit 05ad7c8a5b8aa2aa86bbd3439ae7cf7295cac418 exactement. Ne substitue pas une version plus récente. Si ce commit est inaccessible, arrête-toi et dis-le-moi. 1. Clone https://github.com/Donchitos/Claude-Code-Game-Studios dans un dossier temporaire, place-toi au commit 05ad7c8a5b8aa2aa86bbd3439ae7cf7295cac418, et copie le dossier .claude/skills/team-ui/ de ce checkout. Compare ensuite chaque fichier du dossier aux empreintes enregistrées pour cette fiche le 2026-10-22 : [FINGERPRINTS] - SKILL.md: SHA-256 dce06487831bdcea7f62ead4f47de38c6b6acd877fb047655bf82ed28cfcfb36 Si un fichier ne correspond pas, il a changé depuis la préparation de la fiche : ne l'installe pas encore, dis-moi ce que tu as trouvé et laisse-moi décider. 2. Lis SKILL.md au complet, et dis-moi en mots simples : ce que le skill fait quand on l'utilise, à quoi il se connecte, s'il lit ou envoie des informations personnelles ou des identifiants, et tout ce qui semble inhabituel. Arrête-toi sur tout signal d'alerte et dis-le-moi avant d'aller plus loin. Confirme ces points à partir des fichiers : - Le dossier du skill contient 1 fichier : SKILL.md seulement. Rien dans le dossier n'est un programme ; ce sont des instructions que l'agent suit à l'usage. - Rien n'est envoyé nulle part pendant l'installation elle-même ; le seul téléchargement à l'installation est le dossier du skill depuis GitHub au commit épinglé, et aucun projet à moi n'est audité, lu ni modifié. - Réalité du système intégré, depuis le fichier : à l'usage, le skill lance le hooks/yaml-helper.sh du template pour résoudre review_mode, automation et team.size, suit .claude/docs/automation-modes.md, config-resolution.md, technical-preferences.md et error-recovery-protocol.md, invoque les skills /ux-design et /ux-review du template et ses templates UX, HUD, patterns d'interaction et accessibilité, lit le concept, le parcours, les GDD, les patterns et les fichiers d'accessibilité de mon projet sous design/, et lance les agents du template (ux-designer et ui-programmer à toutes les tailles ; art-director et accessibility-specialist à small et plus ; spécialiste UI moteur à studio) — des agents, docs, templates, skills et fichiers de projet qui vivent hors du dossier de ce skill et sont absents dans une installation seule, donc il ne peut pas rouler comme prévu seul. - À l'usage, ses sous-agents écrivent des artefacts de revue et de design visuel sous production/ui/[feature-name]/ sans demande par écriture, mais seulement dans l'exception bornée que le fichier documente (chemin nommé par l'orchestrateur, artefact nouveau sous production/, docs/ ou tests/, phase fermée par un AskUserQuestion) ; le code d'implémentation de l'ui-programmer sous la racine de code est hors de cette exception et n'est écrit qu'après une seule demande pour l'ensemble des fichiers, et la spec UX et les mises à jour de la bibliothèque de patterns sous design/ sont produites par le sous-skill /ux-design ou un agent qui demande d'abord, parce que les sous-skills ne sont pas couverts par l'exception. Cet orchestrateur n'écrit aucun fichier directement. Aucun service tiers, compte ni identifiant n'est nommé dans le fichier. - Ne conçois et n'implémente aucune fonctionnalité UI, ne lance aucun agent d'équipe, n'invoque ni /ux-design ni /ux-review, ne lance aucun hook du template, et n'utilise le skill d'aucune façon pendant cette installation : l'utiliser est une étape séparée qui ne commence que quand je le demande plus tard. 3. Quand je dis « yes, install », installe-le comme skill : copie tout le dossier team-ui dans le répertoire des skills de l'agent, dans un dossier nommé exactement « team-ui », en gardant ses 1 fichier dans leur arborescence relative d'origine (SKILL.md à sa racine). 4. Vérifie sans appels réseau : frontmatter valide (name: team-ui), les 1 fichier en place avec des empreintes concordantes. N'exécute rien du dossier et n'utilise pas le skill pour vérifier. 5. Indique ce qui a été installé, où, et ce qu'il me reste à faire moi-même (par exemple : qu'il appartient au template complet Claude Code Game Studios et peut ne pas rouler seul (il résout ses réglages via le hook yaml-helper du template, lit les fichiers de contexte design/ du template, invoque ses skills /ux-design et /ux-review et lance ses agents d'équipe UI), et qu'à l'usage, ses artefacts de travail sont écrits sous production/ui/ sous une exception bornée documentée, le code d'implémentation seulement après une demande pour l'ensemble, la spec UX demande d'abord via le sous-skill /ux-design, et la porte d'accessibilité rapporte NOT ASSESSED — jamais réussie — quand aucun palier d'accessibilité engagé n'existe). GitHub est optionnel : si j'ai un compte GitHub ou la CLI gh, tu peux l'utiliser ; sinon l'accès public suffit. Ne jamais l'exiger sauf s'il figure dans les prérequis ci-dessus. Règles : ne touche à rien en dehors du dossier temporaire et de la cible d'installation. Si quelque chose semble anormal, arrête-toi et demande-moi.