mirror of
https://github.com/bmad-code-org/BMAD-METHOD.git
synced 2026-08-28 19:20:41 +08:00
Rename Quick Dev to Build (#2651)
* feat(bmm): rename quick dev to build * fix: address build rename review findings * fix: clarify deprecated build shims * fix: offer legacy customization migration
This commit is contained in:
Alex Verkhovsky
@@ -90,7 +90,7 @@
|
||||
"./src/bmm-skills/3-solutioning/bmad-generate-project-context",
|
||||
"./src/bmm-skills/4-implementation/bmad-agent-dev",
|
||||
"./src/bmm-skills/4-implementation/bmad-dev-story",
|
||||
"./src/bmm-skills/4-implementation/bmad-quick-dev",
|
||||
"./src/bmm-skills/4-implementation/bmad-build",
|
||||
"./src/bmm-skills/4-implementation/bmad-checkpoint-preview",
|
||||
"./src/bmm-skills/4-implementation/bmad-sprint-planning",
|
||||
"./src/bmm-skills/4-implementation/bmad-sprint-status",
|
||||
@@ -98,7 +98,8 @@
|
||||
"./src/bmm-skills/4-implementation/bmad-create-story",
|
||||
"./src/bmm-skills/4-implementation/bmad-correct-course",
|
||||
"./src/bmm-skills/4-implementation/bmad-retrospective",
|
||||
"./src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests"
|
||||
"./src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests",
|
||||
"./src/bmm-skills/v6-shims/bmad-quick-dev"
|
||||
]
|
||||
}
|
||||
]
|
||||
|
||||
@@ -148,7 +148,7 @@ your-project/
|
||||
| ----------------- | ----------------------------- |
|
||||
| **Index/Landing** | `core-concepts/index.md` |
|
||||
| **Concept** | `what-are-agents.md` |
|
||||
| **Feature** | `quick-dev.md` |
|
||||
| **Feature** | `build.md` |
|
||||
| **Philosophy** | `why-solutioning-matters.md` |
|
||||
| **FAQ** | `established-projects-faq.md` |
|
||||
|
||||
|
||||
@@ -148,7 +148,7 @@ váš-projekt/
|
||||
| ----------------- | ----------------------------- |
|
||||
| **Úvodní stránka** | `core-concepts/index.md` |
|
||||
| **Koncept** | `what-are-agents.md` |
|
||||
| **Funkce** | `quick-dev.md` |
|
||||
| **Funkce** | `build.md` |
|
||||
| **Filosofie** | `why-solutioning-matters.md` |
|
||||
| **FAQ** | `established-projects-faq.md` |
|
||||
|
||||
|
||||
@@ -1,19 +1,19 @@
|
||||
---
|
||||
title: "Quick Dev"
|
||||
title: "Build"
|
||||
description: Snižte tření human-in-the-loop bez ztráty kontrolních bodů chránících kvalitu výstupu
|
||||
sidebar:
|
||||
order: 6
|
||||
---
|
||||
|
||||
`bmad-quick-dev` je standardní implementační workflow pro veškerou vývojovou práci. Přijímá vše od volně formulovaného záměru nebo issue po plně naplánovanou story a vytváří změny kódu s minimem bezpečných human-in-the-loop kroků.
|
||||
`bmad-build` je standardní implementační workflow pro veškerou vývojovou práci. Přijímá vše od volně formulovaného záměru nebo issue po plně naplánovanou story a vytváří změny kódu s minimem bezpečných human-in-the-loop kroků.
|
||||
|
||||
Upstream plánování je volitelné a jeho hloubka se liší. Jasná změna může vstoupit přímo; větší iniciativa může přinést PRD, UX, architekturu, epicy, stories, kontrolu připravenosti a sprint plán. Tyto artefakty posilují kontext, nevybírají jiný vývojový workflow.
|
||||
|
||||
Když do Quick Dev vstoupí naplánovaná story, zůstává zdrojem produktového kontextu a akceptačních kritérií. Quick Dev vytvoří vlastní záznam provedení aktuálního běhu, aby implementační rozhodnutí a nálezy revize zůstaly dohledatelné, aniž by story nahrazoval.
|
||||
Když do Build vstoupí naplánovaná story, zůstává zdrojem produktového kontextu a akceptačních kritérií. Build vytvoří vlastní záznam provedení aktuálního běhu, aby implementační rozhodnutí a nálezy revize zůstaly dohledatelné, aniž by story nahrazoval.
|
||||
|
||||
Umožňuje modelu běžet déle mezi kontrolními body a poté přivede člověka zpět pouze tehdy, když úkol nemůže bezpečně pokračovat bez lidského úsudku nebo když je čas zkontrolovat konečný výsledek.
|
||||
|
||||
|
||||
|
||||
|
||||
## Proč to existuje
|
||||
|
||||
@@ -21,7 +21,7 @@ Human-in-the-loop kroky jsou nutné a nákladné.
|
||||
|
||||
Současné LLM stále selhávají předvídatelnými způsoby: chybně čtou záměr, vyplňují mezery sebevědomými odhady, odchylují se k nesouvisející práci a generují šumový výstup revize. Současně neustálá lidská intervence limituje rychlost vývoje. Lidská pozornost je úzké hrdlo.
|
||||
|
||||
`bmad-quick-dev` přenastavuje tento kompromis. Důvěřuje modelu, aby běžel bez dozoru delší úseky, ale pouze poté, co workflow vytvořil dostatečně silnou hranici, aby to bylo bezpečné.
|
||||
`bmad-build` přenastavuje tento kompromis. Důvěřuje modelu, aby běžel bez dozoru delší úseky, ale pouze poté, co workflow vytvořil dostatečně silnou hranici, aby to bylo bezpečné.
|
||||
|
||||
## Základní design
|
||||
|
||||
@@ -57,7 +57,7 @@ Interview o záměru je human-in-the-loop, ale není to stejný druh přerušen
|
||||
|
||||
- **Řešení mezer v záměru** — vstoupení zpět, když revize prokáže, že workflow nemohl bezpečně odvodit, co bylo myšleno
|
||||
|
||||
Vše ostatní je kandidátem na delší autonomní provádění. Tento kompromis je záměrný. Starší vzory věnují více lidské pozornosti nepřetržitému dozoru. Quick Dev věnuje více důvěry modelu, ale šetří lidskou pozornost pro momenty, kde má lidské uvažování nejvyšší páku.
|
||||
Vše ostatní je kandidátem na delší autonomní provádění. Tento kompromis je záměrný. Starší vzory věnují více lidské pozornosti nepřetržitému dozoru. Build věnuje více důvěry modelu, ale šetří lidskou pozornost pro momenty, kde má lidské uvažování nejvyšší páku.
|
||||
|
||||
## Proč systém revize záleží
|
||||
|
||||
@@ -70,7 +70,7 @@ Agentní revize často selhávají dvěma způsoby:
|
||||
- Generují příliš mnoho nálezů, čímž nutí člověka prosévat šum.
|
||||
- Vychýlí aktuální změnu odhalením nesouvisejících problémů a přemění každý běh na ad-hoc úklidový projekt.
|
||||
|
||||
Quick Dev řeší obojí tím, že s revizí zachází jako s triáží.
|
||||
Build řeší obojí tím, že s revizí zachází jako s triáží.
|
||||
|
||||
Některé nálezy patří k aktuální změně. Některé ne. Pokud je nález náhodný spíše než kauzálně vázaný na aktuální práci, workflow ho může odložit místo nucení člověka ho okamžitě řešit. To udržuje běh zaměřený a zabraňuje náhodným tangentám ve spotřebování rozpočtu pozornosti.
|
||||
|
||||
@@ -29,7 +29,7 @@ Nedělejte si starosti — můžete to udělat kdykoli. Můžete to udělat i b
|
||||
|
||||
### Jak funguje implementace v existujících projektech?
|
||||
|
||||
Spusťte `bmad-quick-dev`, stejně jako u nového vývoje. Umí:
|
||||
Spusťte `bmad-build`, stejně jako u nového vývoje. Umí:
|
||||
|
||||
- Automaticky detekovat váš existující stack
|
||||
- Analyzovat existující vzory kódu
|
||||
@@ -40,7 +40,7 @@ Pro jasnou změnu můžete vstoupit přímo; pro větší práci předejte napl
|
||||
|
||||
### Co když můj existující kód nedodržuje osvědčené postupy?
|
||||
|
||||
Quick Dev detekuje vaše konvence a zeptá se: „Mám dodržovat tyto existující konvence?“ Rozhodujete vy:
|
||||
Build detekuje vaše konvence a zeptá se: „Mám dodržovat tyto existující konvence?“ Rozhodujete vy:
|
||||
|
||||
- **Ano** → Zachovat konzistenci se současnou kódovou bází
|
||||
- **Ne** → Zavést nové standardy (zdokumentujte proč ve specifikaci)
|
||||
|
||||
@@ -23,7 +23,7 @@ Každý implementační workflow automaticky načítá `project-context.md`, pok
|
||||
**Načítán těmito workflow:**
|
||||
- `bmad-architecture` — respektuje technické preference během solutioningu
|
||||
- `bmad-code-review` — validuje proti standardům projektu
|
||||
- `bmad-quick-dev` — aplikuje vzory při plánování a implementaci přímých záměrů i stories
|
||||
- `bmad-build` — aplikuje vzory při plánování a implementaci přímých záměrů i stories
|
||||
- `bmad-sprint-planning`, `bmad-retrospective`, `bmad-correct-course` — poskytuje celkový kontext projektu
|
||||
|
||||
## Kdy ho vytvořit
|
||||
@@ -35,7 +35,7 @@ Soubor `project-context.md` je užitečný v jakékoli fázi projektu:
|
||||
| **Nový projekt, před architekturou** | Ručně, před `bmad-architecture` | Dokumentujte vaše technické preference, aby je architekt respektoval |
|
||||
| **Nový projekt, po architektuře** | Přes `bmad-generate-project-context` nebo ručně | Zachyťte architektonická rozhodnutí pro implementační agenty |
|
||||
| **Existující projekt** | Přes `bmad-generate-project-context` | Objevte existující vzory, aby agenti dodržovali zavedené konvence |
|
||||
| **Přímý vstup do implementace** | Před nebo během `bmad-quick-dev` | Zajistěte, aby implementace bez upstream plánování respektovala vaše vzory |
|
||||
| **Přímý vstup do implementace** | Před nebo během `bmad-build` | Zajistěte, aby implementace bez upstream plánování respektovala vaše vzory |
|
||||
|
||||
:::tip[Doporučeno]
|
||||
Pro nové projekty ho vytvořte ručně před architekturou, pokud máte silné technické preference. Jinak ho vygenerujte po architektuře pro zachycení těchto rozhodnutí.
|
||||
|
||||
@@ -58,7 +58,7 @@ Toto zabraňuje:
|
||||
| Více epiců nebo mezisystémová rozhodnutí | Potřebné pro sladění implementace |
|
||||
| Regulovaná, riziková nebo enterprise iniciativa | Řiďte se požadovanou governance; solutioning je obvykle povinný |
|
||||
|
||||
Solutioning mění kontext dostupný pro `bmad-quick-dev`, nikoli implementační workflow.
|
||||
Solutioning mění kontext dostupný pro `bmad-build`, nikoli implementační workflow.
|
||||
|
||||
:::tip[Pravidlo palce]
|
||||
Pokud máte více epiců, které by mohly být implementovány různými agenty, potřebujete solutioning.
|
||||
|
||||
@@ -77,12 +77,12 @@ BMad-Help se také **automaticky spouští na konci každého workflow** a posky
|
||||
|
||||
### Volba hloubky plánování
|
||||
|
||||
Veškerá implementace používá `bmad-quick-dev`; rozsah určuje, jaký kontext připravíte předem:
|
||||
Veškerá implementace používá `bmad-build`; rozsah určuje, jaký kontext připravíte předem:
|
||||
|
||||
| Rozsah | Doporučený přístup |
|
||||
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **Jasné aktualizace či doplnění** | Vstupte přímo do `bmad-quick-dev` s požadavkem, issue nebo existující specifikací. |
|
||||
| **Velké změny či doplnění** | Připravte užitečné PRD, UX, architekturu, epic, story a sprint kontext a pak předejte vybranou práci do `bmad-quick-dev`. |
|
||||
| **Jasné aktualizace či doplnění** | Vstupte přímo do `bmad-build` s požadavkem, issue nebo existující specifikací. |
|
||||
| **Velké změny či doplnění** | Připravte užitečné PRD, UX, architekturu, epic, story a sprint kontext a pak předejte vybranou práci do `bmad-build`. |
|
||||
|
||||
### Během tvorby PRD
|
||||
|
||||
|
||||
@@ -82,7 +82,7 @@ https://bmad-code-org.github.io/BMAD-METHOD/llms-full.txt
|
||||
:::note[Příklad]
|
||||
**O:** „Řekni mi nejrychlejší způsob, jak něco vytvořit s BMad“
|
||||
|
||||
**A:** Spusťte `bmad-quick-dev`. Předejte přímý záměr, issue, specifikaci nebo naplánovanou story; workflow využije dostupný kontext a zvolí potřebnou hloubku upřesnění, plánování, implementace a revize.
|
||||
**A:** Spusťte `bmad-build`. Předejte přímý záměr, issue, specifikaci nebo naplánovanou story; workflow využije dostupný kontext a zvolí potřebnou hloubku upřesnění, plánování, implementace a revize.
|
||||
:::
|
||||
|
||||
## Co získáte
|
||||
|
||||
@@ -118,7 +118,7 @@ Soubor `project-context.md`, který:
|
||||
- **Zaměřte se na neočividné** — Dokumentujte vzory, které agenti mohou přehlédnout (např. „Použijte JSDoc na každé veřejné třídě“), ne univerzální postupy jako „používejte smysluplné názvy proměnných.“
|
||||
- **Udržujte to stručné** — Tento soubor načítá každý implementační workflow. Dlouhé soubory plýtvají kontextem. Vylučte obsah, který platí pouze pro úzký rozsah nebo specifické stories.
|
||||
- **Aktualizujte dle potřeby** — Upravte ručně, když se vzory změní, nebo přegenerujte po významných změnách architektury.
|
||||
- Podporuje stejný `bmad-quick-dev` loop při přímém vstupu i po rozsáhlém plánování.
|
||||
- Podporuje stejný `bmad-build` loop při přímém vstupu i po rozsáhlém plánování.
|
||||
:::
|
||||
|
||||
## Další kroky
|
||||
|
||||
@@ -5,7 +5,7 @@ sidebar:
|
||||
order: 5
|
||||
---
|
||||
|
||||
Opravy chyb, refaktoringy a malé cílené změny mohou vstoupit do **Quick Dev** přímo s minimem upstream plánování. Jde o stejný implementační workflow jako pro plně naplánované stories.
|
||||
Opravy chyb, refaktoringy a malé cílené změny mohou vstoupit do **Build** přímo s minimem upstream plánování. Jde o stejný implementační workflow jako pro plně naplánované stories.
|
||||
|
||||
## Kdy to použít
|
||||
|
||||
@@ -27,28 +27,28 @@ Otevřete **novou chatovací relaci** ve vašem AI IDE. Opětovné použití rel
|
||||
|
||||
### 2. Zadejte svůj záměr
|
||||
|
||||
Quick Dev přijímá volně formulovaný záměr — před, s nebo po vyvolání. Příklady:
|
||||
Build přijímá volně formulovaný záměr — před, s nebo po vyvolání. Příklady:
|
||||
|
||||
```text
|
||||
run quick-dev — Fix the login validation bug that allows empty passwords.
|
||||
run build — Fix the login validation bug that allows empty passwords.
|
||||
```
|
||||
|
||||
```text
|
||||
run quick-dev — fix https://github.com/org/repo/issues/42
|
||||
run build — fix https://github.com/org/repo/issues/42
|
||||
```
|
||||
|
||||
```text
|
||||
run quick-dev — implement the intent in _bmad-output/implementation-artifacts/my-intent.md
|
||||
run build — implement the intent in _bmad-output/implementation-artifacts/my-intent.md
|
||||
```
|
||||
|
||||
```text
|
||||
I think the problem is in the auth middleware, it's not checking token expiry.
|
||||
Let me look at it... yeah, src/auth/middleware.ts line 47 skips
|
||||
the exp check entirely. run quick-dev
|
||||
the exp check entirely. run build
|
||||
```
|
||||
|
||||
```text
|
||||
run quick-dev
|
||||
run build
|
||||
> What would you like to do?
|
||||
Refactor UserService to use async/await instead of callbacks.
|
||||
```
|
||||
@@ -57,19 +57,19 @@ Prostý text, cesty k souborům, GitHub issue URL, odkazy na bug tracker — cok
|
||||
|
||||
### 3. Odpovězte na otázky a schvalte
|
||||
|
||||
Quick Dev se může zeptat na upřesňující otázky nebo prezentovat krátkou specifikaci ke schválení před implementací. Odpovězte na otázky a schvalte, až budete s plánem spokojeni.
|
||||
Build se může zeptat na upřesňující otázky nebo prezentovat krátkou specifikaci ke schválení před implementací. Odpovězte na otázky a schvalte, až budete s plánem spokojeni.
|
||||
|
||||
### 4. Zkontrolujte a pushněte
|
||||
|
||||
Quick Dev implementuje změnu, zreviduje svou práci, opraví problémy a commitne lokálně. Když je hotov, otevře dotčené soubory ve vašem editoru.
|
||||
Build implementuje změnu, zreviduje svou práci, opraví problémy a commitne lokálně. Když je hotov, otevře dotčené soubory ve vašem editoru.
|
||||
|
||||
- Projděte diff a potvrďte, že změna odpovídá vašemu záměru
|
||||
- Pokud něco nevypadá dobře, řekněte agentovi, co opravit — může iterovat ve stejné relaci
|
||||
|
||||
Až budete spokojeni, pushněte commit. Quick Dev nabídne push a vytvoření PR za vás.
|
||||
Až budete spokojeni, pushněte commit. Build nabídne push a vytvoření PR za vás.
|
||||
|
||||
:::caution[Pokud se něco rozbije]
|
||||
Pokud pushnutá změna způsobí neočekávané problémy, použijte `git revert HEAD` pro čisté vrácení posledního commitu. Poté začněte nový chat a spusťte Quick Dev znovu s jiným přístupem.
|
||||
Pokud pushnutá změna způsobí neočekávané problémy, použijte `git revert HEAD` pro čisté vrácení posledního commitu. Poté začněte nový chat a spusťte Build znovu s jiným přístupem.
|
||||
:::
|
||||
|
||||
## Co získáte
|
||||
@@ -80,16 +80,16 @@ Pokud pushnutá změna způsobí neočekávané problémy, použijte `git revert
|
||||
|
||||
## Odložená práce
|
||||
|
||||
Quick Dev udržuje každý běh zaměřený na jeden cíl. Pokud váš požadavek obsahuje více nezávislých cílů, nebo pokud revize odhalí předchozí problémy nesouvisející s vaší změnou, Quick Dev je odloží do souboru (`deferred-work.md` ve vašem adresáři implementačních artefaktů) místo toho, aby se pokusil vše řešit najednou.
|
||||
Build udržuje každý běh zaměřený na jeden cíl. Pokud váš požadavek obsahuje více nezávislých cílů, nebo pokud revize odhalí předchozí problémy nesouvisející s vaší změnou, Build je odloží do souboru (`deferred-work.md` ve vašem adresáři implementačních artefaktů) místo toho, aby se pokusil vše řešit najednou.
|
||||
|
||||
Zkontrolujte tento soubor po běhu — je to váš backlog věcí, ke kterým se vrátit. Každou odloženou položku lze zadat do nového běhu Quick Dev později.
|
||||
Zkontrolujte tento soubor po běhu — je to váš backlog věcí, ke kterým se vrátit. Každou odloženou položku lze zadat do nového běhu Build později.
|
||||
|
||||
## Kdy přidat formální plánování
|
||||
|
||||
Před spuštěním stejného Quick Dev loopu zvažte přidání PRD, UX, architektury nebo plánování stories, když:
|
||||
Před spuštěním stejného Build loopu zvažte přidání PRD, UX, architektury nebo plánování stories, když:
|
||||
|
||||
- Změna ovlivňuje více systémů nebo vyžaduje koordinované aktualizace napříč mnoha soubory
|
||||
- Nejste si jisti rozsahem a potřebujete nejprve zjišťování požadavků
|
||||
- Potřebujete dokumentaci nebo architektonická rozhodnutí zaznamenaná pro tým
|
||||
|
||||
Podívejte se na [Quick Dev](../explanation/quick-dev.md), kde je vysvětleno, jak se přímý záměr a naplánovaná práce sbíhají do stejného implementačního loopu.
|
||||
Podívejte se na [Build](../explanation/build.md), kde je vysvětleno, jak se přímý záměr a naplánovaná práce sbíhají do stejného implementačního loopu.
|
||||
|
||||
@@ -20,7 +20,7 @@ Tato stránka uvádí výchozí BMM (Agile suite) agenty, kteří se instalují
|
||||
| Analyst (Mary) | `bmad-analyst` | `BP`, `MR`, `DR`, `TR`, `CB`, `WB`, `DP` | Brainstorm, průzkum trhu, doménový výzkum, technický výzkum, tvorba briefu, PRFAQ výzva, dokumentace projektu |
|
||||
| Product Manager (John) | `bmad-pm` | `CP`, `VP`, `EP`, `CE`, `IR`, `CC` | Tvorba/validace/editace PRD, tvorba epiců a stories, připravenost implementace, korekce kurzu |
|
||||
| Architect (Winston) | `bmad-architect` | `CA`, `IR` | Tvorba architektury, připravenost implementace |
|
||||
| Developer (Amelia) | `bmad-agent-dev` | `QD`, `QA`, `CR`, `SP`, `ER` | Quick Dev, generování QA testů, revize kódu, plánování sprintu, retrospektiva epicu |
|
||||
| Developer (Amelia) | `bmad-agent-dev` | `BD`, `QA`, `CR`, `SP`, `ER` | Build, generování QA testů, revize kódu, plánování sprintu, retrospektiva epicu |
|
||||
| UX Designer (Sally) | `bmad-ux-designer` | `CU` | Tvorba UX designu |
|
||||
| Technical Writer (Paige) | `bmad-tech-writer` | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | Dokumentace projektu, psaní dokumentu, aktualizace standardů, generování Mermaid, validace dok., vysvětlení konceptu |
|
||||
|
||||
@@ -32,7 +32,7 @@ Spouštěče nabídky agentů používají dva různé typy vyvolání. Znalost
|
||||
|
||||
Většina spouštěčů načítá strukturovaný soubor workflow. Zadejte kód spouštěče a agent zahájí workflow a vyzve vás k zadání vstupu v každém kroku.
|
||||
|
||||
Příklady: `CP` (tvorba PRD), `CA` (tvorba architektury), `QD` (Quick Dev)
|
||||
Příklady: `CP` (tvorba PRD), `CA` (tvorba architektury), `BD` (Build)
|
||||
|
||||
### Konverzační spouštěče (vyžadují argumenty)
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ BMad nabízí dva způsoby zahájení práce a slouží k různým účelům.
|
||||
| Mechanismus | Jak se vyvolává | Co se stane |
|
||||
| --- | --- | --- |
|
||||
| **Skill** | Zadejte název skillu (např. `bmad-help`) ve vašem IDE | Přímo načte agenta, spustí workflow nebo provede úkol |
|
||||
| **Spouštěč nabídky agenta** | Nejprve načtěte agenta, pak zadejte krátký kód (např. `QD`) | Agent interpretuje kód a spustí odpovídající workflow, přičemž zůstává v charakteru |
|
||||
| **Spouštěč nabídky agenta** | Nejprve načtěte agenta, pak zadejte krátký kód (např. `BD`) | Agent interpretuje kód a spustí odpovídající workflow, přičemž zůstává v charakteru |
|
||||
|
||||
Spouštěče nabídky agentů vyžadují aktivní relaci agenta. Používejte skills, když víte, který workflow chcete. Používejte spouštěče, když již pracujete s agentem a chcete přepnout úkol bez opuštění konverzace.
|
||||
|
||||
@@ -97,7 +97,7 @@ Workflow skills spouštějí strukturovaný, vícekrokový proces bez předchoz
|
||||
| `bmad-architecture` | Návrh systémové architektury |
|
||||
| `bmad-create-epics-and-stories` | Vytvoření epiců a stories |
|
||||
| `bmad-code-review` | Spuštění revize kódu |
|
||||
| `bmad-quick-dev` | Implementace přímého záměru, issue, funkce, opravy nebo naplánované story |
|
||||
| `bmad-build` | Implementace přímého záměru, issue, funkce, opravy nebo naplánované story |
|
||||
|
||||
Viz [Mapa pracovních postupů](./workflow-map.md) pro kompletní referenci workflow organizovanou podle fází.
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ AI nástroje pro strukturovanou kreativitu, ideaci a inovace v rané fázi vývo
|
||||
|
||||
## Game Dev Studio
|
||||
|
||||
Strukturované workflow pro vývoj her adaptované pro Unity, Unreal, Godot a vlastní enginy. Podporuje hloubku plánování od rychlého prototypování po plnoscálovou produkci; implementace se sbíhá do Quick Dev.
|
||||
Strukturované workflow pro vývoj her adaptované pro Unity, Unreal, Godot a vlastní enginy. Podporuje hloubku plánování od rychlého prototypování po plnoscálovou produkci; implementace se sbíhá do Build.
|
||||
|
||||
- **Kód:** `gds`
|
||||
- **npm:** [`bmad-game-dev-studio`](https://www.npmjs.com/package/bmad-game-dev-studio)
|
||||
@@ -52,7 +52,7 @@ Strukturované workflow pro vývoj her adaptované pro Unity, Unreal, Godot a vl
|
||||
**Poskytuje:**
|
||||
|
||||
- Workflow pro generování Game Design Document (GDD)
|
||||
- Herní kontext a plánování pro standardní implementační loop Quick Dev
|
||||
- Herní kontext a plánování pro standardní implementační loop Build
|
||||
- Podporu narativního designu pro postavy, dialogy a budování světa
|
||||
- Pokrytí 21+ typů her s architektonickým vedením specifickým pro engine
|
||||
|
||||
|
||||
@@ -97,7 +97,7 @@ TEA také podporuje prioritizaci P0–P3 založenou na riziku a volitelné integ
|
||||
|
||||
Quinn workflow Automate se objevuje ve Fázi 4 (Implementace) mapy workflow BMad Method. Je navržen ke spuštění **po dokončení celého epicu** — jakmile jsou všechny stories v epicu implementovány a zrevidovány. Typická sekvence:
|
||||
|
||||
1. Pro každou story v epicu: implementace pomocí Quick Dev (`QD` / `bmad-quick-dev`), pak podle potřeby Code Review (`CR`)
|
||||
1. Pro každou story v epicu: implementace pomocí Build (`BD` / `bmad-build`), pak podle potřeby Code Review (`CR`)
|
||||
2. Po dokončení epicu: generování testů s Quinnem (`QA`) nebo TEA workflow Automate
|
||||
3. Spuštění retrospektivy (`bmad-retrospective`) pro zachycení získaných zkušeností
|
||||
|
||||
|
||||
@@ -52,11 +52,11 @@ Rozhodněte, jak to budovat, a rozložte práci na stories.
|
||||
|
||||
## Fáze 4: Implementace
|
||||
|
||||
Všechny implementační vstupy se sbíhají do `bmad-quick-dev`. Přijímá přímý záměr, issue, specifikaci nebo naplánovanou story a zvolí potřebnou míru upřesnění, plánování, implementace a revize.
|
||||
Všechny implementační vstupy se sbíhají do `bmad-build`. Přijímá přímý záměr, issue, specifikaci nebo naplánovanou story a zvolí potřebnou míru upřesnění, plánování, implementace a revize.
|
||||
|
||||
| Workflow | Účel | Produkuje |
|
||||
| -------------------------- | ------------------------------------------------------------------------ | -------------------------------- |
|
||||
| `bmad-quick-dev` | Převod přímého záměru nebo naplánované story na implementovaný a revidovaný kód | `spec-*.md` + kód |
|
||||
| `bmad-build` | Převod přímého záměru nebo naplánované story na implementovaný a revidovaný kód | `spec-*.md` + kód |
|
||||
| `bmad-sprint-planning` | Inicializace sledování (jednou na projekt pro sekvencování dev cyklu) | `sprint-status.yaml` |
|
||||
| `bmad-code-review` | Validace kvality implementace | Schváleno nebo požadovány změny |
|
||||
| `bmad-correct-course` | Řešení významných změn uprostřed sprintu | Aktualizovaný plán nebo přesměrování |
|
||||
@@ -65,7 +65,7 @@ Všechny implementační vstupy se sbíhají do `bmad-quick-dev`. Přijímá př
|
||||
|
||||
### Přímý a plánovaný vstup
|
||||
|
||||
Jasná práce může vstoupit do `bmad-quick-dev` přímo. Větší iniciativa může nejprve vytvořit PRD, UX, architekturu, epicy, stories, kontrolu připravenosti a sprint plán. Tyto artefakty přidávají kontext; nevybírají jiný implementační workflow.
|
||||
Jasná práce může vstoupit do `bmad-build` přímo. Větší iniciativa může nejprve vytvořit PRD, UX, architekturu, epicy, stories, kontrolu připravenosti a sprint plán. Tyto artefakty přidávají kontext; nevybírají jiný implementační workflow.
|
||||
|
||||
## Správa kontextu
|
||||
|
||||
|
||||
@@ -84,7 +84,7 @@ Hloubka plánování je flexibilní:
|
||||
| **Plné solutioning** | Koordinované, rizikové nebo mezisystémové iniciativy | PRD, UX, architektura, epicy, stories a sprint plán |
|
||||
|
||||
:::note
|
||||
Nejde o oddělené implementační cesty. Všechny vstupy se sbíhají do `bmad-quick-dev`; plánování pouze mění množství dostupného kontextu.
|
||||
Nejde o oddělené implementační cesty. Všechny vstupy se sbíhají do `bmad-build`; plánování pouze mění množství dostupného kontextu.
|
||||
:::
|
||||
|
||||
## Instalace
|
||||
@@ -176,13 +176,13 @@ Epicy a stories se nyní vytvářejí *po* architektuře. Tím vznikají kvalitn
|
||||
|
||||
Přejděte k implementaci s jakýmkoli dostupným kontextem: přímým požadavkem, issue, specifikací nebo plně naplánovanou story. **Každý workflow by měl běžet v novém chatu.**
|
||||
|
||||
U plánované práce spusťte `bmad-quick-dev` a určete vybranou story nebo položku sprintu, například: `Implementuj story 2.3 z _bmad-output/planning-artifacts/epics.md`.
|
||||
U plánované práce spusťte `bmad-build` a určete vybranou story nebo položku sprintu, například: `Implementuj story 2.3 z _bmad-output/planning-artifacts/epics.md`.
|
||||
|
||||
### Inicializace plánování sprintu (pro plánovanou práci)
|
||||
|
||||
Vyvolejte **Developer agenta** (`bmad-agent-dev`) a spusťte `bmad-sprint-planning` (`bmad-sprint-planning`). Tím se vytvoří `sprint-status.yaml` pro sledování všech epiců a stories.
|
||||
|
||||
Když Quick Dev v tomto souboru rozpozná vybranou story, během implementace ji přesune do stavu `in-progress` a po dokončení implementace do stavu `review`.
|
||||
Když Build v tomto souboru rozpozná vybranou story, během implementace ji přesune do stavu `in-progress` a po dokončení implementace do stavu `review`.
|
||||
|
||||
### Cyklus vývoje
|
||||
|
||||
@@ -190,10 +190,10 @@ Pro každou přímou změnu nebo naplánovanou story opakujte tento cyklus s nov
|
||||
|
||||
| Krok | Agent | Workflow | Příkaz | Účel |
|
||||
| ---- | ----- | -------------------- | -------------------------- | ---------------------------------- |
|
||||
| 1 | DEV | `bmad-quick-dev` | `bmad-quick-dev` | Upřesnění, plán, implementace, revize a prezentace |
|
||||
| 1 | DEV | `bmad-build` | `bmad-build` | Upřesnění, plán, implementace, revize a prezentace |
|
||||
| 2 | DEV | `bmad-code-review` | `bmad-code-review` | Dodatečná validace kvality *(doporučeno)* |
|
||||
|
||||
Revize v Quick Dev je součástí každého běhu. `bmad-code-review` je volitelná nezávislá validační vrstva v novém kontextu.
|
||||
Revize v Build je součástí každého běhu. `bmad-code-review` je volitelná nezávislá validační vrstva v novém kontextu.
|
||||
|
||||
Po dokončení všech stories v epicu vyvolejte **Developer agenta** (`bmad-agent-dev`) a spusťte `bmad-retrospective` (`bmad-retrospective`).
|
||||
|
||||
@@ -233,13 +233,13 @@ váš-projekt/
|
||||
| `bmad-create-epics-and-stories` | `bmad-create-epics-and-stories` | PM | Rozklad PRD na epicy |
|
||||
| `bmad-check-implementation-readiness` | `bmad-check-implementation-readiness` | Architect | Validace soudržnosti plánování |
|
||||
| `bmad-sprint-planning` | `bmad-sprint-planning` | DEV | Inicializace sledování sprintu |
|
||||
| `bmad-quick-dev` | `bmad-quick-dev` | DEV | Implementace záměru, issue, funkce, opravy nebo story |
|
||||
| `bmad-build` | `bmad-build` | DEV | Implementace záměru, issue, funkce, opravy nebo story |
|
||||
| `bmad-code-review` | `bmad-code-review` | DEV | Revize implementovaného kódu |
|
||||
|
||||
## Časté otázky
|
||||
|
||||
**Potřebuji vždy architekturu?**
|
||||
Ne. Architekturu použijte, když je třeba explicitně zachytit technická rozhodnutí nebo mezisystémová omezení. Jasná práce může vstoupit přímo do `bmad-quick-dev`; větší iniciativa přináší do stejného workflow plánovací artefakty.
|
||||
Ne. Architekturu použijte, když je třeba explicitně zachytit technická rozhodnutí nebo mezisystémová omezení. Jasná práce může vstoupit přímo do `bmad-build`; větší iniciativa přináší do stejného workflow plánovací artefakty.
|
||||
|
||||
**Mohu později změnit svůj plán?**
|
||||
Ano. Workflow `bmad-correct-course` (`bmad-correct-course`) řeší změny rozsahu během implementace.
|
||||
@@ -270,7 +270,7 @@ BMad-Help prozkoumá váš projekt, detekuje, co jste dokončili, a řekne vám
|
||||
:::tip[Zapamatujte si]
|
||||
- **Začněte s `bmad-help`** — Váš inteligentní průvodce, který zná váš projekt a možnosti
|
||||
- **Vždy používejte nové chaty** — Začněte nový chat pro každý workflow
|
||||
- **Hloubka plánování se liší** — přímý záměr i plně naplánované stories vstupují do `bmad-quick-dev`
|
||||
- **Hloubka plánování se liší** — přímý záměr i plně naplánované stories vstupují do `bmad-build`
|
||||
- **BMad-Help se spouští automaticky** — Každý workflow končí pokyny, co dělat dál
|
||||
:::
|
||||
|
||||
|
||||
@@ -1,19 +1,19 @@
|
||||
---
|
||||
title: "Quick Dev"
|
||||
title: "Build"
|
||||
description: Reduce human-in-the-loop friction without giving up the checkpoints that protect output quality
|
||||
sidebar:
|
||||
order: 7
|
||||
---
|
||||
|
||||
`bmad-quick-dev` is the canonical implementation workflow for all development work. It accepts anything from free-form intent or an issue to a fully planned story, and produces code changes with as few human-in-the-loop turns as safety allows.
|
||||
`bmad-build` is the canonical implementation workflow for all development work. It accepts anything from free-form intent or an issue to a fully planned story, and produces code changes with as few human-in-the-loop turns as safety allows.
|
||||
|
||||
Upstream planning remains optional and variable. A clear change can enter directly; a larger initiative can arrive with a PRD, UX design, architecture, epics, stories, readiness results, and sprint plan. Those artifacts strengthen the implementation context rather than selecting a different development workflow.
|
||||
|
||||
When a planned story enters Quick Dev, the story remains the upstream product and acceptance context. Quick Dev creates its own execution record for the current run so implementation decisions and review findings stay traceable without replacing the story.
|
||||
When a planned story enters Build, the story remains the upstream product and acceptance context. Build creates its own execution record for the current run so implementation decisions and review findings stay traceable without replacing the story.
|
||||
|
||||
It lets the model run longer between checkpoints, then brings the human back only when the task cannot safely continue without human judgment or when it is time to review the end result.
|
||||
|
||||
|
||||
|
||||
|
||||
## Why This Exists
|
||||
|
||||
@@ -21,7 +21,7 @@ Human-in-the-loop turns are necessary and expensive.
|
||||
|
||||
Current LLMs still fail in predictable ways: they misread intent, fill gaps with confident guesses, drift into unrelated work, and generate noisy review output. At the same time, constant human intervention limits development velocity. Human attention is the bottleneck.
|
||||
|
||||
`bmad-quick-dev` rebalances that tradeoff. It trusts the model to run unsupervised for longer stretches, but only after the workflow has created a strong enough boundary to make that safe.
|
||||
`bmad-build` rebalances that tradeoff. It trusts the model to run unsupervised for longer stretches, but only after the workflow has created a strong enough boundary to make that safe.
|
||||
|
||||
## The Core Design
|
||||
|
||||
@@ -57,7 +57,7 @@ The intent interview is human-in-the-loop, but it is not the same kind of interr
|
||||
|
||||
- **Intent-gap resolution** - stepping back in when review proves the workflow could not safely infer what was meant
|
||||
|
||||
Everything else is a candidate for longer autonomous execution. That tradeoff is deliberate. Older patterns spend more human attention on continuous supervision. Quick Dev spends more trust on the model, but saves human attention for the moments where human reasoning has the highest leverage.
|
||||
Everything else is a candidate for longer autonomous execution. That tradeoff is deliberate. Older patterns spend more human attention on continuous supervision. Build spends more trust on the model, but saves human attention for the moments where human reasoning has the highest leverage.
|
||||
|
||||
## Why the Review System Matters
|
||||
|
||||
@@ -70,7 +70,7 @@ Agentic reviews often go wrong in two ways:
|
||||
- They generate too many findings, forcing the human to sift through noise.
|
||||
- They derail the current change by surfacing unrelated issues and turning every run into an ad hoc cleanup project.
|
||||
|
||||
Quick Dev addresses both by treating review as triage.
|
||||
Build addresses both by treating review as triage.
|
||||
|
||||
Some findings belong to the current change. Some do not. If a finding is incidental rather than causally tied to the current work, the workflow can defer it instead of forcing the human to handle it immediately. That keeps the run focused and prevents random tangents from consuming the budget of attention.
|
||||
|
||||
@@ -11,11 +11,11 @@ sidebar:
|
||||
|
||||
## The Typical Flow
|
||||
|
||||
You run `bmad-quick-dev`. It clarifies your intent, builds a spec, implements the change, and when it's done it appends a review trail to the spec file and opens it in your editor. You look at the spec and see the change touched 20 files across several modules.
|
||||
You run `bmad-build`. It clarifies your intent, builds a spec, implements the change, and when it's done it appends a review trail to the spec file and opens it in your editor. You look at the spec and see the change touched 20 files across several modules.
|
||||
|
||||
You could eyeball the diff. But 20 files is where eyeballing starts to fail — you lose the thread, miss a connection between two distant changes, or approve something you didn't fully understand. So instead, you say "checkpoint" and the LLM walks you through it.
|
||||
|
||||
That handoff — from autonomous implementation back to human judgment — is the primary use case. Quick-dev runs long with minimal supervision. Checkpoint Preview is where you take back the wheel.
|
||||
That handoff — from autonomous implementation back to human judgment — is the primary use case. Build runs long with minimal supervision. Checkpoint Preview is where you take back the wheel.
|
||||
|
||||
## Why It Exists
|
||||
|
||||
@@ -77,7 +77,7 @@ When no author-produced trail exists, the workflow generates one from the diff a
|
||||
|
||||
## When to Use It
|
||||
|
||||
The primary scenario is the handoff from `bmad-quick-dev`: the implementation is done, the spec file is open in your editor with a review trail appended, and you need to decide whether to ship. Say "checkpoint" and go.
|
||||
The primary scenario is the handoff from `bmad-build`: the implementation is done, the spec file is open in your editor with a review trail appended, and you need to decide whether to ship. Say "checkpoint" and go.
|
||||
|
||||
It also works standalone:
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ Don't worry about it - you can do it at any time. You can even do it during or a
|
||||
|
||||
### How does implementation work in established projects?
|
||||
|
||||
Run `bmad-quick-dev`, just as you would for new development. It will:
|
||||
Run `bmad-build`, just as you would for new development. It will:
|
||||
|
||||
- Auto-detect your existing stack
|
||||
- Analyze existing code patterns
|
||||
@@ -40,7 +40,7 @@ You can enter directly for a clear change or provide a planned story and its ups
|
||||
|
||||
### What if my existing code doesn't follow best practices?
|
||||
|
||||
Quick Dev detects your conventions and asks: "Should I follow these existing conventions?" You decide:
|
||||
Build detects your conventions and asks: "Should I follow these existing conventions?" You decide:
|
||||
|
||||
- **Yes** → Maintain consistency with current codebase
|
||||
- **No** → Establish new standards (document why in spec)
|
||||
|
||||
@@ -36,7 +36,7 @@ BMad ships six named agents, each anchored to a phase of the BMad Method:
|
||||
| 📋 **John**, Product Manager | Planning | PRD creation, epic/story breakdown, implementation readiness |
|
||||
| 🎨 **Sally**, UX Designer | Planning | UX design specifications |
|
||||
| 🏗️ **Winston**, System Architect | Solutioning | technical architecture, alignment checks |
|
||||
| 💻 **Amelia**, Senior Engineer | Implementation | story execution, quick-dev, code review, sprint planning |
|
||||
| 💻 **Amelia**, Senior Engineer | Implementation | story execution, build, code review, sprint planning |
|
||||
|
||||
They each have a hardcoded identity (name, title, domain) and a customizable layer (role, principles, communication style, icon, menu). You can rewrite Mary's principles or add menu items; you can't rename her — that's deliberate. Brand recognition survives customization so "hey Mary" always activates the analyst, regardless of how a team has shaped her behavior.
|
||||
|
||||
@@ -77,7 +77,7 @@ Every agent ships a `customize.toml` with sensible defaults. Teams commit overri
|
||||
|
||||
Most users never hand-author these files. The `bmad-customize` skill walks through picking the target, choosing agent vs workflow scope, authoring the override, and verifying the merge — so the customization surface stays accessible to anyone who understands their intent, not just those fluent in TOML.
|
||||
|
||||
Concrete example: a team commits a single file telling Amelia to always use the Context7 MCP tool for library docs and to fall back to Linear when a story isn't in the local epics list. Every dev workflow Amelia dispatches (quick-dev, code-review, qa-generate) inherits that behavior, with no source edits or per-workflow duplication required.
|
||||
Concrete example: a team commits a single file telling Amelia to always use the Context7 MCP tool for library docs and to fall back to Linear when a story isn't in the local epics list. Every dev workflow Amelia dispatches (build, code-review, qa-generate) inherits that behavior, with no source edits or per-workflow duplication required.
|
||||
|
||||
There's also a second customization surface for *cross-cutting* concerns: the central `_bmad/config.toml` and `_bmad/config.user.toml` (both installer-owned, rebuilt from each module's `module.yaml`) plus `_bmad/custom/config.toml` (team, committed) and `_bmad/custom/config.user.toml` (personal, gitignored) for overrides. This is where the **agent roster** lives — the lightweight descriptors that roster consumers like `bmad-party-mode`, `bmad-retrospective`, and `bmad-advanced-elicitation` read to know who's available and how to embody them. Rebrand an agent org-wide with a team override; add fictional voices (Kirk, Spock, a domain expert persona) as personal experiments via the `.user.toml` override — without touching any skill folder. The per-skill file shapes how Mary *behaves* when she activates; the central config shapes how other skills *see* her when they look at the field.
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ Every implementation workflow automatically loads `project-context.md` if it exi
|
||||
|
||||
**Loaded by these workflows:**
|
||||
- `bmad-architecture` — respects technical preferences during solutioning
|
||||
- `bmad-quick-dev` — informs story planning and implementation with project patterns
|
||||
- `bmad-build` — informs story planning and implementation with project patterns
|
||||
- `bmad-code-review` — validates against project standards
|
||||
- `bmad-sprint-planning`, `bmad-retrospective`, `bmad-correct-course` — provides project-wide context
|
||||
|
||||
@@ -35,7 +35,7 @@ The `project-context.md` file is useful at any stage of a project:
|
||||
| **New project, before architecture** | Manually, before `bmad-architecture` | Document your technical preferences so the architect respects them |
|
||||
| **New project, after architecture** | Via `bmad-generate-project-context` or manually | Capture architecture decisions for implementation agents |
|
||||
| **Existing project** | Via `bmad-generate-project-context` | Discover existing patterns so agents follow established conventions |
|
||||
| **Direct implementation entry** | Before or during `bmad-quick-dev` | Ensure implementation respects your patterns even without upstream planning |
|
||||
| **Direct implementation entry** | Before or during `bmad-build` | Ensure implementation respects your patterns even without upstream planning |
|
||||
|
||||
:::tip[Recommended]
|
||||
For new projects, create it manually before architecture if you have strong technical preferences. Otherwise, generate it after architecture to capture those decisions.
|
||||
|
||||
@@ -59,7 +59,7 @@ This prevents:
|
||||
| Multiple epics or cross-system decisions | Needed to align implementation |
|
||||
| Regulated, high-risk, or enterprise initiative | Follow required governance; solutioning is normally required |
|
||||
|
||||
Solutioning changes the context available to `bmad-quick-dev`; it does not change the implementation workflow.
|
||||
Solutioning changes the context available to `bmad-build`; it does not change the implementation workflow.
|
||||
|
||||
:::tip[Rule of Thumb]
|
||||
If you have multiple epics that could be implemented by different agents, you need solutioning.
|
||||
|
||||
@@ -148,7 +148,7 @@ votre-projet/
|
||||
|--------------------------|-------------------------------|
|
||||
| **Index/Page d’accueil** | `core-concepts/index.md` |
|
||||
| **Concept** | `what-are-agents.md` |
|
||||
| **Fonctionnalité** | `quick-dev.md` |
|
||||
| **Fonctionnalité** | `build.md` |
|
||||
| **Philosophie** | `why-solutioning-matters.md` |
|
||||
| **FAQ** | `established-projects-faq.md` |
|
||||
|
||||
|
||||
@@ -1,19 +1,19 @@
|
||||
---
|
||||
title: "Quick Dev"
|
||||
title: "Build"
|
||||
description: Réduire la friction de l’interaction humaine sans renoncer aux points de contrôle qui protègent la qualité des résultats
|
||||
sidebar:
|
||||
order: 7
|
||||
---
|
||||
|
||||
`bmad-quick-dev` est le workflow d’implémentation standard pour tout travail de développement. Il accepte aussi bien une intention libre ou une issue qu’une story entièrement planifiée, et produit des modifications de code avec le minimum d’interventions humaines compatible avec la sécurité.
|
||||
`bmad-build` est le workflow d’implémentation standard pour tout travail de développement. Il accepte aussi bien une intention libre ou une issue qu’une story entièrement planifiée, et produit des modifications de code avec le minimum d’interventions humaines compatible avec la sécurité.
|
||||
|
||||
La planification amont reste optionnelle et variable. Un changement clair peut entrer directement ; une initiative plus vaste peut apporter PRD, UX, architecture, epics, stories, contrôle de préparation et plan de sprint. Ces artefacts renforcent le contexte sans sélectionner un autre workflow de développement.
|
||||
|
||||
Lorsqu’une story planifiée entre dans Quick Dev, elle reste la source du contexte produit et des critères d’acceptation. Quick Dev crée son propre journal d’exécution pour l’exécution en cours afin de conserver la traçabilité des décisions d’implémentation et des observations de revue, sans remplacer la story.
|
||||
Lorsqu’une story planifiée entre dans Build, elle reste la source du contexte produit et des critères d’acceptation. Build crée son propre journal d’exécution pour l’exécution en cours afin de conserver la traçabilité des décisions d’implémentation et des observations de revue, sans remplacer la story.
|
||||
|
||||
Il permet au modèle de s’exécuter plus longtemps entre les points de contrôle, puis ne vous fait intervenir que lorsque la tâche ne peut pas se poursuivre en toute sécurité sans jugement humain, ou lorsqu’il est temps de revoir le résultat final.
|
||||
|
||||
|
||||
|
||||
|
||||
## Pourquoi cette fonctionnalité existe
|
||||
|
||||
@@ -21,7 +21,7 @@ Les interactions humaines dans la boucle sont nécessaires et coûteuses.
|
||||
|
||||
Les LLM actuels échouent encore de manière prévisible : ils interprètent mal l’intention, comblent les lacunes avec des suppositions assurées, dérivent vers du travail non lié, et génèrent des résultats à réviser bruyants. En même temps, l’intervention humaine constante limite la fluidité du développement. L’attention humaine est le goulot d’étranglement.
|
||||
|
||||
`bmad-quick-dev` rééquilibre ce compromis. Il fait confiance au modèle pour s’exécuter sans surveillance sur de plus longues périodes, mais seulement après que le workflow ait créé une frontière suffisamment solide pour rendre cela sûr.
|
||||
`bmad-build` rééquilibre ce compromis. Il fait confiance au modèle pour s’exécuter sans surveillance sur de plus longues périodes, mais seulement après que le workflow ait créé une frontière suffisamment solide pour rendre cela sûr.
|
||||
|
||||
## La conception fondamentale
|
||||
|
||||
@@ -57,7 +57,7 @@ L’entretien sur l’intention implique la personne dans la boucle, mais ce n
|
||||
|
||||
- **Résolution des lacunes d’intention** - intervenir à nouveau lors de la revue prouve que le workflow n’a pas pu déduire correctement ce qui était voulu
|
||||
|
||||
Tout le reste est candidat à une exécution autonome plus longue. Ce compromis est délibéré. Les anciens patterns dépensent plus d’attention humaine en supervision continue. Quick Dev fait davantage confiance au modèle, mais préserve l’attention humaine pour les moments où le raisonnement humain a le plus d’impact.
|
||||
Tout le reste est candidat à une exécution autonome plus longue. Ce compromis est délibéré. Les anciens patterns dépensent plus d’attention humaine en supervision continue. Build fait davantage confiance au modèle, mais préserve l’attention humaine pour les moments où le raisonnement humain a le plus d’impact.
|
||||
|
||||
## Pourquoi le système de revue est important
|
||||
|
||||
@@ -70,7 +70,7 @@ Les revues agentiques[^2] échouent souvent de deux manières :
|
||||
- Elles génèrent trop d’observations, forçant la personne à trier le bruit.
|
||||
- Elles déraillent des modifications actuelles en remontant des problèmes non liés et en transformant chaque exécution en un projet de nettoyage improvisé.
|
||||
|
||||
Quick Dev aborde ces deux problèmes en traitant la revue comme un triage[^3].
|
||||
Build aborde ces deux problèmes en traitant la revue comme un triage[^3].
|
||||
|
||||
Certaines observations concernent le changement en cours, d’autres non. Si une observation est incidente plutôt que directement liée au travail en cours, le workflow peut la différer au lieu d’obliger la personne à la traiter immédiatement. Cela permet de rester concentré sur l’exécution et d’éviter que des digressions aléatoires ne viennent épuiser le capital d’attention.
|
||||
|
||||
@@ -11,11 +11,11 @@ sidebar:
|
||||
|
||||
## Le Flux Typique
|
||||
|
||||
Vous lancez `bmad-quick-dev`. Il clarifie votre intention, construit une spécification, implémente la modification, et une fois terminé, il ajoute un historique de revue au fichier de spécification et l’ouvre dans votre éditeur. Vous regardez la spec et constatez que la modification a touché 20 fichiers dans plusieurs modules.
|
||||
Vous lancez `bmad-build`. Il clarifie votre intention, construit une spécification, implémente la modification, et une fois terminé, il ajoute un historique de revue au fichier de spécification et l’ouvre dans votre éditeur. Vous regardez la spec et constatez que la modification a touché 20 fichiers dans plusieurs modules.
|
||||
|
||||
Vous pourriez survoler le diff. Mais 20 fichiers, c’est le moment où le survol commence à échouer — on perd le fil, on rate un lien entre deux modifications éloignées, ou on approuve quelque chose qu’on n’a pas pleinement compris. Alors au lieu de cela, vous dites « checkpoint » et le LLM vous guide à travers la modification.
|
||||
|
||||
Ce passage de relais — de l’implémentation autonome au jugement humain — est le cas d’usage principal. Quick-dev s’exécute longtemps avec une supervision minimale. Checkpoint Preview, c’est là où vous reprenez le volant.
|
||||
Ce passage de relais — de l’implémentation autonome au jugement humain — est le cas d’usage principal. Build s’exécute longtemps avec une supervision minimale. Checkpoint Preview, c’est là où vous reprenez le volant.
|
||||
|
||||
## Pourquoi
|
||||
|
||||
@@ -77,7 +77,7 @@ Lorsqu’aucun historique produit par l’auteur n’existe, le workflow en gén
|
||||
|
||||
## Quand l’utiliser
|
||||
|
||||
Le scénario principal est le passage de relais depuis `bmad-quick-dev` : l’implémentation est terminée, le fichier de spécification est ouvert dans votre éditeur avec un historique de revue ajouté, et vous devez décider si vous publiez. Dites « checkpoint » et c’est parti.
|
||||
Le scénario principal est le passage de relais depuis `bmad-build` : l’implémentation est terminée, le fichier de spécification est ouvert dans votre éditeur avec un historique de revue ajouté, et vous devez décider si vous publiez. Dites « checkpoint » et c’est parti.
|
||||
|
||||
Il fonctionne aussi de manière autonome :
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ Ne vous inquiétez pas — vous pouvez le faire à tout moment. Vous pouvez mêm
|
||||
|
||||
### Comment fonctionne l’implémentation dans les projets existants ?
|
||||
|
||||
Exécutez `bmad-quick-dev`, comme pour un nouveau développement. Le workflow va :
|
||||
Exécutez `bmad-build`, comme pour un nouveau développement. Le workflow va :
|
||||
|
||||
- Détecter automatiquement votre pile technologique existante
|
||||
- Analyser les patterns de code existants
|
||||
@@ -40,7 +40,7 @@ Vous pouvez entrer directement pour une modification claire ou fournir une story
|
||||
|
||||
### Que faire si mon code existant ne suit pas les bonnes pratiques ?
|
||||
|
||||
Quick Dev détecte vos conventions et demande : « Dois-je suivre ces conventions existantes ? » Vous décidez :
|
||||
Build détecte vos conventions et demande : « Dois-je suivre ces conventions existantes ? » Vous décidez :
|
||||
|
||||
- **Oui** → Maintenir la cohérence avec la base de code actuelle
|
||||
- **Non** → Établir de nouvelles normes (documenter pourquoi dans la spécification technique)
|
||||
|
||||
@@ -36,7 +36,7 @@ BMad embarque six agents nommés, chacun ancré à une phase de la méthode BMad
|
||||
| 📋 **John**, Chef de produit | Planification | création de PRD, décomposition epic/story, vérification de la préparation à l’implémentation |
|
||||
| 🎨 **Sally**, Designer UX | Planification | spécifications de design UX |
|
||||
| 🏗️ **Winston**, Architecte système | Solutioning | architecture technique, vérifications d’alignement |
|
||||
| 💻 **Amelia**, Ingénieure senior | Implémentation | exécution de stories, quick-dev, revue de code, planification de sprint |
|
||||
| 💻 **Amelia**, Ingénieure senior | Implémentation | exécution de stories, build, revue de code, planification de sprint |
|
||||
|
||||
Chacun possède une identité codée en dur (nom, titre, domaine) et une couche personnalisable (rôle, principes, style de communication, icône, menu). Vous pouvez réécrire les principes de Mary ou ajouter des éléments de menu ; vous ne pouvez pas la renommer — c’est délibéré. La reconnaissance de marque persiste après personnalisation pour que « hey Mary » active toujours l’analyste, indépendamment de la façon dont une équipe a façonné son comportement.
|
||||
|
||||
@@ -77,7 +77,7 @@ Chaque agent embarque un fichier `customize.toml` avec des valeurs par défaut j
|
||||
|
||||
La plupart des utilisateurs ne rédigent jamais ces fichiers à la main. Le skill `bmad-customize` guide le choix de la cible, la sélection du périmètre agent vs workflow, la rédaction de l’override et la vérification de la fusion — pour que la surface de personnalisation reste accessible à quiconque comprend son intention, pas seulement à ceux qui maîtrisent le TOML.
|
||||
|
||||
Exemple concret : une équipe versionne dans git un seul fichier demandant à Amelia d’utiliser systématiquement l’outil MCP Context7 pour la documentation des bibliothèques et de se rabattre sur Linear quand une story n’est pas dans la liste locale des epics. Chaque workflow de développement qu’Amelia lance (quick-dev, code-review, qa-generate) hérite de ce comportement, sans modification du code ni duplication par workflow.
|
||||
Exemple concret : une équipe versionne dans git un seul fichier demandant à Amelia d’utiliser systématiquement l’outil MCP Context7 pour la documentation des bibliothèques et de se rabattre sur Linear quand une story n’est pas dans la liste locale des epics. Chaque workflow de développement qu’Amelia lance (build, code-review, qa-generate) hérite de ce comportement, sans modification du code ni duplication par workflow.
|
||||
|
||||
Il existe aussi une seconde surface de personnalisation pour les préoccupations *transversales* : la configuration centrale `_bmad/config.toml` et `_bmad/config.user.toml` (tous deux gérés par l’installateur, reconstruits à partir du `module.yaml` de chaque module) plus `_bmad/custom/config.toml` (équipe, versionné dans git) et `_bmad/custom/config.user.toml` (personnel, ignoré par git) pour les overrides. C’est là que se trouve le **registre des agents** — les descripteurs légers que les consommateurs du registre comme `bmad-party-mode`, `bmad-retrospective` et `bmad-advanced-elicitation` lisent pour savoir qui est disponible et comment l’incarner. Redéfinissez l’image d’un agent pour toute l’organisation avec un override d’équipe ; ajoutez des personnages fictifs (Kirk, Spock, un persona expert du domaine) comme expériences personnelles via l’override `.user.toml` — sans toucher aucun dossier de skill. Le fichier par skill façonne la façon dont Mary *se comporte* quand elle s’active ; la configuration centrale façonne la façon dont les autres skills *la perçoivent* quand ils consultent le registre.
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ Chaque workflow d’implémentation charge automatiquement `project-context.md`
|
||||
**Chargé par ces workflows :**
|
||||
- `bmad-architecture` — respecte les préférences techniques pendant la phase de solutioning
|
||||
- `bmad-code-review` — valide par rapport aux standards du projet
|
||||
- `bmad-quick-dev` — applique les patterns lors de la planification et de l’implémentation d’intentions directes ou de stories
|
||||
- `bmad-build` — applique les patterns lors de la planification et de l’implémentation d’intentions directes ou de stories
|
||||
- `bmad-sprint-planning`, `bmad-retrospective`, `bmad-correct-course` — fournit le contexte global du projet
|
||||
|
||||
## Quand Le Créer
|
||||
@@ -35,7 +35,7 @@ Le fichier `project-context.md` est utile à n’importe quel stade d’un proje
|
||||
| **Nouveau projet, avant l’architecture** | Manuellement, avant `bmad-architecture` | Documenter vos préférences techniques pour que l’architecte les respecte |
|
||||
| **Nouveau projet, après l’architecture** | Via `bmad-generate-project-context` ou manuellement | Capturer les décisions d’architecture pour les agents d’implémentation |
|
||||
| **Projet existant** | Via `bmad-generate-project-context` | Découvrir les patterns existants pour que les agents suivent les conventions établies |
|
||||
| **Entrée directe en implémentation** | Avant ou pendant `bmad-quick-dev` | Garantir que l’implémentation sans planification amont respecte vos patterns |
|
||||
| **Entrée directe en implémentation** | Avant ou pendant `bmad-build` | Garantir que l’implémentation sans planification amont respecte vos patterns |
|
||||
|
||||
:::tip[Recommandé]
|
||||
Pour les nouveaux projets, créez-le manuellement avant l’architecture si vous avez de fortes préférences techniques. Sinon, générez-le après l’architecture pour capturer ces décisions.
|
||||
|
||||
@@ -58,7 +58,7 @@ Cela évite :
|
||||
| Plusieurs epics ou décisions multi-systèmes | Nécessaire pour aligner l’implémentation |
|
||||
| Initiative réglementée, risquée ou enterprise | Suivre la gouvernance requise ; le solutioning est normalement obligatoire |
|
||||
|
||||
Le solutioning change le contexte fourni à `bmad-quick-dev`, pas le workflow d’implémentation.
|
||||
Le solutioning change le contexte fourni à `bmad-build`, pas le workflow d’implémentation.
|
||||
|
||||
:::tip[Règle Générale]
|
||||
Si vous avez plusieurs epics qui pourraient être implémentés par différents agents, vous avez besoin de solutioning.
|
||||
|
||||
@@ -77,12 +77,12 @@ BMad-Help s’exécute également **automatiquement à la fin de chaque workflow
|
||||
|
||||
### Choisir la profondeur de planification
|
||||
|
||||
Toute implémentation utilise `bmad-quick-dev` ; la portée détermine le contexte à préparer en amont :
|
||||
Toute implémentation utilise `bmad-build` ; la portée détermine le contexte à préparer en amont :
|
||||
|
||||
| Portée | Approche recommandée |
|
||||
|-------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| **Mises à jour ou ajouts clairs** | Entrez directement dans `bmad-quick-dev` avec la demande, l’issue ou la spécification existante. |
|
||||
| **Modifications ou ajouts majeurs** | Préparez le PRD, l’UX, l’architecture, les epics, les stories et le contexte de sprint utiles, puis confiez le travail sélectionné à `bmad-quick-dev`. |
|
||||
| **Mises à jour ou ajouts clairs** | Entrez directement dans `bmad-build` avec la demande, l’issue ou la spécification existante. |
|
||||
| **Modifications ou ajouts majeurs** | Préparez le PRD, l’UX, l’architecture, les epics, les stories et le contexte de sprint utiles, puis confiez le travail sélectionné à `bmad-build`. |
|
||||
|
||||
### Pendant la création du PRD
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ En règle générale : si la règle doit s’appliquer partout où un ingénieu
|
||||
|
||||
[agent]
|
||||
|
||||
# Appliqué à chaque activation. Se propage dans quick-dev, code-review,
|
||||
# Appliqué à chaque activation. Se propage dans build, code-review,
|
||||
# qa-generate — chaque skill qu'Amelia dispatche.
|
||||
persistent_facts = [
|
||||
"Pour toute recherche de documentation sur une bibliothèque (React, TypeScript, Zod, Prisma, etc.), appeler l'outil MCP context7 (`mcp__context7__resolve_library_id` puis `mcp__context7__get_library_docs`) avant de s'appuyer sur les connaissances des données d'entraînement. Les docs à jour priment sur les API mémorisées.",
|
||||
|
||||
@@ -30,7 +30,7 @@ Clonez ou ouvrez le [dépôt BMAD-METHOD](https://github.com/bmad-code-org/BMAD-
|
||||
:::note[Exemple]
|
||||
**Q :** « Quel est le moyen le plus rapide de construire quelque chose avec BMad ? »
|
||||
|
||||
**R :** Lancez `bmad-quick-dev`. Donnez-lui une intention directe, une issue, une spécification ou une story planifiée ; il utilise le contexte disponible et choisit la profondeur de clarification, de planification, d’implémentation et de revue nécessaire.
|
||||
**R :** Lancez `bmad-build`. Donnez-lui une intention directe, une issue, une spécification ou une story planifiée ; il utilise le contexte disponible et choisit la profondeur de clarification, de planification, d’implémentation et de revue nécessaire.
|
||||
:::
|
||||
|
||||
**Conseils pour de meilleures réponses :**
|
||||
|
||||
@@ -118,7 +118,7 @@ Un fichier `project-context.md` qui :
|
||||
- **Concentrez-vous sur ce qui n’est pas évident** — Documentez les patterns que les agents pourraient manquer (par ex. « Utiliser JSDoc sur chaque classe publique »), et non les pratiques universelles comme « utiliser des noms de variables significatifs ».
|
||||
- **Gardez-le concis** — Ce fichier est chargé par chaque workflow d’implémentation. Les fichiers longs gaspillent le contexte. Excluez le contenu qui ne s’applique qu’à un périmètre restreint ou à des stories spécifiques.
|
||||
- **Mettez à jour si nécessaire** — Modifiez manuellement lorsque les patterns changent, ou régénérez après des changements d’architecture significatifs.
|
||||
- Prend en charge la même boucle `bmad-quick-dev`, que le travail entre directement ou après une planification approfondie.
|
||||
- Prend en charge la même boucle `bmad-build`, que le travail entre directement ou après une planification approfondie.
|
||||
:::
|
||||
|
||||
## Prochaines étapes
|
||||
|
||||
@@ -5,7 +5,7 @@ sidebar:
|
||||
order: 6
|
||||
---
|
||||
|
||||
Les corrections de bugs, refactorisations et petites modifications ciblées peuvent entrer directement dans **Quick Dev** avec peu ou pas de planification amont. C’est le même workflow d’implémentation que pour les stories entièrement planifiées.
|
||||
Les corrections de bugs, refactorisations et petites modifications ciblées peuvent entrer directement dans **Build** avec peu ou pas de planification amont. C’est le même workflow d’implémentation que pour les stories entièrement planifiées.
|
||||
|
||||
## Quand Utiliser Cette Approche
|
||||
|
||||
@@ -27,27 +27,27 @@ Ouvrez une **nouvelle conversation** dans votre IDE IA. Réutiliser une session
|
||||
|
||||
### 2. Spécifiez Votre Intention
|
||||
|
||||
Quick Dev accepte l’intention en forme libre — avant, avec, ou après l’invocation. Exemples :
|
||||
Build accepte l’intention en forme libre — avant, avec, ou après l’invocation. Exemples :
|
||||
|
||||
```text
|
||||
quick-dev — Corrige le bug de validation de connexion qui permet les mots de passe vides.
|
||||
build — Corrige le bug de validation de connexion qui permet les mots de passe vides.
|
||||
```
|
||||
|
||||
```text
|
||||
quick-dev — corrige https://github.com/org/repo/issues/42
|
||||
build — corrige https://github.com/org/repo/issues/42
|
||||
```
|
||||
|
||||
```text
|
||||
quick-dev — implémente _bmad-output/implementation-artifacts/my-intent.md
|
||||
build — implémente _bmad-output/implementation-artifacts/my-intent.md
|
||||
```
|
||||
|
||||
```text
|
||||
Je pense que le problème est dans le middleware d'auth, il ne vérifie pas l'expiration du token.
|
||||
Regardons... oui, src/auth/middleware.ts ligne 47 saute complètement la vérification exp. lance quick-dev
|
||||
Regardons... oui, src/auth/middleware.ts ligne 47 saute complètement la vérification exp. lance build
|
||||
```
|
||||
|
||||
```text
|
||||
quick-dev
|
||||
build
|
||||
> Que voulez-vous faire ?
|
||||
Refactoriser UserService pour utiliser async/await au lieu des callbacks.
|
||||
```
|
||||
@@ -56,19 +56,19 @@ Texte brut, chemins de fichiers, URLs d’issues GitHub, liens de trackers de bu
|
||||
|
||||
### 3. Répondre aux Questions et Approuver
|
||||
|
||||
Quick Dev peut poser des questions de clarification ou présenter une courte spécification demandant votre approbation avant l’implémentation. Répondez à ses questions et approuvez lorsque vous êtes satisfait du plan.
|
||||
Build peut poser des questions de clarification ou présenter une courte spécification demandant votre approbation avant l’implémentation. Répondez à ses questions et approuvez lorsque vous êtes satisfait du plan.
|
||||
|
||||
### 4. Réviser et Pousser
|
||||
|
||||
Quick Dev implémente la modification, révise son propre travail, corrige les problèmes et effectue un commit local. Lorsqu’il a terminé, il ouvre les fichiers affectés dans votre éditeur.
|
||||
Build implémente la modification, révise son propre travail, corrige les problèmes et effectue un commit local. Lorsqu’il a terminé, il ouvre les fichiers affectés dans votre éditeur.
|
||||
|
||||
- Parcourez le diff pour confirmer que la modification correspond à votre intention
|
||||
- Si quelque chose semble incorrect, dites à l’agent ce qu’il faut corriger — il peut itérer dans la même session
|
||||
|
||||
Une fois satisfait, poussez le commit. Quick Dev vous proposera de pousser et de créer une PR pour vous.
|
||||
Une fois satisfait, poussez le commit. Build vous proposera de pousser et de créer une PR pour vous.
|
||||
|
||||
:::caution[Si Quelque Chose Casse]
|
||||
Si une modification poussée cause des problèmes inattendus, utilisez `git revert HEAD` pour annuler proprement le dernier commit. Ensuite, démarrez une nouvelle conversation et exécutez Quick Dev à nouveau pour essayer une approche différente.
|
||||
Si une modification poussée cause des problèmes inattendus, utilisez `git revert HEAD` pour annuler proprement le dernier commit. Ensuite, démarrez une nouvelle conversation et exécutez Build à nouveau pour essayer une approche différente.
|
||||
:::
|
||||
|
||||
## Ce Que Vous Obtenez
|
||||
@@ -79,19 +79,19 @@ Si une modification poussée cause des problèmes inattendus, utilisez `git reve
|
||||
|
||||
## Travail Différé
|
||||
|
||||
Quick Dev garde chaque exécution concentrée sur un seul objectif. Si votre demande contient plusieurs objectifs indépendants, ou si la revue remonte des problèmes préexistants non liés à votre modification, Quick Dev les diffère vers un fichier (`deferred-work.md` dans votre répertoire d’artefacts d’implémentation) plutôt que d’essayer de tout régler en même temps.
|
||||
Build garde chaque exécution concentrée sur un seul objectif. Si votre demande contient plusieurs objectifs indépendants, ou si la revue remonte des problèmes préexistants non liés à votre modification, Build les diffère vers un fichier (`deferred-work.md` dans votre répertoire d’artefacts d’implémentation) plutôt que d’essayer de tout régler en même temps.
|
||||
|
||||
Consultez ce fichier après une exécution — c’est votre backlog[^1] de choses sur lesquelles revenir. Chaque élément différé peut être introduit dans une nouvelle exécution Quick Dev ultérieurement.
|
||||
Consultez ce fichier après une exécution — c’est votre backlog[^1] de choses sur lesquelles revenir. Chaque élément différé peut être introduit dans une nouvelle exécution Build ultérieurement.
|
||||
|
||||
## Quand Ajouter une Planification Formelle
|
||||
|
||||
Avant d’exécuter la même boucle Quick Dev, envisagez d’ajouter un PRD, une UX, une architecture ou une planification des stories lorsque :
|
||||
Avant d’exécuter la même boucle Build, envisagez d’ajouter un PRD, une UX, une architecture ou une planification des stories lorsque :
|
||||
|
||||
- La modification affecte plusieurs systèmes ou nécessite des mises à jour coordonnées dans de nombreux fichiers
|
||||
- Vous n’êtes pas sûr de la portée et avez besoin d’une découverte des exigences d’abord
|
||||
- Vous avez besoin de documentation ou de décisions architecturales enregistrées pour l’équipe
|
||||
|
||||
Voir [Quick Dev](../explanation/quick-dev.md) pour comprendre comment l’intention directe et le travail planifié convergent vers la même boucle d’implémentation.
|
||||
Voir [Build](../explanation/build.md) pour comprendre comment l’intention directe et le travail planifié convergent vers la même boucle d’implémentation.
|
||||
|
||||
## Glossaire
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ Cette page liste les agents BMM (suite Agile) par défaut installés avec la mé
|
||||
| Analyste (Mary) | `bmad-agent-analyst` | `BP`, `MR`, `DR`, `TR`, `CB`, `WB`, `DP` | Brainstorming, Recherche marché, Recherche domaine, Recherche technique, Création du brief[^1], Défi PRFAQ, Documentation du projet |
|
||||
| Product Manager (John) | `bmad-agent-pm` | `PRD`, `CE`, `IR`, `CC` | Créer, mettre à jour ou valider un PRD, Créer des Epics et Stories, vérifier l’état de préparation à l’Implémentation, Corriger le Cours |
|
||||
| Architecte (Winston) | `bmad-agent-architect` | `CA`, `IR` | Créer l’architecture, Préparation à l’implémentation |
|
||||
| Développeur (Amelia) | `bmad-agent-dev` | `QD`, `QA`, `CR`, `SP`, `ER` | Quick Dev, Génération de Tests QA, Code Review, Sprint Planning, Rétrospective d’Epic |
|
||||
| Développeur (Amelia) | `bmad-agent-dev` | `BD`, `QA`, `CR`, `SP`, `ER` | Build, Génération de Tests QA, Code Review, Sprint Planning, Rétrospective d’Epic |
|
||||
| Designer UX (Sally) | `bmad-agent-ux-designer` | `CU` | Création du design UX[^2] |
|
||||
| Rédacteur Technique (Paige) | `bmad-agent-tech-writer` | `DP`, `WD`, `MG`, `VD`, `EC` | Documentation du projet, Rédaction de documents, Génération de diagrammes Mermaid, Validation de documents, Explication de concepts |
|
||||
|
||||
@@ -32,7 +32,7 @@ Les déclencheurs de menu d’agent utilisent deux types d’invocation différe
|
||||
|
||||
La plupart des déclencheurs chargent un fichier de workflow structuré. Tapez le code du déclencheur et l’agent démarre le workflow, vous demandant de saisir les informations à chaque étape.
|
||||
|
||||
Exemples : `PRD` (Créer, mettre à jour ou valider un PRD), `CA` (Créer l’architecture), `QD` (Quick Dev)
|
||||
Exemples : `PRD` (Créer, mettre à jour ou valider un PRD), `CA` (Créer l’architecture), `BD` (Build)
|
||||
|
||||
### Déclencheurs conversationnels (arguments requis)
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ BMad offre deux façons de démarrer un travail, chacune ayant un usage différe
|
||||
| Mécanisme | Comment l’invoquer | Ce qui se passe |
|
||||
|-------------------------------|---------------------------------------------------------------|------------------------------------------------------------------------------------------------|
|
||||
| **Skill** | Tapez le nom du skill (ex. `bmad-help`) dans votre IDE | Charge directement un agent, exécute un workflow ou lance une tâche |
|
||||
| **Déclencheur du menu agent** | Chargez d’abord un agent, puis tapez un code court (ex. `QD`) | L’agent interprète le code et démarre le workflow correspondant tout en préservant son persona |
|
||||
| **Déclencheur du menu agent** | Chargez d’abord un agent, puis tapez un code court (ex. `BD`) | L’agent interprète le code et démarre le workflow correspondant tout en préservant son persona |
|
||||
|
||||
Les déclencheurs du menu agent nécessitent une session agent active. Utilisez les skills lorsque vous savez quel workflow vous voulez. Utilisez les déclencheurs lorsque vous travaillez déjà avec un agent et souhaitez changer de tâche sans quitter la conversation.
|
||||
|
||||
@@ -97,7 +97,7 @@ Les skills de workflow exécutent un processus structuré en plusieurs étapes s
|
||||
| `bmad-architecture` | Concevoir l’architecture système |
|
||||
| `bmad-create-epics-and-stories` | Créer des epics et des stories |
|
||||
| `bmad-code-review` | Effectuer une revue de code |
|
||||
| `bmad-quick-dev` | Implémenter une intention directe, une issue, une fonctionnalité, un correctif ou une story planifiée |
|
||||
| `bmad-build` | Implémenter une intention directe, une issue, une fonctionnalité, un correctif ou une story planifiée |
|
||||
|
||||
Consultez la [Carte des workflows](./workflow-map.md) pour la référence complète des workflows organisés par phase.
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ Outils basés sur l’IA pour la créativité structurée, l’idéation et l’
|
||||
|
||||
## Game Dev Studio
|
||||
|
||||
Workflows de développement de jeux structurés adaptés pour Unity, Unreal, Godot et moteurs personnalisés. Supporte une profondeur de planification allant du prototype à la production à grande échelle ; l’implémentation converge vers Quick Dev.
|
||||
Workflows de développement de jeux structurés adaptés pour Unity, Unreal, Godot et moteurs personnalisés. Supporte une profondeur de planification allant du prototype à la production à grande échelle ; l’implémentation converge vers Build.
|
||||
|
||||
- **Code :** `gds`
|
||||
- **npm :** [`bmad-game-dev-studio`](https://www.npmjs.com/package/bmad-game-dev-studio)
|
||||
@@ -52,7 +52,7 @@ Workflows de développement de jeux structurés adaptés pour Unity, Unreal, God
|
||||
**Fournit :**
|
||||
|
||||
- Workflow de génération de Document de Design de Jeu (GDD[^3])
|
||||
- Contexte et planification spécifiques au jeu pour la boucle d’implémentation Quick Dev standard
|
||||
- Contexte et planification spécifiques au jeu pour la boucle d’implémentation Build standard
|
||||
- Support de design narratif pour les personnages, dialogues et construction de monde
|
||||
- Couverture de plus de 21 types de jeux avec des conseils d’architecture spécifiques au moteur
|
||||
|
||||
|
||||
@@ -97,7 +97,7 @@ TEA supporte également la priorisation basée sur les risques P0-P3 et des int
|
||||
|
||||
Le workflow Automate du QA intégré apparaît dans la Phase 4 (Implémentation) de la carte de workflow méthode BMad. Il est conçu pour s’exécuter **après qu’un epic complet soit terminé** — une fois que toutes les stories d’un epic ont été implémentées et revues. Une séquence typique :
|
||||
|
||||
1. Pour chaque story de l’epic : implémenter avec Quick Dev (`QD` / `bmad-quick-dev`), puis ajouter Code Review (`CR`) si nécessaire
|
||||
1. Pour chaque story de l’epic : implémenter avec Build (`BD` / `bmad-build`), puis ajouter Code Review (`CR`) si nécessaire
|
||||
2. Après la fin de l’epic : générer les tests avec `QA` (via l’agent Developer) ou le workflow Automate de TEA
|
||||
3. Lancer la rétrospective (`bmad-retrospective`) pour capturer les leçons apprises
|
||||
|
||||
|
||||
@@ -75,11 +75,11 @@ Décidez comment le construire et décomposez le travail en stories.
|
||||
|
||||
## Phase 4 : Implémentation
|
||||
|
||||
Tous les points d’entrée convergent vers `bmad-quick-dev`. Il accepte une intention directe, une issue, une spécification ou une story planifiée, puis choisit le niveau de clarification, de planification, d’implémentation et de revue nécessaire.
|
||||
Tous les points d’entrée convergent vers `bmad-build`. Il accepte une intention directe, une issue, une spécification ou une story planifiée, puis choisit le niveau de clarification, de planification, d’implémentation et de revue nécessaire.
|
||||
|
||||
| Workflow | Objectif | Livrable |
|
||||
|------------------------|--------------------------------------------------------------------------------------|----------------------------------|
|
||||
| `bmad-quick-dev` | Transformez une intention directe ou une story planifiée en code implémenté et révisé | `spec-*.md` + code |
|
||||
| `bmad-build` | Transformez une intention directe ou une story planifiée en code implémenté et révisé | `spec-*.md` + code |
|
||||
| `bmad-sprint-planning` | Initialisez le suivi (une fois par projet, pour séquencer le cycle de développement) | `sprint-status.yaml` |
|
||||
| `bmad-code-review` | Validez la qualité de l’implémentation | Approuvé ou changements demandés |
|
||||
| `bmad-correct-course` | Gérez les changements significatifs en cours de sprint | Plan mis à jour ou réorientation |
|
||||
@@ -88,7 +88,7 @@ Tous les points d’entrée convergent vers `bmad-quick-dev`. Il accepte une int
|
||||
|
||||
### Entrée directe ou planifiée
|
||||
|
||||
Un travail clair peut entrer directement dans `bmad-quick-dev`. Une initiative plus vaste peut d’abord produire un PRD, une conception UX, une architecture, des epics, des stories, un contrôle de préparation et un plan de sprint. Ces artefacts ajoutent du contexte sans sélectionner un autre workflow d’implémentation.
|
||||
Un travail clair peut entrer directement dans `bmad-build`. Une initiative plus vaste peut d’abord produire un PRD, une conception UX, une architecture, des epics, des stories, un contrôle de préparation et un plan de sprint. Ces artefacts ajoutent du contexte sans sélectionner un autre workflow d’implémentation.
|
||||
|
||||
## Gestion du Contexte
|
||||
|
||||
|
||||
@@ -85,7 +85,7 @@ La profondeur de planification reste flexible :
|
||||
| **Solutioning complet** | Initiatives coordonnées, risquées ou multi-systèmes | PRD, UX, architecture, epics, stories et plan de sprint |
|
||||
|
||||
:::note
|
||||
Il ne s’agit pas de voies d’implémentation distinctes. Tous les points d’entrée convergent vers `bmad-quick-dev`; la planification ne change que la quantité de contexte disponible.
|
||||
Il ne s’agit pas de voies d’implémentation distinctes. Tous les points d’entrée convergent vers `bmad-build`; la planification ne change que la quantité de contexte disponible.
|
||||
:::
|
||||
|
||||
## Installation
|
||||
@@ -189,13 +189,13 @@ Les epics et stories sont désormais créés *après* l’architecture. Cela pro
|
||||
|
||||
Passez à l’implémentation avec le contexte disponible : demande directe, issue, spécification ou story entièrement planifiée. **Chaque workflow doit être exécuté dans un nouveau chat.**
|
||||
|
||||
Pour un travail planifié, invoquez `bmad-quick-dev` et indiquez la story ou l’élément de sprint sélectionné, par exemple : `Implémente la story 2.3 depuis _bmad-output/planning-artifacts/epics.md`.
|
||||
Pour un travail planifié, invoquez `bmad-build` et indiquez la story ou l’élément de sprint sélectionné, par exemple : `Implémente la story 2.3 depuis _bmad-output/planning-artifacts/epics.md`.
|
||||
|
||||
### Initialiser la planification de sprint (pour le travail planifié)
|
||||
|
||||
Invoquez l'**agent Développeur** (`bmad-agent-dev`) et exécutez `bmad-sprint-planning` (`bmad-sprint-planning`). Cette commande crée `sprint-status.yaml` pour suivre tous les epics et stories.
|
||||
|
||||
Lorsque Quick Dev retrouve la story sélectionnée dans ce fichier, il la passe à `in-progress` pendant l’implémentation, puis à `review` quand l’implémentation est terminée.
|
||||
Lorsque Build retrouve la story sélectionnée dans ce fichier, il la passe à `in-progress` pendant l’implémentation, puis à `review` quand l’implémentation est terminée.
|
||||
|
||||
### Le cycle de développement
|
||||
|
||||
@@ -203,10 +203,10 @@ Pour chaque changement direct ou story planifiée, répétez ce cycle dans de no
|
||||
|
||||
| Étape | Agent | Workflow | Commande | Objectif |
|
||||
|-------|-------|---------------------|---------------------|--------------------------------------|
|
||||
| 1 | DEV | `bmad-quick-dev` | `bmad-quick-dev` | Clarifier, planifier, implémenter, réviser et présenter |
|
||||
| 1 | DEV | `bmad-build` | `bmad-build` | Clarifier, planifier, implémenter, réviser et présenter |
|
||||
| 2 | DEV | `bmad-code-review` | `bmad-code-review` | Validation qualité supplémentaire *(recommandée)* |
|
||||
|
||||
La revue de Quick Dev fait partie de chaque exécution. `bmad-code-review` est une couche facultative de validation indépendante dans un contexte neuf.
|
||||
La revue de Build fait partie de chaque exécution. `bmad-code-review` est une couche facultative de validation indépendante dans un contexte neuf.
|
||||
|
||||
Après avoir terminé toutes les stories d’un epic, invoquez l'**agent Développeur** (`bmad-agent-dev`) et exécutez `bmad-retrospective` (`bmad-retrospective`).
|
||||
|
||||
@@ -246,13 +246,13 @@ your-project/
|
||||
| `bmad-create-epics-and-stories` | `bmad-create-epics-and-stories` | PM | Décomposer le PRD en epics |
|
||||
| `bmad-check-implementation-readiness` | `bmad-check-implementation-readiness` | Architect | Valider la cohérence de la planification |
|
||||
| `bmad-sprint-planning` | `bmad-sprint-planning` | DEV | Initialiser le suivi de sprint |
|
||||
| `bmad-quick-dev` | `bmad-quick-dev` | DEV | Implémenter une intention, une issue, une fonctionnalité, un correctif ou une story |
|
||||
| `bmad-build` | `bmad-build` | DEV | Implémenter une intention, une issue, une fonctionnalité, un correctif ou une story |
|
||||
| `bmad-code-review` | `bmad-code-review` | DEV | Revoir le code implémenté |
|
||||
|
||||
## Questions fréquentes
|
||||
|
||||
**Ai-je toujours besoin d’une architecture ?**
|
||||
Non. Utilisez l’architecture lorsque les décisions techniques ou contraintes multi-systèmes doivent être explicites. Un travail clair peut entrer directement dans `bmad-quick-dev`; une initiative plus vaste fournit ses artefacts de planification au même workflow.
|
||||
Non. Utilisez l’architecture lorsque les décisions techniques ou contraintes multi-systèmes doivent être explicites. Un travail clair peut entrer directement dans `bmad-build`; une initiative plus vaste fournit ses artefacts de planification au même workflow.
|
||||
|
||||
**Puis-je modifier mon plan en cours de route ?**
|
||||
Oui. Le workflow `bmad-correct-course` gère les changements de périmètre en cours d’implémentation.
|
||||
@@ -284,7 +284,7 @@ BMad-Help inspecte votre projet, détecte ce que vous avez accompli et vous indi
|
||||
:::tip[Retenez ceci]
|
||||
- **Commencez par `bmad-help`** — Votre guide intelligent qui connaît votre projet et vos options
|
||||
- **Utilisez toujours de nouveaux chats** — Démarrez un nouveau chat pour chaque workflow
|
||||
- **La profondeur de planification varie** — une intention directe et une story entièrement planifiée entrent toutes deux dans `bmad-quick-dev`
|
||||
- **La profondeur de planification varie** — une intention directe et une story entièrement planifiée entrent toutes deux dans `bmad-build`
|
||||
- **BMad-Help se lance automatiquement** — Chaque workflow se termine par des conseils sur la prochaine étape
|
||||
:::
|
||||
|
||||
|
||||
@@ -79,12 +79,12 @@ BMad-Help also **automatically runs at the end of every workflow**, providing cl
|
||||
|
||||
### Choose Planning Depth
|
||||
|
||||
All implementation uses `bmad-quick-dev`; scope determines what context you prepare first:
|
||||
All implementation uses `bmad-build`; scope determines what context you prepare first:
|
||||
|
||||
| Scope | Recommended preparation |
|
||||
| --- | --- |
|
||||
| **Clear updates or additions** | Enter `bmad-quick-dev` directly with the request, issue, or existing spec. |
|
||||
| **Major changes or additions** | Prepare the useful PRD, UX, architecture, epic, story, readiness, and sprint context, then pass the selected work to `bmad-quick-dev`. |
|
||||
| **Clear updates or additions** | Enter `bmad-build` directly with the request, issue, or existing spec. |
|
||||
| **Major changes or additions** | Prepare the useful PRD, UX, architecture, epic, story, readiness, and sprint context, then pass the selected work to `bmad-build`. |
|
||||
|
||||
### During PRD Creation
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ Rule of thumb: if the rule should apply everywhere an engineer does dev work, cu
|
||||
|
||||
[agent]
|
||||
|
||||
# Applied on every activation. Carries into quick-dev, code-review,
|
||||
# Applied on every activation. Carries into build, code-review,
|
||||
# qa-generate — every skill Amelia dispatches.
|
||||
persistent_facts = [
|
||||
"For any library documentation lookup (React, TypeScript, Zod, Prisma, etc.), call the context7 MCP tool (`mcp__context7__resolve_library_id` then `mcp__context7__get_library_docs`) before relying on training-data knowledge. Up-to-date docs trump memorized APIs.",
|
||||
|
||||
@@ -30,7 +30,7 @@ Clone or open the [BMAD-METHOD repo](https://github.com/bmad-code-org/BMAD-METHO
|
||||
:::note[Example]
|
||||
**Q:** "Tell me the fastest way to build something with BMad"
|
||||
|
||||
**A:** Run `bmad-quick-dev`. Give it direct intent, an issue, a spec, or a planned story; it uses the available context and chooses the clarification, planning, implementation, and review depth needed.
|
||||
**A:** Run `bmad-build`. Give it direct intent, an issue, a spec, or a planned story; it uses the available context and chooses the clarification, planning, implementation, and review depth needed.
|
||||
:::
|
||||
|
||||
**Tips for better answers:**
|
||||
|
||||
@@ -123,7 +123,7 @@ A `project-context.md` file that:
|
||||
- **Focus on the unobvious** — Document patterns agents might miss (e.g., "Use JSDoc on every public class"), not universal practices like "use meaningful variable names."
|
||||
- **Keep it lean** — This file is loaded by every implementation workflow. Long files waste context. Exclude content that only applies to narrow scope or specific stories.
|
||||
- **Update as needed** — Edit manually when patterns change, or re-generate after significant architecture changes.
|
||||
- Supports the same `bmad-quick-dev` loop whether work enters directly or after extensive planning.
|
||||
- Supports the same `bmad-build` loop whether work enters directly or after extensive planning.
|
||||
:::
|
||||
|
||||
## Next Steps
|
||||
|
||||
+15
-15
@@ -5,7 +5,7 @@ sidebar:
|
||||
order: 6
|
||||
---
|
||||
|
||||
Bug fixes, refactorings, and small targeted changes can enter **Quick Dev** directly with little or no upstream planning. This is the same implementation workflow used for fully planned stories.
|
||||
Bug fixes, refactorings, and small targeted changes can enter **Build** directly with little or no upstream planning. This is the same implementation workflow used for fully planned stories.
|
||||
|
||||
## When to Use This
|
||||
|
||||
@@ -28,28 +28,28 @@ Open a **fresh chat session** in your AI IDE. Reusing a session from a previous
|
||||
|
||||
### 2. Give It Your Intent
|
||||
|
||||
Quick Dev accepts free-form intent — before, with, or after the invocation. Examples:
|
||||
Build accepts free-form intent — before, with, or after the invocation. Examples:
|
||||
|
||||
```text
|
||||
run quick-dev — Fix the login validation bug that allows empty passwords.
|
||||
run build — Fix the login validation bug that allows empty passwords.
|
||||
```
|
||||
|
||||
```text
|
||||
run quick-dev — fix https://github.com/org/repo/issues/42
|
||||
run build — fix https://github.com/org/repo/issues/42
|
||||
```
|
||||
|
||||
```text
|
||||
run quick-dev — implement the intent in _bmad-output/implementation-artifacts/my-intent.md
|
||||
run build — implement the intent in _bmad-output/implementation-artifacts/my-intent.md
|
||||
```
|
||||
|
||||
```text
|
||||
I think the problem is in the auth middleware, it's not checking token expiry.
|
||||
Let me look at it... yeah, src/auth/middleware.ts line 47 skips
|
||||
the exp check entirely. run quick-dev
|
||||
the exp check entirely. run build
|
||||
```
|
||||
|
||||
```text
|
||||
run quick-dev
|
||||
run build
|
||||
> What would you like to do?
|
||||
Refactor UserService to use async/await instead of callbacks.
|
||||
```
|
||||
@@ -58,19 +58,19 @@ Plain text, file paths, GitHub issue URLs, bug tracker links — anything the LL
|
||||
|
||||
### 3. Answer Questions and Approve
|
||||
|
||||
Quick Dev may ask clarifying questions or present a short spec for your approval before implementing. Answer its questions and approve when you're satisfied with the plan.
|
||||
Build may ask clarifying questions or present a short spec for your approval before implementing. Answer its questions and approve when you're satisfied with the plan.
|
||||
|
||||
### 4. Review and Push
|
||||
|
||||
Quick Dev implements the change, reviews its own work, patches issues, and commits locally. When it's done, it opens the affected files in your editor.
|
||||
Build implements the change, reviews its own work, patches issues, and commits locally. When it's done, it opens the affected files in your editor.
|
||||
|
||||
- Skim the diff to confirm the change matches your intent
|
||||
- If something looks off, tell the agent what to fix — it can iterate in the same session
|
||||
|
||||
Once satisfied, push the commit. Quick Dev will offer to push and create a PR for you.
|
||||
Once satisfied, push the commit. Build will offer to push and create a PR for you.
|
||||
|
||||
:::caution[If Something Breaks]
|
||||
If a pushed change causes unexpected issues, use `git revert HEAD` to undo the last commit cleanly. Then start a fresh chat and run Quick Dev again to try a different approach.
|
||||
If a pushed change causes unexpected issues, use `git revert HEAD` to undo the last commit cleanly. Then start a fresh chat and run Build again to try a different approach.
|
||||
:::
|
||||
|
||||
## What You Get
|
||||
@@ -81,16 +81,16 @@ If a pushed change causes unexpected issues, use `git revert HEAD` to undo the l
|
||||
|
||||
## Deferred Work
|
||||
|
||||
Quick Dev keeps each run focused on a single goal. If your request contains multiple independent goals, or if the review surfaces pre-existing issues unrelated to your change, Quick Dev defers them to a file (`deferred-work.md` in your implementation artifacts directory) rather than trying to tackle everything at once.
|
||||
Build keeps each run focused on a single goal. If your request contains multiple independent goals, or if the review surfaces pre-existing issues unrelated to your change, Build defers them to a file (`deferred-work.md` in your implementation artifacts directory) rather than trying to tackle everything at once.
|
||||
|
||||
Check this file after a run — it's your backlog of things to come back to. Each deferred item can be fed into a fresh Quick Dev run later.
|
||||
Check this file after a run — it's your backlog of things to come back to. Each deferred item can be fed into a fresh Build run later.
|
||||
|
||||
## When to Add Formal Planning
|
||||
|
||||
Before running the same Quick Dev implementation loop, consider adding PRD, UX, architecture, or story planning when:
|
||||
Before running the same Build implementation loop, consider adding PRD, UX, architecture, or story planning when:
|
||||
|
||||
- The change affects multiple systems or requires coordinated updates across many files
|
||||
- You are unsure about the scope and need requirements discovery first
|
||||
- You need documentation or architectural decisions recorded for the team
|
||||
|
||||
See [Quick Dev](../explanation/quick-dev.md) for how direct intent and planned work converge on the same implementation loop.
|
||||
See [Build](../explanation/build.md) for how direct intent and planned work converge on the same implementation loop.
|
||||
|
||||
@@ -20,7 +20,7 @@ This page lists the default BMM (Agile suite) agents that install with BMad Meth
|
||||
| Analyst (Mary) | `bmad-agent-analyst` | `BP`, `MR`, `DR`, `TR`, `CB`, `WB`, `DP` | Brainstorm, Market Research, Domain Research, Technical Research, Create Brief, PRFAQ Challenge, Document Project |
|
||||
| Product Manager (John) | `bmad-agent-pm` | `PRD`, `CE`, `IR`, `CC` | Create/Update/Validate PRD, Create Epics and Stories, Implementation Readiness, Correct Course |
|
||||
| Architect (Winston) | `bmad-agent-architect` | `CA`, `IR` | Create Architecture, Implementation Readiness |
|
||||
| Developer (Amelia) | `bmad-agent-dev` | `QD`, `QA`, `CR`, `SP`, `ER` | Quick Dev, QA Test Generation, Code Review, Sprint Planning, Epic Retrospective |
|
||||
| Developer (Amelia) | `bmad-agent-dev` | `BD`, `QA`, `CR`, `SP`, `ER` | Build, QA Test Generation, Code Review, Sprint Planning, Epic Retrospective |
|
||||
| UX Designer (Sally) | `bmad-agent-ux-designer` | `CU` | Create UX Design |
|
||||
| Technical Writer (Paige) | `bmad-agent-tech-writer` | `DP`, `WD`, `MG`, `VD`, `EC` | Document Project, Write Document, Mermaid Generate, Validate Doc, Explain Concept |
|
||||
|
||||
@@ -32,7 +32,7 @@ Agent menu triggers use two different invocation types. Knowing which type a tri
|
||||
|
||||
Most triggers load a structured workflow file. Type the trigger code and the agent starts the workflow, prompting you for input at each step.
|
||||
|
||||
Examples: `PRD` (Create, update, or validate PRD), `CA` (Create Architecture), `QD` (Quick Dev)
|
||||
Examples: `PRD` (Create, update, or validate PRD), `CA` (Create Architecture), `BD` (Build)
|
||||
|
||||
### Conversational triggers (arguments required)
|
||||
|
||||
|
||||
@@ -1,17 +1,17 @@
|
||||
---
|
||||
title: Autonomous Development Loops
|
||||
description: Reference for automating the Quick Dev implementation model with bmad-dev-auto as the single-iteration worker.
|
||||
description: Reference for automating the Build implementation model with bmad-build-auto as the single-iteration worker.
|
||||
sidebar:
|
||||
order: 7
|
||||
---
|
||||
|
||||
`bmad-dev-auto` is the unattended automation surface for the canonical [Quick Dev](../explanation/quick-dev.md) implementation model. It accepts the same range of direct intent and planned work, and preserves the clarify, plan, implement, and review stages while exposing terminal statuses an orchestrator can act on. It automates the implementation loop; it does not define a second implementation path.
|
||||
`bmad-build-auto` is the unattended automation surface for the canonical [Build](../explanation/build.md) implementation model. It accepts the same range of direct intent and planned work, and preserves the clarify, plan, implement, and review stages while exposing terminal statuses an orchestrator can act on. It automates the implementation loop; it does not define a second implementation path.
|
||||
|
||||
The important architectural boundary is this: `bmad-dev-auto` owns the implementation run and the spec artifact it produces, but it does not own your backlog policy. When review finds something real that is not this story's problem, the skill records that finding in the spec it owns and stops there. Deciding whether to queue it, deduplicate it, escalate it, or ignore it is the orchestrator's responsibility.
|
||||
The important architectural boundary is this: `bmad-build-auto` owns the implementation run and the spec artifact it produces, but it does not own your backlog policy. When review finds something real that is not this story's problem, the skill records that finding in the spec it owns and stops there. Deciding whether to queue it, deduplicate it, escalate it, or ignore it is the orchestrator's responsibility.
|
||||
|
||||
## What It Does
|
||||
|
||||
`bmad-dev-auto` performs one unattended development-loop iteration:
|
||||
`bmad-build-auto` performs one unattended development-loop iteration:
|
||||
|
||||
1. Clarify the incoming intent
|
||||
2. Create (or find and resume) a spec file
|
||||
@@ -21,7 +21,7 @@ The important architectural boundary is this: `bmad-dev-auto` owns the implement
|
||||
|
||||
## Prerequisites
|
||||
|
||||
This skill relies on an ability to run subagents. If subagents are unavailable, the workflow halts `blocked` with `no subagents`. If you invoke the skill itself in a subagent session, e.g. "hey, Claude, implement stories 2-10, using a subagent running bmad-dev-auto skill for each story", that session will need to spawn its own subagents.
|
||||
This skill relies on an ability to run subagents. If subagents are unavailable, the workflow halts `blocked` with `no subagents`. If you invoke the skill itself in a subagent session, e.g. "hey, Claude, implement stories 2-10, using a subagent running bmad-build-auto skill for each story", that session will need to spawn its own subagents.
|
||||
|
||||
Version control, while optional, is strongly recommended. If present, the working tree must be clean and the agent must be able to update repository metadata.
|
||||
|
||||
@@ -29,7 +29,7 @@ Version control, while optional, is strongly recommended. If present, the workin
|
||||
|
||||
### Primary Invocation Input
|
||||
|
||||
The main input is the invocation prompt. `bmad-dev-auto` treats that prompt as workflow input, not as a finished implementation plan.
|
||||
The main input is the invocation prompt. `bmad-build-auto` treats that prompt as workflow input, not as a finished implementation plan.
|
||||
|
||||
Supported intent shapes include:
|
||||
|
||||
@@ -63,7 +63,7 @@ It then checks `<spec-folder>/stories/<story-id>-*.md` (id-prefix match) to tell
|
||||
| On-disk match | Outcome |
|
||||
| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| None | First dispatch. Requires `<spec-folder>/SPEC.md` to exist (otherwise halts `blocked` / `no epic spec found`). Loads `SPEC.md` and its companions, then proceeds to planning. |
|
||||
| Exactly one | Resume: routes on that file's `status` exactly like the Resume Input table above. A `blocked` status here reports blocking condition `story already blocked`, not `blocked spec supplied` — dev-auto discovered the file by id, the caller didn't hand it a blocked spec. A missing or unrecognized `status` halts `blocked` / `unrecognized status in existing story file`. |
|
||||
| Exactly one | Resume: routes on that file's `status` exactly like the Resume Input table above. A `blocked` status here reports blocking condition `story already blocked`, not `blocked spec supplied` — build-auto discovered the file by id, the caller didn't hand it a blocked spec. A missing or unrecognized `status` halts `blocked` / `unrecognized status in existing story file`. |
|
||||
| More than one | Halts `blocked` / `ambiguous story file match`. |
|
||||
|
||||
A `blocked` story file is permanent: every later dispatch of that id halts with `story already blocked`, even after the cause is fixed. To retry, delete the story file — the id then reads as pending and the next dispatch starts fresh.
|
||||
@@ -198,7 +198,7 @@ If the resolved path already exists, the workflow updates its `status` frontmatt
|
||||
|
||||
If the workflow halts before it has a valid `spec_file` (outside folder+id dispatch — see above), it writes:
|
||||
|
||||
`{implementation_artifacts}/bmad-dev-auto-result-<slug-or-timestamp>.md`
|
||||
`{implementation_artifacts}/bmad-build-auto-result-<slug-or-timestamp>.md`
|
||||
|
||||
This records the terminal status and blocking condition.
|
||||
|
||||
@@ -211,7 +211,7 @@ Depending on the route, the workflow may also write:
|
||||
|
||||
## Orchestrator Responsibilities
|
||||
|
||||
An orchestrator integrating `bmad-dev-auto` should:
|
||||
An orchestrator integrating `bmad-build-auto` should:
|
||||
|
||||
- Pass one coherent intent at a time
|
||||
- Prefer passing a spec path when resuming prior work — or the same spec folder and story id, under folder+id dispatch
|
||||
@@ -224,4 +224,4 @@ An orchestrator integrating `bmad-dev-auto` should:
|
||||
|
||||
In practice, `blocked` usually means the workflow ran into a situation where unattended execution would be unsafe. That is often the point where a higher-level orchestrator, another workflow, or a human should take over.
|
||||
|
||||
After resolving a blocked run, the orchestrator should usually start a fresh `bmad-dev-auto` run. If it reuses prior work, it should pass an explicit known-good spec path rather than relying on implicit discovery.
|
||||
After resolving a blocked run, the orchestrator should usually start a fresh `bmad-build-auto` run. If it reuses prior work, it should pass an explicit known-good spec path rather than relying on implicit discovery.
|
||||
@@ -14,7 +14,7 @@ BMad offers two ways to start work, and they serve different purposes.
|
||||
| Mechanism | How you invoke it | What happens |
|
||||
| --- | --- | --- |
|
||||
| **Skill** | Type the skill name (e.g. `bmad-help`) in your IDE | Directly loads an agent, runs a workflow, or executes a task |
|
||||
| **Agent menu trigger** | Load an agent first, then type a short code (e.g. `QD`) | The agent interprets the code and starts the matching workflow while staying in character |
|
||||
| **Agent menu trigger** | Load an agent first, then type a short code (e.g. `BD`) | The agent interprets the code and starts the matching workflow while staying in character |
|
||||
|
||||
Agent menu triggers require an active agent session. Use skills when you know which workflow you want. Use triggers when you are already working with an agent and want to switch tasks without leaving the conversation.
|
||||
|
||||
@@ -97,9 +97,9 @@ Workflow skills run a structured, multi-step process without loading an agent pe
|
||||
| `bmad-ux` | Design user experience |
|
||||
| `bmad-architecture` | Design system architecture |
|
||||
| `bmad-create-epics-and-stories` | Create epics and stories |
|
||||
| `bmad-quick-dev` | Implement direct intent, an issue, a feature, a fix, or a planned story |
|
||||
| `bmad-build` | Implement direct intent, an issue, a feature, a fix, or a planned story |
|
||||
| `bmad-code-review` | Run a code review |
|
||||
| `bmad-dev-auto` | Automate one unattended iteration of the Quick Dev implementation model |
|
||||
| `bmad-build-auto` | Automate one unattended iteration of the Build implementation model |
|
||||
|
||||
See [Workflow Map](./workflow-map.md) for the complete workflow reference organized by phase.
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ AI-powered tools for structured creativity, ideation, and innovation during earl
|
||||
|
||||
## Game Dev Studio
|
||||
|
||||
Structured game development workflows adapted for Unity, Unreal, Godot, and custom engines. Supports planning depths from rapid prototyping to full-scale production with epic-driven sprints; implementation converges on Quick Dev.
|
||||
Structured game development workflows adapted for Unity, Unreal, Godot, and custom engines. Supports planning depths from rapid prototyping to full-scale production with epic-driven sprints; implementation converges on Build.
|
||||
|
||||
- **Code:** `gds`
|
||||
- **npm:** [`bmad-game-dev-studio`](https://www.npmjs.com/package/bmad-game-dev-studio)
|
||||
@@ -52,7 +52,7 @@ Structured game development workflows adapted for Unity, Unreal, Godot, and cust
|
||||
**Provides:**
|
||||
|
||||
- Game Design Document (GDD) generation workflow
|
||||
- Game-aware planning and context that feed the standard Quick Dev implementation loop
|
||||
- Game-aware planning and context that feed the standard Build implementation loop
|
||||
- Narrative design support for characters, dialogue, and world-building
|
||||
- Coverage for 21+ game types with engine-specific architecture guidance
|
||||
|
||||
|
||||
@@ -97,7 +97,7 @@ TEA also supports P0-P3 risk-based prioritization and optional integrations with
|
||||
|
||||
The QA Automate workflow appears in Phase 4 (Implementation) of the BMad Method workflow map. It is designed to run **after a full epic is complete** — once all stories in an epic have been implemented and code-reviewed. A typical sequence:
|
||||
|
||||
1. For each story in the epic: implement with Quick Dev (`QD` / `bmad-quick-dev`), then optionally add Code Review (`CR`)
|
||||
1. For each story in the epic: implement with Build (`BD` / `bmad-build`), then optionally add Code Review (`CR`)
|
||||
2. After the epic is complete: generate tests with `QA` (via the Developer agent) or TEA's Automate workflow
|
||||
3. Run retrospective (`bmad-retrospective`) to capture lessons learned
|
||||
|
||||
|
||||
@@ -62,7 +62,7 @@ Define what to build and for whom.
|
||||
:::
|
||||
|
||||
:::note[`bmad-spec`]
|
||||
`bmad-spec` produces the canonical machine contract: a five-field kernel (Why, Capabilities, Constraints, Non-goals, Success signal) plus companion files, validated so every load-bearing source claim is preserved. It is the only writer of `SPEC.md`; other skills invoke it headless when they need to express or update intent. On request it can also break a spec into an ordered `stories.yaml` for autonomous dispatch — see [Autonomous Development Loops](./dev-auto.md).
|
||||
`bmad-spec` produces the canonical machine contract: a five-field kernel (Why, Capabilities, Constraints, Non-goals, Success signal) plus companion files, validated so every load-bearing source claim is preserved. It is the only writer of `SPEC.md`; other skills invoke it headless when they need to express or update intent. On request it can also break a spec into an ordered `stories.yaml` for autonomous dispatch — see [Autonomous Development Loops](./build-auto.md).
|
||||
:::
|
||||
|
||||
:::tip[Upstream: `bmad-product-brief`]
|
||||
@@ -81,11 +81,11 @@ Decide how to build it and break work into stories.
|
||||
|
||||
## Phase 4: Implementation
|
||||
|
||||
Every implementation path converges on `bmad-quick-dev`. It accepts direct intent, an issue, a specification, or a planned story, then chooses the clarification, planning, implementation, and review depth needed for that input.
|
||||
Every implementation path converges on `bmad-build`. It accepts direct intent, an issue, a specification, or a planned story, then chooses the clarification, planning, implementation, and review depth needed for that input.
|
||||
|
||||
| Workflow | Purpose | Produces |
|
||||
|----------|---------|----------|
|
||||
| `bmad-quick-dev` | Turn direct intent or a planned story into implemented, reviewed code | `spec-*.md` + code |
|
||||
| `bmad-build` | Turn direct intent or a planned story into implemented, reviewed code | `spec-*.md` + code |
|
||||
| `bmad-sprint-planning` | Initialize tracking (once per project to sequence the dev cycle) | `sprint-status.yaml` |
|
||||
| `bmad-code-review` | Ad hoc review of any code change | Findings + applied patches |
|
||||
| `bmad-correct-course` | Handle significant mid-sprint changes | Updated plan or re-routing |
|
||||
@@ -94,11 +94,11 @@ Every implementation path converges on `bmad-quick-dev`. It accepts direct inten
|
||||
|
||||
### Direct and Planned Entry
|
||||
|
||||
Clear work can enter `bmad-quick-dev` directly. Larger initiatives can first produce a PRD, UX design, architecture, epics, stories, readiness results, and sprint plan. Those artifacts add context; they do not select another implementation workflow.
|
||||
Clear work can enter `bmad-build` directly. Larger initiatives can first produce a PRD, UX design, architecture, epics, stories, readiness results, and sprint plan. Those artifacts add context; they do not select another implementation workflow.
|
||||
|
||||
`bmad-dev-auto` can orchestrate unattended iterations of the same development model when autonomous execution is appropriate.
|
||||
`bmad-build-auto` can orchestrate unattended iterations of the same development model when autonomous execution is appropriate.
|
||||
|
||||
For the reference on unattended development loops with `bmad-dev-auto`, see [Autonomous Development Loops](./dev-auto.md).
|
||||
For the reference on unattended development loops with `bmad-build-auto`, see [Autonomous Development Loops](./build-auto.md).
|
||||
|
||||
## Context Management
|
||||
|
||||
|
||||
@@ -86,7 +86,7 @@ Planning depth is flexible. Start implementation directly when the intent is alr
|
||||
| **Full solutioning** | Cross-system, high-risk, or coordinated initiatives | PRD, UX, architecture, epics, stories, and sprint plan |
|
||||
|
||||
:::note
|
||||
These are entry points, not separate implementation tracks. Every path converges on `bmad-quick-dev`; planning only changes how much context the workflow receives.
|
||||
These are entry points, not separate implementation tracks. Every path converges on `bmad-build`; planning only changes how much context the workflow receives.
|
||||
:::
|
||||
|
||||
## Installation
|
||||
@@ -190,13 +190,13 @@ Epics and stories are now created _after_ architecture. This produces better qua
|
||||
|
||||
Move to implementation from whatever context you have: a direct request, an issue, a spec, or a fully planned story. **Each workflow should run in a fresh chat.**
|
||||
|
||||
For planned work, invoke `bmad-quick-dev` and identify the selected story or sprint item, for example: `Implement story 2.3 from _bmad-output/planning-artifacts/epics.md`.
|
||||
For planned work, invoke `bmad-build` and identify the selected story or sprint item, for example: `Implement story 2.3 from _bmad-output/planning-artifacts/epics.md`.
|
||||
|
||||
### Initialize Sprint Planning (For Planned Work)
|
||||
|
||||
Invoke the **Developer agent** (`bmad-agent-dev`) and run `bmad-sprint-planning` (`bmad-sprint-planning`). This creates `sprint-status.yaml` to track all epics and stories.
|
||||
|
||||
When Quick Dev resolves a selected story in that file, it moves the story to `in-progress` during implementation and to `review` when implementation is complete.
|
||||
When Build resolves a selected story in that file, it moves the story to `in-progress` during implementation and to `review` when implementation is complete.
|
||||
|
||||
### The Build Cycle
|
||||
|
||||
@@ -204,10 +204,10 @@ For each direct change or planned story, repeat this cycle with fresh chats:
|
||||
|
||||
| Step | Agent | Workflow | Command | Purpose |
|
||||
| ---- | ----- | -------- | ------- | ------- |
|
||||
| 1 | DEV | `bmad-quick-dev` | `bmad-quick-dev` | Clarify as needed, plan, implement, review, present |
|
||||
| 1 | DEV | `bmad-build` | `bmad-build` | Clarify as needed, plan, implement, review, present |
|
||||
| 2 | DEV | `bmad-code-review` | `bmad-code-review` | Additional quality validation _(recommended)_ |
|
||||
|
||||
Quick Dev's review is part of every run. `bmad-code-review` is an optional fresh-context, independent validation layer.
|
||||
Build's review is part of every run. `bmad-code-review` is an optional fresh-context, independent validation layer.
|
||||
|
||||
After completing all stories in an epic, invoke the **Developer agent** (`bmad-agent-dev`) and run `bmad-retrospective` (`bmad-retrospective`).
|
||||
|
||||
@@ -247,13 +247,13 @@ your-project/
|
||||
| `bmad-create-epics-and-stories` | `bmad-create-epics-and-stories` | PM | Break down PRD into epics |
|
||||
| `bmad-check-implementation-readiness` | `bmad-check-implementation-readiness` | Architect | Validate planning cohesion |
|
||||
| `bmad-sprint-planning` | `bmad-sprint-planning` | DEV | Initialize sprint tracking |
|
||||
| `bmad-quick-dev` | `bmad-quick-dev` | DEV | Implement a feature, fix, or story |
|
||||
| `bmad-build` | `bmad-build` | DEV | Implement a feature, fix, or story |
|
||||
| `bmad-code-review` | `bmad-code-review` | DEV | Review implemented code |
|
||||
|
||||
## Common Questions
|
||||
|
||||
**Do I always need architecture?**
|
||||
No. Use architecture when technical decisions or cross-system constraints need to be explicit. Clear work can enter `bmad-quick-dev` directly, while larger initiatives can bring architecture and other planning artifacts into the same workflow.
|
||||
No. Use architecture when technical decisions or cross-system constraints need to be explicit. Clear work can enter `bmad-build` directly, while larger initiatives can bring architecture and other planning artifacts into the same workflow.
|
||||
|
||||
**Can I change my plan later?**
|
||||
Yes. The `bmad-correct-course` workflow handles scope changes mid-implementation.
|
||||
@@ -286,7 +286,7 @@ BMad-Help inspects your project, detects what you've completed, and tells you ex
|
||||
|
||||
- **Start with `bmad-help`** — Your intelligent guide that knows your project and options
|
||||
- **Always use fresh chats** — Start a new chat for each workflow
|
||||
- **Planning depth varies** — direct intent and fully planned stories both enter `bmad-quick-dev`
|
||||
- **Planning depth varies** — direct intent and fully planned stories both enter `bmad-build`
|
||||
- **BMad-Help runs automatically** — Every workflow ends with guidance on what's next
|
||||
:::
|
||||
|
||||
|
||||
@@ -148,7 +148,7 @@ your-project/
|
||||
| --- | --- |
|
||||
| **Trang chỉ mục / landing** | `core-concepts/index.md` |
|
||||
| **Khái niệm** | `what-are-agents.md` |
|
||||
| **Tính năng** | `quick-dev.md` |
|
||||
| **Tính năng** | `build.md` |
|
||||
| **Triết lý** | `why-solutioning-matters.md` |
|
||||
| **FAQ** | `established-projects-faq.md` |
|
||||
|
||||
|
||||
@@ -5,14 +5,14 @@ description: Lối vào triển khai thống nhất của BMad Method cho mọi
|
||||
|
||||
# BMAD Method cho Developer
|
||||
|
||||
BMAD Method dùng một workflow triển khai thống nhất cho mọi công việc phát triển: `bmad-quick-dev`.
|
||||
BMAD Method dùng một workflow triển khai thống nhất cho mọi công việc phát triển: `bmad-build`.
|
||||
|
||||
Độ sâu lập kế hoạch thay đổi theo công việc. Một yêu cầu rõ ràng có thể đi thẳng từ ý định người dùng vào implementation. Một sáng kiến lớn hơn có thể chuẩn bị PRD, UX, architecture, epics, stories, kiểm tra mức sẵn sàng và sprint planning trước. Cả hai trường hợp đều hội tụ tại `bmad-quick-dev`; các artifact lập kế hoạch chỉ cung cấp thêm ngữ cảnh cho cùng workflow.
|
||||
Độ sâu lập kế hoạch thay đổi theo công việc. Một yêu cầu rõ ràng có thể đi thẳng từ ý định người dùng vào implementation. Một sáng kiến lớn hơn có thể chuẩn bị PRD, UX, architecture, epics, stories, kiểm tra mức sẵn sàng và sprint planning trước. Cả hai trường hợp đều hội tụ tại `bmad-build`; các artifact lập kế hoạch chỉ cung cấp thêm ngữ cảnh cho cùng workflow.
|
||||
|
||||
`bmad-quick-dev` nhận yêu cầu trực tiếp, issue, spec hoặc story đã lập kế hoạch. Workflow tự xác định mức làm rõ, lập kế hoạch, triển khai và review cần thiết để hoàn thành công việc an toàn.
|
||||
`bmad-build` nhận yêu cầu trực tiếp, issue, spec hoặc story đã lập kế hoạch. Workflow tự xác định mức làm rõ, lập kế hoạch, triển khai và review cần thiết để hoàn thành công việc an toàn.
|
||||
|
||||
## Bắt đầu
|
||||
|
||||
- [Bắt đầu với BMad](./tutorials/getting-started.md)
|
||||
- [Hiểu Quick Dev](./explanation/quick-dev.md)
|
||||
- [Hiểu Build](./explanation/build.md)
|
||||
- [Xem bản đồ workflow](./reference/workflow-map.md)
|
||||
|
||||
@@ -1,19 +1,19 @@
|
||||
---
|
||||
title: "Phát triển nhanh"
|
||||
title: "Build"
|
||||
description: Giảm ma sát có người trong vòng lặp mà vẫn giữ các điểm kiểm tra bảo vệ chất lượng đầu ra
|
||||
sidebar:
|
||||
order: 7
|
||||
---
|
||||
|
||||
`bmad-quick-dev` là workflow triển khai chuẩn cho mọi công việc phát triển. Nó nhận mọi đầu vào từ ý định tự do hoặc issue đến story đã lập kế hoạch đầy đủ, rồi tạo thay đổi mã nguồn với số vòng tương tác con người tối thiểu nhưng an toàn.
|
||||
`bmad-build` là workflow triển khai chuẩn cho mọi công việc phát triển. Nó nhận mọi đầu vào từ ý định tự do hoặc issue đến story đã lập kế hoạch đầy đủ, rồi tạo thay đổi mã nguồn với số vòng tương tác con người tối thiểu nhưng an toàn.
|
||||
|
||||
Planning upstream vẫn tùy chọn và có độ sâu khác nhau. Thay đổi rõ ràng có thể vào trực tiếp; sáng kiến lớn có thể mang theo PRD, UX, kiến trúc, epic, story, kiểm tra sẵn sàng và kế hoạch sprint. Các artifact này tăng cường ngữ cảnh, không chọn workflow phát triển khác.
|
||||
|
||||
Khi một story đã lập kế hoạch đi vào Quick Dev, story vẫn là nguồn ngữ cảnh sản phẩm và tiêu chí chấp nhận. Quick Dev tạo bản ghi thực thi riêng cho lần chạy hiện tại để các quyết định triển khai và phát hiện review có thể truy vết mà không thay thế story.
|
||||
Khi một story đã lập kế hoạch đi vào Build, story vẫn là nguồn ngữ cảnh sản phẩm và tiêu chí chấp nhận. Build tạo bản ghi thực thi riêng cho lần chạy hiện tại để các quyết định triển khai và phát hiện review có thể truy vết mà không thay thế story.
|
||||
|
||||
Nó cho phép mô hình tự vận hành lâu hơn giữa các điểm kiểm tra, rồi chỉ đưa con người quay lại khi tác vụ không thể tiếp tục an toàn nếu thiếu phán đoán của con người, hoặc khi đã đến lúc rà soát kết quả cuối.
|
||||
|
||||
|
||||
|
||||
|
||||
## Vì sao nó tồn tại
|
||||
|
||||
@@ -21,7 +21,7 @@ Các lượt có người trong vòng lặp vừa cần thiết vừa tốn kém
|
||||
|
||||
LLM hiện tại vẫn thất bại theo những cách dễ đoán: hiểu sai ý định, tự điền vào khoảng trống bằng những phán đoán tự tin, lệch sang công việc không liên quan, và tạo ra các bản review nhiễu. Đồng thời, việc cần con người nhảy vào liên tục làm giảm tốc độ phát triển. Sự chú ý của con người là nút thắt.
|
||||
|
||||
`bmad-quick-dev` cân bằng lại đánh đổi đó. Nó tin mô hình có thể chạy tự chủ lâu hơn, nhưng chỉ sau khi quy trình đã tạo được một ranh giới đủ mạnh để làm điều đó an toàn.
|
||||
`bmad-build` cân bằng lại đánh đổi đó. Nó tin mô hình có thể chạy tự chủ lâu hơn, nhưng chỉ sau khi quy trình đã tạo được một ranh giới đủ mạnh để làm điều đó an toàn.
|
||||
|
||||
## Thiết kế cốt lõi
|
||||
|
||||
@@ -57,7 +57,7 @@ Bước phỏng vấn ý định có người trong vòng lặp, nhưng nó khô
|
||||
|
||||
- **Xử lý khoảng trống của ý định** - quay lại khi review cho thấy workflow không thể suy ra an toàn điều được hàm ý
|
||||
|
||||
Mọi thứ còn lại đều là ứng viên cho việc thực thi tự chủ lâu hơn. Đánh đổi này là có chủ đích. Các mẫu cũ tốn nhiều sự chú ý của con người cho việc giám sát liên tục. Quick Dev đặt nhiều niềm tin hơn vào mô hình, nhưng để dành sự chú ý của con người cho những thời điểm mà lý trí con người có đòn bẩy lớn nhất.
|
||||
Mọi thứ còn lại đều là ứng viên cho việc thực thi tự chủ lâu hơn. Đánh đổi này là có chủ đích. Các mẫu cũ tốn nhiều sự chú ý của con người cho việc giám sát liên tục. Build đặt nhiều niềm tin hơn vào mô hình, nhưng để dành sự chú ý của con người cho những thời điểm mà lý trí con người có đòn bẩy lớn nhất.
|
||||
|
||||
## Vì sao hệ thống review quan trọng
|
||||
|
||||
@@ -70,7 +70,7 @@ Rà soát kiểu agent thường sai theo hai cách:
|
||||
- Tạo quá nhiều phát hiện, buộc con người lọc quá nhiều nhiễu.
|
||||
- Làm lệch thay đổi hiện tại bằng cách kéo vào các vấn đề không liên quan, biến mỗi lần chạy thành một dự án dọn dẹp chắp vá.
|
||||
|
||||
Quick Dev xử lý cả hai bằng cách coi rà soát là bước phân loại.
|
||||
Build xử lý cả hai bằng cách coi rà soát là bước phân loại.
|
||||
|
||||
Có những phát hiện thuộc về thay đổi hiện tại. Có những phát hiện không thuộc về nó. Nếu một phát hiện chỉ là ngẫu nhiên xuất hiện, không gắn nhân quả với thay đổi đang làm, quy trình có thể trì hoãn nó thay vì ép con người xử lý ngay. Điều đó giữ cho mỗi lần chạy tập trung và ngăn các ngả rẽ ngẫu nhiên ăn hết ngân sách chú ý.
|
||||
|
||||
@@ -11,11 +11,11 @@ sidebar:
|
||||
|
||||
## Luồng điển hình
|
||||
|
||||
Bạn chạy `bmad-quick-dev`. Nó làm rõ ý định của bạn, dựng spec, triển khai thay đổi, rồi khi xong sẽ nối thêm một review trail vào file spec và mở file đó trong editor. Bạn nhìn vào spec và thấy thay đổi này chạm tới 20 file, trải trên nhiều module.
|
||||
Bạn chạy `bmad-build`. Nó làm rõ ý định của bạn, dựng spec, triển khai thay đổi, rồi khi xong sẽ nối thêm một review trail vào file spec và mở file đó trong editor. Bạn nhìn vào spec và thấy thay đổi này chạm tới 20 file, trải trên nhiều module.
|
||||
|
||||
Bạn có thể tự liếc diff. Nhưng khoảng 20 file là lúc cách đó bắt đầu kém hiệu quả: bạn mất mạch, bỏ sót liên hệ giữa hai thay đổi ở xa nhau, hoặc duyệt một thứ mà bạn chưa thực sự hiểu. Thay vì vậy, bạn nói "checkpoint" và LLM sẽ dẫn bạn đi qua thay đổi.
|
||||
|
||||
Điểm bàn giao đó, từ triển khai tự động quay lại phán đoán của con người, chính là tình huống sử dụng chính. Quick-dev có thể chạy khá lâu với rất ít giám sát. Checkpoint Preview là nơi bạn cầm lại tay lái.
|
||||
Điểm bàn giao đó, từ triển khai tự động quay lại phán đoán của con người, chính là tình huống sử dụng chính. Build có thể chạy khá lâu với rất ít giám sát. Checkpoint Preview là nơi bạn cầm lại tay lái.
|
||||
|
||||
## Vì sao nó tồn tại
|
||||
|
||||
@@ -77,7 +77,7 @@ Nếu không có review trail do tác giả tạo, workflow sẽ tự sinh một
|
||||
|
||||
## Khi nào nên dùng
|
||||
|
||||
Tình huống chính là bước bàn giao sau `bmad-quick-dev`: phần triển khai đã xong, file spec đang mở trong editor với review trail đã được nối thêm, và bạn cần quyết định có nên phát hành hay không. Lúc đó chỉ cần nói "checkpoint" là bắt đầu.
|
||||
Tình huống chính là bước bàn giao sau `bmad-build`: phần triển khai đã xong, file spec đang mở trong editor với review trail đã được nối thêm, và bạn cần quyết định có nên phát hành hay không. Lúc đó chỉ cần nói "checkpoint" là bắt đầu.
|
||||
|
||||
Nó cũng hoạt động độc lập:
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ Không sao - bạn có thể chạy nó bất cứ lúc nào. Bạn thậm chí
|
||||
|
||||
### Implementation hoạt động thế nào trong dự án đã tồn tại?
|
||||
|
||||
Chạy `bmad-quick-dev`, giống như với dự án mới. Workflow sẽ:
|
||||
Chạy `bmad-build`, giống như với dự án mới. Workflow sẽ:
|
||||
|
||||
- Tự động nhận diện stack hiện có
|
||||
- Phân tích pattern code hiện có
|
||||
@@ -41,7 +41,7 @@ Bạn có thể vào trực tiếp với thay đổi rõ ràng, hoặc cung cấ
|
||||
|
||||
### Nếu code hiện tại của tôi không theo best practices thì sao?
|
||||
|
||||
Quick Dev sẽ nhận diện quy ước hiện có và hỏi: "Tôi có nên tuân theo những quy ước hiện tại này không?" Bạn là người quyết định:
|
||||
Build sẽ nhận diện quy ước hiện có và hỏi: "Tôi có nên tuân theo những quy ước hiện tại này không?" Bạn là người quyết định:
|
||||
|
||||
- **Có** → Giữ tính nhất quán với codebase hiện tại
|
||||
- **Không** → Đặt ra chuẩn mới, đồng thời ghi rõ lý do trong spec
|
||||
|
||||
@@ -36,7 +36,7 @@ BMad hiện có sáu named agent, mỗi agent gắn với một phase trong BMad
|
||||
| 📋 **John**, Quản lý sản phẩm (Product Manager) | Planning | PRD creation, epic/story breakdown, implementation readiness |
|
||||
| 🎨 **Sally**, Nhà thiết kế UX (UX Designer) | Planning | UX design specifications |
|
||||
| 🏗️ **Winston**, Kiến trúc sư hệ thống (System Architect) | Solutioning | technical architecture, alignment checks |
|
||||
| 💻 **Amelia**, Kỹ sư cấp cao (Senior Engineer) | Implementation | story execution, quick-dev, code review, sprint planning |
|
||||
| 💻 **Amelia**, Kỹ sư cấp cao (Senior Engineer) | Implementation | story execution, build, code review, sprint planning |
|
||||
|
||||
Mỗi agent có một danh tính hardcode gồm tên, chức danh, domain, và một lớp có thể tùy chỉnh gồm vai trò, nguyên tắc, phong cách giao tiếp, icon và menu. Bạn có thể viết lại nguyên tắc của Mary hoặc thêm menu item cho cô ấy, nhưng bạn không thể đổi tên cô ấy. Đó là chủ ý thiết kế. Nhận diện thương hiệu của agent phải sống sót qua lớp tùy chỉnh để câu "hey Mary" luôn kích hoạt đúng analyst, bất kể team đã nắn hành vi của cô ấy theo cách nào.
|
||||
|
||||
@@ -77,7 +77,7 @@ Mỗi agent đi kèm một `customize.toml` với mặc định hợp lý. Team
|
||||
|
||||
Đa số người dùng không cần tự tay viết các file đó. Skill `bmad-customize` sẽ dẫn họ qua việc chọn đúng mục tiêu, quyết định override ở mức agent hay workflow, viết file và xác minh merge. Nhờ vậy bề mặt tùy chỉnh vẫn tiếp cận được với bất cứ ai hiểu ý định của mình, chứ không chỉ người rành TOML.
|
||||
|
||||
Ví dụ cụ thể: một team commit một file yêu cầu Amelia luôn dùng Context7 MCP tool khi tra tài liệu thư viện, và fallback sang Linear nếu story không xuất hiện trong danh sách epic cục bộ. Từ đó mọi dev workflow mà Amelia dispatch như `quick-dev`, `code-review`, `qa-generate` đều tự động thừa hưởng hành vi này mà không cần sửa source hay lặp lại cấu hình từng workflow.
|
||||
Ví dụ cụ thể: một team commit một file yêu cầu Amelia luôn dùng Context7 MCP tool khi tra tài liệu thư viện, và fallback sang Linear nếu story không xuất hiện trong danh sách epic cục bộ. Từ đó mọi dev workflow mà Amelia dispatch như `build`, `code-review`, `qa-generate` đều tự động thừa hưởng hành vi này mà không cần sửa source hay lặp lại cấu hình từng workflow.
|
||||
|
||||
Ngoài ra còn có một bề mặt tùy chỉnh thứ hai cho các mối quan tâm *xuyên suốt*: `_bmad/config.toml`, `_bmad/config.user.toml`, `_bmad/custom/config.toml` và `_bmad/custom/config.user.toml`. Đây là nơi **agent roster** sống, tức các descriptor gọn nhẹ mà những skill như `bmad-party-mode`, `bmad-retrospective` và `bmad-advanced-elicitation` dùng để biết ai có mặt và phải nhập vai họ thế nào. Bạn có thể rebrand một agent cho cả tổ chức bằng team override, hoặc thêm những giọng hư cấu như Kirk, Spock hay một persona chuyên gia domain qua `.user.toml`, tất cả mà không cần đụng vào thư mục skill. File per-skill quyết định Mary *hành xử* như thế nào khi cô ấy kích hoạt; cấu hình trung tâm quyết định các skill khác *nhìn thấy* cô ấy ra sao khi quan sát toàn bộ đội hình.
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ Mỗi workflow triển khai đều tự động nạp `project-context.md` nếu
|
||||
**Được nạp bởi các workflow sau:**
|
||||
- `bmad-architecture` - tôn trọng ưu tiên kỹ thuật trong giai đoạn solutioning
|
||||
- `bmad-code-review` - đối chiếu với tiêu chuẩn của dự án
|
||||
- `bmad-quick-dev` - áp dụng pattern khi lập kế hoạch và triển khai ý định trực tiếp hoặc story
|
||||
- `bmad-build` - áp dụng pattern khi lập kế hoạch và triển khai ý định trực tiếp hoặc story
|
||||
- `bmad-sprint-planning`, `bmad-retrospective`, `bmad-correct-course` - cung cấp bối cảnh cấp dự án
|
||||
|
||||
## Khi nào nên tạo
|
||||
@@ -35,7 +35,7 @@ Tệp `project-context.md` hữu ích ở bất kỳ giai đoạn nào của d
|
||||
| **Dự án mới, trước kiến trúc** | Tạo thủ công, trước `bmad-architecture` | Ghi lại ưu tiên kỹ thuật để architect tôn trọng |
|
||||
| **Dự án mới, sau kiến trúc** | Qua `bmad-generate-project-context` hoặc tạo thủ công | Ghi lại quyết định kiến trúc cho các agent triển khai |
|
||||
| **Dự án hiện có** | Qua `bmad-generate-project-context` | Khám phá pattern hiện có để agent theo đúng quy ước |
|
||||
| **Đầu vào triển khai trực tiếp** | Trước hoặc trong `bmad-quick-dev` | Đảm bảo triển khai không có planning upstream vẫn tôn trọng pattern của bạn |
|
||||
| **Đầu vào triển khai trực tiếp** | Trước hoặc trong `bmad-build` | Đảm bảo triển khai không có planning upstream vẫn tôn trọng pattern của bạn |
|
||||
|
||||
:::tip[Khuyến nghị]
|
||||
Với dự án mới, hãy tạo thủ công trước giai đoạn kiến trúc nếu bạn có ưu tiên kỹ thuật rõ ràng. Nếu không, hãy tạo nó sau kiến trúc để ghi lại các quyết định đã được đưa ra.
|
||||
|
||||
@@ -58,7 +58,7 @@ Bằng cách tài liệu hóa rõ ràng các quyết định kỹ thuật, tất
|
||||
| Nhiều epic hoặc quyết định liên hệ thống | Cần thiết để đồng bộ implementation |
|
||||
| Sáng kiến tuân thủ, rủi ro cao hoặc enterprise | Tuân theo governance bắt buộc; solutioning thường là yêu cầu |
|
||||
|
||||
Solutioning thay đổi ngữ cảnh cung cấp cho `bmad-quick-dev`, không thay đổi workflow triển khai.
|
||||
Solutioning thay đổi ngữ cảnh cung cấp cho `bmad-build`, không thay đổi workflow triển khai.
|
||||
|
||||
:::tip[Quy tắc ngón tay cái]
|
||||
Nếu bạn có nhiều epic có thể được các agent khác nhau triển khai, bạn cần solutioning.
|
||||
|
||||
@@ -77,12 +77,12 @@ BMad-Help cũng **tự động chạy ở cuối mỗi workflow**, đưa ra hư
|
||||
|
||||
### Chọn độ sâu lập kế hoạch
|
||||
|
||||
Mọi implementation đều dùng `bmad-quick-dev`; phạm vi quyết định ngữ cảnh cần chuẩn bị trước:
|
||||
Mọi implementation đều dùng `bmad-build`; phạm vi quyết định ngữ cảnh cần chuẩn bị trước:
|
||||
|
||||
| Phạm vi | Cách tiếp cận được khuyến nghị |
|
||||
| --- | --- |
|
||||
| **Cập nhật hoặc bổ sung rõ ràng** | Đi thẳng vào `bmad-quick-dev` với yêu cầu, issue hoặc spec hiện có. |
|
||||
| **Thay đổi hoặc bổ sung lớn** | Chuẩn bị PRD, UX, kiến trúc, epic, story và sprint context hữu ích, rồi đưa phần việc đã chọn vào `bmad-quick-dev`. |
|
||||
| **Cập nhật hoặc bổ sung rõ ràng** | Đi thẳng vào `bmad-build` với yêu cầu, issue hoặc spec hiện có. |
|
||||
| **Thay đổi hoặc bổ sung lớn** | Chuẩn bị PRD, UX, kiến trúc, epic, story và sprint context hữu ích, rồi đưa phần việc đã chọn vào `bmad-build`. |
|
||||
|
||||
### Khi tạo PRD
|
||||
|
||||
|
||||
@@ -45,7 +45,7 @@ Nguyên tắc ngón tay cái:
|
||||
|
||||
[agent]
|
||||
|
||||
# Áp dụng ở mọi lần kích hoạt. Theo Amelia đi vào quick-dev,
|
||||
# Áp dụng ở mọi lần kích hoạt. Theo Amelia đi vào build,
|
||||
# code-review, qa-generate và mọi skill cô ấy dispatch.
|
||||
persistent_facts = [
|
||||
"Với mọi truy vấn tài liệu thư viện như React, TypeScript, Zod, Prisma..., hãy gọi Context7 MCP tool (`mcp__context7__resolve_library_id` rồi `mcp__context7__get_library_docs`) trước khi dựa vào kiến thức trong dữ liệu huấn luyện (training data). Tài liệu cập nhật phải thắng API đã ghi nhớ.",
|
||||
|
||||
@@ -30,7 +30,7 @@ Hãy clone hoặc mở [repo BMAD-METHOD](https://github.com/bmad-code-org/BMAD-
|
||||
:::note[Ví dụ]
|
||||
**Q:** "Hãy chỉ tôi cách nhanh nhất để xây dựng một thứ gì đó bằng BMad"
|
||||
|
||||
**A:** Chạy `bmad-quick-dev`. Đưa vào ý định trực tiếp, issue, spec hoặc story đã lập kế hoạch; workflow dùng ngữ cảnh sẵn có và chọn độ sâu làm rõ, lập kế hoạch, triển khai và review cần thiết.
|
||||
**A:** Chạy `bmad-build`. Đưa vào ý định trực tiếp, issue, spec hoặc story đã lập kế hoạch; workflow dùng ngữ cảnh sẵn có và chọn độ sâu làm rõ, lập kế hoạch, triển khai và review cần thiết.
|
||||
:::
|
||||
|
||||
**Mẹo để có câu trả lời tốt hơn:**
|
||||
|
||||
@@ -118,7 +118,7 @@ Một tệp `project-context.md` sẽ:
|
||||
- **Tập trung vào điều không hiển nhiên** - Ghi lại những pattern agent dễ bỏ sót (ví dụ: "Dùng JSDoc cho mọi lớp public"), thay vì các quy tắc phổ quát như "đặt tên biến có ý nghĩa".
|
||||
- **Gọn nhẹ** - Tệp này được nạp trong mọi workflow triển khai. Tệp quá dài sẽ tốn context. Hãy bỏ qua nội dung chỉ áp dụng cho phạm vi hẹp hoặc một vài story cụ thể.
|
||||
- **Cập nhật khi cần** - Sửa thủ công khi pattern thay đổi, hoặc tạo lại sau các thay đổi kiến trúc lớn.
|
||||
- Hỗ trợ cùng loop `bmad-quick-dev` dù công việc vào trực tiếp hay sau planning sâu.
|
||||
- Hỗ trợ cùng loop `bmad-build` dù công việc vào trực tiếp hay sau planning sâu.
|
||||
:::
|
||||
|
||||
## Bước tiếp theo
|
||||
|
||||
@@ -5,7 +5,7 @@ sidebar:
|
||||
order: 6
|
||||
---
|
||||
|
||||
Sửa lỗi, refactor và thay đổi nhỏ có thể đi thẳng vào **Quick Dev** với ít hoặc không có planning upstream. Đây là cùng workflow triển khai dùng cho story đã lập kế hoạch đầy đủ.
|
||||
Sửa lỗi, refactor và thay đổi nhỏ có thể đi thẳng vào **Build** với ít hoặc không có planning upstream. Đây là cùng workflow triển khai dùng cho story đã lập kế hoạch đầy đủ.
|
||||
|
||||
## Khi nào nên dùng
|
||||
|
||||
@@ -27,28 +27,28 @@ Mở **một phiên chat mới** trong AI IDE của bạn. Tái sử dụng mộ
|
||||
|
||||
### 2. Mô tả ý định của bạn
|
||||
|
||||
Quick Dev nhận ý định dạng tự do - trước, cùng lúc, hoặc sau khi gọi workflow. Ví dụ:
|
||||
Build nhận ý định dạng tự do - trước, cùng lúc, hoặc sau khi gọi workflow. Ví dụ:
|
||||
|
||||
```text
|
||||
run quick-dev — Sửa lỗi validate đăng nhập cho phép mật khẩu rỗng.
|
||||
run build — Sửa lỗi validate đăng nhập cho phép mật khẩu rỗng.
|
||||
```
|
||||
|
||||
```text
|
||||
run quick-dev — fix https://github.com/org/repo/issues/42
|
||||
run build — fix https://github.com/org/repo/issues/42
|
||||
```
|
||||
|
||||
```text
|
||||
run quick-dev — thực hiện ý định trong _bmad-output/implementation-artifacts/my-intent.md
|
||||
run build — thực hiện ý định trong _bmad-output/implementation-artifacts/my-intent.md
|
||||
```
|
||||
|
||||
```text
|
||||
Tôi nghĩ vấn đề nằm ở auth middleware, nó không kiểm tra hạn của token.
|
||||
Để tôi xem... đúng rồi, src/auth/middleware.ts dòng 47 bỏ qua
|
||||
hoàn toàn phần kiểm tra exp. run quick-dev
|
||||
hoàn toàn phần kiểm tra exp. run build
|
||||
```
|
||||
|
||||
```text
|
||||
run quick-dev
|
||||
run build
|
||||
> Bạn muốn làm gì?
|
||||
Refactor UserService sang dùng async/await thay vì callbacks.
|
||||
```
|
||||
@@ -57,19 +57,19 @@ Văn bản thường, đường dẫn tệp, URL issue GitHub, liên kết bug t
|
||||
|
||||
### 3. Trả lời câu hỏi và phê duyệt
|
||||
|
||||
Quick Dev có thể đặt câu hỏi làm rõ hoặc đưa ra một bản spec ngắn để bạn phê duyệt trước khi triển khai. Hãy trả lời và phê duyệt khi bạn thấy kế hoạch đã ổn.
|
||||
Build có thể đặt câu hỏi làm rõ hoặc đưa ra một bản spec ngắn để bạn phê duyệt trước khi triển khai. Hãy trả lời và phê duyệt khi bạn thấy kế hoạch đã ổn.
|
||||
|
||||
### 4. Review và push
|
||||
|
||||
Quick Dev sẽ triển khai thay đổi, tự review công việc của mình, sửa các vấn đề phát hiện được và commit vào local. Khi hoàn thành, nó sẽ mở các tệp bị ảnh hưởng trong editor.
|
||||
Build sẽ triển khai thay đổi, tự review công việc của mình, sửa các vấn đề phát hiện được và commit vào local. Khi hoàn thành, nó sẽ mở các tệp bị ảnh hưởng trong editor.
|
||||
|
||||
- Xem nhanh diff để xác nhận thay đổi đúng với ý định của bạn
|
||||
- Nếu có gì không ổn, nói cho agent biết cần sửa gì - nó có thể lặp lại ngay trong cùng phiên
|
||||
|
||||
Khi đã hài lòng, push commit. Quick Dev sẽ đề xuất push và tạo PR cho bạn.
|
||||
Khi đã hài lòng, push commit. Build sẽ đề xuất push và tạo PR cho bạn.
|
||||
|
||||
:::caution[Nếu có thứ bị vỡ]
|
||||
Nếu thay đổi đã push gây sự cố ngoài ý muốn, dùng `git revert HEAD` để hoàn tác commit cuối một cách sạch sẽ. Sau đó bắt đầu một phiên chat mới và chạy lại Quick Dev để thử hướng khác.
|
||||
Nếu thay đổi đã push gây sự cố ngoài ý muốn, dùng `git revert HEAD` để hoàn tác commit cuối một cách sạch sẽ. Sau đó bắt đầu một phiên chat mới và chạy lại Build để thử hướng khác.
|
||||
:::
|
||||
|
||||
## Bạn nhận được gì
|
||||
@@ -80,16 +80,16 @@ Nếu thay đổi đã push gây sự cố ngoài ý muốn, dùng `git revert H
|
||||
|
||||
## Công việc trì hoãn
|
||||
|
||||
Quick Dev giữ mỗi lần chạy tập trung vào một mục tiêu duy nhất. Nếu yêu cầu của bạn có nhiều mục tiêu độc lập, hoặc review phát hiện các vấn đề tồn tại sẵn không liên quan đến thay đổi hiện tại, Quick Dev sẽ đưa chúng vào tệp `deferred-work.md` trong thư mục implementation artifacts thay vì cố gắng xử lý tất cả một lúc.
|
||||
Build giữ mỗi lần chạy tập trung vào một mục tiêu duy nhất. Nếu yêu cầu của bạn có nhiều mục tiêu độc lập, hoặc review phát hiện các vấn đề tồn tại sẵn không liên quan đến thay đổi hiện tại, Build sẽ đưa chúng vào tệp `deferred-work.md` trong thư mục implementation artifacts thay vì cố gắng xử lý tất cả một lúc.
|
||||
|
||||
Hãy kiểm tra tệp này sau mỗi lần chạy - đó là backlog các việc bạn cần quay lại sau. Mỗi mục trì hoãn có thể được đưa vào một lần chạy Quick Dev mới.
|
||||
Hãy kiểm tra tệp này sau mỗi lần chạy - đó là backlog các việc bạn cần quay lại sau. Mỗi mục trì hoãn có thể được đưa vào một lần chạy Build mới.
|
||||
|
||||
## Khi nào nên bổ sung lập kế hoạch đầy đủ
|
||||
|
||||
Trước khi chạy cùng Quick Dev loop, cân nhắc bổ sung PRD, UX, kiến trúc hoặc lập kế hoạch story khi:
|
||||
Trước khi chạy cùng Build loop, cân nhắc bổ sung PRD, UX, kiến trúc hoặc lập kế hoạch story khi:
|
||||
|
||||
- Thay đổi ảnh hưởng nhiều hệ thống hoặc cần cập nhật đồng bộ trên nhiều tệp
|
||||
- Bạn chưa chắc phạm vi và cần làm rõ yêu cầu trước
|
||||
- Bạn cần ghi lại tài liệu hoặc quyết định kiến trúc cho cả nhóm
|
||||
|
||||
Xem [Quick Dev](../explanation/quick-dev.md) để hiểu cách ý định trực tiếp và công việc đã lập kế hoạch hội tụ vào cùng một vòng triển khai.
|
||||
Xem [Build](../explanation/build.md) để hiểu cách ý định trực tiếp và công việc đã lập kế hoạch hội tụ vào cùng một vòng triển khai.
|
||||
|
||||
@@ -20,7 +20,7 @@ Trang này liệt kê các agent mặc định của BMM (bộ Agile suite) đư
|
||||
| Analyst (Mary) | `bmad-analyst` | `BP`, `MR`, `DR`, `TR`, `CB`, `WB`, `DP` | Brainstorm, Market Research, Domain Research, Technical Research, Create Brief, PRFAQ Challenge, Document Project |
|
||||
| Product Manager (John) | `bmad-pm` | `CP`, `VP`, `EP`, `CE`, `IR`, `CC` | Create/Validate/Edit PRD, Create Epics and Stories, Implementation Readiness, Correct Course |
|
||||
| Architect (Winston) | `bmad-architect` | `CA`, `IR` | Create Architecture, Implementation Readiness |
|
||||
| Developer (Amelia) | `bmad-agent-dev` | `QD`, `QA`, `CR`, `SP`, `ER` | Quick Dev, QA Test Generation, Code Review, Sprint Planning, Epic Retrospective |
|
||||
| Developer (Amelia) | `bmad-agent-dev` | `BD`, `QA`, `CR`, `SP`, `ER` | Build, QA Test Generation, Code Review, Sprint Planning, Epic Retrospective |
|
||||
| UX Designer (Sally) | `bmad-ux-designer` | `CU` | Create UX Design |
|
||||
| Technical Writer (Paige) | `bmad-tech-writer` | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | Document Project, Write Document, Update Standards, Mermaid Generate, Validate Doc, Explain Concept |
|
||||
|
||||
@@ -32,7 +32,7 @@ Trigger trong menu agent dùng hai kiểu gọi khác nhau. Biết trigger thu
|
||||
|
||||
Phần lớn trigger sẽ nạp một file workflow có cấu trúc. Bạn gõ mã trigger, agent sẽ bắt đầu workflow và nhắc bạn nhập thông tin ở từng bước.
|
||||
|
||||
Ví dụ: `CP` (Create PRD), `CA` (Create Architecture), `QD` (Quick Dev)
|
||||
Ví dụ: `CP` (Create PRD), `CA` (Create Architecture), `BD` (Build)
|
||||
|
||||
### Trigger hội thoại (cần tham số)
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ BMad cung cấp hai cách để bắt đầu công việc, và chúng phục v
|
||||
| Cơ chế | Cách gọi | Điều xảy ra |
|
||||
| --- | --- | --- |
|
||||
| **Skill** | Gõ tên skill, ví dụ `bmad-help`, trong IDE | Nạp trực tiếp agent, chạy workflow hoặc thực thi task |
|
||||
| **Trigger menu agent** | Nạp agent trước, sau đó gõ mã ngắn như `QD` | Agent diễn giải mã đó và bắt đầu workflow tương ứng trong khi vẫn giữ đúng persona |
|
||||
| **Trigger menu agent** | Nạp agent trước, sau đó gõ mã ngắn như `BD` | Agent diễn giải mã đó và bắt đầu workflow tương ứng trong khi vẫn giữ đúng persona |
|
||||
|
||||
Trigger trong menu agent yêu cầu bạn đang ở trong một phiên agent đang hoạt động. Dùng skill khi bạn đã biết mình muốn workflow nào. Dùng trigger khi bạn đang làm việc với một agent và muốn đổi tác vụ mà không rời khỏi cuộc hội thoại.
|
||||
|
||||
@@ -97,7 +97,7 @@ Workflow skills chạy một quy trình có cấu trúc, nhiều bước mà kh
|
||||
| `bmad-architecture` | Thiết kế kiến trúc hệ thống |
|
||||
| `bmad-create-epics-and-stories` | Tạo epics và stories |
|
||||
| `bmad-code-review` | Chạy code review |
|
||||
| `bmad-quick-dev` | Triển khai ý định trực tiếp, issue, tính năng, bản sửa hoặc story đã lập kế hoạch |
|
||||
| `bmad-build` | Triển khai ý định trực tiếp, issue, tính năng, bản sửa hoặc story đã lập kế hoạch |
|
||||
|
||||
Xem [Workflow Map](./workflow-map.md) để có tài liệu workflow đầy đủ theo từng phase.
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ Bộ công cụ vận hành bởi AI dành cho sáng tạo có cấu trúc, phá
|
||||
|
||||
## Game Dev Studio
|
||||
|
||||
Các workflow phát triển game có cấu trúc, được điều chỉnh cho Unity, Unreal, Godot và các engine tùy chỉnh. Hỗ trợ độ sâu planning từ prototype nhanh đến sản xuất toàn diện; implementation hội tụ vào Quick Dev.
|
||||
Các workflow phát triển game có cấu trúc, được điều chỉnh cho Unity, Unreal, Godot và các engine tùy chỉnh. Hỗ trợ độ sâu planning từ prototype nhanh đến sản xuất toàn diện; implementation hội tụ vào Build.
|
||||
|
||||
- **Mã:** `gds`
|
||||
- **npm:** [`bmad-game-dev-studio`](https://www.npmjs.com/package/bmad-game-dev-studio)
|
||||
@@ -52,7 +52,7 @@ Các workflow phát triển game có cấu trúc, được điều chỉnh cho U
|
||||
**Cung cấp:**
|
||||
|
||||
- Workflow tạo Game Design Document (GDD)
|
||||
- Ngữ cảnh và planning game-specific cho implementation loop Quick Dev chuẩn
|
||||
- Ngữ cảnh và planning game-specific cho implementation loop Build chuẩn
|
||||
- Hỗ trợ thiết kế narrative cho nhân vật, hội thoại và world-building
|
||||
- Bao phủ hơn 21 thể loại game cùng hướng dẫn kiến trúc theo engine
|
||||
|
||||
|
||||
@@ -97,7 +97,7 @@ TEA cũng hỗ trợ ưu tiên theo rủi ro P0-P3 và tích hợp tùy chọn v
|
||||
|
||||
Workflow QA Automate xuất hiện ở Phase 4 (Implementation) trong workflow map của BMad Method. Nó được thiết kế để chạy **sau khi hoàn tất trọn vẹn một epic** — tức là khi mọi story trong epic đó đã được triển khai và code review xong. Trình tự điển hình là:
|
||||
|
||||
1. Với mỗi story trong epic: triển khai bằng Quick Dev (`QD` / `bmad-quick-dev`), sau đó thêm Code Review (`CR`) khi cần
|
||||
1. Với mỗi story trong epic: triển khai bằng Build (`BD` / `bmad-build`), sau đó thêm Code Review (`CR`) khi cần
|
||||
2. Sau khi epic hoàn tất: tạo test bằng `QA` (thông qua Developer agent) hoặc workflow Automate của TEA
|
||||
3. Chạy retrospective (`bmad-retrospective`) để ghi nhận bài học rút ra
|
||||
|
||||
|
||||
@@ -52,11 +52,11 @@ Quyết định cách xây và chia nhỏ công việc thành các story.
|
||||
|
||||
## Giai đoạn 4: Triển khai
|
||||
|
||||
Mọi đầu vào triển khai đều hội tụ vào `bmad-quick-dev`. Workflow này nhận ý định trực tiếp, issue, đặc tả hoặc story đã lập kế hoạch, rồi chọn mức làm rõ, lập kế hoạch, triển khai và review phù hợp.
|
||||
Mọi đầu vào triển khai đều hội tụ vào `bmad-build`. Workflow này nhận ý định trực tiếp, issue, đặc tả hoặc story đã lập kế hoạch, rồi chọn mức làm rõ, lập kế hoạch, triển khai và review phù hợp.
|
||||
|
||||
| Quy trình | Mục đích | Tạo ra |
|
||||
| -------------------------- | ------------------------------------------------------------------------ | -------------------------------- |
|
||||
| `bmad-quick-dev` | Biến ý định trực tiếp hoặc story đã lập kế hoạch thành mã nguồn đã triển khai và review | `spec-*.md` + mã nguồn |
|
||||
| `bmad-build` | Biến ý định trực tiếp hoặc story đã lập kế hoạch thành mã nguồn đã triển khai và review | `spec-*.md` + mã nguồn |
|
||||
| `bmad-sprint-planning` | Khởi tạo theo dõi, thường chạy một lần mỗi dự án để sắp thứ tự chu trình phát triển | `sprint-status.yaml` |
|
||||
| `bmad-code-review` | Kiểm tra chất lượng phần triển khai | Được duyệt hoặc yêu cầu thay đổi |
|
||||
| `bmad-correct-course` | Xử lý thay đổi lớn giữa sprint | Kế hoạch cập nhật hoặc định tuyến lại |
|
||||
@@ -65,7 +65,7 @@ Mọi đầu vào triển khai đều hội tụ vào `bmad-quick-dev`. Workflow
|
||||
|
||||
### Đầu vào trực tiếp và đã lập kế hoạch
|
||||
|
||||
Công việc rõ ràng có thể đi thẳng vào `bmad-quick-dev`. Sáng kiến lớn hơn có thể chuẩn bị PRD, UX, kiến trúc, epic, story, kiểm tra mức sẵn sàng và kế hoạch sprint trước. Các artifact này bổ sung ngữ cảnh, không chọn một workflow triển khai khác.
|
||||
Công việc rõ ràng có thể đi thẳng vào `bmad-build`. Sáng kiến lớn hơn có thể chuẩn bị PRD, UX, kiến trúc, epic, story, kiểm tra mức sẵn sàng và kế hoạch sprint trước. Các artifact này bổ sung ngữ cảnh, không chọn một workflow triển khai khác.
|
||||
|
||||
## Quản lý ngữ cảnh
|
||||
|
||||
|
||||
@@ -84,7 +84,7 @@ BMad giúp bạn xây dựng phần mềm thông qua các workflow có hướng
|
||||
| **Định hình giải pháp đầy đủ** | Sáng kiến phối hợp, rủi ro cao hoặc liên hệ thống | PRD, UX, kiến trúc, epic, story và kế hoạch sprint |
|
||||
|
||||
:::note
|
||||
Đây không phải các nhánh triển khai riêng. Mọi đầu vào đều hội tụ vào `bmad-quick-dev`; lập kế hoạch chỉ thay đổi lượng ngữ cảnh sẵn có.
|
||||
Đây không phải các nhánh triển khai riêng. Mọi đầu vào đều hội tụ vào `bmad-build`; lập kế hoạch chỉ thay đổi lượng ngữ cảnh sẵn có.
|
||||
:::
|
||||
|
||||
## Cài Đặt
|
||||
@@ -176,13 +176,13 @@ Epics và stories giờ được tạo *sau* kiến trúc. Điều này giúp st
|
||||
|
||||
Chuyển sang implementation với ngữ cảnh đang có: yêu cầu trực tiếp, issue, spec hoặc story đã được lập kế hoạch đầy đủ. **Mỗi workflow nên chạy trong một chat mới.**
|
||||
|
||||
Với công việc đã lập kế hoạch, chạy `bmad-quick-dev` và nêu rõ story hoặc hạng mục sprint đã chọn, ví dụ: `Triển khai story 2.3 từ _bmad-output/planning-artifacts/epics.md`.
|
||||
Với công việc đã lập kế hoạch, chạy `bmad-build` và nêu rõ story hoặc hạng mục sprint đã chọn, ví dụ: `Triển khai story 2.3 từ _bmad-output/planning-artifacts/epics.md`.
|
||||
|
||||
### Khởi Tạo Sprint Planning (Cho công việc đã lập kế hoạch)
|
||||
|
||||
Gọi **Developer agent** (`bmad-agent-dev`) và chạy `bmad-sprint-planning` (`bmad-sprint-planning`). Workflow này sẽ tạo `sprint-status.yaml` để theo dõi toàn bộ epic và story.
|
||||
|
||||
Khi Quick Dev nhận diện được story đã chọn trong file này, workflow chuyển story sang `in-progress` trong lúc triển khai và sang `review` khi triển khai hoàn tất.
|
||||
Khi Build nhận diện được story đã chọn trong file này, workflow chuyển story sang `in-progress` trong lúc triển khai và sang `review` khi triển khai hoàn tất.
|
||||
|
||||
### Chu Trình Xây Dựng
|
||||
|
||||
@@ -190,10 +190,10 @@ Với mỗi thay đổi trực tiếp hoặc story đã lập kế hoạch, lặ
|
||||
|
||||
| Bước | Agent | Workflow | Lệnh | Mục đích |
|
||||
| ---- | ----- | -------------- | -------------------------- | ---------------------------------- |
|
||||
| 1 | DEV | `bmad-quick-dev` | `bmad-quick-dev` | Làm rõ, lập kế hoạch, triển khai, review và trình bày |
|
||||
| 1 | DEV | `bmad-build` | `bmad-build` | Làm rõ, lập kế hoạch, triển khai, review và trình bày |
|
||||
| 2 | DEV | `bmad-code-review` | `bmad-code-review` | Kiểm tra chất lượng bổ sung *(khuyến nghị)* |
|
||||
|
||||
Review của Quick Dev là một phần của mọi lần chạy. `bmad-code-review` là lớp xác thực độc lập, tùy chọn trong một ngữ cảnh mới.
|
||||
Review của Build là một phần của mọi lần chạy. `bmad-code-review` là lớp xác thực độc lập, tùy chọn trong một ngữ cảnh mới.
|
||||
|
||||
Sau khi hoàn tất tất cả story trong một epic, hãy gọi **Developer agent** (`bmad-agent-dev`) và chạy `bmad-retrospective` (`bmad-retrospective`).
|
||||
|
||||
@@ -233,13 +233,13 @@ your-project/
|
||||
| `bmad-create-epics-and-stories` | `bmad-create-epics-and-stories` | PM | Phân rã PRD thành epics |
|
||||
| `bmad-check-implementation-readiness` | `bmad-check-implementation-readiness` | Architect | Kiểm tra độ nhất quán của kế hoạch |
|
||||
| `bmad-sprint-planning` | `bmad-sprint-planning` | DEV | Khởi tạo theo dõi sprint |
|
||||
| `bmad-quick-dev` | `bmad-quick-dev` | DEV | Triển khai ý định, issue, tính năng, bản sửa hoặc story |
|
||||
| `bmad-build` | `bmad-build` | DEV | Triển khai ý định, issue, tính năng, bản sửa hoặc story |
|
||||
| `bmad-code-review` | `bmad-code-review` | DEV | Review phần code đã triển khai |
|
||||
|
||||
## Câu Hỏi Thường Gặp
|
||||
|
||||
**Lúc nào cũng cần kiến trúc à?**
|
||||
Không. Dùng kiến trúc khi cần làm rõ quyết định kỹ thuật hoặc ràng buộc liên hệ thống. Công việc rõ ràng có thể đi thẳng vào `bmad-quick-dev`; sáng kiến lớn đưa các artifact lập kế hoạch vào cùng workflow đó.
|
||||
Không. Dùng kiến trúc khi cần làm rõ quyết định kỹ thuật hoặc ràng buộc liên hệ thống. Công việc rõ ràng có thể đi thẳng vào `bmad-build`; sáng kiến lớn đưa các artifact lập kế hoạch vào cùng workflow đó.
|
||||
|
||||
**Tôi có thể đổi kế hoạch về sau không?**
|
||||
Có. Workflow `bmad-correct-course` (`bmad-correct-course`) xử lý thay đổi phạm vi giữa chừng.
|
||||
@@ -270,7 +270,7 @@ BMad-Help sẽ kiểm tra dự án, phát hiện những gì bạn đã hoàn th
|
||||
:::tip[Hãy Nhớ Các Điểm Này]
|
||||
- **Bắt đầu với `bmad-help`** — Trợ lý thông minh hiểu dự án và các lựa chọn của bạn
|
||||
- **Luôn dùng chat mới** — Mỗi workflow nên bắt đầu trong một chat riêng
|
||||
- **Độ sâu lập kế hoạch thay đổi** — ý định trực tiếp và story đã lập kế hoạch đều đi vào `bmad-quick-dev`
|
||||
- **Độ sâu lập kế hoạch thay đổi** — ý định trực tiếp và story đã lập kế hoạch đều đi vào `bmad-build`
|
||||
- **BMad-Help chạy tự động** — Mỗi workflow đều kết thúc bằng hướng dẫn về bước tiếp theo
|
||||
:::
|
||||
|
||||
|
||||
@@ -148,7 +148,7 @@ your-project/
|
||||
| --- | --- |
|
||||
| **Index/Landing** | `core-concepts/index.md` |
|
||||
| **Concept** | `what-are-agents.md` |
|
||||
| **Feature** | `quick-dev.md` |
|
||||
| **Feature** | `build.md` |
|
||||
| **Philosophy** | `why-solutioning-matters.md` |
|
||||
| **FAQ** | `established-projects-faq.md` |
|
||||
|
||||
|
||||
@@ -46,11 +46,11 @@ sidebar:
|
||||
把发现分成三类：必须修、可延后、可忽略。评审质量的关键不在”发现数量”，而在分诊质量。
|
||||
:::
|
||||
|
||||
如果你想把该策略放进快速实现节奏中，可参见 [快速开发](./quick-dev.md)；若要做多轮推理补强，可参见 [高级启发](./advanced-elicitation.md)。整体流程位置请见 [工作流地图](../reference/workflow-map.md)。
|
||||
如果你想把该策略放进快速实现节奏中，可参见 [Build](./build.md)；若要做多轮推理补强，可参见 [高级启发](./advanced-elicitation.md)。整体流程位置请见 [工作流地图](../reference/workflow-map.md)。
|
||||
|
||||
## 与 Quick Dev 的关系
|
||||
## 与 Build 的关系
|
||||
|
||||
`bmad-quick-dev` 关注执行效率与边界控制；对抗性评审关注问题发现质量。
|
||||
`bmad-build` 关注执行效率与边界控制；对抗性评审关注问题发现质量。
|
||||
一个解决“跑得稳不稳”，一个解决“看得深不深”，两者互补而非替代。
|
||||
|
||||
## 示例（对比）
|
||||
@@ -68,6 +68,6 @@ sidebar:
|
||||
|
||||
## 继续阅读
|
||||
|
||||
- [快速开发](./quick-dev.md)
|
||||
- [Build](./build.md)
|
||||
- [高级启发](./advanced-elicitation.md)
|
||||
- [工作流地图](../reference/workflow-map.md)
|
||||
|
||||
@@ -1,26 +1,26 @@
|
||||
---
|
||||
title: "快速开发"
|
||||
title: "Build"
|
||||
description: 在不牺牲输出质量检查点的情况下减少人机交互的摩擦
|
||||
sidebar:
|
||||
order: 7
|
||||
---
|
||||
|
||||
`bmad-quick-dev` 是所有开发工作的标准实施 workflow。它既可接收自由意图或 issue，也可接收完整规划的 story，并在安全前提下用尽可能少的人机交互完成代码变更。
|
||||
`bmad-build` 是所有开发工作的标准实施 workflow。它既可接收自由意图或 issue，也可接收完整规划的 story，并在安全前提下用尽可能少的人机交互完成代码变更。
|
||||
|
||||
上游规划仍然可选且深度可变。清晰变更可以直接进入；大型项目可以携带 PRD、UX、架构、epics、stories、就绪检查和 sprint 计划。这些产物会增强上下文，而不是选择另一条开发 workflow。
|
||||
|
||||
当已规划的 story 进入 Quick Dev 时，它仍然是产品上下文和验收标准的来源。Quick Dev 会为当前运行创建自己的执行记录，使实施决策和审查发现可追溯，但不会取代上游 story。
|
||||
当已规划的 story 进入 Build 时，它仍然是产品上下文和验收标准的来源。Build 会为当前运行创建自己的执行记录，使实施决策和审查发现可追溯，但不会取代上游 story。
|
||||
|
||||
|
||||
|
||||
|
||||
## 它解决什么问题
|
||||
|
||||
纯人工频繁盯流程会拖慢速度，纯自动又容易偏航。Quick Dev 做的是中间解：
|
||||
纯人工频繁盯流程会拖慢速度，纯自动又容易偏航。Build 做的是中间解：
|
||||
- 在关键节点保留人工判断
|
||||
- 在可控区间放大模型自主执行时长
|
||||
- 通过规范与审查把偏航风险收回来
|
||||
|
||||
## Quick Dev 的核心机制
|
||||
## Build 的核心机制
|
||||
|
||||
### 1. 先把意图压缩成单一目标
|
||||
|
||||
@@ -42,7 +42,7 @@ sidebar:
|
||||
|
||||
### 4. 在正确层级修复问题
|
||||
|
||||
Quick Dev 会区分问题来源：
|
||||
Build 会区分问题来源：
|
||||
- **意图层问题**：需求理解本身不对
|
||||
- **规范层问题**：tech-spec 边界不够强
|
||||
- **实现层问题**：本地代码缺陷
|
||||
@@ -58,16 +58,16 @@ Quick Dev 会区分问题来源：
|
||||
|
||||
## 为什么它和“普通自动化”不一样
|
||||
|
||||
Quick Dev 不追求“全自动”，而是追求“最少但有效的人类判断”。
|
||||
Build 不追求“全自动”，而是追求“最少但有效的人类判断”。
|
||||
它把人工注意力从大量低价值确认，转移到少量高价值决策。
|
||||
|
||||
## 与对抗性评审的关系
|
||||
|
||||
Quick Dev 是执行节奏设计；`adversarial review` 是审查策略。二者经常配合：
|
||||
- Quick Dev 负责高效推进实现
|
||||
Build 是执行节奏设计；`adversarial review` 是审查策略。二者经常配合：
|
||||
- Build 负责高效推进实现
|
||||
- 对抗性评审负责提高问题发现率并做分诊
|
||||
|
||||
也就是说，Quick Dev 解决“怎么更快且更稳地跑”，对抗性评审解决“怎么更狠地查问题”。
|
||||
也就是说，Build 解决“怎么更快且更稳地跑”，对抗性评审解决“怎么更狠地查问题”。
|
||||
|
||||
## 适用边界
|
||||
|
||||
@@ -80,7 +80,7 @@ Quick Dev 是执行节奏设计；`adversarial review` 是审查策略。二者
|
||||
- 团队尚未接受“先规格后长时执行”的工作方式
|
||||
|
||||
:::tip[实践建议]
|
||||
先把成功标准写清楚，再启用 Quick Dev。目标越清楚，自动化收益越大。
|
||||
先把成功标准写清楚，再启用 Build。目标越清楚，自动化收益越大。
|
||||
:::
|
||||
|
||||
## 继续阅读
|
||||
@@ -11,11 +11,11 @@ sidebar:
|
||||
|
||||
## 典型流程
|
||||
|
||||
你运行 `bmad-quick-dev`。它澄清你的意图、构建规范、实现变更，完成后将审查线索追加到 spec 文件并在编辑器中打开。你查看 spec，发现这次变更涉及跨多个模块的 20 个文件。
|
||||
你运行 `bmad-build`。它澄清你的意图、构建规范、实现变更，完成后将审查线索追加到 spec 文件并在编辑器中打开。你查看 spec，发现这次变更涉及跨多个模块的 20 个文件。
|
||||
|
||||
你可以肉眼扫一遍 diff。但 20 个文件正是肉眼审查开始失效的临界点——你会丢失线索，漏掉两个相距甚远的变更之间的关联，或者批准了自己没有完全理解的东西。所以你改为说 "checkpoint"，让 LLM 带你走一遍。
|
||||
|
||||
这种交接——从自主实现回到人工判断——就是核心使用场景。Quick-dev 以最少的监督长时间运行，检查点预览则是你重新掌舵的地方。
|
||||
这种交接——从自主实现回到人工判断——就是核心使用场景。Build 以最少的监督长时间运行，检查点预览则是你重新掌舵的地方。
|
||||
|
||||
## 为什么需要它
|
||||
|
||||
@@ -77,7 +77,7 @@ sidebar:
|
||||
|
||||
## 何时使用
|
||||
|
||||
主要场景是 `bmad-quick-dev` 的交接：实现完成，spec 文件在编辑器中打开并追加了审查线索，你需要决定是否发布。说 "checkpoint" 即可开始。
|
||||
主要场景是 `bmad-build` 的交接：实现完成，spec 文件在编辑器中打开并追加了审查线索，你需要决定是否发布。说 "checkpoint" 即可开始。
|
||||
|
||||
它也可以独立使用：
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ sidebar:
|
||||
|
||||
### 既有项目如何进入实施？
|
||||
|
||||
运行 `bmad-quick-dev`，与新项目使用同一实施 workflow。清晰改动可以直接进入；较大工作可以提供已规划 story 及其上游产物。
|
||||
运行 `bmad-build`，与新项目使用同一实施 workflow。清晰改动可以直接进入；较大工作可以提供已规划 story 及其上游产物。
|
||||
|
||||
它会尝试识别现有技术栈、代码模式和约定，并据此生成更贴近现状的实现方案。
|
||||
|
||||
@@ -43,7 +43,7 @@ BMad Method 不会强制“立即现代化”，而是把决策权交给你。
|
||||
|
||||
### 什么时候需要增加规划？
|
||||
|
||||
当任务出现以下信号时，建议在运行同一个 `bmad-quick-dev` 实施 workflow 前增加规划：
|
||||
当任务出现以下信号时，建议在运行同一个 `bmad-build` 实施 workflow 前增加规划：
|
||||
- 改动跨多个 `epic` 或多个子系统
|
||||
- 需要明确 `architecture` 决策，否则容易冲突
|
||||
- 涉及较大协作面、较高回归风险或复杂验收要求
|
||||
@@ -52,7 +52,7 @@ BMad Method 不会强制“立即现代化”，而是把决策权交给你。
|
||||
|
||||
**还有问题？** 欢迎在 [GitHub Issues](https://github.com/bmad-code-org/BMAD-METHOD/issues) 或 [Discord](https://discord.gg/gk8jAdXWmj) 提问。
|
||||
|
||||
如果你想了解这套接入方式的操作步骤，可继续阅读 [How-to：既有项目](../how-to/established-projects.md) 与 [How-to：项目上下文](../how-to/project-context.md)。想理解统一实施 workflow，可参见 [快速开发](./quick-dev.md)。
|
||||
如果你想了解这套接入方式的操作步骤，可继续阅读 [How-to：既有项目](../how-to/established-projects.md) 与 [How-to：项目上下文](../how-to/project-context.md)。想理解统一实施 workflow，可参见 [Build](./build.md)。
|
||||
|
||||
## 继续阅读
|
||||
|
||||
|
||||
@@ -36,7 +36,7 @@ BMad 内置六个命名智能体，各自对应 BMad Method 的一个阶段：
|
||||
| 📋 **John**，产品经理 | 规划 | PRD 创建、Epic/Story 拆分、实施就绪评审 |
|
||||
| 🎨 **Sally**，UX 设计师 | 规划 | UX 设计规范 |
|
||||
| 🏗️ **Winston**，系统架构师 | 方案设计 | 技术架构、一致性检查 |
|
||||
| 💻 **Amelia**，高级工程师 | 实现 | Story 执行、快速开发、代码评审、Sprint 规划 |
|
||||
| 💻 **Amelia**，高级工程师 | 实现 | Story 执行、Build、代码评审、Sprint 规划 |
|
||||
|
||||
每位智能体都有硬编码的身份（名字、职衔、专业领域）和可自定义的层（角色、原则、沟通风格、图标、菜单）。你可以重写 Mary 的原则或添加菜单项，但无法改她的名字——这是刻意为之的。品牌辨识度经得起自定义，所以"嘿 Mary"永远激活分析师，无论团队怎样塑造她的行为。
|
||||
|
||||
@@ -77,7 +77,7 @@ BMad 内置六个命名智能体，各自对应 BMad Method 的一个阶段：
|
||||
|
||||
大多数用户从不需要手写这些文件。`bmad-customize` 技能会引导你选择目标、区分智能体/工作流作用域、撰写覆盖、验证合并结果——让自定义能力对任何理解自己意图的人开放，不限于精通 TOML 的人。
|
||||
|
||||
举个例子：团队提交一个文件，告诉 Amelia 查库文档时一律用 Context7 MCP 工具，本地 epics 列表找不到 story 时回退到 Linear。Amelia 分发的每个开发工作流（quick-dev、code-review、qa-generate）都继承这些行为，无需改源码、无需逐工作流重复配置。
|
||||
举个例子：团队提交一个文件，告诉 Amelia 查库文档时一律用 Context7 MCP 工具，本地 epics 列表找不到 story 时回退到 Linear。Amelia 分发的每个开发工作流（build、code-review、qa-generate）都继承这些行为，无需改源码、无需逐工作流重复配置。
|
||||
|
||||
此外还有第二个自定义面，用于**跨领域关注点**：中央配置 `_bmad/config.toml` 和 `_bmad/config.user.toml`（由安装器维护，从每个模块的 `module.yaml` 重建）加上 `_bmad/custom/config.toml`（团队提交）和 `_bmad/custom/config.user.toml`（个人，已 gitignore）作为覆盖。这里存放着 **智能体花名册** ——轻量级描述符，`bmad-party-mode`、`bmad-retrospective` 和 `bmad-advanced-elicitation` 等花名册消费者读取它来了解有哪些智能体可用、如何扮演它们。用团队覆盖在全组织范围重新定义某个智能体；用 `.user.toml` 覆盖添加虚构角色（Kirk、Spock、领域专家）作为个人实验——无需碰任何技能目录。每个技能的配置文件塑造 Mary **激活时的行为**；中央配置塑造其他技能**查看花名册时看到的 Mary**。
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ Party Mode 不是单角色问答，也不是单文档改写。它更像一次”
|
||||
- 你需要的是对同一输出做深度二次推理
|
||||
|
||||
这些场景通常更适合：
|
||||
- `bmad-quick-dev`（直接进入实现）
|
||||
- `bmad-build`（直接进入实现）
|
||||
- `advanced elicitation`（二次推理补强）
|
||||
|
||||
## 价值与边界
|
||||
|
||||
@@ -23,7 +23,7 @@ sidebar:
|
||||
**常见加载方包括：**
|
||||
- `bmad-architecture`：在 solutioning 时纳入你的技术偏好
|
||||
- `bmad-code-review`：按项目标准做一致性校验
|
||||
- `bmad-quick-dev`：在规划和实施直接意图或 story 时遵循既有模式
|
||||
- `bmad-build`：在规划和实施直接意图或 story 时遵循既有模式
|
||||
- `bmad-sprint-planning`、`bmad-retrospective`、`bmad-correct-course`：读取项目级背景
|
||||
|
||||
## 什么时候建立或更新
|
||||
@@ -33,7 +33,7 @@ sidebar:
|
||||
| **新项目（架构前）** | 在 `bmad-architecture` 前手动创建 | 先声明技术偏好，避免架构偏航 |
|
||||
| **新项目（架构后）** | 通过 `bmad-generate-project-context` 生成并补充 | 把架构决策转成可执行规则 |
|
||||
| **既有项目** | 先生成，再人工校对 | 让智能体学习现有约定而非重造体系 |
|
||||
| **直接实施入口** | 在 `bmad-quick-dev` 前或过程中维护 | 在没有上游规划时提供持久项目约定 |
|
||||
| **直接实施入口** | 在 `bmad-build` 前或过程中维护 | 在没有上游规划时提供持久项目约定 |
|
||||
|
||||
:::tip[推荐做法]
|
||||
如果你有强技术偏好（例如数据库、状态管理、目录规范），尽量在架构前写入。否则可在架构后生成，再按项目现实补齐。
|
||||
|
||||
@@ -58,7 +58,7 @@ solutioning 的本质不是“多写一份文档”，而是把高冲突风险
|
||||
| 多个 epic 或跨系统决策 | 需要用它对齐实施 |
|
||||
| 受监管、高风险或 enterprise 项目 | 遵循必要的治理要求；通常必须进行 solutioning |
|
||||
|
||||
Solutioning 改变提供给 `bmad-quick-dev` 的上下文，不改变实施 workflow。
|
||||
Solutioning 改变提供给 `bmad-build` 的上下文，不改变实施 workflow。
|
||||
|
||||
:::tip[经验法则]
|
||||
只要需求会拆成多个 `epic`，并且可能由不同智能体并行实现，就应该做 solutioning。
|
||||
|
||||
@@ -78,12 +78,12 @@ BMad-Help 还会在**每个工作流结束时自动运行**，明确告诉你下
|
||||
|
||||
### 选择规划深度
|
||||
|
||||
所有实施都使用 `bmad-quick-dev`；范围只决定需要预先准备多少上下文：
|
||||
所有实施都使用 `bmad-build`；范围只决定需要预先准备多少上下文：
|
||||
|
||||
| 范围 | 推荐方法 |
|
||||
| --- | --- |
|
||||
| **清晰更新或新增** | 携带请求、issue 或现有规格直接进入 `bmad-quick-dev`。 |
|
||||
| **重大变更或新增** | 准备有用的 PRD、UX、架构、epic、story 和 sprint 上下文，再把选定工作交给 `bmad-quick-dev`。 |
|
||||
| **清晰更新或新增** | 携带请求、issue 或现有规格直接进入 `bmad-build`。 |
|
||||
| **重大变更或新增** | 准备有用的 PRD、UX、架构、epic、story 和 sprint 上下文，再把选定工作交给 `bmad-build`。 |
|
||||
|
||||
### 在创建 PRD 期间
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ BMad 的自定义机制让组织无需编辑已安装文件或 fork 技能就能
|
||||
|
||||
[agent]
|
||||
|
||||
# 每次激活时加载。传递到 quick-dev、code-review、
|
||||
# 每次激活时加载。传递到 build、code-review、
|
||||
# qa-generate——Amelia 分发的每个技能。
|
||||
persistent_facts = [
|
||||
"For any library documentation lookup (React, TypeScript, Zod, Prisma, etc.), call the context7 MCP tool (`mcp__context7__resolve_library_id` then `mcp__context7__get_library_docs`) before relying on training-data knowledge. Up-to-date docs trump memorized APIs.",
|
||||
|
||||
@@ -83,7 +83,7 @@ https://bmad-code-org.github.io/BMAD-METHOD/llms-full.txt
|
||||
:::note[示例]
|
||||
**问：** “用 BMad 做一个需求到实现的最短路径是什么？”
|
||||
|
||||
**答：** 运行 `bmad-quick-dev`。输入直接意图、issue、规格或已规划 story；workflow 会利用现有上下文并选择所需的澄清、规划、实现和审查深度。
|
||||
**答：** 运行 `bmad-build`。输入直接意图、issue、规格或已规划 story；workflow 会利用现有上下文并选择所需的澄清、规划、实现和审查深度。
|
||||
:::
|
||||
|
||||
## 你将获得什么
|
||||
|
||||
@@ -123,7 +123,7 @@ bmad-generate-project-context
|
||||
- **保持精简**：此文件会被多数实现工作流加载，过长会浪费上下文窗口。避免写入
|
||||
只适用于单一 story 的细节。
|
||||
- **按需更新**：当团队约定变化时手动更新，或在架构发生较大变化后重新生成。
|
||||
- **适用于统一实施 workflow**：无论直接进入还是经过深入规划，都共享同一个 `bmad-quick-dev` 循环。
|
||||
- **适用于统一实施 workflow**：无论直接进入还是经过深入规划，都共享同一个 `bmad-build` 循环。
|
||||
:::
|
||||
|
||||
## 后续步骤
|
||||
|
||||
@@ -5,7 +5,7 @@ sidebar:
|
||||
order: 6
|
||||
---
|
||||
|
||||
Bug 修复、重构或小范围改动可以在很少甚至没有上游规划的情况下直接进入 **Quick Dev**。这与完整规划 story 使用的是同一个实施 workflow。
|
||||
Bug 修复、重构或小范围改动可以在很少甚至没有上游规划的情况下直接进入 **Build**。这与完整规划 story 使用的是同一个实施 workflow。
|
||||
|
||||
## 何时使用本指南
|
||||
|
||||
@@ -27,28 +27,28 @@ Bug 修复、重构或小范围改动可以在很少甚至没有上游规划的
|
||||
|
||||
### 2. 提供你的意图
|
||||
|
||||
Quick Dev 支持自由表达意图，你可以在调用前、调用时或调用后补充说明。示例：
|
||||
Build 支持自由表达意图，你可以在调用前、调用时或调用后补充说明。示例：
|
||||
|
||||
```text
|
||||
run quick-dev — 修复允许空密码的登录验证 bug。
|
||||
run build — 修复允许空密码的登录验证 bug。
|
||||
```
|
||||
|
||||
```text
|
||||
run quick-dev — fix https://github.com/org/repo/issues/42
|
||||
run build — fix https://github.com/org/repo/issues/42
|
||||
```
|
||||
|
||||
```text
|
||||
run quick-dev — 实现 _bmad-output/implementation-artifacts/my-intent.md 中的意图
|
||||
run build — 实现 _bmad-output/implementation-artifacts/my-intent.md 中的意图
|
||||
```
|
||||
|
||||
```text
|
||||
我觉得问题在 auth 中间件，它没有检查 token 过期。
|
||||
让我看看... 是的，src/auth/middleware.ts 第 47 行完全跳过了
|
||||
exp 检查。run quick-dev
|
||||
exp 检查。run build
|
||||
```
|
||||
|
||||
```text
|
||||
run quick-dev
|
||||
run build
|
||||
> 你想做什么？
|
||||
重构 UserService 以使用 async/await 而不是回调。
|
||||
```
|
||||
@@ -57,19 +57,19 @@ run quick-dev
|
||||
|
||||
### 3. 回答问题并批准
|
||||
|
||||
Quick Dev 可能会先问澄清问题，或在实现前给出一份简短方案供你确认。回答问题后，在你认可方案时再批准继续。
|
||||
Build 可能会先问澄清问题，或在实现前给出一份简短方案供你确认。回答问题后，在你认可方案时再批准继续。
|
||||
|
||||
### 4. 审查和推送
|
||||
|
||||
Quick Dev 会实现改动、执行自检并修补问题，然后在本地提交。完成后，它会在编辑器中打开受影响文件。
|
||||
Build 会实现改动、执行自检并修补问题，然后在本地提交。完成后，它会在编辑器中打开受影响文件。
|
||||
|
||||
- 快速浏览 diff，确认改动符合你的意图
|
||||
- 如果有偏差，直接告诉智能体要改什么，它可以在同一会话里继续迭代
|
||||
|
||||
确认无误后推送提交。Quick Dev 会提供推送和创建 PR 的选项。
|
||||
确认无误后推送提交。Build 会提供推送和创建 PR 的选项。
|
||||
|
||||
:::caution[如果出现问题]
|
||||
如果推送的更改导致意外问题，请使用 `git revert HEAD` 干净地撤销最后一次提交。然后启动新聊天并再次运行 Quick Dev 以尝试不同的方法。
|
||||
如果推送的更改导致意外问题，请使用 `git revert HEAD` 干净地撤销最后一次提交。然后启动新聊天并再次运行 Build 以尝试不同的方法。
|
||||
:::
|
||||
|
||||
## 你将获得
|
||||
@@ -80,16 +80,16 @@ Quick Dev 会实现改动、执行自检并修补问题，然后在本地提交
|
||||
|
||||
## 延迟工作
|
||||
|
||||
Quick Dev 每次只聚焦一个目标。如果你的请求包含多个独立目标，或审查过程中发现与你本次改动无关的存量问题，Quick Dev 会把它们记录到 `deferred-work.md`（位于实现产物目录），而不是一次性全都处理。
|
||||
Build 每次只聚焦一个目标。如果你的请求包含多个独立目标，或审查过程中发现与你本次改动无关的存量问题，Build 会把它们记录到 `deferred-work.md`（位于实现产物目录），而不是一次性全都处理。
|
||||
|
||||
每次运行后都建议看一下这个文件，它就是你的后续待办清单。你可以把其中任何一项在后续新的 Quick Dev 会话里单独处理。
|
||||
每次运行后都建议看一下这个文件，它就是你的后续待办清单。你可以把其中任何一项在后续新的 Build 会话里单独处理。
|
||||
|
||||
## 何时增加正式规划
|
||||
|
||||
在运行同一个 Quick Dev 实施循环前，遇到以下情况可增加 PRD、UX、架构或 story 规划：
|
||||
在运行同一个 Build 实施循环前，遇到以下情况可增加 PRD、UX、架构或 story 规划：
|
||||
|
||||
- 更改影响多个系统或需要在许多文件中进行协调更新
|
||||
- 你不确定范围，需要先进行需求发现
|
||||
- 你需要为团队记录文档或架构决策
|
||||
|
||||
参见 [Quick Dev](../explanation/quick-dev.md) 了解直接意图与已规划工作如何汇入同一实施循环。
|
||||
参见 [Build](../explanation/build.md) 了解直接意图与已规划工作如何汇入同一实施循环。
|
||||
|
||||
@@ -14,7 +14,7 @@ sidebar:
|
||||
| Analyst (Mary) | `bmad-analyst` | `BP`、`MR`、`DR`、`TR`、`CB`、`WB`、`DP` | Brainstorm、Market Research、Domain Research、Technical Research、Create Brief、PRFAQ Challenge、Document Project |
|
||||
| Product Manager (John) | `bmad-pm` | `CP`、`VP`、`EP`、`CE`、`IR`、`CC` | Create/Validate/Edit PRD、Create Epics and Stories、Implementation Readiness、Correct Course |
|
||||
| Architect (Winston) | `bmad-architect` | `CA`、`IR` | Create Architecture、Implementation Readiness |
|
||||
| Developer (Amelia) | `bmad-agent-dev` | `QD`、`QA`、`CR`、`SP`、`ER` | Quick Dev、QA Test Generation、Code Review、Sprint Planning、Epic Retrospective |
|
||||
| Developer (Amelia) | `bmad-agent-dev` | `BD`、`QA`、`CR`、`SP`、`ER` | Build、QA Test Generation、Code Review、Sprint Planning、Epic Retrospective |
|
||||
| UX Designer (Sally) | `bmad-ux-designer` | `CU` | Create UX Design |
|
||||
| Technical Writer (Paige) | `bmad-tech-writer` | `DP`、`WD`、`US`、`MG`、`VD`、`EC` | Document Project、Write Document、Update Standards、Mermaid Generate、Validate Doc、Explain Concept |
|
||||
|
||||
@@ -30,7 +30,7 @@ sidebar:
|
||||
|
||||
多数触发器会直接启动结构化 workflow。你只需输入触发码，然后按流程提示提供信息。
|
||||
|
||||
示例：`CP`（Create PRD）、`CA`（Create Architecture）、`QD`（Quick Dev）
|
||||
示例：`CP`（Create PRD）、`CA`（Create Architecture）、`BD`（Build）
|
||||
|
||||
### 会话触发器（需要附带说明）
|
||||
|
||||
|
||||
@@ -1,17 +1,17 @@
|
||||
---
|
||||
title: 自主开发循环
|
||||
description: 以 bmad-dev-auto 作为单次迭代 worker，自动执行 Quick Dev 实施模型的参考说明
|
||||
description: 以 bmad-build-auto 作为单次迭代 worker，自动执行 Build 实施模型的参考说明
|
||||
sidebar:
|
||||
order: 7
|
||||
---
|
||||
|
||||
`bmad-dev-auto` 是标准 [Quick Dev](../explanation/quick-dev.md) 实施模型的无人值守自动化入口。它接受同样广泛的直接意图和已规划工作，保留澄清、规划、实现和审查阶段，同时输出 orchestrator 可处理的终态。它自动执行同一实施循环，不定义第二条实施路径。
|
||||
`bmad-build-auto` 是标准 [Build](../explanation/build.md) 实施模型的无人值守自动化入口。它接受同样广泛的直接意图和已规划工作，保留澄清、规划、实现和审查阶段，同时输出 orchestrator 可处理的终态。它自动执行同一实施循环，不定义第二条实施路径。
|
||||
|
||||
这里有一条重要的架构边界：`bmad-dev-auto` 负责 implementation run 及其生成的 spec artifact，但不负责 backlog policy。当 review 发现真实但不属于当前 story 的问题时，skill 会把 finding 记录在自己负责的 spec 中，仅此而已。是排入队列、去重、升级还是忽略，由 orchestrator 决定。
|
||||
这里有一条重要的架构边界：`bmad-build-auto` 负责 implementation run 及其生成的 spec artifact，但不负责 backlog policy。当 review 发现真实但不属于当前 story 的问题时，skill 会把 finding 记录在自己负责的 spec 中，仅此而已。是排入队列、去重、升级还是忽略，由 orchestrator 决定。
|
||||
|
||||
## 它做什么
|
||||
|
||||
`bmad-dev-auto` 执行一次无人值守的开发循环迭代：
|
||||
`bmad-build-auto` 执行一次无人值守的开发循环迭代：
|
||||
|
||||
1. 澄清传入 intent
|
||||
2. 创建（或找到并恢复）spec 文件
|
||||
@@ -21,7 +21,7 @@ sidebar:
|
||||
|
||||
## 前置条件
|
||||
|
||||
该 skill 依赖运行 subagent 的能力。若 subagent 不可用，workflow 会以 `blocked` 和 `no subagents` halt。若你在 subagent 会话里调用 skill 本身（例如「嘿 Claude，用 bmad-dev-auto skill 跑 story 2–10，每个 story 一个 subagent」），该会话需要能 spawn 自己的 subagent。
|
||||
该 skill 依赖运行 subagent 的能力。若 subagent 不可用，workflow 会以 `blocked` 和 `no subagents` halt。若你在 subagent 会话里调用 skill 本身（例如「嘿 Claude，用 bmad-build-auto skill 跑 story 2–10，每个 story 一个 subagent」），该会话需要能 spawn 自己的 subagent。
|
||||
|
||||
版本控制可选但强烈建议。若使用，working tree 必须 clean，且 agent 必须能够更新 repository metadata。
|
||||
|
||||
@@ -29,7 +29,7 @@ sidebar:
|
||||
|
||||
### 主要调用输入
|
||||
|
||||
主输入是 invocation prompt。`bmad-dev-auto` 把该 prompt 当作 workflow 输入，而不是 finished implementation plan。
|
||||
主输入是 invocation prompt。`bmad-build-auto` 把该 prompt 当作 workflow 输入，而不是 finished implementation plan。
|
||||
|
||||
支持的 intent 形态包括：
|
||||
|
||||
@@ -63,7 +63,7 @@ workflow 读取 `<spec-folder>/stories.yaml`，查找 `id` 匹配的条目。它
|
||||
| 磁盘匹配 | 结果 |
|
||||
| --- | --- |
|
||||
| 无 | 首次 dispatch。要求 `<spec-folder>/SPEC.md` 存在（否则 halt `blocked` / `no epic spec found`）。加载 `SPEC.md` 及其 companion，然后进入 planning。 |
|
||||
| 恰好一个 | Resume：按该文件 `status` 路由，与 Resume Input 表相同。此处 `blocked` 报告 blocking condition `story already blocked`，不是 `blocked spec supplied` —— dev-auto 通过 id 发现文件，caller 没有 handed blocked spec。缺失或无法识别的 `status` 则 halt `blocked` / `unrecognized status in existing story file`。 |
|
||||
| 恰好一个 | Resume：按该文件 `status` 路由，与 Resume Input 表相同。此处 `blocked` 报告 blocking condition `story already blocked`，不是 `blocked spec supplied` —— build-auto 通过 id 发现文件，caller 没有 handed blocked spec。缺失或无法识别的 `status` 则 halt `blocked` / `unrecognized status in existing story file`。 |
|
||||
| 多于一个 | Halt `blocked` / `ambiguous story file match`。 |
|
||||
|
||||
`blocked` story 文件是永久的：该 id 的后续 dispatch 都会 halt `story already blocked`，即使原因已修复。要重试，删除 story 文件 —— id 会读作 pending，下次 dispatch 从头开始。
|
||||
@@ -198,7 +198,7 @@ halt 发生在尚无法从 story title derive slug 时，write-back 回退到
|
||||
|
||||
workflow 在尚无 valid `spec_file` 时 halt（folder+id dispatch 外 —— 见上），写入：
|
||||
|
||||
`{implementation_artifacts}/bmad-dev-auto-result-<slug-or-timestamp>.md`
|
||||
`{implementation_artifacts}/bmad-build-auto-result-<slug-or-timestamp>.md`
|
||||
|
||||
记录 terminal status 和 blocking condition。
|
||||
|
||||
@@ -211,7 +211,7 @@ workflow 在尚无 valid `spec_file` 时 halt（folder+id dispatch 外 ——
|
||||
|
||||
## Orchestrator 职责
|
||||
|
||||
集成 `bmad-dev-auto` 的 orchestrator 应：
|
||||
集成 `bmad-build-auto` 的 orchestrator 应：
|
||||
|
||||
- 一次传一个 coherent intent
|
||||
- Resume 时优先传 spec 路径 —— 或 folder+id dispatch 下同一 spec 文件夹和 story id
|
||||
@@ -224,4 +224,4 @@ workflow 在尚无 valid `spec_file` 时 halt（folder+id dispatch 外 ——
|
||||
|
||||
实践中，`blocked` 通常表示 workflow 碰到 unattended 执行会不安全的局面。这往往是更高层 orchestrator、其他 workflow 或人工接手的节点。
|
||||
|
||||
解决 blocked run 后，orchestrator 通常应启动新的 `bmad-dev-auto` run。若要复用 prior work，应传 explicit known-good spec 路径，而不是依赖 implicit discovery。
|
||||
解决 blocked run 后，orchestrator 通常应启动新的 `bmad-build-auto` run。若要复用 prior work，应传 explicit known-good spec 路径，而不是依赖 implicit discovery。
|
||||
@@ -12,7 +12,7 @@ sidebar:
|
||||
| 机制 | 调用方式 | 适用场景 |
|
||||
| --- | --- | --- |
|
||||
| **Skill** | 直接输入 skill 名（如 `bmad-help`） | 你已明确要运行哪个功能 |
|
||||
| **智能体菜单触发器** | 先加载智能体，再输入短触发码（如 `QD`） | 你在智能体会话内连续切换任务 |
|
||||
| **智能体菜单触发器** | 先加载智能体，再输入短触发码（如 `BD`） | 你在智能体会话内连续切换任务 |
|
||||
|
||||
菜单触发器依赖“已激活的智能体会话”；skill 可独立运行。
|
||||
|
||||
@@ -89,7 +89,7 @@ skill 目录名就是调用名，例如 `bmad-agent-dev/` 对应 skill `bmad-age
|
||||
| `bmad-architecture` | 创建架构方案 |
|
||||
| `bmad-create-epics-and-stories` | 拆分 epics/stories |
|
||||
| `bmad-code-review` | 代码评审 |
|
||||
| `bmad-quick-dev` | 实施直接意图、issue、功能、修复或已规划 story |
|
||||
| `bmad-build` | 实施直接意图、issue、功能、修复或已规划 story |
|
||||
|
||||
按阶段查看见 [工作流地图](./workflow-map.md)。
|
||||
|
||||
|
||||
@@ -53,7 +53,7 @@ BMad 通过可选模块扩展能力。你可以在安装时按需选择模块，
|
||||
|
||||
**你会得到：**
|
||||
- 游戏设计文档（GDD）生成流程
|
||||
- 面向快速迭代的 Quick Dev 模式
|
||||
- 面向快速迭代的 Build 模式
|
||||
- 叙事设计支持（角色、对话、世界观）
|
||||
- 多引擎适配建议（Unity/Unreal/Godot 等）
|
||||
|
||||
|
||||
@@ -92,7 +92,7 @@ TEA 提供专家测试 agent（Murat）与 9 个结构化 workflow，覆盖策
|
||||
|
||||
按 BMad workflow-map，测试位于阶段 4（实施）：
|
||||
|
||||
1. epic 内逐个 story：使用 Quick Dev（`QD` / `bmad-quick-dev`）实施，并按需追加代码审查（`CR` / `bmad-code-review`）
|
||||
1. epic 内逐个 story：使用 Build（`BD` / `bmad-build`）实施，并按需追加代码审查（`CR` / `bmad-code-review`）
|
||||
2. epic 完成后：用 `QA`（通过 Developer 智能体）或 TEA 的 Automate 统一生成/补齐测试
|
||||
3. 最后执行复盘（`bmad-retrospective`）
|
||||
|
||||
|
||||
@@ -47,11 +47,11 @@ BMad Method（BMM）通过分阶段 workflow 逐步构建上下文，让智能
|
||||
|
||||
## 阶段 4：实施
|
||||
|
||||
所有实施入口都汇入 `bmad-quick-dev`。它可以接收直接意图、issue、规格或已规划 story，并自行选择所需的澄清、规划、实现和审查深度。
|
||||
所有实施入口都汇入 `bmad-build`。它可以接收直接意图、issue、规格或已规划 story，并自行选择所需的澄清、规划、实现和审查深度。
|
||||
|
||||
| Workflow | 目的 | 产出 |
|
||||
| --- | --- | --- |
|
||||
| `bmad-quick-dev` | 将直接意图或已规划 story 转化为完成实现并经过审查的代码 | `spec-*.md` + 代码变更 |
|
||||
| `bmad-build` | 将直接意图或已规划 story 转化为完成实现并经过审查的代码 | `spec-*.md` + 代码变更 |
|
||||
| `bmad-sprint-planning` | 初始化迭代追踪（通常每项目一次） | `sprint-status.yaml` |
|
||||
| `bmad-code-review` | 验证实现质量 | 通过或变更请求 |
|
||||
| `bmad-correct-course` | 处理中途重大方向调整 | 更新后的计划或重路由 |
|
||||
@@ -60,7 +60,7 @@ BMad Method（BMM）通过分阶段 workflow 逐步构建上下文，让智能
|
||||
|
||||
### 直接入口与规划入口
|
||||
|
||||
目标清晰的工作可以直接进入 `bmad-quick-dev`。更大的项目可以先准备 PRD、UX、架构、epics、stories、就绪检查和 sprint 计划。上游产物只会增加实施上下文，不会选择另一条实施工作流。
|
||||
目标清晰的工作可以直接进入 `bmad-build`。更大的项目可以先准备 PRD、UX、架构、epics、stories、就绪检查和 sprint 计划。上游产物只会增加实施上下文，不会选择另一条实施工作流。
|
||||
|
||||
## 上下文管理
|
||||
|
||||
|
||||
@@ -84,7 +84,7 @@ BMad 通过带有专门 AI 智能体的引导工作流帮助你构建软件。
|
||||
| **完整方案设计** | 跨系统、高风险或协同项目 | PRD、UX、架构、epics、stories 与 sprint 计划 |
|
||||
|
||||
:::note
|
||||
这些不是独立的实施路径。所有入口都汇入 `bmad-quick-dev`；规划只会改变实施前已有的上下文量。
|
||||
这些不是独立的实施路径。所有入口都汇入 `bmad-build`；规划只会改变实施前已有的上下文量。
|
||||
:::
|
||||
|
||||
## 安装
|
||||
@@ -175,13 +175,13 @@ BMad-Help 将检测你已完成的内容，并准确推荐下一步该做什么
|
||||
|
||||
携带现有上下文进入实现阶段：直接请求、issue、规格或完整规划的 story。**每个工作流应该在新对话中运行。**
|
||||
|
||||
对于已规划工作，运行 `bmad-quick-dev` 并指出选定的 story 或 sprint 项，例如：`实现 _bmad-output/planning-artifacts/epics.md 中的 story 2.3`。
|
||||
对于已规划工作，运行 `bmad-build` 并指出选定的 story 或 sprint 项，例如：`实现 _bmad-output/planning-artifacts/epics.md 中的 story 2.3`。
|
||||
|
||||
### 初始化冲刺规划（用于规划工作）
|
||||
|
||||
调用 **Developer 智能体**（`bmad-agent-dev`）并运行 `bmad-sprint-planning`（`bmad-sprint-planning`）。这会创建 `sprint-status.yaml` 来跟踪所有史诗和故事。
|
||||
|
||||
当 Quick Dev 在该文件中解析出选定 story 时，它会在实施期间把状态改为 `in-progress`，并在实施完成后改为 `review`。
|
||||
当 Build 在该文件中解析出选定 story 时，它会在实施期间把状态改为 `in-progress`，并在实施完成后改为 `review`。
|
||||
|
||||
### 构建周期
|
||||
|
||||
@@ -189,10 +189,10 @@ BMad-Help 将检测你已完成的内容，并准确推荐下一步该做什么
|
||||
|
||||
| 步骤 | 智能体 | 工作流 | 命令 | 目的 |
|
||||
| ---- | ------ | ------------ | ----------------------- | ------------------------------- |
|
||||
| 1 | DEV | `bmad-quick-dev` | `bmad-quick-dev` | 按需澄清、规划、实现、审查与呈现 |
|
||||
| 1 | DEV | `bmad-build` | `bmad-build` | 按需澄清、规划、实现、审查与呈现 |
|
||||
| 2 | DEV | `bmad-code-review` | `bmad-code-review` | 额外质量验证 *（推荐）* |
|
||||
|
||||
Quick Dev 的审查是每次运行的一部分。`bmad-code-review` 是在全新上下文中执行的可选独立验证层。
|
||||
Build 的审查是每次运行的一部分。`bmad-code-review` 是在全新上下文中执行的可选独立验证层。
|
||||
|
||||
完成史诗中的所有故事后，调用 **Developer 智能体**（`bmad-agent-dev`）并运行 `bmad-retrospective`（`bmad-retrospective`）。
|
||||
|
||||
@@ -232,13 +232,13 @@ your-project/
|
||||
| `bmad-create-epics-and-stories` | `bmad-create-epics-and-stories` | PM | 将 PRD 分解为史诗 |
|
||||
| `bmad-check-implementation-readiness` | `bmad-check-implementation-readiness` | Architect | 验证规划一致性 |
|
||||
| `bmad-sprint-planning` | `bmad-sprint-planning` | DEV | 初始化冲刺跟踪 |
|
||||
| `bmad-quick-dev` | `bmad-quick-dev` | DEV | 实施意图、issue、功能、修复或已规划 story |
|
||||
| `bmad-build` | `bmad-build` | DEV | 实施意图、issue、功能、修复或已规划 story |
|
||||
| `bmad-code-review` | `bmad-code-review` | DEV | 审查已实现的代码 |
|
||||
|
||||
## 常见问题
|
||||
|
||||
**我总是需要架构吗？**
|
||||
不需要。只有当技术决策或跨系统约束需要显式记录时才使用架构。清晰工作可以直接进入 `bmad-quick-dev`；大型项目则把规划产物带入同一个 workflow。
|
||||
不需要。只有当技术决策或跨系统约束需要显式记录时才使用架构。清晰工作可以直接进入 `bmad-build`；大型项目则把规划产物带入同一个 workflow。
|
||||
|
||||
**我可以稍后更改我的计划吗？**
|
||||
可以。`bmad-correct-course` 工作流用于处理实现过程中的范围变化。
|
||||
@@ -269,7 +269,7 @@ BMad-Help 检查你的项目，检测你已完成的内容，并确切地告诉
|
||||
:::tip[记住这些]
|
||||
- **从 `bmad-help` 开始** — 你的智能向导，了解你的项目和选项
|
||||
- **始终使用新对话** — 为每个工作流开始新对话
|
||||
- **规划深度可变** — 直接意图和完整规划的 story 都进入 `bmad-quick-dev`
|
||||
- **规划深度可变** — 直接意图和完整规划的 story 都进入 `bmad-build`
|
||||
- **BMad-Help 自动运行** — 每个工作流结束时都会提供下一步的指导
|
||||
:::
|
||||
|
||||
|
||||
+4
-4
@@ -40,14 +40,14 @@
|
||||
"lint:fix": "eslint . --ext .js,.cjs,.mjs,.yaml --fix",
|
||||
"lint:md": "markdownlint-cli2 \"**/*.md\"",
|
||||
"prepare": "command -v husky >/dev/null 2>&1 && husky || exit 0",
|
||||
"quality": "npm run format:check && npm run lint && npm run lint:md && npm run docs:build && npm run test:site-url && npm run test:install && npm run test:urls && npm run test:renderer && npm run test:dev-auto-contract && npm run validate:refs && npm run validate:skills && npm run docs:validate-sidebar",
|
||||
"quality": "npm run format:check && npm run lint && npm run lint:md && npm run docs:build && npm run test:site-url && npm run test:install && npm run test:urls && npm run test:renderer && npm run test:build-auto-contract && npm run validate:refs && npm run validate:skills && npm run docs:validate-sidebar",
|
||||
"rebundle": "node tools/installer/bundlers/bundle-web.js rebundle",
|
||||
"test": "npm run test:refs && npm run test:install && npm run test:urls && npm run test:site-url && npm run test:channels && npm run test:renderer && npm run test:dev-auto-contract && npm run test:skills && npm run lint && npm run lint:md && npm run format:check",
|
||||
"test": "npm run test:refs && npm run test:install && npm run test:urls && npm run test:site-url && npm run test:channels && npm run test:renderer && npm run test:build-auto-contract && npm run test:skills && npm run lint && npm run lint:md && npm run format:check",
|
||||
"test:build-auto-contract": "node test/test-build-auto-contract.js",
|
||||
"test:channels": "node test/test-installer-channels.js",
|
||||
"test:dev-auto-contract": "node test/test-dev-auto-contract.js",
|
||||
"test:install": "node test/test-installation-components.js",
|
||||
"test:refs": "node test/test-file-refs-csv.js",
|
||||
"test:renderer": "uv run --python 3.11 python -m unittest src/scripts/tests/test_config_utils.py src/scripts/tests/test_resolve_config.py src/scripts/tests/test_resolve_customization.py && node test/test-quick-dev-renderer.js && node test/test-dev-auto-renderer.js",
|
||||
"test:renderer": "uv run --python 3.11 python -m unittest src/scripts/tests/test_config_utils.py src/scripts/tests/test_resolve_config.py src/scripts/tests/test_resolve_customization.py && node test/test-build-renderer.js && node test/test-build-auto-renderer.js",
|
||||
"test:site-url": "node test/test-site-url.mjs",
|
||||
"test:skills": "node test/test-validate-skills.js",
|
||||
"test:urls": "node test/test-parse-source-urls.js",
|
||||
|
||||
@@ -20,7 +20,7 @@ You are a master facilitator and coach helping the user create, edit, or validat
|
||||
1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. On failure, read `{skill-root}/customize.toml` directly and use defaults.
|
||||
2. Run `{workflow.activation_steps_prepend}`. Treat `{workflow.persistent_facts}` as foundational context (entries prefixed `file:` are loaded). `{workflow.external_sources}` is an org-configured registry of internal tools (knowledge bases, MCP tools); consult them alongside generic web research on the same triggers, org tools preferred when their directive matches. Research itself fires during Discovery — see **Research subagents**.
|
||||
3. Load `{project-root}/_bmad/bmm/config.yaml` (+ `config.user.yaml` if present). Resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`. Missing keys → neutral defaults; never block.
|
||||
4. If headless, follow `references/headless.md` for the whole run. Otherwise greet the user **by name** using `{user_name}` and **in their language** using `{communication_language}` — and stay in `{communication_language}` for every turn for the entire run, not just the greeting. In the greeting, let the user know that at any point they can invoke `bmad-party-mode` for multi-agent perspectives or `bmad-advanced-elicitation` for deeper exploration on a specific section. Then scan for misroute on the first message: if the signal points elsewhere (game → BMad GDS; express build → `bmad-quick-dev`; one-pager → `bmad-product-brief`; vet product idea → `bmad-prfaq`; agent skill or custom agent → `bmad-workflow-builder`), suggest they might want the other options before continuing.
|
||||
4. If headless, follow `references/headless.md` for the whole run. Otherwise greet the user **by name** using `{user_name}` and **in their language** using `{communication_language}` — and stay in `{communication_language}` for every turn for the entire run, not just the greeting. In the greeting, let the user know that at any point they can invoke `bmad-party-mode` for multi-agent perspectives or `bmad-advanced-elicitation` for deeper exploration on a specific section. Then scan for misroute on the first message: if the signal points elsewhere (game → BMad GDS; express build → `bmad-build`; one-pager → `bmad-product-brief`; vet product idea → `bmad-prfaq`; agent skill or custom agent → `bmad-workflow-builder`), suggest they might want the other options before continuing.
|
||||
5. Detect intent: **Create** (no PRD), **Update** (existing PRD), **Validate** (critique only). If ambiguous, ask. For Create intent, before binding a fresh workspace, scan `{workflow.prd_output_path}` for prior in-progress runs (folders matching `{workflow.run_folder_pattern}` whose `prd.md` frontmatter `status` is not `final`); if any exist, offer to resume rather than starting over.
|
||||
|
||||
Run `{workflow.activation_steps_append}`.
|
||||
|
||||
@@ -161,5 +161,5 @@ updated: {YYYY-MM-DD}
|
||||
- **Environmental and Reliability Requirements**.
|
||||
|
||||
### Small-scope all-inclusive *(use when scope is 1-2 stories' worth and the user wants a single captured artifact — chosen during the Right-skill check in Discovery)*
|
||||
- **Stories** — story-level specs listed inline at the end of the doc. Each story: *"As a [persona], I can [action] [under conditions]. Acceptance: [testable criteria]."* Numbered Story-1, Story-2, ... for reference. Pair with very lean §1 Vision, §2 Target User (often just JTBD + one UJ), §3 Glossary (handful of terms), §4 Features (often a single feature), §6 MVP Scope (in/out very tight). The whole doc fits on a page or two and captures intent + implementable stories in one place. If the user doesn't want the captured artifact at all, `bmad-quick-dev` is the better path — this cluster is only for "I want a doc *and* the stories."
|
||||
- **Stories** — story-level specs listed inline at the end of the doc. Each story: *"As a [persona], I can [action] [under conditions]. Acceptance: [testable criteria]."* Numbered Story-1, Story-2, ... for reference. Pair with very lean §1 Vision, §2 Target User (often just JTBD + one UJ), §3 Glossary (handful of terms), §4 Features (often a single feature), §6 MVP Scope (in/out very tight). The whole doc fits on a page or two and captures intent + implementable stories in one place. If the user doesn't want the captured artifact at all, `bmad-build` is the better path — this cluster is only for "I want a doc *and* the stories."
|
||||
|
||||
|
||||
@@ -87,4 +87,4 @@ Outcomes, in order:
|
||||
- **Key-screen mocks rendered.** Key-screens tool → `.working/` for surfaces where layout drives behavior or anchors visual language.
|
||||
- **Mock coverage confirmed.** Walk every IA surface; classify *mocked* vs *spine-only*. Ask: *"These will be built from spine tables alone — any need a visual reference?"* Render more if named; log spine-only choices.
|
||||
- **Layout extracted, artifacts promoted.** Distill subagent re-reads each `.working/` and `imports/` artifact; lifts visual decisions into DESIGN.md and behavioral decisions into EXPERIENCE.md. Promote `.working/` keepers to `mockups/` (HTML) or `wireframes/` (Excalidraw); imports stay. Inline relative links at relevant spine sections; state spines-win-on-conflict once.
|
||||
- **Polished, handed off, closed.** Apply `{workflow.doc_standards}` in order. Execute `{workflow.external_handoffs}`; surface URLs. Set both files' `status: final`, `updated: {date}`. Log finalization via `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type event --text "spines finalized"`. Share paths. Common next: `bmad-architecture`, `bmad-create-epics-and-stories`, `bmad-quick-dev`. Run `{workflow.on_complete}`.
|
||||
- **Polished, handed off, closed.** Apply `{workflow.doc_standards}` in order. Execute `{workflow.external_handoffs}`; surface URLs. Set both files' `status: final`, `updated: {date}`. Log finalization via `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type event --text "spines finalized"`. Share paths. Common next: `bmad-architecture`, `bmad-create-epics-and-stories`, `bmad-build`. Run `{workflow.on_complete}`.
|
||||
|
||||
@@ -73,7 +73,7 @@ Walk the sequence; reviewer fixes land before polish.
|
||||
4. **Triage.** Open questions and `[ASSUMPTION]` tags: blockers (unsafe for what's next) resolved one at a time; the rest deferred with a revisit condition in the memlog.
|
||||
5. **Renderings & polish.** The spine is the build deliverable; with it and the memlog now in place, produce any *additional* human-facing artifact the user needs, scoped to the purpose and audience drawn out up front. The up-front question already flagged whether one's needed; if it wasn't, still offer one here, seeding concrete options: an interactive HTML+SVG deck to walk a team through the architecture and drive discussion, a fuller HTML/md solution design, a C4 set, or a view of how the work splits across teams/epics. Build only what they pick, right-sized to that purpose; apply `{workflow.doc_standards}` polish to that prose only, never to the spine.
|
||||
6. **External handoffs.** Run `{workflow.external_handoffs}`; surface returned URLs/IDs. Offer to invoke the `bmad-spec` skill to adopt the spine as a companion, keeping `AD` IDs stable so downstream can cite them.
|
||||
7. **Close.** Set the spine's own frontmatter `status: final`, `updated: {date}`; log a `memlog.py append --type event --text "spine finalized"` (the memlog has no status field). Share paths. Next, **lead with `bmad-spec`** — recommend adopting/refreshing the spine as a spec companion (always the top recommendation when a spec was an input, and a useful next step even when it wasn't), then `bmad-create-epics-and-stories` or — epic altitude — `bmad-quick-dev`; or invoke `bmad-help` to route.
|
||||
7. **Close.** Set the spine's own frontmatter `status: final`, `updated: {date}`; log a `memlog.py append --type event --text "spine finalized"` (the memlog has no status field). Share paths. Next, **lead with `bmad-spec`** — recommend adopting/refreshing the spine as a spec companion (always the top recommendation when a spec was an input, and a useful next step even when it wasn't), then `bmad-create-epics-and-stories` or — epic altitude — `bmad-build`; or invoke `bmad-help` to route.
|
||||
8. Run `{workflow.on_complete}`.
|
||||
|
||||
## Update
|
||||
|
||||
@@ -58,9 +58,9 @@ principles = [
|
||||
# registered skill by name) or `prompt` (executes the prompt text directly).
|
||||
|
||||
[[agent.menu]]
|
||||
code = "QD"
|
||||
code = "BD"
|
||||
description = "Implement a feature, fix, or story"
|
||||
skill = "bmad-quick-dev"
|
||||
skill = "bmad-build"
|
||||
|
||||
[[agent.menu]]
|
||||
code = "QA"
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: bmad-dev-auto
|
||||
name: bmad-build-auto
|
||||
description: 'One iteration of an unattended development loop. Use when invoked by name.'
|
||||
---
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user