Mamy npm-a dla promptów. Z całym dobrodziejstwem inwentarza. GitHub postanowił dołożyć kolejną warstwę do naszego i tak już skomplikowanego drzewa zależności, tym razem w świecie AI. Wypuścili menedżer pakietów dla promptów, wbudowany bezpośrednio w GitHub CLI. Nowa komenda gh skill, dostępna od wersji v2.90.0, pozwala odkrywać, instalować i zarządzać "skillami" dla różnych asystentów AI prosto z repozytoriów Git.
Funkcja, ogłoszona we wpisie na blogu z 16 kwietnia 2026 roku, jest obecnie w fazie public preview. Opiera się na otwartej specyfikacji Agent Skills i na starcie wspiera zaskakująco szeroką gamę hostów: GitHub Copilot, Claude Code, Cursor, Codex, Gemini CLI i tajemniczy Antigravity.
Instalacja naśladuje menedżery pakietów, z których korzystamy na co dzień:
# Przeglądaj i instaluj skille z repozytorium interaktywnie
gh skill install github/awesome-copilot
# Zainstaluj konkretny skill w określonej wersji
gh skill install github/awesome-copilot/documentation-writer@v1.2.0
# Zainstaluj dla innego agenta
gh skill install OWNER/REPO/SKILL_NAME --agent claude-codeSystem oferuje pewne mechanizmy higieny łańcucha dostaw. Można przypinać "skille" do konkretnego taga, a nawet hasha commita, co zapewnia powtarzalność. To się chwali. W ogłoszeniu pada nawet trafna diagnoza: "Skill, który zmienia się po cichu między instalacjami, stanowi ryzyko dla łańcucha dostaw". Aby temu przeciwdziałać, wykorzystano adresowanie treścią z Gita i zaoferowano wsparcie dla niezmiennych wydań (immutable releases) poprzez ochronę tagów.
I tutaj dokumentacja resetuje wszystkie założenia jednym zdaniem: "Skille nie są weryfikowane przez GitHub i powinny być instalowane na własne ryzyko". Zbudowano mechanizm dystrybucji instrukcji wykonywalnych, bo tym w istocie jest dziś złożony prompt, i formalnie przyjęto politykę umywania rąk od kwestii bezpieczeństwa. Te same dokumenty ostrzegają, że "skille" mogą zawierać "prompt injections, ukryte instrukcje lub złośliwe skrypty", a jako antidotum proponują uruchomienie gh skill preview w celu ręcznej inspekcji zawartości przed instalacją.
Comparison data
| Skanowanie repozytorium (kod, sekrety) | Yes |
|---|---|
| Przypinanie do tagu/SHA | Yes |
| Niezmienne wydania (opcjonalne) | Yes |
| Centralna weryfikacja 'skilli' | No |
Cała odpowiedzialność za weryfikację każdego "skilla" spada więc na programistę. GitHub dostarcza narzędzia do zabezpieczenia się (skanowanie kodu w repozytorium źródłowym, wersjonowanie), ale nie zapewnia infrastruktury zaufania. Nie ma centralnego rejestru, procesu weryfikacji, automatycznego skanowania "pakietów" pod kątem malware. Jest tylko zalecenie: "uważaj". Inne ekosystemy już ten eksperyment przerabiały i wyniki były umiarkowane.
W praktyce wygląda to tak, że przed każdym gh skill install OWNER/REPO/SKILL powinienem najpierw wykonać gh skill preview OWNER/REPO/SKILL i samodzielnie przeanalizować kod. Wróciliśmy do lat 90. i czytania skryptów install.sh przed ich uruchomieniem, tylko zamiast basha mamy pliki Markdown z poleceniami dla LLM.
Gwoli pełnej uczciwości: nad pokrewnym problemem pracuję w PromptScript. Autor bazowego skilla .prs może oznaczyć krytyczne pola jako sealed, a kompilator zwraca twardy błąd w momencie, gdy importowana nakładka próbuje je nadpisać. Złośliwy skill nie podmieni cicho content Twojego lokalnego skilla, bo projekt po prostu się nie skompiluje. Opiszę to szerzej w osobnym artykule.
Funkcja jest w public preview, więc model bezpieczeństwa może jeszcze ewoluować. Na razie GitHub dostarcza Ci runtime, a o audytora każe się zatroszczyć samodzielnie. Audytor, jak zwykle, przyjeżdża z Twojej kieszeni.