Team QA

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), ce skill ajoute aussi une ligne de commentaire de run QA à production/session-state/active.md en silence, sans demander — la section Session State Update du fichier le dit elle-même, et c'est divulgué dans cette fiche. Installe-moi « Team QA ». Le skill lui-même orchestre l'équipe QA — seulement le qa-lead et le qa-tester — via un cycle de test complet pour un sprint ou une fonctionnalité. Il résout d'abord review_mode, automation, team.size et qa.level en lançant le hooks/yaml-helper.sh du template, hors du dossier de ce skill (son octroi allowed-tools n'a ni Edit ni outils de tâches), et annonce l'ensemble actif : au team.size individual par défaut, le qa-tester roule et le qa-lead n'est invoqué qu'aux portes de phase ; à small, les deux roulent en pipeline ; à studio, un qa-tester est lancé par story, en parallèle, plus la signature. La Phase 1 charge le contexte : elle trouve le fichier de sprint sous production/sprints/ ou les stories de la fonctionnalité, infère le sprint actif depuis production/session-state/active.md et production/sprint-status.yaml quand aucun argument n'est donné (et n'invente jamais un sprint), lit project.stage, et grep les bugs ouverts déjà au dossier dans production/qa/bugs/. La Phase 2 lance le qa-lead pour la stratégie QA — classification des stories, exigences de preuves de test selon qa.level (à minimal, les tests sont waived et les critères d'acceptation sont parcourus à la place), et un verdict de smoke check pris du plus récent rapport production/qa/smoke-*.md existant, jamais ré-interviewé : un smoke check FAIL arrête le cycle là, UNKNOWN ou NOT ASSESSED continue seulement avec un avertissement, et la stratégie passe par une question de revue explicite. La Phase 3 produit le plan de test et l'orchestrateur ne l'écrit à production/qa/qa-plan-[sprint]-[date].md qu'après avoir demandé « May I write the QA plan…? ». La Phase 4 lance le qa-tester pour écrire les cas de test à un chemin que la phase nomme elle-même, production/qa/test-cases/[story-slug]-cases.md, sous une exception bornée que le fichier documente (chemin nommé par l'orchestrateur, artefact nouveau sous production/, docs/ ou tests/, porte de phase se terminant par un AskUserQuestion, quel que soit le mode d'automation) — aucune demande par écriture dans ces bornes ; les groupes de cas sont revus avant exécution. La Phase 5 parcourt le QA manuel story par story, en ne consignant que les résultats que le testeur donne réellement (une story sans réponse reste non exécutée, jamais remplie à sa place) : un FAIL lance le qa-tester pour déposer un rapport de bug formel dans production/qa/bugs/BUG-[NNNN].md au format /bug-report, et un PASS sur une story Visual/Feel ou UI est prouvé dans production/qa/evidence/ — l'orchestrateur demande une fois par groupe de stories et écrit le fichier de preuve depuis le template, en référençant les captures que le testeur y a sauvées, avec les lignes de signature laissées décochées sauf si la signature a réellement eu lieu, parce que /story-done ferme sur ce répertoire. La Phase 6 lance le qa-lead pour rédiger le rapport de signature en texte dans sa réponse — il n'écrit rien — sous des règles de verdict briefées mot pour mot (un bug S1 ou S2 ouvert dans le périmètre, au dossier ou nouvellement déposé, donne d'abord NOT APPROVED ; toute story sans preuve exécutée, ou un smoke check UNKNOWN / NOT ASSESSED, donne NOT ASSESSED, jamais APPROVED) ; l'orchestrateur vérifie le verdict contre les mêmes règles et n'écrit le rapport à production/qa/qa-signoff-[sprint]-[date].md qu'après avoir demandé. Enfin — divulgué ici parce que le fichier le dit clairement — après la phase finale, l'orchestrateur ajoute en silence un commentaire QA RUN d'une ligne à production/session-state/active.md, sans demander. 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-qa/ 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-qa/ 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 19448b88956168db4a56c8e6be312def07f7c8297cdaa746d8bead633a1716bb 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 et qa.level, suit .claude/docs/automation-modes.md, config-resolution.md et coding-standards.md, lit les fichiers de sprint, stories, bugs, rapports de smoke et session-state de mon projet sous production/, et ne lance que les agents qa-lead et qa-tester du template (selon team.size) — 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 ; d'autres skills du template (/bug-report, /bug-triage, /smoke-check, /story-done) définissent les formats et les portes que ce cycle alimente. - À l'usage, le qa-tester écrit les fichiers de cas de test sous production/qa/test-cases/ 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/, porte de phase se terminant par un AskUserQuestion dans chaque mode d'automation). Tout le reste est écrit par l'orchestrateur seulement après avoir demandé : le plan QA (production/qa/qa-plan-[sprint]-[date].md), les fichiers de preuve par groupe sous production/qa/evidence/, et le rapport de signature (production/qa/qa-signoff-[sprint]-[date].md) ; les rapports de bugs sous production/qa/bugs/ sont écrits par le qa-tester lancé après un FAIL. Une écriture fait exception à tout cela et est divulguée comme telle : après la phase finale, l'orchestrateur ajoute en silence une ligne de commentaire QA RUN à production/session-state/active.md, sans demande. Aucun service tiers, compte ni identifiant n'est nommé dans le fichier. - N'exécute aucun cycle QA, ne lance ni le qa-lead ni le qa-tester, 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-qa dans le répertoire des skills de l'agent, dans un dossier nommé exactement « team-qa », 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-qa), 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, lit les fichiers QA production/ du template et lance ses agents qa-lead et qa-tester), et qu'à l'usage, ses cas de test sont écrits sous production/qa/ sous une exception bornée documentée, ses fichiers de plan, de preuve et de signature seulement après les demandes de l'orchestrateur, et il ajoute en silence une ligne QA RUN à production/session-state/active.md à la fin d'un run, comme le fichier le dit lui-même). 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.