Le Framework Skills - Du Vibe Coding a l'Ingenierie Agentique de Production

Depuis un an, j’affine mon stack de developpement agentique : Claude Code avec un CLAUDE.md soigneusement elabore, des worktrees paralleles, des runs d’agents pendant la nuit, Cursor pour le travail visuel. Ca a ete enormement productif - mais ca a aussi revele un mode d’echec recurrent.

A mesure que CLAUDE.md grossit pour encoder tout ce que l’agent devrait savoir, il commence a gonfler. Conventions de tests, checklists de securite, procedures de mise en production, standards de revue de code - tout fourrer dans le system prompt signifie que chaque session paie le cout en tokens, que l’agent soit en train de refactorer une variable CSS ou de concevoir un nouveau pipeline de facturation. Et une fois que le fichier depasse une certaine taille, l’adherence de l’agent commence a se degrader.

Le framework skills est la solution. C’est la couche de discipline qui me manquait sans que je le sache, et apres avoir passe les dernieres semaines a l’integrer dans mon workflow, je suis convaincu que c’est le prochain standard important pour quiconque fait du travail agentique serieux. Dans cet article, je veux parcourir ce que c’est, pourquoi c’est important, comment ca se compare au Spec Kit de GitHub, et comment je l’ai integre dans mon propre setup.

Que Sont les Agent Skills ?

Anthropic a introduit les Agent Skills fin 2025 comme un moyen structure d’empaqueter des connaissances procedurales pour Claude. L’idee centrale est d’une simplicite desarmante : au lieu de tout entasser dans un seul prompt gigantesque, tu crees de petits repertoires de skills autonomes que l’agent charge uniquement quand c’est pertinent.

Un skill est simplement un dossier contenant un fichier SKILL.md avec un frontmatter YAML et un corps, plus des ressources optionnelles incluses :

my-skill/
├── SKILL.md           # The core instructions + frontmatter
├── scripts/           # Executable helpers the agent can run
├── references/        # Deeper docs loaded on demand
└── assets/            # Templates, example files, images

Le frontmatter du SKILL.md est ce qui fait fonctionner tout le systeme :

---
name: spec-driven-development
description: Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet.
---

Claude voit le name et la description de chaque skill installe au demarrage de la session - mais rien d’autre. Ce n’est que lorsque l’agent decide qu’un skill est pertinent que le corps complet se charge dans le contexte. Ce seul choix de design - le progressive disclosure - est ce qui permet au framework de passer a l’echelle.

Progressive Disclosure : La Percee Silencieuse

Le modele de progressive disclosure fonctionne en trois couches :

1. Metadonnees (toujours chargees) - Juste les champs name et description, quelques tokens par skill. C’est la “table des matieres” de Claude.
2. Instructions (chargees au declenchement) - Le corps complet du SKILL.md, generalement moins de 500 lignes. Se charge quand l’agent fait correspondre la tache a la description du skill.
3. Ressources (chargees a la demande) - Les fichiers sous scripts/, references/ et assets/. Peuvent etre arbitrairement volumineux parce qu’ils n’entrent dans le contexte que quand l’agent les lit explicitement.

Ca resout la plus ancienne tension en ingenierie d’agents : tu veux que l’agent ait acces a tout, mais tu ne veux pas payer pour tout a chaque tour. Le progressive disclosure dit : garde le manuel dans la piece, mais ne le lis pas de bout en bout pour chaque question.

C’est aussi pourquoi les skills grignotent discretement le terrain de MCP. En pratique, connecter plus de deux ou trois serveurs MCP a un agent degrade sensiblement la precision d’utilisation des outils - chaque description d’outil reste dans le contexte en permanence. Les skills, en revanche, te permettent d’en installer des dizaines avec un cout de demarrage quasi nul. MCP et les skills ne sont pas exactement des concurrents - MCP est la plomberie pour l’acces aux outils, les skills sont le cerveau procedural au-dessus de cette plomberie - mais pour l’encapsulation de connaissances, les skills gagnent en ergonomie.

Les Agent-Skills d’Addy Osmani : L’Ingenierie de Production Cle en Main

C’est la que ca devient vraiment interessant pour moi. Addy Osmani - Senior Engineering Director chez Google, qui a dirige l’equipe Developer Experience de Chrome pendant plus d’une decennie, auteur de Learning JavaScript Design Patterns, et devenu l’une des voix les plus eclairees sur le developpement assiste par IA - a empaquete ses propres workflows d’ingenierie de production dans une bibliotheque open-source de skills sur github.com/addyosmani/agent-skills.

