Skille w Claude Code — instrukcje ładowane na żądanie

01 Definicja

Czym właściwie jest skill?

Skill to folder z instrukcjami. Obowiązkowo mieszka w nim plik SKILL.md, a opcjonalnie wszystko, co przydaje się przy zadaniu: skrypty, szablony, przykłady, dokumentacja API, checklisty.

Różnica wobec zwykłego promptu polega na tym, że skill żyje na dysku i jest wielokrotnego użytku. Wrzucasz go do repozytorium, rozdajesz zespołowi przez plugin, wersjonujesz w gicie. Wiedza o tym, „jak się to u nas robi”, przestaje siedzieć w głowie jednej osoby.

Najkrócej

Prompt mówi Claude'owi, co ma zrobić teraz. Skill mówi, jak to się robi u was — za każdym razem.

02 Anatomia
pliku

Budowa pliku SKILL.md

Na górze znajduje się frontmatter w YAML-u z dwoma kluczowymi polami, poniżej — zwykły markdown z instrukcjami.

---
name: deploy-produkcja
description: Wdraża aplikację na produkcję. Używaj gdy user
  mówi "wypuść na produkcję", "zrób deploy", "wdróż zmiany".
---

# Deploy na produkcję

## Przed wdrożeniem
1. Sprawdź, czy testy przechodzą: `npm test`
2. Zweryfikuj, czy branch jest zsynchronizowany z `main`

## Wdrożenie
Uruchom `./scripts/deploy.sh` i obserwuj logi...

Pole description jest najważniejsze

To jedyna rzecz, którą Claude widzi zanim zdecyduje, czy sięgnąć po skill. Musi więc odpowiadać na dwa pytania naraz: co ten skill robi oraz kiedy go użyć. Warto wpisać w nią konkretne sformułowania, których naprawdę używacie w rozmowie.

Pliki towarzyszące

Obok SKILL.md możesz trzymać katalogi scripts/, references/ czy assets/. Claude sięgnie do nich dopiero wtedy, gdy instrukcja go tam odeśle.

03 Mechanika
ładowania

Trzy poziomy ujawniania treści

To sedno całego pomysłu. Skille nie zapychają kontekstu, bo wczytują się warstwami — dokładnie tak głęboko, jak wymaga tego zadanie.

01

Metadane

zawsze w kontekście

Claude widzi wyłącznie name i description każdego zainstalowanego skilla. To wystarczy, by rozpoznać, że dany skill pasuje do zadania.

02

Treść SKILL.md

po dopasowaniu

Gdy zadanie pasuje do opisu, dopiero wtedy wczytywana jest pełna instrukcja i staje się planem działania na tę turę.

03

Pliki dodatkowe

punktowo, w trakcie

Dokumentacja, szablony i skrypty czytane są dopiero wtedy, gdy instrukcja o nich mówi. Skrypt może się nawet wykonać, nie trafiając wcale do kontekstu.

Konsekwencja

Dzięki takiemu podziałowi możesz mieć kilkadziesiąt skilli naraz, a kontekstem płacisz wyłącznie za ten jeden, którego akurat użyto.

04 Lokalizacja

Gdzie mieszkają skille

Zasięg skilla wynika wprost z tego, gdzie leży jego folder.

~/.claude/skills/nazwa/SKILL.md

Skille osobiste — dostępne w każdym Twoim projekcie, na tej maszynie.

.claude/skills/nazwa/SKILL.md

Skille projektowe — commitowane do repozytorium, więc ma je każdy członek zespołu.

plugin/skills/nazwa/SKILL.md

Skille z pluginu — instalowane z marketplace jednym poleceniem i aktualizowane centralnie.

05 Wywołanie

Jak się je uruchamia

Tryb automatyczny

Opisujesz zadanie normalnym językiem, a Claude sam dopasowuje skill po polu description. Nie musisz pamiętać nazw — to główny tryb pracy.

Tryb jawny

Gdy chcesz mieć pewność, że użyty zostanie konkretny skill, wywołujesz go po nazwie:

> /research-daily
> /deploy-produkcja wersja 2.4.0

Argumenty podane po nazwie trafiają do skilla jako kontekst zadania.

06 Praktyka

Kiedy warto napisać skill

Trzeci raz tłumaczysz Claude'owi ten sam proces — to najmocniejszy sygnał.
Zadanie ma ustaloną kolejność kroków, których nie wolno pomylić.
Istnieje firmowy standard: konwencja commitów, format raportu, ton komunikacji.
Robota wymaga wiedzy spoza repozytorium — API partnera, ustalenia z klientem, zasady rozliczeń.
Chcesz, żeby cały zespół robił coś identycznie, niezależnie od tego, kto siedzi przy klawiaturze.

Zasada kciuka

Jeden skill = jedno zadanie. Zamiast budować molocha „obsługa projektu”, napisz trzy osobne, precyzyjnie opisane skille — trafność dopasowania będzie wtedy znacznie wyższa.