Transformer Claude Code en chaîne de production avec mes Claude Skills Art of Dev

À force d'utiliser Claude Code tous les jours sur des projets web, je me suis rendu compte d'une chose : je tapais toujours les mêmes consignes. « N'oublie pas de vérifier les menus », « ne pousse pas sur GitHub sans validation », « ne mets pas un design générique IA », « écris du vrai contenu SEO, pas du remplissage ». À chaque nouveau projet, je devais rejouer la même partition.

Au bout d'un moment, j'ai arrêté de copier-coller mes prompts dans un coin. J'ai transformé ces consignes en skills réutilisables, versionnés sur GitHub, que Claude Code peut charger automatiquement quand le contexte le justifie. Ce repo s'appelle claude-skills-artofdev et il regroupe sept skills que j'utilise vraiment, sur de vrais projets, en production.

Cet article explique ce qu'est un Claude Skill, pourquoi j'ai construit cette collection, comment l'installer, et — surtout — comment l'utiliser sans tomber dans le piège du « gros prompt qui fait tout ».

C'est quoi un Claude Skill ?

Un Claude Skill, c'est juste un dossier. Pas un plugin, pas un binaire, pas un service externe. Un dossier avec un fichier SKILL.md dedans, et éventuellement des références, des templates ou des scripts.

my-skill/
├── SKILL.md
├── references/
├── templates/
└── scripts/

Le SKILL.md contient une description courte (« quand utiliser ce skill »), des règles, et parfois un workflow. Claude Code lit d'abord juste le nom et la description du skill ; il ne charge le contenu complet que si la demande de l'utilisateur correspond.

La différence avec un prompt classique tient en une phrase :

Un prompt répond à une demande. Un skill structure une manière de travailler.

Un prompt, tu le tapes une fois et tu l'oublies. Un skill, tu l'écris une fois et tu le réutilises sur tous tes projets, tu le versionnes, tu l'améliores, tu le partages.

Pourquoi j'ai créé Claude Skills Art of Dev

Je travaille sur beaucoup de choses en parallèle : sites vitrines, SaaS, outils internes, contenus SEO, audits de sécurité, refontes UX, traductions. Avec Claude Code, je gagnais énormément de temps sur l'écriture du code, mais je perdais ce temps ailleurs : à répéter les mêmes garde-fous.

Concrètement, voici les consignes que je devais redonner à chaque session :

• Ne jamais commiter de fichier .env ou de secret.
• Ne jamais pousser sur GitHub sans mon accord explicite.
• Vérifier que les menus et les footers sont cohérents sur tout le site.
• Éviter le design « IA générique » qu'on voit partout (gros gradient violet, blocs floutés, hero sans fin).
• Écrire du vrai contenu SEO, avec une intention de recherche claire, pas du remplissage.
• Documenter le projet correctement, sans inventer de fichiers.
• Respecter la stack existante au lieu d'imposer un framework parallèle.

L'objectif de Claude Skills Art of Dev, c'est de transformer cette méthode de travail personnelle en système réutilisable. Pas une théorie, pas un framework abstrait : ce sont littéralement les règles que j'applique quand je livre un projet à un client.

Les limites des prompts classiques

Avant les skills, j'avais essayé plusieurs approches. Elles avaient toutes le même problème.

Les prompts trop longs. Tu écris un méga-prompt avec toutes tes règles, tu le colles au début de la session, et au bout de quelques échanges Claude commence à les oublier — surtout les règles qui n'ont rien à voir avec la tâche en cours.

Les instructions oubliées. Tu as bien dit « ne pousse pas sur GitHub », mais 30 messages plus tard, dans une autre tâche, l'instruction a été noyée par tout le reste.

Le contexte perdu entre projets. Tu changes de repo, tu changes de session, tu repars de zéro. Toutes tes consignes sont à retaper.

Trop d'informations en une seule fois. Tu mélanges design, SEO, audit, sécurité, GitHub, traduction dans le même prompt. Claude perd la hiérarchie de tes priorités.

Le risque : Claude ne sait plus si la tâche du moment est « écrire du contenu SEO » ou « auditer la sécurité ». Il fait un mélange des deux, mal.

L'approche token-conscious

Un bon skill est spécialisé. Il fait une chose, il la fait bien, et il ne pollue pas le contexte avec ce qui ne le concerne pas.

L'idée clé : Claude ne doit pas tout charger tout le temps. Le mécanisme suit une logique simple :

1. Claude lit d'abord le nom et la description du skill (quelques tokens).
2. Il charge le SKILL.md complet uniquement si la demande correspond.
3. Il charge les references/ ou templates/ seulement si le SKILL.md le demande.

Concrètement, ça veut dire qu'avoir 7 skills installés ne « coûte » presque rien tant que tu ne les déclenches pas. Tu peux donc en avoir beaucoup sans dégrader la qualité des réponses sur des tâches simples.

Les avantages de cette approche :

• Moins de tokens consommés — donc moins cher et plus rapide.
• Moins de bruit — Claude ne mélange pas les contextes.
• Meilleure précision — chaque skill est focalisé sur son sujet.
• Meilleure maintenance — tu modifies un skill sans casser les autres.

