Przejdź do głównej zawartości
AI Developer Toolkit

BMAD Method: role zwinne jako agenci

BMAD Method (Breakthrough Method of Agile AI-driven Development) to otwartoźródłowy framework od BMad Code, który instaluje role zwinne, od analityka po dewelopera, jako skille agenta w Claude Code, Codex i Cursorze. Skille planistyczne piszą PRD, architekturę i epiki, a bmad-build implementuje kolejne historyjki. Od wersji 6.12.0 najpierw bada kod, a potem decyduje, ile specyfikacji i review potrzebuje zmiana.

Twój product manager chce PRD, zanim ktokolwiek napisze kod, architekt chce spisanych decyzji, a deweloperzy chcą oddać historyjkę agentowi i dostać przetestowany pull request. Bez wspólnego procesu każdy promptuje agenta inaczej, PRD nigdy nie dociera do agenta, który pisze kod, a poprawka jednej linii przechodzi tę samą ceremonię co nowa funkcja rozliczeń.

Ta strona jest dla programisty, który uruchamia BMAD, i dla tech leada, który decyduje o jego przyjęciu. Prowadzi jedną funkcję, alerty wydatków dla właścicieli workspace’ów, od PRD do retrospektywy, z przypiętą instalacją, promptami do skopiowania, tabelą, która bramka czego dowodzi, oraz zasadą, kiedy wygrywa lżejszy framework.

Jakich agentów instaluje BMAD i co każdy z nich zapisuje?

Dział zatytułowany „Jakich agentów instaluje BMAD i co każdy z nich zapisuje?”

Skille person (bmad-agent-*) dają agentowi imię, styl wypowiedzi i menu. Skille workflow wykonują pracę. Skill workflow możesz wywołać bezpośrednio; persona dodaje styl rozmowy, nie możliwości.

Skill personyRola (imię w domyślnej konfiguracji)Menu uruchamiaZostawia po sobie
bmad-agent-analystAnalityk biznesowy (Mary)bmad-product-brief, bmad-prfaq, bmad-deep-recon, bmad-brainstorming, bmad-project-contextBrief produktu, PRFAQ, podsumowanie researchu albo blok w AGENTS.md
bmad-agent-pmProduct manager (John)bmad-prd, bmad-create-epics-and-stories, bmad-sprint-planning, bmad-correct-coursePRD, epics.md, propozycje zmian w sprincie
bmad-agent-ux-designerProjektant UX (Sally)bmad-uxDESIGN.md i EXPERIENCE.md
bmad-agent-architectArchitekt systemu (Winston)bmad-architecture, bmad-sprint-planningKrótki dokument architektury
bmad-agent-devStarszy inżynier oprogramowania (Amelia)bmad-build, bmad-code-review, bmad-qa-generate-e2e-tests, bmad-sprint-planning, bmad-retrospectiveKod, specyfikację każdej historyjki, zapisy z review i retrospektywy

BMAD zapisuje do dwóch folderów wyjściowych ustawionych w _bmad/bmm/config.yaml, a do tego do folderów skilli każdego narzędzia:

  • Folder_bmad/ konfiguracja, skrypty i katalog pomocy zarządzane przez instalator
    • bmm/config.yaml ścieżki wyjściowe, języki, poziom umiejętności
    • Foldercustom/ nadpisania zespołu (config.user.toml zostaje prywatny)
      • …
  • Folder_bmad-output/
    • Folderplanning-artifacts/ brief, PRD, UX, architektura, epics.md
      • …
    • Folderimplementation-artifacts/
      • sprint-status.yaml stany historyjek: backlog → ready-for-dev → in-progress → review → done
      • spec-1-2-threshold-check.md jedna specyfikacja na historyjkę, pisana przez bmad-build
      • deferred-work.md cele odłożone podczas planowania
    • Folderspecs/spec-<slug>/ SPEC.md z bmad-spec
      • …
  • Folder.claude/skills/bmad-*/ Claude Code
    • …
  • Folder.agents/skills/bmad-*/ Codex i Cursor
    • …

bmad-help czyta katalog w _bmad/_config/ i twoje artefakty, a potem mówi, który skill uruchomić jako następny. Sięgaj po niego, gdy nie wiesz, na którym etapie jesteś.

Zainstaluj BMAD i podłącz go do agenta

