GitHub Spec Kit vs Kiro vs Claude Code – przepływy pracy SDD

Programiści porównujący konfiguracje rozwoju opartego na specyfikacjach (Spec-Driven Development) w 2026 roku zazwyczaj nie pytają, który model językowy jest najinteligentniejszy. Pytają o to, który przepływ pracy utrzyma agenta AI w zgodności z założeniami, nie pochłaniając zespołu w zbędnych rytuałach.

GitHub Spec Kit, AWS Kiro oraz niestandardowe przepływy pracy Claude Code implementują ten sam szeroki pomysł — wymagania, projekt, zadania, implementacja, walidacja — ale różnią się portowalnością, głębokością integracji oraz stopniem wymuszania procesów.

Jeśli najpierw potrzebujesz zrozumieć koncepcje, przeczytaj Czym jest rozwój oparty na specyfikacjach? oraz neutralny narzędziowo przewodnik Przepływ pracy rozwoju opartego na specyfikacjach w klastrze dokumentacji Architektura aplikacji. Porównanie to znajduje się w hubie Narzędzia dla deweloperów AI obok recenzji asystentów i przewodników po przepływach pracy.

SDD staje się kategorią narzędzi

Rozwój oparty na specyfikacjach (SDD) przestał być ćwiczeniem na papierze gdzieś pod koniec 2025 roku. Każdy duży dostawca kodujących agentów AI oferuje teraz swoją wersję cyklu: specyfikacja-plan-implementacja, a rosnąca lista niezależnych narzędzi rywalizuje o to, ile struktury dodają wokół tej pętli.

Porównanie, które ma znaczenie, to nie „które narzędzie wygrywa”. To głębokość procesu versus portowalność. Kiro jest zintegrowany. Spec Kit jest przenośny. Przepływy pracy Claude Code są podatne na modyfikacje (hackable). Złe specyfikacje pogarszają pracę każdego agenta, niezależnie od tego, którą nakładkę wybierzesz. Dobre specyfikacje działają między narzędziami.

Jak porównywać konfiguracje SDD

Zanim wybierzesz narzędzie, nazwij to, co optymalizujesz. Ta sama funkcja może wydawać się bez wysiłku w jednym setupie i biurokratyczna w innym, w zależności od wielkości zespołu, wieku bazy kodu i tego, ile recenzji potrzebujesz.

Portowalność – Czy specyfikacje mogą żyć jako zwykły markdown w Twoim repozytorium i działać z agentem, którego preferujesz w następnym kwartale? Czy też są powiązane z jednym IDE, jedną chmurą lub jednym własnym formatem?

Tarcie przy konfiguracji – Jak długo trwa droga od „chcę spróbować SDD” do działającej pętli specyfikacja-plan-zadania? Scaffolding CLI, instalacja IDE lub tworzenie własnych poleceń slash mają różną energię aktywacji.

Jakość specyfikacji – Czy narzędzie pomaga napisać precyzyjne wymagania i kryteria akceptacji, czy też głównie generuje długie dokumenty? Struktura jest przydatna. Objętość nie.

Wykonywanie zadań – Jak narzędzie dzieli pracę na przeglądane fragmenty? Czy zadania mogą być wykonywane równolegle? Czy opiera się eksplozjom zadań z pięćdziesięciu punktami?

Kontrolki recenzji – Czy istnieją naturalne bramki ludzkie między etapami specyfikacji, planowania, zadań i implementacji? SDD bez recenzji to po prostu wolniejsze vibe coding.

Zakotwiczenie w repozytorium – Czy przepływ pracy czyta konwencje projektu, rejestry decyzji, ADR-y, AGENTS.md i istniejący kod przed planowaniem? Agenci bez zakotwiczenia ponownie wymyślają architekturę, ponieważ nigdy nie widzą zweryfikowanego zamierzenia stojącego za poprzednimi wyborami.

Współpraca zespołowa – Czy wiele osób może przeglądać te same artefakty specyfikacji w żądaniach pull? Czy można mieszać agentów bez przepisywania procesu?

Uzależnienie od dostawcy (Lock-in) – Co tracisz, jeśli zmienisz edytor, modele lub dostawcę chmury za sześć miesięcy?

GitHub Spec Kit