Les 7 skills de la collection

La collection contient sept skills, chacun pensé pour un moment précis du cycle de vie d'un projet web.

repo-builder

Sert à créer un repo propre dès le départ. Il génère un README clair, un .gitignore adapté à la stack, une structure de dossiers cohérente, des règles de sécurité de base, et il prépare les commandes Git utiles. Ce qu'il ne fait pas : pousser sur GitHub sans validation. Tu restes maître du remote.

Cas typique : tu démarres un nouveau projet, tu veux éviter le « repo bordélique » qui te poursuivra pendant six mois.

production-auditor

Sert à vérifier qu'un projet est prêt pour la production avant publication. Il passe en revue : sécurité, UX, SEO, contenu, espace admin, billing, gestion des erreurs, présence de secrets oubliés, et il fournit un scoring final.

Cas typique : tu vas mettre un site en ligne ou tournes une vidéo de démo, et tu ne veux pas découvrir un console.log("test") en prod ou un endpoint admin sans authentification.

premium-webdesigner

Sert à éviter les designs génériques produits par IA. Tu sais, le hero sombre avec dégradé violet, les six cartes alignées sur fond gris clair, le footer à trois colonnes identiques. Ce skill produit des refontes plus premium, cohérentes avec la stack existante, sans tout casser pour réinventer la roue.

Cas typique : ton site fait « template » et tu veux une vraie identité visuelle sans embaucher un designer.

seo-content-engine

Sert à écrire du contenu SEO qui a vraiment une raison d'exister. Il insiste sur l'anti-bullshit : pas de remplissage, pas de phrases vides du type « dans un monde où l'IA transforme tout », pas de titre H2 décoratif sans contenu derrière. Il travaille à partir d'une intention de recherche claire et d'exemples concrets.

Cas typique : tu veux écrire un article qui se lit, qui est utile, et qui a une chance de remonter sur Google parce qu'il répond à une vraie question.

site-ux-guardian

Sert à vérifier la cohérence globale d'un site. Il regarde les menus, les footers, les routes, les composants dupliqués, le responsive, la cohérence entre front-office et back-office. C'est le skill que tu lances quand tu te dis : « est-ce que mon site est encore cohérent après six refactos ? ».

Cas typique : tu as ajouté trois pages, modifié deux composants, refait la nav, et tu veux que quelqu'un vérifie que rien n'est cassé ailleurs.

multilingual-site-engine

Sert à rendre un site multilingue proprement. Il gère les langues cibles, les variables, les placeholders, les slugs, le SEO multilingue, les menus, les footers, les formulaires et même les emails transactionnels. Il sait que {{user_name}} ne doit pas être traduit.

Cas typique : tu passes un site de FR à FR/EN/DE et tu ne veux pas qu'une variable JSX se retrouve traduite par accident.

skill-orchestrator

Sert à choisir le bon skill au bon moment, sans charger toute la collection automatiquement, et à demander confirmation avant de combiner plusieurs gros skills. C'est le « chef d'orchestre » : il évite que Claude lance trois skills lourds en parallèle pour une tâche qui n'en demandait qu'un.

Cas typique : tu poses une demande ambiguë (« améliore ce site »), et tu veux que Claude te dise quels skills il compte utiliser avant de foncer.

Comment installer la collection

L'installation prend trois commandes :

git clone https://github.com/mrjonk/claude-skills-artofdev.git
cd claude-skills-artofdev
bash install.sh

Le script copie chaque skill vers ~/.claude/skills/, avec sauvegarde automatique si un skill du même nom existe déjà.

Pour vérifier que tout est en place :

ls -la ~/.claude/skills
find ~/.claude/skills -maxdepth 2 -name SKILL.md -print

Tu dois voir sept dossiers, chacun avec son SKILL.md.

Comment utiliser les skills

Tu n'as rien à activer manuellement. Une fois les skills installés, Claude Code les détecte automatiquement et choisit lequel charger selon le contexte de ta demande.

Quelques exemples de prompts qui déclenchent naturellement un skill :

• Crée un repo propre pour un mini CMS PHP/SQLite. → repo-builder
• Audite ce projet avant mise en production. → production-auditor
• Ce site fait trop template WordPress, rends-le plus premium. → premium-webdesigner
• Écris un article SEO complet sur l'installation de Claude Code pour débutants. → seo-content-engine
• Vérifie que les menus, footers et routes sont cohérents sur tout le site. → site-ux-guardian
• Traduis tout le site en anglais et allemand sans casser les variables. → multilingual-site-engine
• Quel skill dois-je utiliser pour cette demande ? → skill-orchestrator

Tu peux aussi demander explicitement : « utilise le skill production-auditor sur ce repo ». Claude le chargera et appliquera ses règles.

Exemple concret : créer un mini CMS propre

Imaginons que tu veuilles créer un mini CMS en PHP/SQLite, avec un back-office simple et un site public. Voici un workflow réaliste, skill par skill.

