SpecScore vs Kiro

Rozwój sterowany specyfikacją (SDD) oznacza zapisanie, co oprogramowanie ma robić, zanim agent AI napisze kod. Kiro, od Amazon Web Services (AWS), to agentowe środowisko programistyczne — edytor, interfejs wiersza poleceń (CLI) i aplikacja webowa — które zamienia prompt w specyfikacje Kiro: wymagania, projekt i zadania. Te wymagania używają EARS (łatwe podejście do składni wymagań), czyli zdania w kształcie „WHEN coś się dzieje, THE SYSTEM SHALL coś zrobić”. SpecScore to otwartoźródłowy format samej specyfikacji oraz CLI, który sprawdza pliki. Ciągła integracja (CI) — automatyczne sprawdzenie każdej proponowanej zmiany — może odrzucić specyfikację SpecScore, która łamie format.

Ostatnia aktualizacja: 30 października 2026

Co je łączy.

Oba traktują spisaną specyfikację jako to, z czego agent ma budować, a nie jako zapis czatu.
Oba trzymają tę specyfikację jako Markdown w projekcie, więc można ją przeglądać jak kod.
Oba dzielą pracę na wymagania, projekt i zadania. Kiro generuje te trzy pliki. SpecScore to format, który zespół może zachować po zakończeniu sesji.

Co Kiro robi dobrze.

Własna dokumentacja Kiro, odczytana 30 października 2026, opisuje produkt. Strona specyfikacji funkcji była oznaczona jako zaktualizowana 4 sierpnia 2026.

Wymagania w ustalonym kształcie zdania

Specyfikacje Kiro umieszczają zachowanie w requirements.md według jednego wzorca EARS: WHEN zachodzi warunek, THE SYSTEM SHALL zrobić rzecz. Dokumentacja podaje przykład formularza z nieprawidłowymi danymi i systemu, który pokazuje błąd walidacji obok pola. Taki kształt łatwiej testować niż ogólnikowy akapit.

Pełna ścieżka od promptu do zadań

Specyfikacja funkcji przechodzi przez wymagania, projekt (design.md) i zadania (tasks.md). Można zacząć od wymagań albo od projektu. Quick Spec uruchamia wszystkie trzy bez zatrzymania na zatwierdzenie między nimi. Specyfikacje Bugfix to osobna ścieżka. Dokumentacja opisuje też uruchamianie niezależnych zadań równolegle, falami, według grafu zależności w tasks.md.

Sprawdzenia wewnątrz produktu

Analyze Requirements, dostępne w IDE i w CLI, szuka niespójności, niejednoznaczności, sprzecznych ograniczeń i luk, zanim powstanie projekt. Correctness — testy oparte na właściwościach, wyprowadzone z tych linii EARS — jest wymienione tylko dla IDE, nie dla CLI, web ani mobile, w tabeli możliwości specyfikacji.

Porównanie możliwości.

Kiro to produkt, który szkicuje specyfikacje. SpecScore to format, który repozytorium może sprawdzić. Tabela porównuje te role.

Możliwość	Kiro	SpecScore
Rola główna	Agentowe IDE, CLI i aplikacja webowa, które szkicują specyfikacje i realizują zadania	Otwarty format specyfikacji + CLI
Pliki specyfikacji	`requirements.md` (albo `bugfix.md`), `design.md`, `tasks.md`	Drzewo spec/ z Markdown i YAML
Składnia wymagań	Wzorzec EARS: WHEN … THE SYSTEM SHALL …	Identyfikatory wymagań (`REQ: slug`) oraz kryteria akceptacji Given/When/Then
Sprawdzanie specyfikacji	Analyze Requirements w IDE i w CLI. Testy oparte na właściwościach w IDE. Nieopisane jako linter formatu dla własnego CI.	specscore spec lint w CI. `/score` to osobna, ręczna ocena AI.
Gdzie działa	Kiro IDE, Kiro CLI, Kiro web. Część sprawdzeń jest tylko w IDE.	Dowolne repozytorium — jeden plik binarny Go, bez konta Kiro
Licencja	Licencja Kiro mówi, że IDE i CLI są treścią AWS (AWS Content) na mocy umowy klienta AWS (AWS Customer Agreement). Kiro Crew to osobne publiczne repozytorium.	CC BY 4.0 format · Apache-2.0 CLI
Cena	Darmowy poziom i plany płatne. Liczby się zmieniają — zobacz cennik Kiro, odczytany 30 października 2026.	Bez opłaty za format ani za CLI

