Componer y versionar skills como código

Tutorial · 8 min de lectura

La mayoría de las colecciones de skills son carpetas de archivos Markdown sin relación entre sí. Si typescript-testing y rust-testing parten de la misma filosofía de pruebas, esa filosofía está duplicada en ambos archivos, y cuando cambia la editas dos veces, o tres, o tantas como skills la compartan.

Skilnu trata un skill más como un paquete: puede declarar una dependencia de otro skill, fijar una restricción de versión y recibir contenido actualizado automáticamente cuando esa dependencia publica una versión nueva. Así se usa en la práctica.

1. Publica el skill base

Escribe primero la parte compartida, aquello sobre lo que se apoyará más de un skill. Publícalo con normalidad, con una versión semántica real:

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

2. Declara una dependencia desde el skill compuesto

Cuando publiques el skill que se apoya en él, añade el skill base bajo Dependencies en lugar de pegar su contenido:

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

Skilnu resuelve la dependencia, comprueba que tú (o quien cargue el skill compuesto) tienes acceso a él y mantiene viva la referencia: el skill compuesto lee siempre el contenido actual de la dependencia dentro de tu restricción de versión, no una instantánea tomada al publicar.

3. Actualiza el skill base

Publica una versión nueva de testing-philosophy, digamos 1.1.0, añadiendo una sección sobre triaje de pruebas inestables. Todo skill que dependa de él con una restricción compatible (>=1.0.0 coincide con 1.1.0) recoge el cambio la próxima vez que se cargue. Editaste un archivo; cada skill dependiente se actualizó sola.

Si un cambio rompe la compatibilidad, publícalo como una nueva versión mayor y deja la decisión sobre la restricción a quien mantiene el skill dependiente: la misma convención que usarías con un paquete versionado semánticamente.

4. Retira versiones antiguas sin romper a quienes dependen de ellas

Cuando una versión ya no sea aquella sobre la que quieres que la gente construya, márcala como obsoleta. Lo que siga fijado a ella seguirá funcionando; lo que tenga una restricción más laxa se irá de ella de forma natural la próxima vez que se resuelva.

5. Bifurca en lugar de copiar

¿Partes del skill de otra persona pero necesitas divergir en vez de depender de él en vivo? Usa Derived from y Lineage mode: fork al publicar. Skilnu registra de dónde viene el fork y un resumen de lo que cambiaste, así la relación sigue siendo rastreable incluso después de que los dos skills dejen de seguirse mutuamente.

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

Dónde importa más

La composición compensa antes que nada en skills que son en realidad «el mismo skill, N veces»: variantes por lenguaje de una filosofía de pruebas o de linting, capas propias de un equipo sobre un manual de incidencias compartido, o guías de estilo sobre las que se apoyan una docena de skills más concretas. Allí donde en código recurrirías a una biblioteca compartida, recurre aquí a una dependencia en lugar de a otro copiar y pegar.