Frameworki spec-driven: Spec Kit kontra OpenSpec kontra BMAD kontra Superpowers

Frameworki spec-driven każą agentowi napisać przeglądalny Markdown (wymagania, projekt i zadania), zanim napisze kod. GitHub Spec Kit pasuje do nowych funkcji, które potrzebują śladu z bramkami na każdym etapie; OpenSpec pasuje do zmian w istniejącym kodzie, bo archiwizacja zmiany scala ją z żywą specyfikacją. BMAD dokłada role produktowe, a Superpowers pisze dokument projektowy tylko przy pracy architektonicznej.

Twój zespół zgodził się, że agenci mają pracować ze specyfikacji, i teraz cztery osoby mają cztery ulubione narzędzia. Jeden developer uruchomił Spec Kit w projekcie po godzinach, drugi przysięga na OpenSpec, product manager widział demo BMAD, a połowa zespołu ma już zainstalowane Superpowers. Potrzebujesz jednego wyboru, pilotażu, który go potwierdzi, i reguły mówiącej, które dokumenty zatwierdza człowiek.

Ta strona jest dla developera, który poprowadzi pilotaż, i dla tech leada, który wybiera framework. Przeprowadza jedną funkcję, „eksport logu audytowego do CSV”, przez Spec Kit i OpenSpec obok siebie, a potem pokazuje, co z tym samym zleceniem robią BMAD, Superpowers i cc-sdd.

Co zyskasz, porównując frameworki spec-driven na jednej funkcji

Tabelę decyzyjną opartą na tym, czy kod już istnieje i kto zatwierdza dokumenty.
Zweryfikowane instalacje wszystkich pięciu frameworków w Claude Code, Codex i Cursorze.
Eksport logu audytowego przeprowadzony przez Spec Kit i OpenSpec oraz drugą zmianę, która pokazuje, gdzie naprawdę się różnią.
Tabelę bramek review: który artefakt zatwierdza człowiek, która kontrola jest deterministyczna i kto się podpisuje.
Stały koszt kontekstu każdego frameworka oraz pułapki, których wciąż uczą stare tutoriale.

Który framework spec-driven wybrać?

Zacznij od jednostki pracy, wokół której zbudowano każdy framework. Spec Kit myśli funkcjami, OpenSpec zmianami w istniejącym systemie, BMAD dokumentami produktowymi przekazywanymi między rolami, a Superpowers pojedynczym zadaniem, którego rozmiar decyduje, czy w ogóle powstanie dokument projektowy.

Framework	Jednostka pracy	Artefakty, które zapisuje	Utrzymuje aktualną specyfikację systemu?	Bramki dla człowieka	Claude Code / Codex / Cursor	Wybierz, gdy	Unikaj, gdy
Spec Kit (GitHub)	Funkcja	`.specify/memory/constitution.md`, potem `specs/NNN-<feature>/spec.md`, `plan.md`, `tasks.md` i pliki pomocnicze	Nie, jeden folder na funkcję	Po każdym etapie, każdy uruchamiasz sam	Skille we wszystkich trzech	Nowe produkty i duże funkcje, które potrzebują konstytucji i pełnego śladu	Małe zmiany w dużej bazie kodu
OpenSpec (Fission AI)	Zmiana	`openspec/changes/<change>/proposal.md`, delty w `specs/`, `design.md`, `tasks.md`	Tak: `archive` scala delty z `openspec/specs/`	Review propozycji przed `apply`	Polecenia i skille w Claude Code i Cursorze, skille w Codex	Istniejący kod i stały strumień zmian	Potrzebujesz formalnego śladu zatwierdzeń dla każdego etapu
BMAD Method (BMad Code)	Dokument produktowy	Brief produktu, PRD, architektura, `SPEC.md`, epiki i historyjki	Osobno dla każdego dokumentu	Przy każdym dokumencie, z przekazaniem między personami	Skille lub pluginy we wszystkich trzech	Praca produktowa z kilkoma interesariuszami i epikami	Pojedynczy developer dowożący małe funkcje
Superpowers (ścieżka dokumentu projektowego)	Zadanie, klasyfikowane jako spike, ograniczone albo architektoniczne	Tylko przy pracy architektonicznej: `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`, potem plan w `docs/superpowers/plans/`	Nie	Zatwierdzenie projektu, potem planu	Plugin we wszystkich trzech	Agenci pomijają testy; specyfikacji chcesz tylko przy dużej pracy	Potrzebujesz specyfikacji dla każdej zmiany
cc-sdd (gotalab)	Specyfikacja	`requirements.md` (EARS), `design.md`, `tasks.md` dla każdej specyfikacji	Osobno dla każdej specyfikacji	Między fazami	Skille; wsparcie Cursora w wersji beta	Chcesz kształtu specyfikacji z Kiro poza Kiro	Chcesz największej społeczności i dokumentacji