Le slogan dit tout : “Production-grade engineering skills for AI coding agents.” Ce ne sont pas des docs de reference - ce sont des workflows que les agents suivent, encodant le type de discipline qu’un ingenieur senior apporte au code de production.

Le repo livre actuellement une vingtaine de skills repartis sur six phases du cycle de vie :

Phase	Skills Representatifs
Define	spec-driven-development, idea-refine
Plan	planning-and-task-breakdown
Build	incremental-implementation, test-driven-development, frontend-ui-engineering
Verify	debugging-and-error-recovery, portes d’execution des tests
Review	code-review-and-quality, security-and-hardening, api-and-interface-design
Ship	shipping-and-launch, ci-cd-and-automation, performance-optimization

Il y a des slash commands correspondantes - /agent-skills:spec, /agent-skills:plan, /agent-skills:build, /agent-skills:test, /agent-skills:review, /agent-skills:ship - qui te donnent un acces direct au skill pertinent a chaque etape.

L’Anatomie du SKILL.md Qui Fait Que Ca Marche

Ce que je trouve le plus precieux, c’est la structure interne coherente de chaque skill. En prenant spec-driven-development comme modele de reference :

• Overview - Un paragraphe : ce que ce skill accomplit et pourquoi l’agent devrait s’en soucier.
• When to Use - Des declencheurs explicites et, tout aussi important, des anti-declencheurs explicites (“Ne pas utiliser pour des corrections d’une ligne ou des changements non ambigus”).
• Process - Un workflow par phases avec des portes de validation. Le spec-driven development guide a travers Specify -> Plan -> Tasks -> Implement, avec un point de controle humain entre chaque phase.
• Rationalizations - Ma section preferee. C’est une liste des excuses qu’un agent (ou un ingenieur fatigue) inventera pour sauter le processus, chacune associee a une refutation ferme. La ligne canonique du skill spec-driven est “A 15-minute spec prevents hours of rework. Waterfall in 15 minutes beats debugging in 15 hours.”
• Red Flags - Signes d’alerte que le skill est mal applique ou completement ignore.
• Verification - Des preuves concretes que le skill a bien ete suivi. Pas “ca a l’air correct” - une checklist.

Cette section Rationalizations est l’innovation cle. Tout ingenieur senior a vu un developpeur junior (ou soi-meme lors d’une mauvaise journee) rationaliser l’absence de tests, sauter une revue, ou balayer d’un geste un probleme de securite. Les skills encodent non seulement le bon processus mais aussi la defense anti-rationalization qui maintient l’agent sur le droit chemin. C’est la difference entre un document et un workflow.

Comparaison avec le Spec Kit de GitHub

Si tu suis cet espace, tu as probablement entendu parler de Spec Kit, le toolkit de GitHub pour le Spec-Driven Development. En surface, il y a beaucoup de chevauchement - les deux visent a remplacer le “vibe coding” par une ingenierie structuree, specification-first. Mais ils sont en fait complementaires plutot que concurrents.

Dimension	Spec Kit (GitHub)	Agent-Skills (Osmani)
Focus principal	Scaffolding du cycle de vie Spec-Driven Development	Bibliotheque complete de workflows d’ingenierie (spec, test, review, ship)
Format de livraison	Templates slash-command + scaffolding de projet	Repertoires SKILL.md a progressive disclosure
Couverture du processus	Specify -> Plan -> Tasks -> Implement	Six phases sur l’ensemble du SDLC
Chargement du contexte	Fichiers prompt injectes en amont	Charges a la demande via correspondance de metadonnees
Surface d’outillage	CLI (specify) qui configure un repo	Repertoires simples, portables entre agents
Anti-rationalization	Implicite dans le flux a portes	Section explicite dans chaque skill
Extensibilite	Base sur des templates	Ecris plus de fichiers SKILL.md, depose-les

Fait interessant, les versions recentes de Spec Kit peuvent desormais installer des agent skills au lieu de fichiers prompt en slash-command via un parametre --ai-skills - les deux convergent donc. Spec Kit te donne un point d’entree batteries-incluses pour le flux spec-plan-tasks-implement ; agent-skills te donne une bibliotheque plus large et plus profonde pour le reste du cycle d’ingenierie, chargee progressivement. J’utilise Spec Kit pour amorcer les nouveaux projets et la bibliotheque agent-skills comme couche de discipline permanente par-dessus.

Pourquoi C’est Important : Le Fosse entre Vibe Coding et Ingenierie

