Créer des skills C# réutilisables
Capitaliser ses conventions C# dans des skills réutilisables : la description qui déclenche, la divulgation progressive qui préserve le contexte, et la frontière skill / CLAUDE.md. Les briques de l'Agentic Layer, sans sur-ingénierie.
Une skill, c’est quoi (et ce que ce n’est pas)
Une skill est un paquet réutilisable que l’agent charge à la demande pour accomplir un type de tâche. Elle regroupe du savoir-faire (procédures, conventions), éventuellement des scripts et des assets, derrière un point d’entrée unique : le fichier SKILL.md.
Ce n’est ni un modèle entraîné sur ton code, ni un raccourci, ni un remplaçant du CLAUDE.md. Une skill n’apprend rien au modèle : elle lui fournit du contexte et une marche à suivre, au bon moment.
Point clé : Capitaliser une convention dans une skill, c’est écrire une fois ce que tu réexpliquerais sinon à chaque session. Ton savoir-faire C# devient une brique réutilisable entre projets.
Anatomie : la description déclenche tout
Une skill minimale, c’est un SKILL.md avec un frontmatter (name + description) et un corps. On peut y ajouter des dossiers references/, scripts/, assets/.
Pour décider si une skill s’applique, l’agent lit sa description — pas son corps. Le corps n’entre dans le contexte que si la skill se déclenche. C’est le principe de divulgation progressive (progressive disclosure).
Point clé : Une description claire et explicite (mentionnant les phrases-déclencheurs typiques) vaut plus, pour le déclenchement, que mille lignes de corps que personne ne lira tant que la skill ne fire pas.
---
name: ddd-aggregate-from-spec
description: Genere un aggregate DDD (racine, invariants,
methodes metier) a partir d'une spec. A utiliser quand on
demande "cree un aggregate", "modelise cette regle en DDD".
---
# Generation d'aggregate DDD
- Toute modification passe par la racine.
- Les invariants sont proteges par des methodes metier,
jamais par des setters publics.
- Un test exprime chaque invariant.
Skill, CLAUDE.md ou slash command ?
Les trois encodent du savoir-faire, mais ne se chargent pas pareil. Choisir le bon support, c’est d’abord une question d’économie de contexte.
| Support | Chargement | Bon pour |
|---|---|---|
CLAUDE.md | Automatique, à chaque session | Conventions permanentes du projet (toujours utiles, donc à garder court) |
| Slash command | Manuel, quand tu l’invoques | Un workflow que tu déclenches toi-même (/review) |
| Skill | À la demande, sur match de description | Une capacité spécialisée et occasionnelle (knowledge + scripts + assets) |
Point clé : Règle simple — toujours utile et court va dans le
CLAUDE.md; occasionnel et spécialisé va dans une skill ; déclenché à la main, c’est un slash command.
Concevoir une skill C# réutilisable
Une bonne skill capture le savoir stable et agnostique au projet : la forme d’un aggregate, la protection des invariants, le découpage port/adapter, les conventions de test. Les détails propres à un dépôt (namespaces, arborescence, noms de classes) restent dans le CLAUDE.md de chaque projet.
Point clé : Même instinct qu’un port hexagonal : la skill décrit le quoi (le pattern, le contrat), le projet fournit le où et le comment. Cette séparation est ce qui rend la skill portable d’un repo à l’autre.
Attention — coder en dur le projet courant. Mettre tes namespaces, chemins et noms de classes actuels dans le
SKILL.mdcouple la skill à un seul repo et tue la réutilisabilité. Garde le générique dans la skill, le spécifique dans le projet.
Skills et Agentic Layer : capitaliser sans sur-ingénierer
Empilées, tes skills forment une couche agentique : un ensemble de capacités standardisées, avec garde-fous et observabilité, partageable dans l’équipe. Mais cette couche émerge, elle ne se construit pas le premier jour.
Point clé : Elle se justifie quand plusieurs devs utilisent des agents au quotidien et que les mêmes workflows reviennent (review, TDD, scaffolding). Le coût ou le risque finit par payer la standardisation.
Attention — trop de skills, descriptions floues. Le déclenchement repose sur la capacité de l’agent à distinguer les descriptions. Trente skills aux descriptions vagues et qui se chevauchent : l’agent fire la mauvaise ou rate la bonne. Peu de skills, chacune avec une description nette et distincte. Désinstalle ce que tu n’utilises pas.
Pour un dev solo qui démarre, un CLAUDE.md affûté et des tests couvrent déjà l’essentiel. Ajoute des skills quand elles paient leur coût — la simplicité d’abord, la structure quand elle se mérite.