GitHub Spec Kit to open-source’owy zestaw narzędzi CLI, który tworzy szkielet pętli opartej na specyfikacjach w Twoim repozytorium i przekazuje wykonanie dowolnemu agentowi kodującemu, którego już używasz. CLI specify umieszcza szablony, polecenia slash i konwencjonalny układ folderów. Typowe polecenia podążają za sekwencją konstytucja-specyfikacja-klarifikacja-plan-zadania-implementacja, z jawnym krokiem klarifikacji w celu usunięcia niejednoznaczności przed rozpoczęciem prac architektonicznych.

Definiującą przewagą Spec Kit jest niezależność od agenta. Oficjalna dokumentacja pozycjonuje go jako narzędzie działające z Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex i dziesiątkami innych agentów. Piszesz specyfikacje raz w markdown, commitujesz je jak kod i wymieniasz wykonawcę bez przepisywania procesu. Dzięki temu Spec Kit jest domyślną rekomendacją dla zespołów, które chcą SDD bez stawiania wszystkiego na jednego dostawcę.

Kompromisy są realne. Spec Kit może wygenerować duże drzewo artefaktów — konstytucja, specyfikacja, plan, zadania, kontrakty — co przynosi korzyści w funkcjach wielosesyjnych, ale wydaje się ciężkie dla małych poprawek CLI. Wątki na Hacker News regularnie porównują te nakłady do ceremonii waterfall. Spec Kit jest też słabszy, jeśli chcesz w pełni zintegrowanego IDE, w którym specyfikacje, zadania i implementacja żyją na jednej prowadzonej powierzchni. Nakłada proces na istniejący edytor, zamiast go zastępować.

Spec Kit pasuje do zespołów, które już mają preferowanego asystenta kodującego AI i chcą ustandaryzowany szkielet SDD na wierzchu. Jest szczególnie silny dla funkcji greenfield, firm wieloagentowych i każdego, kto odrzuca uzależnienie od edytora.

AWS Kiro

Kiro to oparte na specyfikacjach IDE od AWS, zbudowane na forku VS Code / Code OSS. Tam, gdzie Spec Kit przynosi SDD do Twojego istniejącego stacku, Kiro zakłada, że SDD zasługuje na środowisko stworzone na zamówienie. Prompt generuje strukturalne artefakty — typowo requirements.md w notacji EARS, design.md i uporządkowane zależnościami tasks.md — zanim agenci napiszą kod produkcyjny.

Prowadzone doświadczenie to główny atut Kiro. Wymagania, projekt i zadania są obiektami UI pierwszej klasy obok Twojego kodu, a nie plikami, które zarządzasz przez osobny CLI. Kiro dostarcza również Agent Hooks, zasilane zdarzeniami automatyzacje, które mogą aktualizować testy, dokumentację lub powiązane artefakty, gdy implementacja się zmienia. Ta dwukierunkowa pętla to coś, czego Spec Kit nie oferuje z pudełka — specyfikacje Spec Kit pozostają statyczne, dopóki człowiek ich nie zaktualizuje.

Koszty to głębokość integracji w zamian za portowalność. Kiro działa wewnątrz swojego edytora, używa modeli opartych na AWS Bedrock i rozlicza się przez model cenowy oparty na kredytach z planami warstwowymi. Zespoły enterprise już na infrastrukturze AWS często uznają to za akceptowalne. Deweloperzy solo i zespoły wieloedytorowe mogą tak nie myśleć. Kiro ma też niedoskonałości typowe dla nowszego IDE — kompatybilność rozszerzeń, niespodzianki w przepływie pracy i typowe pytanie „czy naprawdę potrzebuję kolejnego edytora?”.

Kiro pasuje do deweloperów, którzy chcą najbardziej prowadzonego doświadczenia SDD i są gotowi przyjąć IDE natywne dla specyfikacji. To silna opcja dla zespołów enterprise, środowisk intensywnie korzystających z AWS i każdego, kto migruje z Amazon Q Developer i chce dyscypliny specyfikacji bez ręcznego składania łańcucha narzędzi. Jeśli dziś żyjesz w standardowym VS Code i kochasz swój obecny setup, Kiro wymaga większej zmiany niż Spec Kit.

Claude Code niestandardowe polecenia i skills

