Team Polish

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 Polish ». Le skill lui-même orchestre l'équipe de polissage pour optimiser et durcir une fonctionnalité ou une zone ; sans argument, il affiche l'usage et sort sans lancer aucun agent. Il résout d'abord review_mode, automation, team.size et workflow en lançant le hooks/yaml-helper.sh du template, hors du dossier de ce skill, et annonce l'ensemble actif avant la Phase 1 : au team.size individual par défaut, le performance-analyst et le technical-artist roulent et aucun programmeur n'est actif, donc les items d'optimisation appartenant à un programmeur ne sont pas implémentés dans ce run — le rapport remet la liste à /dev-story ; à small, le sound-designer, le qa-tester et l'engine-programmer se joignent (plus le tools-programmer quand une cause remonte à un outil d'authoring de contenu), et à studio une passe QA adversariale s'ajoute. La Phase 1 délègue le profilage au performance-analyst, qui profile la zone avec /perf-profile et produit une liste d'optimisation priorisée (changement, gain attendu, responsable par item) — le performance-analyst n'écrit aucun code de jeu. La Phase 2 implémente cette liste via ses responsables dans l'ensemble actif (engine-programmer pour les causes moteur, tools-programmer pour les causes d'outils d'authoring), tandis que la Phase 3 (technical-artist : VFX, particules, shaders, jus visuel) et la Phase 4 (sound-designer : complétude audio, niveaux de mix, couches d'ambiance, vérifications spatiales) roulent en parallèle ; chaque agent implémenteur des Phases 2 à 4 retourne d'abord les fichiers qu'il créera ou changera, et l'orchestrateur demande une fois pour tout l'ensemble des Phases 2-4 avant toute modification, parce que ces phases modifient du code, des shaders, de l'audio et des assets existants et sont hors de l'exception bornée d'écriture. La Phase 5 délègue le durcissement au qa-tester : cas limites, tests de soak, tests de stress, tests de régression nommant chaque changement des Phases 2-4, et tests sur spécification minimale quand disponible. La Phase 6 signe READY FOR RELEASE, NOT ASSESSED ou NEEDS MORE WORK sous des règles strictes que le fichier énonce : les budgets de performance dans project.yaml (performance.target_framerate, frame_budget_ms, draw_call_limit, memory_ceiling_mb) n'ont aucun défaut, donc un budget non réglé signifie que la métrique n'a jamais été comparée et que le verdict ne peut pas être READY ; une phase qui n'a pas roulé donne de même NOT ASSESSED, et une métrique connue au-dessus du budget ou une régression non résolue donne NEEDS MORE WORK. Chaque agent écrit un fichier de rapport daté sous production/polish/, un emplacement que le fichier déclare n'être encore lu par rien dans le dépôt — les rapports sont des enregistrements, pas des entrées de porte. 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-polish/ 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-polish/ 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 8d394fd7111b8ee96d4a91809e6959225d73938ffeafdaa06b0fa5a33679086d 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, team.size et workflow, suit .claude/docs/automation-modes.md, config-resolution.md et error-recovery-protocol.md, utilise le skill /perf-profile du template, lit le code, la bible d'art et les budgets de performance dans project.yaml de mon projet, et lance les agents du template (performance-analyst et technical-artist à toutes les tailles ; engine-programmer, tools-programmer, sound-designer et qa-tester aux tailles plus larges) — des agents, docs, 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 rapport datés sous production/polish/ 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) — et le fichier déclare clairement que rien dans le dépôt ne lit encore production/polish/. Les changements d'optimisation et de polissage des Phases 2 à 4, qui modifient du code, des shaders, de l'audio ou des assets existants, sont hors de cette exception : chaque agent implémenteur retourne d'abord son ensemble de fichiers et ne modifie qu'après une demande pour tout l'ensemble des Phases 2-4. Cet orchestrateur n'écrit aucun fichier directement. Aucun service tiers, compte ni identifiant n'est nommé dans le fichier. - Ne polis et ne profile aucune fonctionnalité, ne lance aucun agent d'équipe, 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-polish dans le répertoire des skills de l'agent, dans un dossier nommé exactement « team-polish », 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-polish), 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 le code et les budgets du projet du template et lance ses agents d'équipe polissage), et qu'à l'usage, ses artefacts de rapport sont écrits sous production/polish/ sous une exception bornée documentée, les modifications des Phases 2 à 4 seulement après une demande pour l'ensemble, et à la taille d'équipe par défaut les items d'optimisation de programmeur sont remis à /dev-story au lieu d'être implémentés). 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.