Team Release

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. À l'usage (jamais pendant l'installation), cette pipeline peut étiqueter une release dans le contrôle de version et déployer en staging puis en production — sa Phase 6 ne le fait qu'après sa propre question d'approbation explicite, posée dans chaque mode d'automation, y compris autonomous, et sa Phase 7 fait publier par le community-manager la communication de lancement préparée en Phase 6. Ces gestes vers l'extérieur relèvent de l'usage du skill dans le template complet, jamais de l'installation de cette fiche. Installe-moi « Team Release ». Le skill lui-même orchestre l'équipe release pour exécuter une release du candidat au déploiement. Sans argument de version, il lit production/session-state/active.md et le fichier le plus récent de production/milestones/ pour inférer la version cible et la confirme — ou en demande une ; il ne prend jamais une version codée en dur par défaut. Il résout d'abord review_mode, automation, team.size, workflow et project.stage en lançant le hooks/yaml-helper.sh du template, hors du dossier de ce skill, puis exécute une vérification de stage avant tout lancement : /gate-check release doit avoir passé et réglé project.stage à Release, sinon le run s'arrête BLOCKED et la seule façon de passer est un override explicite que l'utilisateur choisit, avec une raison consignée dans le brief de la Phase 1, dans l'enregistrement go/no-go et dans le rapport final (l'override ne change jamais le stage lui-même). Il annonce l'ensemble actif : au team.size individual par défaut, seul le release-manager roule ; à small, le producer, le devops-engineer, le qa-lead et le community-manager se joignent ; à studio, le security-engineer, l'analytics-engineer, le localization-lead et le performance-analyst aussi, plus le network-programmer quand le jeu est multijoueur. La Phase 1 délègue la planification de release au producer. La Phase 2 délègue le candidat de release au release-manager : les numéros de version sont augmentés dans les fichiers pertinents sur main et ce commit est le candidat (une branche release/[version] n'est coupée que si la release a besoin de stabilisation, chaque correctif atterrissant aussi sur main), et la liste de release de Polish est confirmée. La Phase 3 exécute la porte qualité en parallèle : le qa-lead exécute la suite de régression complète, le devops-engineer construit les artefacts de release pour toutes les plateformes cibles et lance les tests automatisés en CI, le security-engineer audite la sécurité pré-release quand le jeu a des fonctionnalités en ligne, du multijoueur ou des données de joueurs, et le network-programmer signe le netcode pour les jeux multijoueurs — les conditions de lancement sont décidées depuis platform.online et platform.multiplayer dans project.yaml plus le stockage éventuel de données de joueurs, une clé absente n'est pas un false, l'utilisateur est demandé à la place, et un agent sauté est nommé comme sauté avec sa raison. La Phase 4 recueille les signatures localisation, performance et analytique en parallèle. La Phase 5 prend une signature du technical-director en review_mode full seulement, puis délègue l'appel go/no-go au producer : un NO-GO fait surface immédiatement, saute le déploiement entièrement, et ne peut être passé outre qu'avec la justification écrite de l'utilisateur intégrée à l'enregistrement. La Phase 6 est le déploiement, et elle demande toujours une approbation explicite de l'utilisateur dans chaque mode d'automation, y compris autonomous : seulement après un oui à la question « tag, deploy to staging, deploy to production? » (avec une option staging seulement), le release-manager et le devops-engineer étiquettent la release dans le contrôle de version, finalisent le changelog, déploient en staging pour un smoke test final et déploient en production ; en parallèle, le release-manager finalise les patch notes via /patch-notes et le community-manager prépare l'annonce de lancement, prête à publier sur confirmation du déploiement, avec 48 heures de surveillance des tableaux de bord et des erreurs planifiées après la release. La Phase 7 produit le rapport de release et les mises à jour de jalons, surveille les bugs entrants, publie la communication destinée aux joueurs via le community-manager, et confirme les tableaux de bord live. Les sous-agents écrivent un fichier chacun, surtout sous production/releases/ (les patch notes vont à docs/patch-notes/[version].md), 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) ; les sous-skills comme /patch-notes et /changelog ne sont pas couverts par cette exception et demandent avant d'écrire, et le fichier déclare que rien en lui n'autorise un geste vers l'extérieur ou irréversible — étiquettes, pushes, builds et changements de vitrine demandent une confirmation explicite dans tous les cas. 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-release/ 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-release/ 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 7b9950f0848a72af225564d9820bda4655d56493cd0930208447dfe728d34933 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, workflow et project.stage, suit .claude/docs/automation-modes.md, config-resolution.md et error-recovery-protocol.md, lit l'état de session, les jalons, la liste et la configuration de plateforme de mon projet, et lance jusqu'à dix agents du template (release-manager à toutes les tailles, les neuf autres selon team.size et selon les conditions en ligne, multijoueur et données de joueurs du jeu), plus le technical-director pour une signature en mode full — des agents, docs 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 ; il dépend aussi d'autres skills du template (/gate-check, /release-checklist, /patch-notes, /changelog, /retrospective) dont il consomme les portes et les formats. - À l'usage, ses sous-agents écrivent des fichiers de signature et d'enregistrement sous production/releases/ (et docs/patch-notes/[version].md pour les patch notes) 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) ; les sous-skills qu'il invoque demandent avant d'écrire, et l'augmentation de version de la Phase 2 du release-manager modifie des fichiers existants sur main pour créer le commit candidat. Les gestes vers l'extérieur sont fermés séparément, dans les termes du fichier : l'étiquetage et le déploiement en staging et en production de la Phase 6 n'ont lieu qu'après la question d'approbation explicite du skill, posée dans chaque mode d'automation, y compris autonomous (staging seulement est une option offerte), un NO-GO saute la Phase 6 entièrement, et rien dans le fichier n'autorise étiquettes, pushes, builds ou changements de vitrine sans confirmation explicite. Aucune boutique, aucun compte de plateforme ni identifiant n'est nommé dans le fichier ; les cibles et identifiants de déploiement sont ceux de la pipeline de mon propre projet. - Ne planifie, n'étiquette et ne déploie aucune release, 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-release dans le répertoire des skills de l'agent, dans un dossier nommé exactement « team-release », 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-release), 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, ferme sur /gate-check release ayant réglé project.stage à Release, et lance jusqu'à dix de ses agents d'équipe release), et qu'à l'usage, ses enregistrements sont écrits sous production/releases/ sous une exception bornée documentée, sa Phase 2 augmente les versions sur main, et sa Phase 6 étiquette et déploie en staging et en production seulement après sa question d'approbation explicite dans chaque mode d'automation, la communication de lancement étant publiée en Phase 7). 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.