Przejdź do treści
← Kurs M12L02 · Custom Agents i Ekosystem 🏗️
🏗️ Architekt M12L02 M12 · Lekcja 2 z 5 12 min Ćwiczenie

Agent Skills: rozszerzanie możliwości agentów

Czym są Agent Skills i jak pakują instrukcje, skrypty oraz zasoby w przenośne capability, które agent ładuje tylko wtedy, gdy są potrzebne.

Czego się nauczysz

  • Czym skill różni się od instructions, prompt files i MCP tools
  • Jak zbudowany jest katalog skilla z SKILL.md
  • Dlaczego skills są wygodnym sposobem przenoszenia workflow między agentami i projektami

Skill to nie jest mini-plugin ani narzędzie MCP

To rozróżnienie jest absolutnie kluczowe.

Agent Skill to pakiet instrukcji, skryptów i zasobów, który Copilot może załadować wtedy, gdy uzna go za istotny dla zadania albo gdy wywołasz go ręcznie jako slash command.

Skill nie jest tym samym co:

  • project instructions
  • prompt file
  • custom agent
  • MCP server

Najprostsze porównanie: skills vs instructions

Docs pokazują bardzo dobre rozróżnienie.

Instructions opisują zasady projektu i kodowania. Skills uczą wyspecjalizowanej zdolności albo procesu.

Czyli:

  • instructions mówią, jak pracować w tym repo
  • skill mówi, jak wykonać konkretny typ zadania

To właśnie dlatego skill może zawierać nie tylko tekst, ale też przykłady, skrypty i dodatkowe zasoby.

Skill jest katalogiem, nie pojedynczym plikiem

W praktyce skill to folder z obowiązkowym SKILL.md. W tym samym katalogu możesz trzymać:

  • skrypty
  • przykłady
  • szablony
  • pomocnicze zasoby

To bardzo wygodny model, bo capability nie kończy się na instrukcji. Możesz spakować z nią także rzeczy, do których agent odwoła się dopiero wtedy, gdy będą potrzebne.

SKILL.md ma dwa poziomy odpowiedzialności

Frontmatter definiuje tożsamość skilla, a body opisuje, co i kiedy robić.

Najważniejsze pola frontmatter to:

  • name
  • description
  • argument-hint
  • user-invocable
  • disable-model-invocation

To pozwala sterować tym, czy skill:

  • ma być widoczny jako slash command
  • ma ładować się automatycznie
  • ma działać tylko na żądanie

Najciekawsza rzecz: progresywne ładowanie

Dokumentacja opisuje trzy poziomy ładowania skillów:

  1. discovery po name i description
  2. dociągnięcie body z SKILL.md
  3. sięganie po dodatkowe pliki z katalogu dopiero wtedy, gdy są potrzebne

To jest bardzo sprytny model. Dzięki temu możesz mieć wiele skillów bez natychmiastowego zjadania kontekstu.

I właśnie dlatego skills są tak mocne w większych zestawach workflow.

Skill może być slash commandem, ale nie musi

Jeśli ustawisz odpowiednie pola, skill może działać jak ręcznie wywoływany workflow przez /nazwa-skilla.

Ale może też pozostać ukrytym capability package, które agent ładuje sam, gdy uzna je za trafne.

To daje dwa różne style użycia:

  • manualny, gdy chcesz świadomie odpalać proces
  • automatyczny, gdy skill ma być po prostu częścią ekosystemu zachowań agenta

Skills są przenośne z definicji

To jedna z największych zalet.

Agent Skills są opisane jako open standard i działają nie tylko w VS Code. Dokumentacja wprost wskazuje przenośność między VS Code, Copilot CLI i coding agentem.

To ma ogromne znaczenie organizacyjne. Inwestujesz w capability, a nie tylko w jedną lokalną konfigurację IDE.

Gdzie skills mają sens

Najlepsze przykłady to workflow, które:

  • są powtarzalne
  • mają kilka kroków
  • warto dokumentować wraz z przykładami i skryptami
  • nie powinny być always-on jak instructions

Na przykład:

  • webapp testing
  • debugging pipeline
  • review konkretnego typu zmian
  • deployment checklist

Gdzie skills nie mają sensu

Skill nie jest dobrym rozwiązaniem, jeśli chcesz tylko dopisać dwie reguły do generowania kodu. Wtedy wystarczą instructions.

Skill nie jest też zamiennikiem MCP, jeśli problemem jest brak realnego capability do łączenia z zewnętrznym systemem.

Skills mogą przychodzić z pluginów i rozszerzeń

To ważne dla ekosystemu.

Możesz tworzyć skills lokalnie, kopiować z repozytoriów referencyjnych albo korzystać ze skillów dostarczonych przez pluginy i extension contributions.

Ale tak jak przy każdym współdzielonym workflow: trzeba je reviewować. Szczególnie jeśli skill odwołuje się do skryptów.

Ćwiczenie praktyczne

Zaprojektuj skill dla jednego powtarzalnego zadania w swoim projekcie, na przykład:

  • review zmian w API
  • testowanie UI
  • analiza awarii pipeline

Opisz:

  • name i description
  • czy skill ma być user-invocable
  • jakie pliki poza SKILL.md powinny znaleźć się w katalogu
  • co należy do instrukcji, a co do skryptów albo przykładów

Kluczowe wnioski

  • Skill to przenośny pakiet capability, a nie kolejna odmiana instrukcji projektowych.
  • Największą siłą skillów jest progresywne ładowanie i możliwość dołączania zasobów oraz skryptów.
  • Skill sprawdza się wtedy, gdy chcesz opisać wyspecjalizowany workflow, nie ogólne zasady repo.
  • Skills warto projektować jak moduły wiedzy i procesu, a nie jak dump promptów.

Co dalej

Masz już role i capability. Następna lekcja rozszerza ten obraz o zewnętrzny ekosystem: third-party agents i pluginy, czyli wszystko to, co może wejść do Twojego workflow spoza własnego repozytorium.