Skille dla GitHub Copilota w zespole: problemem nie jest treść, tylko dystrybucja

Problem nie brzmiał “jak napisać dobre skille”

Kiedy zaczynaliśmy budować wspólną bazę skilli dla GitHub Copilota, zakładałem, że najwięcej czasu zejdzie na treść: konwencje w kodzie, wzorce architektoniczne, zasady review, sposób pisania testów.

Treść okazała się najłatwiejsza.

Realny problem pojawił się w momencie, w którym trzeba było te skille dostarczyć trzydziestu osobom — i utrzymać je w aktualności.

Pierwsza wersja procesu wyglądała dokładnie tak, jak wygląda w większości zespołów:

Sklonuj repo.
Skopiuj pliki do katalogu konfiguracyjnego Copilota.
Powtórz, kiedy coś się zmieni.

To są trzy kroki i mniej niż dziesięć minut pracy. A mimo to ten proces nie działa. Nie dlatego, że jest trudny — dlatego, że jest ręczny, powtarzalny i niewidoczny w codziennym flow.

Sformułowałbym to jako regułę:

Standardy w zespole nie padają dlatego, że są złe. Padają dlatego, że koszt ich wdrożenia jest wyższy niż postrzegana korzyść.

Developer, który ma sprint na karku, nie będzie co tydzień sprawdzał, czy w repo z konfiguracją Copilota pojawił się nowy plik. I ma rację, że nie będzie.

Dodatkowe ograniczenia: to nie jest projekt open source

Do tego doszły warunki brzegowe, które w środowisku korporacyjnym są normą:

repozytorium nie mogło trafić na GitHuba — treść skilli opisuje wewnętrzne konwencje, architekturę i procesy,
dystrybucja musiała działać na firmowym sprzęcie z restrykcyjnymi politykami bezpieczeństwa,
nie było mowy o instalowaniu dodatkowych narzędzi po stronie developera,
proces musiał być na tyle prosty, żeby nie wymagał wsparcia — bo wsparcie to znowu ja.

Klasyczne rozwiązania (marketplace, publiczny package registry, skrypt bash z curl-a) odpadały po kolei.

Rozwiązanie: instalator zamiast instrukcji

Zamiast dopisywać kolejne akapity do README, przeprojektowaliśmy sam sposób dostarczania.

Warstwa 1 — paczka instalacyjna. Jedno uruchomienie po stronie developera. Paczka startuje skrypt PowerShell, który pobiera repozytorium ze skillami, wykłada odpowiednie pliki do katalogów konfiguracyjnych Copilota i instaluje je globalnie — tak, żeby były dostępne we wszystkich projektach, a nie tylko w tym, w którym akurat ktoś siedzi.

Warstwa 2 — aktualizacja jako skill. To jest część, z której jestem najbardziej zadowolony. Aktualizacja nie jest osobnym narzędziem ani wpisem w kalendarzu. Jest skillem. Developer prosi agenta o aktualizację skilli, agent uruchamia ten sam, wersjonowany instalator, ten pobiera aktualną wersję i podmienia pliki.

Efekt: system aktualizuje sam siebie, a jedyna rzecz, którą developer musi pamiętać, to nazwa jednego skilla.

Kilka decyzji projektowych, które okazały się istotne:

skrypt instalacyjny leży w repozytorium ze skillami i jest wersjonowany razem z nimi. Agent nie generuje skryptu ad hoc — uruchamia konkretny, znany plik. To istotne, bo eliminuje ryzyko, że model “wymyśli” inną komendę albo da się namówić na coś innego przez treść, którą właśnie przetwarza,
instalacja globalna, bo skille mają być domyślnym kontekstem, a nie czymś, co trzeba włączyć,
jedna ścieżka dla instalacji i aktualizacji — mniej kodu, mniej rozjazdów, mniej przypadków brzegowych.

Onboarding nowej osoby zszedł z “przeczytaj README, sklonuj, skopiuj” do jednej komendy. Adopcja przestała być kwestią dyscypliny.

Miejsce, w którym trzeba być uczciwym: to jest kanał wykonywania kodu

Tu jest część, którą łatwo pominąć w opisie sukcesu, a której pominąć nie wolno.

Zbudowaliśmy mechanizm, który automatycznie pobiera i uruchamia kod na maszynach całego zespołu. Wygoda i powierzchnia ataku rosną tu dokładnie tą samą krzywą. Jedno przejęte konto z prawem zapisu do repozytorium oznacza wykonanie dowolnego kodu na wszystkich stanowiskach, które wywołają update.