Kiro specs, wbudowane w Kiro IDE i CLI od AWS, zapisują requirements.md (EARS), design.md i tasks.md w .kiro/specs/<feature>/ według źródeł wtórnych (26 września 2026 roku nie dało się odczytać kiro.dev). cc-sdd daje ten kształt innym agentom; sam produkt omawia porównanie z Kiro.

Greenfield czy brownfield: które pytanie rozstrzyga?

Odpowiadaj po kolei i zatrzymaj się na pierwszym „tak”.

Czy większość kodu dopiero powstanie albo product owner musi zatwierdzić funkcję, zanim ktokolwiek ją zaplanuje? Użyj Spec Kit. Konstytucja i osobne skille dla etapów dają bramkę na każdym kroku.
Czy zmieniasz działający system kilka razy w tygodniu? Użyj OpenSpec. Propozycja zapisuje tylko deltę, a archiwizacja sprawia, że openspec/specs/ opisuje system w jego obecnym stanie.
Czy praca zaczyna się jako pomysł produktowy, który przed specyfikacją potrzebuje briefu, PRD i architektury? Użyj ścieżki planowania BMAD, a potem buduj historyjka po historyjce.
Czy twoim problemem jest agent, który pomija testy i ogłasza sukces bez dowodów, a nie brak specyfikacji? Użyj Superpowers. Dokument projektowy powstaje tam tylko przy pracy architektonicznej.
Nic z powyższych? Użyj zwykłego Markdownu i kontroli CI opisanych w spec-driven development. Framework dokłada ceremonii; nie sprawia, że specyfikacja jest prawdziwa.

Zespoły mieszane często używają OpenSpec do codziennych zmian i Spec Kit do okazjonalnego nowego serwisu. Nigdy nie prowadź jednej zmiany przez dwa frameworki: agent dostaje wtedy dwa źródła prawdy.

Zainstaluj frameworki spec-driven w każdym agencie

Spec Kit i OpenSpec instalują pliki projektu własnymi CLI. BMAD, Superpowers i cc-sdd instalują się jako skille albo pluginy. Polecenia terminala uruchamiaj w katalogu głównym repozytorium.

# Spec Kit (Python 3.11+ i uv): 10 skilli speckit-* w .claude/skills/
uv tool install specify-cli
specify init --here --integration claude

# OpenSpec (Node >= 20.19.0): 6 skilli oraz polecenia /opsx:*
npm install -g @fission-ai/openspec@latest
openspec init --tools claude

# BMAD, ścieżka stabilna (npm 6.12.0)
npx bmad-method install --directory . --modules bmm --tools claude-code --yes

# cc-sdd: skille Claude Code to domyślny cel
npx cc-sdd@latest

# W sesji Claude Code
# BMAD, ścieżka pluginu (6.13.0-next)
/plugin marketplace add bmad-code-org/bmad-plugins
/plugin install bmad-method@bmad

# Superpowers (marketplace Anthropic zainstalował 26.09.2026 wersję 6.4.1; upstream miał 6.4.2)
/plugin install superpowers@claude-plugins-official

