Claude Code Skills — jak budować własne workflow AI w 2026

Masz problem z workflow.

Claude Code Skills pozwalają zamienić powtarzalne instrukcje w pliki, które żyją w repo albo w Twoim katalogu użytkownika. Claude nie musi za każdym razem dostawać długiego promptu. Wystarczy, że uruchomisz konkretny skill albo opiszesz zadanie tak, żeby Claude sam rozpoznał, którego workflow użyć.

Pełen kontekst Claude Code — w pillarze: Claude Code — kompletny przewodnik 2026.

W tym artykule pokażę:

• czym są Claude Code Skills,
• kiedy warto ich używać,
• jak wygląda prosty SKILL.md,
• jak zbudować pierwszy skill krok po kroku,
• jakie skille warto mieć w zespole,
• czym różnią się Skills, Hooks i MCP,
• jakie błędy najczęściej psują skille,
• na co uważać przy bezpieczeństwie i automatyzacji.

Co to jest Claude Code Skill?

Skill to katalog z plikiem SKILL.md, który opisuje konkretne zadanie, procedurę albo standard pracy.

W praktyce jest to zapisany workflow:

• kiedy go użyć,
• co Claude ma zrobić,
• w jakiej kolejności,
• jakich danych potrzebuje,
• jakich narzędzi może użyć,
• jaki wynik ma zwrócić.

Skill możesz uruchomić ręcznie komendą typu:

Bash
Kopiuj
1
/cleanup-branches

Claude może też użyć skilla automatycznie, jeśli opis w description pasuje do tego, o co prosisz.

Najprościej: skill to prompt, który przestał być jednorazowym promptem i stał się częścią Twojego systemu pracy.

Jak wygląda skill w repo?

Przykładowa struktura:

Kopiuj
1
2
3
4
.claude/
└── skills/
    └── seo-plan-post/
        └── SKILL.md

Plik SKILL.md zawiera frontmatter oraz instrukcję dla Claude.

Przykład:

Markdown
Kopiuj
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

name: seo-plan-post
description: Planuje artykuł SEO od keywordu do briefu. Użyj, gdy użytkownik chce przygotować brief SEO, zaplanować artykuł albo przeanalizować intencję wyszukiwania.

# Instrukcja: SEO Plan Post

## Cel

Przygotuj brief SEO dla artykułu blogowego. Nie pisz pełnego artykułu. Zwróć plan, strukturę i rekomendacje do napisania tekstu.

## KROK 1: Zbierz dane wejściowe

Zapytaj użytkownika o:
- główny keyword,
- intencję wyszukiwania, jeśli ją zna,
- odbiorcę tekstu,
- cel artykułu,
- produkt lub usługę, do której artykuł ma prowadzić.

Jeśli użytkownik podał już te informacje, nie pytaj ponownie.

## KROK 2: Sprawdź dane z GSC

Jeśli w repo dostępny jest skrypt scripts/gsc_fetch.py, użyj go dla podanego keywordu.

Komenda:

python3 scripts/gsc_fetch.py --query "$ARGUMENTS"

Jeśli skrypt nie istnieje albo zwróci błąd, przejdź dalej i zaznacz, że brief powstał bez danych z GSC.

## KROK 3: Zrób research SERP

Sprawdź:
- jakie typy treści dominują w wynikach,
- jakie pytania powtarzają się w topowych artykułach,
- jaką intencję użytkownika widać po wynikach,
- czego brakuje w istniejących materiałach.

## KROK 4: Wygeneruj brief

Zwróć wynik w formacie:

1. Cel artykułu
2. Główna intencja wyszukiwania
3. Proponowany tytuł
4. Meta title
5. Meta description
6. Struktura H2/H3
7. Najważniejsze pytania użytkownika
8. Argumenty i przykłady do użycia
9. Linki wewnętrzne do dodania
10. CTA
11. Czego nie pisać
12. Ryzyka SEO

## Out of scope

Nie pisz pełnego artykułu.
Nie publikuj tekstu w CMS.
Nie wymyślaj danych, których nie ma w źródłach.

Wywołanie może wyglądać tak:

Bash
Kopiuj
1
/seo-plan-post n8n self-hosted

Claude ładuje instrukcję z SKILL.md, wykonuje kroki i zwraca brief. Nie musisz co tydzień pisać: „zrób research SEO, sprawdź intencję, przygotuj H2, dodaj CTA i linki wewnętrzne”.

