Skills · guide

Coder comme un senior

Agent Skills : 24 skills gratuites qui font suivre à Claude le cycle complet d'un ingénieur, du cadrage à la mise en ligne. L'installation, la liste traduite, et le mécanisme que personne ne remarque.

Lecture 12 min Niveau débutant Mis à jour le 8 septembre 2026

i am rankMon outil Sois la marque que recommande. Mesure et améliore ta visibilité IA dans ChatGPT, Gemini et les autres moteurs de recherche. Et transforme leurs réponses en clients. 100 % gratuitAnalyser ma marque Sans carte. Ton premier score en 2 minutes.

Pourquoi ton agent saute des étapes

Tu demandes une fonctionnalité. L'agent écrit du code qui marche. Trois jours plus tard tu découvres qu'il n'y a pas de tests, que les erreurs ne sont pas gérées, que la clé d'API est en clair dans le dépôt, et que personne ne sait pourquoi ce fichier existe.

Ce n'est pas un défaut de compétence. Un modèle optimise pour la réponse qui satisfait la demande telle qu'elle est formulée. Tu as demandé « fais marcher ça », il a fait marcher ça. Les étapes qu'un ingénieur senior fait sans qu'on lui demande (cadrer avant de coder, découper, tester au fur et à mesure, relire, préparer la mise en ligne) ne sont dans aucune de tes phrases.

Agent Skills, ce que c'est exactement

Dépôt : github.com/addyosmani/agent-skills. Licence MIT, gratuit, lisible en entier.

C'est un pack de 24 skills (plus une méta-skill qui joue le chef d'orchestre), écrit par Addy Osmani. Il a passé plus de quatorze ans chez Google, et son dernier poste là-bas était directeur chez Google Cloud AI. Le pack encode les pratiques d'ingénierie qu'il a vues appliquées à cette échelle.

Trois choses le distinguent d'un gros prompt « comporte-toi comme un ingénieur senior ».

1. Chaque skill est une procédure, pas un conseil

   Une skill ne dit pas « pense à tester ». Elle donne les étapes, l'ordre, et ce qui doit être vrai pour passer à la suivante. La skill de tests impose Rouge-Vert-Refactor et une pyramide 80/15/5 ; celle de revue impose un découpage en changements d'environ 100 lignes.

2. Il y a des barrières de vérification

   Le pack exige des preuves avant de continuer : la sortie des tests, le résultat du build, des données réelles d'exécution. Pas « j'ai vérifié », mais la trace.

3. La bonne skill se déclenche toute seule

   La méta-skill using-agent-skills lit ta demande et route vers le bon protocole. Tu écris « corrige ce bug » et c'est la skill de débogage qui prend, sans que tu la nommes.

L'installation

Deux méthodes, selon ton outil.

Avec le CLI skills : le plus simple, et ça marche aussi avec Cursor, Codex, Gemini CLI et les autres agents qui lisent les fichiers SKILL.md :

npx skills add addyosmani/agent-skills

En plugin Claude Code : tu récupères en plus les commandes en barre oblique :

/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills

Redémarre ta session après l'installation : les skills sont lues au démarrage.

Les 9 commandes

Chacune correspond à un moment du cycle. La colonne de droite est le principe que la commande applique : c'est elle qu'il faut retenir, pas la syntaxe.

• /spec : définir quoi construire. Le principe : la spécification avant le code.
• /plan : planifier comment. Des tâches petites et atomiques.
• /build : construire par tranches. Une tranche à la fois.
• /test : prouver que ça marche. Les tests sont la preuve.
• /constraints : poser le niveau d'exigence. On le décide une fois, on l'applique partout.
• /review : relire avant de fusionner. Améliorer la santé du code.
• /webperf : auditer la performance web. Mesurer avant d'optimiser.
• /code-simplify : simplifier. La clarté plutôt que l'astuce.
• /ship : mettre en production. Plus vite est plus sûr.

Les 24 skills, par étape

Toutes, traduites et regroupées comme dans le dépôt, avec le moment où chacune se déclenche.

Le chef d'orchestre

• using-agent-skills. Lit ta demande, choisit le protocole qui s'applique, et pose les règles communes à toutes les autres. C'est elle qui fait que tu n'as jamais à nommer une skill.

Cadrer : avant la première ligne de code