Andrej Karpathy a invente le terme vibe coding pour decrire une pratique specifique et honnete : prompter le modele, accepter ce qu’il produit, ne pas lire le diff, iterer en collant les erreurs en retour. Pour les projets du week-end et les prototypes jetables, c’est un vrai superpouvoir. J’ai construit des choses en deux heures qui auraient pris deux jours d’ingenierie soignee.

Le probleme, c’est que “vibe coding” est devenu un mot-valise. Les gens ont commence a l’utiliser pour decrire tout, du vrai YOLO prompting aux workflows agentiques disciplines avec tests, revue de code et supervision architecturale humaine. Simon Willison a tente de recadrer le terrain avec le “vibe engineering” - meme enthousiasme, mais avec de la rigueur d’ingenierie en plus. Ca n’a pas pris, principalement parce que le mot vibe porte trop de connotations decontractees. Comme Karpathy lui-meme l’a suggere plus tard, agentic engineering est le cadrage plus propre : l’humain est responsable de l’architecture, de la qualite et de la correction ; l’agent est responsable de l’implementation.

Le cadrage d’Osmani est celui que je trouve le plus utile : le plus grand facteur de differenciation entre l’ingenierie agentique et le vibe coding, c’est le testing. Avec une suite de tests solide, un agent peut iterer en boucle jusqu’au vert et tu obtiens une haute confiance dans le resultat. Sans suite de tests, tu voles a l’aveugle a vitesse 10x.

Le framework skills est ce qui rend l’ingenierie agentique applicable de maniere contraignante. C’est la couche structurelle qui transforme l’intention (“on devrait ecrire des specs d’abord”) en processus (“le skill /spec bloque litteralement l’implementation tant que la Phase 1 n’est pas approuvee”). Ca rend aussi le processus portable : les memes fichiers SKILL.md fonctionnent dans Claude Code, Cursor, Gemini CLI, Windsurf et Copilot parce que ce n’est que du markdown avec une convention.

Les Avantages Concrets Que J’ai Mesures

Apres avoir integre le framework skills dans mon stack ces dernieres semaines, voici ce qui a concretement change :

1. Mon CLAUDE.md est Devenu Plus Petit, Pas Plus Gros

C’etait la surprise. Je luttais contre le probleme de gonflement en etant plus discipline sur ce qui entrait dans CLAUDE.md. Les skills m’ont permis de deplacer des chapitres entiers : la checklist de securite, la procedure de release, le playbook de profiling de performances, le guide de conception d’API. Ils sont toujours la, toujours appliques - mais ils n’entrent dans le contexte que quand un skill est declenche. Mon CLAUDE.md porte desormais principalement sur l’architecture du projet et le modele de tenancy, pas sur la discipline d’ingenierie generique. L’agent est nettement plus concentre en consequence.

2. L’Anti-Rationalization Fonctionne Vraiment

C’etait le plus grand changement qualitatif. Avant les skills, quand un agent voulait sauter l’ecriture de tests, il rationalisait : “C’est un changement trivial, les tests seraient excessifs.” Parfois je le remarquais, parfois non. Avec le skill test-driven-development charge, ces rationalisations sont confrontees de plein fouet par la section de refutation du skill. L’agent argumente avec lui-meme et perd. J’ai vu des runs de nuit ou l’agent envisageait de sauter un test, le skill interceptait la pensee, et le run produisait quand meme des tests.

3. Les Runs de Nuit Sont Plus Fiables

Mon workflow overnight agent factory ne vaut que par les portes de qualite implicites que l’agent respecte pendant que je dors. Les skills rendent ces portes explicites. /ship ne se termine pas tant que security-and-hardening et code-review-and-quality n’ont pas verifiablement ete executes. Je me reveille avec des PRs plus proches du merge, pas plus proches de “necessite encore une heure de nettoyage.”

4. Portables d’un Agent a l’Autre

Quand j’itere sur un frontend dans Cursor puis bascule vers Claude Code pour une tache backend, la meme bibliotheque de skills s’applique. Memes conventions, memes portes de verification, memes anti-rationalizations. Plus besoin de tuning de prompt specifique a chaque agent.

5. Composables avec Spec Kit

Pour les projets greenfield, j’amorce avec le CLI specify de Spec Kit, puis je laisse la bibliotheque agent-skills prendre le relais une fois la premiere spec approuvee. Les deux frameworks s’emboitent proprement.

Comment Je l’Utilise au Quotidien

