GitHub Spec Kit: specyfikacja przed kodowaniem z AI

GitHub Spec Kit to otwarty zestaw procesów, szablonów i narzędzi CLI do pracy z agentami kodującymi. Jego najważniejsza zasada brzmi: najpierw ustal, co i dlaczego należy zbudować, potem jak to zrealizować. Oficjalna dokumentacja opisuje proces spec-driven development jako specify → plan → tasks → implement → converge. To wsparcie dla AI SDLC, a nie automat, który zamienia każdą specyfikację w poprawny produkt.

Co daje poszczególny etap?

Etap	Pytanie odbioru	Typowy artefakt
Specify	Co ma się zmienić i po czym poznamy sukces?	Specyfikacja scenariuszy oraz warunków akceptacji.
Plan	Jakie granice architektury i ograniczenia obowiązują?	Plan techniczny z zależnościami i ryzykiem.
Tasks	Jak podzielić pracę na sprawdzalne kawałki?	Lista zadań możliwych do przeglądu.
Implement	Czy kod realizuje zadania bez niezamierzonych zmian?	Diff, testy i działające zachowanie.
Converge	Czy wynik jest zgodny ze specyfikacją?	Kontrola rozbieżności i decyzja o poprawce.

Repozytorium GitHub Spec Kit udostępnia CLI specify, szablony oraz integracje z różnymi agentami. W aktualnej dokumentacji istnieją też osobne procesy diagnozy błędów i oceny pomysłów; nie są obowiązkowymi fazami każdej funkcji. Nie należy więc sprowadzać Spec Kit do jednego promptu „napisz specyfikację”.

Przykład w projekcie AI-native

Załóżmy, że agent ma dodać przycisk „zatwierdź rekomendację” do panelu operatora. Specyfikacja powinna rozdzielić propozycję modelu od faktycznego zapisu, określić rolę osoby zatwierdzającej i wymagać śladu audytowego. Plan wskazuje granicę API, politykę uprawnień oraz sposób obsługi ponownego żądania. Zadania dzielą zmianę na kontrakt, backend, UI i test. Dopiero potem agent koduje. W fazie zbieżności trzeba porównać rezultat z warunkami akceptacji, również dla odmowy i awarii narzędzia.

W takim przepływie Spec Kit pomaga utrzymać intencję w trwałych artefaktach. Nie zastępuje właściciela produktu, który ma prawo zmienić wymaganie, ani przeglądu bezpieczeństwa. Specyfikacja może być błędna; jej format nie jest dowodem poprawności.

Dlaczego to pasuje do suwerennego AI SDLC?

Dokumenty, szablony i kod można przechowywać w repozytorium organizacji. Zespół może porównać działanie Codex, Claude Code czy innego agenta przy tych samych wymaganiach. Wymiana wykonawcy nie musi oznaczać utraty uzgodnionej specyfikacji. To korzyść procesowa, nie gwarancja, że każdy agent jednakowo interpretuje polecenia.

AGENTS.md opisuje stałe zasady repozytorium, a SKILL.md może dostarczyć powtarzalną procedurę. Spec Kit organizuje przebieg konkretnej zmiany. Te trzy elementy się uzupełniają: reguły pracy, metoda i artefakt zadania to różne warstwy.

Kiedy wybrać prostszy proces?

Poprawka jednej literówki nie potrzebuje pełnego zestawu dokumentów. Dla małej zmiany wystarczy jasny opis, test i przegląd diffu. Spec Kit daje największą wartość przy wieloetapowej funkcji, zależnościach między zespołami lub ryzyku, że agent napisze działający kod dla źle zrozumianego problemu. Alternatywą jest własny szablon issue i checklisty, zwykłe RFC albo inny proces SDD. Wybór powinien zależeć od kosztu błędnej implementacji, nie od liczby wygenerowanych plików.

Przed przyjęciem narzędzia przeprowadź jedną próbę na realnym zadaniu. Porównaj czas przygotowania specyfikacji, liczbę zmian zakresu po rozpoczęciu kodowania i liczbę uwag w review. Jeśli artefakty powielają się bez poprawy decyzji, uprość proces.