Gdzie trzymać skille?

To zależy od tego, kto ma z nich korzystać.

1. Skille osobiste

Dla workflow, których używasz we wszystkich projektach:

Kopiuj
1
~/.claude/skills/<skill-name>/SKILL.md

Przykłady:

• summarize-changes,
• commit-helper,
• daily-briefing,
• writing-review,
• meeting-prep.

To dobre miejsce na rzeczy, które są Twoim osobistym stylem pracy.

2. Skille projektowe

Dla workflow specyficznych dla jednego repo:

Kopiuj
1
.claude/skills/<skill-name>/SKILL.md

Przykłady:

• deploy,
• run-local,
• generate-api-client,
• seo-plan-post,
• cms-publish-draft.

To dobre miejsce na standardy zespołu, procedury deployu, konwencje kodu i instrukcje zależne od konkretnego projektu.

3. Skille zespołowe i pluginy

Jeśli skill ma być dystrybuowany szerzej, można go opakować w plugin albo zarządzać nim organizacyjnie. To ma sens dopiero wtedy, gdy zespół ma już kilka działających skilli i wiadomo, które realnie oszczędzają czas.

Na początku wystarczy zwykły katalog .claude/skills/.

Dlaczego Skills zmieniają pracę z Claude Code?

1. Wiedza zostaje w repo

Najlepsze prompty nie giną w historii chatu. Żyją w plikach, które można commitować, reviewować i rozwijać.

Jeśli ktoś w zespole dopracował świetny workflow do code review, deployu albo generowania dokumentacji, nie musi tłumaczyć go każdej osobie osobno. Wystarczy skill.

2. Workflow staje się powtarzalny

Bez skilla:

„Sprawdź ten kod pod kątem bezpieczeństwa, zgodności z CLAUDE.md, testów, błędów, edge case’ów, nazewnictwa, logiki biznesowej i potencjalnych regresji. Na końcu daj listę priorytetów.”

Ze skillem:

Bash
Kopiuj
1
/code-reviewer

Różnica nie polega tylko na krótszym wpisywaniu. Różnica polega na tym, że Claude dostaje za każdym razem ten sam standard oceny.

3. Zespół pracuje według jednego standardu

Jeśli każdy developer pisze własny prompt do review, każdy dostaje trochę inne review.

Skill ustawia wspólną procedurę:

• co sprawdzamy,
• w jakiej kolejności,
• jakie błędy są krytyczne,
• kiedy Claude ma się zatrzymać,
• jak raportować wynik.

To szczególnie ważne przy zadaniach, które mają wpływ na produkcję.

4. Możesz oddzielić wiedzę od zadania

CLAUDE.md dobrze nadaje się do ogólnego kontekstu projektu: architektura, konwencje, stack, zasady pracy.

Skill nadaje się do procedury.

Jeśli w CLAUDE.md zaczyna rosnąć sekcja typu „jak wykonać deploy krok po kroku”, to prawdopodobnie powinna stać się skillem.

5. Skills dobrze łączą się z MCP i Hooks

Skill opisuje workflow.

MCP daje dostęp do zewnętrznych narzędzi, takich jak Notion, GitHub, n8n, baza danych czy CRM.

Hook uruchamia akcję automatycznie przy konkretnym zdarzeniu, na przykład po zapisie pliku albo po zakończeniu odpowiedzi.

Razem dają bardzo mocny zestaw:

• Skill mówi, co zrobić.
• MCP daje dostęp do systemów.
• Hook pilnuje automatycznych reakcji.

Pierwszy skill w 10 minut: cleanup-branches

Zbudujmy prosty skill, który czyści lokalne branche zmergeowane do main.

To dobry przykład, bo:

• ma jasny cel,
• używa komend git,
• wymaga potwierdzenia użytkownika,
• ma ryzyko usunięcia branchy,
• pokazuje, jak pisać bezpieczniejsze instrukcje.

Krok 1: Stwórz katalog

Bash
Kopiuj
1
mkdir -p .claude/skills/cleanup-branches

Krok 2: Stwórz plik SKILL.md

Markdown
Kopiuj
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

name: cleanup-branches
description: Czyści lokalne branche zmergeowane do main albo master. Użyj, gdy użytkownik chce posprzątać lokalne branche po zakończonych feature’ach.
disable-model-invocation: true

# Instrukcja: Cleanup Branches

## Cel

