Dev Story

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. Deux comportements propres à ce skill sont divulgués d'emblée : à l'usage, les agents programmeurs qu'il briefe écrivent du vrai code et des tests dans mon projet, et deux de ses propres écritures — le checkpoint de session et le tampon d'évidence — sont faites sans demande (voir l'introduction). Il est aussi invocable par l'utilisateur seulement (disable-model-invocation dans son frontmatter). Installe-moi « Dev Story ». Il implémente une story en code avec des tests, selon ses ADR. Il vérifie que la story peut commencer (statut et version de l'ADR gouvernant contre le tampon de la story, version du manifeste de contrôle, dépendances — en ne lisant references/version-mismatch.md que quand une version diffère réellement), demande une fois avant de marquer la story In Progress (ses champs Status et Last Updated et son entrée dans production/sprint-status.yaml), puis briefe le bon agent programmeur du template selon la couche et le type de la story (engine-programmer, gameplay-programmer, ui-programmer, ai-programmer ou network-programmer) plus le spécialiste moteur configuré, qui vérifie les fichiers changés ensuite et n'édite rien. Les agents programmeurs écrivent le code et les tests sous les racines code et test du projet ; une story Config/Data n'a besoin d'aucun agent et son fichier de données est édité directement après une demande. Deux écritures font exception au patron demander-d'abord, énoncé dans le SKILL.md lui-même : le checkpoint de session (envoyé au session-state.sh du template) et le tampon d'évidence sont écrits sans demande. Quand le travail est fini, il vérifie que les fichiers nommés existent réellement sur le disque, lance un contrôle de parse du moteur (pour Godot, des runs godot --headless d'import et de parse-check — godot sur le PATH est pré-approuvé par ce skill, alors qu'un moteur lancé via engine.path ou l'exécutable de commands.test demande d'abord), et pour toute story qu'un joueur peut voir, il lance la scène du jeu, capture une image dans production/qa/evidence/[story-slug]/ et rapporte exactement une ligne Run result (OBSERVED, NOT VERIFIED ou N/A). Il termine en remplaçant la section Files de la story par la vraie liste des fichiers changés. Son dossier contient aussi CONTRACT.md et deux références (engine-checks pour Unity/Unreal, version-mismatch). Dépôt : https://github.com/Donchitos/Claude-Code-Game-Studios (le skill est tout le dossier .claude/skills/dev-story/ au commit épinglé : 4 fichiers 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/dev-story/ de ce checkout. Compare ensuite chaque fichier du dossier aux empreintes enregistrées pour cette fiche le 2026-10-22 : [FINGERPRINTS] - CONTRACT.md: SHA-256 95abf80e16dfc28230989db818e6f8afeb05d73cb4600882855f598f5ee77071 - SKILL.md: SHA-256 ca76457c34ec9a8468c34bcc55664273eff2b077afbebe36f1dda0c8ec8e474d - references/engine-checks.md: SHA-256 c3ec789cc1c424366e5e85ebc56e5df317b5dfdd011f9e944e6242235640fdb4 - references/version-mismatch.md: SHA-256 2f38c7964569cba3b22bfbfc0cc702ecb1c4580e7aa294994b3047cae9318a41 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 4 fichiers : SKILL.md, CONTRACT.md (le contrat de passation pour les fichiers de story, d'ADR, de manifeste et d'état de session) et references/engine-checks.md plus references/version-mismatch.md, chacun chargé seulement dans sa situation (contrôles de parse Unity/Unreal ; un écart de version d'ADR ou de manifeste). Rien dans le dossier n'est un programme ; les quatre sont des instructions ou un texte de contrat que le skill lit à l'usage. Son frontmatter met disable-model-invocation: true. - 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 automation, workflow, qa.level, gate_level, engine_values, specialists, perf_budgets, system_overrides) et appelle des scripts du template sous .claude/scripts/ (story-facts.sh, adr-status.sh, md-section.sh, session-state.sh, review-receipts.sh), lance les agents programmeurs du template et le spécialiste moteur configuré, et lance le moteur de jeu du projet pour les contrôles de parse et les captures — des fichiers, agents et outils qui vivent hors du dossier de ce skill et sont absents dans une installation seule, donc il ne peut pas rouler hors du template complet. - À l'usage, il produit du vrai code : les agents programmeurs écrivent code et tests sous les racines code et test de mon projet, la story est marquée In Progress après une demande unique, et sa section Files est remplacée à la fin. Deux écritures font exception, énoncées dans le SKILL.md : le checkpoint de session et le tampon d'évidence (un fichier de hash sous production/qa/evidence/[story-slug]/) sont écrits sans demande. Il lance aussi le jeu pour les stories visibles par un joueur et y sauvegarde une capture. Aucun service tiers, compte ni identifiant n'est nommé dans les fichiers que j'ai lus. - N'implémente aucune story, ne lance aucun hook, script, agent ni moteur 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 dev-story dans le répertoire des skills de l'agent, dans un dossier nommé exactement « dev-story », en gardant ses 4 fichiers dans leur arborescence relative d'origine (SKILL.md à sa racine). 4. Vérifie sans appels réseau : frontmatter valide (name: dev-story), les 4 fichiers 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 briefe les agents programmeurs du template, appelle ses scripts .claude/scripts et lance mon moteur de jeu), et qu'à l'usage il écrit du vrai code et des tests dans mon projet, marque la story In Progress après une demande unique, et écrit son checkpoint de session et son tampon d'évidence sans demande). 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.