Hotfix

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. Un mur propre à ce skill doit être lu d'abord : à l'usage, après ses approbations et son gate QA, il peut FUSIONNER une branche hotfix, ÉTIQUETER une release de patch et la DÉPLOYER — mais seulement après une approbation AskUserQuestion explicite qui tient inconditionnellement, dans tous les modes d'automation y compris autonomous (voir l'introduction). Il est aussi à invocation explicite seulement (disable-model-invocation dans son frontmatter). Installe-moi « Hotfix ». Il conduit un correctif d'urgence qui contourne le processus de sprint normal, avec une piste d'audit complète — invocation explicite seulement, pour les bugs S1 (critique) ou S2 (élevé) ; S3 et moins sont redirigés vers le workflow de bug normal. Il confirme la sévérité avec l'utilisateur, rédige un enregistrement de hotfix (problème, cause racine, correctif, tests, approbations, plan de rollback) et demande avant de l'écrire à production/hotfixes/hotfix-[date]-[short-name].md. Il vérifie que le projet est un dépôt git (git rev-parse) et, seulement au choix de l'utilisateur, crée une branche hotfix/[short-name] depuis la release où le bug vit — l'étiquette de cette release ou sa branche release/*, jamais la tête de main. Il enquête la cause racine, propose le correctif minimal, et ne modifie aucun code avant que l'utilisateur approuve cette proposition ; seulement alors il implémente, en lançant des tests ciblés avec commands.test de project.yaml (consigné NOT RUN, avec la raison, quand absent ou non couvert). Il recueille des approbations parallèles des agents du template lead-programmer, qa-tester et producer — les trois doivent APPROVE — puis un agent qa-lead fixe la portée QA (/smoke-check, un /team-qa ciblé, ou un /team-qa complet), et un résultat QA NOT ASSESSED n'est explicitement pas un passe. Le déploiement est le seul acte irréversible du skill et il est gaté inconditionnellement, peu importe le mode d'automation : seulement sur un oui explicite, il fusionne vers main (et la branche de release si elle existe), étiquette la release de patch et déploie cette étiquette, puis vérifie que le backport est réellement présent sur chaque cible, met à jour le fichier de bug d'origine après une demande, et planifie une revue post-incident dans les 48 heures. Son dossier est un seul SKILL.md. Dépôt : https://github.com/Donchitos/Claude-Code-Game-Studios (le skill est tout le dossier .claude/skills/hotfix/ 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/hotfix/ 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 20233b7851f526da3ad80ee9acb9e2ec9b99bd15e861252eddef04c0d7aaee6c 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 un seul fichier : SKILL.md. Rien dans le dossier n'est un programme ; ce sont des instructions de workflow d'urgence que la session suit à l'usage. Son frontmatter met disable-model-invocation: true et énonce qu'il ne doit rouler que sur une invocation /hotfix explicite. - 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 lu, branché ni modifié. - Réalité du système intégré, depuis les fichiers : ce skill ne lance aucun hook du template — il travaille depuis git (son Bash autorisé se limite aux lectures git rev-parse, git tag --list et git branch --list, plus la création de branche que le texte gate sur mon choix), le commands.test de project.yaml, et les autres skills et agents du template (l'échelle de sévérité de /bug-triage, les agents lead-programmer, qa-tester, producer et qa-lead, /smoke-check, /team-qa, /bug-report) — des pièces qui vivent hors du dossier de ce skill et sont absentes dans une installation seule, donc il ne peut pas fonctionner comme prévu hors du template complet. - À l'usage, il fait de vraies opérations, en partie irréversibles, chacune derrière une approbation explicite : l'enregistrement de hotfix est écrit après une demande, la branche n'est créée qu'à mon choix, aucun changement de code avant que j'approuve le correctif proposé, et la fusion, l'étiquette de release de patch et le déploiement n'arrivent que sur un oui AskUserQuestion inconditionnel qui s'applique dans tous les modes d'automation, y compris autonomous. Le fichier de bug est mis à jour après une demande. Les cibles de déploiement, étiquettes et approbations sont toutes nommées dans le fichier que j'ai lu ; aucun service tiers, compte ni identifiant n'est nommé. - Ne hotfixe rien, ne lance ni git, ni agent du template, ni autre skill, 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 hotfix dans le répertoire des skills de l'agent, dans un dossier nommé exactement « hotfix », 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: hotfix), 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 — qu'il appartient au template complet Claude Code Game Studios et peut ne pas rouler seul (il dépend des agents du template et de /smoke-check, /team-qa et /bug-report), et qu'à l'usage il peut, après des approbations explicites, fusionner une branche hotfix, étiqueter une release de patch et la déployer — le déploiement exigeant toujours son propre oui inconditionnel). 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.