agent-skills - collection de compétences d’ingénierie de niveau production pour les agents de code IA

• Un projet open source dans lequel Addy Osmani, directeur IA chez Google Cloud, a encapsulé des workflows de niveau ingénieur senior sous forme de compétences structurées afin de résoudre le problème des agents de code IA qui sautent les spécifications, les tests et les revues de sécurité
• Composé de 7 commandes slash et de 19 compétences couvrant l’ensemble du cycle de vie du développement (définition → planification → build → vérification → revue → déploiement)
  • /spec définir ce qu’il faut construire : « des spécifications avant le code »
  • /plan planifier la méthode d’implémentation : « en petites tâches atomiques »
  • /build implémentation incrémentale : « une seule tranche à la fois »
  • /test prouver le fonctionnement : « les tests sont des preuves »
  • /review gate qualité avant merge : « améliorer la santé du code »
  • /code-simplify simplifier le code : « la clarté plutôt que l’ingéniosité »
  • /ship déploiement en production : « plus c’est rapide, plus c’est sûr »
• La compétence appropriée s’active automatiquement selon le contexte. Ex. : api-and-interface-design pour la conception d’API, frontend-ui-engineering pour l’implémentation UI
• Les principes clés de la culture d’ingénierie de Google (Hyrum's Law, Beyonce Rule, Chesterton's Fence, Shift Left, etc.) sont directement intégrés aux workflows à chaque étape

Liste complète des 19 compétences

• Define (clarifier ce qu’il faut construire)

  • idea-refine : structure la pensée divergente/convergente pour transformer une idée vague en proposition concrète
  • spec-driven-development : rédaction d’un PRD couvrant objectifs, commandes, structure, style de code, tests et limites avant d’écrire du code

• Plan (décomposer)

  • planning-and-task-breakdown : décompose la spec en petites tâches vérifiables avec critères d’acceptation et ordre des dépendances

• Build (écriture du code)

  • incremental-implementation : implémenter, tester, valider et commit en fines tranches verticales, avec support des feature flags et de changements compatibles avec le rollback
  • test-driven-development : application de Red-Green-Refactor, de la pyramide des tests (80/15/5), de DAMP over DRY et de la Beyonce Rule
  • context-engineering : fournir à l’agent la bonne information au bon moment (fichiers de règles, empaquetage du contexte, intégration MCP)
  • frontend-ui-engineering : architecture de composants, design system, gestion d’état, responsive design, accessibilité WCAG 2.1 AA
  • api-and-interface-design : conception contract-first, Hyrum's Law, One-Version Rule, sémantique des erreurs, validation aux frontières

• Verify (prouver le fonctionnement)

  • browser-testing-with-devtools : données runtime en temps réel via Chrome DevTools MCP (inspection du DOM, logs console, traces réseau, profilage des performances)
  • debugging-and-error-recovery : triage en 5 étapes (reproduire → localiser → réduire → corriger → protéger), avec règle stop-the-line

• Review (gate qualité avant fusion)

  • code-review-and-quality : revue sur 5 axes, taille des changements (~100 lignes), labels de sévérité (Nit/Optional/FYI), critères de rapidité de review
  • code-simplification : Chesterton's Fence, Rule of 500, réduction de la complexité tout en conservant un comportement exact
  • security-and-hardening : prévention OWASP Top 10, patterns d’authentification, gestion des secrets, audit des dépendances, système de frontières à 3 couches
  • performance-optimization : approche measurement-first, objectifs Core Web Vitals, workflow de profilage, analyse de bundle

• Ship (déployer)

  • git-workflow-and-versioning : trunk-based development, commits atomiques, taille des changements (~100 lignes), pattern commit-as-savepoint
  • ci-cd-and-automation : Shift Left, Faster is Safer, feature flags, pipeline de quality gates
  • deprecation-and-migration : vision du code comme dette, approches de dépréciation obligatoire ou recommandée, suppression du code zombie
  • documentation-and-adrs : Architecture Decision Records, documentation d’API, règles de documentation inline (« documenter le pourquoi »)
  • shipping-and-launch : checklist pré-lancement, cycle de vie des feature flags, rollout progressif, procédure de rollback, configuration du monitoring

Personas d’agent

