Claude Code Skills — czym są, jak działają i jak napisać własny skill od zera

Czym są Skills w Claude Code i dlaczego zmieniają sposób pracy

Jeśli używasz Claude Code jako codziennego narzędzia do programowania, w pewnym momencie zaczynasz powtarzać te same instrukcje. „Uruchom serwer developerski i sprawdź czy strona działa." „Zrób review tego diffa pod kątem błędów bezpieczeństwa." „Przejrzyj historię commitów i powiedz co zostało zmienione." Skills to mechanizm, który pozwala zamknąć taki workflow w jedną komendę slash — /run, /code-review, /security-review — i wywoływać go jednym wpisem zamiast za każdym razem tłumaczyć Claude'owi od nowa, co ma robić.

Skill to w gruncie rzeczy plik tekstowy w formacie Markdown przechowywany w folderze .claude/skills/. Nie ma w nim magii — tylko dobrze napisana instrukcja dla modelu, co ma zrobić, gdy wywołasz daną komendę. Siła tkwi w tym, że ta instrukcja może być bardzo precyzyjna, uwzględniać specyficzny stack technologiczny projektu, dostęp do konkretnych narzędzi i kroków które Claude musi wykonać w odpowiedniej kolejności. Raz napisany skill działa jak żywy playbook — powtarzalny, przewidywalny, łatwy do poprawienia.

Skills istnieją na dwóch poziomach. Skille wbudowane (built-in) to te, które Anthropic dostarcza razem z Claude Code — od /run przez /code-review po /init. Skille projektowe to własne pliki SKILL.md tworzone w repozytorium, specyficzne dla danej aplikacji lub zespołu. Oba typy działają dokładnie tak samo — różni je tylko to, kto je napisał i gdzie są przechowywane.

Wbudowane skills Claude Code — pełna lista z opisem

Claude Code przychodzi z zestawem gotowych skills pokrywających najczęstsze potrzeby przy pracy z kodem. Warto je znać, zanim zaczniesz pisać własne — często okazuje się, że to czego szukasz już istnieje.

/run — uruchamia aplikację i weryfikuje czy zmiana działa w praktyce. Skill szuka najpierw pliku SKILL.md w repozytorium opisującego jak odpalić projekt, a jeśli go nie ma — sam rozpoznaje typ aplikacji (serwer, CLI, Electron, przeglądarka) i dobiera odpowiednią metodę. Kończy się zrzutem ekranu lub analizą outputu, nie tylko komunikatem „serwer uruchomiony". Użyj go gdy chcesz mieć pewność że zmiana działa zanim ją commitujesz.

/code-review — przegląda aktualny diff pod kątem błędów, uproszczeń i problemów z wydajnością. Przyjmuje opcjonalne parametry: poziom dokładności (low, medium, high, ultra) oraz flagi --comment (dodaje komentarze inline do PR) i --fix (automatycznie nanosi poprawki na pliki). Tryb ultra używa wielu agentów do równoległego przeglądu — najdokładniejszy, ale też najwolniejszy.

/security-review — dedykowany przegląd bezpieczeństwa zmian na bieżącym branchu. Skupia się na podatnościach OWASP Top 10 — SQL injection, XSS, command injection, insecure deserialization, broken authentication. Zwraca listę konkretnych znalezisk z lokalizacją w kodzie.

/simplify — szuka w zmienionym kodzie miejsc do uproszczenia, usunięcia duplikacji i poprawy czytelności bez zmiany funkcjonalności. Nie poluje na bugi — od tego jest /code-review. Nanosi znalezione poprawki automatycznie.

/verify — uruchamia aplikację i weryfikuje, że konkretna zmiana zachowuje się tak jak powinna. Przydatny gdy chcesz potwierdzić że fix naprawdę naprawił problem zanim go wypchniesz.

/init — tworzy plik CLAUDE.md z dokumentacją projektu. Przeskanuje strukturę repozytorium, przeczyta kluczowe pliki konfiguracyjne i wygeneruje zwięzły dokument opisujący stack, konwencje i specyficzne wymagania. Ten plik jest automatycznie ładowany do kontekstu Claude'a przy każdej sesji — raz stworzony, eliminuje konieczność wyjaśniania projektu od nowa.

/loop — wykonuje zadanie cyklicznie w zadanym interwale. Przydatny do monitorowania deployu, polling statusu CI, automatycznego sprawdzania czy testy przechodzą po zmianach. Wywołujesz go jako /loop 5m /code-review — co 5 minut robi review zmian.

/schedule — tworzy zaplanowane zadania wykonywane przez zdalnych agentów według harmonogramu cron. W odróżnieniu od /loop działa bez otwartej sesji — zadanie jest rejestrowane i wykonuje się autonomicznie o wskazanej godzinie.

/update-config — konfiguruje plik settings.json Claude Code: hooki, uprawnienia, zmienne środowiskowe. Używasz go gdy chcesz ustawić automatyczne zachowania — „przed każdym commitem uruchom linter" albo „pozwól na npm bez pytania o zgodę".

