Każdy, kto używa Claude Code dłużej niż kilka dni, wpada w ten sam schemat. Do każdego nowego projektu wkleja te same kilkanaście linijek kontekstu — styl kodowania, zasady code review, pipeline deploymentu, konwencje nazewnictwa. Do każdej sesji. W kółko. Aż pojawia się pytanie: czy naprawdę nie ma na to lepszego sposobu?
Spis treści
Jest. Nazywa się skills — po polsku skille, choć branżowo używa się angielskiego terminu. To jeden z mechanizmów Claude Code, który w 2025 i 2026 roku zmienił sposób, w jaki zaawansowani deweloperzy i agencje używają tego narzędzia. Zamiast przenosić kontekst ręcznie, zamykasz go w wielorazowej, przenośnej strukturze — i wywołujesz jednym poleceniem slash.
W tym artykule wyjaśniamy, czym dokładnie są skille, jak różnią się od pliku CLAUDE.md i subagentów, jak instalować gotowe skille ze społeczności oraz jak zbudować własny od zera — nawet jeśli nie masz doświadczenia z konfiguracją agentów AI.
Czym są skille w Claude Code — definicja i mechanizm działania
Skill to folder zawierający plik SKILL.md oraz opcjonalne pliki pomocnicze: skrypty, dokumentację referencyjną i szablony output. To nie plugin w sensie WordPressa, nie model, nie płatny dodatek. To otwarty format instrukcji w Markdown, który Claude ładuje dynamicznie do swojego kontekstu.
Kluczowy mechanizm to tak zwane progresywne ładowanie. Claude nie czyta całego skilla przy każdym zapytaniu — to byłoby kosztowne i wolne. Zamiast tego skanuje tylko nagłówek YAML każdego skilla (pole description), zużywając około 100 tokenów na skill. Pełne instrukcje ładuje dopiero wtedy, gdy uzna, że skill jest istotny dla bieżącego zadania — albo gdy wywołasz go bezpośrednio przez slash command.
Oficjalna dokumentacja Claude Code opisuje to precyzyjnie: „Skills extend what Claude can do. Create a SKILL.md file with instructions, and Claude adds it to its toolkit. Claude uses skills when relevant, or you can invoke one directly with /skill-name.”
To oznacza, że skille działają w dwóch trybach jednocześnie. Pierwszy tryb to automatyczny — Claude sam decyduje, kiedy skill jest potrzebny, na podstawie kontekstu rozmowy i opisu skilla. Drugi tryb to manualny — piszesz /nazwa-skilla i Claude natychmiast ładuje i wykonuje instrukcje.
Skille a CLAUDE.md — kluczowa różnica
Jeśli znasz plik CLAUDE.md, możesz zastanawiać się, po co w ogóle skille. Różnica jest fundamentalna i ma bezpośredni wpływ na koszty i jakość pracy.
CLAUDE.md to plik konfiguracyjny projektu — ładuje się przy każdej sesji, za każdym razem, do każdego zadania. Jeśli masz tam 300 linijek konwencji i zasad, Claude płaci tokenowo za ich odczytanie niezależnie od tego, czy zadanie tego wymaga. To ma sens dla informacji, które naprawdę są potrzebne zawsze — ścieżka do głównego pliku, stack technologiczny, podstawowe zasady nazewnictwa.
Skill ładuje się tylko wtedy, gdy jest potrzebny. Szczegółowa procedura code review, 200-linijkowy checklist bezpieczeństwa, instrukcja generowania dokumentacji — to idealne kandydaty na skille, a nie na CLAUDE.md. Długi materiał referencyjny kosztuje praktycznie nic, dopóki nie jest używany. Dokumentacja Anthropic ujmuje to wprost: skill powinien powstawać wtedy, gdy sekcja CLAUDE.md „wyrosła w procedurę zamiast w fakt”.
Praktyczna zasada: CLAUDE.md to fakty o projekcie. Skill to procedury i specjalistyczna wiedza wykonawcza.
Skille a subagenty — czym się różnią
Kolejne pojęcie, które często pojawia się razem ze skillami, to subagenci. To dwa różne mechanizmy służące różnym celom.
Skill to instrukcja działająca w kontekście głównej sesji Claude Code. Kiedy wywołujesz skill, Claude nadal pracuje w tej samej rozmowie, z tym samym kontekstem — po prostu ma do dyspozycji dodatkowy zestaw instrukcji i ewentualnie skryptów. Można powiedzieć, że skill zmienia zachowanie głównego agenta na czas swojego wykonania.
Subagent to odrębna sesja Claude Code uruchomiona z własnym, izolowanym kontekstem. Kiedy główny agent spawuje subagenta, ten pracuje niezależnie — widzi tylko to, co główny agent mu przekazał, a jego wewnętrzna praca (przeszukiwanie plików, pośrednie kroki rozumowania) nie zapycha kontekstu sesji głównej. To ważne, gdy masz do przetworzenia dużo materiału lub chcesz uruchomić kilka zadań równolegle.
Interesująca synergia: subagent może korzystać ze skilli zainstalowanych w projekcie. Jeśli masz skill do code review, subagent przydzielony do review będzie z niego korzystał. To pozwala budować wyspecjalizowane workflow, w których kilka subagentów działa równolegle, każdy z własnym skillset.
Struktura skilla — co musi zawierać SKILL.md
Każdy skill ma dokładnie określoną strukturę. Rozumienie jej pozwala zarówno efektywnie wybierać gotowe skille, jak i tworzyć własne.
Plik SKILL.md składa się z dwóch części. Pierwsza to nagłówek YAML między znacznikami —, który zawiera metadane. Druga to treść Markdown z instrukcjami dla Claude.
Przykładowy nagłówek YAML wygląda następująco:
---
name: code-review
description: Przeprowadza szczegółowy code review. Używaj gdy prosisz o review,
sprawdzenie jakości kodu lub ocenę PR.
allowed-tools: Read, Grep
---
Najważniejsze pole to description. To jedyna część skilla, którą Claude czyta przed zdecydowaniem, czy skill jest istotny. Dobry opis powinien zawierać: czego skill dotyczy, kiedy go używać i jakich fraz użytkownika szukać jako trigger. Źle napisany opis = skill, który nigdy się nie odpali automatycznie.
Opcjonalne pole allowed-tools ogranicza, z jakich narzędzi Claude może korzystać podczas wykonywania skilla. To ważne z punktu widzenia bezpieczeństwa — skill do generowania dokumentacji nie potrzebuje dostępu do operacji na plikach systemowych.
Poza plikiem SKILL.md folder skilla może zawierać podkatalog scripts/ ze skryptami wykonywalnymi, references/ z dokumentacją ładowaną na żądanie i assets/ z szablonami outputu. Anthropic podkreśla, że skill to folder, nie tylko plik — całą strukturę katalogów można traktować jako narzędzie do zarządzania kontekstem.
Gdzie instalować skille — lokalizacje
Skille można instalować w dwóch miejscach, a wybór lokalizacji ma konkretne konsekwencje dla zakresu ich działania.
Skille globalne umieszcza się w katalogu ~/.claude/skills/ w katalogu domowym. Są dostępne we wszystkich projektach na danej maszynie. To idealne miejsce dla skilli związanych z indywidualnym stylem pracy — preferowany styl commit messages, osobisty checklist code review, workflow tworzenia dokumentacji.
Skille projektowe umieszcza się w katalogu .claude/skills/ w głównym katalogu projektu. Są dostępne tylko dla tego projektu. To właściwe miejsce dla skilli powiązanych z konkretnym stosem technologicznym, konwencjami firmy lub specyficznym pipeline deploymentu. Co ważne, najlepsze zespoły w 2026 roku traktują skille projektowe jak infrastrukturę repozytorium — commitują je do gita, tak aby każdy nowy contributor automatycznie miał dostęp do całego zestawu narzędzi projektu.
Folder .claude/skills/ w repozytorium to pattern, który eliminuje onboarding gap: zamiast tłumaczyć nowym deweloperom, jak używa się wewnętrznych narzędzi, po prostu klonują repo i mają wszystko gotowe.
Jak wywołać skill — slash commands
Wywołanie skilla jest proste: wystarczy wpisać /nazwa-katalogu-skilla w sesji Claude Code. Nazwa slash commanda pochodzi bezpośrednio od nazwy katalogu, w którym skill jest zapisany.
Skill można wywołać ręcznie lub czekać, aż Claude uruchomi go automatycznie. Automatyczne uruchamianie działa wtedy, gdy Claude rozpoznaje na podstawie pola description, że skill jest istotny dla bieżącego zadania. Przykład: masz skill z description „Przeprowadza code review, używaj gdy prosisz o review lub sprawdzenie PR” — Claude uruchomi go automatycznie, gdy napiszesz „zrób review tego kodu”.
Warto znać też możliwość tworzenia skilli wywoływanych ręcznie przy użyciu pola disable-model-invocation: true w nagłówku YAML. Skill z tym ustawieniem nie będzie automatycznie ładowany przez Claude — będzie dostępny wyłącznie przez jawne wywołanie slash command. To przydatne dla skilli, które chcesz kontrolować ręcznie, np. „deploy” albo „generate-changelog”.
Jak stworzyć własny skill — krok po kroku
Tworzenie własnego skilla nie wymaga znajomości programowania. Wymaga za to przemyślenia, co naprawdę chcesz zautomatyzować.
Zacznij od pytania: co wklejam do Claude Code wielokrotnie? Jeśli odpowiedź to konkretna procedura — lista kroków, checklist, szczegółowy opis workflow — masz materiał na skill.
Krok pierwszy: stwórz katalog skilla. W terminalu wpisz:
mkdir -p ~/.claude/skills/moj-skillKrok drugi: stwórz plik SKILL.md w tym katalogu. Minimalna zawartość to nagłówek YAML z polem description i treść z instrukcjami. Pamiętaj, że piszesz instrukcje dla Claude, nie dla człowieka — bądź precyzyjny, konkretny, dodaj przykłady. Dobra praktyka to sekcja Gotchas — lista typowych błędów, które Claude może popełnić bez tej wskazówki.
Krok trzeci: przetestuj skill. Uruchom Claude Code w projekcie i wywołaj skill przez /moj-skill. Obserwuj, czy Claude wykonuje dokładnie to, czego oczekujesz. Iteruj — zmień opis, dodaj przykłady, doprecyzuj instrukcje.
Krok czwarty (opcjonalny): jeśli skill wymaga zewnętrznych skryptów lub dokumentacji referencyjnej, dodaj je w podkatalogach scripts/ i references/. W treści SKILL.md wyraźnie zaznacz, kiedy Claude powinien do nich sięgać.
Anthropic udostępnia też oficjalny skill o nazwie skill-creator, który przeprowadza przez interaktywne pytania i generuje SKILL.md. To najszybszy sposób na start dla osób, które nie są pewne, jak sformułować instrukcje.
Przykłady praktycznych skilli — co warto zbudować
Żeby lepiej zrozumieć, co można zrobić ze skillami, warto zobaczyć kilka konkretnych przypadków użycia.
Skill code-review to klasyczny pierwszy skill dla programistów. Zawiera checklist sprawdzania jakości kodu, zasady bezpieczeństwa właściwe dla danego projektu, konwencje nazewnictwa i oczekiwany format outputu. Zamiast za każdym razem opisywać, jak powinien wyglądać review, wystarczy wywołać /code-review na wybranej gałęzi.
Skill commit-message-generator to kolejny popularny przykład. Wiele zespołów ma specyficzny format commit messages — prefix z numerem ticketu, kategorię zmiany, ograniczenie do 72 znaków. Skill enkapsuluje te zasady i generuje wiadomości automatycznie na podstawie git diff.
Skill dokumentacji technicznej przydaje się szczególnie agencjom i zespołom tworzącym produkty dla klientów. Skill może zawierać szablon README, styl pisania komentarzy do kodu i format opisu API — wszystko zgodne z brandbook firmy lub wymaganiami klienta.
Skill deploy-checklist to przykład skilla bezpieczeństwa — sekwencja kroków, które Claude wykonuje przed każdym deploymentem: weryfikacja zmian w konfiguracji, sprawdzenie testów, lista rzeczy do ręcznego potwierdzenia. Tutaj szczególnie przydaje się opcja disable-model-invocation: true, żeby skill nie odpalał się automatycznie, lecz tylko na jawne żądanie.
Dla twórców treści i agencji marketingowych ciekawe są skille contentowe — np. skill artykułu blogowego, który zawiera instrukcje SEO, strukturę nagłówków, zasady formatowania i wymagane elementy (meta opis, FAQ, excerpt). Zamiast wklejać te wymagania przy każdym artykule, wystarczy /blog-article.
Bezpieczeństwo skilli — o czym trzeba pamiętać
Skille mają realny dostęp do narzędzi Claude Code — mogą czytać pliki, uruchamiać skrypty, wykonywać komendy. To czyni je potężnymi, ale też potencjalnie ryzykownym wektorem ataku, jeśli zainstaluje się skill z niezaufanego źródła.
Oficjalna dokumentacja Anthropic jest jednoznaczna: należy używać wyłącznie skilli, które sami stworzyliśmy, lub tych pochodzących bezpośrednio od Anthropic. Złośliwy skill może kierować Claude do wykonywania operacji niezgodnych z jego deklarowanym celem — od wycieku danych po nieautoryzowany dostęp do systemu.
Przed zainstalowaniem jakiegokolwiek skilla ze społeczności warto przejrzeć wszystkie pliki w folderze: SKILL.md, skrypty, pliki referencyjne. Należy szukać nieoczekiwanych wywołań sieciowych, operacji na plikach poza zakresem zadania i wszelkich instrukcji, które nie mają sensu w kontekście deklarowanego celu skilla.
Pole allowed-tools w nagłówku YAML to podstawowe narzędzie ograniczania zasięgu skilla. Skill do generowania dokumentacji powinien mieć dostęp tylko do Read i Grep — nie potrzebuje Write ani możliwości uruchamiania procesów.
Skille w kontekście Claude Fable 5 i modeli frontier
Ekosystem skilli ewoluuje razem z samymi modelami. Premiera Claude Fable 5 w czerwcu 2026 roku zmieniła podejście do tego, który model uruchamia który skill.
Nie każde wywołanie skilla wymaga modelu frontier. Skille do prostej klasyfikacji, wyszukiwania w dokumentach czy generowania commit messages działają równie dobrze na tańszych modelach — Claude Haiku 4.5 czy Sonnet 4.6. Wzorzec, który pojawia się w zaawansowanych workflow, to tzw. cost-routing: szybkie i tanie modele dla zadań prostych, modele klasy Fable dla skilli wymagających długiego rozumowania, złożonych migracji kodu lub wieloetapowych analiz.
W praktyce oznacza to, że budując workflow na bazie skilli, warto rozważyć nie tylko sam skill, ale też model, który go będzie wykonywał. Claude Code pozwala na konfigurację modelu per sesja, co daje elastyczność w sterowaniu kosztami.
Skille nie są dla wszystkich i nie rozwiązują każdego problemu. Jeśli używasz Claude Code okazjonalnie, do jednorazowych zadań, inwestycja czasu w budowanie biblioteki skilli może nie być uzasadniona. Szybki prompt inline jest po prostu szybszy.
Natomiast jeśli używasz Claude Code regularnie, w powtarzalnych workflow, w teamie lub w projekcie długoterminowym — skille zmieniają regułę gry. Zamiast tracić czas na powtarzanie kontekstu, budujesz infrastrukturę wiedzy, która sama się skaluje. Każdy nowy skill to czas zaoszczędzony przy każdym kolejnym wywołaniu.
Najlepsza strategia na start to zidentyfikowanie jednego lub dwóch workflow, które powtarzasz najczęściej, i przekształcenie ich w skille. Nie trzeba budować całej biblioteki od razu — jeden działający skill jest lepszy niż dziesięć zaplanowanych.
Progresywne ładowanie, lokalizacje globalne i projektowe, integracja z subagentami, kontrola bezpieczeństwa przez allowed-tools — to wszystko sprawia, że system skilli jest dobrze zaprojektowany do realnej pracy produkcyjnej. I to właśnie dlatego najlepsze zespoły deweloperskie w 2026 roku traktują .claude/skills/ jak część infrastruktury projektu — nie jak osobisty notatnik, lecz jak repozytorium wiedzy, które dojrzewa razem z kodem.