Branch policy i wymuszone review to warstwa pierwsza i jest konieczna — ale chroni przed pomyłką, nie przed przejętym kontem, które ma uprawnienia do zatwierdzania.

Poniżej lista rzeczy, które w takim systemie warto mieć, uporządkowana według zwrotu z włożonego wysiłku:

Mechanizm	Przed czym chroni
Podpis Authenticode skryptu + polityka `AllSigned`	Uruchomieniem podmienionego skryptu — działa po kompromitacji repo
Instalacja z otagowanego wydania zamiast z HEAD gałęzi	Wstrzyknięciem zmiany, która natychmiast rozjeżdża się po zespole
Ograniczenie uprawnień do tworzenia tagów	Luką, o której zwykle się zapomina — branch policy tagów nie pilnuje
Path-based policy na katalogu instalatora, zakaz self-approval	Zmianą w kodzie wykonywalnym przemyconą w dużym PR
Gate w CI na diffie (poza instalatorem tylko `.md`; blokada `Invoke-Expression`, `DownloadString`, `Set-ExecutionPolicy Bypass`, modyfikacji polityk AV)	Typowymi wzorcami złośliwego kodu
Podpisywanie/haszowanie całej paczki, nie tylko skryptu	Podmianą samego markdownu — to też są instrukcje wykonywane przez agenta
Brak podnoszenia uprawnień (instalacja bez admina), zapis wyłącznie do profilu użytkownika, token read-only	Eskalacją uprawnień i wyciekiem poświadczeń
Lokalny log zainstalowanej wersji i hasha	Brakiem możliwości odtworzenia, co u kogo działało
Wersjonowanie + możliwość rollbacku	Wypuszczeniem zepsutego skilla w środku sprintu

Warto zwrócić uwagę na jeden punkt z tej tabeli, bo jest specyficzny dla systemów agentowych: plik skilla to też kod. To markdown, ale agent czyta go jako instrukcje i według nich działa. Ktoś, kto podmieni treść skilla, nie musi w ogóle dotykać skryptu, żeby zmienić zachowanie narzędzia. Integralność trzeba więc weryfikować dla całego pakietu, a nie tylko dla plików wykonywalnych.

Osobno: rozmowa z security

Jeżeli budujesz coś takiego na sprzęcie firmowym, to fakt, że działa, nie jest walidacją. Wzorzec “skrypt pobiera zawartość z zewnątrz i podmienia pliki w profilu użytkownika” jest dokładnie tym, co wykrywają rozwiązania EDR. Kwestią jest tylko czas.

Dużo lepiej przejść przez security review wtedy, kiedy narzędzie jest jeszcze twoim sukcesem, niż tłumaczyć się z niego po alercie. Przy okazji zwykle okazuje się, że organizacja ma już infrastrukturę, która rozwiązuje połowę problemu — wewnętrzny feed artefaktów, repozytorium pakietów, mechanizm dystrybucji oprogramowania. Instalacja z takiego źródła jest zwykle prostsza do obrony niż własny mechanizm klonowania repo.

Czego jeszcze brakuje

Uczciwie, bo system jest młody:

Telemetria. Instalacja to nie to samo co użycie. Bez podstawowych danych (kto na jakiej wersji, które skille faktycznie się odpalają) za trzy miesiące nie odpowiem na pytanie, czy to podniosło jakość pracy, czy jest półkownikiem.
Override na poziomie projektu. Skill sensowny w jednym repozytorium bywa szkodliwy w innym. Globalna instalacja jest dobra jako domyślna, ale musi dać się nadpisać lokalnie.
Changelog czytany przez ludzi. Jeśli po update podpowiedzi zaczynają wyglądać inaczej, developer musi wiedzieć dlaczego.

Wniosek

Najważniejsza rzecz, którą zabieram z tego projektu jako architekt, nie dotyczy AI.

Dystrybucja jest częścią produktu. Jeśli zaprojektowałeś standard, ale nie zaprojektowałeś ścieżki jego instalacji i aktualizacji, to nie zbudowałeś standardu — zbudowałeś dokumentację. A dokumentacja, do której trzeba ręcznie skopiować pliki, przegrywa z brakiem dokumentacji.

Druga rzecz: w momencie, w którym automatyzujesz dostarczanie czegokolwiek wykonywalnego na maszyny zespołu, przestajesz budować usprawnienie, a zaczynasz budować infrastrukturę. Z wszystkimi tego konsekwencjami — wersjonowaniem, podpisami, rollbackiem i rozmową z bezpieczeństwem.