1. repo-builder — Tu démarres avec un repo propre : README, .gitignore qui exclut .env, structure de dossiers (public/, admin/, data/), commandes Git initiales préparées mais pas exécutées.
2. premium-webdesigner — Tu travailles l'interface du back-office et du front pour qu'elle ne ressemble pas à un template Bootstrap brut.
3. site-ux-guardian — Tu vérifies que la navigation, les retours d'erreur et les états de chargement sont cohérents entre les pages publiques et l'admin.
4. production-auditor — Avant publication ou avant d'enregistrer une démo vidéo, tu lances un audit final : pas de mot de passe en dur, pas de route admin sans authentification, headers de sécurité présents.

Pourquoi c'est plus propre qu'un gros prompt unique ? Parce que chaque étape est vérifiable. Tu sais ce que Claude est censé faire, tu peux relire son travail à chaque étape, et tu n'as pas un seul gros bloc de réponse difficile à auditer.

Exemple concret : refonte d'un site existant

Cas typique : un site qui marche mais qui a vieilli. La tentation est de demander à Claude « refais tout ». Mauvaise idée. Voici une approche plus sûre.

1. premium-webdesigner en premier, pour le design — mais avec une consigne claire : « propose un plan avant de toucher au code ». Tu valides la direction visuelle.
2. site-ux-guardian ensuite, pour vérifier que les composants existants restent cohérents après les changements de design.
3. production-auditor en dernier, juste avant la mise en ligne, pour t'assurer qu'aucune régression de sécurité ou de contenu ne s'est glissée.

L'erreur classique : lancer les trois en même temps. Tu te retrouves avec un design refait, des composants déplacés, et un audit qui pointe des problèmes que tu ne sais plus si c'est toi, le designer skill, ou le ux guardian qui les a introduits.

Exemple concret : rendre un site multilingue

Une traduction propre, ce n'est pas seulement traduire les textes. Une vraie internationalisation touche aux variables, aux shortcodes, aux fragments JSX/PHP, aux slugs d'URL, aux metadata SEO, aux emails transactionnels, et aux formulaires.

Exemple typique de variable à ne pas casser :

<p>Bonjour {{user_name}}, votre commande #{{order_id}} a été expédiée.</p>

Si Claude traduit ça « bêtement », tu te retrouves avec {{nom_utilisateur}} dans le template anglais. La variable n'est plus reconnue par le moteur, l'email part avec {{user_name}} brut visible par le client, et tu passes ta soirée à comprendre pourquoi.

Le skill multilingual-site-engine connaît ces pièges. Il sait reconnaître les placeholders, les balises de framework, les attributs id/class, et il maintient une liste explicite de ce qui ne doit jamais être traduit.

Les avantages de cette approche

Après plusieurs mois d'utilisation sur de vrais projets, voici ce qui change concrètement :

• Moins de répétition. Je ne retape plus mes règles à chaque session.
• Plus de cohérence. Mes projets respectent les mêmes garde-fous, peu importe quand je les commence.
• Meilleure sécurité. Les règles « pas de .env commité, pas de push sans validation » ne se perdent plus dans le contexte.
• Moins de tokens. Chaque skill est chargé seulement quand utile.
• Meilleure maintenabilité. Quand j'améliore une règle, je l'améliore une fois, pas vingt.
• Workflows versionnés. Les skills vivent sur GitHub, donc je peux suivre leur évolution, revenir en arrière, accepter des contributions.
• Meilleure qualité de production. Le production-auditor a déjà rattrapé plusieurs oublis bêtes avant mise en ligne.
• Plus facile à partager. Si un freelance ou une agence veut adopter ma méthode, il clone le repo. Pas de doc de 40 pages à lire.

Les limites honnêtes

Un skill n'est pas une solution miracle. Quelques limites à garder en tête :

• Un skill ne remplace pas un expert. Il aide à structurer le travail, pas à le penser à ta place.
• Claude peut encore se tromper. Les skills réduisent les erreurs, ils ne les éliminent pas.
• Il faut relire les changements. Toujours. Surtout sur les fichiers critiques.
• Il faut tester chaque skill sur de vrais projets avant de le considérer comme stable.
• Il ne faut jamais laisser l'IA pousser ou supprimer sans validation explicite — même avec un skill qui dit « ne pas pousser sans accord ».
• La v1.0 de la collection demande encore à être éprouvée sur plus de cas réels avant d'être considérée comme « stable » au sens strict.

Conclusion

Le vrai sujet, ce n'est pas seulement « comment écrire de meilleurs prompts ». C'est comment construire une méthode de travail IA réutilisable, qui ne dépend pas de ta mémoire ou de ton humeur du jour.

Un prompt répond à une demande. Un skill structure une manière de travailler.

C'est exactement ce que j'ai essayé de faire avec Claude Skills Art of Dev : transformer mes garde-fous personnels en outils réutilisables, partageables, améliorables.

Si tu veux découvrir la collection, le repo est ici : github.com/mrjonk/claude-skills-artofdev. Le README contient tous les détails d'installation et la liste à jour des skills. Les contributions et retours sont bienvenus — c'est aussi ça l'intérêt d'avoir mis tout ça en open source.