# Spec Kit: skille w .agents/skills/, wywoływane jako $speckit-<etap>
uv tool install specify-cli
specify init --here --integration codex

# OpenSpec: tylko skille (bez poleceń dla Codex), wywoływane jako $openspec-propose
npm install -g @fission-ai/openspec@latest
openspec init --tools codex

# BMAD, ścieżka stabilna: skille w .agents/skills/
npx bmad-method install --directory . --modules bmm --tools codex --yes
# BMAD, ścieżka pluginu
codex plugin marketplace add bmad-code-org/bmad-plugins
codex plugin add bmad-method@bmad

# cc-sdd
npx cc-sdd@latest --codex-skills

Superpowers zainstalujesz, wpisując /plugins w sesji Codex i wybierając Superpowers z listy kuratorowanej.

# Spec Kit: identyfikator integracji to cursor-agent, nie cursor
uv tool install specify-cli
specify init --here --integration cursor-agent

# OpenSpec: .cursor/commands/ i .cursor/skills/, wywoływane jako /opsx-propose
npm install -g @fission-ai/openspec@latest
openspec init --tools cursor

# BMAD, ścieżka stabilna: skille w .agents/skills/
npx bmad-method install --directory . --modules bmm --tools cursor --yes

# cc-sdd: wsparcie Cursora jest w wersji beta
npx cc-sdd@latest --cursor-skills

Superpowers zainstalujesz, wpisując /add-plugin superpowers w czacie Agenta. To polecenie pochodzi z README Superpowers; marketplace’u Cursora nie dało się sprawdzić 26 września 2026 roku.

BMAD ma 26 września 2026 roku dwie ścieżki instalacji i każda dostarcza inne skille. Tutorial BMAD używa stabilnego instalatora npm (6.12.0). Plugin (bmad-method@bmad, 6.13.0-next, 21 skilli) podąża za gałęzią main i zawiera bmad-create-epics-and-stories tam, gdzie dokumentacja z main opisuje bmad-preview-ticketing. Wybierz jedną ścieżkę dla całego zespołu i przypnij wersję, inaczej dwóch developerów będzie realizować dwa różne procesy pod jedną nazwą.

specify init --ai claude kończy się błędem: flagę --ai usunięto w Spec Kit 0.10.0. Użyj --integration claude. Bez --integration tryb nieinteraktywny wybiera Copilota.
specify init --here --non-interactive odmawia działania w niepustym repozytorium, dopóki nie dodasz --force (1.0.12).
npm i -g openspec instaluje niezwiązany placeholder z 2022 roku (0.0.0). Właściwy pakiet to @fission-ai/openspec. Polecenia /openspec:proposal, /openspec:apply i /openspec:archive należą do wycofanego procesu; obecny to /opsx:*.
OpenSpec zapisuje polecenia inaczej w każdym narzędziu: /opsx:propose w Claude Code, /opsx-propose w Cursorze, $openspec-propose w Codex.
README BMAD na main wymienia plugin bmad-core-tools; marketplace dostarcza bmad-method@bmad i bmad-toolbox@bmad. Nie istnieje pakiet npm bmad, a poradniki do v4 (polecenia *agent, bmad-core/) nie pasują do v6.
npx skills add obra/superpowers kopiuje skille bez hooka SessionStart, więc metoda nie uruchamia się sama. Zainstaluj plugin.
Starsze tryby poleceń /kiro:* w cc-sdd (--claude, --cursor) są przestarzałe, a --codex jest zablokowany. Używaj flag --*-skills.

Przeprowadź eksport logu audytowego przez Spec Kit i OpenSpec

Funkcja: administratorzy zespołu eksportują log audytowy swojej organizacji do CSV dla zakresu dat nie dłuższego niż 90 dni; członkowie bez roli administratora nie mogą eksportować. Oba przebiegi poniżej używają pisowni z Claude Code. W Codex zamień /speckit- na $speckit-, a /opsx:propose na $openspec-propose; w Cursorze dwukropek w poleceniach OpenSpec zmienia się w łącznik. W Cursorze nazwy /speckit-* się nie zmieniają (skille w .cursor/skills/).

Etap	Spec Kit	OpenSpec
Reguły projektu	`/speckit-constitution` raz, zapisuje `.specify/memory/constitution.md`	Opcjonalne `context:` i `rules:` w `openspec/config.yaml`
Eksploracja / doprecyzowanie	`/speckit-clarify` rozstrzyga otwarte pytania w zapisanej specyfikacji	`/opsx:explore` bada kod i problem przed propozycją
Zapis wymagania	`/speckit-specify`, zapisuje `specs/001-audit-log-export/spec.md`	`/opsx:propose`, zapisuje w jednym kroku `proposal.md`, `specs/audit-log-export/spec.md` (deltę), `design.md` i `tasks.md`
Plan	`/speckit-plan`, zapisuje `plan.md`, `research.md`, `data-model.md`, `contracts/`, `quickstart.md`	Już w `design.md`
Zadania	`/speckit-tasks`, potem `/speckit-analyze`	Już w `tasks.md`
Budowa	`/speckit-implement`, potem `/speckit-converge` aż do „Converged”	`/opsx:apply`
Zamknięcie	Otwierasz PR; folder funkcji zostaje w stanie z chwili zapisu	`/opsx:archive` scala deltę z `openspec/specs/audit-log-export/spec.md`

Spec Kit dzieli planowanie na sześć skilli i po każdym możesz się zatrzymać na review. OpenSpec ma jeden punkt review: propose zapisuje wszystkie cztery artefakty i się zatrzymuje. Jego skill mówi wprost, że zlecenie „authorizes planning only”, i czeka na nową prośbę przed apply.

Zapisz wymaganie. Wklej to samo zdanie do obu frameworków, żeby porównywać frameworki, a nie prompty.

/speckit-specify Team admins can export their organization's audit log as CSV, filtered by a date range of at most 90 days. Members without the admin role cannot export and get no file. Exports over 100,000 rows are refused with a message telling the admin to narrow the range. Every export is itself recorded in the audit log with who exported, the filters and the row count. Out of scope: scheduled exports, JSON, cross-organization exports.

/opsx:propose add-audit-log-csv-export Team admins can export their organization's audit log as CSV, filtered by a date range of at most 90 days. Members without the admin role cannot export and get no file. Exports over 100,000 rows are refused with a message telling the admin to narrow the range. Every export is itself recorded in the audit log with who exported, the filters and the row count. Out of scope: scheduled exports, JSON, cross-organization exports. Read the existing auth middleware and audit tables before writing design.md, and name the files you will touch in tasks.md.

Przejrzyj, co każdy z nich zapisał. spec.md ze Spec Kit używa historyjek użytkownika ze scenariuszami Given/When/Then i numerowanych wymagań (FR-001) i może zostawić do trzech znaczników [NEEDS CLARIFICATION] do rozstrzygnięcia przez ciebie. OpenSpec zapisuje deltę z blokami ### Requirement: i #### Scenario: w formie WHEN/THEN. Oto delta OpenSpec z przebiegu roboczego, którą openspec validate --strict zaakceptował:

## Purpose

Lets organization admins take audit events out of the product as a CSV file for compliance reviews.

## ADDED Requirements

### Requirement: Admin exports audit log as CSV
The system SHALL let an organization admin export audit events for a date range of at most 90 days as CSV.

#### Scenario: Admin exports a 30-day range
- **WHEN** an admin exports a 30-day range containing 1,200 events
- **THEN** the system returns a CSV with a header row and 1,200 data rows

#### Scenario: Non-admin is refused
- **WHEN** a member without the admin role requests an export
- **THEN** the system refuses the request and produces no file

Zaakceptuj każdy z tych dokumentów, gdy każdy scenariusz ma konkretne wejście i wyjście, a w żadnym wymaganiu nie pojawia się nazwa tabeli, klasy ani biblioteki.

