Skills w Claude Code — własne komendy slash krok po kroku
Skills to jeden z najmocniejszych, a najmniej wykorzystywanych mechanizmów Claude Code — własne komendy slash szyte pod Twój projekt.
Skills pozwalają zamknąć powtarzalny proces w jedną komendę slash. Pokazujemy, jak zbudować własną i kiedy to się realnie opłaca.
Kurs Claude Code - Lekcja 16 z 28
Ten artykuł jest częścią bezpłatnego kursu Claude Code - największej polskojęzycznej serii 28 lekcji dla programistów. Od pierwszego uruchomienia do autonomicznych agentów AI.
<-- Lekcja 15: CLAUDE.md - konfiguracja agentaLekcja 17: Serwery MCP
Wyobraź sobie że wpisujesz /deploy-staging i Claude Code sam pobiera aktualny diff, sprawdza testy, buduje Docker image i wysyła na serwer. Albo /review-pr 1234 i agent natychmiast ściąga kod z GitHub, analizuje i zwraca rzeczowy komentarz. To nie magia - to Skills, jeden z najpotężniejszych mechanizmów personalizacji Claude Code, o którym większość deweloperów jeszcze nie wie.
Z tego artykułu dowiesz się:
- Czym są Skills i czym różnią się od CLAUDE.md, hooks i MCP
- Jak działa struktura katalogów i plik SKILL.md z nagłówkiem metadanych (tzw. frontmatter)
- Wstrzykiwanie żywych danych z terminala wprost do skilla (po angielsku „dynamic context injection")
- Nazwane argumenty (named arguments) i jak przekazywać parametry do skilla
- Izolowany podagent (
context: fork) - zadania w oddzielnym kontekście - Wbudowane skills Claude Code - co jest w pudełku
- 5 gotowych do skopiowania skills do prawdziwych projektów
Skills vs CLAUDE.md vs Hooks - gdzie jest różnica?
Zanim zbudujesz pierwszy skill, warto zrozumieć ekosystem. Claude Code ma kilka mechanizmów rozszerzeń które wyglądają podobnie ale mają inny zakres zastosowań:
Cztery mechanizmy rozszerzeń Claude Code i moment, w którym trafiają do kontekstu: CLAUDE.md (zawsze), Skills (na żądanie), Hooks (przy zdarzeniu), MCP (przy wywołaniu narzędzia).
| Mechanizm | Kiedy ładuje się do kontekstu | Typowe zastosowanie | Koszt tokenów |
|---|---|---|---|
| CLAUDE.md | Zawsze, przy każdym promptcie | Stałe zasady projektu, wzorce kodu, dane dostępowe | Wysoki (zawsze) |
| Skills | Na żądanie: /skill-name lub automatyczne uruchomienie |
Procedury krok po kroku, wdrożenia, przegląd kodu, listy kontrolne | Zero dopóki nie użyty |
| Hooks | Automatycznie przy zdarzeniu (zapis pliku, koniec sesji...) | Sprawdzanie kodu (linting), automatyczny commit, blokowanie niebezpiecznych komend | Zero (bash skrypt) |
| MCP | Przy wywołaniu narzędzia MCP | Integracja z zewnętrznymi systemami, GitHub API, bazy danych | Zależnie od odpowiedzi |
Kluczowa zasada: stała wiedza o projekcie to CLAUDE.md. Procedura wywoływana sytuacyjnie to Skill. A rzecz, która ma się uruchamiać automatycznie przy zdarzeniu, to Hook.
Praktyczny test: Jeśli Twój CLAUDE.md urósł do kilku tysięcy znaków i połowa to opisane procedury (jak robić deploy, jak tworzyć PR, jak pisać testy) - te procedury powinny być Skills. Do CLAUDE.md wróci tylko trwała wiedza o projekcie.
Gdzie żyją Skills - struktura katalogów
Skills to katalogi w .claude/skills/. Każdy skill to osobny podkatalog z obowiązkowym plikiem SKILL.md i opcjonalnymi plikami pomocniczymi:
Realny katalog .claude/skills/ w projekcie demo: dziewięć skills, każdy z plikiem SKILL.md. Skill fix-github-issue ma dodatkowo reference.md i katalog scripts/ z pomocniczym skryptem.
.claude/
├── settings.json # globalne ustawienia Claude Code
└── skills/
├── fix-issue/
│ ├── SKILL.md # obowiązkowy (logika skilla)
│ ├── reference.md # opcjonalne (duże docs, nie w kontekście)
│ └── scripts/
│ └── validate.sh
├── deploy-staging/
│ └── SKILL.md
└── review-pr/
└── SKILL.md
Claude Code odkrywa skills automatycznie - skanuje katalog .claude/skills/ w bieżącym projekcie, katalogach nadrzędnych (aż do roota repo) i globalnym ~/.claude/skills/. Zmiany w SKILL.md wchodzą w życie w bieżącej sesji bez restartu.
| Lokalizacja | Zakres | Przykład użycia |
|---|---|---|
~/.claude/skills/ |
Globalne - wszystkie projekty | Komendy które używasz w każdym repo (git-summary, code-review) |
.claude/skills/ (katalog projektu) |
Lokalny - ten projekt | deploy-staging, fix-issue, generate-migration - specyficzne dla projektu |
pakiety/frontend/.claude/skills/ |
Subkatalog (monorepo) | Skill dostępny tylko gdy pracujesz w pakiecie frontend |
Anatomia SKILL.md - frontmatter i treść
Plik SKILL.md ma dwie części: frontmatter (metadane w formacie YAML między ---) i treść (instrukcje dla Claude, format Markdown). Zobaczmy kompletny przykład z opisem każdego pola:
Plik SKILL.md otwarty w edytorze z podświetlaniem składni: frontmatter YAML (pola name, description, argument-hint, allowed-tools, model, effort) i treść Markdown z krokami procedury.
---
# FRONTMATTER - metadane skilla (format YAML)
name: fix-github-issue # nazwa w menu /skills (domyślnie: nazwa katalogu)
description: Naprawia zgłoszenie (issue) z GitHub. # kluczowe: Claude używa do automatycznego uruchamiania
Użyj gdy użytkownik podaje numer zgłoszenia, pyta o błąd lub prośbę o nową funkcję.
when_to_use: Przy zgłoszeniach błędów, prośbach o nowe funkcje, pracy w oparciu o zgłoszenia.
argument-hint: [numer-issue] [branch] # podpowiedź w autocomplete po wpisaniu /
arguments: [issue_num, branch] # mapowanie nazwanych zmiennych
allowed-tools: Bash(git *) Bash(gh *) # te narzędzia nie pytają o zgodę
model: sonnet # opcjonalne: nadpisanie modelu dla tego skilla
effort: high # low | medium | high | xhigh | max
---
# Treść skilla - instrukcje dla Claude w Markdown
## Napraw zgłoszenie #$issue_num
Działaj automatycznie bez pytania o potwierdzenie każdego kroku.
### Krok 1: Pobierz szczegóły z GitHub
!'gh issue view $issue_num --json title,body,labels,assignees'
### Krok 2: Sprawdź powiązane pliki
Przeanalizuj powyższe zgłoszenie. Zidentyfikuj źródło problemu i pliki do zmiany.
### Krok 3: Zaimplementuj poprawkę i utwórz PR
1. 'git checkout -b fix/issue-$issue_num'
2. Dokonaj minimalnych zmian naprawiających problem
3. Dodaj/zaktualizuj testy
4. 'git add -A && git commit -m "Fix: zgłoszenie #$issue_num"'
5. 'git push -u origin fix/issue-$issue_num'
6. 'gh pr create --fill'
Wszystkie pola frontmatteru - ściąga
| Pole | Typ | Opis |
|---|---|---|
name |
opcjonalne | Nazwa w listingach i menu. Domyślnie: nazwa katalogu (myślnik zamieniany na spację) |
description |
ważne | Opis co skill robi i kiedy. Claude używa go do automatycznego uruchamiania. Limit 1536 znaków łącznie z when_to_use |
when_to_use |
opcjonalne | Dodatkowy kontekst kiedy skill ma się włączyć. Dołączany do description |
argument-hint |
opcjonalne | Podpowiedź w autocomplete: [numer-issue] [branch] |
arguments |
opcjonalne | Lista nazwanych argumentów: [issue, branch], dostępne jako \(issue, \)branch |
allowed-tools |
opcjonalne | Narzędzia które nie wymagają zgody użytkownika gdy skill jest aktywny: Bash(git *) Bash(gh *) |
disallowed-tools |
zaawansowane | Zablokuj dostęp do konkretnych narzędzi gdy skill działa |
model |
opcjonalne | Model do użycia: sonnet, opus, haiku. Nadpisuje globalny |
effort |
opcjonalne | Poziom wysiłku: low / medium / high / xhigh / max |
context |
zaawansowane | fork - uruchom w izolowanym podagent context, bez historii rozmowy |
agent |
zaawansowane | Typ podagenta przy context: fork: Explore, Plan, general-purpose |
disable-model-invocation |
opcjonalne | true = tylko ręczne wywołanie przez /, Claude nie uruchamia go automatycznie |
user-invocable |
opcjonalne | false = ukryty z menu /, tylko Claude może go użyć (wiedza działająca w tle) |
paths |
zaawansowane | Glob patterns: skill auto-load tylko gdy pracujesz z pasującymi plikami: src/**/*.ts |
shell |
opcjonalne | bash (domyślnie) lub powershell (Windows) |
Jak wywołać skill - trzy sposoby
1. Ręcznie przez /nazwa-skilla
Najprostszy sposób - wpisz ukośnik i nazwę skilla w promptcie. Podpowiedzi autocomplete pokazują dostępne skills z ich argument-hint:
Autocomplete w Claude Code po wpisaniu /fix: własny skill fix-github-issue z opisem po polsku, tagiem (project) i podpowiedzią argumentów (issue_num, branch) z frontmatteru.
# Bez argumentów
/fix-github-issue
# Z argumentami
/fix-github-issue 1234
/fix-github-issue 1234 main
/deploy-staging
/review-pr 567
2. Automatyczne uruchomienie przez opis skilla
Jeśli description skilla pasuje do zapytania użytkownika - Claude załaduje go automatycznie bez wpisywania /. To wymaga przemyślanego opisu:
# Skill z opisem: "Naprawia błędy i zgłoszenia z GitHub. Użyj gdy użytkownik pyta o błąd."
# Te zapytania uruchamiają skill automatycznie:
"Jest błąd w zgłoszeniu #1234, napraw to"
"Mamy zgłoszenie #89 do zamknięcia"
"Coś się sypie w module logowania, sprawdź zgłoszenie #56"
# Te NIE uruchamiają skilla (za mało słów kluczowych):
"Napisz testy do UserService"
"Zrefaktoryzuj ten kod"
Wskazówka: Jeśli skill uruchamia się za często - zawęź opis. Jeśli za rzadko - dodaj synonimy do when_to_use. Możesz też wyłączyć automatyczne uruchamianie przez disable-model-invocation: true i zostawić tylko ręczne wywołanie.
3. Listowanie dostępnych skills
# Lista wszystkich dostępnych skills
/skills
# Wynik:
Available skills:
fix-github-issue Naprawia zgłoszenie z GitHub. Użyj gdy użytkownik podaje numer zgłoszenia...
deploy-staging Wdraża aplikację na środowisko staging. Tylko ręczne wywołanie.
review-pr Przegląd kodu pull requesta. Pobiera zmiany z GitHub i analizuje.
summarize-changes Podsumowanie niezacommitowanych zmian.
Wstrzykiwanie żywych danych - aktualne dane w skillach
To jest mechanizm który sprawia że skills są naprawdę potężne. Specjalna składnia wewnątrz pliku SKILL.md (pokazujemy ją w listingu poniżej) powoduje że zanim Claude zobaczy skill, Claude Code wykonuje wskazane polecenie powłoki i wstawia jego wynik w to miejsce.
Przepływ wstrzykiwania żywych danych: użytkownik wywołuje skill, Claude Code wykonuje wskazane polecenie, jego wynik jest wstawiany jako tekst i dopiero wtedy Claude widzi skill z aktualnymi danymi.
---
name: review-pr
description: Przegląd kodu pull requesta z GitHub
allowed-tools: Bash(gh *)
---
## Review PR #$0
### Pobrane z GitHub (żywe dane):
**Diff:**
!'gh pr diff $0'
**Informacje:**
!'gh pr view $0 --json title,author,body,labels'
**Lista zmienionych plików:**
!'gh pr diff $0 --name-only'
---
Przejrzyj powyższy diff. Oceń:
1. Poprawność logiki biznesowej
2. Obsługę błędów i przypadków brzegowych
3. Jakość kodu (czytelność, duplikacje)
4. Brakujące testy
5. Potencjalne problemy z bezpieczeństwem
Zwróć listę konkretnych uwag z numerami linii.
Gdy użytkownik wpisze /review-pr 234, Claude Code najpierw wykona gh pr diff 234, gh pr view 234 --json ... i gh pr diff 234 --name-only, wstawi wyniki, a dopiero potem cały skill (z aktualnym diffem!) trafi do kontekstu Claude.
Wielolinijkowe wstrzykiwanie danych
Dla wielu poleceń możesz użyć bloku kodu z wykrzyknikiem:
---
name: project-status
description: Aktualny status projektu - gałęzie, testy, build
---
## Status projektu (aktualne dane)
```!
echo "=== GIT STATUS ==="
git status --short
echo ""
echo "=== OSTATNIE COMMITY ==="
git log --oneline -10
echo ""
echo "=== BRANCH INFO ==="
git branch -v
echo ""
echo "=== WYNIKI TESTÓW ==="
npm test --silent 2>&1 | tail -20
Na podstawie powyższego stanu projektu odpowiedz co warto teraz zrobić
i czy są jakieś alarmy wymagające natychmiastowej uwagi.
### Dostępne zmienne środowiskowe przy wstrzykiwaniu
Zmienne dostępne w !'komenda' i w treści skilla:
$ARGUMENTS # wszystkie argumenty jako jeden string
$0 # pierwszy argument (skrót)
$1 # drugi argument
$ARGUMENTS[0] # pierwszy argument (alternatywnie)
$nazwa_zmiennej # nazwana zmienna z pola arguments: [nazwa_zmiennej]
${CLAUDE_SESSION_ID} # ID bieżącej sesji Claude Code
${CLAUDE_SKILL_DIR} # absolutna ścieżka do katalogu skilla
${CLAUDE_EFFORT} # aktualny poziom wysiłku (low/medium/high...)
**Ważne:** Dynamic context injection wykonuje się synchronicznie zanim Claude zobaczy skill. Jeśli komenda trwa długo (np. pełny build projektu), użytkownik poczeka. Dla długich operacji lepiej jest uruchamiać je jako krok wewnątrz skilla przez Claude, nie przez injection.
## Nazwane argumenty - parametryzowane skills
Zamiast odwoływać się do `\(0`, `\)1`, możesz zdefiniować nazwane zmienne. Zwiększa to czytelność skilla i pomaga Claude lepiej rozumieć kontekst:
Skill migrate-component wywołany z trzema argumentami: /migrate-component SearchBar React Vue. Zmienne \(component, \)fromFramework, $toFramework podstawione z pozycji argumentów.
name: migrate-component
description: Migruje komponent UI z jednego frameworka do drugiego
argument-hint: [komponent] [z-frameworka] [do-frameworka]
arguments: [component, fromFramework, toFramework]
Migracja: $component ($fromFramework -> $toFramework)
Przeprowadź migrację komponentu '$component' z '$fromFramework' do '$toFramework'.
Pliki do analizy:
!'find . -name "$component*" -not -path "/node_modules/"'
Istniejący kod:
!'find . -name "$component*" -not -path "/node_modules/" | head -3 | xargs cat'
Zmień kod tak żeby:
Zachować identyczne API (props/events/slots)
Używać konwencji i idiomów $toFramework
Usunąć wszystkie importy $fromFramework
Zaktualizować testy
Nie zmieniaj logiki biznesowej komponentu.
Wywołanie:
/migrate-component SearchBar React Vue
\(component = SearchBar, \)fromFramework = React, $toFramework = Vue
/migrate-component UserProfileCard Angular React
\(component = UserProfileCard, \)fromFramework = Angular, $toFramework = React
## Izolowany kontekst podagenta (context: fork)
Pole `context: fork` sprawia że skill uruchamia się w **oddzielnym kontekście podagenta** - bez historii bieżącej rozmowy. To świetne dla długich zadań badawczych, analizy kodu lub operacji które mają własny zakres, niezależny od rozmowy:
context: fork tworzy izolowany podagent: brak historii rozmowy, własny zakres narzędzi. Wynik wraca do głównej sesji jako odpowiedź skilla.
name: deep-research
description: Dogłębne zbadanie tematu w kodzie. Użyj gdy pytasz "jak działa X w tym projekcie?"
context: fork
agent: Explore # Explore = tylko narzędzia tylko do odczytu, mniejszy kontekst
effort: high
Zbadaj dogłębnie: $ARGUMENTS
Kroki:
Znajdź wszystkie istotne pliki (Glob, Grep)
Przeczytaj kod od początku do końca
Śledź przepływ danych i zależności
Zidentyfikuj przypadki brzegowe i potencjalne problemy
Zwróć:
Pełne wyjaśnienie jak to działa
Ścieżki do kluczowych plików z numerami linii
Niezrozumiałe fragmenty lub ryzyka
Sugestie refaktoryzacji jeśli widzisz problemy
Dostępne typy agentów przy `context: fork`:
| agent: | Dostępne narzędzia | Kiedy użyć |
| --- | --- | --- |
| `Explore` | Tylko do odczytu (Glob, Grep, Read, Bash tylko odczyt) | Analiza kodu, przegląd, szukanie plików - nigdy nie modyfikuje |
| `Plan` | Tylko do odczytu + generowanie planów | Projektowanie rozwiązania bez implementacji |
| `general-purpose` | Pełny dostęp (jak główna sesja) | Złożone zadania z modyfikacją plików w izolacji |
**Uwaga:** `context: fork` wymaga żeby skill definiował konkretne zadanie do wykonania - nie może być tylko dokumentacją referencyjną. Sama dokumentacja bez zadania do wykonania zwróci pusty wynik.
## Wbudowane skills - co jest w pudełku
Claude Code dostarcza zestaw domyślnych skills dostępnych w każdym projekcie (można je wyłączyć przez `disableBundledSkills: true` w settings.json *(dokładna nazwa klucza może różnić się między wersjami - sprawdź aktualną dokumentację)*):
Wpisanie / w Claude Code pokazuje wbudowane komendy - m.in. /add-dir, /advisor, /agents, /background, /branch - obok Twoich własnych skills z projektu.
| Skill | Opis | Kiedy używać |
| --- | --- | --- |
| `/run` | Uruchom aplikację i zweryfikuj zmiany w przeglądarce | Po każdej zmianie UI/backend - zamiast ręcznego „uruchom serwer” |
| `/verify` | Zbuduj i uruchom app zamiast samych testów | Weryfikacja feature w działającym środowisku |
| `/code-review` | Przegląd kodu zmian - poprawność, bezpieczeństwo, zasada DRY | Przed każdym PR. Opcje: `--fix` (auto-naprawa), `--comment` (komentarze na PR) |
| `/loop` | Uruchamia prompt lub skill cyklicznie (z interwałem lub self-paced) | Ciągłe monitorowanie, iteracyjne poprawianie |
| `/batch` | Równoległe zmiany przez 5-30 podagentów | Masowe migracje, zmiana nazw, zmiany w wielu plikach naraz |
| `/compact` | Manualne skompresowanie konwersacji | Gdy kontekst się zapełnia, chcesz zachować historię |
| `/claude-api` | Referencja do Claude API (modele, ceny, parametry) | Przy budowie aplikacji integrujących Claude |
| `/help` | Pomoc i dokumentacja Claude Code | Gdy nie pamiętasz składni lub szukasz możliwości |
## Skill nr 1: summarize-changes (codziennik pracy)
Jeden z najbardziej przydatnych skills do codziennego użytku - podsumowuje co zrobiłeś w danym dniu:
Skill /summarize-changes wyświetla podsumowanie niezacommitowanych i ostatnich zacommitowanych zmian z kontekstem biznesowym.
~/.claude/skills/summarize-changes/SKILL.md
name: summarize-changes
description: Podsumowuje niezacommitowane zmiany i ostatnie commity. Użyj na koniec dnia roboczego lub przed daily.
Stan projektu
Niezacommitowane zmiany:
!'git diff --stat HEAD 2>/dev/null || echo "Brak zmian"'
Szczegóły zmian:
!'git diff HEAD 2>/dev/null | head -200'
Ostatnie 5 commitów:
!'git log --oneline -5'
Na podstawie powyższych danych:
Napisz zwięzłe podsumowanie (5-10 zdań) co zostało zrobione
Wypisz lista ukończonych zadań (bullet points)
Zaznacz otwarte kwestie i decyzje wymagające uwagi
Zaproponuj commit message dla niezacommitowanych zmian (conventional commits)
Styl: zrozumiały dla menedżera, bez żargonu technicznego.
## Skill nr 2: deploy-staging (wdrożenie z kontrolą wstępną)
Skill który nigdy nie uruchomi się przez przypadek - `disable-model-invocation: true` zapewnia że tylko Ty możesz go wywołać:
.claude/skills/deploy-staging/SKILL.md
name: deploy-staging
description: Deploy aplikacji na środowisko staging
disable-model-invocation: true # TYLKO ręczne wywołanie /deploy-staging
allowed-tools: Bash(docker *) Bash(kubectl *) Bash(git *)
argument-hint: [wersja]
Wdrożenie na Staging
Kontrola wstępna:
!'git status --short'
!'git log --oneline -3'
Aktualna gałąź: !'git rev-parse --abbrev-ref HEAD'
Ostatni tag: !'git describe --tags --abbrev=0 2>/dev/null || echo "brak tagów"'
Wykonaj deploy:
Sprawdź zmiany: czy powyższe niezacommitowane zmiany to problem?
Jeśli tak - STOP i poinformuj użytkownika
Jeśli nie - kontynuuj
Uruchom testy:
npm run test -- --ci
- Zbuduj obraz Docker:
docker build -t myapp:staging-$0 .
docker push registry.mycompany.com/myapp:staging-$0
- Deploy na Kubernetes:
kubectl set image deployment/myapp-staging myapp=registry.mycompany.com/myapp:staging-$0 -n staging
kubectl rollout status deployment/myapp-staging -n staging
- Weryfikuj:
kubectl get pods -n staging
curl -f https://staging.myapp.com/health
Raportuj wynik każdego kroku. Przy błędzie - STOP i podaj szczegóły.
## Skill nr 3: generate-migration (migracje bazy danych)
Skill który automatycznie generuje migracje na podstawie analizy aktualnego schematu:
.claude/skills/generate-migration/SKILL.md
name: generate-migration
description: Generuje migrację bazy danych. Użyj gdy dodajesz/zmieniasz model Django/SQLAlchemy/Prisma.
argument-hint: [opis-zmiany]
allowed-tools: Bash(python *) Bash(psql *)
Generuj migrację: $ARGUMENTS
Aktualny stan modeli:
!'find . -name "models.py" -not -path "/venv/" | head -5 | xargs grep -l "class " 2>/dev/null'
Historia ostatnich migracji:
!'find . -path "/migrations/.py" -not -name "init.py" | sort | tail -5'
Schemat aktualnych tabel:
!'python manage.py showmigrations --list 2>/dev/null | tail -20 || echo "Nie Django"'
Wygeneruj migrację dla: $ARGUMENTS
Kroki:
Przeanalizuj istniejące modele i migracje
Zaproponuj zmianę w modelu (pokaż diff)
Wygeneruj migrację: 'python manage.py makemigrations --name "$ARGUMENTS"'
Sprawdź wygenerowany plik migracji
Zaproponuj wycofanie migracji (plik odwrotnej migracji)
Pokaż SQL który zostanie wykonany: 'python manage.py sqlmigrate '
Uwagi do bezpieczeństwa:
Przy dodaniu NOT NULL bez wartości domyślnej - ostrzeż o potrzebie uzupełnienia danych
Przy zmianie nazwy kolumny - zaproponuj migrację w 3 krokach (dodaj + skopiuj + usuń)
Przy DROP - zaproponuj usuwanie logiczne zamiast trwałego skasowania
## Skill nr 4: explain-code (z izolowanym podagentem)
Skill który używa `context: fork` i agenta Explore do pełnej analizy wskazanego fragmentu - bez zaśmiecania bieżącej rozmowy:
name: explain-code
description: Dogłębne wyjaśnienie jak działa wskazany fragment kodu. Użyj gdy pytasz "jak działa X"
argument-hint: [funkcja-klasa-plik]
context: fork
agent: Explore
effort: high
Przeprowadź dogłębną analizę: $ARGUMENTS
Znajdź wskazany komponent/funkcję/klasę w kodzie
Przeczytaj CAŁY plik - nie tylko wskazany fragment
Śledź zależności - co importuje, co wywołuje, co go wywołuje
Sprawdź testy jeśli istnieją
Sprawdź historię git jeśli istotna: !'git log --oneline --follow -5 -- "$ARGUMENTS" 2>/dev/null'
Odpowiedź sformatuj jako:
Co robi (1 zdanie)
Jak to działa (algorytm krok po kroku)
Zależności (co potrzebuje, co zwraca)
Przypadki brzegowe (co może pójść nie tak)
Sugestie (co można poprawić)
Podawaj konkretne ścieżki plików i numery linii.
Skill /explain-code AuthService uruchamia izolowany podagent Explore który przeszukuje cały projekt (tylko do odczytu) i zwraca pełną analizę do głównej sesji.
## Skill nr 5: setup-project (inicjalizacja projektu z instrukcją)
Skill który nowy developer wpisuje raz po sklonowaniu repo - instaluje wszystko i konfiguruje środowisko:
.claude/skills/setup-project/SKILL.md
name: setup-project
description: Pełna konfiguracja środowiska deweloperskiego. Uruchom po sklonowaniu repo.
disable-model-invocation: true
allowed-tools: Bash(npm *) Bash(pip *) Bash(cp *) Bash(mkdir *)
Setup środowiska deweloperskiego
Sprawdź wymagania:
!'node --version 2>/dev/null || echo "Node.js nie zainstalowany"'
!'python3 --version 2>/dev/null || echo "Python3 nie zainstalowany"'
!'docker --version 2>/dev/null || echo "Docker nie zainstalowany"'
Aktualna zawartość .env:
!'ls -la .env* 2>/dev/null || echo "Brak pliku .env"'
Skonfiguruj środowisko krok po kroku:
Sprawdź powyższe wymagania - jeśli brakuje narzędzi -> poinformuj i zatrzymaj
Zainstaluj zależności:
npm install
pip install -r requirements.txt # jeśli istnieje
- Skopiuj .env.example -> .env (jeśli nie istnieje):
[ ! -f .env ] && cp .env.example .env && echo "Skopiowano .env.example -> .env"
- Uruchom bazy danych przez Docker Compose:
docker compose up -d postgres redis
- Uruchom migracje:
python manage.py migrate # lub: npm run migrate
- Sprawdź czy wszystko działa:
npm run health-check 2>/dev/null || python manage.py check
Zgłoś wynik każdego kroku. Na koniec podaj URL do lokalnej aplikacji.
## Cykl życia skilla w kontekście
Ważna techniczna kwestia: skill który wywołasz zostaje w kontekście do końca sesji (lub do auto-kompresji). Warto to rozumieć żeby uniknąć niespodzianek:
Cykl życia skilla: wywołanie, wstrzyknięcie do kontekstu, pozostanie w sesji, a przy auto-kompresji zachowane pierwsze 5000 tokenów. Jeśli po kompresji skill przestał działać - wywołaj go ponownie.
- **Skill NIE jest re-odczytywany** w kolejnych turnach - załadowany skill to stały tekst w historii rozmowy
- **Wszystkie wywołane skills dzielą budżet 25 000 tokenów** - przy dużych skillach z wieloma dynamic injection możesz szybko go wyczerpać
- **Przy auto-kompresji** - pierwsze 5000 tokenów każdego skilla jest zachowywanych. Jeśli skill przestał „działać” po kompresji - wywołaj go ponownie przez `/nazwa-skilla`
- **Pliki reference.md** i inne pliki pomocnicze w katalogu skilla **NIE ładują się automatycznie** - skill musi je jawnie przywołać lub Claude musi je otworzyć. To celowe - pozwala mieć obszerne dokumentacje bez kosztu tokenów
## Gdzie szukać gotowych skills - ekosystem
Nie musisz tworzyć wszystkiego od zera. Rośnie społeczność dzieląca się skills:
| Zasób | Co znajdziesz |
| --- | --- |
| **Dokumentacja Claude Code** [docs.anthropic.com/claude-code](https://docs.anthropic.com/claude-code) | Oficjalna dokumentacja Anthropic - skills, hooks, ustawienia, integracje IDE |
| **Przykłady społecznościowe** (GitHub, szukaj „claude code skills”) | Gotowe skills od społeczności - przegląd kodu, wdrożenia, testowanie, debugowanie |
## Typowe błędy i jak je naprawić
### Skill nie pojawia się po wpisaniu /
Sprawdź strukturę katalogów
ls -la .claude/skills/
Każdy skill musi być w podkatalogu z SKILL.md
OK .claude/skills/fix-issue/SKILL.md
ZLE .claude/skills/fix-issue.md (zły format)
Sprawdź czy SKILL.md ma poprawny frontmatter
head -10 .claude/skills/fix-issue/SKILL.md
Pierwsze znaki muszą być: ---
### Skill uruchamia się zbyt często (lub wcale)
#### Zbyt ogólny opis - uruchamia się za często
description: Pomaga z kodem.
Użyj gdy użytkownik pyta o kod.
#### Precyzyjny opis - uruchamia się właściwie
description: Naprawia błędy z GitHub Issues.
Użyj gdy użytkownik podaje numer zgłoszenia,
pyta o konkretne zgłoszenie lub raport o błędzie.
### Dynamic injection zwraca pusty wynik
Sprawdź czy komenda działa poza Claude Code
gh pr diff 234 # czy gh jest zalogowane?
git log --oneline -5 # czy jesteś w repo?
Skill z obsługą błędu:
Diff PR:
!'gh pr diff $0 2>/dev/null || echo "Nie można pobrać diff. Sprawdź czy gh jest zalogowane."'
### context: fork nie zwraca wyników
Problem: pure reference docs nie mają "akcji" do wykonania
context: fork
Dokumentacja API
Oto lista endpointów... (Claude nie wie, co „zrobić” z tą informacją w forku)
Rozwiązanie: dodaj konkretną akcję / pytanie
context: fork
agent: Explore
Zbadaj $ARGUMENTS w kodzie i odpowiedz na pytanie: jak to działa?
teraz podagent ma konkretne zadanie do wykonania
## Kiedy tworzyć skill, a kiedy nie
#### Stwórz Skill gdy:
- Powtarzasz tę samą procedurę wielokrotnie
- Masz listę kontrolną kroków do wdrożenia lub wydania wersji
- Chcesz auto-pobrać żywe dane (diff, logi, status)
- Sekcja CLAUDE.md urasta do rozbudowanej procedury
- Chcesz izolować długie zadanie badawcze (fork)
- Chcesz kontrolować które narzędzia wymagają zgody
#### NIE twórz Skill gdy:
- To prosta zasada lub fakt (lepiej CLAUDE.md)
- Hook by działał lepiej (zdarzenie automatyczne)
- Używasz tego raz w projekcie
- To operacja jednolinijkowa
- Skill byłby pustą otoczką bez wartości
## Quick start - stwórz pierwszy skill w 3 minutach
1. Utwórz katalog skills
mkdir -p .claude/skills/summarize-changes
2. Utwórz SKILL.md
cat > .claude/skills/summarize-changes/SKILL.md << 'EOF'
name: summarize-changes
description: Podsumowuje niezacommitowane zmiany. Użyj na koniec dnia pracy.
Niezacommitowane zmiany:
!'git diff --stat HEAD 2>/dev/null || echo "Brak zmian"'
Szczegóły:
!'git diff HEAD 2>/dev/null | head -100'
Napisz zwięzłe podsumowanie co zostało zrobione i zaproponuj commit message.
EOF
3. Gotowe! Wpisz w Claude Code:
/summarize-changes
Pierwszy własny skill w akcji: po 3 minutach konfiguracji /summarize-changes pobiera aktualne zmiany z gita (git diff) i na żywo generuje podsumowanie zmian (u dołu „esc to interrupt” - skill jeszcze pracuje).
## Chcesz opanować Claude Code z trenerem?
Skills, hooks, podagenty, MCP i równoległe przepływy - w praktyce, na warsztacie z praktykiem JSystems. Szkolenie ma termin gwarantowany, więc odbędzie się na pewno.
[](https://jsystems.pl/szkolenia-ai;claude_code.szczegoly?utm_source=blog&utm_medium=article&utm_campaign=post_claude_code_skills&utm_content=banner_claude-code-skills)
[Szkolenie Claude Code z terminem gwarantowanym](https://jsystems.pl/szkolenia-ai;claude_code.szczegoly?utm_source=blog&utm_medium=article&utm_campaign=post_claude_code_skills&utm_content=link_claude-code-skills)
## Podsumowanie
Skills to mechanizm który pozwala zamienić Claude Code z inteligentnego asystenta w dopasowane do Twojego projektu narzędzie z własnym zestawem komend. Kluczowe punkty do zapamiętania:
- **Plik SKILL.md** w katalogu `.claude/skills/nazwa/` - nagłówek metadanych (frontmatter) w formacie YAML + treść w formacie Markdown
- **Wywołanie:** `/nazwa-skilla [argumenty]` lub automatyczne uruchomienie przez opis w polu `description`
- **Wstrzykiwanie żywych danych** - polecenie z terminala wykonuje się, a jego wynik trafia do skilla, zanim Claude go zobaczy
- **Nazwane argumenty** - `arguments: [zmienna1, zmienna2]` zamiast pozycyjnych `\(0`, `\)1`
- **context: fork** - izolowany podagent dla długich zadań analitycznych lub procesów wdrożeniowych
- **disable-model-invocation: true** - obowiązkowe dla skills wdrożeniowych, które nie mogą uruchomić się przez przypadek
- **allowed-tools** - narzędzia które nie pytają o zgodę gdy skill jest aktywny (np. `Bash(git *)`)
Zacznij od jednego skilla - najlepiej takiego który rozwiązuje ból z którym spotykasz się codziennie. Reszta przyjdzie naturalnie.
✕![]()
Poprzednia lekcja
[<-- Lekcja 15: CLAUDE.md - konfiguracja agenta](https://jsystems.pl/show_post/claudemd_jak_skonfigurowac_claude_code_zeby_znal_twoj_projekt_jak_wlasna_kieszen/)
Następna lekcja
[Lekcja 17: Serwery MCP](https://jsystems.pl/show_post/claude_serwery_mcp_jak_podlaczyc_agenta_do_swoich_systemow/)
[Wszystkie lekcje kursu Claude Code](https://jsystems.pl/show_post/claude_code_kompletny_przewodnik_dla_programistow/)