Comporre e versionare skills come codice

Tutorial · 8 min di lettura

La maggior parte delle raccolte di skills sono cartelle di file Markdown senza relazione tra loro. Se typescript-testing e rust-testing partono entrambe dalla stessa filosofia di test, quella filosofia è duplicata in entrambi i file — e quando cambia la modifichi due volte, o tre, o tante quante sono le skills che la condividono.

Skilnu tratta una skill più come un pacchetto: può dichiarare una dipendenza da un'altra skill, fissare un vincolo di versione e ricevere automaticamente il contenuto aggiornato quando quella dipendenza pubblica una nuova versione. Ecco come usarlo davvero.

1. Pubblica la skill di base

Scrivi prima la parte condivisa, quella su cui si appoggerà più di una skill. Pubblicala normalmente, con una vera versione semantica:

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

2. Dichiara una dipendenza dalla skill composta

Quando pubblichi la skill che vi si appoggia, aggiungi la skill di base sotto Dependencies invece di incollarne il contenuto:

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

Skilnu risolve la dipendenza, verifica che tu (o chiunque carichi la skill composta) vi abbia accesso e mantiene viva la referenza: la skill composta legge sempre il contenuto attuale della dipendenza entro il tuo vincolo di versione, non un'istantanea presa al momento della pubblicazione.

3. Aggiorna la skill di base

Pubblica una nuova versione di testing-philosophy — poniamo 1.1.0, aggiungendo una sezione sulla gestione dei test instabili. Ogni skill che ne dipende con un vincolo compatibile (>=1.0.0 corrisponde a 1.1.0) raccoglie la modifica al caricamento successivo. Hai modificato un file; ogni skill dipendente si è aggiornata da sola.

Se una modifica rompe la compatibilità, pubblicala come nuova versione maggiore e lascia la decisione sul vincolo a chi possiede la skill dipendente: la stessa convenzione che useresti per un pacchetto con versionamento semantico.

4. Ritira le vecchie versioni senza rompere le dipendenti

Quando una versione non è più quella su cui vuoi che gli altri costruiscano, contrassegnala come deprecata. Tutto ciò che vi resta ancorato continua a funzionare; tutto ciò che ha un vincolo più permissivo se ne allontana naturalmente alla risoluzione successiva.

5. Forka invece di copiare

Parti dalla skill di qualcun altro ma devi divergere anziché dipenderne in tempo reale? Usa Derived from e Lineage mode: fork al momento della pubblicazione. Skilnu registra da dove proviene il fork e un riepilogo di ciò che hai cambiato, così la relazione resta tracciabile anche dopo che le due skills smettono di seguirsi a vicenda.

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

Dove conta di più

La composizione ripaga prima di tutto nelle skills che sono in realtà «la stessa skill, N volte»: varianti per linguaggio di una filosofia di test o di lint, sovrapposizioni specifiche di una squadra su un runbook condiviso, o guide di stile su cui si appoggiano una dozzina di skills più mirate. Ovunque nel codice ricorreresti a una libreria condivisa, qui ricorri a una dipendenza invece che a un altro copia-e-incolla.