Lekcja 3 · Koszt na żądanie

Skille: kiedy CLAUDE.md już nie wystarcza

W Lekcji 2 padło zdanie: jeśli instrukcja w CLAUDE.md urosła w wieloetapową procedurę używaną tylko czasami — to sygnał, że powinna stać się skillem. Ta lekcja pokazuje dlaczego to działa i jak to zrobić.

Polecane źródło Extend Claude with skills — Claude Code Docs — pełna specyfikacja SKILL.md, frontmatteru i wzorców zaawansowanych.

Ten sam mechanizm, inny moment płatności

Skill to nazwany pakiet instrukcji w pliku SKILL.md, wywoływany komendą /nazwa-skilla albo automatycznie przez Claude, gdy pasuje do rozmowy. Kluczowa różnica względem CLAUDE.md nie leży w tym co można w nim napisać — leży w tym, kiedy ten tekst faktycznie wchodzi do kontekstu.

CLAUDE.mdSkill
Co jest zawsze w kontekściecała treść plikutylko krótki description
Kiedy wchodzi pełna treśćzawsze, na starcie sesjidopiero przy wywołaniu
Dobre dofaktów obowiązujących zawszeprocedur i wiedzy potrzebnej czasami
Kluczowy wniosek: przenosząc wieloetapową procedurę albo długi materiał referencyjny z CLAUDE.md do skilla, nie tracisz nic — zyskujesz to, że płacisz za te tokeny tylko w sesjach, w których faktycznie z nich korzystasz.

Anatomia SKILL.md

Plik ma dwie części: frontmatter YAML (konfiguracja) i treść markdown (instrukcje, które zobaczy Claude po wywołaniu). Tylko description jest zalecane — Claude używa go, żeby zdecydować, kiedy sam sięgnąć po skill.

PoleDo czego służy
descriptionCo robi skill i kiedy go użyć — jedyna część zawsze widoczna w kontekście
disable-model-invocationtrue = tylko człowiek wywołuje, Claude nigdy sam
user-invocablefalse = ukryty z menu /, tylko Claude może go użyć
allowed-toolsNarzędzia dozwolone bez pytania o zgodę, gdy skill jest aktywny
argument-hintPodpowiedź parametrów pokazywana przy autouzupełnianiu

Kiedy tylko Ty, kiedy tylko Claude

Domyślnie zarówno Ty, jak i Claude możecie wywołać dowolny skill. Dla akcji z efektami ubocznymi — deploy, commit, wysyłka wiadomości — ustaw disable-model-invocation: true, żeby Claude nie zdecydował sam, że "kod wygląda gotowy" i uruchomił coś nieodwracalnego. Odwrotnie: user-invocable: false dla wiedzy w tle, której nikt nie wywołuje ręcznie (np. opis starego systemu), ale Claude powinien z niej korzystać, gdy trafi na temat.

Dynamiczna treść: !`komenda`

Linijka w formie !`git diff HEAD` wykonuje się zanim Claude w ogóle zobaczy treść skilla — jej wynik podmienia placeholder, więc Claude dostaje gotowe, aktualne dane, a nie polecenie do wykonania. Przydatne, gdy skill ma działać na żywych danych (diff, status, wynik komendy).

Parametry: $ARGUMENTS

To, co wpiszesz po nazwie skilla, trafia do $ARGUMENTS (albo $0, $1 dla pojedynczych argumentów). /fix-issue 123 ze skillem zawierającym Napraw issue $ARGUMENTS wygeneruje dla Claude: "Napraw issue 123".

Gdzie mieszka skill

LokalizacjaDostępny dla
~/.claude/skills/nazwa/SKILL.mdtylko Ciebie, we wszystkich projektach
.claude/skills/nazwa/SKILL.mdtego projektu — wersjonuj w git, żeby zespół go dostał

To ten drugi wiersz łączy się z Twoją misją: skille projektowe w .claude/skills/, zacommitowane do repo, to sposób na współdzielenie wypracowanych workflow z całym zespołem — nie tylko z Tobą.

Zadanie praktyczne — napiszmy skill razem

Ten workspace ma powtarzalną procedurę: tworzenie nowej lekcji zawsze wymaga tego samego szkieletu HTML (eyebrow, lede, source-rec, quiz, ask-teacher, lesson-nav) i tej samej numeracji. To dokładnie kandydat na skill.

Napiszmy razem .claude/skills/new-lesson/SKILL.md, który:

  1. Wywołuje się tylko ręcznie (disable-model-invocation: true) — Ty decydujesz kiedy powstaje nowa lekcja, nie Claude
  2. Przyjmuje temat lekcji jako argument
  3. Znajduje najwyższy numer w lessons/ i tworzy kolejny plik z poprawnym szkieletem, linkujący ../assets/style.css i ../assets/quiz.js

Daj znać, jak chcesz się nazywał skill i czy pasuje Ci ten zakres — zaproponuję konkretną treść SKILL.md do akceptacji.

Sprawdź się

1. Co różni fundamentalnie CLAUDE.md i skill pod względem kosztu kontekstu?

CLAUDE.md ładuje się w całości na starcie każdej sesji. Ze skilla zawsze widoczny jest tylko krótki opis — pełna treść wchodzi do kontekstu dopiero przy realnym wywołaniu.

2. Chcesz, żeby tylko Ty mógł uruchomić dany skill (np. deploy), nigdy Claude automatycznie. Co ustawiasz?

disable-model-invocation: true usuwa skill z listy tego, co Claude może wywołać samo — zostaje dostępny wyłącznie przez ręczne /nazwa. To odwrotność user-invocable: false, które chowa skill przed Tobą, ale nie przed Claude.

3. Skill ma user-invocable: false (bez disable-model-invocation). Co to oznacza w praktyce?

To pole ukrywa skill z menu /, więc Ty nie wpiszesz go ręcznie — ale Claude nadal widzi jego opis i może po niego sięgnąć, gdy temat pasuje. Dobre dla wiedzy w tle, a nie akcji do ręcznego odpalenia.

4. W SKILL.md masz linijkę !`git diff HEAD`. Co się z nią dzieje?

To preprocessing: komenda uruchamia się przed wysłaniem treści skilla do Claude, a jej wynik podmienia placeholder. Claude widzi już gotowe dane, nigdy samą instrukcję do wykonania.

5. Gdzie umieścisz skill, żeby cały zespół miał do niego dostęp przez git?

Skille w ~/.claude/skills/ są tylko Twoje, na każdym projekcie. Żeby zespół dostał ten sam skill przez zwykłe git pull, musi on siedzieć w .claude/skills/ w repo projektu.
Coś niejasne? Zapytaj mnie wprost — mogę pomóc dobrać opis skilla tak, żeby Claude trafnie go wywoływał, albo przejść dalej do subagentów.
← Lekcja 2: CLAUDE.md pod lupą Następna lekcja: Subagenci — osobne okno kontekstu →