Composer et versionner des skills comme du code

Tutoriel · 8 min de lecture

La plupart des collections de skills sont des dossiers de fichiers Markdown sans lien entre eux. Si typescript-testing et rust-testing partent toutes deux de la même philosophie de test, cette philosophie est dupliquée dans les deux fichiers — et lorsqu'elle évolue, vous la modifiez deux fois, ou trois, ou autant de fois qu'il y a de skills qui la partagent.

Skilnu traite un skill davantage comme un paquet : il peut déclarer une dépendance vers un autre skill, épingler une contrainte de version et recevoir automatiquement le contenu mis à jour lorsque cette dépendance publie une nouvelle version. Voici comment vous en servir concrètement.

1. Publiez le skill de base

Écrivez d'abord la partie commune — celle sur laquelle plusieurs skills s'appuieront. Publiez-la normalement, avec une vraie version sémantique :

name: testing-philosophy
description: Shared testing principles: what to test, what not to, naming conventions.
version: 1.0.0

2. Déclarez une dépendance depuis le skill composé

Lorsque vous publiez le skill qui s'appuie dessus, ajoutez le skill de base sous Dependencies au lieu d'en coller le contenu :

- type: skill
  id: yourhandle/testing-philosophy
  version_constraint: ">=1.0.0"
  optional: false

Skilnu résout la dépendance, vérifie que vous (ou quiconque charge le skill composé) y avez accès, et maintient la référence vivante — le skill composé lit toujours le contenu actuel de la dépendance dans les limites de votre contrainte de version, et non un instantané pris au moment de la publication.

3. Mettez à jour le skill de base

Publiez une nouvelle version de testing-philosophy — disons 1.1.0, ajoutant une section sur le tri des tests instables. Tout skill qui en dépend avec une contrainte compatible (>=1.0.0 correspond à 1.1.0) récupère la modification au chargement suivant. Vous avez modifié un fichier ; toutes les skills dépendants se sont mis à jour d'eux-mêmes.

Si un changement casse la compatibilité, publiez-le comme nouvelle version majeure et laissez la décision de contrainte à la personne responsable du skill dépendant — la même convention que pour un paquet en versionnement sémantique.

4. Retirez les anciennes versions sans casser les dépendances

Lorsqu'une version n'est plus celle sur laquelle vous souhaitez que l'on s'appuie, marquez-la comme dépréciée. Tout ce qui y reste épinglé continue de fonctionner ; tout ce qui a une contrainte plus souple s'en détache naturellement à la résolution suivante.

5. Forkez plutôt que de copier

Vous partez du skill de quelqu'un d'autre mais devez diverger plutôt qu'en dépendre en direct ? Utilisez Derived from et Lineage mode: fork au moment de publier. Skilnu enregistre l'origine du fork et un résumé des changements — la relation reste ainsi traçable même une fois que les deux skills cessent de suivre les mises à jour l'une de l'autre.

derived_from: origin-publisher/base-skill@1.4.2
lineage_mode: fork
lineage_changelog: Added stricter validation and examples

Là où cela compte le plus

La composition est particulièrement payante pour les skills qui sont en réalité « le même skill, N fois » — variantes par langage d'une philosophie de test ou de lint, surcouches propres à une équipe sur un guide d'intervention partagé, ou chartes maison sur lesquelles une douzaine de skills plus spécifiques s'appuient. Partout où vous iriez chercher une bibliothèque partagée dans du code, cherchez ici une dépendance plutôt qu'un nouveau copier-coller.