Co dodaje SpecScore.

Format sam pada w CI

Analiza Kiro działa wewnątrz Kiro. Sprawdzenie SpecScore to polecenie. Workflow dogfood tego repozytorium uruchamia specscore spec lint przy każdym pull requeście i na main. Zepsuta specyfikacja oblewa zadanie tak, jak oblałby je zepsuty test. Skill /score ocenia sformułowania recenzentami AI; to przejście jest ręczne i powyższy workflow go nie uruchamia.

$ specscore spec lint

features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found
features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds
features/apply-discount/refunds:0 [error] readme-exists: README.md not found

3 violations found (3 errors)

Specyfikacja nie jest przywiązana do jednego IDE

Specyfikacje Kiro są w Markdown, więc można je czytać bez produktu. Workflow, który je tworzy i wykonuje, należy do Kiro. Drzewo SpecScore to te same pliki dla Claude Code, Cursor, Copilot albo w ogóle bez agenta — CLI nie wywołuje modelu, żeby lintować.

Wymagania zachowują identyfikator

Dokumentacja Kiro opisuje identyfikowalność jako śledzenie wymagania przez implementację. Nie opisuje stabilnego identyfikatora, który przetrwa przeredagowanie. SpecScore adresuje wymaganie jako REQ: slug, a kryterium akceptacji — jego własnym identyfikatorem.

EARS i Given/When/Then odpowiadają na różne pytania

EARS, tak jak dokumentuje to Kiro, to jedno zdanie o zachowaniu systemu. Kryteria akceptacji SpecScore to scenariusze Given/When/Then powiązane z identyfikatorem wymagania. Linię EARS można zapisać w prozie i nadal trzymać scenariusz w pliku SpecScore, który sprawdza linter. Wzorce zdań są w składni wymagań EARS.

Kiedy wybrać które rozwiązanie.

Sięgnij po Kiro, gdy…

Chcesz agentowego IDE od AWS, które z promptu szkicuje wymagania, projekt i zadania, a potem te zadania realizuje.
Chcesz zdań EARS oraz, w IDE, testów opartych na właściwościach wygenerowanych z tych zdań.
Twój zespół już standaryzuje się na edytorze, CLI albo aplikacji webowej Kiro.

Wybierz SpecScore, gdy…

Specyfikacja ma zostawać poprawna w CI po zakończeniu sesji agenta, w repozytorium, które nie wymaga Kiro.
Potrzebujesz identyfikatorów wymagań, statusu cyklu życia i deterministycznego wyniku lintu.
Chcesz, żeby format był otwartoźródłowy, a sprawdzanie — jednym plikiem binarnym.

Kiro może szkicować. SpecScore może postawić bramkę.

Nic tutaj nie zastępuje edytora Kiro. Jeśli zespół pisze prompty w Kiro, niech Kiro szkicuje. Jeśli specyfikacja ma przetrwać jako przejrzany plik, zapisz ten kontrakt w SpecScore i pozwól, by specscore spec lint oblał pull request, gdy struktura się złamie. Te dwa pliki mogą leżeć w tym samym repozytorium.

Wybierz Kiro na sesję. Wybierz SpecScore na artefakt, który zadanie CI może odrzucić.

Źródła.

Publiczne strony poniżej odczytano 30 października 2026. Ceny, nazwy planów i linie wydań się zmieniają.

Inne porównania.

Ten sam format, obok innych narzędzi rozwoju sterowanego specyfikacją:

Wszystkie razem, na jednej stronie: najlepsze narzędzia rozwoju sterowanego specyfikacją w 2026.

To porównanie opiera się na publicznie dostępnej dokumentacji i kodzie źródłowym. Coś jest błędne lub nieaktualne? otwórz issue z poprawką. Chcesz, żebyśmy porównali SpecScore z innym narzędziem? poproś o nie.