Dział zatytułowany „Zainstaluj BMAD i podłącz go do agenta”

BMAD potrzebuje Node.js dla instalatora i uv w PATH: bmad-build renderuje swój workflow przez uv run i zatrzymuje się, gdy uv brakuje. Skille person działają bez niego, co ukrywa problem aż do pierwszej budowy.

  1. Zainstaluj w katalogu głównym repozytorium, z przypiętą wersją, dla każdego agenta, którego używa zespół (terminal):

    Okno terminala
    uv --version                     # bez uv bmad-build się zatrzymuje
    npx bmad-method@6.12.0 install --directory . --modules bmm \
      --tools claude-code,codex,cursor --yes

    --modules bmm to moduł BMad Method; moduł core instaluje się razem z nim. --tools jest wymagane przy nieinteraktywnej instalacji z --yes; npx bmad-method@6.12.0 install --list-tools wypisuje wszystkie obsługiwane identyfikatory i ich foldery docelowe.

  2. Sprawdź, gdzie twoje narzędzie znalazło skille:

    Instalator zapisuje 29 skilli w .claude/skills/. Wpisz /bmad-help w sesji, żeby potwierdzić, że się ładują; każdy skill jest też poleceniem, na przykład /bmad-build.

  3. Dodaj do repozytorium (commit) _bmad/, .claude/skills/bmad-* i .agents/skills/bmad-*, żeby każdy w zespole uruchamiał tę samą wersję. Aktualizuj świadomie, w osobnym pull requeście: uruchom ponownie npx bmad-method@<wersja> install w repozytorium i wybierz ścieżkę aktualizacji, którą zaproponuje instalator.

Ścieżka pluginu podąża za gałęzią main BMAD (6.13.0-next na 2026-09-26) i dostarcza 21 skilli zamiast 29:

/plugin marketplace add bmad-code-org/bmad-plugins
/plugin install bmad-method@bmad

Wybierz jedną ścieżkę dla całego zespołu. Instalator z npm przypina wersję w repozytorium; plugin zmienia się razem z main, gdzie nazwy skilli wciąż się zmieniają.

Jak bmad-build decyduje, ile ceremonii potrzebuje zmiana?

Dział zatytułowany „Jak bmad-build decyduje, ile ceremonii potrzebuje zmiana?”

Przed 6.12.0 Build wybierał ścieżkę, zanim zajrzał do kodu, więc zmiana, która wyglądała na małą, mogła dostać za mało rygoru, a ta, która wyglądała na dużą, za dużo. Informacje o wydaniu v6.12.0 ujmują zmianę jednym zdaniem: „Build decides how much ceremony a change needs after investigating it, not before.”

Krok 2 bmad-build najpierw przeszukuje kod, niczego cię nie pytając, a potem zapisuje trzy fakty:

FaktCo się liczyPrzykłady
Luki w intencjiTo, czego prośba nie mówi, czego kod nie rozstrzyga i co zauważysz w wynikuKtóra rola może edytować budżet; czy alerty się powtarzają
Rzeczy nieodwracalneWszystko, czego nie da się cofnąćMigracja, usunięcie lub nadpisanie danych, wysłanie maila, wyzwolenie deployu lub zmiany konfiguracji
ZasięgIle plików się zmienia i co nowego będzie wywoływać inny kodNowa tabela, nowa funkcja publiczna, nowy endpoint

Ścieżka wynika z tych faktów:

  • One-shot. Brak luk w intencji, nic nieodwracalnego i mały zasięg. Specyfikacja ma dwie sekcje, ## Intent i ## Implementation Notes, a agent implementuje, przegląda i tworzy commit w jednej sesji. Jeśli w trakcie implementacji wyjdzie luka, krok nieodwracalny albo rosnący zakres, agent się zatrzymuje, przywraca pełne sekcje specyfikacji i wraca do planowania.
  • Dispatch. Wszystko inne. Agent pisze pełną specyfikację: intencję, granice, macierz wejść, wyjść i przypadków brzegowych, mapę kodu, zadania z kryteriami akceptacji Given/When/Then oraz polecenia weryfikacji. Każda luka w intencji staje się otwartym pytaniem, na które musisz odpowiedzieć. Specyfikację zatwierdzasz w punkcie kontrolnym; świeży subagent implementuje ją, traktując specyfikację jako jedyne źródło prawdy; potem równolegle działają trzy warstwy review.