/claude-api — reference dla Anthropic API i SDK. Wymagany gdy pracujesz z API Claude'a w kodzie — zawiera aktualne identyfikatory modeli, parametry, przykłady streamingu, tool use i multi-agent. Skill sam się ładuje gdy wykryje że pytanie dotyczy integracji z API Anthropica.

Jak wywołać skill — składnia i argumenty

Wywołanie skilla jest proste: wpisujesz /nazwa-skilla w prompcie Claude Code. Większość skillów przyjmuje opcjonalne argumenty po spacji — /code-review high, /code-review ultra --fix, /loop 2m /run. Argumenty są opisane w pliku SKILL.md każdego skilla, ale nie musisz ich znać na pamięć — Claude Code podpowie co jest dostępne jeśli wpiszesz sam /code-review bez nic.

Skille są ładowane leniwie — ich pełna definicja trafia do kontekstu dopiero w momencie wywołania. Oznacza to, że samo istnienie 20 skillów w projekcie nie zajmuje miejsca w oknie kontekstu zanim ich nie użyjesz. To ważne przy długich sesjach gdzie kontekst jest cenny.

Struktura pliku SKILL.md — co musi zawierać własny skill

Każdy skill to plik Markdown z metadanymi YAML frontmatter i treścią będącą instrukcją dla modelu. Plik ląduje w .claude/skills/nazwa-skilla/SKILL.md. Nazwa folderu staje się nazwą komendy slash.

Frontmatter wymaga pola description — jednozdaniowy opis tego co skill robi. Ten opis pojawia się gdy Claude Code wyświetla listę dostępnych skillów i jest używany do decydowania czy skill pasuje do danego zapytania. Im bardziej precyzyjny opis, tym trafniejsze automatyczne sugestie.

Treść pliku to instrukcja pisana tak jak piszesz system prompt dla modelu — w naturalnym języku, precyzyjnie, z przykładami jeśli są potrzebne. Możesz w niej odwoływać się do innych plików przez ich ścieżkę, opisywać kroki do wykonania, definiować format outputu i warunki sukcesu. Dobry skill jest samowystarczalny — nowy agent startujący bez żadnego kontekstu sesji powinien być w stanie go wykonać wyłącznie na podstawie treści pliku.

Jedna zasada: skill powinien być napisany zakładając, że model nie widzi historii rozmowy. Skills są często wykonywane przez świeże instancje agentów — bez kontekstu sesji, bez pamięci poprzednich kroków. Wszystko czego skill potrzebuje musi być albo zawarte w jego treści, albo możliwe do odkrycia przez odczytanie plików z dysku.

Skille projektowe vs. skille użytkownika — gdzie trzymać co

Skille dzielą się na dwa zasięgi: projektowy i użytkownika. Skille projektowe mieszkają w .claude/skills/ wewnątrz repozytorium — są commitowane razem z kodem i dostępne dla każdego, kto pracuje na tym repo. To właściwe miejsce dla skillów specyficznych dla projektu: jak go uruchomić, jak deployować na staging, jak uruchomić testy integracyjne, jak seedować bazę danych.

Skille użytkownika mieszkają w ~/.claude/skills/ w katalogu domowym — są dostępne we wszystkich projektach na danej maszynie, niezależnie od repozytorium. To właściwe miejsce dla osobistych preferencji i narzędzi: ulubiony format code review, skrót do generowania changelog, workflow commitowania zgodny z konwencjami których używasz w każdym projekcie.

Przy konflikcie nazw — jeśli masz skill o tej samej nazwie zarówno na poziomie projektu jak i użytkownika — wygrywa skill projektowy. To deliberatna decyzja: projekt powinien być w stanie nadpisać zachowanie globalne kiedy tego wymaga.

Jak napisać własny skill od zera — praktyczny przykład

Wyobraź sobie, że pracujesz nad projektem Next.js z Supabase i za każdym razem gdy kończysz nową funkcjonalność, musisz: sprawdzić czy build przechodzi, zweryfikować typy TypeScript, uruchomić serwer i kliknąć przez nową funkcję w przeglądarce, a na końcu napisać commit message. To pięć kroków które powtarzasz dziesiątki razy w tygodniu. Idealny kandydat na skill.

Tworzysz plik .claude/skills/ship-check/SKILL.md. W frontmatter wpisujesz description: Przed commitem — sprawdź build, typy i zweryfikuj nową funkcję w przeglądarce. W treści opisujesz kolejno: uruchom npm run build i sprawdź czy nie ma błędów, uruchom npx tsc --noEmit i sprawdź błędy TypeScript, odpal serwer dev i otwórz URL funkcji której dotyczy zmiana, zrób screenshot i opisz co widzisz, zaproponuj commit message zgodny z konwencją projektu z pliku CLAUDE.md.

Od tej chwili wpisujesz /ship-check i cały ten workflow odpala się automatycznie. Jeśli build wywali się na błędzie TypeScript — skill zatrzyma się i pokaże Ci dokładnie co jest nie tak, zanim zmarnujesz czas na manualny testing. Jeśli wszystko przejdzie — dostaniesz gotowy commit message.

Generator skillów — /run-skill-generator