Claude Code nie dostarcza jednego oficjalnego produktu SDD w sposób, w jaki robią to Spec Kit lub Kiro. Jeśli jesteś nowy w tym narzędziu, zacznij od przewodnika po instalacji i konfiguracji Claude Code dla setupu, uprawnień i lokalnych backendów. Sam wzorzec SDD żyje w niestandardowych poleceniach, skills i lokalnych w repozytorium szablonach markdown, które utrzymują deweloperzy. Anthropic włączył starsze pliki .claude/commands/*.md w mechanizm Skills, więc trwałym wzorcem jest SKILL.md (lub równoważnik), który definiuje Twoją checklistę specyfikacja-plan-implementacja, ładowaną na żądanie.

To podejście jest najlżejsze i najbardziej podatne na modyfikacje. Możesz przenieść trójplikowy układ w stylu Kiro, odzwierciedlić fazy Spec Kit za pomocą poleceń slash, lub wymyślić minimalny przepływ pracy pasujący do jednego repozytorium. Claude Code czyta CLAUDE.md dla kontekstu projektu zawsze włączonego i pobiera skills, gdy zadanie pasuje. To stopniowe ujawnianie utrzymuje sesje skoncentrowane bez ładowania pełnej konstytucji przy każdym prompcie.

Minusem jest dyscyplina. Nic nie zmusza Cię do przejścia przez bramki klarifikacji lub recenzji, chyba że zbudujesz je sam. Wątki na Reddit i Hacker News dotyczące „rozwój oparty na specyfikacjach wewnątrz Claude Code” pełne są deweloperów, którzy skopiowali czyjś skill, uruchomili go raz i wrócili do nieskonstruowanych promptów, gdy skill wydawał się wolny. SDD w Claude Code działa, gdy traktujesz skills jak kod — wersjonowany, recenzowany i utrzymywany — a nie jak jednorazowe pobranie promptu.

Dla poważnej implementacji przeczytaj Claude Skills i SKILL.md dla deweloperów i zakoduj swoje fazy jako skills z jawnymi kontrolkami recenzji. SDD w Claude Code to właściwy wybór, gdy już żyjesz w Claude Code, chcesz maksymalnej elastyczności i będziesz samodzielnie utrzymywać przepływ pracy. W szczególności dla kroku bramki recenzji, podagenci Claude Code mogą wykonać niezależny przegląd w izolowanym kontekście wygenerowanego kodu przed połączeniem zadania — lekki odpowiednik roli weryfikacji, którą natywnie zapewniają Agent Hooks Kiro.

Superpowers: Zapakowana wersja DIY Stack Skill

Jeśli ręczne budowanie tego stosu skills brzmi dokładnie jak problem dyscypliny, o którym ostrzega tabela powyżej, Superpowers warto rozważyć. To open-source’owy pakiet skills — burza mózgów, pisanie planów, rozwój napędzany podagentami, test-driven development, żądanie recenzji kodu i kilka wspierających skills — dystrybuowany jako instalowalny plugin, a nie coś, co piszesz od zera. Celuje bezpośrednio w ograniczenie „jakość zależy całkowicie od dyscypliny autora”: skills uruchamiają się automatycznie i mają być obowiązkowym przepływem pracy, a nie opcjonalnymi sugestiami, które agent może pominąć.

Wymuszany przez nie przepływ pracy mapuje się blisko na pięciofazową pętlę omówioną w Przepływ pracy rozwoju opartego na specyfikacjach: od wymagań do kodu: burza mózgów dopracowuje surowy pomysł w recenzowany dokument projektowy, pisanie planów dzieli go na małe weryfikowalne zadania, rozwój napędzany podagentami dysponuje świeżym podagentem na zadanie z dwustopniową recenzją, a test-driven development wymusza ścisłe czerwono-zielono-refactor, zanim cokolwiek zostanie uznane za zakończone. Ta ostatnia część jest bardziej restrykcyjna niż większość skills SDD w Claude Code — Superpowers jawnie usuwa kod napisany przed istnieniem testu, który miałby go zawieść.

W przeciwieństwie do lokalnego w repozytorium skilla, który piszesz sam, Superpowers nie jest tylko dla Claude Code. Dostarcza manifesty pluginów dla Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot CLI, Devin, Factory Droid i kilku innych agentów, więc ta sama metodologia podąża za Tobą między szkieletami (harnessami), zamiast żyć w jednym folderze .claude/skills/. To czyni go środkiem między tworzeniem własnego skilla Claude Code a przyjmowaniem cięższego, specyficznego dla IDE narzędzia jak Kiro: otrzymujesz subiektywną, wymuszoną pętlę, nie rezygnując z edytora ani nie zobowiązując się do specyficznego formatu specyfikacji jednego dostawcy.

Superpowers pasuje do deweloperów, którzy cenią podejście Claude Code skills w teorii, ale ciągle wracają do nieskonstruowanych promptów, ponieważ nic nie wymusza bramek recenzji. Jest słabszym dopasowaniem, jeśli masz już specyficzny dla projektu skill SDD dostrojony do Twojego stacku — w takim przypadku wymieniasz niewielką ilość niestandardowości na większą ilość wymuszonej ceremonii.

BMAD, OpenSpec i inne przepływy pracy

Nie każdy zespół chce drzewa artefaktów Spec Kit ani IDE Kiro. Dwa alternatywy pojawiają się stale w porównaniach z 2026 roku.

OpenSpec (Fission AI) przyjmuje podejście centrowane na zmianach z mniejszą liczbą generowanych plików niż Spec Kit. Benchmarki społeczności raportują znacznie niższe zużycie tokenów dla porównywalnych zadań, kosztem mniejszej struktury wstępnej. OpenSpec wygrywa, gdy modyfikujesz istniejącą bazę kodu i chcesz przeglądane specyfikacje bez 800-wierszowej fazy planowania. Rywalizuje ze Spec Kit pod kątem portowalności, a nie z Kiro pod kątem integracji IDE.

BMAD-METHOD (społeczność) idzie w przeciwnym kierunku — wieloagentowe, oparte na rolach przepływy pracy, które symulują persony właściciela produktu, architekta, dewelopera i recenzenta. BMAD może być potężne w dużych wysiłkach greenfield, gdzie jawne oddzielenie ról pomaga. Jest też ciężkie. Zespoły często raportują, że ceremonia opłaca się tylko wtedy, gdy ból koordynacji jest już ostry.

Tessl traktuje specyfikację jako literalne źródło generowanego kodu, oznaczając wynik jako pochodny i zniechęcając do ręcznych edycji. To najsilniejsza postawa „specyfikacja jako źródło” wśród głównego nurtu narzędzi, ale Tessl pozostaje w wersji beta i niesie z sobą najwyższe uzależnienie produktowe w grupie.

Spec Kitty i inne szkielety społecznościowe znajdują się między OpenSpec a Spec Kit pod względem wagi. Są warte obserwacji, jeśli chcesz szablony, nie przyjmując pełnego łańcucha narzędzi GitHub.

Wzorzec we wszystkich z nich jest taki sam. Więcej procesu pomaga, gdy niejednoznaczność jest droga. Więcej procesu szkodzi, gdy szybkość feedbacku jest ważniejsza niż zgodność. Dopasuj wagę narzędzia do wielkości zadania, a nie do hype’u.

Który setup SDD powinieneś użyć?

Nie ma uniwersalnego zwycięzcy. Właściwy setup zależy od tego, kim jesteś, co budujesz i ile struktury będziesz faktycznie utrzymywać.

Deweloper solo, istniejąca baza kodu, małe funkcje. Zacznij od skills Claude Code lub OpenSpec. Napisz krótki blok wymagań, minimalną listę zadań i jedną kontrolkę recenzji. Nie instaluj pełnego drzewa Spec Kit dla zmiany pięćdziesięciu linii.

Chcesz podejścia skills Claude Code, ale ciągle pomijasz własne bramki recenzji. Zainstaluj Superpowers zamiast pisać custom skill od zera. Oddajesz trochę projektowego dostrojenia w zamian za wymuszony pętli burza-mózgów-plan-implementacja-recenzja, który nie zależy od Twojej dyscypliny w danym dniu.

Deweloper solo, funkcja greenfield, wiele sesji. Spec Kit lub dobrze utrzymywany skill SDD w Claude Code. Potrzebujesz trwałych artefaktów bardziej niż prowadzenia ręki przez IDE.

Mały zespół, mieszane edytory. Spec Kit. Zwykłe specyfikacje markdown w Git, recenzowane w pull requestach, wykonywane przez agenta preferowanego przez każdego dewelopera.

Zespół enterprise, AWS-native, presja zgodności (compliance). Kiro. Prowadzone artefakty, śledzalność wymagań i hooks, które utrzymują dokumentację i testy bliżej implementacji.

Środowisko regulowane. Kiro lub Spec Kit plus własna checklistą walidacji — nie same skills Claude Code, chyba że jawnie zakodujesz bramki zgodności. Narzędzia nie zastępują śladów audytowych. Tylko ułatwiają ich tworzenie.

Istniejąca baza kodu, zmiana brownfield. OpenSpec lub lekki przepływ pracy Claude Code. Pełna ceremonia Spec Kit przy każdym bugfixie będzie wyglądać jak waterfall. Zrezerwuj cięższą strukturę dla funkcji poprzecznych (cross-cutting).

Produkt greenfield, wielu agentów. Spec Kit. Portowalność jest ważniejsza niż wygładzenie IDE, gdy Copilot, Claude Code i Cursor mogą dotykać tego samego repozytorium.

Zespoły eksperymentujące z orkiestracją wielu agentów powinny również spojrzeć na Oh My OpenCode Agents dla wzorców dzielenia ról między agentami — komplementarne do artefaktów SDD, a nie ich zamiennik.

Praktyczna tabela decyzyjna

Co faktycznie determinuje sukces

Wybór narzędzia ma mniejsze znaczenie niż jakość artefaktów. Plik wymagań Kiro z niejasnymi kryteriami akceptacji wygeneruje ten sam dryf co niechlujny prompt Claude Code. Plan Spec Kit wymieniający pięćdziesiąt redundantnych zadań będzie czuł się jak waterfall, niezależnie od tego, który agent go implementuje.

Praktyki, które przenoszą się między każdym setupem, są nudne i skuteczne. Utrzymuj specyfikacje wystarczająco małe, aby przejrzeć je w jednej sesji. Pisząc jawnie cele negatywne (non-goals). Dzielić zadania na diffy, które człowiek może przeczytać. Waliduj względem kryteriów akceptacji przed połączeniem. Aktualizuj specyfikację, gdy implementacja odkryje lepszą drogę.

Jeśli nadal wybierasz między SDD a nieskonstruowanymi promptami dla danej funkcji, przeczytaj Rozwój oparty na specyfikacjach vs Vibe Coding. Porównanie narzędzi w tym artykule ma znaczenie dopiero, gdy zdecydujesz, że funkcja zasługuje na specyfikację w ogóle.

Złe specyfikacje pogarszają pracę każdego agenta. Dobre specyfikacje działają między narzędziami.

Wniosek

GitHub Spec Kit, Kiro i przepływy pracy Claude Code to trzy odpowiedzi na to samo pytanie — jak utrzymać agentów AI w zgodności przez sesje — z różnymi zakładami na portowalność versus integrację. Spec Kit optymalizuje pod kątem niezależnego od agenta markdown w Twoim repozytorium. Kiro optymalizuje pod kątem prowadzonego, natywnego dla specyfikacji IDE z agentami opartymi na AWS. Skills Claude Code optymalizują pod kątem hackable, lekkich przepływów pracy, które odnoszą sukces tylko wtedy, gdy je utrzymujesz.

Wybierz najlżejszy setup, który nadal usuwa niejednoznaczność dla funkcji w danym momencie. Dodawaj strukturę, gdy pojawia się ból koordynacji, a nie gdy artykuł blogowy każe Ci to zrobić. Deweloperzy, którzy czerpią wartość z SDD w 2026 roku, to nie ci z najbardziej skomplikowanym łańcuchem narzędzi. To ci, którzy piszą specyfikacje warte implementacji — a potem pozwalają wybranemu narzędziu działać względem nich.

Przydatne linki

• Dokumentacja GitHub Spec Kit — oficjalny referencja przepływu pracy Spec Kit
• Superpowers Quickstart: Instalacja, Przepływ pracy i Wypróbowanie — open-source’owy pakiet skills wymuszający metodologię od burzy mózgów do TDD między Claude Code, Cursor, Codex i innymi agentami
• Martin Fowler o narzędziach SDD — analiza Kiro, Spec Kit i Tessl