Day-One Patch

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 : il est invocable par l'utilisateur seulement (disable-model-invocation dans son frontmatter), et à l'usage il implémente de vrais correctifs de code via des agents du template et lance la commande de test du projet — divulgué dans l'introduction ci-dessous, jamais pendant l'installation. Installe-moi « Day-One Patch ». Il prépare un patch de jour un après le verrouillage du gold master : un mini-sprint de correctifs seulement (aucune nouvelle fonctionnalité, aucun refactoring, aucun correctif estimé à plus de 4 heures), pas un hotfix et pas un sprint complet. Il vérifie d'abord sa propre prémisse — il lit project.stage (project.yaml, repli production/stage.txt), le dernier enregistrement de gate dans production/gate-checks/, les bugs ouverts dans production/qa/bugs/ et le dernier audit de sécurité, et il s'arrête ou avertit clairement quand aucun enregistrement de gate de release passé n'existe, parce que sa passe QA légère n'est justifiée que par ce gate. Il classe les bugs ouverts pour l'inclusion, présente la portée (inclus et reportés) pour approbation, et compare l'effort total à une fenêtre d'un jour. Avant qu'aucun code soit écrit, il lance l'agent release-manager du template pour un plan de rollback et demande avant de l'écrire à production/releases/rollback-plan-[version].md. Pour chaque correctif de code approuvé, il lance l'agent lead-programmer du template pour planifier le correctif minimal sans rien écrire, demande une fois pour l'ensemble, puis fait implémenter les correctifs et les fait vérifier par l'agent qa-tester du template, en lançant des tests ciblés avec commands.test de project.yaml (consigné NOT RUN quand ce réglage est absent) ; les correctifs de configuration seuls sont édités directement, après une demande nommant le fichier et le changement de valeur exact. Un agent qa-lead décide ensuite entre un smoke check ciblé et une régression plus large, et un verdict QA NOT ASSESSED n'est explicitement pas un passe. Enfin, il demande avant d'écrire l'enregistrement du patch à production/releases/day-one-patch-[version].md. 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/day-one-patch/ 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/day-one-patch/ 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 dcd3d710b55dfd9e426965850cb572945d00d5d2d52daf53e83682ad573da971 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 que la session suit à l'usage. Son frontmatter met disable-model-invocation: true — il ne roule que quand l'utilisateur l'invoque. - 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 ni modifié. - Réalité du système intégré, depuis les fichiers : ce skill ne lance aucun hook du template — il lit project.yaml (stage, commands.test), production/stage.txt, les enregistrements de gates, les fichiers de bugs, les fichiers de sprints et les audits de sécurité directement — mais il lance des agents du template qui vivent hors du dossier de ce skill (release-manager pour le plan de rollback, lead-programmer pour les correctifs, qa-tester pour la vérification, qa-lead pour le gate QA) et appelle d'autres skills du template (/smoke-check, /patch-notes, /bug-report, /retrospective), donc il ne peut pas fonctionner comme prévu hors du template complet. - À l'usage, il change du vrai code, mais seulement via des approbations : le plan de rollback est écrit après une demande, les correctifs de code sont planifiés sans rien écrire, puis appliqués seulement après une demande unique couvrant l'ensemble, les tests ciblés roulent avec commands.test de project.yaml, et les correctifs de configuration seuls sont édités directement seulement après une demande nommant le fichier et le changement de valeur. L'enregistrement du patch est écrit après une demande. Aucun service tiers, compte ni identifiant n'est nommé dans le fichier que j'ai lu. - Ne prépare aucun patch, ne lance aucun agent 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 day-one-patch dans le répertoire des skills de l'agent, dans un dossier nommé exactement « day-one-patch », 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: day-one-patch), 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 lance les agents du template release-manager, lead-programmer, qa-tester et qa-lead), et qu'à l'usage il prépare un patch de jour un, applique les correctifs de code approuvés et n'écrit son plan de rollback et son enregistrement de patch sous production/releases/ qu'après avoir demandé). 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.