SpecScore vs OpenSpec

Oba umieszczają specyfikacje w plikach Markdown, tuż obok Twojego kodu, czytelne dla agentów AI. Odpowiadają jednak na inne pytania: OpenSpec organizuje specyfikacje i generuje polecenia dla agentów. SpecScore weryfikuje treść specyfikacji, egzekwuje cykl życia i śledzi powiązania kodu z wymaganiami.

Co je łączy.

Specyfikacje żyją w repozytorium jako pliki Markdown — pod kontrolą wersji, sprawdzane w pull requestach.
Oba są open source na licencji MIT.
Oba używają kryteriów akceptacji Given/When/Then.
Oba traktują agentów AI jako pierwszoklasowych odbiorców specyfikacji.

Co OpenSpec robi dobrze.

Najszersze wsparcie agentów

OpenSpec obsługuje 29 agentów AI dzięki generowanym plikom skilli — Claude, Cursor, Copilot, Gemini, Windsurf, Cline i innych. Jeśli Twój agent jest na liście, OpenSpec integruje się bez konfiguracji.

Niski próg wejścia

npm install -g @fission-ai/openspec && openspec init i od razu piszesz specyfikacje. Brak schematu do nauki, brak wymaganego frontmattera. Zaprojektowany z myślą o prostocie — szczególnie dla istniejących projektów.

Przejrzysty model różnicowy (delta)

Format ADDED / MODIFIED / REMOVED w OpenSpec służący do ewolucji specyfikacji jest świetnie przemyślany. Każda zmiana to katalog z propozycją, specyfikacjami delta i zadaniami — ustrukturyzowany sposób proponowania modyfikacji.

Porównanie możliwości.

Możliwość	OpenSpec	SpecScore
Format specyfikacji	Markdown (bez frontmattera)	Markdown + YAML frontmatter
Linting specyfikacji	Tylko struktura plików	Jakość treści — nieprecyzyjne czasowniki, brakujące AC, wiszące referencje
ID wymagań	Brak (odwołania po tytule)	Oparte na slugach (`REQ: slug-format`)
ID kryteriów akceptacji	Brak	Adresowalne maszynowo ID
Status cyklu życia	Domniemany (lokalizacja pliku)	Egzekwowany — Draft → Under Review → Approved → Implementing → Stable → Deprecated
Śledzenie kod-do-specyfikacji	Brak	Adnotacje `specscore:` + trailery `Verifies:` w commitach
Podfunkcje (sub-features)	Nie	Tak (zagnieżdżone katalogi)
Odsyłacze krzyżowe	Brak formalnego mechanizmu	Zależności, Pomysły źródłowe, odwołania do planów
Integracja CI	Podstawowa (`openspec validate`)	`specscore lint` z konfigurowalną wagą błędów, hooki pre-commit
Wsparcie agentów	29 agentów	Claude Code jako główny + CLI dla każdego agenta
Dostosowywanie schematu	Tak (`schema.yaml`, fork/init)	Stały schemat (spójność z założenia)
Propozycje zmian	Model delta (ADDED/MODIFIED/REMOVED)	Pomysły zmian + propozycje
Zależność runtime	Node.js 20.19+	Brak — pojedynczy plik binarny w Go
Licencja	MIT	MIT

Gdzie SpecScore idzie dalej.

Walidacja wykracza poza strukturę plików

Polecenie validate w OpenSpec sprawdza strukturę plików — czy plik istnieje, czy ma odpowiednie sekcje. SpecScore weryfikuje znacznie głębiej, na dwóch poziomach:lint sprawdza deterministycznie relacje w treści — czy każde wymaganie ma kryteria akceptacji, czy referencje się rozwiązują, czy przejścia stanów są poprawne — a recenzent AI (/review, /score) wychwytuje to, czego żaden linter nie potrafi: wieloznaczne kryteria i nieprecyzyjne czasowniki.

$ specscore lint checkout/apply-discount.md
  ✗ R3  no acceptance criteria
  ✗ link  "Related Feature: discount-tiers" not found

Każde wymaganie ma identyfikator czytelny dla maszyn

OpenSpec odwołuje się do wymagań po tytule — co jest podatne na błędy przy zmianie nazwy. SpecScore przypisuje ID oparte na slugach (REQ: slug-format) oraz identyfikatory AC, które przetrwają zmiany nazw, refaktoryzację i przekazywanie zadań między agentami.

Cykl życia jest egzekwowany, a nie domyślny

W OpenSpec cykl życia specyfikacji to jej lokalizacja na dysku: specs/ (bieżąca),changes/ (proponowana), archive/ (ukończona). W SpecScore cykl życia jest egzekwowanym polem statusu — Draft → Under Review → Approved → Implementing → Stable → Deprecated — weryfikowanym przez linter, zmienianym przez specscore change-status z poziomu git hooks lub CI.

Kod odsyła bezpośrednio do specyfikacji

OpenSpec nie ma mechanizmu śledzenia. SpecScore posiada adnotacje specscore:w komentarzach w kodzie oraz trailery Verifies: w commitach. Uruchomspecscore code refs i uzyskaj deterministyczną odpowiedź na pytanie „jaki kod implementuje to wymaganie?”.

Brak zależności od środowiska wykonawczego

OpenSpec wymaga Node.js 20.19+. SpecScore to pojedynczy plik binarny w Go — brak runtime'u, brak node_modules. Działa w projektach Go, Rust, Python, Java bez dorzucania Node do toolchaina.

Komponowalna hierarchia artefaktów

Specyfikacje w OpenSpec są płaskie wg domen. SpecScore posiada typowaną hierarchię: Pomysły (Ideas) są promowane do Funkcji (Features), Features zawierają wymagania i kryteria akceptacji (ACs), Plany odwołują się do ACs, a Zadania (Tasks) odwołują się do Planów. Wszystkie powiązania są w pełni nawigowalne maszynowo przez CLI.

Kiedy wybrać które rozwiązanie.

Zacznij od OpenSpec, gdy…

Używasz Cursora, Copilota lub innych agentów poza Claude i potrzebujesz integracji prosto z pudełka.
Dodajesz specyfikacje do istniejącej bazy kodu po raz pierwszy i zależy Ci na zerowym tarciu.
Twój zespół przedkłada elastyczność schematu nad ścisłe egzekwowanie reguł.

Wybierz SpecScore, gdy…

Potrzebujesz kontroli jakości specyfikacji — linter wychwytuje niejednoznaczności, zanim agenci zmarnują na nie tokeny.
Potrzebujesz śledzenia kod-do-specyfikacji — pytanie „jaki kod implementuje to wymaganie?” ma zawsze deterministyczną odpowiedź.
Budujesz duży system z wieloma funkcjami, podfunkcjami i przejściami cyklu życia.
Zależy Ci na braku zależności runtime — jeden plik binarny, bez konieczności instalowania Node.js.
Potrzebujesz bramek jakości specyfikacji w CI — specscore lint kończy się niezerowym kodem wyjścia przy błędach, zupełnie jak ESLint czy go vet.

Nie wykluczają się wzajemnie.

SpecScore potrafi lintować pliki spec.md z OpenSpec. Zespoły zaczynające od OpenSpec mogą dodać warstwę jakości SpecScore bez konieczności migracji — weryfikuj specyfikacje, które już masz, dodaj identyfikowalność, gdy jej potrzebujesz, i wdrażaj cykl życia w miarę rozwoju zespołu.

OpenSpec to świetny punkt wejścia. SpecScore to solidne barierki ochronne.

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.