Zbuduj. Spec Kit zapętla /speckit-implement i /speckit-converge, dopóki converge nie zgłosi „Converged”; prompt do tej pętli znajdziesz w tutorialu Spec Kit. OpenSpec uruchamia /opsx:apply, który przechodzi przez tasks.md. W obu przypadkach poprawność kodu potwierdzają testy napisane ze scenariuszy, a nie werdykt frameworka.
Zamknij zmianę. W OpenSpec /opsx:archive waliduje zmianę, przenosi ją do openspec/changes/archive/2026-09-26-add-audit-log-csv-export/ i tworzy openspec/specs/audit-log-export/spec.md. Przebieg roboczy wypisał audit-log-export: create i + 1 added. Spec Kit zostawia specs/001-audit-log-export/ jako zapis tej funkcji.

Co się dzieje przy drugiej zmianie?

Miesiąc później dział compliance prosi o filtr po autorze zdarzenia. Tu drogi obu frameworków się rozchodzą.

W Spec Kit filtr staje się funkcją 002 z własną specyfikacją, planem i zadaniami albo edytujesz specyfikację 001 już po wdrożeniu. Tak czy inaczej nic nie tworzy jednego aktualnego opisu eksportu: żeby dowiedzieć się, co eksport robi dziś, czytelnik musi przeczytać oba foldery i ustalić, który wygrywa.

W OpenSpec propozycja niesie deltę MODIFIED. Instrukcje skilla wymagają skopiowania całego istniejącego bloku wymagania i jego edycji, a nie dopisania fragmentu:

## MODIFIED Requirements

### Requirement: Admin exports audit log as CSV
The system SHALL let an organization admin export audit events for a date range of at most 90 days as CSV, optionally filtered to a single actor.

#### Scenario: Admin exports a 30-day range
- **WHEN** an admin exports a 30-day range containing 1,200 events
- **THEN** the system returns a CSV with a header row and 1,200 data rows

#### Scenario: Non-admin is refused
- **WHEN** a member without the admin role requests an export
- **THEN** the system refuses the request and produces no file

#### Scenario: Admin filters by actor
- **WHEN** an admin exports a 30-day range filtered to an actor who has 40 of the 1,200 events
- **THEN** the system returns a CSV with a header row and exactly 40 data rows, all for that actor

Recenzent czyta jedno wymaganie, widzi nowy scenariusz, a po archiwizacji openspec/specs/audit-log-export/spec.md opisuje eksport w jego obecnym kształcie. To cały argument za OpenSpec w istniejącym kodzie, zamknięty w jednym diffie.

Jak tę samą funkcję obsługują BMAD, Superpowers i cc-sdd?

BMAD dopasowuje rozmiar procesu do zlecenia. Jasna, mała zmiana trafia prosto do jednego skilla (pisownia z Claude Code; w Codex $bmad-build):

/bmad-build Add CSV export of the audit log for team admins, date range at most 90 days, non-admins refused.

bmad-build dopytuje o potrzebne decyzje, pokazuje plan, czeka na twoją zgodę, a potem pisze i sprawdza kod. Jeśli eksport to jedna historyjka w większym epiku compliance, najpierw idzie ścieżka planowania: bmad-product-brief, bmad-prd, bmad-architecture i bmad-spec (zapisuje specs/spec-<slug>/SPEC.md), potem zgłoszenia i jedna budowa na historyjkę, bmad-code-review i bmad-retrospective. Na ścieżce pluginu krok zgłoszeń to bmad-create-epics-and-stories; na ścieżce skilli jest to bmad-preview-ticketing.

Superpowers klasyfikuje zlecenie, zanim o cokolwiek zapyta. Skill brainstorming definiuje trzy ścieżki. Spike wymaga zatwierdzonego pytania i sondy. Zadanie ograniczone dostaje krótki projekt w czacie, który zatwierdzasz. Praca architektoniczna dostaje pisemną specyfikację w docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md, którą zatwierdzasz, zanim writing-plans zapisze plan w docs/superpowers/plans/; ten plan też zatwierdzasz i wybierasz sposób jego wykonania, zanim powstanie jakikolwiek kod. Pojedyncza trasa CSV to raczej zadanie ograniczone, więc plik specyfikacji nie powstaje. Jeśli chcesz pliku dla każdej zmiany, połącz Superpowers z OpenSpec.

