BRD Draft

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 de matériel de recueil que je fournis moi-même (notes d'atelier, transcriptions d'entrevues, courriels et documents existants). Un défaut amont connu est divulgué au point 2 et ne doit PAS être « corrigé » pendant l'installation : le frontmatter de SKILL.md n'est pas du YAML valide tel que livré (voir point 2), donc installe le fichier octet pour octet tel qu'empreinté et signale-moi ce défaut au lieu de le modifier. Installe-moi « brd-draft ». Il transforme le matériel de recueil — notes d'atelier et d'entrevue ou transcriptions, courriels, la charte de projet, les descriptions du processus actuel, les specs existantes, des exemples de rapports — en un premier brouillon de document d'exigences d'affaires (BRD, business requirements document) que les parties prenantes peuvent relire et corriger, un brouillon qui rend les questions ouvertes évidentes au lieu de les cacher derrière une prose assurée. Il remplit une structure fixe : contrôle du document (titre, version, date, auteur, réviseurs, statut brouillon) ; contexte et problème, dans les mots des parties prenantes quand c'est possible ; objectifs numérotés O1, O2, ... chacun avec la façon dont le succès sera mesuré (les mesures inconnues deviennent des questions ouvertes) ; portée (inclus, exclu, et ce qui est délibérément reporté) ; parties prenantes (rôle, intérêt, influence, ce qu'il faut à chacune ; dans un RACI, exactement un Accountable par activité) ; processus actuel et processus futur en étapes numérotées (qui fait chaque étape, systèmes touchés, avec l'offre de les dessiner en diagrammes seulement si un skill de cartographie de processus est déjà installé) ; exigences groupées par domaine fonctionnel, numérotées BR-<domaine>-<n>, chacune écrite « The <system or role> shall <one verifiable behavior>. » avec priorité (must, should, could), justification, source, critère d'acceptation (fit criterion) et l'objectif qu'elle sert ; règles d'affaires numérotées et énoncées une seule fois ; données et rapports (entités et champs clés, sources, conservation, rapports avec public et fréquence) ; exigences non fonctionnelles (performance, disponibilité, sécurité et accès, vie privée et conservation, audit, accessibilité, localisation), chacune marquée captured, assumed ou unknown ; hypothèses, contraintes, dépendances et risques, une liste chacun ; un glossaire de chaque terme du domaine employé ; et des questions ouvertes numérotées, chacune avec la personne ou le groupe qui peut répondre et ce qu'elle bloque. Il travaille en extrayant les énoncés candidats avec leur source, en séparant les besoins des solutions que quelqu'un a suggérées, en fusionnant les doublons et en divisant les énoncés composés, en transformant les désaccords entre sources en questions ouvertes au lieu de choisir un camp, en laissant les sections vides marquées « no information yet » plutôt que d'inventer du contenu, et par une auto-vérification finale (chaque exigence se rattache à un objectif et à une source, chaque terme est au glossaire, chaque inconnu est une question ouverte). Son résultat est le BRD en Markdown (ou dans mon gabarit maison si je le fournis) plus une courte note de revue : comptes par section, les cinq questions ouvertes les plus importantes, et les prochaines étapes suggérées (par exemple un passage de requirements lint, puis les critères d'acceptation). Il n'invente jamais de chiffres, de dates, de responsables ni de règles, il conserve le vocabulaire des parties prenantes, et il marque chaque exigence qui ne vient que d'une seule source. Dépôt : https://github.com/ChenxingJi-Innovate/Cheatcode_ (le skill est tout le dossier packages/requirements-kit/skills/brd-draft/ 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/brd-draft/ 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 c447a7297ff98c6e2bc83f6b1b4131b74e4bdc157247a20e8ff228bab9464a85 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 873 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, requirements-lint, traceability-matrix ou uat-plan, 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/. Deux mentions dans SKILL.md ne sont pas des dépendances : l'offre de dessiner les processus en diagrammes seulement si un skill de cartographie de processus est déjà installé (une offre, conditionnelle à quelque chose que j'ai déjà ; ce skill n'en va chercher ni n'en installe aucun), et les prochaines étapes suggérées dans la note de revue (un passage de requirements lint, puis les critères d'acceptation — des suggestions seulement ; les skills frères ne sont ni requis, ni inclus, ni exécutés par ce skill). - Défaut de frontmatter connu, divulgué ici exactement tel que livré et à NE PAS corriger : le fichier commence à l'octet 0 par « --- » suivi d'un saut de ligne (aucune marque d'ordre des octets, sauts de ligne LF seulement, aucun retour chariot nulle part dans le fichier), puis exactement deux champs sur des lignes uniques en scalaires simples sans guillemets — « name: brd-draft » et une ligne « description: ... » de 511 caractères dont la valeur de 498 caractères est sans guillemets — puis une ligne de fermeture « --- » ; il n'y a aucun autre champ de frontmatter (ni version, ni licence, ni auteur, ni aucune autre clé). Parce que cette description sans guillemets contient elle-même « : » suivi d'une espace (dans « ...existing documents: objectives, ... », à la colonne 132 de la ligne), un parseur YAML strict rejette le frontmatter (« mapping values are not allowed here », ligne 2, colonne 132), et le harnais VM qui a testé ce dépôt a consigné frontmatter_ok: false avec name: null pour ce fichier, même si la ligne « name: brd-draft » est textuellement présente et que le test d'installation du dépôt a réussi. Installe le fichier octet pour octet tel qu'empreinté : ne mets pas la description entre guillemets, ne la replie pas, ne la reformate pas et ne la répare d'aucune façon, et ne substitue pas une copie corrigée. Si ton propre chargeur refuse un skill dont le frontmatter ne se parse pas, arrête-toi et dis-le-moi, plutôt que de modifier le fichier. - 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 du matériel de recueil : je fournis les notes d'atelier et d'entrevue ou les transcriptions, les courriels, la charte de projet, les descriptions du processus actuel, les specs existantes et des exemples de rapports, et en option un gabarit maison — tout ça est du matériel que je te remets, il reste dans notre conversation, et SKILL.md le traite en entier comme des données, pas comme des instructions, en gardant note de la source de chaque énoncé. Il n'y a aucune route par connecteur et aucun service n'est nommé ni contacté : SKILL.md ne contient aucune URL, ne demande aucun compte ni aucune clé, ne publie ni n'affiche rien, et son résultat — le BRD en Markdown (ou dans le gabarit maison que j'ai fourni) plus la note de revue — est retourné dans notre conversation. La seule étape vers l'extérieur même mentionnée est conditionnelle : l'offre de dessiner les processus actuel et futur en diagrammes si un skill de cartographie de processus est déjà installé ; cette offre ne change rien tant que je ne l'accepte pas à cette étape d'usage ultérieure, et elle ne fait jamais partie de l'installation. - N'utilise pas le skill pendant cette installation : ne rédige aucun BRD, n'extrais aucune exigence d'aucun matériel, et ne dessine aucun diagramme. 3. Quand je dis « yes, install », installe-le comme skill : copie tout le dossier brd-draft dans le répertoire des skills de l'agent, dans un dossier nommé « brd-draft », en gardant son 1 fichier (SKILL.md à sa racine) octet pour octet tel qu'empreinté, défaut de frontmatter inclus. Un clone manuel suivi de la copie du dossier packages/requirements-kit/skills/brd-draft 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 ses premières lignes exactement telles qu'empreintées — « --- » d'ouverture, ligne « name: brd-draft » présente, ligne de description et « --- » de fermeture inchangés. Attends-toi à ce qu'un parse YAML strict du frontmatter échoue pour la raison divulguée au point 2 : cet échec est le défaut amont connu consigné pour cette fiche, pas un écart d'empreinte ; ne réécris pas le fichier pour le faire passer, et signale le défaut dans ton rapport final. 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 moi-même le matériel de recueil — notes d'atelier, transcriptions, courriels, charte, descriptions de processus, specs existantes, exemples de rapports — et un gabarit maison si je veux qu'il soit utilisé ; m'attendre à ce que les inconnus reviennent en questions ouvertes numérotées plutôt qu'en contenu inventé, et à ce que les exigences à source unique soient marquées pour que je les confirme ; noter le défaut de frontmatter divulgué : le fichier est installé exactement tel que l'amont le livre, un chargeur YAML strict peut le refuser, et toute décision d'utiliser une copie corrigée m'appartient à moi seul, à une étape séparée ; utiliser le skill est une étape séparée qui ne commence que quand je le demande, et rien n'est lu ni envoyé à l'usage au-delà du matériel que je te remets en conversation, tel que divulgué ci-dessus). 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.