Les agents de code IA sont maintenant assez rapides pour que la vraie question ne soit plus seulement : “est-ce que le modèle peut écrire du code ?” La question plus importante est : est-ce que l’agent suit la discipline d’ingénierie qui garde un vrai codebase en bonne santé ?
Il faut écrire une spécification, découper le travail, construire par petites tranches, tester ce qui change, relire le résultat et livrer avec des preuves.
agent-skills d’Addy Osmani est une tentative open source de transformer cette discipline en workflows réutilisables. Le dépôt le présente comme un ensemble de compétences d’ingénierie de niveau production pour agents de code IA. Concrètement, c’est une collection de compétences Markdown, commandes slash, personas, hooks et checklists qui aident les agents à agir moins comme de l’autocomplétion et plus comme un coéquipier prudent.
L’idée importante est simple : les prompts ne suffisent pas. Les agents ont besoin de processus répétables.
Ce qu’est Agent Skills
Agent Skills est un pack de workflows pour agents de code IA. Il donne à l’agent des instructions structurées pour toute la boucle de livraison logicielle :
Définir -> Planifier -> Construire -> Vérifier -> Relire -> Livrer
Le projet mappe cette boucle à 7 commandes slash :
| Étape | Commande | Objectif |
|---|---|---|
| Définir | /spec | Transformer une idée en spécification concrète |
| Planifier | /plan | Découper le travail en tâches petites et vérifiables |
| Construire | /build | Implémenter une tranche utile à la fois |
| Vérifier | /test | Prouver que le changement fonctionne |
| Relire | /review | Vérifier la qualité avant merge |
| Simplifier | /code-simplify | Réduire la complexité inutile |
| Livrer | /ship | Préparer la mise en production |
Derrière ces commandes, il y a 20 compétences. Chaque compétence est un workflow ciblé avec des étapes, des conditions de déclenchement, des signaux d’alerte, des contrôles contre les rationalisations et des exigences de vérification.
C’est important parce que les échecs des agents sont souvent des échecs de processus : l’agent saute la spécification, écrit trop de code d’un coup, oublie les tests, rationalise un build instable ou annonce que tout est terminé sans preuve.
Agent Skills essaie de bloquer ces échecs au niveau des instructions.
Les 20 compétences sont le vrai produit
Les commandes slash sont des points d’entrée pratiques, mais la bibliothèque de compétences est la partie la plus intéressante.
Les compétences couvrent le cycle normal de l’ingénierie de production :
| Zone | Compétences |
|---|---|
| Définir | raffinement d’idée, développement piloté par spécification |
| Planifier | planification et découpage de tâches |
| Construire | implémentation incrémentale, TDD, ingénierie du contexte, développement guidé par les sources, UI frontend, conception d’API et d’interfaces |
| Vérifier | tests navigateur avec DevTools, debugging et récupération d’erreur |
| Relire | revue de code et qualité, simplification, sécurité, performance |
| Livrer | workflow git, CI/CD, dépréciation et migration, documentation et ADR, lancement |
| Méta | utilisation des compétences d’agent |
C’est utile parce qu’un agent IA n’a pas besoin des mêmes contraintes à chaque étape. Une tâche de planification ne doit pas utiliser les mêmes instructions qu’une revue de sécurité. Une implémentation UI ne doit pas avoir le même standard de preuve qu’un plan de migration. Une session de debugging doit reproduire et localiser le problème avant de proposer un patch.
Agent Skills donne à chaque phase sa propre procédure.
Pourquoi c’est mieux qu’un seul énorme prompt
Une approche fréquente avec les outils de code IA consiste à créer un énorme CLAUDE.md, AGENTS.md ou fichier de règles qui essaie de tout encoder : style de code, standards de tests, limites d’architecture, règles de déploiement, checklists de revue et préférences personnelles.
Ça fonctionne pendant un moment, puis ça devient bruyant. L’agent reçoit des instructions inutiles pour la tâche en cours. Les règles importantes se perdent. Le modèle peut suivre un conseil générique au lieu du workflow précis qui compte maintenant.
Agent Skills utilise plutôt la divulgation progressive. Le fichier de compétence est le point d’entrée. Les références complémentaires sont chargées seulement si nécessaire. Le contexte actif reste plus petit et plus pertinent.
Le choix de conception est subtil mais important :
- Une compétence n’est pas seulement de la documentation.
- Une compétence n’est pas seulement un extrait de prompt.
- Une compétence est une procédure avec des critères de sortie.
C’est la différence entre “pense à tester” et “ne considère pas ce travail terminé tant que la preuve de test pertinente n’existe pas”.
Le modèle anti-rationalisation est l’idée la plus forte
Le README met en avant l’anti-rationalisation comme choix de conception. C’est exactement ce dont les agents ont besoin.
Les agents sont très bons pour produire des explications plausibles qui justifient un raccourci :
| Raccourci | Pourquoi c’est risqué |
|---|---|
| ”C’est un petit changement, pas besoin de test” | Un petit changement peut casser un comportement partagé |
| ”Le code a l’air correct” | Avoir l’air correct n’est pas une preuve runtime |
| ”Je nettoierai plus tard” | Plus tard veut souvent dire jamais |
| ”Le code existant est déjà désordonné” | Un contexte désordonné ne justifie pas plus d’entropie |
| ”Le build devrait passer" | "Devrait” n’est pas un garde-fou qualité |
Un ingénieur senior détecte ces rationalisations instinctivement. Un agent de code a besoin qu’elles soient écrites. Agent Skills intègre cela dans le format des workflows.
C’est probablement la partie que je copierais dans presque toutes les configurations sérieuses d’agents : pas seulement quoi faire, mais aussi les excuses que l’agent n’a pas le droit d’utiliser.
Les personas d’agents ajoutent une couche utile
Le dépôt inclut aussi des personas spécialisés :
| Persona | Rôle |
|---|---|
| code-reviewer | Revue de code avec perspective staff engineer |
| test-engineer | Stratégie de test et analyse qualité |
| security-auditor | Sécurité, menaces et durcissement |
Cela correspond bien au fonctionnement des bonnes équipes d’ingénierie. La même personne peut écrire du code, mais la perspective de revue n’est pas la même que la perspective d’implémentation. Le même agent peut générer des tests, mais un persona test-engineer doit poser d’autres questions qu’un persona builder.
Pour le code IA, cette séparation aide à éviter un problème courant : l’agent qui a écrit le code accepte trop facilement son propre travail. Un persona de revue donne au système la permission d’être plus strict.
Le support des outils est volontairement large
Agent Skills n’est pas limité à un seul environnement.
Le README indique des chemins d’installation ou d’utilisation pour :
- Claude Code, y compris l’installation via marketplace
- Cursor
- Gemini CLI
- Windsurf
- OpenCode
- GitHub Copilot
- Kiro IDE et CLI
- Codex et les autres agents capables de consommer des fichiers d’instructions
Cette portabilité vient du format. Le contenu central est principalement du Markdown. Chaque outil peut le charger différemment, mais les workflows de base ne sont pas enfermés dans un seul fournisseur.
Pour une équipe, c’est utile. Vous pouvez standardiser le processus d’ingénierie même si les développeurs utilisent différentes interfaces d’agents.
Où je l’utiliserais en premier
Je ne commencerais pas par installer tous les workflows en espérant de la magie. Je commencerais par les points les plus risqués de la boucle de développement.
1. Revue de code
La compétence code-review-and-quality est probablement le meilleur point de départ. La revue est l’endroit où les problèmes cachés apparaissent : limites floues, tests manquants, abstractions risquées, gestion d’erreur incohérente et changements trop gros pour être raisonnés correctement.
Si un agent peut relire avec une perspective staff engineer, il devient utile avant même qu’on lui fasse confiance pour implémenter de grosses fonctionnalités.
2. Développement piloté par les tests
La compétence test-driven-development compte parce que les agents optimisent souvent pour terminer le patch visible. Un workflow de test ramène la conversation vers la preuve.
Un bon test avec agent doit répondre :
- Quel comportement a changé ?
- Quel est le plus petit test qui le prouve ?
- Quel cas limite pourrait casser ?
- Le test échouait-il avant le correctif ?
- Le test pertinent passe-t-il après le correctif ?
C’est la différence entre génération de code et ingénierie.
3. Debugging et récupération d’erreur
Le debugging est un endroit où les agents peuvent perdre beaucoup de temps avec assurance. Un processus de triage structuré est essentiel : reproduire, localiser, réduire, corriger, protéger.
Sans cette séquence, l’agent peut corriger des symptômes. Avec elle, il a plus de chances de trouver la vraie source du problème.
4. Sécurité et durcissement
La revue de sécurité convient très bien aux compétences parce qu’elle est à la fois checklist-heavy et dépendante du contexte. On veut que l’agent vérifie les limites d’entrée, les secrets, l’authentification, les dépendances, les headers, CORS et les risques d’injection, mais seulement d’une manière pertinente pour le code réel.
Ce n’est pas un remplacement d’une vraie revue sécurité. C’est une façon de capturer les oublis évidents avant la revue humaine.
Ce que cela signifie pour l’ingénierie assistée par IA
Agent Skills pointe vers un changement plus large : le prochain avantage dans le code IA ne viendra pas seulement de modèles plus puissants. Il viendra aussi de meilleurs systèmes d’exploitation autour des modèles.
Le modèle est le moteur de raisonnement. Les compétences sont la mémoire de processus.
Cette distinction compte. Les ingénieurs seniors ne sont pas utiles seulement parce qu’ils peuvent écrire du code. Ils portent du jugement sur le séquencement, le rayon d’impact, les chemins de rollback, les preuves de test, les risques de dépendances, la qualité de revue et les moments où il vaut mieux ne pas toucher au système.
Agent Skills transforme une partie de ce jugement en procédures réutilisables.
C’est pourquoi le projet semble plus important qu’une simple bibliothèque de prompts. Il n’essaie pas de rendre les agents plus éloquents. Il essaie de les rendre plus disciplinés.
Les compromis
Il y a des compromis.
D’abord, les workflows structurés ajoutent de la friction. Pour un changement minuscule d’une ligne, un cycle complet spec-plan-build-review-ship peut être trop lourd. L’important est d’utiliser la bonne compétence pour le niveau de risque.
Ensuite, les compétences dépendent encore du modèle et de sa capacité à suivre les instructions. Elles améliorent le comportement, mais ne le garantissent pas. Il faut toujours des vérifications, des tests et du jugement humain.
Enfin, les équipes devront adapter les valeurs par défaut. Un prototype de startup, une plateforme de données santé et un backend financier ne devraient pas partager exactement les mêmes seuils de risque.
Mais ce sont de bons compromis. Un workflow ajustable est meilleur qu’une intuition impossible à inspecter.
Démarrage rapide
Pour Claude Code, le README montre l’installation marketplace :
/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills
Si le clonage SSH pose problème, le projet documente aussi un chemin HTTPS :
/plugin marketplace add https://github.com/addyosmani/agent-skills.git
/plugin install agent-skills@addy-agent-skills
Pour le développement local :
git clone https://github.com/addyosmani/agent-skills.git
claude --plugin-dir /path/to/agent-skills
Les autres outils ont leurs propres chemins de chargement, mais l’idée reste la même : exposer les fichiers de compétences à l’agent et laisser le workflow pertinent s’activer pour la tâche.
Conclusion
Agent Skills mérite l’attention parce qu’il traite le code IA comme un problème de workflow d’ingénierie, pas seulement comme un problème de capacité modèle.
Les meilleures équipes qui utilisent des agents IA ne seront pas seulement celles qui demandent du code le plus vite. Ce seront celles qui font suivre aux agents la même boucle qualité que les bons ingénieurs utilisent déjà : définir clairement, planifier en petites unités, construire progressivement, vérifier avec des preuves, relire avec exigence et livrer prudemment.
C’est ce que ce dépôt met en paquet.
Pour les codebases sérieux, c’est la direction que les outils d’agents doivent prendre.