cc-sdd daje Claude Code, Codex i Cursorowi kształt artefaktów z Kiro. Zacznij od discovery i pozwól mu pokierować pracą:

/kiro-discovery CSV export of the audit log for team admins
/kiro-spec-init audit-log-export
/kiro-spec-requirements audit-log-export
/kiro-spec-design audit-log-export
/kiro-spec-tasks audit-log-export
/kiro-impl audit-log-export

To pisownia z Claude Code. W Codex --codex-skills instaluje te same skille w .agents/skills/, wywoływane jako $kiro-discovery, $kiro-spec-init i tak dalej (przewodnik zgodności agentów cc-sdd, 26.09.2026); wsparcie Cursora jest w wersji beta.

requirements.md powstaje w formie EARS z kryteriami akceptacji. Dla istniejącego systemu README dodaje najpierw kiro-steering, a przed projektem opcjonalne kiro-validate-gap. Gdy host ma subagentów, kiro-impl daje każdemu zadaniu świeżego implementującego, który pracuje w cyklu red-green TDD, oraz niezależnego recenzenta.

Gdzie ludzie robią review i co dowodzi poprawności kodu?

Framework specyfikacji przenosi review z diffu na dokumenty. Działa to tylko wtedy, gdy każda bramka ma właściciela, a za werdyktami modelu stoi coś deterministycznego.

Bramka	Spec Kit	OpenSpec	BMAD	Superpowers	Kto zatwierdza
Zachowanie jest właściwe	`spec.md` po `speckit-clarify`	`proposal.md` i delty specyfikacji	PRD, potem `SPEC.md`	Pisemna specyfikacja (praca architektoniczna) albo projekt w czacie (zadanie ograniczone)	Product owner
Projekt pasuje do systemu	`plan.md` z Constitution Check	`design.md`	Dokument architektury	Plan implementacji	Tech lead
Dokumenty są spójne	`speckit-analyze` (model, tylko odczyt)	`openspec validate --strict` (deterministyczne, tylko struktura)	`bmad-code-review` po budowie	Review między zadaniami	Inżynier
Kod robi to, co mówi specyfikacja	Testy ze scenariuszy akceptacyjnych, potem `speckit-converge`	Testy ze scenariuszy; `apply` odhacza `tasks.md`	Testy dla każdej historyjki	TDD dla każdego zadania, potem `verification-before-completion`	CI, potem recenzent PR

Ta tabela działa tylko przy dwóch regułach. Po pierwsze, zamień każdy scenariusz w czerwony test przed implementacją, jak w wykonywalnych kryteriach akceptacji; werdykty converge i skille review to oceny, powtarzalne są tylko testy. Po drugie, trzymaj foldery specyfikacji poza zakresem zapisu agenta implementującego, za pomocą uprawnień i sandboksów oraz wpisu w CODEOWNERS, żeby agent nie mógł zazielenić testu, edytując wymaganie.

Dla OpenSpec dodaj do CI kontrolę struktury:

# Krok CI: oblewa job, jeśli jakakolwiek zmiana albo specyfikacja jest źle zbudowana
npx -y @fission-ai/openspec@1.13.2 validate --all --strict --no-interactive

