Launch Checklist

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. Il est invocable par l'utilisateur seulement (disable-model-invocation dans son frontmatter), et son mode dry-run n'écrit rien du tout. Installe-moi « Launch Checklist ». Il construit une checklist de readiness de lancement à travers tous les départements — code, contenu, QA, store et distribution, légal, infrastructure, communauté et marketing, opérations — cadrée sur le projet plutôt qu'émise au complet : les éléments des stages non atteints sont hors portée, les éléments de processus du rigor minimal sont retirés, et la section de certification n'est émise que pour le platform.cert_tier du projet (none, itch, steam ou console ; un palier absent est une question à poser, jamais une licence d'émettre toutes les voies, et un palier indéterminable marque la section NOT ASSESSED). Il lit CLAUDE.md, le dernier milestone, toute checklist de release existante et le calendrier de contenu, puis scanne le code pour les commentaires TODO, FIXME et HACK, les sorties de debug, les assets placeholder et les valeurs de test ou de dev codées en dur — chaque scan rapportant son dénominateur (fichiers scannés, résultats trouvés) ou NOT ASSESSED quand il n'y avait rien à chercher, parce qu'un scan à zéro résultat sur une racine vide ne doit pas s'afficher comme un crochet vert. Il demande ensuite, section par section, pour les éléments que seule une personne peut confirmer (horaire d'astreinte, EULA, clés presse, prix, un soak test que quelqu'un a lancé) : les éléments non confirmés gardent le statut global à NOT ASSESSED, et cette phase de questions est sautée en mode autonomous et en dry-run, ce qui laisse aussi le statut à NOT ASSESSED. La décision go/no-go suit une règle de première correspondance — NOT READY si un élément bloquant tient, sinon NOT ASSESSED si quoi que ce soit n'est pas vérifié, sinon CONDITIONAL, sinon READY — avec des sign-offs requis des rôles creative, technical, QA, producer et release-manager. Enfin, il présente la checklist et demande avant de l'écrire à production/releases/launch-checklist-[date].md, ne créant rien avant la réponse, pas même le répertoire ; un run dry-run n'écrit rien du tout. 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/launch-checklist/ 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/launch-checklist/ 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 ce8813df00b1b1f513c935fa6fcefd560c293e96fee02040a7705063a6afa7d2 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 checklist 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 : à l'usage, le skill résout la configuration du studio en lançant le hooks/yaml-helper.sh du template (clés rigor, workflow, project.stage, cert_tier, automation), lit la section cert-tier du .claude/docs/effects-map.md du template et son document automation-modes, et suit l'arborescence production/ du template (milestones, releases, calendrier de contenu) — des fichiers qui vivent hors du dossier de ce skill et sont absents dans une installation seule, donc des parties ne peuvent pas rouler hors du template complet. Dans le template, il lit et grep le code et les documents de mon propre projet, en local ; ses scans de code cherchent les commentaires TODO/FIXME/HACK, les sorties de debug, les assets placeholder et les valeurs de test ou de dev codées en dur, et rapportent ce qu'ils ont scanné. - À l'usage, il écrit exactement un fichier, et seulement après avoir demandé : production/releases/launch-checklist-[date].md — ne créant rien avant la réponse, pas même le répertoire production/releases/. En mode dry-run (et pour la phase de confirmation humaine en mode autonomous), il n'écrit rien et les éléments non confirmés gardent le verdict à NOT ASSESSED. Il ne déploie rien et ne contacte aucun store ni service. Aucun compte ni identifiant n'est nommé dans le fichier que j'ai lu ; le scan de valeurs codées en dur qu'il fait cherche des identifiants de test dans mon code comme risque de lancement, ce qui est une recherche, pas une collecte. - Ne construis aucune checklist, ne scanne aucun projet, 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 launch-checklist dans le répertoire des skills de l'agent, dans un dossier nommé exactement « launch-checklist », 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: launch-checklist), 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 résout ses réglages via le hook yaml-helper du template et lit l'effects-map et l'arborescence production du template), et qu'à l'usage il n'écrit qu'un seul fichier de checklist sous production/releases/ après mon oui, ou rien du tout en mode dry-run). 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.