コードのようにスキルを組み合わせ、バージョン管理する

チュートリアル · 8 分で読めます

多くのスキル集は、互いに何の関係もない Markdown ファイルのフォルダーです。typescript-testing と rust-testing がどちらも同じ基本のテスト観から出発しているなら、その考え方は両方のファイルに重複しています。そして変更するときは、2 回、3 回、あるいは共有しているスキルの数だけ編集することになります。

Skilnu はスキルをもっとパッケージに近いものとして扱います。別のスキルへの依存を宣言し、バージョン制約を固定し、その依存が新しいバージョンを公開したときに更新された内容を自動で受け取れます。実際の使い方は次のとおりです。

1. 土台となるスキルを公開する

まず共有部分 — 複数のスキルが土台にするもの — を書きます。本物のセマンティックバージョンを付けて、普通に公開してください。

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

2. 組み合わせたスキルから依存を宣言する

それを土台にするスキルを公開するときは、内容を貼り付ける代わりに土台のスキルを Dependencies の下に追加します。

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

Skilnu は依存を解決し、あなた（またはその組み合わせスキルを読み込む人）がアクセスできることを確認し、参照を生かし続けます。組み合わせスキルは常に、あなたのバージョン制約の範囲内で依存先の現在の内容を読みます。公開時に取られたスナップショットではありません。

3. 土台のスキルを更新する

testing-philosophy の新しいバージョン — たとえば 1.1.0 — を公開し、不安定なテストの切り分けに関する節を追加します。互換性のある制約（>=1.0.0 は 1.1.0 に一致）で依存しているスキルはすべて、次に読み込まれたときにその変更を取り込みます。編集したのは 1 ファイル、更新されたのは依存側すべてです。

互換性を壊す変更なら、新しいメジャーバージョンとして公開し、制約をどうするかは依存スキルの持ち主に委ねてください。セマンティックバージョニングのパッケージで使うのと同じ慣習です。

4. 依存側を壊さずに古いバージョンを退ける

あるバージョンを、もうこれを土台にしてほしくないという状態にしたら、非推奨として印を付けます。まだそこに固定されているものは動き続け、制約が緩いものは次に解決されるときに自然と離れていきます。

5. コピーではなくフォークする

他の人のスキルから始めたいけれど、生きた依存ではなく分岐したい？ 公開時に Derived from と Lineage mode: fork を使ってください。Skilnu はフォーク元と変更点の要約を記録するので、2 つのスキルが互いの更新を追わなくなったあとも関係をたどれます。

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

これがいちばん効く場面

組み合わせがいちばん早く報われるのは、実質「同じスキルの N 回繰り返し」になっているスキルです。ひとつのテスト観や lint 観の言語別バリエーション、共有のインシデント・ランブックに載せるチーム固有の上書き、十数個のより具体的なスキルが土台にする社内スタイルガイドなど。コードで共有ライブラリに手を伸ばす場面では、ここでは次のコピー＆ペーストではなく依存に手を伸ばしてください。