# Stallion ## Co robi Stallion nie jest wtyczką, przez którą łączysz Claude'a z jakąś usługą. To zestaw narzędzi dla programisty, który buduje inne wtyczki Speedwave. Tworzy szkielet nowej wtyczki na bazie szablonu, podnosi jej wersję, zapisuje changelog i dostarcza wspólny pipeline CI, z którego korzysta każda wtyczka, żeby się zbudować, podpisać i opublikować. Jeśli piszesz wtyczki dla Speedwave, Stallion odwala za ciebie tę powtarzalną część roboty. Jak każdą wtyczkę Speedwave, także samego Stalliona pisze, rozwija i dostarcza wyłącznie Speednet. ## Z czego się składa Stallion ma dwie twarze. Jako zainstalowana wtyczka dodaje wspólne instrukcje dla Claude'a (`claude-resources/CLAUDE.md`), zamontowane w trybie tylko do odczytu i importowane przez każdą utworzoną wtyczkę, a do tego trzy polecenia ukośnikowe i jeden hook. Jako repozytorium dostarcza wspólny szablon GitLab CI (`.build-plugin.yml`), który każda wtyczka dołącza do siebie, żeby się zbudować, podpisać i opublikować, oraz lokalny skrypt budujący do testów. **Note:** Manifest Stallion deklaruje tylko `["skills", "commands", "hooks"]`. Nie ma tu `service_id`, portu, `Containerfile` ani workera. Stallion nie uruchamia niczego w kontenerze, tylko dodaje zasoby, z których Claude korzysta, gdy budujesz wtyczkę. Zobacz [korzystanie z wtyczek](/pl/docs/plugins/using-plugins/), żeby poznać ogólne zasady, na jakich zainstalowane wtyczki dodają polecenia, umiejętności i hooki. ### Umiejętności i polecenia | Nazwa | Co robi | | --- | --- | | Umiejętność `create-plugin` | Prowadzi cię przez założenie nowej wtyczki na podstawie zwykłego opisu: slug, worker czy wtyczka zasobowa, szkielet, manifest. | | Umiejętność `add-oauth` | Podpina logowanie oparte na tokenie dla wtyczki MCP, trzymając same dane uwierzytelniające poza zasięgiem workera. | | Polecenie `/stallion:new-plugin` | Zakłada katalog nowej wtyczki na bazie wspólnego szablonu. | | Polecenie `/stallion:bump` | Synchronizuje numer wersji między manifestem, `package.json` a plikami lockfile. | | Polecenie `/stallion:changelog` | Przygotowuje changelog dla wersji, która jest akurat ustawiona. | ### Narzędzia Stallion nie ma workera MCP i nie udostępnia żadnych narzędzi, a jedynie wymienione wyżej umiejętności, polecenia i hooki. ## Jak to działa Poproś Claude'a, żeby utworzył szkielet wtyczki, na przykład poleceniem `/stallion:new-plugin jira "Jira Integration"`, a Claude skopiuje drzewo szablonu do katalogu nowej wtyczki i podmieni w nim miejsca do wypełnienia: slug, nazwę wyświetlaną, domyślny port 4010, domyślny limit pamięci 256 MiB oraz wersję Stallion, która utworzyła szkielet. Generator sprawdza slug wyrażeniem `^[a-z][a-z0-9-]{0,63}$` i odrzuca 13 zarezerwowanych, wbudowanych identyfikatorów usług: slack, sharepoint, redmine, gitlab, github, atlassian, office, playwright, context7, os, oauth, ide i host_exec. Możesz też po prostu opisać zwykłym językiem wtyczkę, jakiej potrzebujesz, i zostawić umiejętności `create-plugin` zebranie sluga, pytanie o to, czy chodzi o workera MCP, czy o wtyczkę zasobową, uruchomienie generatora i przeprowadzenie cię przez uzupełnianie manifestu oraz narzędzi. Wydanie nowej wersji przebiega w kolejności: podbicie wersji, potem changelog, potem commit. `/stallion:bump` podnosi wersję naraz w manifeście, `package.json` i plikach lockfile, a `/stallion:changelog` odczytuje tę wersję i proponuje punkty do changeloga, podzielone na wpisy widoczne dla użytkownika i wpisy przeznaczone wyłącznie dla programistów. CI publikuje nową wersję po scaleniu do głównej gałęzi i nie pozwala ponownie opublikować wersji, która już istnieje. Sam pipeline budujący ma trzy etapy uruchamiane na głównej gałęzi. Etap build kompiluje wtyczkę. Etap sign odtwarza algorytm cyfrowego odcisku wtyczki Speedwave (SHA-256 liczony po plikach posortowanych według ścieżki, z ramkowaniem długości, podpisany kluczem Ed25519), używając prywatnego klucza podpisującego Speednet jako chronionej zmiennej CI, i przerywa działanie, gdy natrafi na jakikolwiek symlink. Etap publish wysyła podpisane archiwum ZIP do rejestru pakietów GitLab. ## Jak to skonfigurować Wtyczki zależą od pakietów `@speedwave/*` z prywatnego rejestru npm w GitLabie, więc zanim zrobisz cokolwiek innego, czeka cię jeden krok na poziomie maszyny: utwórz w GitLabie deploy token z uprawnieniem do odczytu rejestru pakietów i wyeksportuj go jako `NPM_TOKEN`. Dokładne, jednorazowe kroki znajdziesz w pliku README repozytorium Stallion. Potem zainstaluj Stallion w swoim projekcie do tworzenia wtyczek i utwórz pierwszą wtyczkę poleceniem `/stallion:new-plugin` albo opisując ją Claude'owi. Gdy wtyczka potrzebuje OAuth2 zamiast statycznego tokenu, poproś o to Claude'a, a umiejętność `add-oauth` przeprowadzi cię przez blok `oauth` w manifeście, punkty montowania w środowisku uruchomieniowym oraz mechanizm odświeżania tokenu po błędzie 401, biorąc [wtyczkę GLPI za wzorcową implementację](/pl/docs/plugins/catalog/glpi/). ## Granice bezpieczeństwa Polecenia i skrypty Stallion działają bezpośrednio z zainstalowanej wtyczki; nie ma osobnego kroku instalacji ani osobnej kopii dla każdego repozytorium. Klucz podpisujący, który potwierdza autentyczność wtyczki, jest chronioną zmienną CI, a nigdy czymś, co autor wtyczki trzyma u siebie bezpośrednio. Lokalny, niepodpisany build zainstaluje się tylko wtedy, gdy ustawisz furtkę awaryjną `SPEEDWAVE_ALLOW_UNSIGNED=1`, bo domyślnie Speedwave instaluje wyłącznie podpisane wtyczki. Gdy utworzona wtyczka dodaje OAuth2, worker widzi jedynie krótkotrwały token dostępu; sekret klienta i token odświeżający zostają po stronie hosta. Zobacz [jak obsługiwane są dane uwierzytelniające](/pl/docs/security/credentials/), żeby poznać ten model w całości. Własny hook Stallion, `repos-shortcuts.mjs`, jest zaimplementowany, ale oznaczony jako "jeszcze nie działa" w przypadku zainstalowanej wtyczki, więc pozostaje nieaktywny.