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.

Notatka

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, ż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ę.

Installed plugins $ install plugin my my-project

plugintypesignedon

figmamcp✓ ed25519

glpimcp✓ ed25519

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, ż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.