Skills zusammenstellen und versionieren wie Code

Tutorial · 8 Min. Lesezeit

Die meisten Skill-Sammlungen sind Ordner voller Markdown-Dateien ohne Bezug zueinander. Wenn typescript-testing und rust-testing beide von derselben Testphilosophie ausgehen, ist diese Philosophie in beiden Dateien dupliziert — und wenn sie sich ändert, bearbeiten Sie sie zweimal, oder dreimal, oder so oft, wie es Skills gibt, die sie teilen.

Skilnu behandelt einen Skill eher wie ein Paket: Er kann eine Abhängigkeit zu einem anderen Skill deklarieren, eine Versionsbedingung festlegen und automatisch aktualisierte Inhalte bekommen, wenn diese Abhängigkeit eine neue Version veröffentlicht. So nutzen Sie das konkret.

1. Den Basis-Skill veröffentlichen

Schreiben Sie zuerst den gemeinsamen Teil — das, worauf mehr als ein Skill aufbauen wird. Veröffentlichen Sie ihn ganz normal, mit einer echten semantischen Version:

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

2. Eine Abhängigkeit aus dem zusammengesetzten Skill deklarieren

Wenn Sie den darauf aufbauenden Skill veröffentlichen, tragen Sie den Basis-Skill unter Dependencies ein, statt seinen Inhalt hineinzukopieren:

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

Skilnu löst die Abhängigkeit auf, prüft, ob Sie (oder wer auch immer den zusammengesetzten Skill lädt) Zugriff darauf haben, und hält die Referenz lebendig — der zusammengesetzte Skill liest stets den aktuellen Inhalt der Abhängigkeit innerhalb Ihrer Versionsbedingung, keine Momentaufnahme vom Zeitpunkt der Veröffentlichung.

3. Den Basis-Skill aktualisieren

Veröffentlichen Sie eine neue Version von testing-philosophy — sagen wir 1.1.0, mit einem Abschnitt über den Umgang mit instabilen Tests. Jeder Skill, der mit einer kompatiblen Bedingung davon abhängt (>=1.0.0 passt auf 1.1.0), übernimmt die Änderung beim nächsten Laden. Sie haben eine Datei bearbeitet; jeder abhängige Skill hat sich selbst aktualisiert.

Ist eine Änderung brechend, veröffentlichen Sie sie als neue Hauptversion und überlassen Sie die Entscheidung über die Bedingung derjenigen Person, der der abhängige Skill gehört — dieselbe Konvention, die Sie bei einem Paket mit semantischer Versionierung anwenden würden.

4. Alte Versionen zurückziehen, ohne Abhängige zu brechen

Wenn eine Version nicht mehr die ist, auf der andere aufbauen sollen, markieren Sie sie als veraltet. Alles, was noch darauf festgelegt ist, läuft weiter; alles mit einer lockereren Bedingung wandert beim nächsten Auflösen von selbst weiter.

5. Forken statt kopieren

Sie beginnen mit dem Skill einer anderen Person, müssen aber abweichen, statt live davon abzuhängen? Nutzen Sie beim Veröffentlichen Derived from und Lineage mode: fork. Skilnu hält fest, woher der Fork stammt, samt einer Zusammenfassung Ihrer Änderungen — die Beziehung bleibt also nachvollziehbar, auch wenn die beiden Skills einander nicht mehr folgen.

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

Wo das am meisten zählt

Komposition zahlt sich am schnellsten bei Skills aus, die eigentlich „derselbe Skill, N-mal“ sind — sprachspezifische Varianten einer Test- oder Lint-Philosophie, teamspezifische Auflagen auf einem gemeinsamen Incident-Runbook, oder Hausstile, auf denen ein Dutzend spezialisierterer Skills aufbaut. Überall dort, wo Sie im Code zu einer gemeinsamen Bibliothek greifen würden, greifen Sie hier zu einer Abhängigkeit statt zum nächsten Copy-and-paste.