Spec Kit, czyli zestaw narzędzi GitHuba do programowania sterowanego specyfikacją, zebrał w kilka tygodni od premiery dwadzieścia dwa tysiące sześćset gwiazdek i sporo uwag od społeczności. Efektem jest paczka zmian: obsługa trzech nowych agentów, działanie na zwykłych Windowsach bez W S L dwa, dwie nowe komendy — /constitution i /implement — oraz możliwość przekazania tokenu GitHuba do C L I, żeby nie uderzać w limity API. Autor projektu przechodzi przez każdą z nich na żywym przykładzie.
Trzy nowe agenty na liście
Przy bootstrapowaniu projektu komendą specify wybiera się agenta, dla którego narzędzie wygeneruje szablony. Do tej pory na liście były Copilot, Claude i Gemini. Doszły trzy kolejne: Cursor, Qwen C L I, Windsurf oraz opencode.
Autor zapowiada, że to nie koniec. W kolejce czekają pull requesty dodające OpenAI Codex, Roo Code i Kilo Code — społeczność zgłaszała je najczęściej.
Osobno trwają prace nad opublikowaniem paczki w rejestrze pakietów Pythona.
Zwykłe Windowsy, bez W S L
Druga zmiana dotyczy systemu. Wcześniej Spec Kit wymagał Linuksa, macOS-a albo skonfigurowanego W S L dwa. Powód był prozaiczny: przy bootstrapowaniu projektu narzędzie wywołuje skrypty pomocnicze, które zbierają kontekst gałęzi, a były to skrypty powłoki.
Teraz te same skrypty są dostępne w PowerShellu. Jeśli pracujesz na maszynie wirtualnej bez możliwości uruchomienia W S L, nie jesteś już odcięty.
Przy okazji uporządkowano widok komend po instalacji. Zamiast rozbudowanego opisu z wariantami uruchomienia pokazuje się teraz sama lista komend do użycia w agencie.
Konstytucja projektu w jednej komendzie
Konstytucja to plik w katalogu memory wewnątrz folderu .specify. Zapisuje się w nim rzeczy nienegocjowalne — te elementy projektu, których model nie ma zgadywać ani zmieniać.
Wcześniej trzeba było poprosić agenta zwykłym promptem: hej, zaktualizuj konstytucję i dopilnuj tych zasad. Teraz jest komenda /constitution, a pod nią gotowy prompt, który zna wymagania i proces.
W demonstracji autor pisze: statyczna strona z minimalnymi zależnościami, zoptymalizowana pod mobile i desktop, responsywna, ze standardami dostępności. Efektem są zmiany w czterech plikach, nie w jednym.
Powstaje sama konstytucja — architektura statyczna, responsywny układ, standardy dostępności, minimalne zależności, optymalizacja wydajności. Ale zmieniają się też szablony. Do szablonu planu wstawiony zostaje blok sprawdzenia zgodności z konstytucją, więc przy pracy nad planem technicznym kontrola odbywa się automatycznie. Do szablonu specyfikacji trafia sekcja wymagań konstytucyjnych. Szablon zadań dostaje analogiczne wpisy.
Tego nie promptowałem. To wszystko jest wbudowane w jedną komendę ze slashem.
Ta sama komenda służy do aktualizacji. Autor dopisuje: używamy Next.js — bo tak zdecydowano w jego organizacji — i konstytucja zostaje rozszerzona o wymagania frameworka, z podbiciem numeru wersji dokumentu. To nadal zwykły plik Markdown, więc każdy wpis można ręcznie poprawić.
Przy okazji pada uwaga o różnicach między modelami. Autor woli w tym zadaniu Sonnet cztery od G P T pięć, bo Sonnet pracuje iteracyjnie i widać kolejne zmiany na bieżąco, zamiast czekać na jeden duży blok na końcu. Zastrzega jednocześnie, że obietnica szybkości Spec Kita jest dyskusyjna i zależy od wybranego modelu — Sonnet potrafi myśleć dłuższą chwilę.
Implementacja też ma swoją komendę
Drugi nowy prompt rozwiązuje problem zgłaszany najczęściej. Kiedy masz już komplet artefaktów — specyfikację, plan, kontrakty, model danych i listę zadań — przychodzi moment na kod. I ludzie się gubili: prosić model o implementację planu czy specyfikacji? Jak to sformułować?
Odpowiedź autora jest jednoznaczna: nie proś modelu własnymi słowami. Użyj /implement.
Komenda sprawdza warunki wstępne, upewnia się, że wszystkie artefakty i zadania są na miejscu, czyta listę zadań i przechodzi przez nie po kolei.
Token GitHuba kontra limity API
Ostatnia zmiana pochodzi od zewnętrznego kontrybutora o pseudonimie ZFish i dotyczy pobierania szablonów. Specify sięga po nie przez API GitHuba, żeby ustalić, które wydanie pobrać — i robi to bez uwierzytelnienia.
Przy pojedynczym użyciu to bez znaczenia. Problem pojawia się w dużej organizacji, gdzie Spec Kit odpala wielu programistów albo gdzie zadania integracji ciągłej pobierają wydania w pętli. Wtedy wspólny limit zapytań anonimowych się kończy.
Rozwiązanie z pull requesta numer trzysta czterdzieści trzy: możesz przekazać token GitHuba. C L I przyjmuje opcję gh-token, można też skorzystać ze zmiennych środowiskowych w rodzaju GH_TOKEN czy GITHUB_TOKEN. Opcja jest opisana w pliku readme repozytorium.
Szablony da się zresztą pobrać także ręcznie — wystarczy wejść w wydania repozytorium, ściągnąć paczkę i rozpakować ją dla swojego agenta.
Co dalej
Autor zapowiada wpis na blogu podsumowujący zmiany oraz materiał o dokumentacji Spec Kita, która dopiero powstaje — chodzi o to, żeby wyszukanie nazwy narzędzia w Google prowadziło od razu do właściwych przewodników.
Zwraca też uwagę na zakładkę Discussions w repozytorium, zwykle pomijaną. Toczą się tam rozmowy o kolejnych integracjach, na przykład o wsparciu dla Aidera.
Jedna prośba proceduralna na koniec: przy większych przepisaniach najpierw zakładaj issue, nie pull request. Duży pull request bez wcześniejszej dyskusji zostanie odrzucony.
Koniec artykułu.