🎁 Ce que tu reçois : le prompt complet à coller en premier message, la pile de 7 skills dans l'ordre, les 4 pièges qui coûtent le plus cher, l'arborescence livrée, et la variante du prompt pour Claude Fable 5.1.
Prompt et pile de skills pour reprendre le site vitrine d'un professionnel indépendant (praticien bien-être, artisan, coach, thérapeute, cabinet libéral) qui tourne aujourd'hui sur un éditeur en ligne : Wix, IONOS MyWebsite, Jimdo, un vieux WordPress. Le point commun de ces sites : personne ne récupérera jamais leur code source.
La cible : un site statique, rapide, propre, qui se dépose par FTP chez l'hébergeur actuel du client. Pas de build, pas de framework, rien à maintenir.
1. Le prompt
Colle-le en premier message dans Claude Code. Remplace ce qui est entre chevrons.
Refonte complète du site <URL du site actuel>, celui d'un·e <activité : praticien
bien-être / artisan / coach / …> installé·e à <ville>.
## Contraintes de livraison
- Site 100 % statique : HTML + CSS + JS vanilla + GSAP. Pas de build, pas de framework.
L'hébergement actuel est <IONOS / OVH / Wix / …> : ça doit se déposer tel quel
par FTP, ou sur Netlify, sans étape de compilation.
- Convertible en Next.js plus tard sans rien jeter : CSS autonome, composants indépendants.
- Le site doit rester entièrement lisible sans JavaScript. Aucun contenu masqué en CSS :
les états initiaux d'animation sont posés en JS. Si l'animation ne charge pas,
la page reste complète.
- Une seule feuille CSS, couleurs en tokens OKLCH.
- Pages : <accueil, présentation, témoignages, tarifs/prestations, contact, mentions légales>.
## Étape 1 — Récupérer la matière (ne rien inventer)
1. Lis les <N> pages du site actuel. Sors : tous les textes, la structure,
la promesse commerciale, le ton.
2. Récupère les visuels de marque en pleine résolution : logo, bandeau, photos.
Si le logo n'existe qu'en JPEG sur fond blanc, détoure-le par flood fill depuis
les bords de l'image — jamais par un seuil de luminance, ça troue les reflets clairs
des formes en volume. Passe séparée sur les contre-poinçons des lettres fermées.
3. La palette du nouveau site sort du logo existant. Ne « modernise » pas ces couleurs
sans mon accord : c'est la seule chose que le client reconnaît.
4. Écris `PRODUCT.md` (ce que vend le client, à qui, ce qu'il faut garder de l'existant)
et `tasks/todo.md` avec une section « Bloqué côté client ».
## Étape 2 — Direction artistique : demander AVANT de produire
Ne produis pas plusieurs maquettes à l'aveugle. Pose-moi une seule question, avec
trois références concrètes et nommées, décrites en deux lignes chacune. Par exemple :
« premium sobre », « immersif photo plein écran », « votre bandeau actuel en mieux ».
Je réponds en dix secondes et tu produis une seule direction, la bonne.
Ensuite écris `DESIGN.md` : tokens, typo, grille, motion, composants.
Une direction que je rejette est archivée : on n'y revient jamais.
## Étape 3 — Règles de contenu (non négociables)
- Aucun chiffre inventé : durée d'une prestation, années d'expérience, nombre de clients,
tarifs, délais. Si le chiffre n'est pas sur le site d'origine, il n'existe pas —
il part dans `todo.md` en question au client.
- Aucune allégation réglementée : promesse de résultat, vocabulaire médical ou
thérapeutique, performance chiffrée, comparaison avec la concurrence.
- Signale-moi par écrit tout contenu de l'ancien site qui expose le client
juridiquement, au lieu de le recopier tel quel. Le client tranche, par écrit.
- Chaque page porte son cadre. Mentions légales complètes et à jour.
## Étape 4 — Construire
Une seule pièce interactive forte sur l'accueil, pas six. Tout le reste la sert.
Photos en WebP, dimensionnées. Aucune dépendance superflue.
## Étape 5 — Preuve avant « c'est fait » (obligatoire)
Écris des tests Playwright dans `tests/`, et lance-les tous avant toute annonce :
- reveals d'animation + erreurs console, page par page
- toutes les pages en viewport mobile, contrôle du débordement horizontal
- la pièce interactive de l'accueil : souris ET clavier, desktop ET mobile
- contraste AA. Attention : `getComputedStyle` renvoie l'OKLCH brut, un calculateur
qui parse les nombres sort des ratios faux. Peins la couleur sur un canvas 1×1
et relis le pixel : c'est le navigateur qui convertit.
- contraste du texte posé sur une photo : masque le texte, capture la zone, calcule
le pire ratio sur les pixels réels. Lire le fond via les ancêtres CSS donne « blanc ».
- `prefers-reduced-motion` respecté + cibles tactiles ≥ 44 px
- tout le contenu visible avec JavaScript désactivé
Serveur local : `cd site && python3 -m http.server 8777`.
Aucune tâche n'est « terminée » sans la sortie de ces passes affichée.
## Étape 6 — Capitaliser
À chaque bug résolu ou décision non triviale, ajoute UNE ligne à `tasks/lessons.md` :
la cause en une phrase, puis le fix. C'est ce fichier qui rend le projet suivant plus rapide.
Commence par l'étape 1, et montre-moi ton plan avant d'écrire la moindre ligne de code.
2. La pile de skills
Sept skills, dans cet ordre. Aucun subagent : sur un site de six pages, la parallélisation coûte plus qu'elle ne rapporte.
| Skill | Quand | Ce qu'il apporte |
|---|---|---|
ui-ux-pro-max | avant tout | cadrage : styles, palettes, pairings de fontes, stack |
frontend-design | avant la DA | direction visuelle qui ne sent pas le template |
design-taste-frontend | avant la DA | passe anti-slop, audit du site existant d'abord |
high-end-visual-design | pendant | ce qui fait « cher » : spacing, ombres, cartes, typo |
emil-design-eng | pendant | polish de composant, décisions d'animation, détails invisibles |
gsap-core | animations | API GSAP : tweens, easing, matchMedia, reduced-motion |
impeccable | passe finale | critique d'interface : hiérarchie, états, accessibilité |
Selon le contexte, ajouter redesign-existing-projects si le code source du site actuel est récupérable, plus une passe SEO et une passe accessibilité dédiées avant la mise en ligne.
3. Les quatre pièges qui coûtent le plus cher
Produire des maquettes avant d'avoir demandé une référence
Trois directions rejetées d'affilée, c'est trois fois le même tort : partir de l'esthétique au lieu de partir de ce que le client reconnaît. Une question à trois références règle ça en dix secondes. Voir l'étape 2 du prompt.
Les chiffres inventés
Un modèle qui écrit « 30 ans d'expérience » pour faire sérieux te fait signer un mensonge au nom du client. Tout chiffre non sourcé est une question, pas une phrase. Voir l'étape 3.
Le calculateur de contraste qui lit l'OKLCH comme du RGB
Des ratios de 1.07 partout, ou l'inverse : un site déclaré conforme qui ne l'est pas. Voir l'étape 5.
position: fixed dans un parent qui porte transform ou backdrop-filter
L'élément se positionne par rapport au parent, pas au viewport : sur mobile, le menu se retrouve hors écran. Ne se voit qu'en test mobile réel. Voir l'étape 5.
4. L'arborescence livrée
site/
index.html accueil, avec la pièce interactive
<pages intérieures>.html
mentions.html
assets/css/style.css feuille unique, tokens OKLCH
assets/js/main.js interactions, GSAP
assets/img/ logo détouré, photos WebP
tests/ les passes Playwright
tasks/todo.md actif, < 50 lignes
tasks/lessons.md une ligne par bug résolu
CLAUDE.md les règles du projet, lues à chaque session
DESIGN.md la direction retenue
5. Variante pour Claude Fable 5.1
Le prompt de la partie 1 est écrit en étapes numérotées. C'est le bon format pour un modèle qu'il faut cadrer. Avec Claude Fable 5.1 (claude-fable-5-1), ce cadrage se retourne contre toi : un prompt trop prescriptif fait baisser la qualité de sortie. Le modèle raisonne en continu, ses tours durent longtemps, et il travaille mieux si on lui donne l'objectif, les contraintes dures et la raison, pas la marche à suivre.
| Le prompt de la partie 1 | La variante Fable 5.1 |
|---|---|
| six étapes numérotées | un objectif, des contraintes, des interdits |
| « fais ceci, puis cela » | « voici pour qui c'est et ce que ça doit permettre » |
| liste de tests imposée | « établis ta méthode de vérification et lance-la à intervalle régulier » |
| « ne lance pas de sous-agents » | « délègue les sous-tâches indépendantes et continue pendant » |
⏳ Prévois aussi des tours longs : une seule requête peut travailler plusieurs minutes avant de répondre. Ce n'est pas un blocage.
Le prompt
Je reprends le site d'un·e <activité> installé·e à <ville>. C'est un travail facturé :
le livrable part chez le client, qui n'a aucune compétence technique et restera
sur son hébergement actuel <IONOS / OVH / …>. Ce que le site doit lui permettre :
être trouvé, inspirer confiance, et donner envie de prendre rendez-vous.
Site actuel : <URL>.
Contraintes dures, non négociables :
- HTML + CSS + JS vanilla + GSAP. Aucun build, aucun framework. Le dossier se dépose
par FTP tel quel.
- Le site reste entièrement lisible sans JavaScript. Rien n'est masqué en CSS.
- Une feuille CSS, couleurs en tokens OKLCH, palette dérivée du logo existant.
- Aucun chiffre qui ne figure pas sur le site actuel. Durée de prestation, années
d'expérience, nombre de clients, tarifs : si ce n'est pas sourcé, c'est une question
pour le client, pas une phrase sur la page.
- Aucune allégation réglementée : promesse de résultat, vocabulaire médical, comparaison
avec la concurrence. Si l'ancien site en contient, tu me le signales par écrit
au lieu de le recopier.
Ce que tu ne fais pas :
- Tu ne pars pas sur une direction artistique avant que je l'aie choisie. Quand tu es
prêt à la poser, arrête-toi et propose-moi trois références nommées, deux lignes
chacune. J'en choisis une. Une direction que je rejette est archivée, on n'y revient pas.
- Tu n'ajoutes ni page, ni fonctionnalité, ni abstraction au-delà de ce que le travail
demande. Pas de refactor de confort, pas de gestion d'erreur pour des cas impossibles.
- Quand je pose une question ou que je réfléchis à voix haute, le livrable est ta réponse.
Tu ne modifies rien tant que je n'ai pas demandé.
Vérification :
Établis ta propre méthode de contrôle du rendu réel dans un navigateur — pas seulement
la lecture du code — et relance-la régulièrement pendant que tu construis. Elle doit
couvrir au minimum : le rendu mobile sans débordement horizontal, le contraste réel
du texte y compris posé sur photo, le fonctionnement au clavier, le respect de
`prefers-reduced-motion`, et l'intégralité du contenu avec JavaScript désactivé.
Avant d'annoncer un résultat, vérifie chaque affirmation contre une sortie d'outil
de cette session. Ce que tu n'as pas vérifié, tu le dis. Si un test échoue, tu montres
l'erreur. Une vérification par un sous-agent à contexte neuf vaut mieux que ta propre
relecture.
Délégation :
Délègue les sous-tâches indépendantes et continue à travailler pendant qu'elles tournent.
Interviens si l'une part de travers ou manque de contexte.
Mémoire :
Tiens `tasks/lessons.md` : une leçon par entrée, la cause en une phrase puis le fix.
Corrections comme approches confirmées, avec la raison. N'y note pas ce que le dépôt
enregistre déjà, mets à jour une entrée existante plutôt que d'en créer une seconde,
et supprime celles qui se révèlent fausses. Relis ce fichier au début des sessions suivantes.
Style :
Ouvre tes réponses par le résultat : ce qui s'est passé, ou ce que tu as trouvé.
Le détail vient après. Si tu as travaillé longtemps sans que je regarde, ton message
final est ma première vue sur tout ça : écris-le pour quelqu'un qui n'a rien suivi,
en phrases complètes, sans le vocabulaire que tu t'es fabriqué en chemin.
Commence par lire le site actuel et récupérer la matière. Montre-moi où tu en es
avant d'écrire du code.
Réglages
- Modèle :
claude-fable-5-1. Via l'API, l'intensité se règle avecoutput_config.effort:highpour ce type de chantier,xhighsi la qualité prime,mediumoulowpour les retouches de routine. Sur Fable 5.1, un effort bas reste au niveau duxhighdes générations précédentes. - Ce que Fable 5.1 apporte ici : une première implémentation complète et correcte d'un système bien spécifié, la navigation dans l'ambigu, et la délégation en parallèle. C'est exactement la forme de ce travail.
- Ce qu'il faut surveiller : à effort élevé, il peut ranger et généraliser au-delà de la demande. D'où le paragraphe « ce que tu ne fais pas ».