Usuń lokalne branche, które zostały już zmergeowane do głównego brancha.

Nie usuwaj:
- main,
- master,
- develop,
- obecnie aktywnego brancha,
- branchy niezmergeowanych.

Zawsze pokaż listę przed usunięciem i poproś użytkownika o potwierdzenie.

## KROK 1: Sprawdź obecny branch

Wykonaj:

git branch --show-current

Jeśli obecny branch nie jest main ani master, zatrzymaj się i napisz:

„Jesteś na branchu: <nazwa>. Przejdź najpierw na main/master i zaktualizuj repo. Nie usuwam branchy z tego miejsca.”

Nie wykonuj automatycznie checkout, jeśli użytkownik tego nie potwierdzi.

## KROK 2: Zaktualizuj informacje o branchach

Wykonaj:

git fetch --prune

Jeśli komenda zwróci błąd, zatrzymaj się i pokaż błąd użytkownikowi.

## KROK 3: Pobierz listę zmergeowanych branchy

Dla main:

git branch --merged main | grep -v "^\*" | grep -vE "^[[:space:]]*(main|master|develop)$"

Dla master:

git branch --merged master | grep -v "^\*" | grep -vE "^[[:space:]]*(main|master|develop)$"

## KROK 4: Pokaż listę użytkownikowi

Wypisz branche w formacie:

- feat/old-checkout
- fix/legacy-bug
- chore/remove-unused-config

Napisz:

„Znalazłem X lokalnych branchy zmergeowanych do main/master. Usunąć je? Odpowiedz: tak / nie.”

## KROK 5: Usuń branche po potwierdzeniu

Jeśli użytkownik odpowie „tak”, wykonaj dla każdego brancha:

git branch -d <branch-name>

Nie używaj git branch -D, chyba że użytkownik wyraźnie o to poprosi i rozumie ryzyko.

## KROK 6: Podsumuj wynik

Zwróć:

- ile branchy usunięto,
- których nie udało się usunąć,
- czy pojawiły się błędy,
- co użytkownik może zrobić dalej.

Krok 3: Uruchom skill

W Claude Code wpisz:

Bash
Kopiuj
1
/cleanup-branches

Skill powinien pokazać listę branchy i poprosić o potwierdzenie przed usunięciem.

Ważne: skille z efektami ubocznymi muszą być ostrożne

Nie każdy skill powinien działać automatycznie.

Jeśli skill:

• usuwa pliki,
• kasuje branche,
• robi deploy,
• wysyła wiadomości,
• publikuje content,
• zmienia dane w bazie,
• wykonuje migracje,
• korzysta z API zewnętrznych systemów,

to powinien mieć twarde ograniczenia.

W takich skillach warto dodać:

YAML
Kopiuj
1
disable-model-invocation: true

Dzięki temu Claude nie powinien uruchamiać go sam na podstawie luźnego kontekstu rozmowy. Użytkownik musi wywołać go ręcznie.

To ważne szczególnie przy skillach typu:

• /deploy,
• /send-slack-message,
• /delete-old-files,
• /cleanup-branches,
• /publish-draft,
• /run-migration.

Claude może dobrze rozumieć intencję, ale nie powinien sam decydować, że „chyba już czas na produkcję”.

10 skilli, które warto mieć w zespole

Poniżej lista praktycznych skilli, które mogą działać w software house, agencji AI, zespole produktowym albo zespole contentowym.

1. /code-reviewer

Sprawdza większe zmiany w kodzie.

Powinien analizować:

• zgodność z CLAUDE.md,
• potencjalne bugi,
• edge case’y,
• bezpieczeństwo,
• test coverage,
• duplikację logiki,
• migracje i kompatybilność wsteczną,
• czy zmiana nie psuje istniejących założeń.

Dobry output:

• krytyczne problemy,
• rzeczy do poprawy,
• sugestie,
• pytania do autora,
• decyzja: merge / poprawić / wymaga dyskusji.

2. /summarize-changes

Podsumowuje aktualne zmiany w repo.

Przydatne przed commitem, review albo daily.

Może zwracać:

• co się zmieniło,
• jakie pliki są kluczowe,
• jakie ryzyka widać,
• propozycję commit message,
• listę testów do uruchomienia.

3. /deploy

Prowadzi przez deploy.

Taki skill powinien być ręczny, ostrożny i z potwierdzeniami.

Minimalna procedura:

• sprawdź branch,
• sprawdź status repo,
• uruchom testy,
• zbuduj aplikację,
• wypisz plan,
• poproś o potwierdzenie,
• wykonaj deploy,
• sprawdź health check,
• podsumuj wynik.

4. /run-local

Uruchamia projekt lokalnie.

Dobry dla repo, które ma wiele kroków startowych:

• instalacja zależności,
• zmienne środowiskowe,
• baza danych,
• migracje,
• backend,
• frontend,
• worker,
• testowy użytkownik.

Ten skill oszczędza czas szczególnie nowym osobom w zespole.

5. /seo-plan-post

Planuje artykuł SEO od keywordu do briefu.

Może uwzględniać:

• intencję wyszukiwania,
• strukturę H2/H3,
• pytania użytkowników,
• luki w istniejących treściach,
• linkowanie wewnętrzne,
• CTA,
• meta title i meta description.

To nie jest skill do pisania artykułu. To skill do przygotowania briefu.

6. /blog-draft

Generuje pierwszy draft artykułu na podstawie briefu.

Powinien korzystać z:

• tonu marki,
• struktury z briefu,
• zasad formatowania,
• przykładów dobrych tekstów,
• zakazów: czego nie pisać, jakich fraz unikać.

Może kończyć pracę zapisaniem pliku markdown, ale publikacja w CMS powinna wymagać osobnego potwierdzenia albo osobnego skilla.

7. /daily-briefing

Robi poranny radar.

Może sprawdzać:

• nowe issue,
• pull requesty,
• alerty,
• unread messages,
• kalendarz,
• źródła branżowe,
• GSC,
• lead signals.

Dobry output:

• co wymaga reakcji dziś,
• co można odłożyć,
• jakie są szanse sprzedażowe,
• jaki content warto nagrać lub napisać.

8. /meeting-prep

Przygotowuje do rozmowy z klientem.

Może zebrać:

• kim jest klient,
• co już wiadomo,
• jakie były poprzednie ustalenia,
• jakie pytania discovery zadać,
• jakie obiekcje mogą się pojawić,
• jaki powinien być cel spotkania,
• co trzeba ustalić przed końcem rozmowy.

Ten skill jest szczególnie przydatny w sprzedaży konsultacyjnej.

9. /brain-capture

Najprostszy możliwy skill.

Dodaje pomysł, notatkę albo obserwację do jednego pliku inbox, na przykład:

Kopiuj
1
00_INBOX.md

Format może być prosty:

• data,
• źródło,
• notatka,
• tag,
• następny krok.

Taki skill zmniejsza tarcie. Nie trzeba myśleć, gdzie zapisać pomysł.

10. /n8n-build-workflow

Buduje workflow n8n na podstawie opisu.

To już bardziej zaawansowany skill, szczególnie jeśli łączy się z MCP.

Może robić:

• doprecyzowanie wymagań,
• plan workflow,
• wygenerowanie JSON,
• walidację,
• opis node’ów,
• instrukcję testu,
• zapis dokumentacji,
• opcjonalne wgranie workflow do n8n.

Przy tym skillu konieczne są limity i potwierdzenia, bo automatyzacje mogą wpływać na realne dane i procesy.

Skills vs Hooks vs MCP — kiedy czego używać?

Przykład:

Skill /build-workflow mówi Claude’owi, jak zbudować automatyzację.

MCP n8n pozwala utworzyć workflow w n8n.

Hook może po zakończeniu pracy zapisać raport albo uruchomić walidację.

Najprostsza zasada:

• Skill = procedura.
• Hook = automatyczny trigger.
• MCP = integracja z narzędziem.

Anatomia dobrego skilla

Dobry skill nie jest długim promptem wrzuconym do pliku.

Dobry skill jest instrukcją operacyjną.

1. Ma jasny cel

Na początku napisz, co skill robi.

Słabo:

„Pomaga przy SEO.”

Lepiej:

„Przygotowuje brief SEO dla artykułu blogowego. Nie pisze pełnego tekstu. Zwraca strukturę, intencję, pytania użytkowników, meta dane, linkowanie i CTA.”

2. Ma dobry opis w description

description pomaga Claude’owi rozpoznać, kiedy skill ma sens.

Słabo:

YAML
Kopiuj
1
description: SEO skill

Lepiej:

YAML
Kopiuj
1
description: Przygotowuje brief SEO dla artykułu blogowego. Użyj, gdy użytkownik chce zaplanować artykuł, przeanalizować keyword, intencję wyszukiwania albo strukturę H2/H3.

Opis powinien zawierać:

• co skill robi,
• kiedy go użyć,
• czego nie robi,
• typowe frazy użytkownika.

3. Ma kroki w logicznej kolejności

Claude lepiej działa, gdy workflow jest sekwencyjny.

Dobry układ:

1. Sprawdź dane wejściowe.
2. Zbierz brakujące informacje.
3. Wykonaj analizę.
4. Wykonaj akcję.
5. Zweryfikuj wynik.
6. Zwróć raport.

4. Ma konkretne formaty outputu

Nie pisz:

„Podsumuj wynik.”

Napisz:

„Zwróć wynik w formacie:

• Co zrobiono
• Co się udało
• Co się nie udało
• Ryzyka
• Następny krok”

Claude nie powinien zgadywać, jak ma wyglądać odpowiedź.

5. Ma granice

Każdy dobry skill powinien mieć sekcję „Out of scope”.

Przykład:

Markdown
Kopiuj
1
2
3
4
5
6
7
## Out of scope

Nie publikuj artykułu w CMS.
Nie wysyłaj wiadomości do klienta.
Nie wykonuj deployu.
Nie usuwaj plików.
Nie wymyślaj danych, których nie ma w źródłach.

Granice są szczególnie ważne, gdy skill korzysta z narzędzi albo API.

6. Ma obsługę błędów

Nie zakładaj, że wszystko zadziała.

Dodaj instrukcje:

• jeśli komenda zwróci błąd,
• jeśli brakuje pliku,
• jeśli API nie odpowiada,
• jeśli dane są puste,
• jeśli użytkownik nie podał wymaganych informacji,
• jeśli repo jest w złym stanie.

Przykład:

Kopiuj
1
Jeśli `git status --short` pokazuje niezacommitowane zmiany, zatrzymaj deploy i zapytaj użytkownika, czy chce kontynuować.

7. Jest tak krótki, jak się da

Skill nie powinien być książką.

Jeśli instrukcja robi się długa, rozbij ją:

• SKILL.md — główny workflow,
• reference.md — szczegółowe zasady,
• examples.md — przykłady outputu,
• scripts/ — deterministyczne skrypty.

W SKILL.md zostaw tylko to, co Claude musi mieć pod ręką od razu.

Najczęstsze błędy przy pisaniu skilli

1. Skill jest za ogólny

Słabo:

„Pomagaj przy deployu.”

Lepiej:

„Przeprowadź deploy aplikacji Next.js na Vercel. Najpierw sprawdź branch, status repo, testy i build. Nie wykonuj deployu bez potwierdzenia użytkownika.”

Ogólny skill daje ogólne wyniki.

2. Skill miesza kilka zadań naraz

Jeden skill nie powinien robić wszystkiego.

Słabo:

• research SEO,
• brief,
• pisanie artykułu,
• publikacja,
• post na LinkedIn,
• grafika,
• newsletter.

Lepiej rozbić to na kilka skilli:

• /seo-plan-post,
• /blog-draft,
• /cms-publish-draft,
• /linkedin-post,
• /newsletter-draft.

Dzięki temu każdy workflow ma jasny zakres.

3. Brakuje danych wejściowych

Jeśli skill potrzebuje keywordu, URL-a, numeru issue albo środowiska deployu, musi to jasno powiedzieć.

Przykład:

Markdown
Kopiuj
1
2
3
4
5
6
7
8
## Dane wejściowe

Wymagane:
- keyword albo temat,
- odbiorca,
- cel artykułu.

Jeśli brakuje którejś informacji, zapytaj użytkownika przed rozpoczęciem pracy.

Claude nie powinien zgadywać tam, gdzie brak danych zmienia wynik.

4. Ścieżki są zahardkodowane

Słabo:

Kopiuj
1
/Users/kacper/projekty/blog/scripts/gsc_fetch.py

Lepiej:

Kopiuj
1
scripts/gsc_fetch.py

Albo:

Kopiuj
1
$HOME/projekty/blog/scripts/gsc_fetch.py

Najbezpieczniejsze są ścieżki względne względem repo.

5. Skill nie ma potwierdzeń

To błąd przy wszystkim, co zmienia stan systemu.

Potwierdzenia powinny być wymagane przed:

• usunięciem,
• deployem,
• publikacją,
• wysłaniem wiadomości,
• migracją,
• zmianą konfiguracji,
• masową edycją plików.

6. Skill używa za szerokich uprawnień

Jeśli dodajesz allowed-tools, rób to ostrożnie.

Słabo:

YAML
Kopiuj
1
allowed-tools: Bash

Lepiej:

YAML
Kopiuj
1
allowed-tools: Bash(git status *) Bash(git diff *) Bash(git branch *)

Zasada: dawaj tylko te uprawnienia, które są potrzebne do wykonania konkretnego workflow.

7. Skill powtarza to, co Claude robi natywnie

Nie każdy prompt musi być skillem.

Skill ma sens, gdy zadanie:

• powtarza się,
• ma kilka kroków,
• ma standard jakości,
• wymaga konkretnego formatu,
• korzysta z plików, narzędzi albo danych,
• ma ryzyka, które trzeba kontrolować.

Jeśli zadanie brzmi „streść ten plik”, skill prawdopodobnie nie jest potrzebny.

Jak testować skill?

Nie testuj skilla tylko na idealnym przypadku.

Sprawdź:

1. Czy Claude wie, kiedy go użyć?
2. Czy skill działa po ręcznym wywołaniu?
3. Czy pyta o brakujące dane?
4. Czy zatrzymuje się przy błędzie?
5. Czy nie wykonuje ryzykownych akcji bez potwierdzenia?
6. Czy output ma zawsze ten sam format?
7. Czy nowa osoba w zespole rozumie instrukcję?
8. Czy skill nie jest za długi?
9. Czy nie dubluje innego skilla?
10. Czy działa w świeżo sklonowanym repo?

Dobry test to nie tylko „czy działa”.

Dobry test brzmi: „czy działa bezpiecznie, powtarzalnie i zrozumiale dla osoby, która nie pisała tego workflow”.

Minimalny template dobrego skilla

Możesz zacząć od takiego szablonu:

Markdown
Kopiuj
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

name: nazwa-skilla
description: Krótko opisz, co skill robi i kiedy Claude ma go użyć.
disable-model-invocation: true

# Instrukcja: Nazwa skilla

## Cel

Napisz jednym lub dwoma zdaniami, jaki jest cel tego workflow.

## Kiedy używać

Użyj tego skilla, gdy:
- ...
- ...
- ...

## Dane wejściowe

Wymagane:
- ...

Opcjonalne:
- ...

Jeśli brakuje danych wymaganych, zapytaj użytkownika przed rozpoczęciem pracy.

## KROK 1: ...

Instrukcja.

## KROK 2: ...

Instrukcja.

## KROK 3: ...

Instrukcja.

## Obsługa błędów

Jeśli:
- ...
to:
- ...

## Format odpowiedzi

Zwróć wynik w formacie:

1. Co zrobiono
2. Wynik
3. Ryzyka
4. Następny krok

## Out of scope

Nie rób:
- ...
- ...
- ...

Dla skilli bez efektów ubocznych możesz usunąć:

YAML
Kopiuj
1
disable-model-invocation: true

Dla skilli z efektami ubocznymi lepiej zostawić.

Skills marketplace — gdzie szukać gotowych przykładów?

Najlepsze źródła na start:

1. Oficjalne przykłady Anthropic

Warto zacząć od oficjalnych skilli i dokumentacji, bo pokazują aktualny sposób pisania SKILL.md, frontmatter, argumentów i ograniczeń.

2. Repozytoria community

Listy typu „awesome” są dobre do inspiracji, ale trzeba je traktować ostrożnie. Skill z internetu może zawierać komendy, których nie chcesz odpalać u siebie.

3. Własne repo

Najlepsze skille i tak powstaną z Twojej pracy.

Nie zaczynaj od pytania: „jakie skille są modne?”.

Zacznij od pytania:

„Jakie instrukcje powtarzam Claude’owi co tydzień?”

Tam jest pierwszy skill.

Jak wdrożyć skille w zespole?

Nie zaczynaj od biblioteki 50 skilli.

Zacznij od 3–5 workflow, które zespół naprawdę wykonuje regularnie.

Dobre pierwsze skille:

• /code-reviewer,
• /summarize-changes,
• /run-local,
• /deploy-staging,
• /meeting-prep.

Potem ustal standard:

• jak nazywamy skille,
• kto może dodać skill do repo,
• kto robi review,
• kiedy skill wymaga disable-model-invocation,
• jakie narzędzia mogą być w allowed-tools,
• jak testujemy skill przed użyciem w zespole,
• jak opisujemy zmiany w skillach,
• kiedy skill rozbijamy na kilka mniejszych.

Bez tego po miesiącu będziesz mieć nie bibliotekę workflow, tylko nowy folder z chaosem.

Prosty standard nazewnictwa

Używaj nazw w kebab-case:

Dobrze:

Kopiuj
1
2
3
4
5
6
code-reviewer
cleanup-branches
seo-plan-post
blog-draft
meeting-prep
deploy-staging

Słabo:

Kopiuj
1
2
3
4
5
6
CodeReviewer
code_reviewer
review
my-skill
test2
final-deploy-real

Nazwa powinna mówić, co skill robi.

Nie musi być kreatywna. Ma być czytelna.

Kiedy nie robić skilla?

Nie rób skilla, jeśli:

• zadanie jest jednorazowe,
• nie ma powtarzalnego procesu,
• wystarczy zwykły prompt,
• workflow nie jest jeszcze przetestowany,
• zespół nie wie, jaki ma być standard,
• skill miałby automatyzować niejasny proces.

Najpierw dopracuj workflow ręcznie. Dopiero potem zapisz go jako skill.

Automatyzowanie chaosu tylko przyspiesza chaos.

Podsumowanie

Claude Code Skills są jednym z najpraktyczniejszych sposobów na zamianę AI z „asystenta od promptów” w narzędzie do powtarzalnej pracy.

Największa wartość nie polega na tym, że wpisujesz krótszą komendę.

Największa wartość polega na tym, że:

• workflow zostaje w repo,
• zespół używa jednego standardu,
• Claude ma jasne instrukcje,
• procesy są łatwiejsze do testowania,
• ryzykowne akcje można ograniczyć,
• wiedza nie znika w historii rozmów.

Dobry skill nie powinien być długi ani efektowny.

Powinien być jasny, konkretny i bezpieczny.

Zacznij od jednego workflow, który dziś powtarzasz najczęściej. Zapisz go w SKILL.md. Przetestuj na realnym zadaniu. Popraw po pierwszym użyciu.

Tak buduje się bibliotekę skilli, która naprawdę oszczędza czas.

Nauczymy Twój zespół programistyczny korzystać z Claude Code

Jeśli budujesz zespół, który ma pracować z Claude Code na poważnie, nie zaczynaj od przypadkowych skilli.

Zacznij od mapy workflow:

• które zadania powtarzacie najczęściej,
• gdzie Claude realnie skraca pracę,
• które procesy mają ryzyko,
• gdzie potrzebne są potwierdzenia,
• co powinno zostać w CLAUDE.md,
• co powinno stać się skillem,
• co wymaga MCP,
• co lepiej obsłużyć hookiem.

W Dokodu wchodzimy do zespołu programistycznego i uczymy go realnie korzystać z Claude Code: od pierwszych skilli, przez standard nazewnictwa, review i governance, aż po integracje z Twoim repo, CRM, CMS albo n8n. Nie teoria — konkretne workflow, które Twoi developerzy zaczną używać następnego dnia. Szczegóły programu znajdziesz na stronie szkolenia Claude Code i AI-assisted development.

A jeśli wolisz gotowe rozwiązanie zamiast szkolenia — wdrożymy własne workflow i skille AI w Twojej firmie, zintegrowane z Waszym stackiem i procesami.

Umów 30-minutową konsultację, a pokażemy, od których 5 skilli warto zacząć w Twoim zespole — i jak przeszkolić developerów, żeby Claude Code realnie skracał im pracę.

Umów bezpłatną 30-minutową konsultację → szkolenie zespołu z Claude Code

Co czytać dalej

• Claude Code — kompletny przewodnik 2026 — pillar (czym jest, vs Cursor, MCP)
• Claude Code — instalacja krok po kroku — od zera do działającego CLI
• Claude Code — cennik 2026 — który plan dla intensywnego usage
• Claude Code MCP — top 10 serwerów — bo skille często używają MCP
• Agent AI dla firm — pillar dla zarządu

<!--auto-related-->

Powiązane artykuły

• Jak stworzyć agenta AI krok po kroku
• Chatbot RAG na własnych danych (n8n + Qdrant)
• Claude Code — kompletny przewodnik

<!--/auto-related-->