Każda specyfikacja celuje w jeden cel widoczny dla użytkownika i 900–1600 tokenów; powyżej tego BMAD proponuje odłożenie celów pobocznych do deferred-work.md. Żaden z tych limitów nie jest twardą bramką.

Przeprowadź małą zmianę ścieżką one-shot

Dział zatytułowany „Przeprowadź małą zmianę ścieżką one-shot”

Zacznij od małej zmiany, żeby zobaczyć routing bez ścieżki planistycznej. Repozytorium to aplikacja SaaS w Next.js i Postgresie; zmiana dodaje linię z budżetem w nagłówku ustawień workspace’u.

W Codeksie zacznij prompt od $bmad-build, w Cursorze od „Use the bmad-build skill to”. Agent powinien zrelacjonować swoje badanie kodu, nie znaleźć luk w intencji ani rzeczy nieodwracalnych i zapisać _bmad-output/implementation-artifacts/spec-workspace-budget-header.md z route: 'oneshot'. Potem implementuje, uruchamia warstwy review i tworzy lokalny commit. Nigdy nie wypycha zmian.

Jeśli agent skieruje tę zmianę na dispatch, przeczytaj dlaczego. „No budget set” kontra ukryty nagłówek to prawdziwa luka w intencji i agent słusznie o nią pyta.

Przeprowadź funkcję przez ścieżkę planistyczną

Dział zatytułowany „Przeprowadź funkcję przez ścieżkę planistyczną”

Właściwa funkcja jest większa: właściciele workspace’u dostają maila, gdy wydatki na agentów przekroczą 80% miesięcznego budżetu. Dotyka danych rozliczeniowych, wysyła maile (nieodwracalne) i wymaga zadania cyklicznego, więc idzie ścieżką planistyczną. Każdy krok poniżej to osobna sesja; kontekst między nimi niosą pliki.

  1. Napisz PRD z product managerem. bmad-prd przeprowadza z tobą wywiad, a potem zapisuje PRD w _bmad-output/planning-artifacts/. Odpowiadaj tak, jak odpowiedziałby właściciel produktu; wartością są pytania agenta.

  2. Zapisz decyzje architektoniczne. bmad-architecture pisze krótki dokument z decyzjami, które utrzymują spójność historyjek budowanych osobno: gdzie liczone są wydatki, co uruchamia sprawdzenie progu i jak zapewnić idempotentność zasady „jeden mail na próg na miesiąc”.

  3. Podziel pracę na epiki i historyjki. Uruchom bmad-create-epics-and-stories. Zapisuje epics.md. Dla tej funkcji spodziewaj się jednego epika z trzema historyjkami: zapis budżetu, sprawdzanie progów, wysłanie i zalogowanie alertu.

  4. Przejdź bramkę gotowości przed jakimkolwiek kodem. bmad-sprint-planning zadaje całemu planowi jedno pytanie: czy deweloper może zaimplementować te historyjki bez wymyślania decyzji, których nic nie zapisuje? Odpowiada PASS, CONCERNS albo FAIL. Przy PASS generuje sprint-status.yaml, który śledzi każdą historyjkę. W trakcie epika wygląda tak:

    development_status:
      epic-1: in-progress
      1-1-workspace-budget-setting: done
      1-2-threshold-check: ready-for-dev
      1-3-alert-email-and-log: backlog
      epic-1-retrospective: optional

  5. Buduj po jednej historyjce. bmad-build rozpoznaje historyjkę z epika, raz kompiluje epic-1-context.md z dokumentów planistycznych i zapisuje spec-1-2-threshold-check.md. Historyjka 1-2 niczego nie wysyła, ale decyduje, kiedy maile wychodzą, więc spodziewaj się ścieżki dispatch, specyfikacji z macierzą wejść i wyjść oraz otwartych pytań w punkcie kontrolnym.

    W punkcie kontrolnym wybierz Approve and stop, jeśli chcesz implementacji w nowej sesji, albo Approve and continue, żeby iść dalej. Po zatwierdzeniu wszystko wewnątrz <frozen-after-approval> (intencja, granice i macierz wejść i wyjść) jest zablokowane i tylko ty możesz to zmienić.

  6. Przejrzyj i przekaż dalej. Build kończy warstwami review, oznacza specyfikację jako done, przesuwa historyjkę na review i tworzy lokalny commit. Historyjkę zamyka (done) dopiero bmad-code-review. Uruchom bmad-walkthrough, żeby dostać prowadzony przegląd dla człowieka, a potem bmad-code-review dla każdej historyjki: ustawia jej status done, gdy nie zostają żadne nierozwiązane uwagi o wadze high ani medium. Jeśli zespół robi review w pull requeście, ustaw done w sprint-status.yaml ręcznie po scaleniu pull requesta.

  7. Zamknij epik dowodami. Gdy wszystkie trzy historyjki mają status done, uruchom retrospektywę.

    Werdykt to accepted, accepted-with-open-items albo rejected. Każda historyjka bez statusu done wymusza rejected, chyba że człowiek to nadpisze.

