SpecScore vs BMAD Method
BMAD Method (przełomowa metoda zwinnego wytwarzania sterowanego przez AI) to otwartoźródłowy sposób prowadzenia zwinnego dostarczania z agentami AI: doprecyzować pracę, zaplanować ją, zbudować i sprawdzić, a decyzje zapisać. Dokument wymagań produktu (PRD) to prozaiczny opis tego, co zbudować i dla kogo; mapa workflow metody wytwarza taki dokument, a potem architekturę i historyjki. Rozwój sterowany specyfikacją (SDD) to szersza idea, w której mieszczą się oba — zachowanie jest określone przed kodem. SpecScore to otwartoźródłowy format tej specyfikacji oraz interfejs wiersza poleceń (CLI). Ciągła integracja (CI) — automatyczne sprawdzenie każdej proponowanej zmiany — może paść, gdy plik SpecScore jest strukturalnie błędny.
Co je łączy.
Co BMAD Method robi dobrze.
README projektu, odczytane 30 października 2026, nazywa v6.12 wydaniem stabilnym, a v7 podglądem na gałęzi main. Data v7 w tym README już minęła. Traktuj nazwy linii jako migawkę.
Metoda, która sama dobiera skalę
README mówi, że małe zmiany idą od razu do budowy, a większa praca dostaje planowanie. Mapa workflow na main rozpisuje fazy: PRD (PRD.md), opcjonalną specyfikację UX, architecture.md z rejestrami decyzji, pliki epików i historyjek, a potem sprint. To pełna pętla zwinna, nie pojedynczy prompt.
Bramka przed implementacją
Ta sama mapa wymienia bmad-check-implementation-readiness, które zwraca PASS, CONCERNS albo FAIL przed implementacją. Agent product-manager w v6 ma też krok validate-PRD. To bramki workflow uruchamiane przez agenta. To nie jest osobny linter formatu, który kierujesz na dowolne drzewo Markdown.
Jest naprawdę opublikowana
Metoda jest na licencji MIT w publicznym repozytorium. Stabilna instalacja z README to npx bmad-method install i prosi o Node.js 20.12 albo nowszy oraz Python 3.10 albo nowszy. Strona bmadcode.com mówi, że metoda jest darmowa.
Porównanie możliwości.
BMAD to proces. SpecScore to format artefaktu, do którego proces może celować. Tabela porównuje te role.
| Możliwość | BMAD Method | SpecScore |
|---|---|---|
| Rola główna | Metoda zwinna: agenty, skille i workflow od pomysłu do zweryfikowanego kodu | Otwarty format specyfikacji + CLI |
| Artefakty planowania | PRD, specyfikacja UX, architektura, epiki i historyjki, status sprintu — na mapie workflow odczytanej 30 października 2026 | Pomysły, funkcje, plany, zadania w drzewie spec/, z identyfikatorami wymagań |
| Sprawdzanie pracy | Bramka gotowości (PASS / CONCERNS / FAIL) i workflow validate-PRD, uruchamiane przez agenta | specscore spec lint w CI, deterministycznie. /score to ręczna ocena AI. |
| Identyfikatory wymagań | Historyjki i wymagania funkcjonalne wewnątrz PRD i plików epików. To nie jest REQ: slug ze SpecScore. | REQ: slug oraz identyfikatory kryteriów akceptacji |
| Środowisko uruchomieniowe | Node.js i Python dla instalatora v6.12 opisanego w README | Nic poza jednym plikiem binarnym Go |
| Licencja | MIT, bmad-code-org/BMAD-METHOD | CC BY 4.0 format · Apache-2.0 CLI |
Co dodaje SpecScore.
Sprawdzenie jest poleceniem, nie krokiem metody
Wynik gotowości BMAD to decyzja wewnątrz jego workflow. Wynik SpecScore to kod wyjścia procesu. dogfood.yml uruchamia specscore spec lint przy każdym pull requeście. /score ocenia artefakt recenzentami skonfigurowanymi w repozytorium; wywołujesz go ty. CI tego nie robi.
$ 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)
Format przeżywa inną metodę
Dokumenty BMAD są ukształtowane przez jego workflow. Jeśli przestaniesz uruchamiać BMAD, Markdown zostaje, ale nic poza metodą nie egzekwuje kształtu. Drzewo SpecScore jest kontraktem. Inny workflow — w tym BMAD — może je pisać, a linter i tak obowiązuje.
Historyjki i wymagania zostają powiązane identyfikatorem
Historyjki BMAD niosą kontekst dalej, żeby agent nie decydował o produkcie od nowa. SpecScore robi z powiązania rzecz mechaniczną: zadanie w planie cytuje REQ: slug, a adnotacje specscore: plus trailery commita Verifies: wskazują kod z powrotem na kryterium.
Kiedy wybrać które rozwiązanie.
Sięgnij po BMAD Method, gdy…
- Chcesz pełnej pętli zwinnej — PRD, architektura, historyjki, sprint — wykonywanej przez agentów ze workflow przypisanymi do ról.
- Chcesz bramki gotowości oraz zestawu perspektyw produktu, architektury i testów, które metoda dostarcza.
- Ujednolicasz sposób, w jaki zespół pisze prompty, a skille metody są tym standardem.
Wybierz SpecScore, gdy…
- Specyfikacja ma padać w CI, gdy nagłówek, odnośnik albo status jest błędny, nawet jeśli tego dnia nikt nie uruchamia workflow BMAD.
- Potrzebujesz stabilnych identyfikatorów wymagań między narzędziami, nie tylko wewnątrz plików historyjek jednej metody.
- Chcesz format otwartoźródłowy, do którego może celować inny proces.
Metoda może pisać w tym formacie.
BMAD odpowiada na pytanie „jak prowadzimy pracę”. SpecScore odpowiada na pytanie „który plik jest kontraktem i skąd CI wie, że jest nienaruszony”. Zespół może zostawić PRD i historyjki BMAD na rozmowę, a funkcję SpecScore — na wymagania, które muszą przejść lint.
Użyj BMAD Method do pętli. Użyj SpecScore do artefaktu, który sprawdza pull request.
Ź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.
Opinia
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.