Important : Les skills font partie du systeme de plugins de Claude Code - tu ne peux pas juste cloner un repo dans un repertoire quelconque et t’attendre a ce que Claude le trouve. Le systeme de plugins gere la decouverte, l’enregistrement et le cablage des slash commands.

Installation

Dans une session Claude Code, lance ces deux commandes :

# 1. Register Osmani's repo as a plugin marketplace
/plugin marketplace add addyosmani/agent-skills

# 2. Install the plugin from that marketplace
/plugin install agent-skills@addy-agent-skills

Redemarre Claude Code apres l’installation - les skills et les commandes sont decouverts au demarrage de la session, donc ils n’apparaitront pas avant d’ouvrir une nouvelle session.

Depannage : Si le clone du marketplace echoue silencieusement (les commandes n’apparaissent jamais), la cause la plus frequente est les permissions SSH. Corrige avec :

git config --global url."https://github.com/".insteadOf "git@github.com:"

Puis relance les deux commandes ci-dessus dans une nouvelle session.

Pour la specification complete des plugins et skills, consulte la documentation skills d’Anthropic.

Utilisation des Commandes

Une fois installe, le plugin enregistre sept slash commands namespacees qui correspondent au cycle de vie du developpement. Le prefixe agent-skills: les distingue des commandes integrees de Claude Code (comme le /review integre qui examine les pull requests) :

/agent-skills:spec           → write a structured specification (saves to SPEC.md)
/agent-skills:plan           → break the spec into small, verifiable tasks
/agent-skills:build          → implement the next task incrementally (thin vertical slices)
/agent-skills:test           → TDD workflow; for bugs, uses the "Prove-It" pattern (failing test first)
/agent-skills:review         → five-axis code review (correctness, readability, architecture, security, performance)
/agent-skills:code-simplify  → simplify code for clarity without changing behavior
/agent-skills:ship           → pre-launch checklist (quality, security, performance, accessibility, infra, docs)

Derriere ces commandes se trouvent 21 skills couvrant l’ensemble du SDLC - de idea-refine et spec-driven-development en passant par debugging-and-error-recovery jusqu’a shipping-and-launch. Les skills se declenchent aussi automatiquement : Claude voit leurs descriptions au demarrage de la session et charge les instructions completes quand une tache correspond. Tu n’as pas toujours besoin de la slash command ; commencer a travailler sur une nouvelle fonctionnalite invoquera naturellement les skills de spec et de planification.

Apres l’installation, allegue ton CLAUDE.md - deplace les sections de discipline d’ingenierie generique, ne garde que l’architecture specifique au projet. Les skills portent maintenant ce poids.

Pour les skills internes specifiques a mes projets - enforcement multi-tenancy, conventions du modele de donnees NutriSpan, patterns CadQuery de SortFlex - j’ecris mes propres fichiers SKILL.md en utilisant la structure d’Osmani comme template. Cette anatomie en six sections (Overview / When to Use / Process / Rationalizations / Red Flags / Verification) est la bonne forme meme pour des skills specifiques a un domaine.

Ce Qu’il Faut Retenir

Si tu fais encore tourner des workflows agentiques avec un seul CLAUDE.md surcharge, tu laisses beaucoup de levier sur la table. Le framework skills n’est pas une mode - c’est une reponse d’ingenierie honnete a un vrai probleme de mise a l’echelle : comment donner plus de discipline a un agent sans payer le cout en contexte de tout charger a chaque tour ?

Le design progressive disclosure d’Anthropic a resolu le probleme de chargement. La bibliotheque open-source de skills d’Addy Osmani te donne vingt workflows eprouves pour demarrer. Le Spec Kit de GitHub te donne le point d’entree. Mets les trois ensemble et tu obtiens quelque chose qui ressemble enfin a de l’ingenierie plutot qu’a du prompting.

Pour quiconque construit du logiciel serieux avec des agents - pas des prototypes, pas des projets du week-end, mais les choses qui doivent fonctionner en production dans un an - c’est le framework que j’adopterais aujourd’hui.

References

• addyosmani/agent-skills - La bibliotheque de skills de production d’Addy Osmani
• Equipping agents for the real world with Agent Skills - Le post de lancement d’Anthropic
• Agent Skills - Claude API Docs - Reference officielle
• github/spec-kit - Le toolkit Spec-Driven Development de GitHub
• Agentic Engineering - Addy Osmani - Le contexte plus large
• How to write a good spec for AI agents - Addy Osmani - L’article complementaire sur l’ecriture de specs
• Progressive Disclosure Might Replace MCP - MCPJam - L’argument progressive disclosure vs MCP