Przy mniejszym zakresie pomiń PRD: bmad-spec skraca brief do _bmad-output/specs/spec-<slug>/SPEC.md i opcjonalnego stories.yaml, które bmad-build przyjmuje razem z identyfikatorem historyjki. Nie mieszaj obu ścieżek w jednym epiku.

Dopasuj bmad-build do swojego repozytorium

Dział zatytułowany „Dopasuj bmad-build do swojego repozytorium”

Nadpisania zespołu leżą w _bmad/custom/, którego instalator nigdy nie rusza. Listy są dopisywane do wartości domyślnych, a wartości tekstowe (stringi) je zastępują. Ten plik sprawia, że każda budowa ładuje konwencje testowe i instrukcje dla agenta, oraz opisuje przekazanie do pull requesta:

# _bmad/custom/bmad-build.toml — w repozytorium, dotyczy całego zespołu
[workflow]
persistent_facts = [
  "file:AGENTS.md",
  "file:docs/testing.md",
]
on_complete = "Print the exact gh pr create command for this branch, with the spec path in the body. Do not run it."

Osobiste preferencje, na przykład otwieranie każdej ukończonej specyfikacji w edytorze, trafiają do _bmad/custom/bmad-build.user.toml. Uruchom bmad-customize, żeby tworzyć nadpisania interaktywnie; zna każde pole, które da się dostosować.

Żeby agent implementujący nie edytował planu, zablokuj zapisy do folderu planistycznego tylko w sesjach budowy. Sesje planistyczne (bmad-prd, bmad-architecture, bmad-create-epics-and-stories, bmad-ux) i bmad-correct-course zapisują do tego folderu, więc blokada dla całego zespołu w .claude/settings.json by je zepsuła. W Claude Code uruchamiaj każdą sesję budowy w katalogu głównym repozytorium (od niego liczona jest ścieżka ./) z regułą w wierszu poleceń; reguła Edit obejmuje każde wbudowane narzędzie do edycji plików:

Okno terminala
claude --disallowedTools "Edit(./_bmad-output/planning-artifacts/**)"

Reguła blokuje narzędzia edycji, ale nie zapisy przez powłokę, takie jak sed czy echo, więc to reguła CODEOWNERS poniżej jest bramką egzekwującą dla każdego narzędzia, nie tylko dla Codeksa i Cursora. Zostaw implementation-artifacts/ z prawem zapisu, bo bmad-build aktualizuje własną specyfikację i sprint-status.yaml.

W każdym narzędziu wymuś tę granicę na etapie review regułą CODEOWNERS dla _bmad-output/planning-artifacts/, tak jak opisano w uprawnieniach i sandboksach.

Jak zweryfikować wynik BMAD bez czytania każdej linii?

Dział zatytułowany „Jak zweryfikować wynik BMAD bez czytania każdej linii?”

Markdown sam niczego nie dowodzi, więc przypisz każdej bramce właściciela:

BramkaCzego dowodziCzego nie dowodziZatwierdza
PRD z listą założeńZachowanie, którego chce biznes, jest spisaneŻe to właściwy produktWłaściciel produktu
Decyzje architektoniczneHistoryjki nie będą sobie przeczyć we wspólnych kwestiachŻe kod się ich trzymaTech lead
Bramka gotowości (bmad-sprint-planning)Każda historyjka prowadzi do wymagania i z powrotemŻe wymagania są poprawneTech lead
Punkt kontrolny specyfikacji w bmad-buildMacierz wejść i wyjść oraz kryteria akceptacji opisują historyjkęŻe kod je spełniaInżynier odpowiedzialny za historyjkę
Audyt testów macierzy (krok 3 budowy)Każdy wiersz macierzy ma test, który się uruchomił i przeszedłZachowanie spoza macierzyCI ponownie uruchamia testy
Warstwy review i log triażuUwagi zostały sprawdzone, z werdyktem i dowodem dla każdejŻe niczego nie przeoczonoInżynier, potem recenzent PR
Code review (bmad-code-review) → historyjka doneHistoryjka nie ma nierozwiązanych uwag o wadze high ani mediumŻe recenzenci szukali we właściwych miejscachInżynier odpowiedzialny za historyjkę
Werdykt retrospektywyEpik spełnił kryteria akceptacji, ze źródłamiDługoterminowe zachowanie na produkcjiWłaściciel produktu

Większość dowodzenia robią dwie części bmad-build. Audyt testów macierzy liczy test, który istnieje, ale się nie uruchomił, jako brakujący, i zabrania poprawiania oczekiwania pod kod; wiersz niezgodny z kodem odsyła agenta do ciebie. Triaż review zapisuje każdą uwagę w sekcji ## Review Triage Log specyfikacji z werdyktem (high, medium, low, false albo maybe-false) i dowodem, więc recenzent widzi, co odrzucono i dlaczego, a nie tylko, co poprawiono.

Żadna z nich nie zastępuje CI. Pull request zawiera ścieżkę specyfikacji, mapowanie wierszy macierzy na testy i zielony przebieg testów, czyli pakiet dowodów, który recenzent czyta zamiast całego diffa. Zapisuj kryteria jako wykonywalne kryteria akceptacji, stosuj ochronę wyroczni i przeglądaj pull request od agenta, otwierając kod tylko tam, gdzie wiersz macierzy nie ma testu albo plik leży poza mapą kodu.

Kiedy narzut ról w BMAD się zwraca?

Dział zatytułowany „Kiedy narzut ról w BMAD się zwraca?”

BMAD kosztuje cię trzy rzeczy. Kontekst: claude plugin details mierzy plugin na ~1676 tokenów w każdej sesji, a bmad-toolbox@bmad dokłada ~975. Według naszego własnego pomiaru na wersji 6.12.0 (2026-09-26) opisy 29 skilli z instalacji npm to łącznie około 8000 znaków. Dokumenty: zaplanowana funkcja daje PRD, dokument architektury, epics.md i jedną specyfikację na historyjkę, a każdy z nich musi przeczytać człowiek. Zmienność: BMAD był kilka razy przebudowywany (polecenia *agent w v4, skille w v6, teraz ścieżka pluginów na main), więc aktualizacje wymagają osobnego pull requesta.

Role są warte tego kosztu, gdy decyzja podjęta przy planowaniu inaczej zginęłaby przed implementacją. Zdecyduj na podstawie tej tabeli:

Twoja sytuacjaUżyjDlaczego
Praca produktowa z właścicielem produktu, kilkoma epikami i przekazaniami między ludźmiŚcieżka planistyczna BMADPRD, architektura i bramka gotowości przenoszą decyzje do agenta, który pisze kod
Zespół, który już pracuje w Scrumie i chce historyjek, statusu sprintu i retrospektyw w repozytoriumBMADJego artefakty odpowiadają ceremoniom, które już prowadzisz; zobacz zwinne workflow z agentami
Strumień błędów i małych funkcji w działającym produkcieSam bmad-build albo OpenSpecŚcieżka one-shot utrzymuje małe zmiany tanimi; OpenSpec dodatkowo prowadzi żywą specyfikację systemu
Nowa usługa lub funkcja, która potrzebuje śladu z bramkami na każdym etapieSpec KitEtapy constitution, clarify i analyze z jawnymi bramkami
Samodzielny deweloper, którego problemem jest pomijanie testów przez agenta, a nie gubione wymaganiaSuperpowersDyscyplina na poziomie zadania, mniej stałego kontekstu i bez przekazań między personami
Poprawka jednej linii, literówka albo podbicie zależnościBez frameworkaOd 6.12.0 bmad-build nie uruchamia się sam przy formatowaniu, operacjach git ani interaktywnych edycjach

