Build

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, lis ceci d'abord : ses trois outils livrés n'exigent que Python 3 (bibliothèque standard seulement, rien à installer par pip). Le travail autour d'eux peut impliquer, seulement quand une étape en a vraiment besoin et seulement comme divulgué au point 2 : un vrai navigateur pour les captures d'écran, ou Playwright via npx (un premier lancement de Playwright peut télécharger Chromium, environ 150 Mo) ; Node pour les tests de logique optionnels (node --test) ; et, si je choisis de déployer, mon propre compte d'hébergement chez Netlify, Vercel, Cloudflare Pages ou GitHub Pages — je le crée et je m'y connecte moi-même, ne me demande jamais mon mot de passe et ne le tape jamais, les paliers gratuits sont le défaut du skill, et tout domaine, palier payant, service de formulaire, Stripe ou Supabase est un choix séparé que je fais à partir du cahier des charges, jamais une exigence de ce skill. Je fournis le contenu réel moi-même : mes mots, mes photos, mes prix et mes preuves — le skill interdit d'inventer des témoignages, des chiffres ou des allégations, et tout ce qui manque est marqué, pas fabriqué. Installe-moi « build ». Il mène un propriétaire non technique de « je veux un site web ou une application qui fait X » à un produit réel et en ligne, en six étapes : (1) clarifier et écrire un cahier des charges d'une page en langage clair, et obtenir un oui ; (2) choisir la pile la plus simple qui fonctionne (HTML/CSS simple d'abord, des services hébergés de formulaire ou de paiement au lieu d'un serveur, un générateur statique seulement passé environ 10 pages de contenu, Next.js/Vite + Supabase sur Vercel seulement quand des comptes et des données partagées sont vraiment requis) ; (3) s'engager sur une direction de design avant tout code — une fiche de direction, des jetons nommés de type/couleur/espace/forme/mouvement en propriétés CSS personnalisées, et un contrôle anti-motifs, prouvés par des chiffres de contraste ; (4) construire en 3 à 8 petites tranches vérifiées, en échafaudant un projet site/, en roulant un aperçu local, en vérifiant après chaque tranche, en sauvegardant des points de sauvegarde git, et en écrivant un test qui échoue avant toute logique qui calcule, valide, filtre ou transforme ; (5) QA dans un vrai navigateur à 375, 768 et 1440, corrections par ordre de sévérité, re-vérification, deux rondes complètes maximum ; (6) livrer seulement après m'avoir demandé, vérifier le site en ligne, et remettre une note README en langage clair. Trois listes de contrôle (design, qa, ship) et trois outils Python l'accompagnent : serve.py (serveur d'aperçu local), sitecheck.py (robot d'exploration/vérification de site) et contrast.py (contraste WCAG). Dépôt : https://github.com/Jakeschincariol/master-skills (le skill est tout le dossier skills/build/ au commit épinglé : SKILL.md plus ses dossiers checklists/ et tools/, 8 fichiers) Version épinglée : installe le code au commit b5b43e44f0a976ad25bda5095a94c161aab2f086 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/Jakeschincariol/master-skills dans un dossier temporaire, place-toi au commit b5b43e44f0a976ad25bda5095a94c161aab2f086, et copie le dossier skills/build/ 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 e738a0f7fc1ee270e0a96756c5c6bdf8e3610e365f3ecb58a01788f861459340 - checklists/design.md: SHA-256 9e10e7ea57ee639c93786198584b023fea1c92ca86e8dc4c9647858f32b45f5b - checklists/qa.md: SHA-256 96dec757992214448445e2a3ab0de91a6e7ce0fd3a0b491e58fa6f4fb8e4d4c9 - checklists/ship.md: SHA-256 ee77c6cb0a9ee772d605874c79320191b59c0ac093f2a8a54f12d65c804be6f6 - tools/contrast.py: SHA-256 bddb2ef833623adc1cb716ea10868b338108324aa898176156dc3e56c74ea93c - tools/serve.py: SHA-256 88a0f6ce916d41ea855c232644e53515b80136143b0684b93009fe767a48c091 - tools/sitecheck.py: SHA-256 8f30c94fb77defa7cb09990c4fb4ec578507d5d95594ec18a5bc0c7c5ac5fe6f - tools/test_build.py: SHA-256 bb0847daa5e00d2f529a98f9490dd1085e1f58033586031ff877b146279fcb5a 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, lis les trois listes de contrôle de checklists/ (design.md, qa.md, ship.md) et lis les quatre fichiers Python de tools/ (contrast.py, serve.py, sitecheck.py, test_build.py), et dis-moi en mots simples : ce que le skill fait quand on l'utilise, à quels services il se connecte, 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 des fichiers : - Le dossier du skill contient 8 fichiers seulement : SKILL.md (17 528 octets), trois listes de contrôle dans checklists/ (design.md 6 458 octets, qa.md 4 825 octets, ship.md 3 693 octets) et quatre fichiers Python dans tools/ (contrast.py 15 906 octets, serve.py 13 864 octets, sitecheck.py 63 123 octets, test_build.py 15 520 octets). Le skill est autonome dans son propre dossier : SKILL.md n'appelle que les outils et les listes assis à côté de lui, sitecheck.py importe serve.py de son propre dossier tools/ quand il sert un dossier lui-même, et test_build.py importe contrast, serve et sitecheck de ce même dossier. Il n'a besoin d'aucun fichier d'ailleurs dans le dépôt — ni les deux autres skills (edit, virality), ni le README, ni les fichiers de plugin. Les quatre fichiers Python n'utilisent que la bibliothèque standard de Python 3. - 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, aucune clé n'est demandée, et il n'y a aucune télémétrie dans le dossier. Les outils ne lisent jamais de variables d'environnement, de clés API, de mots de passe ou de fichiers d'identifiants : SKILL.md et checklists/ship.md disent le contraire — ne jamais demander ni taper mon mot de passe, les secrets ne vont jamais dans le code frontal, et toute clé API dont un projet a besoin vit dans les réglages d'environnement de l'hébergeur, réglée par moi, jamais dans le HTML/JS ni dans le dépôt git. - Ce qui quitte cette machine à l'usage, divulgué ici avant que ça arrive — utiliser le skill est une étape séparée qui ne commence que quand je te demande de construire ou de vérifier un site : (a) contrast.py ne touche jamais au réseau : il calcule les ratios WCAG localement à partir de couleurs ou d'un fichier CSS que je lui désigne, et il ne lit que ce fichier. (b) serve.py est un serveur d'aperçu local : par défaut il écoute sur 127.0.0.1 seulement (port 8000 d'abord) et sert le dossier site/ aux navigateurs de cette machine, avec des en-têtes sans cache, des plages d'octets et mon 404.html ; avec --lan il écoute sur 0.0.0.0 à la place, donc quiconque sur le même Wi-Fi peut ouvrir le site à l'adresse LAN affichée pendant qu'il roule — c'est une exposition sur le réseau local, pas un envoi internet, et ça n'arrive que si ce drapeau est utilisé ; --open ouvre en plus l'URL locale dans mon navigateur par défaut. (c) sitecheck.py explore avec de simples requêtes GET/HEAD (urllib de Python, User-Agent « sitecheck/1.0.0 (+https://github.com/Jakeschincariol/master-skills) », aucun corps, aucune clé) : sur un dossier local il démarre serve.py sur 127.0.0.1 lui-même et chaque requête reste sur cette machine ; sur une URL que je lui donne, il récupère les pages et les ressources de même origine de ce site (profondeur 3 par défaut, limite 100 pages) plus un contrôle /favicon.ico, donc le serveur de ce site voit des requêtes de pages ordinaires depuis mon adresse ; seulement avec --external envoie-t-il aussi des requêtes GET/HEAD à chaque URL externe de lien et de ressource trouvée dans le site — sans --external, les URL externes sont comptées et sautées, jamais contactées. Il n'exécute pas de JavaScript et ne soumet jamais de formulaires. --report FICHIER ou --json écrit son rapport localement. (d) test_build.py est la suite de tests des outils eux-mêmes, pas une partie du flot normal : si elle roule un jour, elle ne travaille que contre des dossiers temporaires et des serveurs qu'elle démarre sur 127.0.0.1, et elle roule la CLI sitecheck.py comme sous-processus local. (e) Construire un site écrit des fichiers localement — la structure du projet (site/ : index.html, styles.css, app.js et logic.js, img/, fonts/, 404.html, favicon.svg ; tests/ ; README.md) — et utilise des commandes shell locales : les python3 tools/serve.py, python3 tools/sitecheck.py et python3 tools/contrast.py ci-dessus, git init une fois plus git add -A / git commit après chaque tranche (points de sauvegarde, locaux seulement, aucun distant sauf si une route de déploiement ci-dessous en ajoute un), et node --test tests/ pour les tests de logique quand Node est présent (ou une page tests.html locale quand il ne l'est pas). (f) QA navigateur : avec un outil navigateur, des captures à 375x812, 768x1024 et 1440x900 de l'aperçu local ou, après déploiement, de l'URL en ligne ; sans outil, npx playwright screenshot récupère ces mêmes URL, npx télécharge le paquet Playwright s'il manque, et checklists/qa.md avertit qu'un premier lancement peut exiger npx playwright install chromium, un téléchargement d'environ 150 Mo — dis-le-moi avant de le rouler. (g) Livraison, seulement après que tu me l'as demandé et que j'ai dit oui, parce que ça publie sur l'internet public : je crée mon propre compte d'hébergement et je m'y connecte moi-même, puis exactement une route de déploiement roule et téléverse tout le dossier site/ — avec mon contenu réel, mes photos et mes prix dedans — chez l'hébergeur que j'ai choisi : npx netlify-cli deploy --dir=site --prod (Netlify), npx vercel --prod (Vercel), npx wrangler pages deploy site (Cloudflare Pages), gh repo create --public --source=. --push plus l'activation de Pages (GitHub Pages : le code du projet est poussé dans un dépôt GitHub public), ou aucun téléversement de ta part : un zip local de site/ que je glisse-dépose moi-même chez l'hébergeur. Chaque route npx télécharge aussi le paquet CLI de cet hébergeur s'il manque. Un domaine personnalisé, si j'en ajoute un, signifie des enregistrements DNS que je règle chez mon registraire. Après le déploiement, la vérification envoie ce que les points (c) et (f) décrivent contre l'URL en ligne, plus une vraie soumission de formulaire de test : cette soumission envoie l'entrée de test là où mon formulaire est branché pour aller. (h) Les choix de pile que le cahier des charges peut ajouter, chacun ma décision et chacun ne recevant des données que parce que le site fini l'utilise, jamais parce que les outils livrés le font : un service de formulaire (Netlify Forms via data-netlify="true", ou Formspree) reçoit les soumissions de formulaires de mes visiteurs ; Stripe Payment Links ou Checkout (hébergé par Stripe, jamais de champs de carte construits par le skill) reçoit le paiement d'un visiteur quand il paie ; Supabase (auth et Postgres) et l'hébergement Vercel seulement pour une vraie application avec comptes et données partagées ; un générateur statique (Astro ou Eleventy) seulement pour un blog ou un site de contenu passé environ 10 pages. Polices : Google Fonts avec display=swap et un preconnect, ou des woff2 auto-hébergés — si Google Fonts est choisi, le navigateur d'un visiteur récupère les polices chez Google quand il ouvre le site fini. (i) Le tableau « Credits and going deeper » à la fin de SKILL.md nomme quatre skills tiers OPTIONNELS qui ne font pas partie de cette installation et ne sont pas requis pour utiliser build (impeccable via npx impeccable install ou un ajout de marketplace de plugin, le frontend-design d'Anthropic via une installation de plugin, gstack via git clone https://github.com/garrytan/gstack.git dans ~/.claude/skills/gstack suivi de l'exécution de son script ./setup, et superpowers via une installation de plugin) : ne roule aucun de ceux-là pendant cette installation ni comme partie de l'utilisation de build ; si je demande un jour l'un d'eux séparément, il téléchargerait — et pour gstack, exécuterait — du code tiers, et on le vérifierait d'abord. - N'exécute aucun des quatre fichiers Python pendant cette installation, ne démarre pas le serveur d'aperçu, n'explore aucun site, n'échafaude aucun projet, n'installe ni Playwright, ni paquets Node, ni aucune CLI de déploiement, et ne déploie ni ne publie rien : tout ça, c'est l'usage, plus tard, seulement quand je demande un site. 3. Quand je dis « yes, install », installe-le comme skill : copie tout le dossier build dans le répertoire des skills de l'agent, dans un dossier nommé « build », en gardant ses 8 fichiers (SKILL.md à sa racine, les trois listes de contrôle dans son sous-dossier checklists/ et les quatre fichiers Python dans son sous-dossier tools/). Un clone manuel suivi de la copie du dossier skills/build 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 : frontmatter valide (name: build), les 8 fichiers en place avec des empreintes concordantes. N'exécute pas contrast.py, serve.py, sitecheck.py ou test_build.py pour vérifier. 5. Indique ce qui a été installé, où, et ce qu'il me reste à faire moi-même (par exemple : apporter l'idée et le contenu réel — mots, photos, prix, preuves — et répondre aux 3 à 5 questions du cahier des charges et approuver le cahier et la direction de design ; créer mon propre compte d'hébergement et m'y connecter moi-même si je déploie, et décider moi-même l'hébergeur, tout domaine personnalisé et tout palier payant ; régler moi-même toute clé API dont un projet a besoin dans les réglages d'environnement de l'hébergeur, jamais dans le code frontal ; choisir moi-même toute route de service de formulaire, Stripe ou Supabase à partir du cahier des charges, en sachant que ses données y vont comme divulgué ci-dessus ; utiliser le skill est une étape séparée qui ne commence que quand je le demande, et les envois à l'usage divulgués ci-dessus arrivent seulement à ce moment-là, sur la route qui roule). 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.