Skills, agents, commandes slash, comment remettre un peu d’ordre dans l’IA de développement

Quand on commence à utiliser Claude Code, Codex ou d’autres assistants de développement, on voit très vite surgir un vocabulaire qui peut sembler opaque : agent, sous-agent, skill, commande slash, CLAUDE.md, AGENTS.md, permissions, sandbox, worktree… Pour un projet web ou applicatif, cela peut donner une impression de complexité supplémentaire. Pourtant, le sujet est plus simple qu’il n’y paraît : il s’agit surtout d’organiser le travail de l’IA dans GitHub pour éviter l’improvisation permanente.

Ces outils ne sont pas magiques. Ils ne remplacent ni l’architecture, ni la qualité des issues, ni la discipline de review. En revanche, ils peuvent rendre un projet beaucoup plus fluide si les rôles sont clairs : qui explore, qui exécute, qui relit, qui valide les règles. Tant qu’on reste dans des prompts ponctuels, l’IA fait ce qu’elle peut avec le contexte de l’instant. Dès qu’on formalise les repères dans le dépôt, la qualité devient plus stable, plus reproductible, et donc plus utile.

C'est quoi, au juste, un agent ou un sous-agent ?

Le terme “agent” semble ambitieux, alors que son usage est souvent très pragmatique. Dans un repo, un agent est simplement un assistant à qui l’on confie une mission circonscrite : explorer sans modifier, analyser un bug, préparer un plan de correction, auditer un risque sécurité, relire un diff, ou vérifier une convention.

Le sous-agent va encore plus loin dans cette logique de séparation : il opère dans un cadre plus étroit, avec un objectif, un contexte et parfois des outils autorisés spécifiques. Cette séparation devient précieuse dès que la base de code grossit. On évite de tout mélanger dans une seule conversation : exploration du legacy, patch sur un service sensible, puis génération d’un résumé de PR. Chaque rôle travaille dans sa boîte, puis remonte un résultat exploitable.

L’idée importante : un agent n’est pas un “super prompt”. C’est un rôle de travail. Et comme pour une équipe humaine, la qualité dépend de la clarté de mission, des limites et du passage de relais.

Et une skill, c'est quoi alors ?

Une skill, c’est une procédure documentée pour l’IA. Là où l’agent décrit qui fait quoi, la skill décrit comment exécuter une tâche récurrente avec cohérence. Elle contient des étapes, des points de contrôle, des fichiers à consulter, des commandes à lancer, des erreurs fréquentes à éviter et un format de sortie attendu.

Concrètement, si vous répétez souvent les mêmes demandes (review de PR, triage d’issue, préparation de release, audit accessibilité), la skill vous évite de retaper à chaque fois une longue instruction. La méthode devient versionnée, visible, améliorable dans Git. L’équipe peut la relire comme n’importe quel composant du projet.

Le gain principal n’est pas “faire plus vite” ; c’est “faire de manière plus fiable”. Une bonne skill réduit la variabilité entre deux exécutions et transforme une bonne pratique implicite en standard explicite.

Les commandes slash dans tout ça ?

La commande slash est le point d’entrée ergonomique. Au lieu de rédiger un long prompt, vous lancez un raccourci comme /review, /fix-issue ou /ship-staging. Techniquement, elle déclenche un workflow déjà défini, souvent relié à une skill.

La différence paraît mineure, mais elle est essentielle à l’échelle d’un projet. Une commande slash bien nommée crée une interface stable entre l’humain et les procédures IA. Tout le monde appelle la même action, avec le même niveau d’exigence. Résultat : moins de dispersion, moins de formulations ambiguës, plus de continuité entre les sessions.

En pratique, retenez ceci : la commande slash n’est pas la logique métier. C’est la poignée. La logique doit rester dans des fichiers versionnés et relisibles.

Pourquoi tout cela finit dans GitHub

Ces concepts prennent de la valeur lorsqu’ils vivent dans le dépôt, pas dans une conversation isolée. GitHub joue alors le rôle d’ossature : issues pour cadrer le besoin, branches (ou worktrees) pour isoler l’exécution, pull requests pour relire et discuter, checks CI pour sécuriser la fusion.

Sans cette structure, on accumule des intentions. Avec elle, on construit une mémoire de décision. L’IA bénéficie directement de cette traçabilité : elle peut partir d’une issue claire, relier son travail à une PR, suivre des conventions explicites, et s’aligner sur des tests reproductibles.

Autrement dit, le vrai sujet n’est pas “quelle IA est la plus forte”. Le vrai sujet est “est-ce que notre repo permet un travail propre, traçable et amélioré dans le temps”.

À quoi ressemble un repo bien préparé pour Claude Code