Praktyczna zasada dla tech leada: wprowadzaj ścieżkę planistyczną tylko wtedy, gdy co najmniej dwie różne osoby odpowiadają za „co” i za „jak”. Gdy jeden deweloper odpowiada za oba, persony rozmawiają same ze sobą, a sam bmad-build daje dobór ścieżki i review bez przekazań. Wszystkie opcje obok siebie znajdziesz w porównaniu frameworków spec-driven.

Co się psuje, gdy uruchamiasz BMAD w prawdziwym zespole?

Dział zatytułowany „Co się psuje, gdy uruchamiasz BMAD w prawdziwym zespole?”

bmad-build zatrzymuje się przy aktywacji. Objaw: skill zgłasza nieudane polecenie uv run … render_skill.py i staje. Brakuje uv albo nie ma go w PATH agenta. Naprawa: zainstaluj uv, uruchom sesję agenta od nowa, żeby odczytała nowy PATH, i uruchom skill ponownie. Nie proś agenta o bezpośrednie uruchomienie workflow: niewyrenderowane pliki kroków wciąż zawierają placeholdery szablonu.

Stare nazwy skilli nic nie robią. Objaw: po świeżej instalacji /bmad-quick-dev albo /bmad-create-prd są nieznane. Od 6.12.0 przestarzałe shimy są opcjonalne. Naprawa: używaj bmad-build i bmad-prd albo zainstaluj ponownie z --shims na czas migracji.

Review prosi o ręczne wklejanie promptów. Objaw: build zapisuje prompty recenzentów w implementation-artifacts/ i się zatrzymuje. Środowisko nie mogło uruchomić subagentów. Naprawa: uruchom każdy prompt w osobnej sesji i wklej wyniki z powrotem albo uruchom budowę tam, gdzie subagenci są dostępni (mają ich zarówno Claude Code, jak i Codex).

Każde review coś znajduje. Objaw: trywialna zmiana wraca z kilkoma uwagami. Recenzent Blind Hunter musi zgłosić minimalną liczbę problemów, zależną od rozmiaru diffa; uwagi odrzuca się w triażu. Naprawa: czytaj log triażu i sprawdzaj, czy każdy werdykt false podaje dowód.

Agent zmienia plan pod swój kod. Objaw: commit historyjki zmienia PRD, architekturę albo zamrożony blok specyfikacji, a testy przechodzą. Naprawa: uruchamiaj sesje budowy z opisaną wyżej regułą --disallowedTools, dodaj wpis w CODEOWNERS i wymagaj, żeby każda zmiana w planning-artifacts/ przechodziła przez bmad-correct-course w sesji planistycznej z prawem zapisu, który tworzy propozycję zmiany w sprincie zamiast cichej edycji.

Dokumenty planistyczne rozjeżdżają się po epiku. Objaw: pół roku później PRD opisuje funkcję, która od tamtej pory się zmieniła; dokumenty BMAD są per funkcja. Naprawa: traktuj retrospektywę jako koniec życia PRD, a bieżące zachowanie trzymaj w testach i żywej specyfikacji (spec-driven development).

Dwóch deweloperów uruchamia dwa różne BMAD-y. Objaw: agent jednej osoby proponuje skille, których drugi nie ma, bo ktoś zainstalował plugin z main. Naprawa: przypnij jedną wersję npm i zapisz ją w AGENTS.md.

Dokąd dalej z BMAD

Dział zatytułowany „Dokąd dalej z BMAD”
Porównanie frameworków pracy z agentami BMAD obok wszystkich innych frameworków, z kosztami kontekstu i miejscem każdego z nich.
Porównanie frameworków spec-driven Spec Kit, OpenSpec, BMAD i Superpowers na tej samej funkcji.
Zwinne workflow z agentami Planuj sprinty pod przepustowość review i przynoś dane o przepływie na retrospektywę.
Wykonywalne kryteria akceptacji Zamień każde kryterium Given/When/Then w padający test przed budową.
OpenSpec Lżejszy wybór dla strumienia zmian w istniejącym systemie, z żywą specyfikacją.
Pakiet dowodów Co musi zawierać pull request, żeby recenzent mógł mu zaufać bez czytania każdej linii.

Autor:

Zobacz co nowego na platformie.

Polityka prywatności Regulamin Ustawienia cookie