• interview-me. Un entretien, une question à la fois, jusqu'à cerner ce que tu veux vraiment à environ 95 % de certitude. Se déclenche quand ta demande est trop vague.
• idea-refine. Ouvre le champ des possibles, puis referme : une idée floue devient une proposition concrète. Pour un concept encore brut.
• spec-driven-development. Écrit un cahier des charges (objectifs, commandes, structure, style de code, tests, limites) avant tout code. Pour un nouveau projet ou un changement important.
• constraint-driven-development. T'interroge sur ton niveau d'exigence, écrit CONSTRAINTS.md, et repère les agents qui désactivent les contrôles. Quand rien n'est écrit ou que la qualité baisse.

Planifier

• planning-and-task-breakdown. Découpe la spécification en tâches petites et vérifiables, avec des critères d'acceptation et un ordre de dépendances. C'est cette skill qui produit le plan avec ses points de contrôle.

Construire

• incremental-implementation. Des tranches verticales fines : implémenter, tester, vérifier, valider, avec des drapeaux de fonctionnalité et des valeurs par défaut sûres. Dès qu'un changement touche plus d'un fichier.
• test-driven-development. Rouge-Vert-Refactor, pyramide de tests 80/15/5, tailles de tests, DAMP plutôt que DRY, et la règle Beyoncé (« si tu y tenais, tu aurais dû mettre un test dessus »). Pour toute logique ou correction de bug.
• context-engineering. Donne à l'agent la bonne information au bon moment, via les fichiers de règles et les intégrations MCP. Au démarrage d'une session ou quand la qualité chute.
• source-driven-development. Ancre chaque décision de framework dans la documentation officielle : vérifier, citer la source, signaler ce qui ne l'est pas. Quand tu veux du code sourcé.
• doubt-driven-development. Relecture adverse en contexte neuf, selon le protocole AFFIRMER → EXTRAIRE → DOUTER → RÉCONCILIER → ARRÊTER, avec escalade possible vers un autre modèle. Pour les enjeux sérieux : production, sécurité, code inconnu.
• frontend-ui-engineering. Architecture de composants, système de design, gestion d'état, adaptatif, accessibilité WCAG 2.1 AA. Pour toute interface visible par un utilisateur.
• api-and-interface-design. Conception par contrat, loi de Hyrum, règle d'une seule version, sémantique des erreurs, validation aux frontières. Pour une API ou une interface publique.

Vérifier

• browser-testing-with-devtools. Passe par le MCP Chrome DevTools pour lire des données réelles d'exécution : DOM, console, réseau, profilage. Pour tout ce qui tourne dans un navigateur.
• debugging-and-error-recovery. Triage en cinq temps (reproduire, localiser, réduire, corriger, protéger), avec une règle d'arrêt immédiat et des replis sûrs. Quand un test casse ou que le comportement surprend.

Relire

• code-review-and-quality. Relecture sur cinq axes, changements calibrés à environ 100 lignes, étiquettes de gravité (Détail / Facultatif / Pour info), et des normes de vitesse de relecture. Avant toute fusion.
• code-simplification. Barrière de Chesterton, règle des 500, réduire la complexité sans changer le comportement. Quand le code marche mais devient pénible à lire.
• security-and-hardening. Prévention du top 10 OWASP, schémas d'authentification, gestion des secrets, audit des dépendances, frontières à trois niveaux. Dès qu'il y a une entrée utilisateur, de l'authentification ou du stockage.
• performance-optimization. Mesurer d'abord : cibles Core Web Vitals, profilage, analyse du poids des bundles, détection des anti-patrons et des N+1. Quand tu as des exigences de performance ou un doute.

Publier

• git-workflow-and-versioning. Développement sur tronc commun, commits atomiques, calibrage des changements, le commit comme point de sauvegarde. À chaque changement, toujours.
• ci-cd-and-automation. Décaler les contrôles vers la gauche, drapeaux de fonctionnalité, portes de qualité dans le pipeline, boucles de retour sur échec. Pour construire ou modifier une chaîne de déploiement.
• deprecation-and-migration. Le code est un passif : dépréciation obligatoire ou consultative, schémas de migration, suppression du code zombie. Pour retirer un ancien système ou migrer des utilisateurs.
• documentation-and-adrs. Fiches de décision d'architecture, documentation d'API, standards de commentaires : documenter le pourquoi, jamais le quoi. À chaque décision structurante.
• observability-and-instrumentation. Journalisation structurée, métriques RED, traçage OpenTelemetry, alertes fondées sur les symptômes : instrumenter pendant qu'on construit. Pour tout ce qui tourne en production.
• shipping-and-launch. Checklists avant lancement, cycle de vie des drapeaux, déploiements progressifs, procédures de retour arrière, mise en place de la surveillance. Juste avant de déployer.

Le mécanisme que personne ne remarque