• 3 personas d’experts sont préconfigurés pour des revues ciblées
  • code-reviewer : perspective d’un ingénieur staff senior, avec une revue de code sur 5 axes selon le critère « est-ce au niveau d’une approbation par un staff engineer ? »
  • test-engineer : perspective d’un expert QA, avec stratégie de test, analyse de couverture et pattern Prove-It
  • security-auditor : perspective d’un ingénieur sécurité, avec détection de vulnérabilités, modélisation des menaces et évaluation OWASP

Checklists de référence

• 4 documents de référence rapide utilisés par les compétences quand nécessaire
  • testing-patterns.md : structure des tests, conventions de nommage, mocking, exemples React/API/E2E, antipatterns
  • security-checklist.md : vérifications avant commit, authentification, validation des entrées, headers, CORS, OWASP Top 10
  • performance-checklist.md : objectifs Core Web Vitals, checklists frontend/backend, commandes de mesure
  • accessibility-checklist.md : navigation clavier, lecteur d’écran, design visuel, ARIA, outils de test

Principes de conception des compétences

• Du processus, pas de la prose : les compétences sont des workflows suivis par l’agent, avec étapes, checkpoints et critères de sortie, et non des documents de référence
• Prévenir les rationalisations : chaque compétence intègre les excuses classiques utilisées par les agents pour sauter des étapes (« j’ajouterai les tests plus tard ») ainsi que les contre-arguments correspondants
• La vérification n’est pas négociable : chaque compétence se termine par des exigences de preuve (tests passés, sortie de build, données runtime), et « ça a l’air de marcher » n’est pas suffisant
• Divulgation progressive : SKILL.md sert de point d’entrée, et les références de support ne sont chargées qu’en cas de besoin afin de minimiser la consommation de tokens

Installation (outils pris en charge)

• Claude Code (recommandé) : /plugin marketplace add addyosmani/agent-skills puis /plugin install agent-skills@addy-agent-skills
  • Développement local : git clone puis claude --plugin-dir /path/to/agent-skills
• Cursor : copier n’importe quel SKILL.md dans .cursor/rules/ ou référencer tout le répertoire skills/
• Gemini CLI : gemini skills install https://github.com/addyosmani/agent-skills.git
• Windsurf : ajouter le contenu des compétences à la configuration des règles Windsurf
• GitHub Copilot : utiliser les définitions d’agents de agents/ comme personas Copilot, et le contenu des compétences dans .github/copilot-instructions.md
• Codex et autres agents : les compétences étant en Markdown standard, elles sont compatibles avec tous les agents prenant en charge les system prompts ou les fichiers d’instructions

[xguru]

On dirait qu’en ce moment, publier ses propres skill sets devient presque une mode.

Comme ce ne sont au fond que des fichiers Markdown, il n’est pas nécessaire de tout reprendre tel quel.
Plus il y en a, plus la consommation de tokens augmente.
Il vaut mieux dire à son agent : « Analyse ça et ne prends que ce qui est nécessaire. »

C’est comme ça qu’on se construit son propre harness.

[thestackai]

Oui. Je pense que c’est la meilleure façon de faire face à l’afflux d’open source.

[yangeok]

On dirait que c’est un peu comme speckit.

[blacksocks]

On nous a demandé en interne d’essayer de développer uniquement avec le vibe coding, donc j’ai testé plusieurs approches. Mais une fois lancé, je me suis rendu compte qu’avoir d’excellentes compétences en développement ne garantit pas forcément une qualité élevée..
J’ai plutôt l’impression que l’essentiel, c’est la capacité à relire et à comprendre le code généré par l’IA. Plus les outils s’améliorent, plus cette ironie devient frappante : la capacité à « lire et juger » devient encore plus importante.

[ragingwind]

Le responsable de l’équipe Chrome chez Google, Addy Osmani, a rejoint Google Cloud AI en tant que Director.

[xguru]

Oh, quand est-ce que ça a été déplacé ? J’ai toujours cru que c’était encore le cas. Je l’ai corrigé.

[ragingwind]

Moi aussi, désormais, la seule personne que je connais dans l’équipe Chrome, c’est Paul Kinlan (responsable DevRel de Chrome). Comme le temps passe.