Côté Claude Code, le point central est généralement CLAUDE.md. C’est la mémoire opérationnelle du projet : conventions critiques, commandes de test, attentes d’architecture, règles de réponse et garde-fous. Ce fichier doit rester court, concret et maintenu comme du code vivant.

Autour, le dossier .claude/ permet de répartir les responsabilités : des règles ciblées, des skills dédiées, des agents spécialisés et des réglages d’accès. Cette séparation évite les documents monolithiques illisibles et favorise une maintenance incrémentale.

Une structure saine n’a pas besoin d’être massive. Elle doit surtout répondre à une logique claire : un endroit pour les règles globales, un endroit pour les procédures répétées, un endroit pour les rôles spécialisés, et des permissions explicites sur ce qui est sensible.

Et côté Codex, comment on cadre le repo ?

Chez Codex, l’ancrage repose souvent sur AGENTS.md et les consignes locales. Le principe est simple : documenter dans le repo la manière de naviguer, tester, modifier et valider. Si plusieurs fichiers AGENTS.md existent, la portée dépend de l’arborescence : un fichier plus profond peut préciser les règles d’un sous-dossier.

Cette logique épouse très bien les grands monorepos : on garde des règles globales au niveau racine, puis des instructions plus précises dans des zones techniques spécifiques. Cela permet d’éviter l’ambiguïté et de réduire les erreurs de contexte quand l’IA travaille sur des composants très différents.

En résumé, Claude Code et Codex convergent sur l’essentiel : ce qui n’est pas écrit de façon claire dans le dépôt sera vite réinterprété. Ce qui est explicite et versionné devient un cadre fiable.

Schéma — Comparison Grid (Claude Code vs Codex)

Une règle simple pour choisir entre agent, skill et commande

Pour éviter le sur-design, utilisez une règle en trois lignes :

• Agent : quand vous déléguez une mission spécialisée et bornée (exploration, audit, review, plan).
• Skill : quand vous standardisez une procédure récurrente (review PR, release, correction d’issue, contrôle accessibilité).
• Commande slash : quand vous voulez déclencher cette procédure rapidement, sans reformuler le protocole.

Le repo GitHub reste la colonne vertébrale : c’est là que vivent l’historique, les conventions, les protections, et la qualité de collaboration.

Schéma — Concept Grid (Agent vs Skill vs Commande slash)

Un exemple très concret sur un projet web

Imaginons un projet Astro ou React avec cette issue : “Ajouter un mode sombre sur les pages marketing et corriger les contrastes insuffisants”.

Étape 1 — Cadrage issue : la demande précise les pages concernées, les contraintes design, les critères d’acceptation et les tests attendus.

Étape 2 — Agent d’exploration : un agent cartographie les tokens de couleur, les layouts partagés, les composants déjà thémés, les snapshots visuels et les zones à risque.

Étape 3 — Skill d’exécution : une skill ui-review rappelle les garde-fous : contraste WCAG, non-duplication des variables, cohérence design system, responsive, dark/light parity.

Étape 4 — PR + review : le changement part en branche dédiée, passe par tests, review humaine + IA, puis fusion si la check-list qualité est validée.

Ce flux paraît simple, et c’est exactement le but. La sophistication doit rester dans la qualité d’exécution, pas dans l’empilement de concepts.

Schéma — Pipeline (issue → agent → skill → PR)

Les erreurs les plus fréquentes

La première erreur consiste à tout centraliser dans un seul fichier immense. À partir d’un certain volume, les instructions deviennent contradictoires et donc inefficaces. Mieux vaut plusieurs documents courts, chacun avec une fonction claire.

La deuxième erreur est de créer trop d’agents trop tôt. Beaucoup d’équipes ont besoin d’un ou deux rôles utiles, pas d’une taxonomie complète dès le départ.

Troisième erreur : ignorer les permissions. Si l’outil lit partout, écrit partout, exécute n’importe quelle commande et accède à des secrets par défaut, le risque opérationnel grimpe vite.

Enfin, erreur silencieuse mais fréquente : penser qu’un agent compensera un repo désorganisé. Sans issues claires, sans tests crédibles et sans discipline de review, l’IA va surtout accélérer la confusion.

Par quoi commencer sans transformer le repo en usine à gaz

Commencez minimaliste :

• Un fichier central clair (CLAUDE.md ou AGENTS.md selon l’outil principal).
• Un cadrage de permissions pour protéger secrets et dossiers sensibles.
• Une skill de review PR (tests, sécurité, régressions, lisibilité).
• Une skill alignée sur un besoin fréquent de votre produit.
• Éventuellement un agent de lecture seule pour l’exploration.

Avec ce socle, vous obtenez déjà 80 % de la valeur : meilleure qualité de contexte, moins de répétition, et une collaboration plus régulière entre humains et IA. Le reste se construit ensuite, au rythme des besoins réels du projet — pas avant.

Vous savez tout maintenant : à vos repos !