Sprawdza dokumenty, nie kod. Przepuszcza też jeden częsty błąd: w przebiegu roboczym scenariusz zapisany trzema krzyżykami (### Scenario:), pod wymaganiem, które miało też poprawny #### Scenario:, przeszedł --strict z samą linią INFO, że nagłówek „is ignored by validation”. Wymaganie, którego jedyny scenariusz ma trzy krzyżyki, oblewa --strict. Jeśli traktujesz scenariusze jako przypadki testowe, wyszukuj w openspec/ wzorzec ^### Scenario:.

Review the planning documents for the audit-log CSV export before any code is written. Do not edit them.
Find them in whichever exists: specs/0*-audit-log-export/, openspec/changes/add-audit-log-csv-export/, specs/spec-audit-log-export/ or docs/superpowers/specs/.
Report, with the requirement ID or heading:
1. Requirements with no scenario that has a concrete input and a concrete expected output.
2. Scenarios a wrong implementation could pass (for example, a range filter tested with data that would pass unfiltered).
3. Missing edge cases: range of exactly 90 days, empty range, exactly 100,000 rows, deleted actor, timezone at the range boundary, a non-admin calling the endpoint directly.
4. Any table, class, file or library name inside a requirement.
5. Tasks that no requirement justifies, and requirements with no task.
End with READY or NOT READY and the three changes that matter most.

To review jest bramką, którą product owner albo tech lead czyta zamiast kodu. Pull request niesie potem pakiet dowodów: każde wymaganie przypisane do testu, który go dowodzi.

Ile kontekstu kosztuje każdy framework spec-driven?

Stały koszt to to, co framework dokłada do każdej sesji, zanim go użyjesz. Claude Code 2.1.283 mierzy go dla pluginów poleceniem claude plugin details <plugin>; dla skilli lokalnych w projekcie policz opisy.

Framework	Sposób instalacji	Stały koszt (26.09.2026)	Najcięższe pojedyncze wywołanie
Spec Kit 1.0.12	10 skilli w projekcie	Około 1150 znaków opisów skilli, mniej więcej 300 tokenów (szacunek przy czterech znakach na token)	`speckit-checklist`, 22,7 KB instrukcji
OpenSpec 1.13.2	6 skilli w projekcie i 6 poleceń w Claude Code	Około 2200 znaków opisów, mniej więcej 550 tokenów (ten sam szacunek)	`openspec-explore`, 22,8 KB
BMAD `bmad-method@bmad`	Plugin, 21 skilli	~1676 tokenów (`claude plugin details`); `bmad-toolbox@bmad` dokłada ~975	Nie mierzono
Superpowers	Plugin, 15 skilli i hook SessionStart	~838 tokenów (`claude plugin details`)	`subagent-driven-development`, ~11,8 tys. tokenów przy każdym uruchomieniu; `brainstorming` ~6,3 tys.

Większym kosztem są dokumenty: jedna funkcja w Spec Kit produkuje ich osiem, a każdy kolejny etap je czyta. Uruchom /context w Claude Code przed pierwszym etapem pilotażu i po nim, żeby zmierzyć oba efekty.

Przeprowadź pilotaż frameworka spec-driven na jednej funkcji

Tylko pilotaż pokaże, jak twoi recenzenci zniosą osiem dokumentów na funkcję.

Wybierz jedną prawdziwą funkcję, która dotyka istniejącego kodu i ma product ownera, a nie zabawkę.
Zainstaluj jeden framework (najwyżej dwa, jeśli wybierasz między Spec Kit a OpenSpec) na gałęzi, według zakładek powyżej, i zatwierdź (commit) wygenerowane pliki, żeby wszyscy recenzowali tę samą konfigurację.
Przeprowadź przez niego funkcję. Zapisz czas od zlecenia do zatwierdzonej specyfikacji, liczbę rund review na dokument i stały koszt kontekstu.
Zamień każdy scenariusz w test przed implementacją i pozwól CI rozstrzygnąć, czy funkcja jest gotowa.
Tydzień później przeprowadź drugą zmianę w tej samej funkcji. To, jak łatwo recenzent odpowie na pytanie „co ta funkcja robi teraz?”, jest wynikiem, który rozdziela frameworki.

Recommend one spec-driven framework for this repository: GitHub Spec Kit, OpenSpec, BMAD Method, Superpowers or plain Markdown specs. Do not install anything.
First inspect: how much code exists and how old it is (git log --since="1 year ago" --oneline | wc -l), whether specs, ADRs or PRDs already exist, the test runner and how CI runs it, and which agent config files exist (CLAUDE.md, AGENTS.md, .cursor/).
Then answer:
1. Is this mostly greenfield or brownfield, with the evidence.
2. The framework you recommend, and the one you would reject, each in two sentences tied to that evidence.
3. The first feature to pilot it on, and which document the product owner and the tech lead each approve.
4. The test command that will prove the pilot feature, and whether it runs in CI today.

Co psuje się przy wdrażaniu frameworka spec-driven?

Nikt nie recenzuje dokumentów. Objaw: specyfikacje są zatwierdzane kilka minut po wygenerowaniu, a błędy prowadzą do wymagań, których nikt nie przeczytał. Niezrecenzowana specyfikacja przenosi halucynację wyżej w procesie. Wyjście: zrób z zatwierdzenia specyfikacji i projektu jawne checki pull requestu z imiennymi właścicielami i przed zatwierdzeniem uruchamiaj prompt review bramki.

Agent poprawia specyfikację pod swój kod. Objaw: PR z implementacją zmienia spec.md albo deltę OpenSpec, a testy przechodzą. Wyjście: zablokuj zapis do folderów specyfikacji w sesjach implementacyjnych, wymagaj właściciela specyfikacji w CODEOWNERS i odrzuć PR.

Dwa frameworki konkurują. Objaw: repozytorium ma specs/001-…, openspec/changes/… i docs/superpowers/specs/… dla tej samej funkcjonalności, a agenci cytują ten plik, który znaleźli pierwszy. Wyjście: wybierz jeden framework specyfikacji na repozytorium i zapisz to w CLAUDE.md albo AGENTS.md. Superpowers może zostać jako dyscyplina budowania, jeśli jego dokumenty projektowe wskazują na tę jedną specyfikację.

Specyfikacja per funkcja rozjeżdża się z systemem. Objaw: w Spec Kit albo BMAD specs/001-… opisuje eksport z chwili wdrożenia we wrześniu i nikt nie wie, czy to wciąż prawda. Wyjście: albo przenieś pracę na istniejącym kodzie do OpenSpec, albo dodaj kontrole śledzenia wymagań i dryfu z spec-driven development.

Ceremonia przygniata małe zmiany. Objaw: developerzy omijają framework przy wszystkim, co trwa krócej niż dzień, i proces zanika. Wyjście: opublikuj regułę rozmiaru. Błędy i refaktoryzacje przechodzą przez czerwony test; małe zmiany obsługują propozycje OpenSpec, bmad-build z BMAD albo ograniczony projekt w Superpowers; pełne planowanie Spec Kit albo BMAD zostaw dla funkcji z kilkoma historyjkami użytkownika.

Źle zbudowane scenariusze przechodzą walidację. Objaw: scenariusz OpenSpec zapisany jako ### Scenario: pod wymaganiem, które ma już jeden poprawny #### Scenario:, jest pomijany, a openspec validate --strict pozostaje zielone (1.13.2). Wyjście: wyszukuj w CI scenariusze z trzema krzyżykami i generuj testy ze scenariuszy skryptem, który oblewa, gdy żadnego nie znajdzie.

Dokąd dalej z frameworkami spec-driven

Spec-driven development Koncepcja wyjściowa: jedna autorytatywna specyfikacja, delta specyfikacji w każdym PR i kontrole CI wykrywające dryf.

GitHub Spec Kit w praktyce Pełny przebieg Spec Kit na eksporcie logu audytowego, z pętlą implement i converge.

OpenSpec Propozycje zmian, delty specyfikacji i archiwizacja w istniejącej bazie kodu.

Wykonywalne kryteria akceptacji Zamień każdy scenariusz w czerwony test, zanim agent zacznie implementację.

Superpowers Plugin dyscypliny stojący za ścieżką dokumentu projektowego: worktree, TDD, review i weryfikacja.

Porównanie frameworków pracy z agentami Frameworki spec-driven obok pakietów dyscypliny i harnessów orkiestracyjnych.