Expertise - Skills et plugins : apprendre vos conventions à vos agents de code

Qu'est-ce qu'un skill ?

Prenons une application Django avec une table de plusieurs millions de lignes. Dans ce projet, ajouter une colonne obligatoire se fait en trois migrations : la colonne d'abord sans contrainte, puis le remplissage par lots, puis la contrainte. L'équipe le sait. L'agent, lui, écrit une seule migration, qui verrouille la table pendant plusieurs minutes en production. Chaque développeur finit par recopier la même consigne dans ses demandes, plus ou moins complète selon les jours.

Un skill sert à écrire cette consigne une fois pour toutes. C'est un dossier, en général versionné dans le dépôt, qui contient un fichier de consignes en Markdown et parfois des scripts ou des exemples. Le fichier commence par une description courte, par exemple « à utiliser pour écrire ou modifier une migration de base de données ». Au départ, l'agent ne lit que cette description. Quand la tâche du moment y correspond, il charge le reste : les trois étapes, une migration du projet qui sert de modèle, le script qui vérifie qu'aucune migration ne bloque une grosse table.

Un skill ou le fichier AGENTS.md ?

Le fichier AGENTS.md (ou CLAUDE.md) est lu à chaque session. On y met ce qui vaut pour toutes les tâches : la commande de test, les conventions de commit, ce qu'il ne faut jamais toucher. Un skill n'est chargé que quand il sert. Il peut donc décrire une procédure longue et détaillée sans encombrer l'agent le reste du temps : la procédure de migration n'a rien à faire dans son contexte quand il corrige un bouton.

C'est la description qui décide si le skill sera utilisé. Si elle est vague, l'agent ne le charge jamais, ou le charge sur une tâche qui n'a rien à voir. Nous l'écrivons avec les mots que les développeurs emploient vraiment dans leurs demandes, et nous vérifions qu'elle se déclenche sur les bonnes tâches.

Qu'est-ce qu'un plugin ?

Un plugin regroupe plusieurs briques dans un même paquet, et leur liste dépend de l'outil. Dans Claude Code, on y trouve des skills, des sous-agents (des agents spécialisés, chacun avec son rôle et ses outils), des commandes qu'on lance par leur nom, des hooks qui se déclenchent tout seuls et des connecteurs MCP vers vos services. Un plugin Codex contient des skills, des serveurs MCP, des hooks et des extensions de navigateur. Toute l'équipe installe le même paquet depuis un catalogue partagé.

Comme le reste du code, un plugin a des versions. Quand quelqu'un corrige une consigne, la correction passe par une merge request et une relecture, puis chaque développeur la récupère à la mise à jour suivante.

---

Ce que ça change pour une équipe

Les conventions du projet sont écrites dans le dépôt, et plus seulement dans la tête de quelques développeurs. L'agent d'un développeur arrivé la semaine dernière les applique comme celui du plus ancien.

Quand un agent refait la même erreur, on corrige le skill une fois, et la correction sert à toute l'équipe sur les tâches suivantes.

Nos skills fonctionnent avec Claude Code comme avec Codex : une équipe peut utiliser les deux, et changer d'agent sans réécrire ses skills.

Un exemple : notre plugin interne

Notre propre méthode de travail tient dans un plugin. Il contient un agent par rôle (écrire un commit, relire, vérifier la couverture des tests, enquêter sur un test qui casse, localiser du code), et chacun a ses limites écrites dans sa consigne : aucun ne pousse de code, aucun ne répond à un collègue dans une review. Tous les développeurs qui installent le plugin travaillent avec les mêmes agents et les mêmes limites. Le détail de chaque agent est sur notre page Claude Code.

Ce que Naeka peut faire pour vous

Des skills pour votre stack et votre métier

Nous partons des consignes que votre équipe répète le plus souvent à ses agents, et des erreurs qui reviennent en review. Elles deviennent des skills : une procédure de migration, une contrainte réglementaire de votre secteur, la façon d'écrire un test dans votre projet.

Un agent de review qui applique votre REVIEW.md

Nous écrivons un agent de relecture qui suit les règles de votre REVIEW.md : ce qu'il doit vérifier en priorité, ce qui bloque une merge request, ce qui n'est qu'une remarque. Il relit chaque modification avec les mêmes critères, qu'elle vienne d'un agent ou d'un développeur.

Des commandes pour vos process

Une commande de release, par exemple, prépare le changelog, le numéro de version, le tag et la merge request exactement comme votre équipe le fait aujourd'hui à la main.

Un plugin d'équipe dans votre dépôt Git

Nous regroupons le tout dans un plugin versionné dans un dépôt Git qui vous appartient. Votre équipe l'installe, le relit et le modifie comme n'importe quel code, avec ou sans nous.

Des skills mesurés

Nous prenons quelques tâches réelles de votre backlog, nous les confions à l'agent avec et sans le skill, et nous comparons les résultats : les tests qui passent, ce que la relecture a dû reprendre, le temps passé. Un skill qui n'apporte rien est corrigé ou supprimé.

La formation de votre équipe

Nous formons vos développeurs à écrire leurs propres skills : repérer une consigne qui mérite d'en devenir un, écrire une description qui se déclenche au bon moment, tester le résultat. Nous leur apprenons aussi à lire un skill trouvé en ligne avant de l'installer, parce que ses scripts tournent avec les droits du développeur. Pour la méthode de travail autour des agents, voir notre page agentic coding.

---

Vous voulez des skills et des plugins pour votre équipe ?

Contactez-nous. Nous commençons en général par relever les consignes que vos développeurs répètent le plus à leurs agents, nous en faisons un premier skill, et nous mesurons ce qu'il change sur quelques tâches de votre backlog.