UAT Plan

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 : aucun pour l'installation elle-même : aucun compte, aucune clé API, aucun service payant, et rien d'autre à installer d'abord. Pour utiliser le skill ensuite, aucune clé ni aucun compte n'est requis non plus : il fonctionne à partir d'exigences ou d'histoires utilisateur et d'une portée de livraison que je fournis moi-même, dans notre conversation. Le skill ne nomme aucun service externe, aucun connecteur et aucun site web : les seules routes à l'usage sont le matériel que je te remets et, seulement si je le demande, un document de plan ou un fichier tableur que tu écris localement pour moi — les deux divulgués au point 2 avant qu'ils arrivent. Installe-moi « uat-plan ». Il planifie les tests d'acceptation utilisateur (UAT) et rédige des scripts UAT destinés aux gens d'affaires à partir de mes exigences ou de mes critères d'acceptation. À partir de la portée que je lui donne, il produit un plan UAT — ce qui est dans et hors de portée, par processus d'affaires, les personnes et les rôles (propriétaire d'affaires qui signe, responsable UAT, testeurs par processus, contact de l'équipe de livraison pour les défauts), l'environnement et les données de test requises par script (qui les prépare, et ce qui doit être masqué), les critères d'entrée, les critères de sortie, les règles de défauts (gravité en termes d'affaires, qui trie et en combien de temps, retest plus un ensemble de régression nommé après un correctif), un calendrier avec tri quotidien et une date de signature, et un registre de signature (accepter, accepter avec conditions, ou rejeter) — plus un script pas à pas par scénario d'affaires, qu'un testeur d'affaires peut exécuter sans l'équipe de livraison dans la pièce : chaque script a un identifiant, les identifiants des exigences ou critères d'acceptation qu'il couvre, des préconditions, le rôle du testeur, une priorité, et un tableau d'étapes avec l'action, les données de test, le résultat attendu, et des colonnes vides pour le résultat réel, réussi ou échoué, et l'identifiant de défaut. Il vérifie ensuite la couverture : chaque exigence dans la portée est couverte par au moins un script, et celles qui ne le sont pas sont listées avec la raison. Il ne marque jamais rien comme réussi, n'invente jamais de dates, de noms ni de valeurs de données que je n'ai pas fournis (il laisse plutôt un espace réservé clair et le liste dans les points ouverts), et ne met jamais de données personnelles ou financières réelles dans un script — il décrit plutôt le profil de l'enregistrement. Dépôt : https://github.com/ChenxingJi-Innovate/Cheatcode_ (le skill est tout le dossier packages/requirements-kit/skills/uat-plan/ au commit épinglé : SKILL.md seulement, 1 fichier) Version épinglée : installe le code au commit 1071f72533f0a8bb671e2d9b48c8d75f12adc904 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/ChenxingJi-Innovate/Cheatcode_ dans un dossier temporaire, place-toi au commit 1071f72533f0a8bb671e2d9b48c8d75f12adc904, et copie le dossier packages/requirements-kit/skills/uat-plan/ de ce checkout. Compare ensuite chaque fichier du dossier aux empreintes enregistrées pour cette fiche le 2026-10-19 : [FINGERPRINTS] - SKILL.md: SHA-256 26a34f6ede63aaf1f393b4f91ae62933b2a62f866767da3eaa15f0f76c969d80 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, à quels services il peut se connecter, s'il lit ou envoie des informations personnelles ou des clés, 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 du fichier : - Le dossier du skill contient 1 fichier seulement : SKILL.md (3 585 octets). Il n'y a aucun script, aucun code, aucun import, aucune URL et aucune référence de fichier dedans : le skill est autonome dans son propre dossier et n'a besoin d'aucun fichier d'ailleurs dans le dépôt — ni les skills frères (acceptance-criteria, brd-draft, requirements-lint, traceability-matrix), ni les fichiers du package (packages/requirements-kit/README.md, cheatcode.json, .claude-plugin/plugin.json, LICENSE), ni les fichiers de la racine du dépôt, ni l'app installer/. SKILL.md ne nomme aucun service, aucun connecteur et aucun site web. - Un défaut connu à me redire, exactement comme consigné — ne le corrige pas et ne modifie pas le fichier (le modifier briserait son empreinte) : le bloc frontmatter est délimité par des lignes --- et contient exactement deux champs, name: uat-plan et une description sur une seule ligne, mais cette description est un scalaire brut sans guillemets contenant « : » (deux-points suivi d'une espace, après les mots « acceptance criteria »), ce que les parseurs YAML stricts rejettent (« mapping values are not allowed here »). Le champ name lui-même se lit clairement comme uat-plan ; rapporte le frontmatter comme présent mais non valide en YAML strict, tel que consigné dans cette fiche. - 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é. Aucun script n'est exécuté pendant l'installation (il n'y en a aucun), aucune clé n'est demandée, et il n'y a aucune télémétrie dans le dossier. - Ce qui est lu et ce qui quitte cette conversation à l'usage, divulgué ici avant que ça arrive — utiliser le skill est une étape séparée qui ne commence que quand j'apporte des exigences : (a) tout ce sur quoi le skill travaille est du matériel que je fournis dans notre conversation : exigences ou histoires utilisateur avec critères d'acceptation, portée de la livraison, qui sont les utilisateurs d'affaires, et toute contrainte (dates, environnements, restrictions de données). SKILL.md traite tout ça comme des données, pas des instructions ; si des critères d'acceptation manquent, les conditions de test sont dérivées des exigences et marquées comme dérivées. Rien dans le skill n'envoie ce matériel nulle part : il n'y a aucune route réseau, aucun connecteur et aucun service externe dans le fichier. (b) Le résultat reste chez moi : un document de plan UAT (portée, personnes, environnement et données, critères d'entrée et de sortie, règles de défauts, calendrier, registre de signature), puis les scripts sous forme de tableaux, puis la vérification de couverture — le tout produit dans notre conversation ; seulement quand je le demande et que ton installation peut écrire des fichiers, les scripts peuvent aussi être écrits dans un tableur local avec une feuille par processus. Cette écriture de fichier locale optionnelle, sur ma demande seulement, est la seule chose qui sorte jamais de la conversation, et elle va dans un fichier que je choisis — jamais pendant l'installation. (c) Une règle de sécurité de SKILL.md à me redire : ne jamais mettre de données personnelles ou financières réelles dans un script ; décrire plutôt le profil de l'enregistrement, et masquer toute donnée qui doit l'être. - Le reste reste dans notre conversation à l'usage : délimiter la portée par processus d'affaires, assigner les rôles, rédiger les scripts pas à pas dans les écrans et les mots qu'utilisent les gens d'affaires, la vérification de couverture, et la liste des points ouverts pour tout ce qui n'a pas été fourni. Deux autres règles de SKILL.md à me redire : les scripts testent des résultats d'affaires, pas l'implémentation ; et le skill ne marque jamais rien comme réussi — les colonnes de résultats restent vides pour le testeur. - N'utilise pas le skill pendant cette installation : ne rédige aucun plan ni script UAT, et n'écris aucun fichier de plan ni de tableur. 3. Quand je dis « yes, install », installe-le comme skill : copie tout le dossier uat-plan dans le répertoire des skills de l'agent, dans un dossier nommé « uat-plan », en gardant son 1 fichier (SKILL.md à sa racine). Un clone manuel suivi de la copie du dossier packages/requirements-kit/skills/uat-plan dans ~/.claude/skills/ est la route décrite ici ; toute autre route ne convient que si chaque fichier installé correspond à son empreinte. 4. Vérifie sans appels réseau : le 1 fichier en place avec une empreinte concordante, et le frontmatter exactement comme consigné — name lisible comme uat-plan, et le défaut YAML strict connu sur la ligne de description présent et non modifié (ne rapporte pas le frontmatter comme du YAML valide, et ne le corrige pas). N'exécute aucune étape d'usage pour vérifier. 5. Indique ce qui a été installé, où, et ce qu'il me reste à faire moi-même (par exemple : apporter les exigences ou les histoires utilisateur avec critères d'acceptation, la portée de la livraison, qui sont les utilisateurs d'affaires, et toute contrainte — dates, environnements, restrictions de données ; décider les noms ou garder les rôles là où SKILL.md laisse des espaces réservés, et régler moi-même la liste des points ouverts ; signer moi-même à la fin, puisque le skill prépare le registre de signature mais ne signe jamais rien et ne marque jamais rien comme réussi ; utiliser le skill est une étape séparée qui ne commence que quand je le demande, et le traitement à l'usage divulgué ci-dessus arrive seulement à ce moment-là). 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.