Skills dla Claude – kompletny przewodnik po customizacji AI
Skills dla Claude to zaawansowany system instrukcji, który pozwala nauczyć model AI specyficznych workflow i procesów roboczych – raz skonfigurowane umiejętności działają we wszystkich kolejnych rozmowach. W przeciwieństwie do tradycyjnych promptów, Skills eliminują potrzebę wielokrotnego wyjaśniania tych samych preferencji, standardów czy procedur. Dzięki architekturze progressive disclosure i integracji z Model Context Protocol (MCP), Skills przekształcają Claude’a w wyspecjalizowane narzędzie dostosowane do Twoich unikalnych potrzeb.
Czym są Skills dla Claude
Skills (Agent Skills) to zestawy instrukcji zapakowane w prosty folder, które uczą Claude’a jak obsługiwać konkretne zadania i workflow. Każdy Skill składa się z obowiązkowego pliku SKILL.md zawierającego zarówno metadane (YAML frontmatter), jak i szczegółowe instrukcje w Markdown. Opcjonalnie folder może zawierać skrypty wykonywalne, dokumentację referencyjną czy assety wykorzystywane w outputach.
Fundamentalna różnica między Skills a tradycyjnymi promptami polega na trwałości i strukturze. Prompt to jednorazowa instrukcja podawana w rozmowie – musisz ją powtarzać za każdym razem. Skill to uporządkowana wiedza załadowana do systemu Claude’a, która aktywuje się automatycznie gdy zajdzie potrzeba. Zamiast pisać “wygeneruj raport finansowy według naszych standardów korporacyjnych, z tabelami w formacie X, wykresami typu Y i podsumowaniem według metodologii Z” w każdej konwersacji, tworzysz Skill który enkapsuluje te wymagania raz na zawsze.
Skills są przeznaczone dla trzech głównych grup użytkowników:
- Programiści – którzy potrzebują, by Claude konsekwentnie stosował określone workflow, konwencje kodowania czy wzorce architektoniczne
- Power users – automatyzujący powtarzalne procesy jak generowanie dokumentacji, analiza danych czy research
- Zespoły – standaryzujące sposób pracy z AI w całej organizacji (brand guidelines, compliance, procesowe best practices)
Każdy Skill działa identycznie w Claude.ai, Claude Code i przez API – create once, use everywhere. Ta przenośność oznacza, że raz zaprojektowany Skill można wykorzystywać w różnych środowiskach bez modyfikacji kodu.
Dlaczego Skills zmieniają sposób pracy z AI
Problem który rozwiązują Skills jest prosty ale fundamentalny: każda nowa konwersacja z Claude zaczyna się od zera. Nawet jeśli wczoraj szczegółowo wyjaśniłeś jak tworzyć raporty zgodne z wymogami Twojej firmy, dziś musisz to powtórzyć. W przypadku złożonych workflow to oznacza marnowanie czasu, niespójne wyniki i frustrację.
Skills wprowadzają zasadę “naucz raz, korzystaj zawsze”. Z mojego doświadczenia najcenniejsze okazują się w trzech scenariuszach:
Generowanie dokumentów o powtarzalnej strukturze. Zamiast za każdym razem instruować Claude’a o formacie prezentacji, stylach nagłówków, wymaganym brandingu i strukturze slajdów, konfigurujesz Skill który zawiera te standardy. Prosisz “stwórz prezentację Q1 results” – Claude automatycznie stosuje szablon korporacyjny, właściwe czcionki, układ slajdów i tone of voice.
Research i analiza z konsystentną metodologią. Skill może enkapsulować kompletny framework analityczny – od określenia źródeł danych, przez metodologię zbierania informacji, po format finalnego raportu. Każda analiza konkurencji przeprowadzona przez Claude będzie stosować identyczne kryteria oceny, zachowując porównywalność wyników w czasie.
Code review według Twoich standardów. Zamiast wyjaśniać przy każdym pull requeście “sprawdź czy kod stosuje nasze konwencje nazewnictwa, czy testy pokrywają edge cases, czy dokumentacja jest aktualna”, tworzysz Skill który automatycznie przeprowadza review według tych kryteriów.
Skills szczególnie błyszczą w połączeniu z wbudowanymi możliwościami Claude’a jak code execution czy document creation. Skill może nie tylko wygenerować strukturę dokumentu, ale też wykonać skrypty walidacyjne, przetworzyć dane i stworzyć finalny output – wszystko w jednym, zautomatyzowanym przepływie.
Dla zespołów budujących integracje z Model Context Protocol, Skills dodają warstwę wiedzy na surowym dostępie do narzędzi. MCP daje Claude’owi możliwość wywołania API Twojego serwisu, ale Skill uczy go jak to robić efektywnie – jaką sekwencję wywołań zastosować, jak obsługiwać błędy, jakie są best practices dla Twojej platformy.
Progressive Disclosure – architektura trzech poziomów
Kluczową innowacją Skills jest system progressive disclosure – inteligentnego ładowania kontekstu. Zamiast wpychać całą wiedzę do każdej rozmowy (co zjadałoby ogromną liczbę tokenów), Skills wykorzystują trzystopniową hierarchię:
Poziom 1: YAML frontmatter (zawsze załadowany). Znajduje się w system prompt Claude’a i zawiera absolutne minimum – nazwę Skilla i zwięzły opis. To wystarcza, by Claude wiedział że taki Skill istnieje i kiedy powinien go użyć. Przykład: “Skills: notion-setup (tworzy struktury workspace w Notion)”. Claude widzi to przy każdym zapytaniu, ale zużywa zaledwie kilkanaście tokenów.
Poziom 2: SKILL.md body (ładowany gdy relevant). Gdy Claude stwierdzi że Skill jest istotny dla bieżącego zadania – dopiero wtedy wczytuje pełne instrukcje z ciała pliku SKILL.md. Te instrukcje zawierają szczegółowy workflow, best practices, przykłady użycia i troubleshooting. To rdzeń Skilla – dokładne przepisy “jak” wykonać zadanie.
Poziom 3: Linked files (na żądanie). Jeśli w trakcie wykonywania workflow Claude potrzebuje dodatkowej dokumentacji – może nawigować do plików w folderze references/ i załadować je selektywnie. Przykład: Skill do analizy finansowej może mieć w references/ szczegółowe opisy metryk księgowych, ale Claude załaduje je tylko gdy napotka nieznany wskaźnik.
Dlaczego to ważne? Minimalizacja zużycia tokenów przy zachowaniu specjalistycznej wiedzy. Wyobraź sobie że masz 20 różnych Skills – gdyby wszystkie były zawsze w pełni załadowane, zużyłbyś setki tysięcy tokenów w system prompt zanim w ogóle zaczniesz rozmowę. Progressive disclosure oznacza, że płacisz tylko za to co faktycznie potrzebne w danym momencie.
Ten mechanizm działa automatycznie – nie musisz manualnie włączać/wyłączać Skills. Claude sam ocenia na podstawie Twojego zapytania które Skills mogą być pomocne i ładuje je progresywnie. System ten pozwala utrzymywać nawet 20-50 Skills jednocześnie aktywnych, bez degradacji wydajności.
Podstawowa struktura Skills
Każdy Skill to folder o nazwie w formacie kebab-case (małe litery, wyrazy połączone myślnikami). Wewnątrz folderu znajdują się pliki według ściśle określonej konwencji:
your-skill-name/
├── SKILL.md # OBOWIĄZKOWY - główny plik skilla
├── scripts/ # opcjonalne - kod wykonywalny
│ ├── process.py
│ └── validate.sh
├── references/ # opcjonalne - dokumentacja
│ ├── api-guide.md
│ └── examples/
└── assets/ # opcjonalne - szablony, fonty, ikony
└── template.md
Wymagania krytyczne – bezwzględne:
Nazwa pliku SKILL.md musi być dokładnie taka (case-sensitive). Nie zadziałają warianty: SKILL.MD, skill.md, Skill.md. Tylko SKILL.md – system nie rozpozna innych nazw.
Nazwa folderu musi być w kebab-case: notion-project-setup ✅, natomiast Notion Project Setup ❌, notion_project_setup ❌, NotionProjectSetup ❌. Bez spacji, bez underscores, bez wielkich liter.
Brak README.md wewnątrz folderu Skilla. Cała dokumentacja idzie do SKILL.md lub do references/. README.md jest zarezerwowany dla repozytorium GitHub gdy dystrybuujesz Skill publicznie (o czym w kolejnych artykułach serii), ale nie może znajdować się w samym folderze Skilla – powoduje konflikty.
Minimalna zawartość SKILL.md to frontmatter YAML plus instrukcje Markdown:
markdown
---
name: your-skill-name
description: Co robi i kiedy używać.
---
# Instrukcje
Twój workflow krok po kroku...
To absolutne minimum. Foldery scripts/, references/ i assets/ są opcjonalne – dodajesz je gdy Skill potrzebuje wykonywać kod, linkować do rozbudowanej dokumentacji lub wykorzystywać template’y. Większość prostych Skills to po prostu SKILL.md – nic więcej.
Katalogi są read-only dla niektórych lokalizacji (np. Skills zainstalowane z MCP są montowane tylko do odczytu), dlatego jeśli Skill musi modyfikować pliki – pracuje na kopiach w working directory Claude’a, nie w własnym folderze.
YAML frontmatter – najbardziej krytyczna część
YAML frontmatter to metadane na początku SKILL.md otoczone ---. To najbardziej krytyczny fragment całego Skilla – to on decyduje czy Claude załaduje Skill w odpowiednim momencie.
Minimalna poprawna struktura:
yaml
---
name: your-skill-name
description: Co robi. Używaj gdy użytkownik [konkretne frazy].
---
To wszystko czego bezwzględnie potrzebujesz. Dwa pola: name i description.
Wymagania dla pola name:
- Tylko kebab-case (małe litery, myślniki jako separatory)
- Brak spacji, brak wielkich liter
- Powinno odzwierciedlać nazwę folderu
- Przykład:
notion-workspace-setup
Wymagania dla pola description (tutaj jest cały klucz):
Description MUSI zawierać dwa elementy:
- Co Skill robi – zwięzłe wyjaśnienie funkcjonalności
- Kiedy go używać – konkretne frazy trigger, które użytkownik może wypowiedzieć
Maksymalna długość: 1024 znaki. To jedyne info które Claude widzi zawsze (poziom 1 progressive disclosure), więc musi być na tyle precyzyjne, by Claude wiedział kiedy Skill załadować, ale wystarczająco zwięzłe by nie marnować tokenów.
Przykład dobrego description:
yaml
description: Analizuje pliki Figma i generuje dokumentację developer handoff. Używaj gdy użytkownik uploaduje .fig, pyta o "design specs", "component docs" lub "design-to-code handoff".
Dlaczego to działa:
- Jasno określa co robi (analiza Figma → docs)
- Wymienia konkretne trigger phrases (“design specs”, “component docs”)
- Wskazuje trigger na poziomie typu pliku (.fig)
Przykład złego description:
yaml
description: Pomaga z projektami.
Dlaczego nie działa:
- Zbyt ogólne – co to znaczy “pomaga”?
- Brak trigger phrases – kiedy załadować?
- Claude nie będzie wiedział czy to pasuje do zapytania
Opcjonalne pola frontmatter:
yaml
license: MIT # Jeśli open-source
compatibility: "Wymaga Node.js 18+, dostęp do sieci"
metadata:
author: Twoja Firma
version: 1.0.0
mcp-server: nazwa-serwera
- license – standardowe licencje (MIT, Apache-2.0) gdy dystrybuujesz publicznie
- compatibility – wymogi środowiskowe (pakiety systemowe, sieć, itp.)
- metadata – dowolne custom fields (autor, wersja, powiązany MCP server)
Zakazane w frontmatter – security restrictions:
Absolutnie nie możesz użyć:
- XML angle brackets (
<>) – ryzyko injection do system prompt - Nazw zawierających “claude” lub “anthropic” (zarezerwowane)
Frontmatter pojawia się w system prompt Claude’a, dlatego złośliwa zawartość mogłaby wstrzyknąć niepożądane instrukcje. Anthropic stosuje safe YAML parsing i blokuje niebezpieczne konstrukcje.
Przykłady dobrych i złych descriptions w praktyce:
| Dobry ✅ | Zły ❌ |
|---|---|
Manages Linear workflows: sprint planning, task creation, status tracking. Use when user mentions "sprint", "Linear tasks", or "project planning". | Helps with projects. |
End-to-end customer onboarding for PayFlow: account creation, payment setup, subscriptions. Use when "onboard customer", "set up subscription", "create PayFlow account". | Creates sophisticated multi-page systems. |
Analyzes CSV data with statistical models. Use for "regression", "clustering", "statistical analysis". NOT for simple data exploration. | Processes data. |
Pierwsze przykłady są konkretne, zawierają trigger words i jasno określają scope. Drugie są zbyt ogólne – Claude nie będzie wiedział kiedy je załadować.
Skills a MCP – kuchenna analogia
Gdy rozmawiamy o Skills w kontekście Model Context Protocol, najlepsza jest analogia do profesjonalnej kuchni:
MCP to profesjonalna kuchnia – dostarcza dostęp do narzędzi, składników i sprzętu. Masz połączenie do Notion API (półki z produktami), Linear API (piece i patelnie), GitHub API (noże i deski). Claude może teoretycznie wszystko wywołać, ale nie wie jak to zrobić efektywnie.
Skills to przepisy – szczegółowe instrukcje krok po kroku jak stworzyć konkretną potrawę. “Aby stworzyć projekt w Notion: 1) stwórz stronę główną, 2) dodaj database dla tasków, 3) skonfiguruj properties, 4) wygeneruj template.” To workflow, best practices, sekwencja kroków.
Razem tworzą wartość – profesjonalna kuchnia bez przepisów wymaga od kucharza (użytkownika) ciągłego instruowania co robić. Przepisy bez kuchni to tylko teoria. Połączenie MCP + Skills daje autonomicznych agentów AI, którzy wykonują złożone zadania bez mikromanagementu.
Dlaczego to ma znaczenie dla użytkowników MCP:
Bez Skills:
- Użytkownik łączy MCP ale nie wie co dalej
- Support tickets typu “jak zrobić X z waszą integracją”
- Każda rozmowa zaczyna się od zera
- Niespójne wyniki – każdy promptuje inaczej
- Użytkownicy obwiniają connector gdy problem leży w braku guidance
Ze Skills:
- Pre-built workflows aktywują się automatycznie
- Konsystentne, reliable użycie narzędzi
- Best practices wbudowane w każdą interakcję
- Niższa krzywa uczenia się dla integracji
- Lepsze pierwsze wrażenie (time-to-value)
Z mojego researchu wynika, że Skills mogą zredukować czas onboardingu użytkowników MCP o 60-80%. Zamiast czytać dokumentację API i eksperymentować z tool calls, użytkownik po prostu mówi “set up new project” – Skill orkiestruje całą sekwencję wywołań zgodnie z best practices.
Kiedy używać tylko Skills (bez MCP):
Skills nie wymagają MCP – mogą bazować wyłącznie na wbudowanych możliwościach Claude’a:
- Generowanie dokumentów (docx, pptx, markdown)
- Code execution (Python scripts, bash commands)
- Analiza uploaded files
- Tworzenie artifacts (React components, HTML, SVG)
Przykład: Skill do tworzenia frontend designs nie potrzebuje żadnego MCP – wykorzystuje tylko artifact system Claude’a do generowania kodu React/HTML z embedded style guides.
Kiedy używać Skills + MCP:
Gdy workflow wymaga dostępu do zewnętrznych systemów:
- Zarządzanie projektami (Notion, Asana, Linear)
- Automatyzacja developmentu (GitHub, GitLab)
- Monitoring i debugging (Sentry, Datadog)
- Communication (Slack, email)
MCP dostarcza real-time data access i tool invocation, Skill dostarcza orchestration logic i domain expertise. To synergia którą najlepiej ilustruje przykład z dokumentacji Anthropic – Sentry code review Skill:
- MCP server Sentry dostarcza access do error monitoring data
- Skill enkapsuluje workflow: pobierz błędy → przeanalizuj kod → zaproponuj fix → stwórz PR na GitHub
- Użytkownik mówi “fix bugs from last deploy” – Skill automatycznie orkiestruje całą sekwencję z wykorzystaniem Sentry MCP + GitHub MCP
Bez Skilla użytkownik musiałby manualnie prowadzić Claude’a przez każdy krok. Skill to automatyzacja którą skonfigurujesz raz, a która działa wielokrotnie.
Pierwsze kroki – jak zacząć
Instalacja Skilla w Claude.ai:
- Otwórz Settings → Skills (zakładka w ustawieniach)
- Kliknij “Upload skill”
- Wybierz folder Skilla (spakowany jako ZIP jeśli uploadujesz) lub przeciągnij folder
- Skill pojawi się na liście – toggle go ON
- Gotowe – Claude automatycznie załaduje Skill gdy zajdzie potrzeba
Instalacja w Claude Code:
- Umieść folder Skilla w katalog Claude Code skills directory
- Lokalizacja różni się per OS – sprawdź dokumentację
- Restart Claude Code
- Skill pojawi się automatycznie w liście dostępnych
Użyj skill-creator do pierwszego Skilla:
Najszybszy sposób aby stworzyć funkcjonalny Skill to wykorzystać built-in skill-creator skill dostępny w Claude.ai:
Użyj skill-creator aby pomóc mi zbudować Skill do [Twój use case]
skill-creator poprowadzi Cię przez:
- Definiowanie use case (trigger → steps → result)
- Generowanie poprawnego YAML frontmatter
- Sugerowanie trigger phrases i struktury
- Review i identyfikację potencjalnych problemów
Z mojego doświadczenia 15-30 minut z skill-creator wystarcza aby stworzyć i przetestować funkcjonalny Skill. To interaktywny proces – skill-creator zadaje pytania, generuje draft, Ty testujesz i iterujesz.
Test “hello world” Skilla:
Stwórz najprostszy możliwy Skill aby zrozumieć mechanikę:
markdown
---
name: hello-skill
description: Testowy skill który odpowiada "Hello from Skill!". Używaj gdy użytkownik pyta o test skilla.
---
# Hello Skill
Gdy użytkownik pyta o test, odpowiedz:
"Hello from Skill! Ten skill został poprawnie załadowany."
Zapisz to jako SKILL.md w folderze hello-skill/, zapakuj do ZIP, uploaduj w Settings → Skills, włącz go i zapytaj Claude’a:
Czy możesz przetestować hello skill?
Claude powinien odpowiedzieć dokładnie według instrukcji ze Skilla. Jeśli tak – gratulacje, Twój pierwszy Skill działa! Jeśli nie – sprawdź czy nazwa folderu, nazwa pliku i frontmatter są dokładnie według wymagań (case-sensitive!).
Następny krok to projektowanie i tworzenie Skilla który rozwiązuje realny problem w Twoim workflow. W kolejnym artykule tej serii pokażę jak skutecznie planować use cases, pisać efektywne instrukcje i wykorzystać wzorce które sprawdziły się w produkcji. Omówimy również techniki prompt engineering specyficzne dla Skills – bo Skills to nie tylko treść, ale też struktura która maksymalizuje skuteczność AI.
Skills (Agent Skills) to zestawy instrukcji zapisane w pliku SKILL.md, które uczą Claude’a konkretnych workflow raz — i aktywują się automatycznie we wszystkich kolejnych rozmowach bez potrzeby powtarzania. Kluczowa różnica wobec promptu: prompt to jednorazowa instrukcja, którą musisz wpisywać na nowo w każdej sesji. Skill to trwała wiedza załadowana do systemu — Claude sam rozpoznaje, kiedy jej użyć. Przykład: zamiast każdorazowo tłumaczyć format raportów, styl nagłówków i wymagania brandingowe, konfigurujesz Skill raz i piszesz tylko “stwórz raport Q1” — reszta dzieje się automatycznie.
Każdy Skill to folder w formacie kebab-case zawierający obowiązkowy plik SKILL.md z YAML frontmatter i instrukcjami Markdown — nazwa pliku jest case-sensitive i musi brzmieć dokładnie SKILL.md. Minimalna poprawna struktura to dwa pola w frontmatter: name (kebab-case, bez spacji i wielkich liter) oraz description (maksymalnie 1024 znaki). Description to najważniejszy element — musi zawierać zarówno co Skill robi, jak i konkretne frazy trigger, które aktywują jego załadowanie. Przykład skutecznego description: “Analizuje pliki Figma i generuje dokumentację developer handoff. Używaj gdy użytkownik uploaduje .fig, pyta o ‘design specs’ lub ‘design-to-code handoff’.” Foldery scripts/, references/ i assets/ są opcjonalne — większość prostych Skills to wyłącznie SKILL.md.
Progressive Disclosure to trzystopniowy mechanizm ładowania wiedzy, który sprawia, że Claude płaci tokenami tylko za to, czego faktycznie potrzebuje w danym momencie — nie za całą bibliotekę Skills naraz. Poziom 1: tylko YAML frontmatter (kilkanaście tokenów) jest zawsze widoczny — Claude wie, że Skill istnieje. Poziom 2: pełne instrukcje z ciała SKILL.md są ładowane dopiero gdy Claude oceni, że Skill jest releventny dla bieżącego zapytania. Poziom 3: pliki z folderu references/ są ładowane selektywnie, wyłącznie gdy workflow ich wymaga. Praktyczny efekt: możesz utrzymywać 20–50 aktywnych Skills jednocześnie bez degradacji wydajności ani eksplozji kosztów — system ładuje tylko to, co potrzebne.
Skills i MCP działają jak przepisy i profesjonalna kuchnia — MCP dostarcza dostęp do narzędzi (Notion API, GitHub, Linear), a Skill enkapsuluje wiedzę jak ich używać efektywnie: sekwencję wywołań, obsługę błędów i best practices. Bez Skilla użytkownik musi prowadzić Claude’a krok po kroku przez każde wywołanie API. Ze Skillem wystarczy powiedzieć “napraw błędy z ostatniego deploy” — Skill automatycznie orkiestruje pobranie błędów z Sentry, analizę kodu, propozycję fixa i stworzenie PR na GitHubie. Skills nie wymagają MCP — mogą działać wyłącznie na wbudowanych możliwościach Claude’a (generowanie dokumentów, code execution, analiza plików). MCP jest potrzebny tylko gdy workflow wymaga dostępu do zewnętrznych systemów w czasie rzeczywistym.
Instalacja Skilla w Claude.ai wymaga wejścia w Settings → Skills, kliknięcia “Upload skill” i przesłania folderu Skilla (spakowanego jako ZIP) — po włączeniu przełącznika Claude automatycznie wykrywa i ładuje Skill gdy zajdzie potrzeba. W Claude Code umieszczasz folder Skilla w dedykowanym katalogu skills directory (lokalizacja zależy od systemu operacyjnego) i restartujesz aplikację. Skills działają identycznie w Claude.ai, Claude Code i przez API — tę samą konfigurację możesz używać w każdym środowisku bez modyfikacji. Ważne ograniczenie: wewnątrz folderu Skilla nie może znajdować się plik README.md — powoduje konflikty. Cała dokumentacja trafia do SKILL.md lub do references/.
Trzy błędy eliminują działanie Skilla zanim w ogóle się uruchomi: zła wielkość liter w nazwie pliku (skill.md zamiast SKILL.md), niepoprawny format nazwy folderu (spacje lub podkreślniki zamiast myślników) oraz zbyt ogólny opis w polu description. Nazwy pliku i folderu są case-sensitive i muszą być dokładnie według konwencji: folder moj-skill/, plik SKILL.md. Description bez konkretnych fraz trigger (“Pomaga z projektami”) sprawia, że Claude nie wie kiedy Skill załadować — opis musi zawierać dosłowne słowa kluczowe, których użytkownik może użyć. Dodatkowo: w YAML frontmatter nie wolno używać znaków < > ani nazw zawierających “claude” lub “anthropic” — Anthropic blokuje te konstrukcje ze względów bezpieczeństwa (ochrona przed injection do system promptu).