Claude Code ma wbudowany generator skillów. Jeśli ręcznie wykonałeś jakiś proces — uruchomiłeś aplikację przez kilka nieoczywistych kroków, zainstalowałeś zależności systemowe, ustawiłeś zmienne środowiskowe — i chcesz go zautomatyzować, możesz wywołać /run-skill-generator. Claude przeanalizuje co zrobiłeś w tej sesji i zaproponuje plik SKILL.md, który odtworzy ten proces przy przyszłych wywołaniach.

Generator jest szczególnie cenny przy projektach z niestandardowym środowiskiem — specyficznymi wersjami Node, zewnętrznymi zależnościami binarnymi, konfiguracją wymaganą przed uruchomieniem. Zamiast dokumentować to w README (który nikt nie czyta), zamieniasz to w skill który Claude wykona sam.

Skills a CLAUDE.md — różnica której nie wolno mylić

CLAUDE.md i skills to dwa różne mechanizmy służące różnym celom, choć często są mylone. CLAUDE.md to dokumentacja projektu — opisuje stack, konwencje, strukturę folderów, zasady które Claude ma zawsze respektować. Jest ładowany automatycznie do kontekstu przy każdej sesji i działa jako stały system prompt. Nie zawiera kroków do wykonania — zawiera kontekst i reguły.

Skill to workflow — sekwencja kroków do wykonania na żądanie. Nie jest ładowany automatycznie, nie zajmuje kontekstu dopóki go nie wywołasz, i jest zaprojektowany pod konkretną akcję, nie pod ciągłe tło. Dobra zasada: jeśli chcesz żeby Claude coś wiedział — CLAUDE.md. Jeśli chcesz żeby coś zrobił na komendę — skill.

W praktyce te dwa mechanizmy uzupełniają się: skill może odwoływać się do CLAUDE.md jako źródła informacji o projekcie, a CLAUDE.md może wskazywać na skille jako właściwy sposób wykonania typowych operacji.

Skills w pracy zespołowej — jak standaryzować workflow agencji lub zespołu

Najcenniejsze zastosowanie skillów projektowych to standaryzacja workflow w zespole. Zamiast tłumaczyć każdemu nowemu deweloperowi jak uruchomić projekt, jak robić deploy na staging, jak formatować commit messages — te rzeczy żyją w plikach SKILL.md w repozytorium. Każdy ma do nich dostęp, każdy wywołuje je tak samo, każdy dostaje ten sam rezultat.

Dla agencji tworzących wiele projektów podobnego typu — np. sklepy Next.js z Supabase — skille użytkownika pozwalają przenieść sprawdzone wzorce między projektami. Skill do audytu bezpieczeństwa, skill do optymalizacji Core Web Vitals, skill do generowania sitemapy — raz napisany, działa w każdym nowym projekcie bez żadnej konfiguracji.

Skills można też używać w połączeniu z /loop i /schedule do tworzenia autonomicznych agentów monitorujących. Skill sprawdzający czy deploy na Vercelu przeszedł pomyślnie, uruchamiany co 5 minut po pushu, jest prostą formą CI bez żadnej zewnętrznej infrastruktury.

Najczęstsze błędy przy pisaniu własnych skillów

Pierwsza i najczęstsza pomyłka to zakładanie kontekstu sesji. Skill napisany jako „kontynuuj to co robiliśmy" zawiedzie gdy będzie wykonywany przez świeżego agenta. Każdy skill musi opisywać co ma zrobić od początku, bez polegania na tym, co padło wcześniej w rozmowie.

Drugi błąd to zbyt ogólny opis w frontmatter. description: robi różne rzeczy z kodem jest bezużyteczny — Claude Code nie będzie wiedział kiedy go zaproponować, a użytkownik nie będzie wiedział kiedy go wywołać. Opis powinien zaczynać się od czasownika i jasno mówić co skill robi w jednym zdaniu.

Trzeci błąd to skill który próbuje robić za dużo. Skill łączący deployment, testy, review kodu i aktualizację dokumentacji to skill, który zawiedzie w połowie i zostawi projekt w nieokreślonym stanie. Lepiej mieć cztery małe, niezależne skille niż jeden wielki. Małe skille są łatwiejsze do debugowania, łatwiejsze do ponownego użycia i łatwiejsze do poprawienia kiedy jeden krok zmienia się.

Podsumowanie — kiedy warto pisać własny skill

Skill warto napisać gdy wykonujesz tę samą sekwencję kroków trzeci raz. Nie wcześniej — przedwczesna automatyzacja to strata czasu, bo nie wiesz jeszcze jak dokładnie ten workflow powinien wyglądać. Ale przy trzecim powtórzeniu wzorzec jest już wyraźny i pisanie skilla zajmie mniej czasu niż sumują się przyszłe powtórzenia.

Skills nie zastępują znajomości narzędzi — Claude nadal musi mieć dostęp do terminala, plików i przeglądarki żeby skill działał. Ale zamieniają wiedzę o projekcie w coś wykonywalnego i powtarzalnego — i to jest ich prawdziwa wartość. Nie oszczędzają jednej minuty dziś. Oszczędzają pięć minut każdego dnia przez następne miesiące.