코드처럼 스킬을 조합하고 버전 관리하기

튜토리얼 · 8분 분량

대부분의 스킬 모음은 서로 아무 관계도 없는 Markdown 파일들의 폴더입니다. typescript-testing과(와) rust-testing이(가) 모두 같은 기본 테스트 철학에서 출발한다면, 그 철학은 두 파일에 중복되어 있습니다. 그리고 그것이 바뀔 때마다 두 번, 세 번, 혹은 그것을 공유하는 스킬 수만큼 고쳐야 합니다.

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과 일치)은 다음에 불러올 때 그 변경을 가져갑니다. 당신이 고친 것은 파일 하나이고, 모든 의존 스킬이 스스로 갱신되었습니다.

변경이 호환성을 깬다면 새 메이저 버전으로 공개하고, 제약을 어떻게 할지는 의존 스킬의 주인에게 맡기세요. 시맨틱 버저닝 패키지에서 쓰는 것과 같은 관례입니다.

4. 의존 스킬을 깨뜨리지 않고 옛 버전 물리기

어떤 버전이 더 이상 사람들이 그 위에 쌓기를 바라는 버전이 아니게 되면, 권장하지 않음으로 표시하세요. 여전히 거기 고정된 것은 계속 동작하고, 더 느슨한 제약을 가진 것은 다음 해석 때 자연스럽게 옮겨 갑니다.

5. 복사 대신 포크하기

다른 사람의 스킬에서 출발하지만, 실시간으로 의존하기보다 갈라져야 한다면? 공개할 때 Derived from과(와) Lineage mode: fork을(를) 쓰세요. Skilnu는 포크의 출처와 무엇을 바꿨는지에 대한 요약을 기록하므로, 두 스킬이 서로의 업데이트를 따라가지 않게 된 뒤에도 관계를 추적할 수 있습니다.

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

가장 크게 차이가 나는 곳

조합이 가장 빨리 보답하는 것은 사실상 「같은 스킬을 N번 반복한」 스킬들입니다. 하나의 테스트 또는 린트 철학의 언어별 변형, 공용 장애 런북 위에 얹는 팀별 덧입힘, 또는 더 구체적인 스킬 열몇 개가 함께 기대는 사내 스타일 가이드 같은 것들이죠. 코드에서 공용 라이브러리에 손을 뻗을 자리라면, 여기서는 또 한 번의 복사·붙여넣기 대신 의존성에 손을 뻗으세요.