C'est la partie du pack dont personne ne parle, et c'est pourtant ce qui le fait fonctionner là où un prompt échoue.

Chaque skill contient une section intitulée Rationalizations. Ce n'est pas de la documentation : c'est une table qui liste les excuses que les agents utilisent pour sauter une étape, chacune accompagnée de sa réfutation.

La conséquence pratique est celle-ci : tu n'as pas besoin de surveiller l'agent. Un prompt qui dit « n'oublie pas les tests » se fait contourner dès que le modèle trouve une bonne raison de contourner. Une table de rationalisations anticipe la raison et la neutralise avant qu'elle serve.

C'est aussi ce qui explique pourquoi le pack paraît plus lent au début. Il l'est. Il refuse d'avancer sans preuve, et la preuve prend du temps à produire.

Ton premier projet, de l'idée à la mise en ligne

Prends un vrai petit projet, pas un exemple jouet : le pack est conçu pour du code qui va vivre. Compte une heure la première fois.

1. Pose le niveau d'exigence, une fois pour toutes

   /constraints

   Réponds honnêtement à ses questions. Un projet personnel n'a pas les mêmes seuils qu'une application qui gère des paiements, et le dire évite que l'agent sur-ingénierie ou sous-teste. Le fichier CONSTRAINTS.md qu'il écrit sera relu à chaque étape.

2. Décris ton idée en une phrase, laisse-le t'interroger

   /spec une app pour suivre mes dépenses mensuelles

   Il va poser des questions une par une. Ne les expédie pas. C'est le seul moment où corriger un malentendu coûte une phrase plutôt qu'une journée. Tu ressors avec un cahier des charges écrit.

3. Fais générer le plan, et lis-le

   /plan

   Tu obtiens des tâches découpées avec leurs critères d'acceptation et leur ordre. C'est ta dernière occasion d'intervenir à moindre coût : si une tâche te paraît floue à la lecture, elle le sera aussi à l'exécution.

4. Laisse-le construire

   /build

   Il implémente tranche par tranche, teste et valide au fur et à mesure. C'est long, et c'est normal : tu approuves le plan une fois, puis il déroule.

5. Fais-le relire avant de publier

   /review
   /ship

   /review passe le code sur cinq axes. /ship lance en parallèle un relecteur de code, un auditeur de sécurité, un ingénieur de tests et un auditeur de performance, puis fusionne leurs conclusions en une seule décision : on publie ou on ne publie pas.

Ce que le pack ne fait pas

Trois limites honnêtes, dont aucune n'est écrite dans le dépôt.

1. Il ne décide rien à ta place

   Il fournit des procédures et exige des preuves. Ce que tu construis, pour qui, et si ça vaut le coup d'être construit : ça reste entièrement toi. Un projet inutile parfaitement testé reste un projet inutile.

2. Il est disproportionné sur les petites choses

   Sur un script de vingt lignes ou une correction d'une ligne, lancer le cycle complet coûte plus cher que le problème. Le pack est fait pour du code qui va vivre, être relu et déployé. Pour le reste, demande normalement.

3. Il ne remplace pas la connaissance de ton propre code

   Les relecteurs sont bons sur ce qui est mesurable : sécurité, performance, structure. Ils ne savent pas qu'une fonction bizarre existe parce qu'un client a exigé un comportement précis il y a deux ans. La barrière de Chesterton est dans les skills pour cette raison : ne retire pas une clôture avant de savoir pourquoi elle est là.

Les erreurs du premier essai

1. Aller directement à /build

   C'est l'erreur numéro un. Sans /spec ni /plan, la commande construit quelque chose, mais tu retombes exactement dans le problème du début : du code qui marche, écrit contre une demande mal cadrée.

2. Expédier l'entretien de cadrage

   Les questions une par une paraissent lentes et on répond « oui, comme tu veux ». Chaque « comme tu veux » est une décision que le modèle prendra à ta place, et qu'il prendra vers la moyenne.

3. N'installer qu'une skill

   Répétons-le : l'installation ciblée laisse le dossier references/ derrière elle, sans le dire. Les skills renvoient alors à des checklists absentes.

4. Confondre lenteur et blocage

   Le pack s'arrête quand une preuve manque. Ce n'est pas une panne, c'est la fonctionnalité principale. Lis ce qu'il demande plutôt que de relancer.

5. Le garder alors qu'on ne s'en sert pas

   Si tu ne fais que du prototypage jetable, ce pack te ralentira sans rien t'apporter. Il devient rentable au moment précis où quelqu'un d'autre que toi va lire ton code : un associé, un client, ou toi dans six mois.