# Najlepsze narzędzia rozwoju sterowanego specyfikacją w 2026

Canonical: https://specscore.md/pl/spec-driven-development/tools/

SpecScore to otwarty, sprawdzany linterem format plików dla specyfikacji, zapisany w Markdown i YAML (YAML Ain't Markup Language). [Rozwój sterowany specyfikacją](https://specscore.md/pl/spec-driven-development/) (SDD) to praktyka, w której spisana specyfikacja jest źródłem prawdy, według którego buduje się kod i względem którego się go sprawdza. Narzędzia rozwoju sterowanego specyfikacją to formaty, przepływy pracy i produkty używane do pisania, przechowywania i czasem sprawdzania tych specyfikacji. Dokument wymagań produktu (PRD) to proza, która określa problem i zakres, zanim ktokolwiek podzieli ją na zadania. [Łatwe podejście do składni wymagań](https://kiro.dev/docs/specs/feature-specs/) (EARS) to zdanie wymagania w postaci „WHEN coś się dzieje, THE SYSTEM SHALL coś zrobić”. [Interfejs wiersza poleceń](https://specscore.md/pl/cli/) (CLI) to program, który uruchamiasz w terminalu. [Ciągła integracja](https://specscore.md/pl/validators/) (CI) to automatyczne sprawdzenie każdej proponowanej zmiany.

To porównanie narzędzi rozwoju sterowanego specyfikacją obejmuje [GitHub Spec Kit](https://github.com/github/spec-kit), [OpenSpec](https://github.com/Fission-AI/OpenSpec), [Kiro](https://kiro.dev/), [Tessl](https://docs.tessl.io/), [BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD), [Task Master AI](https://github.com/eyaltoledano/claude-task-master), [CodeSpeak](https://codespeak.dev/), [Datarim](https://github.com/Arcanada-one/datarim), zwykły Markdown i [SpecScore](https://specscore.md/pl/). Strony publiczne i repozytoria odczytano 30 października 2026. Polecenia, układ plików i to, co produkt sprawdza, mogą się zmienić; źródła na dole podają stronę, z której pochodzi każde twierdzenie.

Dla repozytorium liczy się to, czy specyfikacja może samodzielnie nie przejść CI. W repozytorium strony SpecScore [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) instaluje CLI SpecScore i uruchamia `specscore spec lint` przy pull requestach i przy pushach na main. Skill [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) w specstudio-skills to ręczna ocena AI artefaktu. Wywołujesz go ty. Ten przepływ pracy tego nie robi.

## Narzędzia rozwoju sterowanego specyfikacją, obok siebie.

Każdy wiersz to rola, a nie punktacja. Nazwa prowadzi do porównania SpecScore, a nagłówek poniżej — do źródła danej komórki.

| Narzędzie | Czym jest | Jak specyfikacje są pisane i przechowywane | Automatyczna walidacja specyfikacji | Licencja | Dla kogo |
| --- | --- | --- | --- | --- | --- |
| [GitHub Spec Kit](https://specscore.md/pl/vs/spec-kit/) | Przepływ pracy agenta, który tworzy artefakty Markdown | Katalog funkcji pod `specs/`: `spec.md`, `plan.md`, `tasks.md` | `/speckit.analyze` zgłasza luki między artefaktami w sesji agenta. Rozszerzenia społeczności mogą dodać bramki. | [MIT](https://github.com/github/spec-kit/blob/main/LICENSE) w [github/spec-kit](https://github.com/github/spec-kit) | Zespół, który chce jednego wspólnego procesu dla agenta |
| [OpenSpec](https://specscore.md/pl/vs/openspec/) | Foldery zmian i polecenia agenta, żeby uzgodnić treść przed kodem | Zwykły Markdown pod `openspec/changes/`: proposal, specs, design, tasks | `openspec validate` sprawdza strukturę zmiany i specyfikacji i może zakończyć się kodem innym niż zero, także ze skryptu CI. | [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE) w [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) | Zespół, który chce lekkiego folderu zmiany i sprawdzenia struktury |
| [Kiro](https://specscore.md/pl/vs/kiro/) | Agentowe IDE, CLI i aplikacja webowa AWS, które szkicują specyfikacje | `requirements.md` w EARS oraz `design.md` i `tasks.md` | Analyze Requirements wewnątrz Kiro, przed projektowaniem. Strona specyfikacji funkcji opisuje to sprawdzenie w produkcie. | IDE i CLI są treścią AWS (AWS Content) na mocy [licencji Kiro](https://kiro.dev/license/) (AWS Customer Agreement). | Ktoś, kto chce, żeby Kiro szkicowało wymagania, design i zadania |
| [Tessl](https://specscore.md/pl/vs/tessl/) | Platforma skilli dla agentów oraz tile rozwoju sterowanego specyfikacją | Skille jako pliki w repozytorium. Tile zapisuje `.spec.md` pod `specs/`. | Tile dostarcza `scripts/validate-specs.sh` i `scripts/check-spec-links.sh`. Jego GitHub Actions lintują sam tile. | Tile jest na [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE) w [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile). Platforma jest produktem Tessl. | Zespół, który ujednolica skille agentów albo używa reguł tile’a „najpierw specyfikacja” |
| [BMAD Method](https://specscore.md/pl/vs/bmad-method/) | Zwinna metoda rozwoju sterowanego przez AI | Briefy, specyfikacje i architektura, które można przenieść do innego przepływu pracy | README opisuje artefakty metody i przepływy pracy agentów. Nie dokumentuje lintera formatu dla CI. | [MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE) w [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD), z informacją o znaku towarowym w tym pliku. | Zespół, który chce zwinnej metody agentowej dopasowanej do skali zmiany |
| [Task Master AI](https://specscore.md/pl/vs/task-master-ai/) | Lista zadań dla agentów kodujących, rozbierana z PRD | Proza PRD, często `.taskmaster/docs/prd.txt`, a potem wygenerowane zadania | README opisuje rozbiór PRD na zadania. Nie opisuje lintera dla PRD. | [MIT z Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE) w [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master) | Zespół, który ma już PRD i chce je podzielić na zadania |
| [CodeSpeak](https://specscore.md/pl/vs/codespeak/) | Agentowy zestaw narzędzi, który zamienia intencję z czatu w wymagania powiązane z kodem | Ustrukturyzowane wymagania wewnątrz produktu, powiązane z kodem | Strona mówi, że wymagania są egzekwowane przy każdej zmianie, wewnątrz produktu. | [Regulamin](https://codespeak.dev/terms-of-service) (obowiązuje od 3 marca 2026): CodeSpeak Ltd zachowuje Usługę, w tym jej kod źródłowy. Strona produktu nie publikuje repozytorium źródłowego zestawu narzędzi. | Zespół, który chce zbierać intencję z czatów i trzymać ją powiązaną z kodem |
| [Datarim](https://specscore.md/pl/vs/datarim/) | Iteracyjny przepływ pracy dla Claude Code, Codex CLI, Cursor i Antigravity | `/dr-prd` zapisuje PRD. Aktywne zadania leżą w `backlog.md`. | `/dr-compliance` i `/dr-dream lint` działają, gdy wywołasz te polecenia. | [MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE) w [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim) | Zespół, który chce poleceń etapami i backlogu w repozytorium |
| [Plain Markdown](https://specscore.md/pl/vs/plain-markdown/) | Zwyczajny plik Markdown, który piszesz i commitujesz | Dowolny plik `.md`, w katalogu, który wybierzesz | Taki przegląd, jaki zrobisz czytając, dopóki nie dodasz sprawdzacza | Nie ma produktu ani pliku licencji. Warunki pliku są warunkami repozytorium. | Krótka notatka, spike albo przegląd, który zrobisz czytając |
| [SpecScore](https://specscore.md/pl/) | Otwarty format specyfikacji oraz CLI, które lintuje pliki | Markdown + YAML w drzewie `spec/` | [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) uruchamia `specscore spec lint` przy pull requestach i pushach na main. [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) to ręczna ocena AI, a ten przepływ pracy jej nie uruchamia. | [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) dla formatu w [specscore/specscore](https://github.com/specscore/specscore). [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) dla CLI w [specscore/specscore-cli](https://github.com/specscore/specscore-cli). | Zespół, który potrzebuje, żeby plik specyfikacji nie przeszedł CI, gdy format się psuje |

## GitHub Spec Kit

[GitHub Spec Kit](https://github.github.io/spec-kit/) to otwarty zestaw narzędzi, który daje agentowi kodującemu proces: Specify, Plan, Tasks, Implement i Converge. Strona główna dokumentacji Spec Kit, z datą 28 września 2026, mówi, że każda faza tworzy artefakt Markdown, który czyta następna faza.

Te pliki leżą w katalogu funkcji pod `specs/`. [Przewodnik aktualizacji](https://github.github.io/spec-kit/upgrade.html), odczytany 30 października 2026, podaje ścieżki takie jak `specs/001-my-feature/spec.md`, a obok `plan.md` i `tasks.md`. [Referencja agentowego SDD](https://github.github.io/spec-kit/reference/agentic-sdd.html) opisuje `/speckit.analyze` jako raport niespójności między specyfikacją, planem i zadaniami, bez edycji plików. `/speckit.clarify` i `/speckit.checklist` to kolejne polecenia, które uruchamiasz w agencie. Strona główna dokumentacji wymienia też rozszerzenia społeczności, w tym jedno o nazwie CI Guard, które dodają bramki zgodności.

Licencja to [MIT](https://github.com/github/spec-kit/blob/main/LICENSE), w publicznym repozytorium [github/spec-kit](https://github.com/github/spec-kit). Spec Kit pasuje zespołowi, który chce tego procesu i godzi się zostawić specyfikację jako Markdown napisany przez agenta. Zestawienie ze SpecScore jest na [SpecScore vs Spec Kit](https://specscore.md/pl/vs/spec-kit/).

## OpenSpec

[OpenSpec](https://github.com/Fission-AI/OpenSpec), od Fission-AI, trzyma każdą zmianę we własnym folderze, żeby człowiek i agent mogli się zgodzić, zanim powstanie kod. [README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md), odczytany 30 października 2026, pokazuje `openspec/changes/add-dark-mode/` z `proposal.md`, katalogiem `specs/`, `design.md` i `tasks.md`. Wymagania to zwykły Markdown: zdanie SHALL oraz scenariusz WHEN / THEN. Ten sam README mówi, że obsługuje 30+ asystentów AI.

`openspec validate` sprawdza zmiany i specyfikacje pod kątem problemów strukturalnych. [Dokumentacja CLI](https://openspec.dev/docs/cli), odczytana 30 października 2026, opisuje kod wyjścia inny niż zero, gdy walidacja się nie powiedzie, oraz fragment powłoki, który może uruchomić zadanie CI. To sprawdzenie dotyczy struktury zmian i specyfikacji OpenSpec.

Licencja to [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE), w [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec). OpenSpec pasuje zespołowi, który chce folderu zmiany i tego sprawdzenia struktury. Zobacz [SpecScore vs OpenSpec](https://specscore.md/pl/vs/openspec/).

## Kiro

[Kiro](https://kiro.dev/), od Amazon Web Services (AWS), to agentowe środowisko programistyczne: edytor, CLI i aplikacja webowa. [Strona specyfikacji funkcji](https://kiro.dev/docs/specs/feature-specs/), zaktualizowana 4 sierpnia 2026, prowadzi funkcję przez wymagania, design i zadania. `requirements.md` używa EARS. `design.md` i `tasks.md` leżą obok. Quick Spec może wykonać wszystkie trzy bez zatrzymania na akceptację między nimi.

Analyze Requirements szuka niespójności, niejednoznaczności, sprzecznych ograniczeń i luk przed projektowaniem. Ta analiza działa wewnątrz Kiro. Strona specyfikacji funkcji opisuje sprawdzenie w produkcie.

[Licencja Kiro](https://kiro.dev/license/), odczytana 30 października 2026, mówi, że IDE i CLI są licencjonowane jako treść AWS (AWS Content) na mocy umowy klienta AWS (AWS Customer Agreement) lub innej pisemnej umowy oraz AWS Intellectual Property License. Kiro pasuje komuś, kto chce, żeby ten produkt szkicował te trzy pliki. Zobacz [SpecScore vs Kiro](https://specscore.md/pl/vs/kiro/). Wzorce zdań są w [składni wymagań EARS](https://specscore.md/pl/articles/ears-requirements/).

## Tessl

[Dokumentacja Tessl](https://docs.tessl.io/), odczytana 30 października 2026, opisuje otwartą platformę do zarządzania skillami agentów: rejestr, nadzór, ewaluacje i powiązane mechanizmy kontroli. Skille, reguły i dokumenty to pliki w repozytorium.

Osobny artefakt, tile rozwoju sterowanego specyfikacją, jest publikowany z [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile) i wymieniony w [rejestrze Tessl](https://tessl.io/registry/tessl-labs/spec-driven-development). README tile’a mówi, że agent zapisuje pliki `.spec.md` w katalogu `specs/`, z frontmatter YAML, `targets` i linkami `[@test]`. Dokumentuje `scripts/validate-specs.sh` i `scripts/check-spec-links.sh` oraz GitHub Actions, które lintują sam tile.

Licencja tile’a to [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE), w tamtym repozytorium. Dokumentacja opisuje platformę rejestru jako produkt Tessl i nie wskazuje publicznego repozytorium całej platformy. Tessl pasuje zespołowi, który ujednolica skille, albo zespołowi, który chce sterowania tile’a „najpierw specyfikacja, potem kod”. Zobacz [SpecScore vs Tessl](https://specscore.md/pl/vs/tessl/).

## BMAD Method

README repozytorium [BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD), odczytane 30 października 2026, opisuje zwinną metodę rozwoju sterowanego przez AI. Mówi, że metody można użyć od początku do końca albo przenieść jej briefy, specyfikacje i architekturę do przepływu pracy, który już masz. Wymieniona tam stabilna linia to v6.12. v7 jest opisane jako podgląd na gałęzi main. Projekt zapisuje nazwę jako BMad; repozytorium nazywa się BMAD-METHOD.

README skupia się na tych artefaktach planowania i na skillach agentów, które je tworzą. Nie dokumentuje polecenia, które lintuje stały schemat specyfikacji w CI.

Licencja to [MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE), w [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD). Ten plik licencji zawiera też informację o znaku towarowym BMad. Metoda pasuje zespołowi, który chce zwinnej pętli i zostawi specyfikację w tych briefach i specyfikacjach. Zobacz [SpecScore vs the BMAD Method](https://specscore.md/pl/vs/bmad-method/).

## Task Master AI

[Task Master AI](https://github.com/eyaltoledano/claude-task-master) to lista zadań dla agentów kodujących AI. README, odczytane 30 października 2026, zaleca PRD, często pod `.taskmaster/docs/prd.txt`, oraz `task-master parse-prd`, żeby zamienić tę prozę w zadania. [Dokumentacja](https://tryhamster.com/docs/taskmaster) opisuje strukturę zadań, zależności i tagi.

README traktuje PRD jako wejście, a listę zadań jako to, z czego pracuje agent. Nie opisuje lintera sformułowań ani struktury PRD.

Licencja to [MIT z Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE), w [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master). README mówi, że można budować produkty z Task Master oraz że sprzedaż samego Task Master albo oferowanie go jako usługi hostowanej jest poza tym udzieleniem. Pasuje zespołowi, który chce podzielić PRD na zadania. Zobacz [SpecScore vs Task Master AI](https://specscore.md/pl/vs/task-master-ai/).

## CodeSpeak

Strona [CodeSpeak](https://codespeak.dev/), odczytana 30 października 2026, opisuje agentowy zestaw narzędzi inżynierskich. Zbiera intencję z czatów agentów, zamienia ją w ustrukturyzowane wymagania powiązane z kodem i mówi, że egzekwuje te wymagania przy każdej zmianie. Strona mówi też, że narzędzie webowe odzyskuje intencję z czatów, dopóki nie wystartuje pełny produkt.

[Regulamin](https://codespeak.dev/terms-of-service), obowiązujący od 3 marca 2026, stwierdza, że CodeSpeak Ltd zachowuje Usługę, w tym jej oprogramowanie i kod źródłowy. Strona produktu nie publikuje repozytorium źródłowego tego zestawu narzędzi, więc ta strona nie podaje dla niego licencji oprogramowania.

CodeSpeak pasuje zespołowi, który chce wymagania zebrane z rozmowy i trzymane w powiązaniu z kodem wewnątrz tego produktu. Zobacz [SpecScore vs CodeSpeak](https://specscore.md/pl/vs/codespeak/).

## Datarim

README [Datarim](https://github.com/Arcanada-one/datarim), z odznaką wersji 4.9.0, odczytane 30 października 2026, opisuje iteracyjny przepływ pracy dla Claude Code, Codex CLI, Cursor i Google Antigravity. `/dr-prd` generuje PRD. Aktywne zadania leżą w `backlog.md`, a ukończona historia w `backlog-archive.md`.

`/dr-compliance` sprawdza implementację względem PRD, gdy uruchomisz to polecenie. `/dr-dream lint` bada kondycję bazy wiedzy pod kątem sprzeczności, osieroconych elementów, zepsutych linków, nieaktualnej treści i duplikatów. To polecenia w przepływie pracy.

Licencja to [MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE), w [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim). Datarim pasuje zespołowi, który chce tych poleceń etapami na agentach wymienionych w README. Zobacz [SpecScore vs Datarim](https://specscore.md/pl/vs/datarim/).

## Plain Markdown

Zwykły Markdown to specyfikacja jako zwyczajny plik `.md`: nagłówek, kilka punktów, tam, gdzie go commitujesz. Nie ma schematu. Przegląd to ktoś, kto czyta plik, dopóki nie dodasz własnego sprawdzacza.

Nie ma produktu ani pliku licencji, do którego można podać link. Warunki pliku są takie, jaką licencję nadasz repozytorium. Zwykły Markdown pasuje do krótkiej notatki, spike’a albo zespołu, który przejrzy prozę, czytając ją. Zobacz [SpecScore vs plain Markdown](https://specscore.md/pl/vs/plain-markdown/).

## SpecScore

[SpecScore](https://specscore.md/pl/) to format specyfikacji — funkcje, wymagania i kryteria akceptacji jako Markdown z YAML — oraz CLI, które sprawdza pliki. Format jest w [specscore/specscore](https://github.com/specscore/specscore). CLI jest w [specscore/specscore-cli](https://github.com/specscore/specscore-cli).

Jak pisać kryteria, żeby agent mógł je sprawdzić, opisuje [jak pisać kryteria akceptacji](https://specscore.md/pl/articles/acceptance-criteria/).

Szablon specyfikacji funkcji w Markdown — wymagania, kryteria akceptacji, plan i zadania — jest w [szablonie PRD w Markdown](https://specscore.md/pl/articles/feature-spec-template/).

Rozwój sterowany specyfikacją z Claude Code i Cursorem — plik funkcji, plik instrukcji agenta i `specscore spec lint` w pętli opisuje [rozwój sterowany specyfikacją z Claude Code i Cursorem](https://specscore.md/pl/articles/claude-code-specs/).

Jak uruchomić ten linter w ciągłej integracji, opisuje [lintowanie specyfikacji w CI](https://specscore.md/pl/articles/lint-specs-in-ci/).

W repozytorium tej strony [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) instaluje to CLI i uruchamia `specscore spec lint` przy pull requestach i przy pushach na main. Specyfikacja, która łamie format, nie przechodzi tego zadania. Skill [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) to ręczna ocena AI: ponownie uruchamia skonfigurowanych recenzentów, gdy o to poprosisz, a przepływ pracy dogfood go nie wywołuje.

Licencja formatu to [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE), w [specscore/specscore](https://github.com/specscore/specscore). Licencja CLI to [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE), w [specscore/specscore-cli](https://github.com/specscore/specscore-cli). SpecScore pasuje zespołowi, który potrzebuje, żeby specyfikacja nie przeszła CI, gdy nagłówek, link albo status jest błędny, niezależnie od tego, który agent napisał plik. `openspec validate` to najbliższe sprawdzenie strukturalne wśród pozostałych narzędzi na tej stronie; sprawdza własny kształt zmiany OpenSpec. Poszczególne porównania zaczynają się od [/vs/](https://specscore.md/pl/vs/).

## Jak wybrać.

Wybierz GitHub Spec Kit, OpenSpec, BMAD Method albo Datarim, gdy chcesz prowadzony proces i Markdown, który da się przejrzeć w pull requeście. Wybierz Kiro, gdy chcesz, żeby ten produkt szkicował wymagania EARS. Wybierz Task Master AI, gdy PRD ma stać się listą zadań. Wybierz CodeSpeak, gdy intencja ma być zbierana z czatów wewnątrz tego produktu. Wybierz Tessl, gdy problemem są skille agentów, a tile specyfikacji jest opcjonalnym sterowaniem.

Wybierz SpecScore, gdy sam plik specyfikacji ma nie przejść CI. Sprawdzenie w tym repozytorium to `specscore spec lint` w [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml). Przepływ pracy z listy powyżej wciąż może być sposobem, w jaki specyfikacja powstaje.

## Źródła.

Odczyt 30 października 2026, z wyjątkiem miejsc, gdzie strona podaje własną datę aktualizacji. Ceny i nazwy planów pominięto, bo się zmieniają.

- [Dokumentacja GitHub Spec Kit (strona z datą 28 września 2026)](https://github.github.io/spec-kit/)
- [Spec Kit — referencja agentowego SDD](https://github.github.io/spec-kit/reference/agentic-sdd.html)
- [Spec Kit — przewodnik aktualizacji (ścieżki specs/)](https://github.github.io/spec-kit/upgrade.html)
- [github/spec-kit — licencja MIT](https://github.com/github/spec-kit/blob/main/LICENSE)
- [Fission-AI/OpenSpec — README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md)
- [Dokumentacja CLI OpenSpec — openspec validate](https://openspec.dev/docs/cli)
- [Fission-AI/OpenSpec — licencja MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE)
- [Dokumentacja Kiro — specyfikacje funkcji i EARS (zaktualizowano 4 sierpnia 2026)](https://kiro.dev/docs/specs/feature-specs/)
- [Kiro — licencja](https://kiro.dev/license/)
- [Dokumentacja Tessl — czym jest Tessl?](https://docs.tessl.io/)
- [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile)
- [Tile rozwoju sterowanego specyfikacją Tessl — licencja MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE)
- [bmad-code-org/BMAD-METHOD — README](https://github.com/bmad-code-org/BMAD-METHOD)
- [BMAD-METHOD — licencja MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE)
- [eyaltoledano/claude-task-master — README](https://github.com/eyaltoledano/claude-task-master)
- [Task Master — MIT z Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE)
- [CodeSpeak](https://codespeak.dev/)
- [CodeSpeak — regulamin (obowiązuje od 3 marca 2026)](https://codespeak.dev/terms-of-service)
- [Arcanada-one/datarim — README (odznaka 4.9.0)](https://github.com/Arcanada-one/datarim)
- [Datarim — licencja MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE)
- [specscore/specscore — dogfood.yml (specscore spec lint)](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml)
- [specstudio-skills — skill /score (ręczna ocena AI)](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md)
- [specscore/specscore — CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE)
- [specscore/specscore-cli — Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE)