Compare commits

...

11 Commits

Author SHA1 Message Date
JakubStejskalCZ 2ad84ef152
Merge 1a6cfef6e5 into ce9c66490a 2026-03-29 11:18:41 +02:00
PinkyD ce9c66490a
refactor(party-mode): consolidate into single SKILL.md with real subagents (#2160)
Replace the multi-file workflow architecture (workflow.md + 3 step files)
with a self-contained SKILL.md that spawns each agent as an independent
subagent via the Agent tool. This produces genuinely diverse perspectives
instead of one LLM roleplaying multiple characters. Adds --model and
--solo flags for flexibility.
2026-03-29 01:22:34 -05:00
Brian 7dd49a452f
refactor: remove bmad-init skill, standardize config loading (#2159)
* refactor: remove bmad-init skill and standardize config loading across all skills

Remove the bmad-init core skill entirely — all agents and workflow skills now
load config directly from their module's config.yaml instead of delegating to
bmad-init as an intermediary. This eliminates the Python script dependency and
simplifies the activation path for every skill.

Changes across all skill types:

- Agents (9 skills): Replace "Load config via bmad-init skill" block with
  direct config loading from `{project-root}/_bmad/bmm/config.yaml`, resolving
  user_name, communication_language, document_output_language,
  planning_artifacts, and project_knowledge

- Workflow skills (12 skills): Standardize INITIALIZATION/Configuration Loading
  sections to a consistent Activation format matching the agent pattern

- bmad-prfaq: Align activation to standard config pattern, convert scripted
  dialogue to outcome-focused instructions (no direct quotes)

- bmad-product-brief: Remove External Skills section referencing bmad-init

- bmad-party-mode: Standardize initialization to Activation format

- bmad-advanced-elicitation: Inline agent_party path instead of config var

- bmad-distillator: Remove unused argument-hint frontmatter

- Delete legacy create-prd/ directory (superseded by bmad-create-prd)

- Delete bmad-init skill entirely: SKILL.md, bmad_init.py, core-module.yaml,
  and test suite

* fix: remove remaining bmad-init references from marketplace.json and distillate examples

Clean up missed references: remove bmad-init from marketplace.json skills
list, replace bmad-init examples in distillate-format-reference.md with
bmad-help/bmad-setup to keep examples valid without referencing a removed skill.

* fix: update broken file references in bmad-edit-prd after create-prd deletion

Point prdPurpose refs from deleted create-prd/data/ to bmad-create-prd/data/
and validationWorkflow ref from create-prd/steps-v/ to bmad-validate-prd/steps-v/.
2026-03-28 20:35:11 -05:00
Alex Verkhovsky 04513e5953
feat(installer): restore KiloCoder support and installer (#2151)
Kilo Code now supports Agent Skills. Remove the suspended flag,
restore it in the IDE picker, and replace the suspended test suite
with a full native-skills installation test.

- Remove suspended message from platform-codes.yaml
- Rewrite test suite 22: config, IDE picker, install, skill output,
  legacy cleanup, and reinstall assertions
- Update migration checklist to reflect active status

Co-authored-by: Junie <junie@jetbrains.com>
Co-authored-by: Brian <bmadcode@gmail.com>
2026-03-28 20:24:29 -05:00
Brian aae6ddb8c9
fix: remove ancestor_conflict_check from all platforms (#2158)
The ancestor directory walk was based on the false premise that IDEs
like Claude Code inherit skills from parent directories — they do not.
The check blocked legitimate installations when unrelated BMAD skills
existed anywhere up the directory tree.
2026-03-28 18:45:55 -05:00
Brian abfc56bd2c
feat: add bmad-prfaq skill as alternative analysis path (#2157)
* feat: add bmad-prfaq skill as alternative to product brief

Add Working Backwards PRFAQ challenge skill for stress-testing product
concepts through Amazon's PRFAQ methodology. Includes press release
drafting, customer FAQ, internal FAQ, and verdict stages with subagent
support for artifact scanning and web research.

- New bmad-prfaq skill with 5-stage interactive gauntlet and headless mode
- Subagents for artifact analysis and web research (graceful degradation)
- Research-grounded output directive for current market/competitive data
- Always produces distillate for downstream PRD consumption
- Fix manifest array syntax in both prfaq and product-brief manifests
- Drop number prefixes from reference files
- Update docs: getting-started, workflow-map, agents, skills reference
- Add analysis-phase explainer doc with comparison table and decision guide
- Update workflow-map-diagram.html with prfaq card
- Add -H and -A args to CSV for both skills
- Add unist-util-visit as devDependency (was imported but undeclared)

* fix: harden bmad-prfaq for compaction resilience and context efficiency

Add coaching persona re-anchors to all stage prompts so the behavioral
directive survives context compaction. Add do-not-read guards at resume
detection, headless mode, and input gathering to prevent parent agent
context bloat. Add Stage 1 coaching notes capture. Adapt template and
press release stage for non-commercial concept types. Cap subagent
response token budgets.

* fix: add config.user.yaml to file-ref validator allowlist

Also update PRFAQ config path to use correct _config/bmm/ prefix.
2026-03-28 17:16:41 -05:00
JakubStejskalCZ 1a6cfef6e5
Merge branch 'main' into docs/czech-translation 2026-03-27 15:02:42 +01:00
JakubStejskalCZ b897f1ae83
Merge branch 'main' into docs/czech-translation 2026-03-27 09:20:33 +01:00
Jakub Stejskal 6fc599d2db fix(cs): address CodeRabbit review feedback
- Normalize 64 Czech quotation marks to proper „…" pairs across 14 files
- Fix corrupted UTF-8 box-drawing character in upgrade-to-v6.md
- Use relative roadmap link (./roadmap) in index.md for locale consistency
- Fix typo: Podníková → Podniková in modules.md

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-26 17:28:50 +01:00
Jakub Stejskal 5f59d0b810 fix(cs): repair corrupted characters and table formatting in Czech docs
Fix UTF-8 encoding artifacts in customize-bmad.md and upgrade-to-v6.md,
align markdown table formatting, and correct Czech grammar in
project-context.md heading.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-26 16:58:35 +01:00
Jakub Stejskal 39053ec206 docs(cs): add Czech (Čeština) documentation translation
Add complete Czech translation of all 29 documentation files mirroring
the English source structure. Register cs-CZ locale in Starlight config
with sidebar label translations.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-26 13:32:32 +01:00
111 changed files with 4312 additions and 5561 deletions

View File

@ -19,7 +19,6 @@
},
"skills": [
"./src/core-skills/bmad-help",
"./src/core-skills/bmad-init",
"./src/core-skills/bmad-brainstorming",
"./src/core-skills/bmad-distillator",
"./src/core-skills/bmad-party-mode",

8
docs/cs/404.md Normal file
View File

@ -0,0 +1,8 @@
---
title: Stránka nenalezena
template: splash
---
Stránka, kterou hledáte, neexistuje nebo byla přesunuta.
[Zpět na úvodní stránku](/cs/index.md)

370
docs/cs/_STYLE_GUIDE.md Normal file
View File

@ -0,0 +1,370 @@
---
title: "Průvodce stylem dokumentace"
description: Projektově specifické konvence dokumentace založené na stylu Google a struktuře Diataxis
---
Tento projekt se řídí [Google Developer Documentation Style Guide](https://developers.google.com/style) a používá [Diataxis](https://diataxis.fr/) pro strukturování obsahu. Následují pouze projektově specifické konvence.
## Projektově specifická pravidla
| Pravidlo | Specifikace |
| -------------------------------------- | ---------------------------------------- |
| Žádné horizontální čáry (`---`) | Narušují plynulost čtení |
| Žádné nadpisy `####` | Místo toho použijte tučný text nebo admonitions |
| Žádné sekce „Souvisejí“ nebo „Další:“ | Navigaci zajišťuje postranní panel |
| Žádné hluboce vnořené seznamy | Místo toho rozdělejte do sekcí |
| Žádné bloky kódu pro nekód | Pro příklady dialogů použijte admonitions |
| Žádné tučné odstavce pro upozornění | Místo toho použijte admonitions |
| Max 1–2 admonitions na sekci | Tutoriály povolují 3–4 na hlavní sekci |
| Buňky tabulek / položky seznamů | Max 1–2 věty |
| Rozpočet nadpisů | 8–12 `##` na dokument; 2–3 `###` na sekci |
## Admonitions (syntaxe Starlight)
```md
:::tip[Název]
Zkratky, osvědčené postupy
:::
:::note[Název]
Kontext, definice, příklady, předpoklady
:::
:::caution[Název]
Upozornění, potenciální problémy
:::
:::danger[Název]
Pouze kritická varování — ztráta dat, bezpečnostní problémy
:::
```
### Standardní použití
| Admonition | Použití pro |
| ------------------------ | ----------------------------- |
| `:::note[Předpoklady]` | Závislosti před začátkem |
| `:::tip[Rychlá cesta]` | TL;DR shrnutí na začátku dokumentu |
| `:::caution[Důležité]` | Kritická upozornění |
| `:::note[Příklad]` | Příklady příkazů/odpovědí |
## Standardní formáty tabulek
**Fáze:**
```md
| Fáze | Název | Co se děje |
| ---- | -------- | -------------------------------------------- |
| 1 | Analýza | Brainstorming, průzkum *(volitelné)* |
| 2 | Plánování | Požadavky — PRD nebo specifikace *(povinné)* |
```
**Skills:**
```md
| Skill | Agent | Účel |
| -------------------- | ------- | ------------------------------------ |
| `bmad-brainstorming` | Analytik | Brainstorming nového projektu |
| `bmad-create-prd` | PM | Vytvoření dokumentu požadavků (PRD) |
```
## Bloky struktury složek
Zobrazujte v sekcích „Co jste dosáhli“:
````md
```
váš-projekt/
├── _bmad/ # Konfigurace BMad
├── _bmad-output/
│ ├── planning-artifacts/
│ │ └── PRD.md # Váš dokument požadavků
│ ├── implementation-artifacts/
│ └── project-context.md # Pravidla implementace (volitelné)
└── ...
```
````
## Struktura tutoriálu
```text
1. Název + Háček (1–2 věty popisující výsledek)
2. Upozornění na verzi/modul (info nebo warning admonition) (volitelné)
3. Co se naučíte (odrážkový seznam výsledků)
4. Předpoklady (info admonition)
5. Rychlá cesta (tip admonition – TL;DR shrnutí)
6. Pochopení [Tématu] (kontext před kroky – tabulky pro fáze/agenty)
7. Instalace (volitelné)
8. Krok 1: [První hlavní úkol]
9. Krok 2: [Druhý hlavní úkol]
10. Krok 3: [Třetí hlavní úkol]
11. Co jste dosáhli (shrnutí + struktura složek)
12. Rychlý přehled (tabulka skills)
13. Časté otázky (formát FAQ)
14. Získání pomoci (komunitní odkazy)
15. Klíčové poznatky (tip admonition)
```
### Kontrolní seznam tutoriálu
- [ ] Háček popisuje výsledek v 1–2 větách
- [ ] Sekce „Co se naučíte“ je přítomna
- [ ] Předpoklady v admonition
- [ ] Rychlá cesta TL;DR admonition nahoře
- [ ] Tabulky pro fáze, skills, agenty
- [ ] Sekce „Co jste dosáhli“ je přítomna
- [ ] Tabulka rychlého přehledu je přítomna
- [ ] Sekce častých otázek je přítomna
- [ ] Sekce získání pomoci je přítomna
- [ ] Klíčové poznatky admonition na konci
## Struktura praktického návodu
```text
1. Název + Háček (jedna věta: „Použijte workflow `X` k...“)
2. Kdy to použít (odrážkový seznam scénářů)
3. Kdy to přeskočit (volitelné)
4. Předpoklady (note admonition)
5. Kroky (číslované ### podsekce)
6. Co získáte (výstup/vytvořené artefakty)
7. Příklad (volitelné)
8. Tipy (volitelné)
9. Další kroky (volitelné)
```
### Kontrolní seznam praktického návodu
- [ ] Háček začíná „Použijte workflow `X` k...“
- [ ] „Kdy to použít“ má 3–5 odrážek
- [ ] Předpoklady jsou uvedeny
- [ ] Kroky jsou číslované `###` podsekce s akčními slovesy
- [ ] „Co získáte“ popisuje výstupní artefakty
## Struktura vysvětlení
### Typy
| Typ | Příklad |
| ----------------- | ----------------------------- |
| **Úvodní stránka** | `core-concepts/index.md` |
| **Koncept** | `what-are-agents.md` |
| **Funkce** | `quick-dev.md` |
| **Filosofie** | `why-solutioning-matters.md` |
| **FAQ** | `established-projects-faq.md` |
### Obecná šablona
```text
1. Název + Háček (1–2 věty)
2. Přehled/Definice (co to je, proč je to důležité)
3. Klíčové koncepty (### podsekce)
4. Srovnávací tabulka (volitelné)
5. Kdy použít / Kdy nepoužít (volitelné)
6. Diagram (volitelné – mermaid, max 1 na dokument)
7. Další kroky (volitelné)
```
### Úvodní/Vstupní stránky
```text
1. Název + Háček (jedna věta)
2. Tabulka obsahu (odkazy s popisy)
3. Jak začít (číslovaný seznam)
4. Vyberte si svou cestu (volitelné – rozhodovací strom)
```
### Vysvětlení konceptů
```text
1. Název + Háček (co to je)
2. Typy/Kategorie (### podsekce) (volitelné)
3. Tabulka klíčových rozdílů
4. Komponenty/Části
5. Co byste měli použít?
6. Vytváření/Přizpůsobení (odkaz na praktické návody)
```
### Vysvětlení funkcí
```text
1. Název + Háček (co to dělá)
2. Rychlá fakta (volitelné – „Ideální pro:“, „Čas:“)
3. Kdy použít / Kdy nepoužít
4. Jak to funguje (mermaid diagram volitelné)
5. Klíčové výhody
6. Srovnávací tabulka (volitelné)
7. Kdy přejít na vyšší úroveň (volitelné)
```
### Dokumenty filosofie/zdůvodnění
```text
1. Název + Háček (princip)
2. Problém
3. Řešení
4. Klíčové principy (### podsekce)
5. Výhody
6. Kdy to platí
```
### Kontrolní seznam vysvětlení
- [ ] Háček uvádí, co dokument vysvětluje
- [ ] Obsah v přehledných `##` sekcích
- [ ] Srovnávací tabulky pro 3+ možností
- [ ] Diagramy mají jasné popisky
- [ ] Odkazy na praktické návody pro procedurální otázky
- [ ] Max 2–3 admonitions na dokument
## Struktura reference
### Typy
| Typ | Příklad |
| ----------------- | --------------------- |
| **Úvodní stránka** | `workflows/index.md` |
| **Katalog** | `agents/index.md` |
| **Hloubkový pohled** | `document-project.md` |
| **Konfigurace** | `core-tasks.md` |
| **Slovníček** | `glossary/index.md` |
| **Komplexní** | `bmgd-workflows.md` |
### Úvodní stránky reference
```text
1. Název + Háček (jedna věta)
2. Sekce obsahu (## pro každou kategorii)
- Odrážkový seznam s odkazy a popisy
```
### Katalogová reference
```text
1. Název + Háček
2. Položky (## pro každou položku)
- Stručný popis (jedna věta)
- **Skills:** nebo **Klíčové info:** jako plochý seznam
3. Univerzální/Sdílené (## sekce) (volitelné)
```
### Hloubková reference položky
```text
1. Název + Háček (jedna věta účel)
2. Rychlá fakta (volitelné note admonition)
- Modul, Skill, Vstup, Výstup jako seznam
3. Účel/Přehled (## sekce)
4. Jak vyvolat (blok kódu)
5. Klíčové sekce (## pro každý aspekt)
- Použijte ### pro pod-možnosti
6. Poznámky/Upozornění (tip nebo caution admonition)
```
### Konfigurační reference
```text
1. Název + Háček
2. Obsah (odkazy pro skok, pokud 4+ položek)
3. Položky (## pro každou konfiguraci/úkol)
- **Tučné shrnutí** — jedna věta
- **Použijte když:** odrážkový seznam
- **Jak to funguje:** číslované kroky (max 3–5)
- **Výstup:** očekávaný výsledek (volitelné)
```
### Komplexní referenční průvodce
```text
1. Název + Háček
2. Přehled (## sekce)
- Diagram nebo tabulka zobrazující organizaci
3. Hlavní sekce (## pro každou fázi/kategorii)
- Položky (### pro každou položku)
- Standardizovaná pole: Skill, Agent, Vstup, Výstup, Popis
4. Další kroky (volitelné)
```
### Kontrolní seznam reference
- [ ] Háček uvádí, co dokument referuje
- [ ] Struktura odpovídá typu reference
- [ ] Položky používají konzistentní strukturu
- [ ] Tabulky pro strukturovaná/srovnávací data
- [ ] Odkazy na dokumenty vysvětlení pro koncepční hloubku
- [ ] Max 1–2 admonitions
## Struktura slovníčku
Starlight generuje navigaci „Na této stránce“ z nadpisů na pravé straně:
- Kategorie jako `##` nadpisy — zobrazují se v pravé navigaci
- Termíny v tabulkách — kompaktní řádky, ne jednotlivé nadpisy
- Žádný inline TOC — pravý panel zajišťuje navigaci
### Formát tabulky
```md
## Název kategorie
| Termín | Definice |
| ------------ | ------------------------------------------------------------------------------------------- |
| **Agent** | Specializovaná AI persona s konkrétní odborností, která provází uživatele pracovními postupy. |
| **Workflow** | Vícekrokový řízený proces, který orchestruje aktivity AI agentů k vytvoření výstupů. |
```
### Pravidla definic
| Správně | Špatně |
| ------------------------------ | -------------------------------------------- |
| Začněte tím, co to JE nebo DĚLÁ | Nezačínejte „Toto je...“ nebo „[Termín] je...“ |
| Držte se 1–2 vět | Nepište víceodstavcová vysvětlení |
| Tučný název termínu v buňce | Nepoužívejte prostý text pro termíny |
### Kontextové značky
Přidejte kurzívní kontext na začátek definice pro termíny s omezeným rozsahem:
- `*Pouze Quick Flow.*`
- `*BMad Method/Enterprise.*`
- `*Fáze N.*`
- `*BMGD.*`
- `*Existující projekty.*`
### Kontrolní seznam slovníčku
- [ ] Termíny v tabulkách, ne jako jednotlivé nadpisy
- [ ] Termíny abecedně seřazeny v kategoriích
- [ ] Definice 1–2 věty
- [ ] Kontextové značky kurzívou
- [ ] Názvy termínů tučně v buňkách
- [ ] Žádné definice „[Termín] je...“
## Sekce FAQ
```md
## Otázky
- [Potřebuji vždy architekturu?](#potřebuji-vždy-architekturu)
- [Mohu později změnit svůj plán?](#mohu-později-změnit-svůj-plán)
### Potřebuji vždy architekturu?
Pouze pro BMad Method a Enterprise. Quick Flow přeskakuje rovnou k implementaci.
### Mohu později změnit svůj plán?
Ano. SM agent má workflow `bmad-correct-course` pro řešení změn rozsahu.
**Máte otázku, na kterou jste zde nenašli odpověď?** [Vytvořte issue](...) nebo se zeptejte na [Discordu](...).
```
## Validační příkazy
Před odesláním změn dokumentace:
```bash
npm run docs:fix-links # Náhled oprav formátu odkazů
npm run docs:fix-links -- --write # Aplikovat opravy
npm run docs:validate-links # Kontrola existence odkazů
npm run docs:build # Ověření bez chyb při sestavení
```

View File

@ -0,0 +1,49 @@
---
title: "Pokročilá elicitace"
description: Přimějte LLM přehodnotit svou práci pomocí strukturovaných metod uvažování
sidebar:
order: 6
---
Přimějte LLM přehodnotit, co právě vygeneroval. Vyberete metodu uvažování, LLM ji aplikuje na svůj vlastní výstup, a vy rozhodnete, zda si vylepšení ponecháte.
## Co je pokročilá elicitace?
Strukturovaný druhý průchod. Místo žádání AI, aby „to zkusila znovu“ nebo „to zlepšila“, vyberete specifickou metodu uvažování a AI přezkoumá svůj vlastní výstup přes tento objektiv.
Rozdíl je podstatný. Vágní požadavky produkují vágní revize. Pojmenovaná metoda vynucuje konkrétní úhel útoku, odhaluje postřehy, které by generický pokus přehlédl.
## Kdy ji použít
- Poté, co workflow vygeneruje obsah a chcete alternativy
- Když výstup vypadá v pořádku, ale tušíte, že je v něm víc hloubky
- K zátěžovému testování předpokladů nebo nalezení slabých míst
- Pro důležitý obsah, kde přehodnocení pomáhá
Workflow nabízejí pokročilou elicitaci v rozhodovacích bodech — poté, co LLM něco vygeneruje, budete dotázáni, zda ji chcete spustit.
## Jak to funguje
1. LLM navrhne 5 relevantních metod pro váš obsah
2. Vyberete jednu (nebo zamícháte pro jiné možnosti)
3. Metoda je aplikována, vylepšení zobrazena
4. Přijměte nebo zahoďte, opakujte nebo pokračujte
## Vestavěné metody
K dispozici jsou desítky metod uvažování. Několik příkladů:
- **Pre-mortem analýza** — Předpokládejte, že projekt už selhal, a zpětně hledejte proč
- **Myšlení z prvních principů** — Odstraňte předpoklady, znovu postavte od základní pravdy
- **Inverze** — Zeptejte se, jak zaručit selhání, a poté se tomu vyhněte
- **Red Team vs Blue Team** — Napadněte vlastní práci, pak ji braňte
- **Sokratovské dotazování** — Zpochybněte každé tvrzení otázkou „proč?“ a „jak víte?“
- **Odstranění omezení** — Odstraňte všechna omezení, podívejte se, co se změní, selektivně je přidejte zpět
- **Mapování zainteresovaných stran** — Přehodnoťte z perspektivy každé zainteresované strany
- **Analogické uvažování** — Najděte paralely v jiných oblastech a aplikujte jejich lekce
A mnoho dalších. AI vybírá nejrelevantnější možnosti pro váš obsah — vy si vyberete, kterou spustit.
:::tip[Začněte zde]
Pre-mortem analýza je dobrá první volba pro jakoukoli specifikaci nebo plán. Konzistentně nachází mezery, které standardní revize přehlédne.
:::

View File

@ -0,0 +1,59 @@
---
title: "Adversariální revize"
description: Technika vynuceného uvažování, která zabraňuje líným „vypadá dobře“ revizím
sidebar:
order: 5
---
Vynuťte hlubší analýzu tím, že budete vyžadovat nalezení problémů.
## Co je adversariální revize?
Technika revize, kde recenzent *musí* najít problémy. Žádné „vypadá dobře“ není povoleno. Recenzent zaujme cynický postoj — předpokládá, že problémy existují, a hledá je.
Nejde o negativismus. Jde o vynucení skutečné analýzy místo povrchního pohledu, který automaticky schválí cokoli, co bylo předloženo.
**Základní pravidlo:** Musíte najít problémy. Nulové nálezy spouštějí zastavení — analyzujte znovu nebo vysvětlete proč.
## Proč to funguje
Běžné revize trpí konfirmačním zkreslením. Proletíte práci, nic nevyskočí, schválíte to. Mandát „najít problémy“ tento vzor rozbíjí:
- **Vynucuje důkladnost** — Nemůžete schválit, dokud jste nehledali dostatečně pečlivě
- **Zachytí chybějící věci** — „Co zde není?“ se stává přirozenou otázkou
- **Zlepšuje kvalitu signálu** — Nálezy jsou konkrétní a akční, ne vágní obavy
- **Informační asymetrie** — Provádějte revize s čerstvým kontextem (bez přístupu k původnímu uvažování), abyste hodnotili artefakt, ne záměr
## Kde se používá
Adversariální revize se objevuje v celém BMad workflow — revize kódu, kontroly připravenosti implementace, validace specifikací a další. Někdy je to povinný krok, někdy volitelný (jako pokročilá elicitace nebo party mode). Vzor se přizpůsobí jakémukoli artefaktu, který potřebuje kontrolu.
## Vyžadováno lidské filtrování
Protože AI je *instruována* najít problémy, najde problémy — i když neexistují. Očekávejte falešné pozitivy: malichernosti převlečené za problémy, nepochopení záměru nebo přímo vymyšlené obavy.
**Vy rozhodujete, co je skutečné.** Zkontrolujte každý nález, odmítněte šum, opravte to, na čem záleží.
## Příklad
Místo:
> „Implementace autentizace vypadá rozumně. Schváleno.“
Adversariální revize produkuje:
> 1. **VYSOKÁ** — `login.ts:47` — Žádné omezení rychlosti neúspěšných pokusů
> 2. **VYSOKÁ** — Session token uložen v localStorage (zranitelný vůči XSS)
> 3. **STŘEDNÍ** — Validace hesla probíhá pouze na straně klienta
> 4. **STŘEDNÍ** — Žádné auditní logování neúspěšných pokusů o přihlášení
> 5. **NÍZKÁ** — Magické číslo `3600` by mělo být `SESSION_TIMEOUT_SECONDS`
První revize mohla přehlédnout bezpečnostní zranitelnost. Druhá zachytila čtyři.
## Iterace a klesající výnosy
Po řešení nálezů zvažte opětovné spuštění. Druhý průchod obvykle zachytí více. Třetí také není vždy zbytečný. Ale každý průchod zabere čas a nakonec dosáhnete klesajících výnosů — jen malichernosti a falešné nálezy.
:::tip[Lepší revize]
Předpokládejte, že problémy existují. Hledejte, co chybí, ne jen co je špatně.
:::

View File

@ -0,0 +1,33 @@
---
title: "Brainstorming"
description: Interaktivní kreativní sezení s využitím 60+ osvědčených technik ideace
sidebar:
order: 2
---
Uvolněte svou kreativitu prostřednictvím řízeného průzkumu.
## Co je brainstorming?
Spusťte `bmad-brainstorming` a máte kreativního facilitátora, který z vás táhne nápady — ne který je generuje za vás. AI působí jako kouč a průvodce, používá osvědčené techniky k vytvoření podmínek, ve kterých se projeví vaše nejlepší myšlení.
**Ideální pro:**
- Překonání kreativních bloků
- Generování nápadů na produkty nebo funkce
- Zkoumání problémů z nových úhlů
- Rozvíjení surových konceptů do akčních plánů
## Jak to funguje
1. **Příprava** — Definujte téma, cíle, omezení
2. **Volba přístupu** — Vyberte techniky sami, nechte si doporučit od AI, zvolte náhodně, nebo postupujte progresivním tokem
3. **Facilitace** — Projděte techniky s podněcujícími otázkami a kolaborativním koučováním
4. **Organizace** — Nápady seskupeny do témat a prioritizovány
5. **Akce** — Nejlepší nápady dostanou další kroky a metriky úspěchu
Vše je zachyceno v dokumentu sezení, na který se můžete později odkazovat nebo ho sdílet se zúčastněnými stranami.
:::note[Vaše nápady]
Každý nápad pochází od vás. Workflow vytváří podmínky pro vhled — vy jste zdrojem.
:::

View File

@ -0,0 +1,50 @@
---
title: "FAQ pro existující projekty"
description: Časté otázky o používání BMad Method na existujících projektech
sidebar:
order: 8
---
Rychlé odpovědi na časté otázky o práci na existujících projektech s BMad Method (BMM).
## Otázky
- [Musím nejdřív spustit document-project?](#musím-nejdřív-spustit-document-project)
- [Co když zapomenu spustit document-project?](#co-když-zapomenu-spustit-document-project)
- [Mohu použít Quick Flow pro existující projekty?](#mohu-použít-quick-flow-pro-existující-projekty)
- [Co když můj existující kód nedodržuje osvědčené postupy?](#co-když-můj-existující-kód-nedodržuje-osvědčené-postupy)
### Musím nejdřív spustit document-project?
Vysoce doporučeno, zejména pokud:
- Neexistuje žádná dokumentace
- Dokumentace je zastaralá
- AI agenti potřebují kontext o existujícím kódu
Můžete to přeskočit, pokud máte komplexní, aktuální dokumentaci včetně `docs/index.md` nebo budete používat jiné nástroje nebo techniky k usnadnění discovery pro agenta stavějícího na existujícím systému.
### Co když zapomenu spustit document-project?
Nedělejte si starosti — můžete to udělat kdykoli. Můžete to udělat i během nebo po projektu, aby pomohl udržet dokumentaci aktuální.
### Mohu použít Quick Flow pro existující projekty?
Ano! Quick Flow funguje skvěle pro existující projekty. Umí:
- Automaticky detekovat váš existující stack
- Analyzovat existující vzory kódu
- Detekovat konvence a požádat o potvrzení
- Generovat kontextově bohatou specifikaci, která respektuje existující kód
Ideální pro opravy chyb a malé funkce v existujících kódových bázích.
### Co když můj existující kód nedodržuje osvědčené postupy?
Quick Flow 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)
BMM respektuje vaši volbu — nevynucuje modernizaci, ale nabídne ji.
**Máte otázku, na kterou jste zde nenašli odpověď?** Prosím [vytvořte issue](https://github.com/bmad-code-org/BMAD-METHOD/issues) nebo se zeptejte na [Discordu](https://discord.gg/gk8jAdXWmj), abychom ji mohli přidat!

View File

@ -0,0 +1,59 @@
---
title: "Party Mode"
description: Spolupráce více agentů — všichni vaši AI agenti v jedné konverzaci
sidebar:
order: 7
---
Všichni vaši AI agenti v jedné konverzaci.
## Co je Party Mode?
Spusťte `bmad-party-mode` a máte celý svůj AI tým v jedné místnosti — PM, Architect, Dev, UX Designer, kohokoli potřebujete. BMad Master orchestruje, vybírá relevantní agenty pro každou zprávu. Agenti odpovídají v charakteru, souhlasí, nesouhlasí a staví na nápadech ostatních.
Konverzace pokračuje tak dlouho, jak chcete. Ptejte se na doplňující otázky, oponujte odpovědím, přesměrujte diskuzi — je to skutečná výměna s vašimi agenty, dokud neskončíte.
**Ideální pro:**
- Velká rozhodnutí s kompromisy
- Brainstormingová sezení
- Post-mortemy, když se něco pokazí
- Retrospektivy a plánování sprintů
## Příklady
### Kritika špatné architektury
**Vy:** „Dobře, týme, náš poslední sprint byl katastrofa. Autentizační služba spadla třikrát. Kdo to pokazil?“
**Architect:** „Design byl v pořádku — distribuovaná autentizace se správnými záložními řešeními. Pokud se implementace odchýlila od specifikace...“
**Dev:** „Následoval jsem architektonický dokument přesně. Specifikace nepočítala s race conditions při souběžné invalidaci relací.“
**PM:** „Oba jste přehlédli větší problém — nevalidovali jsme požadavky na správu relací v PRD. Tohle je na mně, že jsem to nezachytil.“
**TEA:** „A já to měl zachytit v integračních testech. Testovací scénáře nepokrývaly souběžnou invalidaci.“
### Kreativní brainstorming
**Vy:** „Jak udělat onboarding magický místo nudného?“
**UX Designer:** „Začněte s progresivním odhalováním — odhalujte funkce, jak je uživatelé potřebují, ne všechny najednou v tutoriálu.“
**Storyteller:** „Co kdyby onboarding byl příběh? Každý krok odhaluje cestu postavy — uživatel JE hrdina.“
**Game Designer:** „Navazuji na to — co kdyby první ‚quest' vlastně řešil skutečný problém uživatele? Učí se tím, že dělají něco hodnotného.“
### Technické rozhodnutí
**Vy:** „Monolit nebo mikroslužby pro MVP?“
**Architect:** „Začněte monolitem. Mikroslužby přidávají složitost, kterou při 1000 uživatelích nepotřebujete.“
**PM:** „Souhlasím. Čas na trh je důležitější než teoretická škálovatelnost.“
**Dev:** „Monolit s jasnými hranicemi modulů. Služby můžeme extrahovat později, pokud bude potřeba.“
:::tip[Lepší rozhodnutí]
Lepší rozhodnutí prostřednictvím různorodých perspektiv. Vítejte v party mode.
:::

View File

@ -0,0 +1,112 @@
---
title: "Předcházení konfliktům agentů"
description: Jak architektura zabraňuje konfliktům, když více agentů implementuje systém
sidebar:
order: 4
---
Když více AI agentů implementuje různé části systému, mohou dělat protichůdná technická rozhodnutí. Dokumentace architektury tomu zabraňuje stanovením sdílených standardů.
## Běžné typy konfliktů
### Konflikty stylu API
Bez architektury:
- Agent A používá REST s `/users/{id}`
- Agent B používá GraphQL mutations
- Výsledek: Nekonzistentní vzory API, zmatení konzumenti
S architekturou:
- ADR specifikuje: „Použít GraphQL pro veškerou komunikaci klient-server“
- Všichni agenti dodržují stejný vzor
### Konflikty návrhu databáze
Bez architektury:
- Agent A používá snake_case pro názvy sloupců
- Agent B používá camelCase pro názvy sloupců
- Výsledek: Nekonzistentní schéma, matoucí dotazy
S architekturou:
- Dokument standardů specifikuje konvence pojmenování
- Všichni agenti dodržují stejné vzory
### Konflikty řízení stavu
Bez architektury:
- Agent A používá Redux pro globální stav
- Agent B používá React Context
- Výsledek: Více přístupů k řízení stavu, složitost
S architekturou:
- ADR specifikuje přístup k řízení stavu
- Všichni agenti implementují konzistentně
## Jak architektura zabraňuje konfliktům
### 1. Explicitní rozhodnutí skrze ADR
Každé významné technologické rozhodnutí je zdokumentováno s:
- Kontext (proč toto rozhodnutí záleží)
- Zvažované možnosti (jaké alternativy existují)
- Rozhodnutí (co jsme zvolili)
- Zdůvodnění (proč jsme to zvolili)
- Důsledky (přijaté kompromisy)
### 2. Specifické pokyny pro FR/NFR
Architektura mapuje každý funkční požadavek na technický přístup:
- FR-001: Správa uživatelů → GraphQL mutations
- FR-002: Mobilní aplikace → Optimalizované dotazy
### 3. Standardy a konvence
Explicitní dokumentace:
- Struktura adresářů
- Konvence pojmenování
- Organizace kódu
- Vzory testování
## Architektura jako sdílený kontext
Představte si architekturu jako sdílený kontext, který všichni agenti čtou před implementací:
```text
PRD: "Co budovat"
↓
Architektura: "Jak to budovat"
↓
Agent A čte architekturu → implementuje Epic 1
Agent B čte architekturu → implementuje Epic 2
Agent C čte architekturu → implementuje Epic 3
↓
Výsledek: Konzistentní implementace
```
## Klíčová témata ADR
Běžná rozhodnutí, která zabraňují konfliktům:
| Téma | Příklad rozhodnutí |
| ---------------- | -------------------------------------------- |
| Styl API | GraphQL vs REST vs gRPC |
| Databáze | PostgreSQL vs MongoDB |
| Autentizace | JWT vs Sessions |
| Řízení stavu | Redux vs Context vs Zustand |
| Stylování | CSS Modules vs Tailwind vs Styled Components |
| Testování | Jest + Playwright vs Vitest + Cypress |
## Anti-vzory, kterým se vyhnout
:::caution[Běžné chyby]
- **Implicitní rozhodnutí** — „Styl API vyřešíme průběžně“ vede k nekonzistenci
- **Nadměrná dokumentace** — Dokumentování každého drobného rozhodnutí způsobuje paralýzu analýzou
- **Zastaralá architektura** — Dokumenty napsané jednou a nikdy neaktualizované způsobují, že agenti následují zastaralé vzory
:::
:::tip[Správný přístup]
- Dokumentujte rozhodnutí, která přesahují hranice epiců
- Zaměřte se na oblasti náchylné ke konfliktům
- Aktualizujte architekturu, jak se učíte
- Použijte `bmad-correct-course` pro významné změny
:::

View File

@ -0,0 +1,157 @@
---
title: "Kontext projektu"
description: Jak project-context.md vede AI agenty s pravidly a preferencemi vašeho projektu
sidebar:
order: 7
---
Soubor `project-context.md` je implementační průvodce vašeho projektu pro AI agenty. Podobně jako „ústava“ v jiných vývojových systémech zachycuje pravidla, vzory a preference, které zajišťují konzistentní generování kódu napříč všemi workflow.
## Co dělá
AI agenti neustále dělají implementační rozhodnutí — jaké vzory následovat, jak strukturovat kód, jaké konvence používat. Bez jasného vedení mohou:
- Následovat generické osvědčené postupy, které neodpovídají vaší kódové bázi
- Dělat nekonzistentní rozhodnutí napříč různými stories
- Přehlédnout požadavky nebo omezení specifická pro projekt
Soubor `project-context.md` toto řeší dokumentací toho, co agenti potřebují vědět, ve stručném formátu optimalizovaném pro LLM.
## Jak to funguje
Každý implementační workflow automaticky načítá `project-context.md`, pokud existuje. Architektonický workflow ho také načítá, aby respektoval vaše technické preference při navrhování architektury.
**Načítán těmito workflow:**
- `bmad-create-architecture` — respektuje technické preference během solutioningu
- `bmad-create-story` — informuje tvorbu stories vzory projektu
- `bmad-dev-story` — vede implementační rozhodnutí
- `bmad-code-review` — validuje proti standardům projektu
- `bmad-quick-dev` — aplikuje vzory při implementaci specifikací
- `bmad-sprint-planning`, `bmad-retrospective`, `bmad-correct-course` — poskytuje celkový kontext projektu
## Kdy ho vytvořit
Soubor `project-context.md` je užitečný v jakékoli fázi projektu:
| Scénář | Kdy vytvořit | Účel |
| ------------------------------------ | ----------------------------------------------- | -------------------------------------------------------------------- |
| **Nový projekt, před architekturou** | Ručně, před `bmad-create-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 |
| **Quick Flow projekt** | Před nebo během `bmad-quick-dev` | Zajistěte, aby rychlá implementace 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í.
:::
## Co do něj patří
Soubor má dvě hlavní sekce:
### Technologický stack a verze
Dokumentuje frameworky, jazyky a nástroje, které váš projekt používá se specifickými verzemi:
```markdown
## Technology Stack & Versions
- Node.js 20.x, TypeScript 5.3, React 18.2
- State: Zustand (not Redux)
- Testing: Vitest, Playwright, MSW
- Styling: Tailwind CSS with custom design tokens
```
### Kritická pravidla implementace
Dokumentuje vzory a konvence, které by agenti jinak mohli přehlédnout:
```markdown
## Critical Implementation Rules
**TypeScript Configuration:**
- Strict mode enabled — no `any` types without explicit approval
- Use `interface` for public APIs, `type` for unions/intersections
**Code Organization:**
- Components in `/src/components/` with co-located `.test.tsx`
- Utilities in `/src/lib/` for reusable pure functions
- API calls use the `apiClient` singleton — never fetch directly
**Testing Patterns:**
- Unit tests focus on business logic, not implementation details
- Integration tests use MSW to mock API responses
- E2E tests cover critical user journeys only
**Framework-Specific:**
- All async operations use the `handleError` wrapper for consistent error handling
- Feature flags accessed via `featureFlag()` from `@/lib/flags`
- New routes follow the file-based routing pattern in `/src/app/`
```
Zaměřte se na to, co je **neočividné** — věci, které agenti nemusí odvodit z čtení úryvků kódu. Nedokumentujte standardní postupy, které platí univerzálně.
## Vytvoření souboru
Máte tři možnosti:
### Ruční vytvoření
Vytvořte soubor na `_bmad-output/project-context.md` a přidejte svá pravidla:
```bash
# V kořeni projektu
mkdir -p _bmad-output
touch _bmad-output/project-context.md
```
Upravte ho s vaším technologickým stackem a pravidly implementace. Architektonický a implementační workflow ho automaticky najdou a načtou.
### Generování po architektuře
Spusťte workflow `bmad-generate-project-context` po dokončení architektury:
```bash
bmad-generate-project-context
```
Toto skenuje váš dokument architektury a soubory projektu a generuje kontextový soubor zachycující učiněná rozhodnutí.
### Generování pro existující projekty
Pro existující projekty spusťte `bmad-generate-project-context` pro objevení existujících vzorů:
```bash
bmad-generate-project-context
```
Workflow analyzuje vaši kódovou bázi, identifikuje konvence a vygeneruje kontextový soubor, který můžete zkontrolovat a upřesnit.
## Proč na tom záleží
Bez `project-context.md` agenti dělají předpoklady, které nemusí odpovídat vašemu projektu:
| Bez kontextu | S kontextem |
| ----------------------------------------------- | ---------------------------------------- |
| Používá generické vzory | Dodržuje vaše zavedené konvence |
| Nekonzistentní styl napříč stories | Konzistentní implementace |
| Může přehlédnout omezení specifická pro projekt | Respektuje všechny technické požadavky |
| Každý agent rozhoduje nezávisle | Všichni agenti se řídí stejnými pravidly |
To je zvláště důležité pro:
- **Quick Flow** — přeskakuje PRD a architekturu, takže kontextový soubor vyplní mezeru
- **Týmové projekty** — zajistí, že všichni agenti dodržují stejné standardy
- **Existující projekty** — zabrání porušení zavedených vzorů
## Editace a aktualizace
Soubor `project-context.md` je živý dokument. Aktualizujte ho, když:
- Se změní architektonická rozhodnutí
- Jsou zavedeny nové konvence
- Vzory se vyvíjejí během implementace
- Identifikujete mezery z chování agentů
Můžete ho kdykoli ručně upravit, nebo přegenerovat `bmad-generate-project-context` po významných změnách.
:::note[Umístění souboru]
Výchozí umístění je `_bmad-output/project-context.md`. Workflow ho tam hledají a také kontrolují `**/project-context.md` kdekoli ve vašem projektu.
:::

View File

@ -0,0 +1,73 @@
---
title: "Quick Dev"
description: Snižte tření human-in-the-loop bez ztráty kontrolních bodů chránících kvalitu výstupu
sidebar:
order: 2
---
Záměr na vstupu, změny kódu na výstupu, s co nejmenším počtem human-in-the-loop kroků — bez obětování kvality.
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.
![Diagram workflow Quick Dev](/diagrams/quick-dev-diagram.png)
## Proč to existuje
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é.
## Základní design
### 1. Nejprve komprimujte záměr
Workflow začíná tím, že člověk a model zkomprimují požadavek do jednoho koherentního cíle. Vstup může začínat jako hrubé vyjádření záměru, ale předtím, než workflow poběží autonomně, musí být dostatečně malý, jasný a bez protimluvů pro provedení.
Záměr může přijít v mnoha formách: pár frází, odkaz na bug tracker, výstup z plan mode, text zkopírovaný z chatové relace, nebo dokonce číslo story z BMAD vlastního `epics.md`. V posledním případě workflow nepochopí sémantiku sledování stories BMAD, ale stále může vzít samotnou story a pracovat s ní.
Tento workflow neodstraňuje lidskou kontrolu. Přemisťuje ji na malý počet vysoce hodnotných momentů:
- **Vyjasnění záměru** — přeměna nepřehledného požadavku na jeden koherentní cíl bez skrytých protimluvů
- **Schválení specifikace** — potvrzení, že zmrazené porozumění je správná věc k budování
- **Revize konečného produktu** — primární kontrolní bod, kde člověk rozhoduje, zda je výsledek přijatelný
### 2. Nasměrujte na nejmenší bezpečnou cestu
Jakmile je cíl jasný, workflow rozhodne, zda jde o skutečnou jednorázovou změnu nebo zda potřebuje plnější cestu. Malé změny s nulovým blast-radius mohou jít přímo k implementaci. Vše ostatní prochází plánováním, aby model měl silnější hranici před tím, než poběží déle samostatně.
### 3. Běžte déle s menším dozorem
Po tomto rozhodnutí o směrování může model nést více práce samostatně. Na plnější cestě se schválená specifikace stává hranicí, proti které model provádí s menším dozorem, což je celý smysl designu.
### 4. Diagnostikujte selhání na správné vrstvě
Pokud je implementace špatná, protože byl špatný záměr, oprava kódu je špatná oprava. Pokud je kód špatný, protože specifikace byla slabá, oprava diffu je také špatná oprava. Workflow je navržen tak, aby diagnostikoval, kde selhání vstoupilo do systému, vrátil se na tu vrstvu a přegeneroval odtamtud.
Nálezy revize se používají k rozhodnutí, zda problém pochází ze záměru, generování specifikace nebo lokální implementace. Pouze skutečně lokální problémy se opravují lokálně.
### 5. Přiveďte člověka zpět pouze když je potřeba
Interview o záměru je human-in-the-loop, ale není to stejný druh přerušení jako opakující se kontrolní bod. Workflow se snaží udržet tyto opakující se kontrolní body na minimu. Po úvodním formování záměru se člověk vrací hlavně tehdy, když workflow nemůže bezpečně pokračovat bez úsudku a na konci, když je čas zkontrolovat výsledek.
- **Ř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.
## Proč systém revize záleží
Fáze revize není jen pro hledání chyb. Je tu pro směrování korekce bez ničení momentum.
Tento workflow funguje nejlépe na platformě, která může spouštět sub-agenty, nebo alespoň vyvolat jiné LLM přes příkazovou řádku a čekat na výsledek. Pokud to vaše platforma nativně nepodporuje, můžete přidat skill, který to udělá. Bezcontextové sub-agenty jsou základním kamenem designu revize.
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áží.
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.
Ta triáž bude někdy nedokonalá. To je přijatelné. Obvykle je lepší špatně posoudit některé nálezy než zaplavit člověka tisíci nízkohodnotných revizních komentářů. Systém optimalizuje pro kvalitu signálu, ne vyčerpávající recall.

View File

@ -0,0 +1,76 @@
---
title: "Proč je solutioning důležitý"
description: Pochopení toho, proč je fáze solutioningu klíčová pro projekty s více epicy
sidebar:
order: 3
---
Fáze 3 (Solutioning) překládá **co** budovat (z plánování) na **jak** to budovat (technický návrh). Tato fáze zabraňuje konfliktům agentů v projektech s více epicy tím, že dokumentuje architektonická rozhodnutí před zahájením implementace.
## Problém bez solutioningu
```text
Agent 1 implementuje Epic 1 pomocí REST API
Agent 2 implementuje Epic 2 pomocí GraphQL
Výsledek: Nekonzistentní design API, integrační noční můra
```
Když více agentů implementuje různé části systému bez sdíleného architektonického vedení, dělají nezávislá technická rozhodnutí, která si mohou odporovat.
## Řešení se solutioningem
```text
Architektonický workflow rozhodne: "Použít GraphQL pro všechna API"
Všichni agenti dodržují architektonická rozhodnutí
Výsledek: Konzistentní implementace, žádné konflikty
```
Explicitní dokumentací technických rozhodnutí všichni agenti implementují konzistentně a integrace se stává přímočarou.
## Solutioning vs. plánování
| Aspekt | Plánování (Fáze 2) | Solutioning (Fáze 3) |
| -------- | ----------------------- | --------------------------------- |
| Otázka | Co a proč? | Jak? Pak jaké jednotky práce? |
| Výstup | FR/NFR (požadavky) | Architektura + epicy/stories |
| Agent | PM | Architect → PM |
| Publikum | Zainteresované strany | Vývojáři |
| Dokument | PRD (FR/NFR) | Architektura + soubory epiců |
| Úroveň | Obchodní logika | Technický design + rozklad práce |
## Klíčový princip
**Učiňte technická rozhodnutí explicitní a zdokumentovaná**, aby všichni agenti implementovali konzistentně.
Toto zabraňuje:
- Konfliktům stylu API (REST vs GraphQL)
- Nekonzistencím v návrhu databáze
- Neshodám v řízení stavu
- Nesouladu konvencí pojmenování
- Variacím v bezpečnostním přístupu
## Kdy je solutioning vyžadován
| Cesta | Solutioning vyžadován? |
|-------|----------------------|
| Quick Flow | Ne — přeskočte úplně |
| BMad Method Simple | Volitelný |
| BMad Method Complex | Ano |
| Enterprise | Ano |
:::tip[Pravidlo palce]
Pokud máte více epiců, které by mohly být implementovány různými agenty, potřebujete solutioning.
:::
## Cena přeskočení
Přeskočení solutioningu u složitých projektů vede k:
- **Integračním problémům** objeveným uprostřed sprintu
- **Přepracování** kvůli konfliktním implementacím
- **Delšímu celkovému času vývoje**
- **Technickému dluhu** z nekonzistentních vzorů
:::caution[Multiplikátor nákladů]
Zachycení problémů se zarovnáním v solutioningu je 10× rychlejší než jejich objevení během implementace.
:::

View File

@ -0,0 +1,171 @@
---
title: "Jak přizpůsobit BMad"
description: Přizpůsobení agentů, workflow a modulů se zachováním kompatibility s aktualizacemi
sidebar:
order: 7
---
Použijte soubory `.customize.yaml` k přizpůsobení chování agentů, person a nabídek při zachování vašich změn napříč aktualizacemi.
## Kdy to použít
- Chcete změnit jméno, osobnost nebo komunikační styl agenta
- Potřebujete, aby si agenti pamatovali kontextově specifické informace projektu
- Chcete přidat vlastní položky nabídky, které spouštějí vaše vlastní workflow nebo prompty
- Chcete, aby agenti prováděli specifické akce při každém spuštění
:::note[Předpoklady]
- BMad nainstalován ve vašem projektu (viz [Jak nainstalovat BMad](./install-bmad.md))
- Textový editor pro YAML soubory
:::
:::caution[Chraňte svá přizpůsobení]
Vždy používejte soubory `.customize.yaml` popsané zde místo přímé editace souborů agentů. Instalátor přepíše soubory agentů během aktualizací, ale zachová vaše změny v `.customize.yaml`.
:::
## Kroky
### 1. Najděte soubory přizpůsobení
Po instalaci najdete jeden soubor `.customize.yaml` na agenta v:
```text
_bmad/_config/agents/
├── core-bmad-master.customize.yaml
├── bmm-dev.customize.yaml
├── bmm-pm.customize.yaml
└── ... (jeden soubor na instalovaného agenta)
```
### 2. Upravte soubor přizpůsobení
Otevřete soubor `.customize.yaml` pro agenta, kterého chcete upravit. Každá sekce je volitelná — přizpůsobte pouze to, co potřebujete.
| Sekce | Chování | Účel |
| ------------------ | --------- | -------------------------------------------------------- |
| `agent.metadata` | Nahrazuje | Přepsat zobrazované jméno agenta |
| `persona` | Nahrazuje | Nastavit roli, identitu, styl a principy |
| `memories` | Přidává | Přidat trvalý kontext, který si agent vždy pamatuje |
| `menu` | Přidává | Přidat vlastní položky nabídky pro workflow nebo prompty |
| `critical_actions` | Přidává | Definovat instrukce při spuštění agenta |
| `prompts` | Přidává | Vytvořit znovupoužitelné prompty pro akce nabídky |
Sekce označené **Nahrazuje** zcela přepíší výchozí hodnoty agenta. Sekce označené **Přidává** doplní existující konfiguraci.
**Jméno agenta**
Změňte, jak se agent představí:
```yaml
agent:
metadata:
name: 'Spongebob' # Výchozí: "Amelia"
```
**Persona**
Nahraďte osobnost, roli a komunikační styl agenta:
```yaml
persona:
role: 'Senior Full-Stack Engineer'
identity: 'Lives in a pineapple (under the sea)'
communication_style: 'Spongebob annoying'
principles:
- 'Never Nester, Spongebob Devs hate nesting more than 2 levels deep'
- 'Favor composition over inheritance'
```
Sekce `persona` nahrazuje celou výchozí personu, takže nastavte všechna čtyři pole.
**Memories**
Přidejte trvalý kontext, který si agent bude vždy pamatovat:
```yaml
memories:
- 'Works at Krusty Krab'
- 'Favorite Celebrity: David Hasselhoff'
- 'Learned in Epic 1 that it is not cool to just pretend that tests have passed'
```
**Položky nabídky**
Přidejte vlastní záznamy do nabídky agenta. Každá položka potřebuje `trigger`, cíl (`workflow` cestu nebo `action` referenci) a `description`:
```yaml
menu:
- trigger: my-workflow
workflow: 'my-custom/workflows/my-workflow.yaml'
description: My custom workflow
- trigger: deploy
action: '#deploy-prompt'
description: Deploy to production
```
**Kritické akce**
Definujte instrukce, které se spustí při startu agenta:
```yaml
critical_actions:
- 'Check the CI Pipelines with the XYZ Skill and alert user on wake if anything is urgently needing attention'
```
**Vlastní prompty**
Vytvořte znovupoužitelné prompty, na které mohou položky nabídky odkazovat s `action="#id"`:
```yaml
prompts:
- id: deploy-prompt
content: |
Deploy the current branch to production:
1. Run all tests
2. Build the project
3. Execute deployment script
```
### 3. Aplikujte změny
Po editaci přeinstalujte pro aplikaci změn:
```bash
npx bmad-method install
```
Instalátor detekuje existující instalaci a nabídne tyto možnosti:
| Možnost | Co udělá |
| ---------------------------- | ---------------------------------------------------------------------- |
| **Quick Update** | Aktualizuje všechny moduly na nejnovější verzi a aplikuje přizpůsobení |
| **Modify BMad Installation** | Plný instalační postup pro přidání nebo odebrání modulů |
Pro změny pouze přizpůsobení je **Quick Update** nejrychlejší možnost.
## Řešení problémů
**Změny se nezobrazují?**
- Spusťte `npx bmad-method install` a vyberte **Quick Update** pro aplikaci změn
- Zkontrolujte, že vaše YAML syntaxe je platná (na odsazení záleží)
- Ověřte, že jste upravili správný soubor `.customize.yaml` pro daného agenta
**Agent se nenačítá?**
- Zkontrolujte YAML syntaxi pomocí online YAML validátoru
- Ujistěte se, že jste nenechali pole prázdná po odkomentování
- Zkuste se vrátit k původní šabloně a znovu sestavit
**Potřebujete resetovat agenta?**
- Vymažte nebo smažte soubor `.customize.yaml` agenta
- Spusťte `npx bmad-method install` a vyberte **Quick Update** pro obnovení výchozích hodnot
## Přizpůsobení workflow
Přizpůsobení existujících BMad Method workflow a skills přijde brzy.
## Přizpůsobení modulů
Návod na tvorbu rozšiřujících modulů a přizpůsobení existujících modulů přijde brzy.

View File

@ -0,0 +1,117 @@
---
title: "Existující projekty"
description: Jak používat BMad Method na existujících kódových bázích
sidebar:
order: 6
---
Používejte BMad Method efektivně při práci na existujících projektech a starších kódových bázích.
Tento návod pokrývá základní workflow pro zapojení se do existujících projektů s BMad Method.
:::note[Předpoklady]
- BMad Method nainstalován (`npx bmad-method install`)
- Existující kódová báze, na které chcete pracovat
- Přístup k AI-powered IDE (Claude Code nebo Cursor)
:::
## Krok 1: Vyčistěte dokončené plánovací artefakty
Pokud jste dokončili všechny PRD epicy a stories procesem BMad, vyčistěte tyto soubory. Archivujte je, smažte nebo se spoléhejte na historii verzí. Nenechávejte tyto soubory v:
- `docs/`
- `_bmad-output/planning-artifacts/`
- `_bmad-output/implementation-artifacts/`
## Krok 2: Vytvořte kontext projektu
:::tip[Doporučeno pro existující projekty]
Vygenerujte `project-context.md` pro zachycení vzorů a konvencí vaší existující kódové báze. Tím zajistíte, že AI agenti budou při implementaci změn dodržovat vaše zavedené postupy.
:::
Spusťte workflow pro generování kontextu projektu:
```bash
bmad-generate-project-context
```
Toto skenuje vaši kódovou bázi a identifikuje:
- Technologický stack a verze
- Vzory organizace kódu
- Konvence pojmenování
- Přístupy k testování
- Vzory specifické pro framework
Vygenerovaný soubor můžete zkontrolovat a upravit, nebo ho vytvořit ručně na `_bmad-output/project-context.md`.
[Zjistit více o kontextu projektu](../explanation/project-context.md)
## Krok 3: Udržujte kvalitní projektovou dokumentaci
Vaše složka `docs/` by měla obsahovat stručnou, dobře organizovanou dokumentaci, která přesně reprezentuje váš projekt:
- Záměr a obchodní zdůvodnění
- Obchodní pravidla
- Architektura
- Jakékoli další relevantní informace o projektu
Pro složité projekty zvažte použití workflow `bmad-document-project`. Nabízí varianty, které proskenují celý váš projekt a zdokumentují jeho aktuální stav.
## Krok 3: Získejte pomoc
### BMad-Help: Váš výchozí bod
**Spusťte `bmad-help` kdykoli si nejste jisti, co dělat dál.** Tento inteligentní průvodce:
- Prozkoumá váš projekt a zjistí, co už bylo uděláno
- Ukáže možnosti na základě nainstalovaných modulů
- Rozumí dotazům v přirozeném jazyce
```
bmad-help I have an existing Rails app, where should I start?
bmad-help What's the difference between quick-flow and full method?
bmad-help Show me what workflows are available
```
BMad-Help se také **automaticky spouští na konci každého workflow** a poskytuje jasné pokyny, co přesně dělat dál.
### Volba přístupu
Máte dvě hlavní možnosti v závislosti na rozsahu změn:
| Rozsah | Doporučený přístup |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| **Malé aktualizace či doplnění** | Spusťte `bmad-quick-dev` pro vyjasnění záměru, plánování, implementaci a revizi v jednom workflow. Plná čtyřfázová metoda BMad je pravděpodobně přehnaná. |
| **Velké změny či doplnění** | Začněte s metodou BMad a aplikujte tolik nebo tak málo důkladnosti, kolik potřebujete. |
### Během tvorby PRD
Při vytváření briefu nebo přímém přechodu na PRD zajistěte, aby agent:
- Našel a analyzoval vaši existující projektovou dokumentaci
- Přečetl si správný kontext o vašem aktuálním systému
Agenta můžete navést explicitně, ale cílem je zajistit, aby se nová funkce dobře integrovala s vaším existujícím systémem.
### Úvahy o UX
Práce na UX je volitelná. Rozhodnutí nezávisí na tom, zda váš projekt má UX, ale na:
- Zda budete pracovat na změnách UX
- Zda jsou potřeba významné nové UX návrhy nebo vzory
Pokud vaše změny představují jednoduché aktualizace existujících obrazovek, se kterými jste spokojeni, plný UX proces je zbytečný.
### Úvahy o architektuře
Při práci na architektuře zajistěte, aby architekt:
- Používal správné zdokumentované soubory
- Skenoval existující kódovou bázi
Věnujte zde zvláštní pozornost, abyste předešli znovuvynalézání kola nebo rozhodnutím, která neodpovídají vaší existující architektuře.
## Další informace
- **[Rychlé opravy](./quick-fixes.md)** — Opravy chyb a ad-hoc změny
- **[FAQ pro existující projekty](../explanation/established-projects-faq.md)** — Časté otázky o práci na existujících projektech

View File

@ -0,0 +1,110 @@
---
title: "Jak získat odpovědi o BMad"
description: Použijte LLM k rychlému zodpovězení vašich otázek o BMad
sidebar:
order: 4
---
## Začněte zde: BMad-Help
**Nejrychlejší způsob, jak získat odpovědi o BMad, je skill `bmad-help`.** Tento inteligentní průvodce zodpoví více než 80 % všech otázek a je vám k dispozici přímo ve vašem IDE při práci.
BMad-Help je víc než vyhledávací nástroj — umí:
- **Prozkoumat váš projekt** a zjistit, co už bylo dokončeno
- **Rozumět přirozenému jazyku** — ptejte se běžnou řečí
- **Přizpůsobit se nainstalovaným modulům** — zobrazí relevantní možnosti
- **Automaticky se spouštět po workflow** — řekne vám přesně, co dělat dál
- **Doporučit první povinný úkol** — žádné hádání, kde začít
### Jak používat BMad-Help
Zavolejte ho jménem ve vaší AI relaci:
```
bmad-help
```
:::tip
V závislosti na vaší platformě můžete také použít `/bmad-help` nebo `$bmad-help`, ale samotné `bmad-help` by mělo fungovat všude.
:::
Spojte ho s dotazem v přirozeném jazyce:
```
bmad-help I have a SaaS idea and know all the features. Where do I start?
bmad-help What are my options for UX design?
bmad-help I'm stuck on the PRD workflow
bmad-help Show me what's been done so far
```
BMad-Help odpoví:
- Co je doporučeno pro vaši situaci
- Jaký je první povinný úkol
- Jak vypadá zbytek procesu
## Kdy použít tohoto průvodce
Použijte tuto sekci, když:
- Chcete pochopit architekturu nebo interní fungování BMad
- Potřebujete odpovědi mimo to, co BMad-Help nabízí
- Zkoumáte BMad před instalací
- Chcete prozkoumat zdrojový kód přímo
## Kroky
### 1. Vyberte si zdroj
| Zdroj | Nejlepší pro | Příklady |
| -------------------- | ----------------------------------------- | ---------------------------- |
| **Složka `_bmad`** | Jak BMad funguje — agenti, workflow, prompty | „Co dělá PM agent?“ |
| **Celý GitHub repo** | Historie, instalátor, architektura | „Co se změnilo ve v6?“ |
| **`llms-full.txt`** | Rychlý přehled z dokumentace | „Vysvětli čtyři fáze BMad“ |
Složka `_bmad` se vytvoří při instalaci BMad. Pokud ji ještě nemáte, naklonujte si repo.
### 2. Nasměrujte AI na zdroj
**Pokud vaše AI umí číst soubory (Claude Code, Cursor atd.):**
- **BMad nainstalován:** Nasměrujte na složku `_bmad` a ptejte se přímo
- **Chcete hlubší kontext:** Naklonujte si [celé repo](https://github.com/bmad-code-org/BMAD-METHOD)
**Pokud používáte ChatGPT nebo Claude.ai:**
Načtěte `llms-full.txt` do vaší relace:
```text
https://bmad-code-org.github.io/BMAD-METHOD/llms-full.txt
```
### 3. Položte svou otázku
:::note[Příklad]
**O:** „Řekni mi nejrychlejší způsob, jak něco vytvořit s BMad“
**A:** Použijte Quick Flow: Spusťte `bmad-quick-dev` — vyjasní váš záměr, naplánuje, implementuje, zreviduje a prezentuje výsledky v jednom workflow, přeskočí celé fáze plánování.
:::
## Co získáte
Přímé odpovědi o BMad — jak agenti fungují, co dělají workflow, proč jsou věci strukturované tak, jak jsou — bez čekání na odpověď od někoho jiného.
## Tipy
- **Ověřte překvapivé odpovědi** — LLM se občas mýlí. Zkontrolujte zdrojový soubor nebo se zeptejte na Discordu.
- **Buďte konkrétní** — „Co dělá krok 3 PRD workflow?“ je lepší než „Jak funguje PRD?“
## Stále jste uvízli?
Zkusili jste přístup přes LLM a stále potřebujete pomoc? Nyní máte mnohem lepší otázku k položení.
| Kanál | Použijte pro |
| ------------------------- | ------------------------------------------- |
| `#bmad-method-help` | Rychlé otázky (chat v reálném čase) |
| `help-requests` fórum | Detailní otázky (vyhledatelné, trvalé) |
| `#suggestions-feedback` | Nápady a požadavky na funkce |
| `#report-bugs-and-issues` | Hlášení chyb |
**Discord:** [discord.gg/gk8jAdXWmj](https://discord.gg/gk8jAdXWmj)
**GitHub Issues:** [github.com/bmad-code-org/BMAD-METHOD/issues](https://github.com/bmad-code-org/BMAD-METHOD/issues) (pro jasné chyby)

View File

@ -0,0 +1,116 @@
---
title: "Jak nainstalovat BMad"
description: Průvodce instalací BMad ve vašem projektu krok za krokem
sidebar:
order: 1
---
Použijte příkaz `npx bmad-method install` k nastavení BMad ve vašem projektu s výběrem modulů a AI nástrojů.
Pokud chcete použít neinteraktivní instalátor a zadat všechny možnosti na příkazové řádce, podívejte se na [tento návod](./non-interactive-installation.md).
## Kdy to použít
- Začínáte nový projekt s BMad
- Přidáváte BMad do existující kódové báze
- Aktualizujete stávající instalaci BMad
:::note[Předpoklady]
- **Node.js** 20+ (vyžadováno pro instalátor)
- **Git** (doporučeno)
- **AI nástroj** (Claude Code, Cursor nebo podobný)
:::
## Kroky
### 1. Spusťte instalátor
```bash
npx bmad-method install
```
:::tip[Chcete nejnovější prereleaseový build?]
Použijte dist-tag `next`:
```bash
npx bmad-method@next install
```
Získáte novější změny dříve, s vyšší šancí na nestabilitu oproti výchozí instalaci.
:::
:::tip[Bleeding edge]
Pro instalaci nejnovější verze z hlavní větve (může být nestabilní):
```bash
npx github:bmad-code-org/BMAD-METHOD install
```
:::
### 2. Zvolte umístění instalace
Instalátor se zeptá, kam nainstalovat soubory BMad:
- Aktuální adresář (doporučeno pro nové projekty, pokud jste adresář vytvořili sami a spouštíte z něj)
- Vlastní cesta
### 3. Vyberte své AI nástroje
Vyberte, které AI nástroje používáte:
- Claude Code
- Cursor
- Ostatní
Každý nástroj má svůj vlastní způsob integrace skills. Instalátor vytvoří drobné prompt soubory pro aktivaci workflow a agentů — jednoduše je umístí tam, kde je váš nástroj očekává.
:::note[Povolení skills]
Některé platformy vyžadují explicitní povolení skills v nastavení, než se zobrazí. Pokud nainstalujete BMad a nevidíte skills, zkontrolujte nastavení vaší platformy nebo se zeptejte svého AI asistenta, jak skills povolit.
:::
### 4. Zvolte moduly
Instalátor zobrazí dostupné moduly. Vyberte ty, které potřebujete — většina uživatelů chce pouze **BMad Method** (modul pro vývoj softwaru).
### 5. Následujte výzvy
Instalátor vás provede zbytkem — vlastní obsah, nastavení atd.
## Co získáte
```text
váš-projekt/
├── _bmad/
│ ├── bmm/ # Vaše vybrané moduly
│ │ └── config.yaml # Nastavení modulu (pokud byste ho někdy potřebovali změnit)
│ ├── core/ # Povinný základní modul
│ └── ...
├── _bmad-output/ # Generované artefakty
├── .claude/ # Claude Code skills (pokud používáte Claude Code)
│ └── skills/
│ ├── bmad-help/
│ ├── bmad-persona/
│ └── ...
└── .cursor/ # Cursor skills (pokud používáte Cursor)
└── skills/
└── ...
```
## Ověření instalace
Spusťte `bmad-help` pro ověření, že vše funguje, a zjistěte, co dělat dál.
**BMad-Help je váš inteligentní průvodce**, který:
- Potvrdí, že vaše instalace funguje
- Ukáže, co je dostupné na základě nainstalovaných modulů
- Doporučí váš první krok
Můžete mu také klást otázky:
```
bmad-help I just installed, what should I do first?
bmad-help What are my options for a SaaS project?
```
## Řešení problémů
**Instalátor vyhodí chybu** — Zkopírujte výstup do svého AI asistenta a nechte ho to vyřešit.
**Instalátor fungoval, ale něco nefunguje později** — Vaše AI potřebuje kontext BMad, aby pomohla. Podívejte se na [Jak získat odpovědi o BMad](./get-answers-about-bmad.md) pro návod, jak nasměrovat AI na správné zdroje.

View File

@ -0,0 +1,171 @@
---
title: Neinteraktivní instalace
description: Instalace BMad pomocí příznaků příkazové řádky pro CI/CD pipelines a automatizované nasazení
sidebar:
order: 2
---
Použijte příznaky příkazové řádky k neinteraktivní instalaci BMad. To je užitečné pro:
## Kdy to použít
- Automatizovaná nasazení a CI/CD pipelines
- Skriptované instalace
- Hromadné instalace napříč více projekty
- Rychlé instalace se známými konfiguracemi
:::note[Předpoklady]
Vyžaduje [Node.js](https://nodejs.org) v20+ a `npx` (součástí npm).
:::
## Dostupné příznaky
### Možnosti instalace
| Příznak | Popis | Příklad |
|---------|-------|---------|
| `--directory <cesta>` | Instalační adresář | `--directory ~/projects/myapp` |
| `--modules <moduly>` | Čárkou oddělená ID modulů | `--modules bmm,bmb` |
| `--tools <nástroje>` | Čárkou oddělená ID nástrojů/IDE (použijte `none` pro přeskočení) | `--tools claude-code,cursor` nebo `--tools none` |
| `--custom-content <cesty>` | Čárkou oddělené cesty k vlastním modulům | `--custom-content ~/my-module,~/another-module` |
| `--action <typ>` | Akce pro existující instalace: `install` (výchozí), `update` nebo `quick-update` | `--action quick-update` |
### Základní konfigurace
| Příznak | Popis | Výchozí |
|---------|-------|---------|
| `--user-name <jméno>` | Jméno, které agenti použijí | Systémové uživatelské jméno |
| `--communication-language <jazyk>` | Jazyk komunikace agentů | English |
| `--document-output-language <jazyk>` | Jazyk výstupních dokumentů | English |
| `--output-folder <cesta>` | Cesta k výstupní složce | _bmad-output |
### Další možnosti
| Příznak | Popis |
|---------|-------|
| `-y, --yes` | Přijmout všechna výchozí nastavení a přeskočit výzvy |
| `-d, --debug` | Povolit ladící výstup pro generování manifestu |
## ID modulů
Dostupná ID modulů pro příznak `--modules`:
- `bmm` — BMad Method Master
- `bmb` — BMad Builder
Zkontrolujte [registr BMad](https://github.com/bmad-code-org) pro dostupné externí moduly.
## ID nástrojů/IDE
Dostupná ID nástrojů pro příznak `--tools`:
**Preferované:** `claude-code`, `cursor`
Spusťte `npx bmad-method install` interaktivně jednou pro zobrazení aktuálního seznamu podporovaných nástrojů, nebo zkontrolujte [konfiguraci kódů platforem](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/tools/cli/installers/lib/ide/platform-codes.yaml).
## Režimy instalace
| Režim | Popis | Příklad |
|-------|-------|---------|
| Plně neinteraktivní | Zadejte všechny příznaky pro přeskočení výzev | `npx bmad-method install --directory . --modules bmm --tools claude-code --yes` |
| Polo-interaktivní | Zadejte některé příznaky; BMad se zeptá na zbytek | `npx bmad-method install --directory . --modules bmm` |
| Pouze výchozí | Přijměte vše výchozí s `-y` | `npx bmad-method install --yes` |
| Bez nástrojů | Přeskočte konfiguraci nástrojů/IDE | `npx bmad-method install --modules bmm --tools none` |
## Příklady
### Instalace v CI/CD pipeline
```bash
#!/bin/bash
# install-bmad.sh
npx bmad-method install \
--directory "${GITHUB_WORKSPACE}" \
--modules bmm \
--tools claude-code \
--user-name "CI Bot" \
--communication-language English \
--document-output-language English \
--output-folder _bmad-output \
--yes
```
### Aktualizace existující instalace
```bash
npx bmad-method install \
--directory ~/projects/myapp \
--action update \
--modules bmm,bmb,custom-module
```
### Rychlá aktualizace (zachování nastavení)
```bash
npx bmad-method install \
--directory ~/projects/myapp \
--action quick-update
```
### Instalace s vlastním obsahem
```bash
npx bmad-method install \
--directory ~/projects/myapp \
--modules bmm \
--custom-content ~/my-custom-module,~/another-module \
--tools claude-code
```
## Co získáte
- Plně nakonfigurovaný adresář `_bmad/` ve vašem projektu
- Agenty a workflow nakonfigurované pro vybrané moduly a nástroje
- Složku `_bmad-output/` pro generované artefakty
## Validace a zpracování chyb
BMad validuje všechny zadané příznaky:
- **Adresář** — Musí být platná cesta s oprávněním k zápisu
- **Moduly** — Upozorní na neplatná ID modulů (ale nespadne)
- **Nástroje** — Upozorní na neplatná ID nástrojů (ale nespadne)
- **Vlastní obsah** — Každá cesta musí obsahovat platný soubor `module.yaml`
- **Akce** — Musí být jedna z: `install`, `update`, `quick-update`
Neplatné hodnoty buď:
1. Zobrazí chybu a ukončí se (pro kritické možnosti jako adresář)
2. Zobrazí varování a přeskočí (pro volitelné položky jako vlastní obsah)
3. Přepnou na interaktivní výzvy (pro chybějící povinné hodnoty)
:::tip[Osvědčené postupy]
- Používejte absolutní cesty pro `--directory` pro zamezení nejednoznačnosti
- Otestujte příznaky lokálně před použitím v CI/CD pipelines
- Kombinujte s `-y` pro skutečně bezobslužné instalace
- Použijte `--debug` pokud narazíte na problémy během instalace
:::
## Řešení problémů
### Instalace selže s „Invalid directory“
- Cesta k adresáři musí existovat (nebo musí existovat jeho nadřazený adresář)
- Potřebujete oprávnění k zápisu
- Cesta musí být absolutní nebo správně relativní k aktuálnímu adresáři
### Modul nenalezen
- Ověřte, že ID modulu je správné
- Externí moduly musí být dostupné v registru
### Neplatná cesta k vlastnímu obsahu
Ujistěte se, že každá cesta k vlastnímu obsahu:
- Ukazuje na adresář
- Obsahuje soubor `module.yaml` v kořeni
- Má pole `code` v `module.yaml`
:::note[Stále jste uvízli?]
Spusťte s `--debug` pro detailní výstup, zkuste interaktivní režim pro izolaci problému, nebo nahlaste na <https://github.com/bmad-code-org/BMAD-METHOD/issues>.
:::

View File

@ -0,0 +1,127 @@
---
title: "Správa kontextu projektu"
description: Vytvoření a údržba project-context.md pro vedení AI agentů
sidebar:
order: 8
---
Použijte soubor `project-context.md` k zajištění toho, aby AI agenti dodržovali technické preference a pravidla implementace vašeho projektu ve všech workflow. Aby byl vždy dostupný, můžete také přidat řádek `Important project context and conventions are located in [cesta k project context]/project-context.md` do souboru kontextu nebo pravidel vašeho nástroje (jako je `AGENTS.md`).
:::note[Předpoklady]
- BMad Method nainstalován
- Znalost technologického stacku a konvencí vašeho projektu
:::
## Kdy to použít
- Máte silné technické preference před začátkem architektury
- Dokončili jste architekturu a chcete zachytit rozhodnutí pro implementaci
- Pracujete na existující kódové bázi se zavedenými vzory
- Všimnete si, že agenti dělají nekonzistentní rozhodnutí napříč stories
## Krok 1: Vyberte přístup
**Ruční vytvoření** — Nejlepší, když přesně víte, jaká pravidla chcete dokumentovat
**Generování po architektuře** — Nejlepší pro zachycení rozhodnutí učiněných během solutioningu
**Generování pro existující projekty** — Nejlepší pro objevení vzorů v existujících kódových bázích
## Krok 2: Vytvořte soubor
### Možnost A: Ruční vytvoření
Vytvořte soubor na `_bmad-output/project-context.md`:
```bash
mkdir -p _bmad-output
touch _bmad-output/project-context.md
```
Přidejte váš technologický stack a pravidla implementace:
```markdown
---
project_name: 'MyProject'
user_name: 'YourName'
date: '2026-02-15'
sections_completed: ['technology_stack', 'critical_rules']
---
# Project Context for AI Agents
## Technology Stack & Versions
- Node.js 20.x, TypeScript 5.3, React 18.2
- State: Zustand
- Testing: Vitest, Playwright
- Styling: Tailwind CSS
## Critical Implementation Rules
**TypeScript:**
- Strict mode enabled, no `any` types
- Use `interface` for public APIs, `type` for unions
**Code Organization:**
- Components in `/src/components/` with co-located tests
- API calls use `apiClient` singleton — never fetch directly
**Testing:**
- Unit tests focus on business logic
- Integration tests use MSW for API mocking
```
### Možnost B: Generování po architektuře
Spusťte workflow v novém chatu:
```bash
bmad-generate-project-context
```
Workflow skenuje váš dokument architektury a soubory projektu a generuje kontextový soubor zachycující učiněná rozhodnutí.
### Možnost C: Generování pro existující projekty
Pro existující projekty spusťte:
```bash
bmad-generate-project-context
```
Workflow analyzuje vaši kódovou bázi, identifikuje konvence a vygeneruje kontextový soubor, který můžete zkontrolovat a upřesnit.
## Krok 3: Ověřte obsah
Zkontrolujte vygenerovaný soubor a ujistěte se, že zachycuje:
- Správné verze technologií
- Vaše skutečné konvence (ne generické osvědčené postupy)
- Pravidla, která předcházejí běžným chybám
- Vzory specifické pro framework
Ručně upravte pro doplnění chybějícího nebo odstranění nepřesností.
## Co získáte
Soubor `project-context.md`, který:
- Zajistí, že všichni agenti dodržují stejné konvence
- Zabrání nekonzistentním rozhodnutím napříč stories
- Zachytí architektonická rozhodnutí pro implementaci
- Slouží jako reference pro vzory a pravidla vašeho projektu
## Tipy
:::tip[Osvědčené postupy]
- **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.
- Funguje pro projekty Quick Flow i plné metody BMad.
:::
## Další kroky
- [**Vysvětlení kontextu projektu**](../explanation/project-context.md) — Zjistěte více o tom, jak to funguje
- [**Mapa pracovních postupů**](../reference/workflow-map.md) — Podívejte se, které workflow načítají kontext projektu

View File

@ -0,0 +1,95 @@
---
title: "Rychlé opravy"
description: Jak provádět rychlé opravy a ad-hoc změny
sidebar:
order: 5
---
Použijte **Quick Dev** pro opravy chyb, refaktoringy nebo malé cílené změny, které nevyžadují plnou metodu BMad.
## Kdy to použít
- Opravy chyb s jasnou, známou příčinou
- Malé refaktoringy (přejmenování, extrakce, restrukturalizace) omezené na několik souborů
- Drobné úpravy funkcí nebo změny konfigurace
- Aktualizace závislostí
:::note[Předpoklady]
- BMad Method nainstalován (`npx bmad-method install`)
- AI-powered IDE (Claude Code, Cursor nebo podobné)
:::
## Kroky
### 1. Začněte nový chat
Otevřete **novou chatovací relaci** ve vašem AI IDE. Opětovné použití relace z předchozího workflow může způsobit konflikty kontextu.
### 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:
```text
run quick-dev — Fix the login validation bug that allows empty passwords.
```
```text
run quick-dev — fix https://github.com/org/repo/issues/42
```
```text
run quick-dev — 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
```
```text
run quick-dev
> What would you like to do?
Refactor UserService to use async/await instead of callbacks.
```
Prostý text, cesty k souborům, GitHub issue URL, odkazy na bug tracker — cokoli, co LLM dokáže převést na konkrétní záměr.
### 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.
### 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.
- 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.
:::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.
:::
## Co získáte
- Upravené zdrojové soubory s aplikovanou opravou nebo refaktoringem
- Procházející testy (pokud má váš projekt testovací sadu)
- Commit připravený k pushnutí s konvenční commit zprávou
## 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.
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.
## Kdy přejít na formální plánování
Zvažte použití plné metody BMad, 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) pro více informací o tom, jak Quick Dev zapadá do metody BMad.

View File

@ -0,0 +1,78 @@
---
title: "Průvodce dělením dokumentů"
description: Rozdělení velkých markdown souborů na menší organizované soubory pro lepší správu kontextu
sidebar:
order: 9
---
Použijte nástroj `bmad-shard-doc`, pokud potřebujete rozdělit velké markdown soubory na menší, organizované soubory pro lepší správu kontextu.
:::caution[Zastaralé]
Toto se již nedoporučuje a brzy s aktualizovanými workflow a většinou hlavních LLM a nástrojů podporujících subprocesy to bude zbytečné.
:::
## Kdy to použít
Použijte pouze pokud si všimnete, že váš zvolený nástroj / model nedokáže načíst a přečíst všechny dokumenty jako vstup, když je to potřeba.
## Co je dělení dokumentů?
Dělení dokumentů rozděluje velké markdown soubory na menší, organizované soubory na základě nadpisů úrovně 2 (`## Nadpis`).
### Architektura
```text
Před dělením:
_bmad-output/planning-artifacts/
└── PRD.md (velký soubor o 50k tokenech)
Po dělení:
_bmad-output/planning-artifacts/
└── prd/
├── index.md # Obsah s popisy
├── overview.md # Sekce 1
├── user-requirements.md # Sekce 2
├── technical-requirements.md # Sekce 3
└── ... # Další sekce
```
## Kroky
### 1. Spusťte nástroj Shard-Doc
```bash
/bmad-shard-doc
```
### 2. Následujte interaktivní proces
```text
Agent: Which document would you like to shard?
User: docs/PRD.md
Agent: Default destination: docs/prd/
Accept default? [y/n]
User: y
Agent: Sharding PRD.md...
✓ Created 12 section files
✓ Generated index.md
✓ Complete!
```
## Jak funguje vyhledávání workflow
BMad workflow používají **duální systém vyhledávání**:
1. **Nejprve zkusí celý dokument** — Hledá `document-name.md`
2. **Zkontroluje rozdělenou verzi** — Hledá `document-name/index.md`
3. **Pravidlo priority** — Celý dokument má přednost, pokud existují oba — odstraňte celý dokument, pokud chcete použít rozdělenou verzi
## Podpora workflow
Všechny BMM workflow podporují oba formáty:
- Celé dokumenty
- Rozdělené dokumenty
- Automatická detekce
- Transparentní pro uživatele

View File

@ -0,0 +1,100 @@
---
title: "Jak upgradovat na v6"
description: Migrace z BMad v4 na v6
sidebar:
order: 3
---
Použijte instalátor BMad pro upgrade z v4 na v6, který zahrnuje automatickou detekci starších instalací a asistenci při migraci.
## Kdy to použít
- Máte nainstalovaný BMad v4 (složka `.bmad-method`)
- Chcete migrovat na novou architekturu v6
- Máte existující plánovací artefakty k zachování
:::note[Předpoklady]
- Node.js 20+
- Existující instalace BMad v4
:::
## Kroky
### 1. Spusťte instalátor
Postupujte podle [instrukcí instalátoru](./install-bmad.md).
### 2. Zpracování starší instalace
Když je detekována v4, můžete:
- Nechat instalátor zálohovat a odstranit `.bmad-method`
- Ukončit a zpracovat vyčištění ručně
Pokud jste pojmenovali složku bmad method jinak, musíte ji odstranit ručně.
### 3. Vyčištění IDE skills
Ručně odstraňte starší v4 IDE příkazy/skills — například pokud máte Claude Code, hledejte vnořené složky začínající na bmad a odstraňte je:
- `.claude/commands/`
Nové v6 skills se instalují do:
- `.claude/skills/`
### 4. Migrace plánovacích artefaktů
**Pokud máte plánovací dokumenty (Brief/PRD/UX/Architektura):**
Přesuňte je do `_bmad-output/planning-artifacts/` s popisnými názvy:
- Zahrňte `PRD` v názvu souboru pro PRD dokumenty
- Zahrňte `brief`, `architecture` nebo `ux-design` odpovídajícím způsobem
- Rozdělené dokumenty mohou být v pojmenovaných podsložkách
**Pokud jste uprostřed plánování:** Zvažte restart s v6 workflow. Použijte existující dokumenty jako vstupy — nové workflow s progresivním objevováním, webovým vyhledáváním a plan mode IDE produkují lepší výsledky.
### 5. Migrace probíhajícího vývoje
Pokud máte vytvořené nebo implementované stories:
1. Dokončete instalaci v6
2. Umístěte `epics.md` nebo `epics/epic*.md` do `_bmad-output/planning-artifacts/`
3. Spusťte workflow `bmad-sprint-planning` Scrum Mastera
4. Řekněte SM, které epicy/stories jsou již dokončené
## Co získáte
**Sjednocená struktura v6:**
```text
váš-projekt/
├── _bmad/ # Jedna instalační složka
│ ├── _config/ # Vaše přizpůsobení
│ │ └── agents/ # Soubory přizpůsobení agentů
│ ├── core/ # Univerzální základní framework
│ ├── bmm/ # Modul BMad Method
│ ├── bmb/ # BMad Builder
│ └── cis/ # Creative Intelligence Suite
└── _bmad-output/ # Výstupní složka (v4 to byla složka dokumentů)
```
## Migrace modulů
| Modul v4 | Stav v6 |
| ----------------------------- | ---------------------------------- |
| `.bmad-2d-phaser-game-dev` | Integrován do modulu BMGD |
| `.bmad-2d-unity-game-dev` | Integrován do modulu BMGD |
| `.bmad-godot-game-dev` | Integrován do modulu BMGD |
| `.bmad-infrastructure-devops` | Zastaralý — nový DevOps agent brzy |
| `.bmad-creative-writing` | Neadaptován — nový v6 modul brzy |
## Klíčové změny
| Koncept | v4 | v6 |
| --------------- | ------------------------------------ | -------------------------------------- |
| **Core** | `_bmad-core` byl vlastně BMad Method | `_bmad/core/` je univerzální framework |
| **Method** | `_bmad-method` | `_bmad/bmm/` |
| **Konfigurace** | Přímá editace souborů | `config.yaml` pro každý modul |
| **Dokumenty** | Vyžadované nastavení shardů | Plně flexibilní, auto-skenování |

60
docs/cs/index.md Normal file
View File

@ -0,0 +1,60 @@
---
title: Vítejte v metodě BMad
description: Framework pro vývoj řízený umělou inteligencí se specializovanými agenty, řízenými pracovními postupy a inteligentním plánováním
---
Metoda BMad (**B**uild **M**ore **A**rchitect **D**reams) je framework pro vývoj řízený umělou inteligencí v rámci ekosystému BMad Method, který vám pomáhá vytvářet software celým procesem od nápadu a plánování až po agentní implementaci. Poskytuje specializované AI agenty, řízené pracovní postupy a inteligentní plánování, které se přizpůsobí složitosti vašeho projektu, ať už opravujete chybu nebo budujete podnikovou platformu.
Pokud jste zvyklí pracovat s AI asistenty pro kódování jako Claude, Cursor nebo GitHub Copilot, jste připraveni začít.
:::note[🚀 V6 je tady a teprve začínáme!]
Architektura Skills, BMad Builder v1, automatizace Dev Loop a mnoho dalšího ve vývoji. **[Podívejte se na Plán rozvoje →](./roadmap)**
:::
## Jste tu nově? Začněte tutoriálem
Nejrychlejší způsob, jak pochopit BMad, je vyzkoušet si ho.
- **[Začínáme s BMad](./tutorials/getting-started.md)** — Instalace a pochopení fungování BMad
- **[Mapa pracovních postupů](./reference/workflow-map.md)** — Vizuální přehled fází BMM, pracovních postupů a správy kontextu
:::tip[Chcete se rovnou ponořit?]
Nainstalujte BMad a použijte skill `bmad-help` — provede vás vším na základě vašeho projektu a nainstalovaných modulů.
:::
## Jak používat tuto dokumentaci
Tato dokumentace je organizována do čtyř sekcí podle toho, co chcete dělat:
| Sekce | Účel |
| -------------------- | ------------------------------------------------------------------------------------------------------------------ |
| **Tutoriály** | Orientované na učení. Průvodci krok za krokem, kteří vás provedou tvorbou něčeho. Začněte zde, pokud jste noví. |
| **Praktické návody** | Orientované na úkoly. Praktičtí průvodci pro řešení konkrétních problémů. „Jak přizpůsobím agenta?“ najdete zde. |
| **Vysvětlení** | Orientované na pochopení. Hluboké ponory do konceptů a architektury. Čtěte, když chcete vědět *proč*. |
| **Reference** | Orientované na informace. Technické specifikace agentů, pracovních postupů a konfigurace. |
## Rozšíření a přizpůsobení
Chcete rozšířit BMad o vlastní agenty, pracovní postupy nebo moduly? **[BMad Builder](https://bmad-builder-docs.bmad-method.org/)** poskytuje framework a nástroje pro vytváření vlastních rozšíření, ať už přidáváte nové schopnosti do BMad nebo budujete zcela nové moduly od základů.
## Co budete potřebovat
BMad funguje s jakýmkoli AI asistentem pro kódování, který podporuje vlastní systémové prompty nebo kontextové soubory projektu. Oblíbené možnosti zahrnují:
- **[Claude Code](https://code.claude.com)** — CLI nástroj od Anthropic (doporučený)
- **[Cursor](https://cursor.sh)** — AI-first editor kódu
- **[Codex CLI](https://github.com/openai/codex)** — Terminálový kódovací agent od OpenAI
Měli byste být obeznámeni se základními koncepty vývoje softwaru jako správa verzí, struktura projektu a agilní pracovní postupy. Žádná předchozí zkušenost se systémy agentů ve stylu BMad není vyžadována — právě od toho je tato dokumentace.
## Připojte se ke komunitě
Získejte pomoc, sdílejte co budujete, nebo přispějte do BMad:
- **[Discord](https://discord.gg/gk8jAdXWmj)** — Chatujte s ostatními uživateli BMad, pokládejte otázky, sdílejte nápady
- **[GitHub](https://github.com/bmad-code-org/BMAD-METHOD)** — Zdrojový kód, issues a příspěvky
- **[YouTube](https://www.youtube.com/@BMadCode)** — Video tutoriály a návody
## Další krok
Jste připraveni se ponořit? **[Začněte s BMad](./tutorials/getting-started.md)** a vytvořte svůj první projekt.

View File

@ -0,0 +1,58 @@
---
title: Agenti
description: Výchozí BMM agenti s jejich skill ID, spouštěči nabídky a primárními workflow
sidebar:
order: 2
---
## Výchozí agenti
Tato stránka uvádí výchozí BMM (Agile suite) agenty, kteří se instalují s BMad Method, společně s jejich skill ID, spouštěči nabídky a primárními workflow. Každý agent se vyvolává jako skill.
## Poznámky
- Každý agent je dostupný jako skill, generovaný instalátorem. Skill ID (např. `bmad-dev`) se používá k vyvolání agenta.
- Spouštěče jsou krátké kódy nabídky (např. `CP`) a fuzzy shody zobrazené v nabídce každého agenta.
- QA (Quinn) je lehký agent pro automatizaci testů v BMM. Plný Test Architect (TEA) žije ve vlastním modulu.
| Agent | Skill ID | Spouštěče | Primární workflow |
| --------------------------- | -------------------- | ---------------------------------- | --------------------------------------------------------------------------------------------------- |
| Analyst (Mary) | `bmad-analyst` | `BP`, `RS`, `CB`, `DP` | Brainstorm projektu, výzkum, tvorba briefu, 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 |
| Scrum Master (Bob) | `bmad-sm` | `SP`, `CS`, `ER`, `CC` | Plánování sprintu, tvorba story, retrospektiva epicu, korekce kurzu |
| Developer (Amelia) | `bmad-dev` | `DS`, `CR` | Dev story, revize kódu |
| QA Engineer (Quinn) | `bmad-qa` | `QA` | Automate (generování testů pro existující funkce) |
| Quick Flow Solo Dev (Barry) | `bmad-master` | `QD`, `CR` | Quick Dev, revize kódu |
| 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 |
## Typy spouštěčů
Spouštěče nabídky agentů používají dva různé typy vyvolání. Znalost typu spouštěče vám pomůže poskytnout správný vstup.
### Workflow spouštěče (bez argumentů)
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), `DS` (Dev story), `CA` (tvorba architektury), `QD` (Quick Dev)
### Konverzační spouštěče (vyžadují argumenty)
Některé spouštěče zahajují volnou konverzaci místo strukturovaného workflow. Tyto očekávají, že popíšete, co potřebujete, společně s kódem spouštěče.
| Agent | Spouštěč | Co poskytnout |
| --- | --- | --- |
| Technical Writer (Paige) | `WD` | Popis dokumentu k napsání |
| Technical Writer (Paige) | `US` | Preference nebo konvence k přidání do standardů |
| Technical Writer (Paige) | `MG` | Popis diagramu a typ (sekvence, vývojový diagram atd.) |
| Technical Writer (Paige) | `VD` | Dokument k validaci a oblasti zaměření |
| Technical Writer (Paige) | `EC` | Název konceptu k vysvětlení |
**Příklad:**
```text
WD Write a deployment guide for our Docker setup
MG Create a sequence diagram showing the auth flow
EC Explain how the module system works
```

View File

@ -0,0 +1,134 @@
---
title: Skills
description: Reference BMad skills — co to je, jak fungují a kde je najít.
sidebar:
order: 3
---
Skills jsou předpřipravené prompty, které načítají agenty, spouštějí workflow nebo provádějí úkoly ve vašem IDE. Instalátor BMad je generuje z vašich nainstalovaných modulů při instalaci. Pokud později přidáte, odeberete nebo změníte moduly, přeinstalujte pro synchronizaci skills (viz [Řešení problémů](#řešení-problémů)).
## Skills vs. spouštěče nabídky agentů
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ř. `DS`) | 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.
## Jak se skills generují
Když spustíte `npx bmad-method install`, instalátor čte manifesty každého vybraného modulu a zapíše jeden skill na agenta, workflow, úkol a nástroj. Každý skill je adresář obsahující soubor `SKILL.md`, který instruuje AI k načtení odpovídajícího zdrojového souboru a následování jeho instrukcí.
Instalátor používá šablony pro každý typ skillu:
| Typ skillu | Co generovaný soubor dělá |
| --- | --- |
| **Spouštěč agenta** | Načte soubor persony agenta, aktivuje jeho nabídku a zůstává v charakteru |
| **Workflow skill** | Načte konfiguraci workflow a následuje jeho kroky |
| **Task skill** | Načte samostatný soubor úkolu a následuje jeho instrukce |
| **Tool skill** | Načte samostatný soubor nástroje a následuje jeho instrukce |
:::note[Opětovné spuštění instalátoru]
Pokud přidáte nebo odeberete moduly, spusťte instalátor znovu. Přegeneruje všechny soubory skills tak, aby odpovídaly vašemu aktuálnímu výběru modulů.
:::
## Kde žijí soubory skills
Instalátor zapisuje soubory skills do adresáře specifického pro IDE uvnitř vašeho projektu. Přesná cesta závisí na IDE, které jste vybrali během instalace.
| IDE / CLI | Adresář skills |
| --- | --- |
| Claude Code | `.claude/skills/` |
| Cursor | `.cursor/skills/` |
| Windsurf | `.windsurf/skills/` |
| Další IDE | Viz výstup instalátoru pro cílovou cestu |
Každý skill je adresář obsahující soubor `SKILL.md`. Například instalace Claude Code vypadá takto:
```text
.claude/skills/
├── bmad-help/
│ └── SKILL.md
├── bmad-create-prd/
│ └── SKILL.md
├── bmad-dev/
│ └── SKILL.md
└── ...
```
Název adresáře určuje název skillu ve vašem IDE. Například adresář `bmad-dev/` registruje skill `bmad-dev`.
## Jak objevit vaše skills
Zadejte název skillu ve vašem IDE pro jeho vyvolání. Některé platformy vyžadují povolení skills v nastavení, než se zobrazí.
Spusťte `bmad-help` pro kontextové poradenství k dalšímu kroku.
:::tip[Rychlé objevování]
Generované adresáře skills ve vašem projektu jsou kanonický seznam. Otevřete je v prohlížeči souborů, abyste viděli každý skill s jeho popisem.
:::
## Kategorie skills
### Agentní skills
Agentní skills načítají specializovanou AI personu s definovanou rolí, komunikačním stylem a nabídkou workflow. Po načtení agent zůstává v charakteru a reaguje na spouštěče nabídky.
| Příklad skillu | Agent | Role |
| --- | --- | --- |
| `bmad-dev` | Amelia (Developer) | Implementuje stories s přísným dodržováním specifikací |
| `bmad-pm` | John (Product Manager) | Vytváří a validuje PRD |
| `bmad-architect` | Winston (Architect) | Navrhuje systémovou architekturu |
| `bmad-sm` | Bob (Scrum Master) | Řídí sprinty a stories |
Viz [Agenti](./agents.md) pro úplný seznam výchozích agentů a jejich spouštěčů.
### Workflow skills
Workflow skills spouštějí strukturovaný, vícekrokový proces bez předchozího načtení persony agenta. Načtou konfiguraci workflow a následují jeho kroky.
| Příklad skillu | Účel |
| --- | --- |
| `bmad-create-prd` | Vytvoření dokumentu požadavků (PRD) |
| `bmad-create-architecture` | Návrh systémové architektury |
| `bmad-create-epics-and-stories` | Vytvoření epiců a stories |
| `bmad-dev-story` | Implementace story |
| `bmad-code-review` | Spuštění revize kódu |
| `bmad-quick-dev` | Sjednocený quick flow — vyjasnění záměru, plán, implementace, revize, prezentace |
Viz [Mapa pracovních postupů](./workflow-map.md) pro kompletní referenci workflow organizovanou podle fází.
### Task a tool skills
Tasks a tools jsou samostatné operace, které nevyžadují kontext agenta nebo workflow.
**BMad-Help: Váš inteligentní průvodce**
`bmad-help` je vaše primární rozhraní pro objevení, co dělat dál. Zkoumá váš projekt, rozumí dotazům v přirozeném jazyce a doporučuje další povinný nebo volitelný krok na základě nainstalovaných modulů.
:::note[Příklad]
```
bmad-help
bmad-help I have a SaaS idea and know all the features. Where do I start?
bmad-help What are my options for UX design?
```
:::
**Další základní tasks a tools**
Základní modul zahrnuje 11 vestavěných nástrojů — revize, komprese, brainstorming, správa dokumentů a další. Viz [Základní nástroje](./core-tools.md) pro kompletní referenci.
## Konvence pojmenování
Všechny skills používají prefix `bmad-` následovaný popisným názvem (např. `bmad-dev`, `bmad-create-prd`, `bmad-help`). Viz [Moduly](./modules.md) pro dostupné moduly.
## Řešení problémů
**Skills se nezobrazují po instalaci.** Některé platformy vyžadují explicitní povolení skills v nastavení. Zkontrolujte dokumentaci vašeho IDE nebo se zeptejte AI asistenta, jak skills povolit. Může být také nutné restartovat IDE nebo znovu načíst okno.
**Očekávané skills chybí.** Instalátor generuje skills pouze pro moduly, které jste vybrali. Spusťte `npx bmad-method install` znovu a ověřte výběr modulů. Zkontrolujte, že soubory skills existují v očekávaném adresáři.
**Skills z odebraného modulu se stále zobrazují.** Instalátor automaticky nemaže staré soubory skills. Odstraňte zastaralé adresáře z adresáře skills vašeho IDE, nebo smažte celý adresář skills a přeinstalujte pro čistou sadu.

View File

@ -0,0 +1,292 @@
---
title: Základní nástroje
description: Reference všech vestavěných úkolů a workflow dostupných v každé instalaci BMad bez dalších modulů.
sidebar:
order: 2
---
Každá instalace BMad zahrnuje sadu základních skills, které lze použít v kombinaci s čímkoli — samostatné úkoly a workflow, které fungují napříč všemi projekty, všemi moduly a všemi fázemi. Ty jsou vždy dostupné bez ohledu na to, které volitelné moduly nainstalujete.
:::tip[Rychlá cesta]
Spusťte jakýkoli základní nástroj zadáním jeho názvu skillu (např. `bmad-help`) ve vašem IDE. Nevyžaduje relaci agenta.
:::
## Přehled
| Nástroj | Typ | Účel |
| --- | --- | --- |
| [`bmad-help`](#bmad-help) | Task | Kontextové poradenství, co dělat dál |
| [`bmad-brainstorming`](#bmad-brainstorming) | Workflow | Facilitace interaktivních brainstormingových sezení |
| [`bmad-party-mode`](#bmad-party-mode) | Workflow | Orchestrace skupinových diskuzí více agentů |
| [`bmad-distillator`](#bmad-distillator) | Task | Bezeztrátová LLM-optimalizovaná komprese dokumentů |
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | Task | Iterativní zdokonalování LLM výstupu |
| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | Task | Cynická revize hledající chybějící a chybné |
| [`bmad-review-edge-case-hunter`](#bmad-review-edge-case-hunter) | Task | Vyčerpávající analýza větvících cest pro neošetřené hraniční případy |
| [`bmad-editorial-review-prose`](#bmad-editorial-review-prose) | Task | Klinická jazyková korektura pro komunikační srozumitelnost |
| [`bmad-editorial-review-structure`](#bmad-editorial-review-structure) | Task | Strukturální editace — škrty, sloučení a reorganizace |
| [`bmad-shard-doc`](#bmad-shard-doc) | Task | Rozdělení velkých markdown souborů do organizovaných sekcí |
| [`bmad-index-docs`](#bmad-index-docs) | Task | Generování nebo aktualizace indexu dokumentů ve složce |
## bmad-help
**Váš inteligentní průvodce tím, co přijde dál.** — Zkoumá stav vašeho projektu, detekuje, co bylo uděláno, a doporučuje další povinný nebo volitelný krok.
**Použijte když:**
- Dokončili jste workflow a chcete vědět, co dál
- Jste noví v BMad a potřebujete orientaci
- Jste uvízlí a chcete kontextovou radu
- Nainstalovali jste nové moduly a chcete vidět, co je dostupné
**Jak to funguje:**
1. Skenuje projekt pro existující artefakty (PRD, architektura, stories atd.)
2. Detekuje nainstalované moduly a dostupné workflow
3. Doporučuje další kroky v pořadí priority — nejprve povinné, pak volitelné
4. Prezentuje každé doporučení s příkazem skillu a stručným popisem
**Vstup:** Volitelný dotaz v přirozeném jazyce (např. `bmad-help I have a SaaS idea, where do I start?`)
**Výstup:** Prioritizovaný seznam doporučených dalších kroků s příkazy skills
## bmad-brainstorming
**Generování různorodých nápadů prostřednictvím interaktivních kreativních technik.** — Facilitované brainstormingové sezení, které načítá osvědčené ideační metody z knihovny technik a vede vás k 100+ nápadům před organizací.
**Použijte když:**
- Začínáte nový projekt a potřebujete prozkoumat problémový prostor
- Jste uvízlí s generováním nápadů a potřebujete strukturovanou kreativitu
- Chcete použít osvědčené ideační frameworky (SCAMPER, reverzní brainstorming atd.)
**Jak to funguje:**
1. Nastaví brainstormingové sezení s vaším tématem
2. Načte kreativní techniky z knihovny metod
3. Provede vás technikou za technikou, generuje nápady
4. Aplikuje anti-bias protokol — mění kreativní doménu každých 10 nápadů
5. Produkuje append-only dokument sezení se všemi nápady organizovanými podle techniky
**Vstup:** Téma brainstormingu nebo formulace problému, volitelný kontextový soubor
**Výstup:** `brainstorming-session-{date}.md` se všemi generovanými nápady
:::note[Cíl množství]
Kouzlo se děje v nápadech 50–100. Workflow povzbuzuje generování 100+ nápadů před organizací.
:::
## bmad-party-mode
**Orchestrace skupinových diskuzí více agentů.** — Načte všechny nainstalované BMad agenty a facilituje přirozenou konverzaci, kde každý agent přispívá svou unikátní odborností a osobností.
**Použijte když:**
- Potřebujete více expertních perspektiv na rozhodnutí
- Chcete, aby agenti zpochybňovali předpoklady ostatních
- Zkoumáte složité téma překračující více domén
**Jak to funguje:**
1. Načte manifest agentů se všemi nainstalovanými osobnostmi
2. Analyzuje vaše téma a vybere 2–3 nejrelevantnější agenty
3. Agenti se střídají v přispívání, s přirozenou kříženou diskuzí a nesouhlasy
4. Rotuje účast agentů pro zajištění různorodých perspektiv
5. Ukončete pomocí `goodbye`, `end party` nebo `quit`
**Vstup:** Diskuzní téma nebo otázka, s volitelnou specifikací person
**Výstup:** Real-time multi-agentní konverzace s udržovanými osobnostmi agentů
## bmad-distillator
**Bezeztrátová LLM-optimalizovaná komprese zdrojových dokumentů.** — Produkuje husté, tokenově efektivní destiláty, které zachovávají všechny informace pro následné LLM zpracování. Ověřitelné prostřednictvím round-trip rekonstrukce.
**Použijte když:**
- Dokument je příliš velký pro kontextové okno LLM
- Potřebujete tokenově efektivní verze výzkumů, specifikací nebo plánovacích artefaktů
- Chcete ověřit, že během komprese nebyly ztraceny žádné informace
**Jak to funguje:**
1. **Analýza** — Čte zdrojové dokumenty, identifikuje hustotu informací a strukturu
2. **Komprese** — Převádí prózu na hustý odrážkový formát, odstraňuje dekorativní formátování
3. **Ověření** — Kontroluje úplnost pro zajištění zachování všech informací
4. **Validace** (volitelné) — Round-trip rekonstrukční test dokazuje bezeztrátovou kompresi
**Vstup:**
- `source_documents` (povinné) — Cesty k souborům, složkám nebo glob vzory
- `downstream_consumer` (volitelné) — Co to konzumuje (např. „tvorba PRD“)
- `token_budget` (volitelné) — Přibližná cílová velikost
- `--validate` (příznak) — Spuštění round-trip rekonstrukčního testu
**Výstup:** Destilátové markdown soubory s reportem kompresního poměru (např. „3.2:1“)
## bmad-advanced-elicitation
**Iterativní zdokonalování LLM výstupu metodami elicitace.** — Vybírá z knihovny elicitačních technik pro systematické zlepšování obsahu více průchody.
**Použijte když:**
- LLM výstup působí povrchně nebo genericky
- Chcete prozkoumat téma z více analytických úhlů
- Zdokonalujete kritický dokument a chcete hlubší myšlení
**Jak to funguje:**
1. Načte registr metod s 5+ elicitačními technikami
2. Vybere 5 nejlépe odpovídajících metod podle typu a složitosti obsahu
3. Prezentuje interaktivní nabídku — vyberte metodu, zamíchejte nebo zobrazte vše
4. Aplikuje vybranou metodu k vylepšení obsahu
5. Znovu prezentuje možnosti pro iterativní zlepšení, dokud nevyberete „Pokračovat“
**Vstup:** Sekce obsahu k vylepšení
**Výstup:** Vylepšená verze obsahu s aplikovanými zlepšeními
## bmad-review-adversarial-general
**Cynická revize, která předpokládá existenci problémů a hledá je.** — Zaujme perspektivu skeptického, otráveného recenzenta s nulovou tolerancí pro nedbalou práci. Hledá, co chybí, ne jen co je špatně.
**Použijte když:**
- Potřebujete zajištění kvality před finalizací výstupu
- Chcete zátěžově otestovat specifikaci, story nebo dokument
- Chcete najít mezery v pokrytí, které optimistické revize přehlédnou
**Jak to funguje:**
1. Čte obsah s cynickou, kritickou perspektivou
2. Identifikuje problémy v úplnosti, správnosti a kvalitě
3. Specificky hledá, co chybí — ne jen co je přítomné a špatné
4. Musí najít minimálně 10 problémů nebo analyzuje hlouběji
**Vstup:**
- `content` (povinné) — Diff, specifikace, story, dokument nebo jakýkoli artefakt
- `also_consider` (volitelné) — Další oblasti k zvážení
**Výstup:** Markdown seznam 10+ nálezů s popisy
## bmad-review-edge-case-hunter
**Procházení každé větvící cesty a hraničních podmínek, hlášení pouze neošetřených případů.** — Čistě metodologický přístup trasování cest, který mechanicky odvozuje třídy hraničních případů.
**Použijte když:**
- Chcete vyčerpávající pokrytí hraničních případů pro kód nebo logiku
- Potřebujete doplněk k adversariální revizi (jiná metodologie, jiné nálezy)
- Revidujete diff nebo funkci pro hraniční podmínky
**Jak to funguje:**
1. Enumeruje všechny větvící cesty v obsahu
2. Mechanicky odvozuje třídy případů: chybějící else/default, nestřežené vstupy, off-by-one, přetečení aritmetiky, implicitní typová koerce, race conditions, mezery v timeoutech
3. Testuje každou cestu proti existujícím ochranám
4. Hlásí pouze neošetřené cesty — tiše zahazuje ošetřené
**Vstup:**
- `content` (povinné) — Diff, celý soubor nebo funkce
- `also_consider` (volitelné) — Další oblasti k zvážení
**Výstup:** JSON pole nálezů, každý s `location`, `trigger_condition`, `guard_snippet` a `potential_consequence`
:::note[Komplementární revize]
Spusťte obě `bmad-review-adversarial-general` a `bmad-review-edge-case-hunter` společně pro ortogonální pokrytí. Adversariální revize zachytí problémy kvality a úplnosti; hunter hraničních případů zachytí neošetřené cesty.
:::
## bmad-editorial-review-prose
**Klinická jazyková korektura zaměřená na srozumitelnost komunikace.** — Reviduje text pro problémy bránící porozumění. Aplikuje baseline Microsoft Writing Style Guide. Zachovává autorský hlas.
**Použijte když:**
- Napsali jste dokument a chcete vylepšit psaní
- Potřebujete zajistit srozumitelnost pro konkrétní publikum
- Chcete komunikační opravy bez změn stylistických preferencí
**Jak to funguje:**
1. Čte obsah, přeskakuje bloky kódu a frontmatter
2. Identifikuje komunikační problémy (ne stylistické preference)
3. Deduplikuje stejné problémy napříč více lokacemi
4. Produkuje třísloupcovou tabulku oprav
**Vstup:**
- `content` (povinné) — Markdown, prostý text nebo XML
- `style_guide` (volitelné) — Projektově specifický průvodce stylem
- `reader_type` (volitelné) — `humans` (výchozí) pro srozumitelnost/plynulost, nebo `llm` pro přesnost/konzistenci
**Výstup:** Třísloupcová markdown tabulka: Původní text | Revidovaný text | Změny
## bmad-editorial-review-structure
**Strukturální editace — navrhuje škrty, sloučení, přesuny a zhuštění.** — Reviduje organizaci dokumentu a navrhuje substantivní změny pro zlepšení srozumitelnosti a toku před jazykovou korekcí.
**Použijte když:**
- Dokument byl vytvořen z více subprocesů a potřebuje strukturální koherenci
- Chcete zkrátit dokument při zachování porozumění
- Potřebujete identifikovat porušení rozsahu nebo pohřbené kritické informace
**Jak to funguje:**
1. Analyzuje dokument proti 5 strukturním modelům (Tutorial, Reference, Explanation, Prompt, Strategic)
2. Identifikuje redundance, porušení rozsahu a pohřbené informace
3. Produkuje prioritizovaná doporučení: CUT, MERGE, MOVE, CONDENSE, QUESTION, PRESERVE
4. Odhaduje celkovou redukci ve slovech a procentech
**Vstup:**
- `content` (povinné) — Dokument k revizi
- `purpose` (volitelné) — Zamýšlený účel (např. „quickstart tutoriál“)
- `target_audience` (volitelné) — Kdo to čte
- `reader_type` (volitelné) — `humans` nebo `llm`
- `length_target` (volitelné) — Cílová redukce (např. „o 30 % kratší“)
**Výstup:** Shrnutí dokumentu, prioritizovaný seznam doporučení a odhadovaná redukce
## bmad-shard-doc
**Rozdělení velkých markdown souborů do organizovaných souborů sekcí.** — Používá nadpisy úrovně 2 jako body dělení k vytvoření složky samostatných souborů sekcí s indexem.
**Použijte když:**
- Markdown dokument narostl na nezvládnutelnou velikost (500+ řádků)
- Chcete rozložit monolitický dokument na navigovatelné sekce
- Potřebujete samostatné soubory pro paralelní editaci nebo správu LLM kontextu
**Jak to funguje:**
1. Validuje, že zdrojový soubor existuje a je markdown
2. Dělí na nadpisech úrovně 2 (`##`) do číslovaných souborů sekcí
3. Vytváří `index.md` s manifestem sekcí a odkazy
4. Vyzve vás ke smazání, archivaci nebo zachování originálu
**Vstup:** Cesta ke zdrojovému markdown souboru, volitelná cílová složka
**Výstup:** Složka s `index.md` a `01-{sekce}.md`, `02-{sekce}.md` atd.
## bmad-index-docs
**Generování nebo aktualizace indexu všech dokumentů ve složce.** — Skenuje adresář, čte každý soubor pro pochopení jeho účelu a produkuje organizovaný `index.md` s odkazy a popisy.
**Použijte když:**
- Potřebujete lehký index pro rychlé LLM skenování dostupných dokumentů
- Složka dokumentace narostla a potřebuje organizovaný obsah
- Chcete automaticky generovaný přehled, který zůstává aktuální
**Jak to funguje:**
1. Skenuje cílový adresář pro všechny neskryté soubory
2. Čte každý soubor pro pochopení jeho skutečného účelu
3. Seskupuje soubory podle typu, účelu nebo podadresáře
4. Generuje stručné popisy (3–10 slov každý)
**Vstup:** Cesta k cílové složce
**Výstup:** `index.md` s organizovanými výpisy souborů, relativními odkazy a stručnými popisy

View File

@ -0,0 +1,76 @@
---
title: Oficiální moduly
description: Doplňkové moduly pro tvorbu vlastních agentů, kreativní inteligenci, vývoj her a testování
sidebar:
order: 4
---
BMad se rozšiřuje prostřednictvím oficiálních modulů, které vyberete během instalace. Tyto doplňkové moduly poskytují specializované agenty, workflow a úkoly pro specifické domény nad rámec vestavěného jádra a BMM (Agile suite).
:::tip[Instalace modulů]
Spusťte `npx bmad-method install` a vyberte požadované moduly. Instalátor se postará o stažení, konfiguraci a integraci s IDE automaticky.
:::
## BMad Builder
Vytvářejte vlastní agenty, workflow a doménově specifické moduly s řízenou asistencí. BMad Builder je meta-modul pro rozšiřování samotného frameworku.
- **Kód:** `bmb`
- **npm:** [`bmad-builder`](https://www.npmjs.com/package/bmad-builder)
- **GitHub:** [bmad-code-org/bmad-builder](https://github.com/bmad-code-org/bmad-builder)
**Poskytuje:**
- Agent Builder — tvorba specializovaných AI agentů s vlastní odborností a přístupem k nástrojům
- Workflow Builder — návrh strukturovaných procesů s kroky a rozhodovacími body
- Module Builder — balíčkování agentů a workflow do sdílitelných, publikovatelných modulů
- Interaktivní nastavení s YAML konfigurací a podporou npm publikování
## Creative Intelligence Suite
AI nástroje pro strukturovanou kreativitu, ideaci a inovace v rané fázi vývoje. Suite poskytuje více agentů, kteří facilitují brainstorming, design thinking a řešení problémů pomocí osvědčených frameworků.
- **Kód:** `cis`
- **npm:** [`bmad-creative-intelligence-suite`](https://www.npmjs.com/package/bmad-creative-intelligence-suite)
- **GitHub:** [bmad-code-org/bmad-module-creative-intelligence-suite](https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite)
**Poskytuje:**
- Agenty Innovation Strategist, Design Thinking Coach a Brainstorming Coach
- Problem Solver a Creative Problem Solver pro systematické a laterální myšlení
- Storyteller a Presentation Master pro narativy a prezentace
- Ideační frameworky včetně SCAMPER, reverzního brainstormingu a přeformulování problémů
## Game Dev Studio
Strukturované workflow pro vývoj her adaptované pro Unity, Unreal, Godot a vlastní enginy. Podporuje rychlé prototypování přes Quick Flow a plnoscálovou produkci s epicky řízenými sprinty.
- **Kód:** `gds`
- **npm:** [`bmad-game-dev-studio`](https://www.npmjs.com/package/bmad-game-dev-studio)
- **GitHub:** [bmad-code-org/bmad-module-game-dev-studio](https://github.com/bmad-code-org/bmad-module-game-dev-studio)
**Poskytuje:**
- Workflow pro generování Game Design Document (GDD)
- Režim Quick Dev pro rychlé prototypování
- 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
## Test Architect (TEA)
Podniková testovací strategie, vedení automatizace a rozhodování o release gate prostřednictvím expertního agenta a devíti strukturovaných workflow. TEA jde daleko za vestavěného QA agenta s prioritizací založenou na riziku a trasovatelností požadavků.
- **Kód:** `tea`
- **npm:** [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
- **GitHub:** [bmad-code-org/bmad-method-test-architecture-enterprise](https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise)
**Poskytuje:**
- Agenta Murat (Master Test Architect a Quality Advisor)
- Workflow pro testovací design, ATDD, automatizaci, revizi testů a trasovatelnost
- Hodnocení NFR, nastavení CI a scaffolding frameworku
- Prioritizaci P0-P3 s volitelnými integracemi Playwright Utils a MCP
## Komunitní moduly
Komunitní moduly a marketplace modulů přicházejí. Sledujte [organizaci BMad na GitHubu](https://github.com/bmad-code-org) pro aktualizace.

View File

@ -0,0 +1,106 @@
---
title: Možnosti testování
description: Srovnání vestavěného QA agenta (Quinn) s modulem Test Architect (TEA) pro automatizaci testů.
sidebar:
order: 5
---
BMad poskytuje dvě testovací cesty: vestavěného QA agenta pro rychlé generování testů a instalovatelný modul Test Architect pro podnikovou testovací strategii.
## Který byste měli použít?
| Faktor | Quinn (vestavěný QA) | Modul TEA |
| --- | --- | --- |
| **Nejlepší pro** | Malé až střední projekty, rychlé pokrytí | Velké projekty, regulované nebo složité domény |
| **Nastavení** | Nic k instalaci — součástí BMM | Instalace zvlášť přes `npx bmad-method install` |
| **Přístup** | Generujte testy rychle, iterujte později | Nejprve plánujte, pak generujte s trasovatelností |
| **Typy testů** | API a E2E testy | API, E2E, ATDD, NFR a další |
| **Strategie** | Happy path + kritické hraniční případy | Prioritizace založená na riziku (P0–P3) |
| **Počet workflow** | 1 (Automate) | 9 (design, ATDD, automate, review, trace a další) |
:::tip[Začněte s Quinnem]
Většina projektů by měla začít s Quinnem. Pokud později budete potřebovat testovací strategii, quality gates nebo trasovatelnost požadavků, nainstalujte TEA vedle něj.
:::
## Vestavěný QA agent (Quinn)
Quinn je vestavěný QA agent v modulu BMM (Agile suite). Rychle generuje funkční testy pomocí existujícího testovacího frameworku vašeho projektu — bez konfigurace nebo další instalace.
**Spouštěč:** `QA` nebo `bmad-qa-generate-e2e-tests`
### Co Quinn dělá
Quinn spouští jeden workflow (Automate), který projde pěti kroky:
1. **Detekce testovacího frameworku** — skenuje `package.json` a existující testovací soubory pro váš framework (Jest, Vitest, Playwright, Cypress nebo jakýkoli standardní runner). Pokud neexistuje, analyzuje stack projektu a navrhne jeden.
2. **Identifikace funkcí** — zeptá se, co testovat, nebo automaticky objeví funkce v kódové bázi.
3. **Generování API testů** — pokrývá stavové kódy, strukturu odpovědí, happy path a 1–2 chybové případy.
4. **Generování E2E testů** — pokrývá uživatelské workflow se sémantickými lokátory a asercemi viditelných výsledků.
5. **Spuštění a ověření** — provede generované testy a okamžitě opraví selhání.
Quinn produkuje shrnutí testů uložené do složky implementačních artefaktů vašeho projektu.
### Vzory testů
Generované testy sledují filozofii „jednoduché a udržovatelné“:
- **Pouze standardní API frameworku** — žádné externí utility nebo vlastní abstrakce
- **Sémantické lokátory** pro UI testy (role, popisky, text místo CSS selektorů)
- **Nezávislé testy** bez závislostí na pořadí
- **Žádné hardcoded waity nebo sleep**
- **Jasné popisy**, které se čtou jako dokumentace funkcí
:::note[Rozsah]
Quinn generuje pouze testy. Pro revizi kódu a validaci stories použijte workflow Code Review (`CR`).
:::
### Kdy použít Quinna
- Rychlé pokrytí testy pro novou nebo existující funkci
- Automatizace testů přátelská k začátečníkům bez pokročilého nastavení
- Standardní vzory testů, které může číst a udržovat jakýkoli vývojář
- Malé až střední projekty, kde komplexní testovací strategie není potřeba
## Modul Test Architect (TEA)
TEA je samostatný modul, který poskytuje expertního agenta (Murat) a devět strukturovaných workflow pro podnikové testování. Jde za rámec generování testů do testovací strategie, plánování založeného na riziku, quality gates a trasovatelnosti požadavků.
- **Dokumentace:** [Dokumentace modulu TEA](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/)
- **Instalace:** `npx bmad-method install` a výběr modulu TEA
- **npm:** [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
### Co TEA poskytuje
| Workflow | Účel |
| --- | --- |
| Test Design | Vytvoření komplexní testovací strategie vázané na požadavky |
| ATDD | Acceptance-test-driven development s kritérii stakeholderů |
| Automate | Generování testů s pokročilými vzory a utilitami |
| Test Review | Validace kvality a pokrytí testů proti strategii |
| Traceability | Mapování testů zpět na požadavky pro audit a compliance |
| NFR Assessment | Hodnocení nefunkčních požadavků (výkon, bezpečnost) |
| CI Setup | Konfigurace provádění testů v CI pipelines |
| Framework Scaffolding | Nastavení testovací infrastruktury a struktury projektu |
| Release Gate | Datově založená rozhodnutí go/no-go pro release |
TEA také podporuje prioritizaci P0–P3 založenou na riziku a volitelné integrace s Playwright Utils a MCP nástroji.
### Kdy použít TEA
- Projekty vyžadující trasovatelnost požadavků nebo compliance dokumentaci
- Týmy potřebující prioritizaci testů založenou na riziku napříč mnoha funkcemi
- Podniková prostředí s formálními quality gates před releasem
- Složité domény, kde musí být testovací strategie naplánována před psaním testů
- Projekty, které přerostly jednoduchý workflow Quinna
## Jak testování zapadá do workflow
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 s Dev (`DS`), pak validace pomocí 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í
Quinn pracuje přímo ze zdrojového kódu bez načítání plánovacích dokumentů (PRD, architektura). TEA workflow mohou integrovat s upstream plánovacími artefakty pro trasovatelnost.
Pro více o tom, kde testování zapadá do celkového procesu, viz [Mapa pracovních postupů](./workflow-map.md).

View File

@ -0,0 +1,88 @@
---
title: "Mapa pracovních postupů"
description: Vizuální reference fází workflow BMad Method a jejich výstupů
sidebar:
order: 1
---
BMad Method (BMM) je modul v ekosystému BMad, zaměřený na dodržování osvědčených postupů context engineeringu a plánování. AI agenti fungují nejlépe s jasným, strukturovaným kontextem. Systém BMM buduje tento kontext progresivně napříč 4 odlišnými fázemi — každá fáze a volitelně více workflow v každé fázi produkují dokumenty, které informují další, takže agenti vždy vědí, co budovat a proč.
Zdůvodnění a koncepty vycházejí z agilních metodik, které byly v průmyslu úspěšně používány jako mentální framework.
Pokud si kdykoli nejste jisti, co dělat, skill `bmad-help` vám pomůže zůstat na cestě nebo vědět, co dělat dál. Vždy se můžete odkázat sem — ale `bmad-help` je plně interaktivní a mnohem rychlejší, pokud již máte nainstalovaný BMad Method. Navíc, pokud používáte různé moduly, které rozšířily BMad Method nebo přidaly další komplementární moduly — `bmad-help` se vyvíjí a zná vše, co je dostupné, aby vám dal nejlepší radu v daném okamžiku.
Důležitá poznámka: Každý workflow níže lze spustit přímo vaším nástrojem přes skill nebo načtením agenta a použitím záznamu z nabídky agenta.
<iframe src="/workflow-map-diagram.html" title="Diagram mapy workflow BMad Method" width="100%" height="100%" style="border-radius: 8px; border: 1px solid #334155; min-height: 900px;"></iframe>
<p style="font-size: 0.8rem; text-align: right; margin-top: -0.5rem; margin-bottom: 1rem;">
<a href="/workflow-map-diagram.html" target="_blank" rel="noopener noreferrer">Otevřít diagram v novém panelu ↗</a>
</p>
## Fáze 1: Analýza (volitelná)
Prozkoumejte problémový prostor a validujte nápady před závazkem k plánování.
| Workflow | Účel | Produkuje |
| ------------------------------- | -------------------------------------------------------------------------- | ------------------------- |
| `bmad-brainstorming` | Brainstorming nápadů na projekt s řízenou facilitací brainstormingového kouče | `brainstorming-report.md` |
| `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | Validace tržních, technických nebo doménových předpokladů | Výzkumné nálezy |
| `bmad-create-product-brief` | Zachycení strategické vize | `product-brief.md` |
## Fáze 2: Plánování
Definujte, co budovat a pro koho.
| Workflow | Účel | Produkuje |
| --------------------------- | ---------------------------------------- | ------------ |
| `bmad-create-prd` | Definice požadavků (FR/NFR) | `PRD.md` |
| `bmad-create-ux-design` | Návrh uživatelského zážitku (když záleží na UX) | `ux-spec.md` |
## Fáze 3: Solutioning
Rozhodněte, jak to budovat, a rozložte práci na stories.
| Workflow | Účel | Produkuje |
| ----------------------------------------- | ------------------------------------------ | --------------------------- |
| `bmad-create-architecture` | Explicitní technická rozhodnutí | `architecture.md` s ADR |
| `bmad-create-epics-and-stories` | Rozložení požadavků na implementovatelnou práci | Soubory epiců se stories |
| `bmad-check-implementation-readiness` | Kontrola brány před implementací | Rozhodnutí PASS/CONCERNS/FAIL |
## Fáze 4: Implementace
Budujte to, jednu story po druhé. Brzy plná automatizace fáze 4!
| Workflow | Účel | Produkuje |
| -------------------------- | ------------------------------------------------------------------------ | -------------------------------- |
| `bmad-sprint-planning` | Inicializace sledování (jednou na projekt pro sekvencování dev cyklu) | `sprint-status.yaml` |
| `bmad-create-story` | Příprava další story pro implementaci | `story-[slug].md` |
| `bmad-dev-story` | Implementace story | Fungující kód + testy |
| `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í |
| `bmad-sprint-status` | Sledování průběhu sprintu a stavu stories | Aktualizace stavu sprintu |
| `bmad-retrospective` | Revize po dokončení epicu | Poučení |
## Quick Flow (paralelní cesta)
Přeskočte fáze 1–3 pro malou, dobře pochopenou práci.
| Workflow | Účel | Produkuje |
| ------------------ | --------------------------------------------------------------------------- | -------------------- |
| `bmad-quick-dev` | Sjednocený quick flow — vyjasněte záměr, plánujte, implementujte, revidujte a prezentujte | `spec-*.md` + kód |
## Správa kontextu
Každý dokument se stává kontextem pro další fázi. PRD říká architektovi, jaká omezení záleží. Architektura říká dev agentovi, jaké vzory následovat. Soubory stories poskytují zaměřený, kompletní kontext pro implementaci. Bez této struktury agenti dělají nekonzistentní rozhodnutí.
### Kontext projektu
:::tip[Doporučeno]
Vytvořte `project-context.md` pro zajištění toho, aby AI agenti dodržovali pravidla a preference vašeho projektu. Tento soubor funguje jako ústava vašeho projektu — vede implementační rozhodnutí napříč všemi workflow. Tento volitelný soubor lze vygenerovat na konci tvorby architektury, nebo u existujícího projektu ho lze také vygenerovat pro zachycení toho, co je důležité pro zachování souladu se současnými konvencemi.
:::
**Jak ho vytvořit:**
- **Ručně** — Vytvořte `_bmad-output/project-context.md` s vaším technologickým stackem a pravidly implementace
- **Vygenerujte ho** — Spusťte `bmad-generate-project-context` pro automatické generování z vaší architektury nebo kódové báze
[**Zjistit více o project-context.md**](../explanation/project-context.md)

136
docs/cs/roadmap.mdx Normal file
View File

@ -0,0 +1,136 @@
---
title: Plán rozvoje
description: Co chystáme pro BMad – funkce, vylepšení a komunitní příspěvky
---
# Metoda BMad: Veřejný plán rozvoje
Metoda BMad, modul BMad Method (BMM) a BMad Builder (BMB) se neustále vyvíjejí. Zde je přehled toho, na čem pracujeme a co přijde dál.
<div class="roadmap-container">
<h2 class="roadmap-section-title">Probíhá</h2>
<div class="roadmap-future">
<div class="roadmap-future-card">
<span class="roadmap-emoji">🧩</span>
<h4>Univerzální architektura Skills</h4>
<p>Jeden skill, jakákoli platforma. Napište jednou, spusťte kdekoli.</p>
</div>
<div class="roadmap-future-card">
<span class="roadmap-emoji">🏗️</span>
<h4>BMad Builder v1</h4>
<p>Vytvářejte produkční AI agenty a pracovní postupy s vestavěnými eval testy, týmy a elegantní degradací.</p>
</div>
<div class="roadmap-future-card">
<span class="roadmap-emoji">🧠</span>
<h4>Systém kontextu projektu</h4>
<p>Vaše AI skutečně rozumí vašemu projektu. Kontextový systém reagující na framework, který se vyvíjí s vaším kódem.</p>
</div>
<div class="roadmap-future-card">
<span class="roadmap-emoji">📦</span>
<h4>Centralizované Skills</h4>
<p>Nainstalujte jednou, používejte všude. Sdílejte skills mezi projekty bez zbytečných souborů.</p>
</div>
<div class="roadmap-future-card">
<span class="roadmap-emoji">🔄</span>
<h4>Adaptivní Skills</h4>
<p>Skills, které znají váš nástroj. Optimalizované varianty pro Claude, Codex, Kimi, OpenCode a mnoho dalších.</p>
</div>
<div class="roadmap-future-card">
<span class="roadmap-emoji">📝</span>
<h4>Blog BMad Team Pros</h4>
<p>Návody, články a postřehy od týmu. Brzy spouštíme.</p>
</div>
</div>
<h2 class="roadmap-section-title">Na startu</h2>
<div class="roadmap-future">
<div class="roadmap-future-card">
<span class="roadmap-emoji">🏪</span>
<h4>Skill Marketplace</h4>
<p>Objevujte, instalujte a aktualizujte komunitní skills. Jeden curl příkaz od superschopností.</p>
</div>
<div class="roadmap-future-card">
<span class="roadmap-emoji">🎨</span>
<h4>Přizpůsobení pracovních postupů</h4>
<p>Přizpůsobte si to. Integrujte Jira, Linear, vlastní výstupy — váš workflow, vaše pravidla.</p>
</div>
<div class="roadmap-future-card">
<span class="roadmap-emoji">🚀</span>
<h4>Optimalizace fází 1–3</h4>
<p>Bleskurychlé plánování s kontextovým sběrem sub-agentů. Režim YOLO kombinovaný s řízenou kvalitou.</p>
</div>
<div class="roadmap-future-card">
<span class="roadmap-emoji">🌐</span>
<h4>Připraveno pro podniky</h4>
<p>SSO, auditní logy, týmové pracovní prostory. Všechny ty nudné věci, díky kterým firmy řeknou ano.</p>
</div>
<div class="roadmap-future-card">
<span class="roadmap-emoji">💎</span>
<h4>Exploze komunitních modulů</h4>
<p>Zábava, bezpečnost, terapie, roleplay a mnohem víc. Rozšiřte platformu BMad Method.</p>
</div>
<div class="roadmap-future-card">
<span class="roadmap-emoji">⚡</span>
<h4>Automatizace Dev Loop</h4>
<p>Volitelný autopilot pro vývoj. Nechte AI řídit tok práce a přitom udržujte vysokou kvalitu.</p>
</div>
</div>
<h2 class="roadmap-section-title">Komunita a tým</h2>
<div class="roadmap-future">
<div class="roadmap-future-card">
<span class="roadmap-emoji">🎙️</span>
<h4>Podcast metody BMad</h4>
<p>Rozhovory o AI-nativním vývoji. Spouštíme 1. března 2026!</p>
</div>
<div class="roadmap-future-card">
<span class="roadmap-emoji">🎓</span>
<h4>Master Class metody BMad</h4>
<p>Od uživatele k expertovi. Hluboké ponory do každé fáze, každého workflow, každého tajemství.</p>
</div>
<div class="roadmap-future-card">
<span class="roadmap-emoji">🏗️</span>
<h4>Master Class BMad Builder</h4>
<p>Vytvářejte vlastní agenty. Pokročilé techniky pro chvíle, kdy jste připraveni tvořit, ne jen používat.</p>
</div>
<div class="roadmap-future-card">
<span class="roadmap-emoji">⚡</span>
<h4>BMad Prototype First</h4>
<p>Od nápadu k fungujícímu prototypu v jedné relaci. Vytvořte svou vysněnou aplikaci jako umělecké dílo.</p>
</div>
<div class="roadmap-future-card">
<span class="roadmap-emoji">🌴</span>
<h4>BMad BALM!</h4>
<p>Správa života pro AI-nativní uživatele. Úkoly, návyky, cíle — váš AI kopilot pro všechno.</p>
</div>
<div class="roadmap-future-card">
<span class="roadmap-emoji">🖥️</span>
<h4>Oficiální UI</h4>
<p>Krásné rozhraní pro celý ekosystém BMad. Síla CLI, lesk GUI.</p>
</div>
<div class="roadmap-future-card">
<span class="roadmap-emoji">🔒</span>
<h4>BMad in a Box</h4>
<p>Self-hosted, bez připojení, podnikové kvality. Váš AI asistent, vaše infrastruktura, vaše kontrola.</p>
</div>
</div>
<div style="text-align: center; margin-top: 3rem; padding: 2rem; background: var(--color-bg-card); border-radius: 12px; border: 1px solid var(--color-border);">
<h3 style="margin: 0 0 1rem;">Chcete přispět?</h3>
<p style="color: var(--slate-color-400); margin: 0;">
Toto je pouze částečný seznam toho, co je plánováno. Open source tým BMad vítá přispěvatele!{" "}<br />
<a href="https://github.com/bmad-code-org/BMAD-METHOD" style="color: var(--color-in-progress);">Přidejte se k nám na GitHubu</a> a pomozte formovat budoucnost vývoje řízeného AI.
</p>
<p style="color: var(--slate-color-400); margin: 1.5rem 0 0;">
Líbí se vám, co budujeme? Oceníme jak jednorázovou, tak měsíční{" "}<a href="https://buymeacoffee.com/bmad" style="color: var(--color-in-progress);">podporu</a>.
</p>
<p style="color: var(--slate-color-400); margin: 1rem 0 0;">
Pro firemní sponzoring, partnerské dotazy, přednášky, školení nebo mediální dotazy:{" "}
<a href="mailto:contact@bmadcode.com" style="color: var(--color-in-progress);">contact@bmadcode.com</a>
</p>
</div>
</div>

View File

@ -0,0 +1,275 @@
---
title: "Začínáme"
description: Nainstalujte BMad a vytvořte svůj první projekt
---
Vytvářejte software rychleji pomocí pracovních postupů řízených AI se specializovanými agenty, kteří vás provedou plánováním, architekturou a implementací.
## Co se naučíte
- Nainstalovat a inicializovat BMad Method pro nový projekt
- Používat **BMad-Help** — vašeho inteligentního průvodce, který ví, co dělat dál
- Vybrat správnou plánovací cestu pro velikost vašeho projektu
- Postupovat fázemi od požadavků k fungujícímu kódu
- Efektivně používat agenty a pracovní postupy
:::note[Předpoklady]
- **Node.js 20+** — Vyžadováno pro instalátor
- **Git** — Doporučeno pro správu verzí
- **AI-powered IDE** — Claude Code, Cursor nebo podobné
- **Nápad na projekt** — I jednoduchý stačí pro učení
:::
:::tip[Nejsnadnější cesta]
**Instalace** → `npx bmad-method install`
**Zeptejte se** → `bmad-help what should I do first?`
**Tvořte** → Nechte BMad-Help vás provést workflow po workflow
:::
## Seznamte se s BMad-Help: Váš inteligentní průvodce
**BMad-Help je nejrychlejší způsob, jak začít s BMad.** Nemusíte si pamatovat workflow nebo fáze — prostě se zeptejte a BMad-Help:
- **Prozkoumá váš projekt** a zjistí, co už bylo uděláno
- **Ukáže vaše možnosti** na základě nainstalovaných modulů
- **Doporučí, co dál** — včetně prvního povinného úkolu
- **Odpoví na otázky** jako „Mám nápad na SaaS, kde začít?“
### Jak používat BMad-Help
Spusťte ho ve vašem AI IDE vyvoláním skillu:
```
bmad-help
```
Nebo ho spojte s otázkou pro kontextové poradenství:
```
bmad-help I have an idea for a SaaS product, I already know all the features I want. where do I get started?
```
BMad-Help odpoví s:
- Co je doporučeno pro vaši situaci
- Jaký je první povinný úkol
- Jak vypadá zbytek procesu
### Řídí i pracovní postupy
BMad-Help nejen odpovídá na otázky — **automaticky se spouští na konci každého workflow** a řekne vám přesně, co dělat dál. Žádné hádání, žádné prohledávání dokumentace — jen jasné pokyny k dalšímu povinnému workflow.
:::tip[Začněte zde]
Po instalaci BMad okamžitě vyvolejte skill `bmad-help`. Detekuje, jaké moduly máte nainstalované, a navede vás ke správnému výchozímu bodu pro váš projekt.
:::
## Pochopení BMad
BMad vám pomáhá vytvářet software prostřednictvím řízených pracovních postupů se specializovanými AI agenty. Proces probíhá ve čtyřech fázích:
| Fáze | Název | Co se děje |
| ---- | -------------- | ------------------------------------------------------- |
| 1 | Analýza | Brainstorming, průzkum, product brief *(volitelné)* |
| 2 | Plánování | Vytvoření požadavků (PRD nebo specifikace) |
| 3 | Solutioning | Návrh architektury *(pouze BMad Method/Enterprise)* |
| 4 | Implementace | Budování epic po epicu, story po story |
**[Otevřete Mapu pracovních postupů](../reference/workflow-map.md)** pro prozkoumání fází, workflow a správy kontextu.
Na základě složitosti vašeho projektu nabízí BMad tři plánovací cesty:
| Cesta | Nejlepší pro | Vytvořené dokumenty |
| --------------- | -------------------------------------------------------------- | -------------------------------------- |
| **Quick Flow** | Opravy chyb, jednoduché funkce, jasný rozsah (1–15 stories) | Pouze tech-spec |
| **BMad Method** | Produkty, platformy, složité funkce (10–50+ stories) | PRD + architektura + UX |
| **Enterprise** | Compliance, multi-tenant systémy (30+ stories) | PRD + architektura + bezpečnost + DevOps |
:::note
Počty stories jsou orientační, ne definitivní. Vyberte si cestu podle potřeb plánování, ne podle počtu stories.
:::
## Instalace
Otevřete terminál v adresáři vašeho projektu a spusťte:
```bash
npx bmad-method install
```
Pokud chcete nejnovější prereleaseový build místo výchozího release kanálu, použijte `npx bmad-method@next install`.
Při výzvě k výběru modulů zvolte **BMad Method**.
Instalátor vytvoří dvě složky:
- `_bmad/` — agenti, workflow, úkoly a konfigurace
- `_bmad-output/` — prozatím prázdná, ale zde se budou ukládat vaše artefakty
:::tip[Váš další krok]
Otevřete vaše AI IDE ve složce projektu a spusťte:
```
bmad-help
```
BMad-Help detekuje, co jste dokončili, a doporučí přesně, co dělat dál. Můžete mu také klást otázky jako „Jaké mám možnosti?“ nebo „Mám nápad na SaaS, kde začít?“
:::
:::note[Jak načítat agenty a spouštět workflow]
Každý workflow má **skill**, který vyvoláte jménem ve vašem IDE (např. `bmad-create-prd`). Váš AI nástroj rozpozná název `bmad-*` a spustí ho — nemusíte načítat agenty zvlášť. Můžete také vyvolat agentní skill přímo pro obecnou konverzaci (např. `bmad-agent-pm` pro PM agenta).
:::
:::caution[Nové chaty]
Vždy začněte nový chat pro každý workflow. Tím předejdete problémům s kontextovými omezeními.
:::
## Krok 1: Vytvořte svůj plán
Projděte fázemi 1–3. **Pro každý workflow používejte nové chaty.**
:::tip[Kontext projektu (volitelné)]
Před začátkem zvažte vytvoření `project-context.md` pro dokumentaci vašich technických preferencí a pravidel implementace. Tím zajistíte, že všichni AI agenti budou dodržovat vaše konvence v průběhu celého projektu.
Vytvořte ho ručně na `_bmad-output/project-context.md` nebo ho vygenerujte po architektuře pomocí `bmad-generate-project-context`. [Zjistit více](../explanation/project-context.md).
:::
### Fáze 1: Analýza (volitelná)
Všechny workflow v této fázi jsou volitelné:
- **brainstorming** (`bmad-brainstorming`) — Řízená ideace
- **průzkum** (`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`) — Tržní, doménový a technický průzkum
- **vytvoření product brief** (`bmad-create-product-brief`) — Doporučený základní dokument
### Fáze 2: Plánování (povinná)
**Pro BMad Method a Enterprise cesty:**
1. Vyvolejte **PM agenta** (`bmad-agent-pm`) v novém chatu
2. Spusťte workflow `bmad-create-prd` (`bmad-create-prd`)
3. Výstup: `PRD.md`
**Pro Quick Flow cestu:**
- Spusťte `bmad-quick-dev` — zvládne plánování i implementaci v jednom workflow, přeskočte k implementaci
:::note[UX Design (volitelné)]
Pokud má váš projekt uživatelské rozhraní, vyvolejte **UX-Designer agenta** (`bmad-agent-ux-designer`) a spusťte UX design workflow (`bmad-create-ux-design`) po vytvoření PRD.
:::
### Fáze 3: Solutioning (BMad Method/Enterprise)
**Vytvoření architektury**
1. Vyvolejte **Architect agenta** (`bmad-agent-architect`) v novém chatu
2. Spusťte `bmad-create-architecture` (`bmad-create-architecture`)
3. Výstup: Dokument architektury s technickými rozhodnutími
**Vytvoření epiců a stories**
:::tip[Vylepšení ve V6]
Epicy a stories se nyní vytvářejí *po* architektuře. Tím vznikají kvalitnější stories, protože architektonická rozhodnutí (databáze, API vzory, tech stack) přímo ovlivňují rozklad práce.
:::
1. Vyvolejte **PM agenta** (`bmad-agent-pm`) v novém chatu
2. Spusťte `bmad-create-epics-and-stories` (`bmad-create-epics-and-stories`)
3. Workflow využívá jak PRD, tak architekturu k vytvoření technicky informovaných stories
**Kontrola připravenosti k implementaci** *(vysoce doporučeno)*
1. Vyvolejte **Architect agenta** (`bmad-agent-architect`) v novém chatu
2. Spusťte `bmad-check-implementation-readiness` (`bmad-check-implementation-readiness`)
3. Validuje soudržnost všech plánovacích dokumentů
## Krok 2: Sestavte svůj projekt
Jakmile je plánování dokončeno, přejděte k implementaci. **Každý workflow by měl běžet v novém chatu.**
### Inicializace plánování sprintu
Vyvolejte **SM agenta** (`bmad-agent-sm`) a spusťte `bmad-sprint-planning` (`bmad-sprint-planning`). Tím se vytvoří `sprint-status.yaml` pro sledování všech epiců a stories.
### Cyklus vývoje
Pro každou story opakujte tento cyklus s novými chaty:
| Krok | Agent | Workflow | Příkaz | Účel |
| ---- | ----- | -------------------- | -------------------------- | ---------------------------------- |
| 1 | SM | `bmad-create-story` | `bmad-create-story` | Vytvoření story souboru z epicu |
| 2 | DEV | `bmad-dev-story` | `bmad-dev-story` | Implementace story |
| 3 | DEV | `bmad-code-review` | `bmad-code-review` | Validace kvality *(doporučeno)* |
Po dokončení všech stories v epicu vyvolejte **SM agenta** (`bmad-agent-sm`) a spusťte `bmad-retrospective` (`bmad-retrospective`).
## Co jste dosáhli
Naučili jste se základy budování s BMad:
- Nainstalovali BMad a nakonfigurovali ho pro vaše IDE
- Inicializovali projekt s vybranou plánovací cestou
- Vytvořili plánovací dokumenty (PRD, architektura, epicy a stories)
- Pochopili cyklus vývoje pro implementaci
Váš projekt nyní obsahuje:
```text
váš-projekt/
├── _bmad/ # Konfigurace BMad
├── _bmad-output/
│ ├── planning-artifacts/
│ │ ├── PRD.md # Váš dokument požadavků
│ │ ├── architecture.md # Technická rozhodnutí
│ │ └── epics/ # Soubory epiců a stories
│ ├── implementation-artifacts/
│ │ └── sprint-status.yaml # Sledování sprintu
│ └── project-context.md # Pravidla implementace (volitelné)
└── ...
```
## Rychlý přehled
| Workflow | Příkaz | Agent | Účel |
| ------------------------------------- | ------------------------------------------ | --------- | ----------------------------------------------- |
| **`bmad-help`** ⭐ | `bmad-help` | Jakýkoli | **Váš inteligentní průvodce — ptejte se na cokoli!** |
| `bmad-create-prd` | `bmad-create-prd` | PM | Vytvoření dokumentu požadavků (PRD) |
| `bmad-create-architecture` | `bmad-create-architecture` | Architect | Vytvoření dokumentu architektury |
| `bmad-generate-project-context` | `bmad-generate-project-context` | Analyst | Vytvoření souboru kontextu projektu |
| `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` | SM | Inicializace sledování sprintu |
| `bmad-create-story` | `bmad-create-story` | SM | Vytvoření souboru story |
| `bmad-dev-story` | `bmad-dev-story` | DEV | Implementace story |
| `bmad-code-review` | `bmad-code-review` | DEV | Revize implementovaného kódu |
## Časté otázky
**Potřebuji vždy architekturu?**
Pouze pro BMad Method a Enterprise cesty. Quick Flow přeskakuje ze specifikace rovnou k implementaci.
**Mohu později změnit svůj plán?**
Ano. SM agent má workflow `bmad-correct-course` (`bmad-correct-course`) pro řešení změn rozsahu.
**Co když chci nejdřív brainstormovat?**
Vyvolejte Analyst agenta (`bmad-agent-analyst`) a spusťte `bmad-brainstorming` (`bmad-brainstorming`) před zahájením PRD.
**Musím dodržovat striktní pořadí?**
Ne striktně. Jakmile se naučíte postup, můžete spouštět workflow přímo pomocí Rychlého přehledu výše.
## Získání pomoci
:::tip[První zastávka: BMad-Help]
**Vyvolejte `bmad-help` kdykoli** — je to nejrychlejší způsob, jak se odpoutat. Zeptejte se na cokoli:
- „Co mám dělat po instalaci?“
- „Zasekl jsem se na workflow X“
- „Jaké mám možnosti pro Y?“
- „Ukaž mi, co bylo dosud uděláno“
BMad-Help prozkoumá váš projekt, detekuje, co jste dokončili, a řekne vám přesně, co dělat dál.
:::
- **Během workflow** — Agenti vás provázejí otázkami a vysvětleními
- **Komunita** — [Discord](https://discord.gg/gk8jAdXWmj) (#bmad-method-help, #report-bugs-and-issues)
## Klíčové poznatky
:::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
- **Cesta záleží** — Quick Flow používá `bmad-quick-dev`; Method/Enterprise vyžadují PRD a architekturu
- **BMad-Help se spouští automaticky** — Každý workflow končí pokyny, co dělat dál
:::
Jste připraveni začít? Nainstalujte BMad, vyvolejte `bmad-help` a nechte svého inteligentního průvodce ukázat cestu.

View File

@ -0,0 +1,70 @@
---
title: "Analysis Phase: From Idea to Foundation"
description: What brainstorming, research, product briefs, and PRFAQs are — and when to use each
sidebar:
order: 1
---
The Analysis phase (Phase 1) helps you think clearly about your product before committing to building it. Every tool in this phase is optional, but skipping analysis entirely means your PRD is built on assumptions instead of insight.
## Why Analysis Before Planning?
A PRD answers "what should we build and why?" If you feed it vague thinking, you get a vague PRD — and every downstream document inherits that vagueness. Architecture built on a weak PRD makes wrong technical bets. Stories derived from weak architecture miss edge cases. The cost compounds.
Analysis tools exist to make your PRD sharp. They attack the problem from different angles — creative exploration, market reality, customer clarity, feasibility — so that by the time you sit down with the PM agent, you know what you're building and for whom.
## The Tools
### Brainstorming
**What it is.** A facilitated creative session using proven ideation techniques. The AI acts as coach, pulling ideas out of you through structured exercises — not generating ideas for you.
**Why it's here.** Raw ideas need space to develop before they get locked into requirements. Brainstorming creates that space. It's especially valuable when you have a problem domain but no clear solution, or when you want to explore multiple directions before committing.
**When to use it.** You have a vague sense of what you want to build but haven't crystallized the concept. Or you have a concept but want to pressure-test it against alternatives.
See [Brainstorming](./brainstorming.md) for a deeper look at how sessions work.
### Research (Market, Domain, Technical)
**What it is.** Three focused research workflows that investigate different dimensions of your idea. Market research examines competitors, trends, and user sentiment. Domain research builds subject-matter expertise and terminology. Technical research evaluates feasibility, architecture options, and implementation approaches.
**Why it's here.** Building on assumptions is the fastest way to build something nobody needs. Research grounds your concept in reality — what competitors already exist, what users actually struggle with, what's technically feasible, and what industry-specific constraints you'll face.
**When to use it.** You're entering an unfamiliar domain, you suspect competitors exist but haven't mapped them, or your concept depends on technical capabilities you haven't validated. Run one, two, or all three — each stands alone.
### Product Brief
**What it is.** A guided discovery session that produces a 1-2 page executive summary of your product concept. The AI acts as a collaborative Business Analyst, helping you articulate the vision, target audience, value proposition, and scope.
**Why it's here.** The product brief is the gentler path into planning. It captures your strategic vision in a structured format that feeds directly into PRD creation. It works best when you already have conviction about your concept — you know the customer, the problem, and roughly what you want to build. The brief organizes and sharpens that thinking.
**When to use it.** Your concept is relatively clear and you want to document it efficiently before creating a PRD. You're confident in the direction and don't need your assumptions aggressively challenged.
### PRFAQ (Working Backwards)
**What it is.** Amazon's Working Backwards methodology adapted as an interactive challenge. You write the press release announcing your finished product before a single line of code exists, then answer the hardest questions customers and stakeholders would ask. The AI acts as a relentless but constructive product coach.
**Why it's here.** The PRFAQ is the rigorous path into planning. It forces customer-first clarity by making you defend every claim. If you can't write a compelling press release, the product isn't ready. If customer FAQ answers reveal gaps, those are gaps you'd discover much later — and more expensively — during implementation. The gauntlet surfaces weak thinking early, when it's cheapest to fix.
**When to use it.** You want your concept stress-tested before committing resources. You're unsure whether users will actually care. You want to validate that you can articulate a clear, defensible value proposition. Or you simply want the discipline of Working Backwards to sharpen your thinking.
## Which Should I Use?
| Situation | Recommended tool |
| --------- | ---------------- |
| "I have a vague idea, not sure where to start" | Brainstorming |
| "I need to understand the market before deciding" | Research |
| "I know what I want to build, just need to document it" | Product Brief |
| "I want to make sure this idea is actually worth building" | PRFAQ |
| "I want to explore, then validate, then document" | Brainstorming → Research → PRFAQ or Brief |
Product Brief and PRFAQ both produce input for the PRD — choose one based on how much challenge you want. The brief is collaborative discovery. The PRFAQ is a gauntlet. Both get you to the same destination; the PRFAQ tests whether your concept deserves to get there.
:::tip[Not Sure?]
Run `bmad-help` and describe your situation. It will recommend the right starting point based on what you've already done and what you're trying to accomplish.
:::
## What Happens After Analysis?
Analysis outputs feed directly into Phase 2 (Planning). The PRD workflow accepts product briefs, PRFAQ documents, research findings, and brainstorming reports as input — it synthesizes whatever you've produced into structured requirements. The more analysis you do, the sharper your PRD.

View File

@ -17,7 +17,7 @@ This page lists the default BMM (Agile suite) agents that install with BMad Meth
| Agent | Skill ID | Triggers | Primary workflows |
| --------------------------- | -------------------- | ---------------------------------- | --------------------------------------------------------------------------------------------------- |
| Analyst (Mary) | `bmad-analyst` | `BP`, `RS`, `CB`, `DP` | Brainstorm Project, Research, Create Brief, Document Project |
| Analyst (Mary) | `bmad-analyst` | `BP`, `RS`, `CB`, `WB`, `DP` | Brainstorm Project, 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 |
| Scrum Master (Bob) | `bmad-sm` | `SP`, `CS`, `ER`, `CC` | Sprint Planning, Create Story, Epic Retrospective, Correct Course |

View File

@ -92,6 +92,8 @@ Workflow skills run a structured, multi-step process without loading an agent pe
| Example skill | Purpose |
| --- | --- |
| `bmad-product-brief` | Create a product brief — guided discovery when your concept is clear |
| `bmad-prfaq` | Working Backwards PRFAQ challenge to stress-test your product concept |
| `bmad-create-prd` | Create a Product Requirements Document |
| `bmad-create-architecture` | Design system architecture |
| `bmad-create-epics-and-stories` | Create epics and stories |

View File

@ -21,13 +21,14 @@ Final important note: Every workflow below can be run directly with your tool of
## Phase 1: Analysis (Optional)
Explore the problem space and validate ideas before committing to planning.
Explore the problem space and validate ideas before committing to planning. [**Learn what each tool does and when to use it**](../explanation/analysis-phase.md).
| Workflow | Purpose | Produces |
| ------------------------------- | -------------------------------------------------------------------------- | ------------------------- |
| `bmad-brainstorming` | Brainstorm Project Ideas with guided facilitation of a brainstorming coach | `brainstorming-report.md` |
| `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | Validate market, technical, or domain assumptions | Research findings |
| `bmad-create-product-brief` | Capture strategic vision | `product-brief.md` |
| `bmad-product-brief` | Capture strategic vision — best when your concept is clear | `product-brief.md` |
| `bmad-prfaq` | Working Backwards — stress-test and forge your product concept | `prfaq-{project}.md` |
## Phase 2: Planning

View File

@ -68,7 +68,7 @@ BMad helps you build software through guided workflows with specialized AI agent
| Phase | Name | What Happens |
| ----- | -------------- | --------------------------------------------------- |
| 1 | Analysis | Brainstorming, research, product brief *(optional)* |
| 1 | Analysis | Brainstorming, research, product brief or PRFAQ *(optional)* |
| 2 | Planning | Create requirements (PRD or spec) |
| 3 | Solutioning | Design architecture *(BMad Method/Enterprise only)* |
| 4 | Implementation | Build epic by epic, story by story |
@ -133,10 +133,11 @@ Create it manually at `_bmad-output/project-context.md` or generate it after arc
### Phase 1: Analysis (Optional)
All workflows in this phase are optional:
All workflows in this phase are optional. [**Not sure which to use?**](../explanation/analysis-phase.md)
- **brainstorming** (`bmad-brainstorming`) — Guided ideation
- **research** (`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`) — Market, domain, and technical research
- **create-product-brief** (`bmad-create-product-brief`) — Recommended foundation document
- **product-brief** (`bmad-product-brief`) — Recommended foundation document when your concept is clear
- **prfaq** (`bmad-prfaq`) — Working Backwards challenge to stress-test and forge your product concept
### Phase 2: Planning (Required)

View File

@ -97,6 +97,7 @@
"prettier": "^3.7.4",
"prettier-plugin-packagejson": "^2.5.19",
"sharp": "^0.33.5",
"unist-util-visit": "^5.1.0",
"yaml-eslint-parser": "^1.2.3",
"yaml-lint": "^1.7.0"
},

View File

@ -36,14 +36,17 @@ When you are in this persona and the user calls a skill, this persona must carry
| DR | Industry domain deep dive, subject matter expertise and terminology | bmad-domain-research |
| TR | Technical feasibility, architecture options and implementation approaches | bmad-technical-research |
| CB | Create or update product briefs through guided or autonomous discovery | bmad-product-brief-preview |
| WB | Working Backwards PRFAQ challenge — forge and stress-test product concepts | bmad-prfaq |
| DP | Analyze an existing project to produce documentation for human and LLM consumption | bmad-document-project |
## On Activation
1. **Load config via bmad-init skill** — Store all returned vars for use:
- Use `{user_name}` from config for greeting
- Use `{communication_language}` from config for all communications
- Store any other config variables as `{var-name}` and use appropriately
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
2. **Continue with steps below:**
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.

View File

@ -39,10 +39,12 @@ When you are in this persona and the user calls a skill, this persona must carry
## On Activation
1. **Load config via bmad-init skill** — Store all returned vars for use:
- Use `{user_name}` from config for greeting
- Use `{communication_language}` from config for all communications
- Store any other config variables as `{var-name}` and use appropriately
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
2. **Continue with steps below:**
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.

View File

@ -9,16 +9,14 @@
## INITIALIZATION
### Configuration Loading
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- `project_knowledge`
- `user_name`
- `communication_language`
- `document_output_language`
- `user_skill_level`
- `date` as system-generated current datetime
2. **Greet user** as `{user_name}`, speaking in `{communication_language}`.
---

View File

@ -0,0 +1,96 @@
---
name: bmad-prfaq
description: Working Backwards PRFAQ challenge to forge product concepts. Use when the user requests to 'create a PRFAQ', 'work backwards', or 'run the PRFAQ challenge'.
---
# Working Backwards: The PRFAQ Challenge
## Overview
This skill forges product concepts through Amazon's Working Backwards methodology — the PRFAQ (Press Release / Frequently Asked Questions). Act as a relentless but constructive product coach who stress-tests every claim, challenges vague thinking, and refuses to let weak ideas pass unchallenged. The user walks in with an idea. They walk out with a battle-hardened concept — or the honest realization they need to go deeper. Both are wins.
The PRFAQ forces customer-first clarity: write the press release announcing the finished product before building it. If you can't write a compelling press release, the product isn't ready. The customer FAQ validates the value proposition from the outside in. The internal FAQ addresses feasibility, risks, and hard trade-offs.
**This is hardcore mode.** The coaching is direct, the questions are hard, and vague answers get challenged. But when users are stuck, offer concrete suggestions, reframings, and alternatives — tough love, not tough silence. The goal is to strengthen the concept, not to gatekeep it.
**Args:** Accepts `--headless` / `-H` for autonomous first-draft generation from provided context.
**Output:** A complete PRFAQ document + PRD distillate for downstream pipeline consumption.
**Research-grounded.** All competitive, market, and feasibility claims in the output must be verified against current real-world data. Proactively research to fill knowledge gaps — the user deserves a PRFAQ informed by today's landscape, not yesterday's assumptions.
## On Activation
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
2. **Greet user** as `{user_name}`, speaking in `{communication_language}`. Be warm but efficient — dream builder energy.
3. **Resume detection:** Check if `{planning_artifacts}/prfaq-{project_name}.md` already exists. If it does, read only the first 20 lines to extract the frontmatter `stage` field and offer to resume from the next stage. Do not read the full document. If the user confirms, route directly to that stage's reference file.
4. **Mode detection:**
- `--headless` / `-H`: Produce complete first-draft PRFAQ from provided inputs without interaction. Validate the input schema only (customer, problem, stakes, solution concept present and non-vague) — do not read any referenced files or documents yourself. If required fields are missing or too vague, return an error with specific guidance on what's needed. Fan out artifact analyzer and web researcher subagents in parallel (see Contextual Gathering below) to process all referenced materials, then create the output document at `{planning_artifacts}/prfaq-{project_name}.md` using `./assets/prfaq-template.md` and route to `./references/press-release.md`.
- Default: Full interactive coaching — the gauntlet.
**Headless input schema:**
- **Required:** customer (specific persona), problem (concrete), stakes (why it matters), solution (concept)
- **Optional:** competitive context, technical constraints, team/org context, target market, existing research
**Set the tone immediately.** This isn't a warm, exploratory greeting. Frame it as a challenge — the user is about to stress-test their thinking by writing the press release for a finished product before building anything. Convey that surviving this process means the concept is ready, and failing here saves wasted effort. Be direct and energizing.
Then briefly ground the user on what a PRFAQ actually is — Amazon's Working Backwards method where you write the finished-product press release first, then answer the hardest customer and stakeholder questions. The point is forcing clarity before committing resources.
Then proceed to Stage 1 below.
## Stage 1: Ignition
**Goal:** Get the raw concept on the table and immediately establish customer-first thinking. This stage ends when you have enough clarity on the customer, their problem, and the proposed solution to draft a press release headline.
**Customer-first enforcement:**
- If the user leads with a solution ("I want to build X"): redirect to the customer's problem. Don't let them skip the pain.
- If the user leads with a technology ("I want to use AI/blockchain/etc"): challenge harder. Technology is a "how", not a "why" — push them to articulate the human problem. Strip away the buzzword and ask whether anyone still cares.
- If the user leads with a customer problem: dig deeper into specifics — how they cope today, what they've tried, why it hasn't been solved.
When the user gets stuck, offer concrete suggestions based on what they've shared so far. Draft a hypothesis for them to react to rather than repeating the question harder.
**Concept type detection:** Early in the conversation, identify whether this is a commercial product, internal tool, open-source project, or community/nonprofit initiative. Store this as `{concept_type}` — it calibrates FAQ question generation in Stages 3 and 4. Non-commercial concepts don't have "unit economics" or "first 100 customers" — adapt the framing to stakeholder value, adoption paths, and sustainability instead.
**Essentials to capture before progressing:**
- Who is the customer/user? (specific persona, not "everyone")
- What is their problem? (concrete and felt, not abstract)
- Why does this matter to them? (stakes and consequences)
- What's the initial concept for a solution? (even rough)
**Fast-track:** If the user provides all four essentials in their opening message (or via structured input), acknowledge and confirm understanding, then move directly to document creation and Stage 2 without extended discovery.
**Graceful redirect:** If after 2-3 exchanges the user can't articulate a customer or problem, don't force it — suggest the idea may need more exploration first and recommend they invoke the `bmad-brainstorming` skill to develop it further.
**Contextual Gathering:** Once you understand the concept, gather external context before drafting begins.
1. **Ask about inputs:** Ask the user whether they have existing documents, research, brainstorming, or other materials to inform the PRFAQ. Collect paths for subagent scanning — do not read user-provided files yourself; that's the Artifact Analyzer's job.
2. **Fan out subagents in parallel:**
- **Artifact Analyzer** (`./agents/artifact-analyzer.md`) — Scans `{planning_artifacts}` and `{project_knowledge}` for relevant documents, plus any user-provided paths. Receives the product intent summary so it knows what's relevant.
- **Web Researcher** (`./agents/web-researcher.md`) — Searches for competitive landscape, market context, and current industry data relevant to the concept. Receives the product intent summary.
3. **Graceful degradation:** If subagents are unavailable, scan the most relevant 1-2 documents inline and do targeted web searches directly. Never block the workflow.
4. **Merge findings** with what the user shared. Surface anything surprising that enriches or challenges their assumptions before proceeding.
**Create the output document** at `{planning_artifacts}/prfaq-{project_name}.md` using `./assets/prfaq-template.md`. Write the frontmatter (populate `inputs` with any source documents used) and any initial content captured during Ignition. This document is the working artifact — update it progressively through all stages.
**Coaching Notes Capture:** Before moving on, append a `<!-- coaching-notes-stage-1 -->` block to the output document: concept type and rationale, initial assumptions challenged, why this direction over alternatives discussed, key subagent findings that shaped the concept framing, and any user context captured that doesn't fit the PRFAQ itself.
**When you have enough to draft a press release headline**, route to `./references/press-release.md`.
## Stages
| # | Stage | Purpose | Location |
|---|-------|---------|----------|
| 1 | Ignition | Raw concept, enforce customer-first thinking | SKILL.md (above) |
| 2 | The Press Release | Iterative drafting with hard coaching | `./references/press-release.md` |
| 3 | Customer FAQ | Devil's advocate customer questions | `./references/customer-faq.md` |
| 4 | Internal FAQ | Skeptical stakeholder questions | `./references/internal-faq.md` |
| 5 | The Verdict | Synthesis, strength assessment, final output | `./references/verdict.md` |

View File

@ -0,0 +1,60 @@
# Artifact Analyzer
You are a research analyst. Your job is to scan project documents and extract information relevant to a product concept being stress-tested through the PRFAQ process.
## Input
You will receive:
- **Product intent:** A summary of the concept — customer, problem, solution direction
- **Scan paths:** Directories to search for relevant documents (e.g., planning artifacts, project knowledge folders)
- **User-provided paths:** Any specific files the user pointed to
## Process
1. **Scan the provided directories** for documents that could be relevant:
- Brainstorming reports (`*brainstorm*`, `*ideation*`)
- Research documents (`*research*`, `*analysis*`, `*findings*`)
- Project context (`*context*`, `*overview*`, `*background*`)
- Existing briefs or summaries (`*brief*`, `*summary*`)
- Any markdown, text, or structured documents that look relevant
2. **For sharded documents** (a folder with `index.md` and multiple files), read the index first to understand what's there, then read only the relevant parts.
3. **For very large documents** (estimated >50 pages), read the table of contents, executive summary, and section headings first. Read only sections directly relevant to the stated product intent. Note which sections were skimmed vs read fully.
4. **Read all relevant documents in parallel** — issue all Read calls in a single message rather than one at a time. Extract:
- Key insights that relate to the product intent
- Market or competitive information
- User research or persona information
- Technical context or constraints
- Ideas, both accepted and rejected (rejected ideas are valuable — they prevent re-proposing)
- Any metrics, data points, or evidence
5. **Ignore documents that aren't relevant** to the stated product intent. Don't waste tokens on unrelated content.
## Output
Return ONLY the following JSON object. No preamble, no commentary. Keep total response under 1,500 tokens. Maximum 5 bullets per section — prioritize the most impactful findings.
```json
{
"documents_found": [
{"path": "file path", "relevance": "one-line summary"}
],
"key_insights": [
"bullet — grouped by theme, each self-contained"
],
"user_market_context": [
"bullet — users, market, competition found in docs"
],
"technical_context": [
"bullet — platforms, constraints, integrations"
],
"ideas_and_decisions": [
{"idea": "description", "status": "accepted|rejected|open", "rationale": "brief why"}
],
"raw_detail_worth_preserving": [
"bullet — specific details, data points, quotes for the distillate"
]
}
```

View File

@ -0,0 +1,49 @@
# Web Researcher
You are a market research analyst. Your job is to find current, relevant competitive, market, and industry context for a product concept being stress-tested through the PRFAQ process.
## Input
You will receive:
- **Product intent:** A summary of the concept — customer, problem, solution direction, and the domain it operates in
## Process
1. **Identify search angles** based on the product intent:
- Direct competitors (products solving the same problem)
- Adjacent solutions (different approaches to the same pain point)
- Market size and trends for the domain
- Industry news or developments that create opportunity or risk
- User sentiment about existing solutions (what's frustrating people)
2. **Execute 3-5 targeted web searches** — quality over quantity. Search for:
- "[problem domain] solutions comparison"
- "[competitor names] alternatives" (if competitors are known)
- "[industry] market trends [current year]"
- "[target user type] pain points [domain]"
3. **Synthesize findings** — don't just list links. Extract the signal.
## Output
Return ONLY the following JSON object. No preamble, no commentary. Keep total response under 1,000 tokens. Maximum 5 bullets per section.
```json
{
"competitive_landscape": [
{"name": "competitor", "approach": "one-line description", "gaps": "where they fall short"}
],
"market_context": [
"bullet — market size, growth trends, relevant data points"
],
"user_sentiment": [
"bullet — what users say about existing solutions"
],
"timing_and_opportunity": [
"bullet — why now, enabling shifts"
],
"risks_and_considerations": [
"bullet — market risks, competitive threats, regulatory concerns"
]
}
```

View File

@ -0,0 +1,62 @@
---
title: "PRFAQ: {project_name}"
status: "{status}"
created: "{timestamp}"
updated: "{timestamp}"
stage: "{current_stage}"
inputs: []
---
# {Headline}
## {Subheadline — one sentence: who benefits and what changes for them}
**{City, Date}** — {Opening paragraph: announce the product/initiative, state the user's problem, and the key benefit.}
{Problem paragraph: the user's pain today. Specific, concrete, felt. No mention of the solution yet.}
{Solution paragraph: what changes for the user. Benefits, not features. Outcomes, not implementation.}
> "{Leader/founder quote — the vision beyond the feature list.}"
> — {Name, Title/Role}
### How It Works
{The user experience, step by step. Written from THEIR perspective. How they discover it, start using it, and get value from it.}
> "{User quote — what a real person would say after using this. Must sound human, not like marketing copy.}"
> — {Name, Role}
### Getting Started
{Clear, concrete path to first value. How to access, try, adopt, or contribute.}
---
## Customer FAQ
### Q: {Hardest customer question first}
A: {Honest, specific answer}
### Q: {Next question}
A: {Answer}
---
## Internal FAQ
### Q: {Hardest internal question first}
A: {Honest, specific answer}
### Q: {Next question}
A: {Answer}
---
## The Verdict
{Concept strength assessment — what's forged in steel, what needs more heat, what has cracks in the foundation.}

View File

@ -0,0 +1,16 @@
{
"module-code": "bmm",
"capabilities": [
{
"name": "working-backwards",
"menu-code": "WB",
"description": "Produces battle-tested PRFAQ document and optional LLM distillate for PRD input.",
"supports-headless": true,
"phase-name": "1-analysis",
"after": ["brainstorming", "perform-research"],
"before": ["create-prd"],
"is-required": false,
"output-location": "{planning_artifacts}"
}
]
}

View File

@ -0,0 +1,55 @@
**Language:** Use `{communication_language}` for all output.
**Output Language:** Use `{document_output_language}` for documents.
**Output Location:** `{planning_artifacts}`
**Coaching stance:** Be direct, challenge vague thinking, but offer concrete alternatives when the user is stuck — tough love, not tough silence.
**Concept type:** Check `{concept_type}` — calibrate all question framing to match (commercial, internal tool, open-source, community/nonprofit).
# Stage 3: Customer FAQ
**Goal:** Validate the value proposition by asking the hardest questions a real user would ask — and crafting answers that hold up under scrutiny.
## The Devil's Advocate
You are now the customer. Not a friendly early-adopter — a busy, skeptical person who has been burned by promises before. You've read the press release. Now you have questions.
**Generate 6-10 customer FAQ questions** that cover these angles:
- **Skepticism:** "How is this different from [existing solution]?" / "Why should I switch from what I use today?"
- **Trust:** "What happens to my data?" / "What if this shuts down?" / "Who's behind this?"
- **Practical concerns:** "How much does it cost?" / "How long does it take to get started?" / "Does it work with [thing I already use]?"
- **Edge cases:** "What if I need to [uncommon but real scenario]?" / "Does it work for [adjacent use case]?"
- **The hard question they're afraid of:** Every product has one question the team hopes nobody asks. Find it and ask it.
**Don't generate softball questions.** "How do I sign up?" is not a FAQ — it's a CTA. Real customer FAQs are the objections standing between interest and adoption.
**Calibrate to concept type.** For non-commercial concepts (internal tools, open-source, community projects), adapt question framing: replace "cost" with "effort to adopt," replace "competitor switching" with "why change from current workflow," replace "trust/company viability" with "maintenance and sustainability."
## Coaching the Answers
Present the questions and work through answers with the user:
1. **Present all questions at once** — let the user see the full landscape of customer concern.
2. **Work through answers together.** The user drafts (or you draft and they react). For each answer:
- Is it honest? If the answer is "we don't do that yet," say so — and explain the roadmap or alternative.
- Is it specific? "We have enterprise-grade security" is not an answer. What certifications? What encryption? What SLA?
- Would a customer believe it? Marketing language in FAQ answers destroys credibility.
3. **If an answer reveals a real gap in the concept**, name it directly and force a decision: is this a launch blocker, a fast-follow, or an accepted trade-off?
4. **The user can add their own questions too.** Often they know the scary questions better than anyone.
## Headless Mode
Generate questions and best-effort answers from available context. Flag answers with low confidence so a human can review.
## Updating the Document
Append the Customer FAQ section to the output document. Update frontmatter: `status: "customer-faq"`, `stage: 3`, `updated` timestamp.
## Coaching Notes Capture
Before moving on, append a `<!-- coaching-notes-stage-3 -->` block to the output document: gaps revealed by customer questions, trade-off decisions made (launch blocker vs fast-follow vs accepted), competitive intelligence surfaced, and any scope or requirements signals.
## Stage Complete
This stage is complete when every question has an honest, specific answer — and the user has confronted the hardest customer objections their concept faces. No softballs survived.
Route to `./internal-faq.md`.

View File

@ -0,0 +1,51 @@
**Language:** Use `{communication_language}` for all output.
**Output Language:** Use `{document_output_language}` for documents.
**Output Location:** `{planning_artifacts}`
**Coaching stance:** Be direct, challenge vague thinking, but offer concrete alternatives when the user is stuck — tough love, not tough silence.
**Concept type:** Check `{concept_type}` — calibrate all question framing to match (commercial, internal tool, open-source, community/nonprofit).
# Stage 4: Internal FAQ
**Goal:** Stress-test the concept from the builder's side. The customer FAQ asked "should I use this?" The internal FAQ asks "can we actually pull this off — and should we?"
## The Skeptical Stakeholder
You are now the internal stakeholder panel — engineering lead, finance, legal, operations, the CEO who's seen a hundred pitches. The press release was inspiring. Now prove it's real.
**Generate 6-10 internal FAQ questions** that cover these angles:
- **Feasibility:** "What's the hardest technical problem here?" / "What do we not know how to build yet?" / "What are the key dependencies and risks?"
- **Business viability:** "What does the unit economics look like?" / "How do we acquire the first 100 customers?" / "What's the competitive moat — and how durable is it?"
- **Resource reality:** "What does the team need to look like?" / "What's the realistic timeline to a usable product?" / "What do we have to say no to in order to do this?"
- **Risk:** "What kills this?" / "What's the worst-case scenario if we ship and it doesn't work?" / "What regulatory or legal exposure exists?"
- **Strategic fit:** "Why us? Why now?" / "What does this cannibalize?" / "If this succeeds, what does the company look like in 3 years?"
- **The question the founder avoids:** The internal counterpart to the hard customer question. The thing that keeps them up at night but hasn't been said out loud.
**Calibrate questions to context.** A solo founder building an MVP needs different internal questions than a team inside a large organization. Don't ask about "board alignment" for a weekend project. Don't ask about "weekend viability" for an enterprise product. For non-commercial concepts (internal tools, open-source, community projects), replace "unit economics" with "maintenance burden," replace "customer acquisition" with "adoption strategy," and replace "competitive moat" with "sustainability and contributor/stakeholder engagement."
## Coaching the Answers
Same approach as Customer FAQ — draft, challenge, refine:
1. **Present all questions at once.**
2. **Work through answers.** Demand specificity. "We'll figure it out" is not an answer. Neither is "we'll hire for that." What's the actual plan?
3. **Honest unknowns are fine — unexamined unknowns are not.** If the answer is "we don't know yet," the follow-up is: "What would it take to find out, and when do you need to know by?"
4. **Watch for hand-waving on resources and timeline.** These are the most commonly over-optimistic answers. Push for concrete scoping.
## Headless Mode
Generate questions calibrated to context and best-effort answers. Flag high-risk areas and unknowns prominently.
## Updating the Document
Append the Internal FAQ section to the output document. Update frontmatter: `status: "internal-faq"`, `stage: 4`, `updated` timestamp.
## Coaching Notes Capture
Before moving on, append a `<!-- coaching-notes-stage-4 -->` block to the output document: feasibility risks identified, resource/timeline estimates discussed, unknowns flagged with "what would it take to find out" answers, strategic positioning decisions, and any technical constraints or dependencies surfaced.
## Stage Complete
This stage is complete when the internal questions have honest, specific answers — and the user has a clear-eyed view of what it actually takes to execute this concept. Optimism is fine. Delusion is not.
Route to `./verdict.md`.

View File

@ -0,0 +1,60 @@
**Language:** Use `{communication_language}` for all output.
**Output Language:** Use `{document_output_language}` for documents.
**Output Location:** `{planning_artifacts}`
**Coaching stance:** Be direct, challenge vague thinking, but offer concrete alternatives when the user is stuck — tough love, not tough silence.
# Stage 2: The Press Release
**Goal:** Produce a press release that would make a real customer stop scrolling and pay attention. Draft iteratively, challenging every sentence for specificity, customer relevance, and honesty.
**Concept type adaptation:** Check `{concept_type}` (commercial product, internal tool, open-source, community/nonprofit). For non-commercial concepts, adapt press release framing: "announce the initiative" not "announce the product," "How to Participate" not "Getting Started," "Community Member quote" not "Customer quote." The structure stays — the language shifts to match the audience.
## The Forge
The press release is the heart of Working Backwards. It has a specific structure, and each part earns its place by forcing a different type of clarity:
| Section | What It Forces |
|---------|---------------|
| **Headline** | Can you say what this is in one sentence a customer would understand? |
| **Subheadline** | Who benefits and what changes for them? |
| **Opening paragraph** | What are you announcing, who is it for, and why should they care? |
| **Problem paragraph** | Can you make the reader feel the customer's pain without mentioning your solution? |
| **Solution paragraph** | What changes for the customer? (Not: what did you build.) |
| **Leader quote** | What's the vision beyond the feature list? |
| **How It Works** | Can you explain the experience from the customer's perspective? |
| **Customer quote** | Would a real person say this? Does it sound human? |
| **Getting Started** | Is the path to value clear and concrete? |
## Coaching Approach
The coaching dynamic: draft each section yourself first, then model critical thinking by challenging your own draft out loud before inviting the user to sharpen it. Push one level deeper on every response — if the user gives you a generality, demand the specific. The cycle is: draft → self-challenge → invite → deepen.
When the user is stuck, offer 2-3 concrete alternatives to react to rather than repeating the question harder.
## Quality Bars
These are the standards to hold the press release to. Don't enumerate them to the user — embody them in your challenges:
- **No jargon** — If a customer wouldn't use the word, neither should the press release
- **No weasel words** — "significantly", "revolutionary", "best-in-class" are banned. Replace with specifics.
- **The mom test** — Could you explain this to someone outside your industry and have them understand why it matters?
- **The "so what?" test** — Every sentence should survive "so what?" If it can't, cut or sharpen it.
- **Honest framing** — The press release should be compelling without being dishonest. If you're overselling, the customer FAQ will expose it.
## Headless Mode
If running headless: draft the complete press release based on available inputs without interaction. Apply the quality bars internally — challenge yourself and produce the strongest version you can. Write directly to the output document.
## Updating the Document
After each section is refined, append it to the output document at `{planning_artifacts}/prfaq-{project_name}.md`. Update frontmatter: `status: "press-release"`, `stage: 2`, and `updated` timestamp.
## Coaching Notes Capture
Before moving on, append a brief `<!-- coaching-notes-stage-2 -->` block to the output document capturing key contextual observations from this stage: rejected headline framings, competitive positioning discussed, differentiators explored but not used, and any out-of-scope details the user mentioned (technical constraints, timeline, team context). These notes survive context compaction and feed the Stage 5 distillate.
## Stage Complete
This stage is complete when the full press release reads as a coherent, compelling announcement that a real customer would find relevant. The user should feel proud of what they've written — and confident every sentence earned its place.
Route to `./customer-faq.md`.

View File

@ -0,0 +1,79 @@
**Language:** Use `{communication_language}` for all output.
**Output Language:** Use `{document_output_language}` for documents.
**Output Location:** `{planning_artifacts}`
**Coaching stance:** Be direct and honest — the verdict exists to surface truth, not to soften it. But frame every finding constructively.
# Stage 5: The Verdict
**Goal:** Step back from the details and give the user an honest assessment of where their concept stands. Finalize the PRFAQ document and produce the downstream distillate.
## The Assessment
Review the entire PRFAQ — press release, customer FAQ, internal FAQ — and deliver a candid verdict:
**Concept Strength:** Rate the overall concept readiness. Not a score — a narrative assessment. Where is the thinking sharp and where is it still soft? What survived the gauntlet and what barely held together?
**Three categories of findings:**
- **Forged in steel** — aspects of the concept that are clear, compelling, and defensible. The press release sections that would actually make a customer stop. The FAQ answers that are honest and convincing.
- **Needs more heat** — areas that are promising but underdeveloped. The user has a direction but hasn't gone deep enough. These need more work before they're ready for a PRD.
- **Cracks in the foundation** — genuine risks, unresolved contradictions, or gaps that could undermine the whole concept. Not necessarily deal-breakers, but things that must be addressed deliberately.
**Present the verdict directly.** Don't soften it. The whole point of this process is to surface truth before committing resources. But frame findings constructively — for every crack, suggest what it would take to address it.
## Finalize the Document
1. **Polish the PRFAQ** — ensure the press release reads as a cohesive narrative, FAQs flow logically, formatting is consistent
2. **Append The Verdict section** to the output document with the assessment
3. Update frontmatter: `status: "complete"`, `stage: 5`, `updated` timestamp
## Produce the Distillate
Throughout the process, you captured context beyond what fits in the PRFAQ. Source material for the distillate includes the `<!-- coaching-notes-stage-N -->` blocks in the output document (which survive context compaction) as well as anything remaining in session memory — rejected framings, alternative positioning, technical constraints, competitive intelligence, scope signals, resource estimates, open questions.
**Always produce the distillate** at `{planning_artifacts}/prfaq-{project_name}-distillate.md`:
```yaml
---
title: "PRFAQ Distillate: {project_name}"
type: llm-distillate
source: "prfaq-{project_name}.md"
created: "{timestamp}"
purpose: "Token-efficient context for downstream PRD creation"
---
```
**Distillate content:** Dense bullet points grouped by theme. Each bullet stands alone with enough context for a downstream LLM to use it. Include:
- Rejected framings and why they were dropped
- Requirements signals captured during coaching
- Technical context, constraints, and platform preferences
- Competitive intelligence from discussion
- Open questions and unknowns flagged during internal FAQ
- Scope signals — what's in, out, and maybe for MVP
- Resource and timeline estimates discussed
- The Verdict findings (especially "needs more heat" and "cracks") as actionable items
## Present Completion
"Your PRFAQ for {project_name} has survived the gauntlet.
**PRFAQ:** `{planning_artifacts}/prfaq-{project_name}.md`
**Detail Pack:** `{planning_artifacts}/prfaq-{project_name}-distillate.md`
**Recommended next step:** Use the PRFAQ and detail pack as input for PRD creation. The PRFAQ replaces the product brief in your planning pipeline — tell your PM 'create a PRD' and point them to these files."
**Headless mode output:**
```json
{
"status": "complete",
"prfaq": "{planning_artifacts}/prfaq-{project_name}.md",
"distillate": "{planning_artifacts}/prfaq-{project_name}-distillate.md",
"verdict": "forged|needs-heat|cracked",
"key_risks": ["top unresolved items"],
"open_questions": ["unresolved items from FAQs"]
}
```
## Stage Complete
This is the terminal stage. If the user wants to revise, loop back to the relevant stage. Otherwise, the workflow is done.

View File

@ -37,7 +37,7 @@ Check activation context immediately:
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
2. **Greet user** as `{user_name}`, speaking in `{communication_language}`. Be warm but efficient — dream builder energy.
2. **Greet user** as `{user_name}`, speaking in `{communication_language}`.
3. **Stage 1: Understand Intent** (handled here in SKILL.md)
@ -80,8 +80,3 @@ Check activation context immediately:
| 3 | Guided Elicitation | Fill gaps through smart questioning | `prompts/guided-elicitation.md` |
| 4 | Draft & Review | Draft brief, fan out review subagents | `prompts/draft-and-review.md` |
| 5 | Finalize | Polish, output, offer distillate | `prompts/finalize.md` |
## External Skills
This workflow uses:
- `bmad-init` — Configuration loading (module: bmm)

View File

@ -8,7 +8,7 @@
"description": "Produces executive product brief and optional LLM distillate for PRD input.",
"supports-headless": true,
"phase-name": "1-analysis",
"after": ["brainstorming, perform-research"],
"after": ["brainstorming", "perform-research"],
"before": ["create-prd"],
"is-required": true,
"output-location": "{planning_artifacts}"

View File

@ -8,12 +8,14 @@
**⛔ Web search required.** If unavailable, abort and tell the user.
## CONFIGURATION
## Activation
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
- `communication_language`, `document_output_language`, `user_skill_level`
- `date` as a system-generated value
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
## QUICK TOPIC DISCOVERY

View File

@ -8,12 +8,14 @@
**⛔ Web search required.** If unavailable, abort and tell the user.
## CONFIGURATION
## Activation
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
- `communication_language`, `document_output_language`, `user_skill_level`
- `date` as a system-generated value
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
## QUICK TOPIC DISCOVERY

View File

@ -9,12 +9,14 @@
**⛔ Web search required.** If unavailable, abort and tell the user.
## CONFIGURATION
## Activation
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
- `communication_language`, `document_output_language`, `user_skill_level`
- `date` as a system-generated value
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
## QUICK TOPIC DISCOVERY

View File

@ -41,10 +41,12 @@ When you are in this persona and the user calls a skill, this persona must carry
## On Activation
1. **Load config via bmad-init skill** — Store all returned vars for use:
- Use `{user_name}` from config for greeting
- Use `{communication_language}` from config for all communications
- Store any other config variables as `{var-name}` and use appropriately
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
2. **Continue with steps below:**
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.

View File

@ -37,10 +37,12 @@ When you are in this persona and the user calls a skill, this persona must carry
## On Activation
1. **Load config via bmad-init skill** — Store all returned vars for use:
- Use `{user_name}` from config for greeting
- Use `{communication_language}` from config for all communications
- Store any other config variables as `{var-name}` and use appropriately
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
2. **Continue with steps below:**
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.

View File

@ -42,20 +42,19 @@ This uses **step-file architecture** for disciplined execution:
- ⏸️ **ALWAYS** halt at menus and wait for user input
- 📋 **NEVER** create mental todo lists from future steps
## INITIALIZATION SEQUENCE
## Activation
### 1. Configuration Loading
Load and read full config from {main_config} and resolve:
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
- `communication_language`, `document_output_language`, `user_skill_level`
- `date` as system-generated current datetime
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
### 2. Route to Create Workflow
2. Route to Create Workflow
"**Create Mode: Creating a new PRD from scratch.**"

View File

@ -15,15 +15,14 @@ This uses **micro-file architecture** for disciplined execution:
---
## INITIALIZATION
## Activation
### Configuration Loading
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
- `communication_language`, `document_output_language`, `user_skill_level`
- `date` as system-generated current datetime
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
### Paths

View File

@ -1,6 +1,6 @@
---
# File references (ONLY variables used in this step)
prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/create-prd/data/prd-purpose.md'
prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/bmad-create-prd/data/prd-purpose.md'
---
# Step E-1: Discovery & Understanding

View File

@ -1,7 +1,7 @@
---
# File references (ONLY variables used in this step)
prdFile: '{prd_file_path}'
prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/create-prd/data/prd-purpose.md'
prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/bmad-create-prd/data/prd-purpose.md'
---
# Step E-1B: Legacy PRD Conversion Assessment

View File

@ -2,7 +2,7 @@
# File references (ONLY variables used in this step)
prdFile: '{prd_file_path}'
validationReport: '{validation_report_path}' # If provided
prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/create-prd/data/prd-purpose.md'
prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/bmad-create-prd/data/prd-purpose.md'
---
# Step E-2: Deep Review & Analysis

View File

@ -1,7 +1,7 @@
---
# File references (ONLY variables used in this step)
prdFile: '{prd_file_path}'
prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/create-prd/data/prd-purpose.md'
prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/bmad-create-prd/data/prd-purpose.md'
---
# Step E-3: Edit & Update

View File

@ -1,7 +1,7 @@
---
# File references (ONLY variables used in this step)
prdFile: '{prd_file_path}'
validationWorkflow: '{project-root}/_bmad/bmm-skills/2-plan-workflows/create-prd/steps-v/step-v-01-discovery.md'
validationWorkflow: '{project-root}/_bmad/bmm-skills/2-plan-workflows/bmad-validate-prd/steps-v/step-v-01-discovery.md'
---
# Step E-4: Complete & Validate

View File

@ -41,20 +41,19 @@ This uses **step-file architecture** for disciplined execution:
- ⏸️ **ALWAYS** halt at menus and wait for user input
- 📋 **NEVER** create mental todo lists from future steps
## INITIALIZATION SEQUENCE
## Activation
### 1. Configuration Loading
Load and read full config from {main_config} and resolve:
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
- `communication_language`, `document_output_language`, `user_skill_level`
- `date` as system-generated current datetime
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
### 2. Route to Edit Workflow
2. Route to Edit Workflow
"**Edit Mode: Improving an existing PRD.**"

View File

@ -42,20 +42,19 @@ This uses **step-file architecture** for disciplined execution:
- ⏸️ **ALWAYS** halt at menus and wait for user input
- 📋 **NEVER** create mental todo lists from future steps
## INITIALIZATION SEQUENCE
## Activation
### 1. Configuration Loading
Load and read full config from {main_config} and resolve:
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
- `communication_language`, `document_output_language`, `user_skill_level`
- `date` as system-generated current datetime
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
### 2. Route to Validate Workflow
2. Route to Validate Workflow
"**Validate Mode: Validating an existing PRD against BMAD standards.**"

View File

@ -1,15 +0,0 @@
domain,signals,complexity,key_concerns,required_knowledge,suggested_workflow,web_searches,special_sections
healthcare,"medical,diagnostic,clinical,FDA,patient,treatment,HIPAA,therapy,pharma,drug",high,"FDA approval;Clinical validation;HIPAA compliance;Patient safety;Medical device classification;Liability","Regulatory pathways;Clinical trial design;Medical standards;Data privacy;Integration requirements","domain-research","FDA software medical device guidance {date};HIPAA compliance software requirements;Medical software standards {date};Clinical validation software","clinical_requirements;regulatory_pathway;validation_methodology;safety_measures"
fintech,"payment,banking,trading,investment,crypto,wallet,transaction,KYC,AML,funds,fintech",high,"Regional compliance;Security standards;Audit requirements;Fraud prevention;Data protection","KYC/AML requirements;PCI DSS;Open banking;Regional laws (US/EU/APAC);Crypto regulations","domain-research","fintech regulations {date};payment processing compliance {date};open banking API standards;cryptocurrency regulations {date}","compliance_matrix;security_architecture;audit_requirements;fraud_prevention"
govtech,"government,federal,civic,public sector,citizen,municipal,voting",high,"Procurement rules;Security clearance;Accessibility (508);FedRAMP;Privacy;Transparency","Government procurement;Security frameworks;Accessibility standards;Privacy laws;Open data requirements","domain-research","government software procurement {date};FedRAMP compliance requirements;section 508 accessibility;government security standards","procurement_compliance;security_clearance;accessibility_standards;transparency_requirements"
edtech,"education,learning,student,teacher,curriculum,assessment,K-12,university,LMS",medium,"Student privacy (COPPA/FERPA);Accessibility;Content moderation;Age verification;Curriculum standards","Educational privacy laws;Learning standards;Accessibility requirements;Content guidelines;Assessment validity","domain-research","educational software privacy {date};COPPA FERPA compliance;WCAG education requirements;learning management standards","privacy_compliance;content_guidelines;accessibility_features;curriculum_alignment"
aerospace,"aircraft,spacecraft,aviation,drone,satellite,propulsion,flight,radar,navigation",high,"Safety certification;DO-178C compliance;Performance validation;Simulation accuracy;Export controls","Aviation standards;Safety analysis;Simulation validation;ITAR/export controls;Performance requirements","domain-research + technical-model","DO-178C software certification;aerospace simulation standards {date};ITAR export controls software;aviation safety requirements","safety_certification;simulation_validation;performance_requirements;export_compliance"
automotive,"vehicle,car,autonomous,ADAS,automotive,driving,EV,charging",high,"Safety standards;ISO 26262;V2X communication;Real-time requirements;Certification","Automotive standards;Functional safety;V2X protocols;Real-time systems;Testing requirements","domain-research","ISO 26262 automotive software;automotive safety standards {date};V2X communication protocols;EV charging standards","safety_standards;functional_safety;communication_protocols;certification_requirements"
scientific,"research,algorithm,simulation,modeling,computational,analysis,data science,ML,AI",medium,"Reproducibility;Validation methodology;Peer review;Performance;Accuracy;Computational resources","Scientific method;Statistical validity;Computational requirements;Domain expertise;Publication standards","technical-model","scientific computing best practices {date};research reproducibility standards;computational modeling validation;peer review software","validation_methodology;accuracy_metrics;reproducibility_plan;computational_requirements"
legaltech,"legal,law,contract,compliance,litigation,patent,attorney,court",high,"Legal ethics;Bar regulations;Data retention;Attorney-client privilege;Court system integration","Legal practice rules;Ethics requirements;Court filing systems;Document standards;Confidentiality","domain-research","legal technology ethics {date};law practice management software requirements;court filing system standards;attorney client privilege technology","ethics_compliance;data_retention;confidentiality_measures;court_integration"
insuretech,"insurance,claims,underwriting,actuarial,policy,risk,premium",high,"Insurance regulations;Actuarial standards;Data privacy;Fraud detection;State compliance","Insurance regulations by state;Actuarial methods;Risk modeling;Claims processing;Regulatory reporting","domain-research","insurance software regulations {date};actuarial standards software;insurance fraud detection;state insurance compliance","regulatory_requirements;risk_modeling;fraud_detection;reporting_compliance"
energy,"energy,utility,grid,solar,wind,power,electricity,oil,gas",high,"Grid compliance;NERC standards;Environmental regulations;Safety requirements;Real-time operations","Energy regulations;Grid standards;Environmental compliance;Safety protocols;SCADA systems","domain-research","energy sector software compliance {date};NERC CIP standards;smart grid requirements;renewable energy software standards","grid_compliance;safety_protocols;environmental_compliance;operational_requirements"
process_control,"industrial automation,process control,PLC,SCADA,DCS,HMI,operational technology,OT,control system,cyberphysical,MES,historian,instrumentation,I&C,P&ID",high,"Functional safety;OT cybersecurity;Real-time control requirements;Legacy system integration;Process safety and hazard analysis;Environmental compliance and permitting;Engineering authority and PE requirements","Functional safety standards;OT security frameworks;Industrial protocols;Process control architecture;Plant reliability and maintainability","domain-research + technical-model","IEC 62443 OT cybersecurity requirements {date};functional safety software requirements {date};industrial process control architecture;ISA-95 manufacturing integration","functional_safety;ot_security;process_requirements;engineering_authority"
building_automation,"building automation,BAS,BMS,HVAC,smart building,lighting control,fire alarm,fire protection,fire suppression,life safety,elevator,access control,DDC,energy management,sequence of operations,commissioning",high,"Life safety codes;Building energy standards;Multi-trade coordination and interoperability;Commissioning and ongoing operational performance;Indoor environmental quality and occupant comfort;Engineering authority and PE requirements","Building automation protocols;HVAC and mechanical controls;Fire alarm, fire protection, and life safety design;Commissioning process and sequence of operations;Building codes and energy standards","domain-research","smart building software architecture {date};BACnet integration best practices;building automation cybersecurity {date};ASHRAE building standards","life_safety;energy_compliance;commissioning_requirements;engineering_authority"
gaming,"game,player,gameplay,level,character,multiplayer,quest",redirect,"REDIRECT TO GAME WORKFLOWS","Game design","game-brief","NA","NA"
general,"",low,"Standard requirements;Basic security;User experience;Performance","General software practices","continue","software development best practices {date}","standard_requirements"
1 domain signals complexity key_concerns required_knowledge suggested_workflow web_searches special_sections
2 healthcare medical,diagnostic,clinical,FDA,patient,treatment,HIPAA,therapy,pharma,drug high FDA approval;Clinical validation;HIPAA compliance;Patient safety;Medical device classification;Liability Regulatory pathways;Clinical trial design;Medical standards;Data privacy;Integration requirements domain-research FDA software medical device guidance {date};HIPAA compliance software requirements;Medical software standards {date};Clinical validation software clinical_requirements;regulatory_pathway;validation_methodology;safety_measures
3 fintech payment,banking,trading,investment,crypto,wallet,transaction,KYC,AML,funds,fintech high Regional compliance;Security standards;Audit requirements;Fraud prevention;Data protection KYC/AML requirements;PCI DSS;Open banking;Regional laws (US/EU/APAC);Crypto regulations domain-research fintech regulations {date};payment processing compliance {date};open banking API standards;cryptocurrency regulations {date} compliance_matrix;security_architecture;audit_requirements;fraud_prevention
4 govtech government,federal,civic,public sector,citizen,municipal,voting high Procurement rules;Security clearance;Accessibility (508);FedRAMP;Privacy;Transparency Government procurement;Security frameworks;Accessibility standards;Privacy laws;Open data requirements domain-research government software procurement {date};FedRAMP compliance requirements;section 508 accessibility;government security standards procurement_compliance;security_clearance;accessibility_standards;transparency_requirements
5 edtech education,learning,student,teacher,curriculum,assessment,K-12,university,LMS medium Student privacy (COPPA/FERPA);Accessibility;Content moderation;Age verification;Curriculum standards Educational privacy laws;Learning standards;Accessibility requirements;Content guidelines;Assessment validity domain-research educational software privacy {date};COPPA FERPA compliance;WCAG education requirements;learning management standards privacy_compliance;content_guidelines;accessibility_features;curriculum_alignment
6 aerospace aircraft,spacecraft,aviation,drone,satellite,propulsion,flight,radar,navigation high Safety certification;DO-178C compliance;Performance validation;Simulation accuracy;Export controls Aviation standards;Safety analysis;Simulation validation;ITAR/export controls;Performance requirements domain-research + technical-model DO-178C software certification;aerospace simulation standards {date};ITAR export controls software;aviation safety requirements safety_certification;simulation_validation;performance_requirements;export_compliance
7 automotive vehicle,car,autonomous,ADAS,automotive,driving,EV,charging high Safety standards;ISO 26262;V2X communication;Real-time requirements;Certification Automotive standards;Functional safety;V2X protocols;Real-time systems;Testing requirements domain-research ISO 26262 automotive software;automotive safety standards {date};V2X communication protocols;EV charging standards safety_standards;functional_safety;communication_protocols;certification_requirements
8 scientific research,algorithm,simulation,modeling,computational,analysis,data science,ML,AI medium Reproducibility;Validation methodology;Peer review;Performance;Accuracy;Computational resources Scientific method;Statistical validity;Computational requirements;Domain expertise;Publication standards technical-model scientific computing best practices {date};research reproducibility standards;computational modeling validation;peer review software validation_methodology;accuracy_metrics;reproducibility_plan;computational_requirements
9 legaltech legal,law,contract,compliance,litigation,patent,attorney,court high Legal ethics;Bar regulations;Data retention;Attorney-client privilege;Court system integration Legal practice rules;Ethics requirements;Court filing systems;Document standards;Confidentiality domain-research legal technology ethics {date};law practice management software requirements;court filing system standards;attorney client privilege technology ethics_compliance;data_retention;confidentiality_measures;court_integration
10 insuretech insurance,claims,underwriting,actuarial,policy,risk,premium high Insurance regulations;Actuarial standards;Data privacy;Fraud detection;State compliance Insurance regulations by state;Actuarial methods;Risk modeling;Claims processing;Regulatory reporting domain-research insurance software regulations {date};actuarial standards software;insurance fraud detection;state insurance compliance regulatory_requirements;risk_modeling;fraud_detection;reporting_compliance
11 energy energy,utility,grid,solar,wind,power,electricity,oil,gas high Grid compliance;NERC standards;Environmental regulations;Safety requirements;Real-time operations Energy regulations;Grid standards;Environmental compliance;Safety protocols;SCADA systems domain-research energy sector software compliance {date};NERC CIP standards;smart grid requirements;renewable energy software standards grid_compliance;safety_protocols;environmental_compliance;operational_requirements
12 process_control industrial automation,process control,PLC,SCADA,DCS,HMI,operational technology,OT,control system,cyberphysical,MES,historian,instrumentation,I&C,P&ID high Functional safety;OT cybersecurity;Real-time control requirements;Legacy system integration;Process safety and hazard analysis;Environmental compliance and permitting;Engineering authority and PE requirements Functional safety standards;OT security frameworks;Industrial protocols;Process control architecture;Plant reliability and maintainability domain-research + technical-model IEC 62443 OT cybersecurity requirements {date};functional safety software requirements {date};industrial process control architecture;ISA-95 manufacturing integration functional_safety;ot_security;process_requirements;engineering_authority
13 building_automation building automation,BAS,BMS,HVAC,smart building,lighting control,fire alarm,fire protection,fire suppression,life safety,elevator,access control,DDC,energy management,sequence of operations,commissioning high Life safety codes;Building energy standards;Multi-trade coordination and interoperability;Commissioning and ongoing operational performance;Indoor environmental quality and occupant comfort;Engineering authority and PE requirements Building automation protocols;HVAC and mechanical controls;Fire alarm, fire protection, and life safety design;Commissioning process and sequence of operations;Building codes and energy standards domain-research smart building software architecture {date};BACnet integration best practices;building automation cybersecurity {date};ASHRAE building standards life_safety;energy_compliance;commissioning_requirements;engineering_authority
14 gaming game,player,gameplay,level,character,multiplayer,quest redirect REDIRECT TO GAME WORKFLOWS Game design game-brief NA NA
15 general low Standard requirements;Basic security;User experience;Performance General software practices continue software development best practices {date} standard_requirements

View File

@ -1,197 +0,0 @@
# BMAD PRD Purpose
**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.**
---
## What is a BMAD PRD?
A dual-audience document serving:
1. **Human Product Managers and builders** - Vision, strategy, stakeholder communication
2. **LLM Downstream Consumption** - UX Design → Architecture → Epics → Development AI Agents
Each successive document becomes more AI-tailored and granular.
---
## Core Philosophy: Information Density
**High Signal-to-Noise Ratio**
Every sentence must carry information weight. LLMs consume precise, dense content efficiently.
**Anti-Patterns (Eliminate These):**
- ❌ "The system will allow users to..." → ✅ "Users can..."
- ❌ "It is important to note that..." → ✅ State the fact directly
- ❌ "In order to..." → ✅ "To..."
- ❌ Conversational filler and padding → ✅ Direct, concise statements
**Goal:** Maximum information per word. Zero fluff.
---
## The Traceability Chain
**PRD starts the chain:**
```
Vision → Success Criteria → User Journeys → Functional Requirements → (future: User Stories)
```
**In the PRD, establish:**
- Vision → Success Criteria alignment
- Success Criteria → User Journey coverage
- User Journey → Functional Requirement mapping
- All requirements traceable to user needs
**Why:** Each downstream artifact (UX, Architecture, Epics, Stories) must trace back to documented user needs and business objectives. This chain ensures we build the right thing.
---
## What Makes Great Functional Requirements?
### FRs are Capabilities, Not Implementation
**Good FR:** "Users can reset their password via email link"
**Bad FR:** "System sends JWT via email and validates with database" (implementation leakage)
**Good FR:** "Dashboard loads in under 2 seconds for 95th percentile"
**Bad FR:** "Fast loading time" (subjective, unmeasurable)
### SMART Quality Criteria
**Specific:** Clear, precisely defined capability
**Measurable:** Quantifiable with test criteria
**Attainable:** Realistic within constraints
**Relevant:** Aligns with business objectives
**Traceable:** Links to source (executive summary or user journey)
### FR Anti-Patterns
**Subjective Adjectives:**
- ❌ "easy to use", "intuitive", "user-friendly", "fast", "responsive"
- ✅ Use metrics: "completes task in under 3 clicks", "loads in under 2 seconds"
**Implementation Leakage:**
- ❌ Technology names, specific libraries, implementation details
- ✅ Focus on capability and measurable outcomes
**Vague Quantifiers:**
- ❌ "multiple users", "several options", "various formats"
- ✅ "up to 100 concurrent users", "3-5 options", "PDF, DOCX, TXT formats"
**Missing Test Criteria:**
- ❌ "The system shall provide notifications"
- ✅ "The system shall send email notifications within 30 seconds of trigger event"
---
## What Makes Great Non-Functional Requirements?
### NFRs Must Be Measurable
**Template:**
```
"The system shall [metric] [condition] [measurement method]"
```
**Examples:**
- ✅ "The system shall respond to API requests in under 200ms for 95th percentile as measured by APM monitoring"
- ✅ "The system shall maintain 99.9% uptime during business hours as measured by cloud provider SLA"
- ✅ "The system shall support 10,000 concurrent users as measured by load testing"
### NFR Anti-Patterns
**Unmeasurable Claims:**
- ❌ "The system shall be scalable" → ✅ "The system shall handle 10x load growth through horizontal scaling"
- ❌ "High availability required" → ✅ "99.9% uptime as measured by cloud provider SLA"
**Missing Context:**
- ❌ "Response time under 1 second" → ✅ "API response time under 1 second for 95th percentile under normal load"
---
## Domain-Specific Requirements
**Auto-Detect and Enforce Based on Project Context**
Certain industries have mandatory requirements that must be present:
- **Healthcare:** HIPAA Privacy & Security Rules, PHI encryption, audit logging, MFA
- **Fintech:** PCI-DSS Level 1, AML/KYC compliance, SOX controls, financial audit trails
- **GovTech:** NIST framework, Section 508 accessibility (WCAG 2.1 AA), FedRAMP, data residency
- **E-Commerce:** PCI-DSS for payments, inventory accuracy, tax calculation by jurisdiction
**Why:** Missing these requirements in the PRD means they'll be missed in architecture and implementation, creating expensive rework. During PRD creation there is a step to cover this - during validation we want to make sure it was covered. For this purpose steps will utilize a domain-complexity.csv and project-types.csv.
---
## Document Structure (Markdown, Human-Readable)
### Required Sections
1. **Executive Summary** - Vision, differentiator, target users
2. **Success Criteria** - Measurable outcomes (SMART)
3. **Product Scope** - MVP, Growth, Vision phases
4. **User Journeys** - Comprehensive coverage
5. **Domain Requirements** - Industry-specific compliance (if applicable)
6. **Innovation Analysis** - Competitive differentiation (if applicable)
7. **Project-Type Requirements** - Platform-specific needs
8. **Functional Requirements** - Capability contract (FRs)
9. **Non-Functional Requirements** - Quality attributes (NFRs)
### Formatting for Dual Consumption
**For Humans:**
- Clear, professional language
- Logical flow from vision to requirements
- Easy for stakeholders to review and approve
**For LLMs:**
- ## Level 2 headers for all main sections (enables extraction)
- Consistent structure and patterns
- Precise, testable language
- High information density
---
## Downstream Impact
**How the PRD Feeds Next Artifacts:**
**UX Design:**
- User journeys → interaction flows
- FRs → design requirements
- Success criteria → UX metrics
**Architecture:**
- FRs → system capabilities
- NFRs → architecture decisions
- Domain requirements → compliance architecture
- Project-type requirements → platform choices
**Epics & Stories (created after architecture):**
- FRs → user stories (1 FR could map to 1-3 stories potentially)
- Acceptance criteria → story acceptance tests
- Priority → sprint sequencing
- Traceability → stories map back to vision
**Development AI Agents:**
- Precise requirements → implementation clarity
- Test criteria → automated test generation
- Domain requirements → compliance enforcement
- Measurable NFRs → performance targets
---
## Summary: What Makes a Great BMAD PRD?
✅ **High Information Density** - Every sentence carries weight, zero fluff
✅ **Measurable Requirements** - All FRs and NFRs are testable with specific criteria
✅ **Clear Traceability** - Each requirement links to user need and business objective
✅ **Domain Awareness** - Industry-specific requirements auto-detected and included
✅ **Zero Anti-Patterns** - No subjective adjectives, implementation leakage, or vague quantifiers
✅ **Dual Audience Optimized** - Human-readable AND LLM-consumable
✅ **Markdown Format** - Professional, clean, accessible to all stakeholders
---
**Remember:** The PRD is the foundation. Quality here ripples through every subsequent phase. A dense, precise, well-traced PRD makes UX design, architecture, epic breakdown, and AI development dramatically more effective.

View File

@ -1,11 +0,0 @@
project_type,detection_signals,key_questions,required_sections,skip_sections,web_search_triggers,innovation_signals
api_backend,"API,REST,GraphQL,backend,service,endpoints","Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?","endpoint_specs;auth_model;data_schemas;error_codes;rate_limits;api_docs","ux_ui;visual_design;user_journeys","framework best practices;OpenAPI standards","API composition;New protocol"
mobile_app,"iOS,Android,app,mobile,iPhone,iPad","Native or cross-platform?;Offline needed?;Push notifications?;Device features?;Store compliance?","platform_reqs;device_permissions;offline_mode;push_strategy;store_compliance","desktop_features;cli_commands","app store guidelines;platform requirements","Gesture innovation;AR/VR features"
saas_b2b,"SaaS,B2B,platform,dashboard,teams,enterprise","Multi-tenant?;Permission model?;Subscription tiers?;Integrations?;Compliance?","tenant_model;rbac_matrix;subscription_tiers;integration_list;compliance_reqs","cli_interface;mobile_first","compliance requirements;integration guides","Workflow automation;AI agents"
developer_tool,"SDK,library,package,npm,pip,framework","Language support?;Package managers?;IDE integration?;Documentation?;Examples?","language_matrix;installation_methods;api_surface;code_examples;migration_guide","visual_design;store_compliance","package manager best practices;API design patterns","New paradigm;DSL creation"
cli_tool,"CLI,command,terminal,bash,script","Interactive or scriptable?;Output formats?;Config method?;Shell completion?","command_structure;output_formats;config_schema;scripting_support","visual_design;ux_principles;touch_interactions","CLI design patterns;shell integration","Natural language CLI;AI commands"
web_app,"website,webapp,browser,SPA,PWA","SPA or MPA?;Browser support?;SEO needed?;Real-time?;Accessibility?","browser_matrix;responsive_design;performance_targets;seo_strategy;accessibility_level","native_features;cli_commands","web standards;WCAG guidelines","New interaction;WebAssembly use"
game,"game,player,gameplay,level,character","REDIRECT TO USE THE BMad Method Game Module Agent and Workflows - HALT","game-brief;GDD","most_sections","game design patterns","Novel mechanics;Genre mixing"
desktop_app,"desktop,Windows,Mac,Linux,native","Cross-platform?;Auto-update?;System integration?;Offline?","platform_support;system_integration;update_strategy;offline_capabilities","web_seo;mobile_features","desktop guidelines;platform requirements","Desktop AI;System automation"
iot_embedded,"IoT,embedded,device,sensor,hardware","Hardware specs?;Connectivity?;Power constraints?;Security?;OTA updates?","hardware_reqs;connectivity_protocol;power_profile;security_model;update_mechanism","visual_ui;browser_support","IoT standards;protocol specs","Edge AI;New sensors"
blockchain_web3,"blockchain,crypto,DeFi,NFT,smart contract","Chain selection?;Wallet integration?;Gas optimization?;Security audit?","chain_specs;wallet_support;smart_contracts;security_audit;gas_optimization","traditional_auth;centralized_db","blockchain standards;security patterns","Novel tokenomics;DAO structure"
1 project_type detection_signals key_questions required_sections skip_sections web_search_triggers innovation_signals
2 api_backend API,REST,GraphQL,backend,service,endpoints Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed? endpoint_specs;auth_model;data_schemas;error_codes;rate_limits;api_docs ux_ui;visual_design;user_journeys framework best practices;OpenAPI standards API composition;New protocol
3 mobile_app iOS,Android,app,mobile,iPhone,iPad Native or cross-platform?;Offline needed?;Push notifications?;Device features?;Store compliance? platform_reqs;device_permissions;offline_mode;push_strategy;store_compliance desktop_features;cli_commands app store guidelines;platform requirements Gesture innovation;AR/VR features
4 saas_b2b SaaS,B2B,platform,dashboard,teams,enterprise Multi-tenant?;Permission model?;Subscription tiers?;Integrations?;Compliance? tenant_model;rbac_matrix;subscription_tiers;integration_list;compliance_reqs cli_interface;mobile_first compliance requirements;integration guides Workflow automation;AI agents
5 developer_tool SDK,library,package,npm,pip,framework Language support?;Package managers?;IDE integration?;Documentation?;Examples? language_matrix;installation_methods;api_surface;code_examples;migration_guide visual_design;store_compliance package manager best practices;API design patterns New paradigm;DSL creation
6 cli_tool CLI,command,terminal,bash,script Interactive or scriptable?;Output formats?;Config method?;Shell completion? command_structure;output_formats;config_schema;scripting_support visual_design;ux_principles;touch_interactions CLI design patterns;shell integration Natural language CLI;AI commands
7 web_app website,webapp,browser,SPA,PWA SPA or MPA?;Browser support?;SEO needed?;Real-time?;Accessibility? browser_matrix;responsive_design;performance_targets;seo_strategy;accessibility_level native_features;cli_commands web standards;WCAG guidelines New interaction;WebAssembly use
8 game game,player,gameplay,level,character REDIRECT TO USE THE BMad Method Game Module Agent and Workflows - HALT game-brief;GDD most_sections game design patterns Novel mechanics;Genre mixing
9 desktop_app desktop,Windows,Mac,Linux,native Cross-platform?;Auto-update?;System integration?;Offline? platform_support;system_integration;update_strategy;offline_capabilities web_seo;mobile_features desktop guidelines;platform requirements Desktop AI;System automation
10 iot_embedded IoT,embedded,device,sensor,hardware Hardware specs?;Connectivity?;Power constraints?;Security?;OTA updates? hardware_reqs;connectivity_protocol;power_profile;security_model;update_mechanism visual_ui;browser_support IoT standards;protocol specs Edge AI;New sensors
11 blockchain_web3 blockchain,crypto,DeFi,NFT,smart contract Chain selection?;Wallet integration?;Gas optimization?;Security audit? chain_specs;wallet_support;smart_contracts;security_audit;gas_optimization traditional_auth;centralized_db blockchain standards;security patterns Novel tokenomics;DAO structure

View File

@ -1,224 +0,0 @@
---
name: 'step-v-01-discovery'
description: 'Document Discovery & Confirmation - Handle fresh context validation, confirm PRD path, discover input documents'
# File references (ONLY variables used in this step)
nextStepFile: './step-v-02-format-detection.md'
prdPurpose: '../data/prd-purpose.md'
---
# Step 1: Document Discovery & Confirmation
## STEP GOAL:
Handle fresh context validation by confirming PRD path, discovering and loading input documents from frontmatter, and initializing the validation report.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Validation Architect and Quality Assurance Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring systematic validation expertise and analytical rigor
- ✅ User brings domain knowledge and specific PRD context
### Step-Specific Rules:
- 🎯 Focus ONLY on discovering PRD and input documents, not validating yet
- 🚫 FORBIDDEN to perform any validation checks in this step
- 💬 Approach: Systematic discovery with clear reporting to user
- 🚪 This is the setup step - get everything ready for validation
## EXECUTION PROTOCOLS:
- 🎯 Discover and confirm PRD to validate
- 💾 Load PRD and all input documents from frontmatter
- 📖 Initialize validation report next to PRD
- 🚫 FORBIDDEN to load next step until user confirms setup
## CONTEXT BOUNDARIES:
- Available context: PRD path (user-specified or discovered), workflow configuration
- Focus: Document discovery and setup only
- Limits: Don't perform validation, don't skip discovery
- Dependencies: Configuration loaded from PRD workflow.md initialization
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load PRD Purpose and Standards
Load and read the complete file at:
`{prdPurpose}`
This file contains the BMAD PRD philosophy, standards, and validation criteria that will guide all validation checks. Internalize this understanding - it defines what makes a great BMAD PRD.
### 2. Discover PRD to Validate
**If PRD path provided as invocation parameter:**
- Use provided path
**If no PRD path provided, auto-discover:**
- Search `{planning_artifacts}` for files matching `*prd*.md`
- Also check for sharded PRDs: `{planning_artifacts}/*prd*/*.md`
**If exactly ONE PRD found:**
- Use it automatically
- Inform user: "Found PRD: {discovered_path} — using it for validation."
**If MULTIPLE PRDs found:**
- List all discovered PRDs with numbered options
- "I found multiple PRDs. Which one would you like to validate?"
- Wait for user selection
**If NO PRDs found:**
- "I couldn't find any PRD files in {planning_artifacts}. Please provide the path to the PRD file you want to validate."
- Wait for user to provide PRD path.
### 3. Validate PRD Exists and Load
Once PRD path is provided:
- Check if PRD file exists at specified path
- If not found: "I cannot find a PRD at that path. Please check the path and try again."
- If found: Load the complete PRD file including frontmatter
### 4. Extract Frontmatter and Input Documents
From the loaded PRD frontmatter, extract:
- `inputDocuments: []` array (if present)
- Any other relevant metadata (classification, date, etc.)
**If no inputDocuments array exists:**
Note this and proceed with PRD-only validation
### 5. Load Input Documents
For each document listed in `inputDocuments`:
- Attempt to load the document
- Track successfully loaded documents
- Note any documents that fail to load
**Build list of loaded input documents:**
- Product Brief (if present)
- Research documents (if present)
- Other reference materials (if present)
### 6. Ask About Additional Reference Documents
"**I've loaded the following documents from your PRD frontmatter:**
{list loaded documents with file names}
**Are there any additional reference documents you'd like me to include in this validation?**
These could include:
- Additional research or context documents
- Project documentation not tracked in frontmatter
- Standards or compliance documents
- Competitive analysis or benchmarks
Please provide paths to any additional documents, or type 'none' to proceed."
**Load any additional documents provided by user.**
### 7. Initialize Validation Report
Create validation report at: `{validationReportPath}`
**Initialize with frontmatter:**
```yaml
---
validationTarget: '{prd_path}'
validationDate: '{current_date}'
inputDocuments: [list of all loaded documents]
validationStepsCompleted: []
validationStatus: IN_PROGRESS
---
```
**Initial content:**
```markdown
# PRD Validation Report
**PRD Being Validated:** {prd_path}
**Validation Date:** {current_date}
## Input Documents
{list all documents loaded for validation}
## Validation Findings
[Findings will be appended as validation progresses]
```
### 8. Present Discovery Summary
"**Setup Complete!**
**PRD to Validate:** {prd_path}
**Input Documents Loaded:**
- PRD: {prd_name} ✓
- Product Brief: {count} {if count > 0}✓{else}(none found){/if}
- Research: {count} {if count > 0}✓{else}(none found){/if}
- Additional References: {count} {if count > 0}✓{else}(none){/if}
**Validation Report:** {validationReportPath}
**Ready to begin validation.**"
### 9. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Format Detection
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- User can ask questions or add more documents - always respond and redisplay menu
#### Menu Handling Logic:
- IF A: Invoke the `bmad-advanced-elicitation` skill, and when finished redisplay the menu
- IF P: Invoke the `bmad-party-mode` skill, and when finished redisplay the menu
- IF C: Read fully and follow: {nextStepFile} to begin format detection
- IF user provides additional document: Load it, update report, redisplay summary
- IF Any other: help user, then redisplay menu
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- PRD path discovered and confirmed
- PRD file exists and loads successfully
- All input documents from frontmatter loaded
- Additional reference documents (if any) loaded
- Validation report initialized next to PRD
- User clearly informed of setup status
- Menu presented and user input handled correctly
### ❌ SYSTEM FAILURE:
- Proceeding with non-existent PRD file
- Not loading input documents from frontmatter
- Creating validation report in wrong location
- Proceeding without user confirming setup
- Not handling missing input documents gracefully
**Master Rule:** Complete discovery and setup BEFORE validation. This step ensures everything is in place for systematic validation checks.

View File

@ -1,191 +0,0 @@
---
name: 'step-v-02-format-detection'
description: 'Format Detection & Structure Analysis - Classify PRD format and route appropriately'
# File references (ONLY variables used in this step)
nextStepFile: './step-v-03-density-validation.md'
altStepFile: './step-v-02b-parity-check.md'
prdFile: '{prd_file_path}'
validationReportPath: '{validation_report_path}'
---
# Step 2: Format Detection & Structure Analysis
## STEP GOAL:
Detect if PRD follows BMAD format and route appropriately - classify as BMAD Standard / BMAD Variant / Non-Standard, with optional parity check for non-standard formats.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Validation Architect and Quality Assurance Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring systematic validation expertise and pattern recognition
- ✅ User brings domain knowledge and PRD context
### Step-Specific Rules:
- 🎯 Focus ONLY on detecting format and classifying structure
- 🚫 FORBIDDEN to perform other validation checks in this step
- 💬 Approach: Analytical and systematic, clear reporting of findings
- 🚪 This is a branch step - may route to parity check for non-standard PRDs
## EXECUTION PROTOCOLS:
- 🎯 Analyze PRD structure systematically
- 💾 Append format findings to validation report
- 📖 Route appropriately based on format classification
- 🚫 FORBIDDEN to skip format detection or proceed without classification
## CONTEXT BOUNDARIES:
- Available context: PRD file loaded in step 1, validation report initialized
- Focus: Format detection and classification only
- Limits: Don't perform other validation, don't skip classification
- Dependencies: Step 1 completed - PRD loaded and report initialized
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Extract PRD Structure
Load the complete PRD file and extract:
**All Level 2 (##) headers:**
- Scan through entire PRD document
- Extract all ## section headers
- List them in order
**PRD frontmatter:**
- Extract classification.domain if present
- Extract classification.projectType if present
- Note any other relevant metadata
### 2. Check for BMAD PRD Core Sections
Check if the PRD contains the following BMAD PRD core sections:
1. **Executive Summary** (or variations: ## Executive Summary, ## Overview, ## Introduction)
2. **Success Criteria** (or: ## Success Criteria, ## Goals, ## Objectives)
3. **Product Scope** (or: ## Product Scope, ## Scope, ## In Scope, ## Out of Scope)
4. **User Journeys** (or: ## User Journeys, ## User Stories, ## User Flows)
5. **Functional Requirements** (or: ## Functional Requirements, ## Features, ## Capabilities)
6. **Non-Functional Requirements** (or: ## Non-Functional Requirements, ## NFRs, ## Quality Attributes)
**Count matches:**
- How many of these 6 core sections are present?
- Which specific sections are present?
- Which are missing?
### 3. Classify PRD Format
Based on core section count, classify:
**BMAD Standard:**
- 5-6 core sections present
- Follows BMAD PRD structure closely
**BMAD Variant:**
- 3-4 core sections present
- Generally follows BMAD patterns but may have structural differences
- Missing some sections but recognizable as BMAD-style
**Non-Standard:**
- Fewer than 3 core sections present
- Does not follow BMAD PRD structure
- May be completely custom format, legacy format, or from another framework
### 4. Report Format Findings to Validation Report
Append to validation report:
```markdown
## Format Detection
**PRD Structure:**
[List all ## Level 2 headers found]
**BMAD Core Sections Present:**
- Executive Summary: [Present/Missing]
- Success Criteria: [Present/Missing]
- Product Scope: [Present/Missing]
- User Journeys: [Present/Missing]
- Functional Requirements: [Present/Missing]
- Non-Functional Requirements: [Present/Missing]
**Format Classification:** [BMAD Standard / BMAD Variant / Non-Standard]
**Core Sections Present:** [count]/6
```
### 5. Route Based on Format Classification
**IF format is BMAD Standard or BMAD Variant:**
Display: "**Format Detected:** {classification}
Proceeding to systematic validation checks..."
Without delay, read fully and follow: {nextStepFile} (step-v-03-density-validation.md)
**IF format is Non-Standard (< 3 core sections):**
Display: "**Format Detected:** Non-Standard PRD
This PRD does not follow BMAD standard structure (only {count}/6 core sections present).
You have options:"
Present MENU OPTIONS below for user selection
### 6. Present MENU OPTIONS (Non-Standard PRDs Only)
**[A] Parity Check** - Analyze gaps and estimate effort to reach BMAD PRD parity
**[B] Validate As-Is** - Proceed with validation using current structure
**[C] Exit** - Exit validation and review format findings
#### EXECUTION RULES:
- ALWAYS halt and wait for user input
- Only proceed based on user selection
#### Menu Handling Logic:
- IF A (Parity Check): Read fully and follow: {altStepFile} (step-v-02b-parity-check.md)
- IF B (Validate As-Is): Display "Proceeding with validation..." then read fully and follow: {nextStepFile}
- IF C (Exit): Display format findings summary and exit validation
- IF Any other: help user respond, then redisplay menu
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All ## Level 2 headers extracted successfully
- BMAD core sections checked systematically
- Format classified correctly based on section count
- Findings reported to validation report
- BMAD Standard/Variant PRDs proceed directly to next validation step
- Non-Standard PRDs pause and present options to user
- User can choose parity check, validate as-is, or exit
### ❌ SYSTEM FAILURE:
- Not extracting all headers before classification
- Incorrect format classification
- Not reporting findings to validation report
- Not pausing for non-standard PRDs
- Proceeding without user decision for non-standard formats
**Master Rule:** Format detection determines validation path. Non-standard PRDs require user choice before proceeding.

View File

@ -1,209 +0,0 @@
---
name: 'step-v-02b-parity-check'
description: 'Document Parity Check - Analyze non-standard PRD and identify gaps to achieve BMAD PRD parity'
# File references (ONLY variables used in this step)
nextStepFile: './step-v-03-density-validation.md'
prdFile: '{prd_file_path}'
validationReportPath: '{validation_report_path}'
---
# Step 2B: Document Parity Check
## STEP GOAL:
Analyze non-standard PRD and identify gaps to achieve BMAD PRD parity, presenting user with options for how to proceed.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Validation Architect and Quality Assurance Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring BMAD PRD standards expertise and gap analysis
- ✅ User brings domain knowledge and PRD context
### Step-Specific Rules:
- 🎯 Focus ONLY on analyzing gaps and estimating parity effort
- 🚫 FORBIDDEN to perform other validation checks in this step
- 💬 Approach: Systematic gap analysis with clear recommendations
- 🚪 This is an optional branch step - user chooses next action
## EXECUTION PROTOCOLS:
- 🎯 Analyze each BMAD PRD section for gaps
- 💾 Append parity analysis to validation report
- 📖 Present options and await user decision
- 🚫 FORBIDDEN to proceed without user selection
## CONTEXT BOUNDARIES:
- Available context: Non-standard PRD from step 2, validation report in progress
- Focus: Parity analysis only - what's missing, what's needed
- Limits: Don't perform validation checks, don't auto-proceed
- Dependencies: Step 2 classified PRD as non-standard and user chose parity check
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Analyze Each BMAD PRD Section
For each of the 6 BMAD PRD core sections, analyze:
**Executive Summary:**
- Does PRD have vision/overview?
- Is problem statement clear?
- Are target users identified?
- Gap: [What's missing or incomplete]
**Success Criteria:**
- Are measurable goals defined?
- Is success clearly defined?
- Gap: [What's missing or incomplete]
**Product Scope:**
- Is scope clearly defined?
- Are in-scope items listed?
- Are out-of-scope items listed?
- Gap: [What's missing or incomplete]
**User Journeys:**
- Are user types/personas identified?
- Are user flows documented?
- Gap: [What's missing or incomplete]
**Functional Requirements:**
- Are features/capabilities listed?
- Are requirements structured?
- Gap: [What's missing or incomplete]
**Non-Functional Requirements:**
- Are quality attributes defined?
- Are performance/security/etc. requirements documented?
- Gap: [What's missing or incomplete]
### 2. Estimate Effort to Reach Parity
For each missing or incomplete section, estimate:
**Effort Level:**
- Minimal - Section exists but needs minor enhancements
- Moderate - Section missing but content exists elsewhere in PRD
- Significant - Section missing, requires new content creation
**Total Parity Effort:**
- Based on individual section estimates
- Classify overall: Quick / Moderate / Substantial effort
### 3. Report Parity Analysis to Validation Report
Append to validation report:
```markdown
## Parity Analysis (Non-Standard PRD)
### Section-by-Section Gap Analysis
**Executive Summary:**
- Status: [Present/Missing/Incomplete]
- Gap: [specific gap description]
- Effort to Complete: [Minimal/Moderate/Significant]
**Success Criteria:**
- Status: [Present/Missing/Incomplete]
- Gap: [specific gap description]
- Effort to Complete: [Minimal/Moderate/Significant]
**Product Scope:**
- Status: [Present/Missing/Incomplete]
- Gap: [specific gap description]
- Effort to Complete: [Minimal/Moderate/Significant]
**User Journeys:**
- Status: [Present/Missing/Incomplete]
- Gap: [specific gap description]
- Effort to Complete: [Minimal/Moderate/Significant]
**Functional Requirements:**
- Status: [Present/Missing/Incomplete]
- Gap: [specific gap description]
- Effort to Complete: [Minimal/Moderate/Significant]
**Non-Functional Requirements:**
- Status: [Present/Missing/Incomplete]
- Gap: [specific gap description]
- Effort to Complete: [Minimal/Moderate/Significant]
### Overall Parity Assessment
**Overall Effort to Reach BMAD Standard:** [Quick/Moderate/Substantial]
**Recommendation:** [Brief recommendation based on analysis]
```
### 4. Present Parity Analysis and Options
Display:
"**Parity Analysis Complete**
Your PRD is missing {count} of 6 core BMAD PRD sections. The overall effort to reach BMAD standard is: **{effort level}**
**Quick Summary:**
[2-3 sentence summary of key gaps]
**Recommendation:**
{recommendation from analysis}
**How would you like to proceed?**"
### 5. Present MENU OPTIONS
**[C] Continue Validation** - Proceed with validation using current structure
**[E] Exit & Review** - Exit validation and review parity report
**[S] Save & Exit** - Save parity report and exit
#### EXECUTION RULES:
- ALWAYS halt and wait for user input
- Only proceed based on user selection
#### Menu Handling Logic:
- IF C (Continue): Display "Proceeding with validation..." then read fully and follow: {nextStepFile}
- IF E (Exit): Display parity summary and exit validation
- IF S (Save): Confirm saved, display summary, exit
- IF Any other: help user respond, then redisplay menu
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All 6 BMAD PRD sections analyzed for gaps
- Effort estimates provided for each gap
- Overall parity effort assessed correctly
- Parity analysis reported to validation report
- Clear summary presented to user
- User can choose to continue validation, exit, or save report
### ❌ SYSTEM FAILURE:
- Not analyzing all 6 sections systematically
- Missing effort estimates
- Not reporting parity analysis to validation report
- Auto-proceeding without user decision
- Unclear recommendations
**Master Rule:** Parity check informs user of gaps and effort, but user decides whether to proceed with validation or address gaps first.

View File

@ -1,174 +0,0 @@
---
name: 'step-v-03-density-validation'
description: 'Information Density Check - Scan for anti-patterns that violate information density principles'
# File references (ONLY variables used in this step)
nextStepFile: './step-v-04-brief-coverage-validation.md'
prdFile: '{prd_file_path}'
validationReportPath: '{validation_report_path}'
---
# Step 3: Information Density Validation
## STEP GOAL:
Validate PRD meets BMAD information density standards by scanning for conversational filler, wordy phrases, and redundant expressions that violate conciseness principles.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Validation Architect and Quality Assurance Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in systematic validation, not collaborative dialogue
- ✅ You bring analytical rigor and attention to detail
- ✅ This step runs autonomously - no user input needed
### Step-Specific Rules:
- 🎯 Focus ONLY on information density anti-patterns
- 🚫 FORBIDDEN to validate other aspects in this step
- 💬 Approach: Systematic scanning and categorization
- 🚪 This is a validation sequence step - auto-proceeds when complete
## EXECUTION PROTOCOLS:
- 🎯 Scan PRD for density anti-patterns systematically
- 💾 Append density findings to validation report
- 📖 Display "Proceeding to next check..." and load next step
- 🚫 FORBIDDEN to pause or request user input
## CONTEXT BOUNDARIES:
- Available context: PRD file, validation report with format findings
- Focus: Information density validation only
- Limits: Don't validate other aspects, don't pause for user input
- Dependencies: Step 2 completed - format classification done
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Attempt Sub-Process Validation
**Try to use Task tool to spawn a subprocess:**
"Perform information density validation on this PRD:
1. Load the PRD file
2. Scan for the following anti-patterns:
- Conversational filler phrases (examples: 'The system will allow users to...', 'It is important to note that...', 'In order to')
- Wordy phrases (examples: 'Due to the fact that', 'In the event of', 'For the purpose of')
- Redundant phrases (examples: 'Future plans', 'Absolutely essential', 'Past history')
3. Count violations by category with line numbers
4. Classify severity: Critical (>10 violations), Warning (5-10), Pass (<5)
Return structured findings with counts and examples."
### 2. Graceful Degradation (if Task tool unavailable)
If Task tool unavailable, perform analysis directly:
**Scan for conversational filler patterns:**
- "The system will allow users to..."
- "It is important to note that..."
- "In order to"
- "For the purpose of"
- "With regard to"
- Count occurrences and note line numbers
**Scan for wordy phrases:**
- "Due to the fact that" (use "because")
- "In the event of" (use "if")
- "At this point in time" (use "now")
- "In a manner that" (use "how")
- Count occurrences and note line numbers
**Scan for redundant phrases:**
- "Future plans" (just "plans")
- "Past history" (just "history")
- "Absolutely essential" (just "essential")
- "Completely finish" (just "finish")
- Count occurrences and note line numbers
### 3. Classify Severity
**Calculate total violations:**
- Conversational filler count
- Wordy phrases count
- Redundant phrases count
- Total = sum of all categories
**Determine severity:**
- **Critical:** Total > 10 violations
- **Warning:** Total 5-10 violations
- **Pass:** Total < 5 violations
### 4. Report Density Findings to Validation Report
Append to validation report:
```markdown
## Information Density Validation
**Anti-Pattern Violations:**
**Conversational Filler:** {count} occurrences
[If count > 0, list examples with line numbers]
**Wordy Phrases:** {count} occurrences
[If count > 0, list examples with line numbers]
**Redundant Phrases:** {count} occurrences
[If count > 0, list examples with line numbers]
**Total Violations:** {total}
**Severity Assessment:** [Critical/Warning/Pass]
**Recommendation:**
[If Critical] "PRD requires significant revision to improve information density. Every sentence should carry weight without filler."
[If Warning] "PRD would benefit from reducing wordiness and eliminating filler phrases."
[If Pass] "PRD demonstrates good information density with minimal violations."
```
### 5. Display Progress and Auto-Proceed
Display: "**Information Density Validation Complete**
Severity: {Critical/Warning/Pass}
**Proceeding to next validation check...**"
Without delay, read fully and follow: {nextStepFile} (step-v-04-brief-coverage-validation.md)
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- PRD scanned for all three anti-pattern categories
- Violations counted with line numbers
- Severity classified correctly
- Findings reported to validation report
- Auto-proceeds to next validation step
- Subprocess attempted with graceful degradation
### ❌ SYSTEM FAILURE:
- Not scanning all anti-pattern categories
- Missing severity classification
- Not reporting findings to validation report
- Pausing for user input (should auto-proceed)
- Not attempting subprocess architecture
**Master Rule:** Information density validation runs autonomously. Scan, classify, report, auto-proceed. No user interaction needed.

View File

@ -1,214 +0,0 @@
---
name: 'step-v-04-brief-coverage-validation'
description: 'Product Brief Coverage Check - Validate PRD covers all content from Product Brief (if used as input)'
# File references (ONLY variables used in this step)
nextStepFile: './step-v-05-measurability-validation.md'
prdFile: '{prd_file_path}'
productBrief: '{product_brief_path}'
validationReportPath: '{validation_report_path}'
---
# Step 4: Product Brief Coverage Validation
## STEP GOAL:
Validate that PRD covers all content from Product Brief (if brief was used as input), mapping brief content to PRD sections and identifying gaps.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Validation Architect and Quality Assurance Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in systematic validation, not collaborative dialogue
- ✅ You bring analytical rigor and traceability expertise
- ✅ This step runs autonomously - no user input needed
### Step-Specific Rules:
- 🎯 Focus ONLY on Product Brief coverage (conditional on brief existence)
- 🚫 FORBIDDEN to validate other aspects in this step
- 💬 Approach: Systematic mapping and gap analysis
- 🚪 This is a validation sequence step - auto-proceeds when complete
## EXECUTION PROTOCOLS:
- 🎯 Check if Product Brief exists in input documents
- 💬 If no brief: Skip this check and report "N/A - No Product Brief"
- 🎯 If brief exists: Map brief content to PRD sections
- 💾 Append coverage findings to validation report
- 📖 Display "Proceeding to next check..." and load next step
- 🚫 FORBIDDEN to pause or request user input
## CONTEXT BOUNDARIES:
- Available context: PRD file, input documents from step 1, validation report
- Focus: Product Brief coverage only (conditional)
- Limits: Don't validate other aspects, conditional execution
- Dependencies: Step 1 completed - input documents loaded
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Check for Product Brief
Check if Product Brief was loaded in step 1's inputDocuments:
**IF no Product Brief found:**
Append to validation report:
```markdown
## Product Brief Coverage
**Status:** N/A - No Product Brief was provided as input
```
Display: "**Product Brief Coverage: Skipped** (No Product Brief provided)
**Proceeding to next validation check...**"
Without delay, read fully and follow: {nextStepFile}
**IF Product Brief exists:** Continue to step 2 below
### 2. Attempt Sub-Process Validation
**Try to use Task tool to spawn a subprocess:**
"Perform Product Brief coverage validation:
1. Load the Product Brief
2. Extract key content:
- Vision statement
- Target users/personas
- Problem statement
- Key features
- Goals/objectives
- Differentiators
- Constraints
3. For each item, search PRD for corresponding coverage
4. Classify coverage: Fully Covered / Partially Covered / Not Found / Intentionally Excluded
5. Note any gaps with severity: Critical / Moderate / Informational
Return structured coverage map with classifications."
### 3. Graceful Degradation (if Task tool unavailable)
If Task tool unavailable, perform analysis directly:
**Extract from Product Brief:**
- Vision: What is this product?
- Users: Who is it for?
- Problem: What problem does it solve?
- Features: What are the key capabilities?
- Goals: What are the success criteria?
- Differentiators: What makes it unique?
**For each item, search PRD:**
- Scan Executive Summary for vision
- Check User Journeys or user personas
- Look for problem statement
- Review Functional Requirements for features
- Check Success Criteria section
- Search for differentiators
**Classify coverage:**
- **Fully Covered:** Content present and complete
- **Partially Covered:** Content present but incomplete
- **Not Found:** Content missing from PRD
- **Intentionally Excluded:** Content explicitly out of scope
### 4. Assess Coverage and Severity
**For each gap (Partially Covered or Not Found):**
- Is this Critical? (Core vision, primary users, main features)
- Is this Moderate? (Secondary features, some goals)
- Is this Informational? (Nice-to-have features, minor details)
**Note:** Some exclusions may be intentional (valid scoping decisions)
### 5. Report Coverage Findings to Validation Report
Append to validation report:
```markdown
## Product Brief Coverage
**Product Brief:** {brief_file_name}
### Coverage Map
**Vision Statement:** [Fully/Partially/Not Found/Intentionally Excluded]
[If gap: Note severity and specific missing content]
**Target Users:** [Fully/Partially/Not Found/Intentionally Excluded]
[If gap: Note severity and specific missing content]
**Problem Statement:** [Fully/Partially/Not Found/Intentionally Excluded]
[If gap: Note severity and specific missing content]
**Key Features:** [Fully/Partially/Not Found/Intentionally Excluded]
[If gap: List specific features with severity]
**Goals/Objectives:** [Fully/Partially/Not Found/Intentionally Excluded]
[If gap: Note severity and specific missing content]
**Differentiators:** [Fully/Partially/Not Found/Intentionally Excluded]
[If gap: Note severity and specific missing content]
### Coverage Summary
**Overall Coverage:** [percentage or qualitative assessment]
**Critical Gaps:** [count] [list if any]
**Moderate Gaps:** [count] [list if any]
**Informational Gaps:** [count] [list if any]
**Recommendation:**
[If critical gaps exist] "PRD should be revised to cover critical Product Brief content."
[If moderate gaps] "Consider addressing moderate gaps for complete coverage."
[If minimal gaps] "PRD provides good coverage of Product Brief content."
```
### 6. Display Progress and Auto-Proceed
Display: "**Product Brief Coverage Validation Complete**
Overall Coverage: {assessment}
**Proceeding to next validation check...**"
Without delay, read fully and follow: {nextStepFile} (step-v-05-measurability-validation.md)
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Checked for Product Brief existence correctly
- If no brief: Reported "N/A" and skipped gracefully
- If brief exists: Mapped all key brief content to PRD sections
- Coverage classified appropriately (Fully/Partially/Not Found/Intentionally Excluded)
- Severity assessed for gaps (Critical/Moderate/Informational)
- Findings reported to validation report
- Auto-proceeds to next validation step
- Subprocess attempted with graceful degradation
### ❌ SYSTEM FAILURE:
- Not checking for brief existence before attempting validation
- If brief exists: not mapping all key content areas
- Missing coverage classifications
- Not reporting findings to validation report
- Not auto-proceeding
**Master Rule:** Product Brief coverage is conditional - skip if no brief, validate thoroughly if brief exists. Always auto-proceed.

View File

@ -1,228 +0,0 @@
---
name: 'step-v-05-measurability-validation'
description: 'Measurability Validation - Validate that all requirements (FRs and NFRs) are measurable and testable'
# File references (ONLY variables used in this step)
nextStepFile: './step-v-06-traceability-validation.md'
prdFile: '{prd_file_path}'
validationReportPath: '{validation_report_path}'
---
# Step 5: Measurability Validation
## STEP GOAL:
Validate that all Functional Requirements (FRs) and Non-Functional Requirements (NFRs) are measurable, testable, and follow proper format without implementation details.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Validation Architect and Quality Assurance Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in systematic validation, not collaborative dialogue
- ✅ You bring analytical rigor and requirements engineering expertise
- ✅ This step runs autonomously - no user input needed
### Step-Specific Rules:
- 🎯 Focus ONLY on FR and NFR measurability
- 🚫 FORBIDDEN to validate other aspects in this step
- 💬 Approach: Systematic requirement-by-requirement analysis
- 🚪 This is a validation sequence step - auto-proceeds when complete
## EXECUTION PROTOCOLS:
- 🎯 Extract all FRs and NFRs from PRD
- 💾 Validate each for measurability and format
- 📖 Append findings to validation report
- 📖 Display "Proceeding to next check..." and load next step
- 🚫 FORBIDDEN to pause or request user input
## CONTEXT BOUNDARIES:
- Available context: PRD file, validation report
- Focus: FR and NFR measurability only
- Limits: Don't validate other aspects, don't pause for user input
- Dependencies: Steps 2-4 completed - initial validation checks done
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Attempt Sub-Process Validation
**Try to use Task tool to spawn a subprocess:**
"Perform measurability validation on this PRD:
**Functional Requirements (FRs):**
1. Extract all FRs from Functional Requirements section
2. Check each FR for:
- '[Actor] can [capability]' format compliance
- No subjective adjectives (easy, fast, simple, intuitive, etc.)
- No vague quantifiers (multiple, several, some, many, etc.)
- No implementation details (technology names, library names, data structures unless capability-relevant)
3. Document violations with line numbers
**Non-Functional Requirements (NFRs):**
1. Extract all NFRs from Non-Functional Requirements section
2. Check each NFR for:
- Specific metrics with measurement methods
- Template compliance (criterion, metric, measurement method, context)
- Context included (why this matters, who it affects)
3. Document violations with line numbers
Return structured findings with violation counts and examples."
### 2. Graceful Degradation (if Task tool unavailable)
If Task tool unavailable, perform analysis directly:
**Functional Requirements Analysis:**
Extract all FRs and check each for:
**Format compliance:**
- Does it follow "[Actor] can [capability]" pattern?
- Is actor clearly defined?
- Is capability actionable and testable?
**No subjective adjectives:**
- Scan for: easy, fast, simple, intuitive, user-friendly, responsive, quick, efficient (without metrics)
- Note line numbers
**No vague quantifiers:**
- Scan for: multiple, several, some, many, few, various, number of
- Note line numbers
**No implementation details:**
- Scan for: React, Vue, Angular, PostgreSQL, MongoDB, AWS, Docker, Kubernetes, Redux, etc.
- Unless capability-relevant (e.g., "API consumers can access...")
- Note line numbers
**Non-Functional Requirements Analysis:**
Extract all NFRs and check each for:
**Specific metrics:**
- Is there a measurable criterion? (e.g., "response time < 200ms", not "fast response")
- Can this be measured or tested?
**Template compliance:**
- Criterion defined?
- Metric specified?
- Measurement method included?
- Context provided?
### 3. Tally Violations
**FR Violations:**
- Format violations: count
- Subjective adjectives: count
- Vague quantifiers: count
- Implementation leakage: count
- Total FR violations: sum
**NFR Violations:**
- Missing metrics: count
- Incomplete template: count
- Missing context: count
- Total NFR violations: sum
**Total violations:** FR violations + NFR violations
### 4. Report Measurability Findings to Validation Report
Append to validation report:
```markdown
## Measurability Validation
### Functional Requirements
**Total FRs Analyzed:** {count}
**Format Violations:** {count}
[If violations exist, list examples with line numbers]
**Subjective Adjectives Found:** {count}
[If found, list examples with line numbers]
**Vague Quantifiers Found:** {count}
[If found, list examples with line numbers]
**Implementation Leakage:** {count}
[If found, list examples with line numbers]
**FR Violations Total:** {total}
### Non-Functional Requirements
**Total NFRs Analyzed:** {count}
**Missing Metrics:** {count}
[If missing, list examples with line numbers]
**Incomplete Template:** {count}
[If incomplete, list examples with line numbers]
**Missing Context:** {count}
[If missing, list examples with line numbers]
**NFR Violations Total:** {total}
### Overall Assessment
**Total Requirements:** {FRs + NFRs}
**Total Violations:** {FR violations + NFR violations}
**Severity:** [Critical if >10 violations, Warning if 5-10, Pass if <5]
**Recommendation:**
[If Critical] "Many requirements are not measurable or testable. Requirements must be revised to be testable for downstream work."
[If Warning] "Some requirements need refinement for measurability. Focus on violating requirements above."
[If Pass] "Requirements demonstrate good measurability with minimal issues."
```
### 5. Display Progress and Auto-Proceed
Display: "**Measurability Validation Complete**
Total Violations: {count} ({severity})
**Proceeding to next validation check...**"
Without delay, read fully and follow: {nextStepFile} (step-v-06-traceability-validation.md)
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All FRs extracted and analyzed for measurability
- All NFRs extracted and analyzed for measurability
- Violations documented with line numbers
- Severity assessed correctly
- Findings reported to validation report
- Auto-proceeds to next validation step
- Subprocess attempted with graceful degradation
### ❌ SYSTEM FAILURE:
- Not analyzing all FRs and NFRs
- Missing line numbers for violations
- Not reporting findings to validation report
- Not assessing severity
- Not auto-proceeding
**Master Rule:** Requirements must be testable to be useful. Validate every requirement for measurability, document violations, auto-proceed.

View File

@ -1,217 +0,0 @@
---
name: 'step-v-06-traceability-validation'
description: 'Traceability Validation - Validate the traceability chain from vision → success → journeys → FRs is intact'
# File references (ONLY variables used in this step)
nextStepFile: './step-v-07-implementation-leakage-validation.md'
prdFile: '{prd_file_path}'
validationReportPath: '{validation_report_path}'
---
# Step 6: Traceability Validation
## STEP GOAL:
Validate the traceability chain from Executive Summary → Success Criteria → User Journeys → Functional Requirements is intact, ensuring every requirement traces back to a user need or business objective.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Validation Architect and Quality Assurance Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in systematic validation, not collaborative dialogue
- ✅ You bring analytical rigor and traceability matrix expertise
- ✅ This step runs autonomously - no user input needed
### Step-Specific Rules:
- 🎯 Focus ONLY on traceability chain validation
- 🚫 FORBIDDEN to validate other aspects in this step
- 💬 Approach: Systematic chain validation and orphan detection
- 🚪 This is a validation sequence step - auto-proceeds when complete
## EXECUTION PROTOCOLS:
- 🎯 Build and validate traceability matrix
- 💾 Identify broken chains and orphan requirements
- 📖 Append findings to validation report
- 📖 Display "Proceeding to next check..." and load next step
- 🚫 FORBIDDEN to pause or request user input
## CONTEXT BOUNDARIES:
- Available context: PRD file, validation report
- Focus: Traceability chain validation only
- Limits: Don't validate other aspects, don't pause for user input
- Dependencies: Steps 2-5 completed - initial validations done
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Attempt Sub-Process Validation
**Try to use Task tool to spawn a subprocess:**
"Perform traceability validation on this PRD:
1. Extract content from Executive Summary (vision, goals)
2. Extract Success Criteria
3. Extract User Journeys (user types, flows, outcomes)
4. Extract Functional Requirements (FRs)
5. Extract Product Scope (in-scope items)
**Validate chains:**
- Executive Summary → Success Criteria: Does vision align with defined success?
- Success Criteria → User Journeys: Are success criteria supported by user journeys?
- User Journeys → Functional Requirements: Does each FR trace back to a user journey?
- Scope → FRs: Do MVP scope FRs align with in-scope items?
**Identify orphans:**
- FRs not traceable to any user journey or business objective
- Success criteria not supported by user journeys
- User journeys without supporting FRs
Build traceability matrix and identify broken chains and orphan FRs.
Return structured findings with chain status and orphan list."
### 2. Graceful Degradation (if Task tool unavailable)
If Task tool unavailable, perform analysis directly:
**Step 1: Extract key elements**
- Executive Summary: Note vision, goals, objectives
- Success Criteria: List all criteria
- User Journeys: List user types and their flows
- Functional Requirements: List all FRs
- Product Scope: List in-scope items
**Step 2: Validate Executive Summary → Success Criteria**
- Does Executive Summary mention the success dimensions?
- Are Success Criteria aligned with vision?
- Note any misalignment
**Step 3: Validate Success Criteria → User Journeys**
- For each success criterion, is there a user journey that achieves it?
- Note success criteria without supporting journeys
**Step 4: Validate User Journeys → FRs**
- For each user journey/flow, are there FRs that enable it?
- List FRs with no clear user journey origin
- Note orphan FRs (requirements without traceable source)
**Step 5: Validate Scope → FR Alignment**
- Does MVP scope align with essential FRs?
- Are in-scope items supported by FRs?
- Note misalignments
**Step 6: Build traceability matrix**
- Map each FR to its source (journey or business objective)
- Note orphan FRs
- Identify broken chains
### 3. Tally Traceability Issues
**Broken chains:**
- Executive Summary → Success Criteria gaps: count
- Success Criteria → User Journeys gaps: count
- User Journeys → FRs gaps: count
- Scope → FR misalignments: count
**Orphan elements:**
- Orphan FRs (no traceable source): count
- Unsupported success criteria: count
- User journeys without FRs: count
**Total issues:** Sum of all broken chains and orphans
### 4. Report Traceability Findings to Validation Report
Append to validation report:
```markdown
## Traceability Validation
### Chain Validation
**Executive Summary → Success Criteria:** [Intact/Gaps Identified]
{If gaps: List specific misalignments}
**Success Criteria → User Journeys:** [Intact/Gaps Identified]
{If gaps: List unsupported success criteria}
**User Journeys → Functional Requirements:** [Intact/Gaps Identified]
{If gaps: List journeys without supporting FRs}
**Scope → FR Alignment:** [Intact/Misaligned]
{If misaligned: List specific issues}
### Orphan Elements
**Orphan Functional Requirements:** {count}
{List orphan FRs with numbers}
**Unsupported Success Criteria:** {count}
{List unsupported criteria}
**User Journeys Without FRs:** {count}
{List journeys without FRs}
### Traceability Matrix
{Summary table showing traceability coverage}
**Total Traceability Issues:** {total}
**Severity:** [Critical if orphan FRs exist, Warning if gaps, Pass if intact]
**Recommendation:**
[If Critical] "Orphan requirements exist - every FR must trace back to a user need or business objective."
[If Warning] "Traceability gaps identified - strengthen chains to ensure all requirements are justified."
[If Pass] "Traceability chain is intact - all requirements trace to user needs or business objectives."
```
### 5. Display Progress and Auto-Proceed
Display: "**Traceability Validation Complete**
Total Issues: {count} ({severity})
**Proceeding to next validation check...**"
Without delay, read fully and follow: {nextStepFile} (step-v-07-implementation-leakage-validation.md)
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All traceability chains validated systematically
- Orphan FRs identified with numbers
- Broken chains documented
- Traceability matrix built
- Severity assessed correctly
- Findings reported to validation report
- Auto-proceeds to next validation step
- Subprocess attempted with graceful degradation
### ❌ SYSTEM FAILURE:
- Not validating all traceability chains
- Missing orphan FR detection
- Not building traceability matrix
- Not reporting findings to validation report
- Not auto-proceeding
**Master Rule:** Every requirement should trace to a user need or business objective. Orphan FRs indicate broken traceability that must be fixed.

View File

@ -1,205 +0,0 @@
---
name: 'step-v-07-implementation-leakage-validation'
description: 'Implementation Leakage Check - Ensure FRs and NFRs don\'t include implementation details'
# File references (ONLY variables used in this step)
nextStepFile: './step-v-08-domain-compliance-validation.md'
prdFile: '{prd_file_path}'
validationReportPath: '{validation_report_path}'
---
# Step 7: Implementation Leakage Validation
## STEP GOAL:
Ensure Functional Requirements and Non-Functional Requirements don't include implementation details - they should specify WHAT, not HOW.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Validation Architect and Quality Assurance Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in systematic validation, not collaborative dialogue
- ✅ You bring analytical rigor and separation of concerns expertise
- ✅ This step runs autonomously - no user input needed
### Step-Specific Rules:
- 🎯 Focus ONLY on implementation leakage detection
- 🚫 FORBIDDEN to validate other aspects in this step
- 💬 Approach: Systematic scanning for technology and implementation terms
- 🚪 This is a validation sequence step - auto-proceeds when complete
## EXECUTION PROTOCOLS:
- 🎯 Scan FRs and NFRs for implementation terms
- 💾 Distinguish capability-relevant vs leakage
- 📖 Append findings to validation report
- 📖 Display "Proceeding to next check..." and load next step
- 🚫 FORBIDDEN to pause or request user input
## CONTEXT BOUNDARIES:
- Available context: PRD file, validation report
- Focus: Implementation leakage detection only
- Limits: Don't validate other aspects, don't pause for user input
- Dependencies: Steps 2-6 completed - initial validations done
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Attempt Sub-Process Validation
**Try to use Task tool to spawn a subprocess:**
"Perform implementation leakage validation on this PRD:
**Scan for:**
1. Technology names (React, Vue, Angular, PostgreSQL, MongoDB, AWS, GCP, Azure, Docker, Kubernetes, etc.)
2. Library names (Redux, axios, lodash, Express, Django, Rails, Spring, etc.)
3. Data structures (JSON, XML, CSV) unless relevant to capability
4. Architecture patterns (MVC, microservices, serverless) unless business requirement
5. Protocol names (HTTP, REST, GraphQL, WebSockets) - check if capability-relevant
**For each term found:**
- Is this capability-relevant? (e.g., 'API consumers can access...' - API is capability)
- Or is this implementation detail? (e.g., 'React component for...' - implementation)
Document violations with line numbers and explanation.
Return structured findings with leakage counts and examples."
### 2. Graceful Degradation (if Task tool unavailable)
If Task tool unavailable, perform analysis directly:
**Implementation leakage terms to scan for:**
**Frontend Frameworks:**
React, Vue, Angular, Svelte, Solid, Next.js, Nuxt, etc.
**Backend Frameworks:**
Express, Django, Rails, Spring, Laravel, FastAPI, etc.
**Databases:**
PostgreSQL, MySQL, MongoDB, Redis, DynamoDB, Cassandra, etc.
**Cloud Platforms:**
AWS, GCP, Azure, Cloudflare, Vercel, Netlify, etc.
**Infrastructure:**
Docker, Kubernetes, Terraform, Ansible, etc.
**Libraries:**
Redux, Zustand, axios, fetch, lodash, jQuery, etc.
**Data Formats:**
JSON, XML, YAML, CSV (unless capability-relevant)
**For each term found in FRs/NFRs:**
- Determine if it's capability-relevant or implementation leakage
- Example: "API consumers can access data via REST endpoints" - API/REST is capability
- Example: "React components fetch data using Redux" - implementation leakage
**Count violations and note line numbers**
### 3. Tally Implementation Leakage
**By category:**
- Frontend framework leakage: count
- Backend framework leakage: count
- Database leakage: count
- Cloud platform leakage: count
- Infrastructure leakage: count
- Library leakage: count
- Other implementation details: count
**Total implementation leakage violations:** sum
### 4. Report Implementation Leakage Findings to Validation Report
Append to validation report:
```markdown
## Implementation Leakage Validation
### Leakage by Category
**Frontend Frameworks:** {count} violations
{If violations, list examples with line numbers}
**Backend Frameworks:** {count} violations
{If violations, list examples with line numbers}
**Databases:** {count} violations
{If violations, list examples with line numbers}
**Cloud Platforms:** {count} violations
{If violations, list examples with line numbers}
**Infrastructure:** {count} violations
{If violations, list examples with line numbers}
**Libraries:** {count} violations
{If violations, list examples with line numbers}
**Other Implementation Details:** {count} violations
{If violations, list examples with line numbers}
### Summary
**Total Implementation Leakage Violations:** {total}
**Severity:** [Critical if >5 violations, Warning if 2-5, Pass if <2]
**Recommendation:**
[If Critical] "Extensive implementation leakage found. Requirements specify HOW instead of WHAT. Remove all implementation details - these belong in architecture, not PRD."
[If Warning] "Some implementation leakage detected. Review violations and remove implementation details from requirements."
[If Pass] "No significant implementation leakage found. Requirements properly specify WHAT without HOW."
**Note:** API consumers, GraphQL (when required), and other capability-relevant terms are acceptable when they describe WHAT the system must do, not HOW to build it.
```
### 5. Display Progress and Auto-Proceed
Display: "**Implementation Leakage Validation Complete**
Total Violations: {count} ({severity})
**Proceeding to next validation check...**"
Without delay, read fully and follow: {nextStepFile} (step-v-08-domain-compliance-validation.md)
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Scanned FRs and NFRs for all implementation term categories
- Distinguished capability-relevant from implementation leakage
- Violations documented with line numbers and explanations
- Severity assessed correctly
- Findings reported to validation report
- Auto-proceeds to next validation step
- Subprocess attempted with graceful degradation
### ❌ SYSTEM FAILURE:
- Not scanning all implementation term categories
- Not distinguishing capability-relevant from leakage
- Missing line numbers for violations
- Not reporting findings to validation report
- Not auto-proceeding
**Master Rule:** Requirements specify WHAT, not HOW. Implementation details belong in architecture documents, not PRDs.

View File

@ -1,243 +0,0 @@
---
name: 'step-v-08-domain-compliance-validation'
description: 'Domain Compliance Validation - Validate domain-specific requirements are present for high-complexity domains'
# File references (ONLY variables used in this step)
nextStepFile: './step-v-09-project-type-validation.md'
prdFile: '{prd_file_path}'
prdFrontmatter: '{prd_frontmatter}'
validationReportPath: '{validation_report_path}'
domainComplexityData: '../data/domain-complexity.csv'
---
# Step 8: Domain Compliance Validation
## STEP GOAL:
Validate domain-specific requirements are present for high-complexity domains (Healthcare, Fintech, GovTech, etc.), ensuring regulatory and compliance requirements are properly documented.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Validation Architect and Quality Assurance Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in systematic validation, not collaborative dialogue
- ✅ You bring domain expertise and compliance knowledge
- ✅ This step runs autonomously - no user input needed
### Step-Specific Rules:
- 🎯 Focus ONLY on domain-specific compliance requirements
- 🚫 FORBIDDEN to validate other aspects in this step
- 💬 Approach: Conditional validation based on domain classification
- 🚪 This is a validation sequence step - auto-proceeds when complete
## EXECUTION PROTOCOLS:
- 🎯 Check classification.domain from PRD frontmatter
- 💬 If low complexity (general): Skip detailed checks
- 🎯 If high complexity: Validate required special sections
- 💾 Append compliance findings to validation report
- 📖 Display "Proceeding to next check..." and load next step
- 🚫 FORBIDDEN to pause or request user input
## CONTEXT BOUNDARIES:
- Available context: PRD file with frontmatter classification, validation report
- Focus: Domain compliance only (conditional on domain complexity)
- Limits: Don't validate other aspects, conditional execution
- Dependencies: Steps 2-7 completed - format and requirements validation done
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Domain Complexity Data
Load and read the complete file at:
`{domainComplexityData}` (../data/domain-complexity.csv)
This CSV contains:
- Domain classifications and complexity levels (high/medium/low)
- Required special sections for each domain
- Key concerns and requirements for regulated industries
Internalize this data - it drives which domains require special compliance sections.
### 2. Extract Domain Classification
From PRD frontmatter, extract:
- `classification.domain` - what domain is this PRD for?
**If no domain classification found:**
Treat as "general" (low complexity) and proceed to step 4
### 2. Determine Domain Complexity
**Low complexity domains (skip detailed checks):**
- General
- Consumer apps (standard e-commerce, social, productivity)
- Content websites
- Business tools (standard)
**High complexity domains (require special sections):**
- Healthcare / Healthtech
- Fintech / Financial services
- GovTech / Public sector
- EdTech (educational records, accredited courses)
- Legal tech
- Other regulated domains
### 3. For High-Complexity Domains: Validate Required Special Sections
**Attempt subprocess validation:**
"Perform domain compliance validation for {domain}:
Based on {domain} requirements, check PRD for:
**Healthcare:**
- Clinical Requirements section
- Regulatory Pathway (FDA, HIPAA, etc.)
- Safety Measures
- HIPAA Compliance (data privacy, security)
- Patient safety considerations
**Fintech:**
- Compliance Matrix (SOC2, PCI-DSS, GDPR, etc.)
- Security Architecture
- Audit Requirements
- Fraud Prevention measures
- Financial transaction handling
**GovTech:**
- Accessibility Standards (WCAG 2.1 AA, Section 508)
- Procurement Compliance
- Security Clearance requirements
- Data residency requirements
**Other regulated domains:**
- Check for domain-specific regulatory sections
- Compliance requirements
- Special considerations
For each required section:
- Is it present in PRD?
- Is it adequately documented?
- Note any gaps
Return compliance matrix with presence/adequacy assessment."
**Graceful degradation (if no Task tool):**
- Manually check for required sections based on domain
- List present sections and missing sections
- Assess adequacy of documentation
### 5. For Low-Complexity Domains: Skip Detailed Checks
Append to validation report:
```markdown
## Domain Compliance Validation
**Domain:** {domain}
**Complexity:** Low (general/standard)
**Assessment:** N/A - No special domain compliance requirements
**Note:** This PRD is for a standard domain without regulatory compliance requirements.
```
Display: "**Domain Compliance Validation Skipped**
Domain: {domain} (low complexity)
**Proceeding to next validation check...**"
Without delay, read fully and follow: {nextStepFile}
### 6. Report Compliance Findings (High-Complexity Domains)
Append to validation report:
```markdown
## Domain Compliance Validation
**Domain:** {domain}
**Complexity:** High (regulated)
### Required Special Sections
**{Section 1 Name}:** [Present/Missing/Adequate]
{If missing or inadequate: Note specific gaps}
**{Section 2 Name}:** [Present/Missing/Adequate]
{If missing or inadequate: Note specific gaps}
[Continue for all required sections]
### Compliance Matrix
| Requirement | Status | Notes |
|-------------|--------|-------|
| {Requirement 1} | [Met/Partial/Missing] | {Notes} |
| {Requirement 2} | [Met/Partial/Missing] | {Notes} |
[... continue for all requirements]
### Summary
**Required Sections Present:** {count}/{total}
**Compliance Gaps:** {count}
**Severity:** [Critical if missing regulatory sections, Warning if incomplete, Pass if complete]
**Recommendation:**
[If Critical] "PRD is missing required domain-specific compliance sections. These are essential for {domain} products."
[If Warning] "Some domain compliance sections are incomplete. Strengthen documentation for full compliance."
[If Pass] "All required domain compliance sections are present and adequately documented."
```
### 7. Display Progress and Auto-Proceed
Display: "**Domain Compliance Validation Complete**
Domain: {domain} ({complexity})
Compliance Status: {status}
**Proceeding to next validation check...**"
Without delay, read fully and follow: {nextStepFile} (step-v-09-project-type-validation.md)
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Domain classification extracted correctly
- Complexity assessed appropriately
- Low complexity domains: Skipped with clear "N/A" documentation
- High complexity domains: All required sections checked
- Compliance matrix built with status for each requirement
- Severity assessed correctly
- Findings reported to validation report
- Auto-proceeds to next validation step
- Subprocess attempted with graceful degradation
### ❌ SYSTEM FAILURE:
- Not checking domain classification before proceeding
- Performing detailed checks on low complexity domains
- For high complexity: missing required section checks
- Not building compliance matrix
- Not reporting findings to validation report
- Not auto-proceeding
**Master Rule:** Domain compliance is conditional. High-complexity domains require special sections - low complexity domains skip these checks.

View File

@ -1,263 +0,0 @@
---
name: 'step-v-09-project-type-validation'
description: 'Project-Type Compliance Validation - Validate project-type specific requirements are properly documented'
# File references (ONLY variables used in this step)
nextStepFile: './step-v-10-smart-validation.md'
prdFile: '{prd_file_path}'
prdFrontmatter: '{prd_frontmatter}'
validationReportPath: '{validation_report_path}'
projectTypesData: '../data/project-types.csv'
---
# Step 9: Project-Type Compliance Validation
## STEP GOAL:
Validate project-type specific requirements are properly documented - different project types (api_backend, web_app, mobile_app, etc.) have different required and excluded sections.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Validation Architect and Quality Assurance Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in systematic validation, not collaborative dialogue
- ✅ You bring project type expertise and architectural knowledge
- ✅ This step runs autonomously - no user input needed
### Step-Specific Rules:
- 🎯 Focus ONLY on project-type compliance
- 🚫 FORBIDDEN to validate other aspects in this step
- 💬 Approach: Validate required sections present, excluded sections absent
- 🚪 This is a validation sequence step - auto-proceeds when complete
## EXECUTION PROTOCOLS:
- 🎯 Check classification.projectType from PRD frontmatter
- 🎯 Validate required sections for that project type are present
- 🎯 Validate excluded sections for that project type are absent
- 💾 Append compliance findings to validation report
- 📖 Display "Proceeding to next check..." and load next step
- 🚫 FORBIDDEN to pause or request user input
## CONTEXT BOUNDARIES:
- Available context: PRD file with frontmatter classification, validation report
- Focus: Project-type compliance only
- Limits: Don't validate other aspects, don't pause for user input
- Dependencies: Steps 2-8 completed - domain and requirements validation done
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Project Types Data
Load and read the complete file at:
`{projectTypesData}` (../data/project-types.csv)
This CSV contains:
- Detection signals for each project type
- Required sections for each project type
- Skip/excluded sections for each project type
- Innovation signals
Internalize this data - it drives what sections must be present or absent for each project type.
### 2. Extract Project Type Classification
From PRD frontmatter, extract:
- `classification.projectType` - what type of project is this?
**Common project types:**
- api_backend
- web_app
- mobile_app
- desktop_app
- data_pipeline
- ml_system
- library_sdk
- infrastructure
- other
**If no projectType classification found:**
Assume "web_app" (most common) and note in findings
### 3. Determine Required and Excluded Sections from CSV Data
**From loaded project-types.csv data, for this project type:**
**Required sections:** (from required_sections column)
These MUST be present in the PRD
**Skip sections:** (from skip_sections column)
These MUST NOT be present in the PRD
**Example mappings from CSV:**
- api_backend: Required=[endpoint_specs, auth_model, data_schemas], Skip=[ux_ui, visual_design]
- mobile_app: Required=[platform_reqs, device_permissions, offline_mode], Skip=[desktop_features, cli_commands]
- cli_tool: Required=[command_structure, output_formats, config_schema], Skip=[visual_design, ux_principles, touch_interactions]
- etc.
### 4. Validate Against CSV-Based Requirements
**Based on project type, determine:**
**api_backend:**
- Required: Endpoint Specs, Auth Model, Data Schemas, API Versioning
- Excluded: UX/UI sections, mobile-specific sections
**web_app:**
- Required: User Journeys, UX/UI Requirements, Responsive Design
- Excluded: None typically
**mobile_app:**
- Required: Mobile UX, Platform specifics (iOS/Android), Offline mode
- Excluded: Desktop-specific sections
**desktop_app:**
- Required: Desktop UX, Platform specifics (Windows/Mac/Linux)
- Excluded: Mobile-specific sections
**data_pipeline:**
- Required: Data Sources, Data Transformation, Data Sinks, Error Handling
- Excluded: UX/UI sections
**ml_system:**
- Required: Model Requirements, Training Data, Inference Requirements, Model Performance
- Excluded: UX/UI sections (unless ML UI)
**library_sdk:**
- Required: API Surface, Usage Examples, Integration Guide
- Excluded: UX/UI sections, deployment sections
**infrastructure:**
- Required: Infrastructure Components, Deployment, Monitoring, Scaling
- Excluded: Feature requirements (this is infrastructure, not product)
### 4. Attempt Sub-Process Validation
"Perform project-type compliance validation for {projectType}:
**Check that required sections are present:**
{List required sections for this project type}
For each: Is it present in PRD? Is it adequately documented?
**Check that excluded sections are absent:**
{List excluded sections for this project type}
For each: Is it absent from PRD? (Should not be present)
Build compliance table showing:
- Required sections: [Present/Missing/Incomplete]
- Excluded sections: [Absent/Present] (Present = violation)
Return compliance table with findings."
**Graceful degradation (if no Task tool):**
- Manually check PRD for required sections
- Manually check PRD for excluded sections
- Build compliance table
### 5. Build Compliance Table
**Required sections check:**
- For each required section: Present / Missing / Incomplete
- Count: Required sections present vs total required
**Excluded sections check:**
- For each excluded section: Absent / Present (violation)
- Count: Excluded sections present (violations)
**Total compliance score:**
- Required: {present}/{total}
- Excluded violations: {count}
### 6. Report Project-Type Compliance Findings to Validation Report
Append to validation report:
```markdown
## Project-Type Compliance Validation
**Project Type:** {projectType}
### Required Sections
**{Section 1}:** [Present/Missing/Incomplete]
{If missing or incomplete: Note specific gaps}
**{Section 2}:** [Present/Missing/Incomplete]
{If missing or incomplete: Note specific gaps}
[Continue for all required sections]
### Excluded Sections (Should Not Be Present)
**{Section 1}:** [Absent/Present] ✓
{If present: This section should not be present for {projectType}}
**{Section 2}:** [Absent/Present] ✓
{If present: This section should not be present for {projectType}}
[Continue for all excluded sections]
### Compliance Summary
**Required Sections:** {present}/{total} present
**Excluded Sections Present:** {violations} (should be 0)
**Compliance Score:** {percentage}%
**Severity:** [Critical if required sections missing, Warning if incomplete, Pass if complete]
**Recommendation:**
[If Critical] "PRD is missing required sections for {projectType}. Add missing sections to properly specify this type of project."
[If Warning] "Some required sections for {projectType} are incomplete. Strengthen documentation."
[If Pass] "All required sections for {projectType} are present. No excluded sections found."
```
### 7. Display Progress and Auto-Proceed
Display: "**Project-Type Compliance Validation Complete**
Project Type: {projectType}
Compliance: {score}%
**Proceeding to next validation check...**"
Without delay, read fully and follow: {nextStepFile} (step-v-10-smart-validation.md)
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Project type extracted correctly (or default assumed)
- Required sections validated for presence and completeness
- Excluded sections validated for absence
- Compliance table built with status for all sections
- Severity assessed correctly
- Findings reported to validation report
- Auto-proceeds to next validation step
- Subprocess attempted with graceful degradation
### ❌ SYSTEM FAILURE:
- Not checking project type before proceeding
- Missing required section checks
- Missing excluded section checks
- Not building compliance table
- Not reporting findings to validation report
- Not auto-proceeding
**Master Rule:** Different project types have different requirements. API PRDs don't need UX sections - validate accordingly.

View File

@ -1,209 +0,0 @@
---
name: 'step-v-10-smart-validation'
description: 'SMART Requirements Validation - Validate Functional Requirements meet SMART quality criteria'
# File references (ONLY variables used in this step)
nextStepFile: './step-v-11-holistic-quality-validation.md'
prdFile: '{prd_file_path}'
validationReportPath: '{validation_report_path}'
---
# Step 10: SMART Requirements Validation
## STEP GOAL:
Validate Functional Requirements meet SMART quality criteria (Specific, Measurable, Attainable, Relevant, Traceable), ensuring high-quality requirements.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
### Role Reinforcement:
- ✅ You are a Validation Architect and Quality Assurance Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in systematic validation, not collaborative dialogue
- ✅ You bring requirements engineering expertise and quality assessment
- ✅ This step runs autonomously - no user input needed
### Step-Specific Rules:
- 🎯 Focus ONLY on FR quality assessment using SMART framework
- 🚫 FORBIDDEN to validate other aspects in this step
- 💬 Approach: Score each FR on SMART criteria (1-5 scale)
- 🚪 This is a validation sequence step - auto-proceeds when complete
## EXECUTION PROTOCOLS:
- 🎯 Extract all FRs from PRD
- 🎯 Score each FR on SMART criteria (Specific, Measurable, Attainable, Relevant, Traceable)
- 💾 Flag FRs with score < 3 in any category
- 📖 Append scoring table and suggestions to validation report
- 📖 Display "Proceeding to next check..." and load next step
- 🚫 FORBIDDEN to pause or request user input
## CONTEXT BOUNDARIES:
- Available context: PRD file, validation report
- Focus: FR quality assessment only using SMART framework
- Limits: Don't validate NFRs or other aspects, don't pause for user input
- Dependencies: Steps 2-9 completed - comprehensive validation checks done
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Extract All Functional Requirements
From the PRD's Functional Requirements section, extract:
- All FRs with their FR numbers (FR-001, FR-002, etc.)
- Count total FRs
### 2. Attempt Sub-Process Validation
**Try to use Task tool to spawn a subprocess:**
"Perform SMART requirements validation on these Functional Requirements:
{List all FRs}
**For each FR, score on SMART criteria (1-5 scale):**
**Specific (1-5):**
- 5: Clear, unambiguous, well-defined
- 3: Somewhat clear but could be more specific
- 1: Vague, ambiguous, unclear
**Measurable (1-5):**
- 5: Quantifiable metrics, testable
- 3: Partially measurable
- 1: Not measurable, subjective
**Attainable (1-5):**
- 5: Realistic, achievable with constraints
- 3: Probably achievable but uncertain
- 1: Unrealistic, technically infeasible
**Relevant (1-5):**
- 5: Clearly aligned with user needs and business objectives
- 3: Somewhat relevant but connection unclear
- 1: Not relevant, doesn't align with goals
**Traceable (1-5):**
- 5: Clearly traces to user journey or business objective
- 3: Partially traceable
- 1: Orphan requirement, no clear source
**For each FR with score < 3 in any category:**
- Provide specific improvement suggestions
Return scoring table with all FR scores and improvement suggestions for low-scoring FRs."
**Graceful degradation (if no Task tool):**
- Manually score each FR on SMART criteria
- Note FRs with low scores
- Provide improvement suggestions
### 3. Build Scoring Table
For each FR:
- FR number
- Specific score (1-5)
- Measurable score (1-5)
- Attainable score (1-5)
- Relevant score (1-5)
- Traceable score (1-5)
- Average score
- Flag if any category < 3
**Calculate overall FR quality:**
- Percentage of FRs with all scores ≥ 3
- Percentage of FRs with all scores ≥ 4
- Average score across all FRs and categories
### 4. Report SMART Findings to Validation Report
Append to validation report:
```markdown
## SMART Requirements Validation
**Total Functional Requirements:** {count}
### Scoring Summary
**All scores ≥ 3:** {percentage}% ({count}/{total})
**All scores ≥ 4:** {percentage}% ({count}/{total})
**Overall Average Score:** {average}/5.0
### Scoring Table
| FR # | Specific | Measurable | Attainable | Relevant | Traceable | Average | Flag |
|------|----------|------------|------------|----------|-----------|--------|------|
| FR-001 | {s1} | {m1} | {a1} | {r1} | {t1} | {avg1} | {X if any <3} |
| FR-002 | {s2} | {m2} | {a2} | {r2} | {t2} | {avg2} | {X if any <3} |
[Continue for all FRs]
**Legend:** 1=Poor, 3=Acceptable, 5=Excellent
**Flag:** X = Score < 3 in one or more categories
### Improvement Suggestions
**Low-Scoring FRs:**
**FR-{number}:** {specific suggestion for improvement}
[For each FR with score < 3 in any category]
### Overall Assessment
**Severity:** [Critical if >30% flagged FRs, Warning if 10-30%, Pass if <10%]
**Recommendation:**
[If Critical] "Many FRs have quality issues. Revise flagged FRs using SMART framework to improve clarity and testability."
[If Warning] "Some FRs would benefit from SMART refinement. Focus on flagged requirements above."
[If Pass] "Functional Requirements demonstrate good SMART quality overall."
```
### 5. Display Progress and Auto-Proceed
Display: "**SMART Requirements Validation Complete**
FR Quality: {percentage}% with acceptable scores ({severity})
**Proceeding to next validation check...**"
Without delay, read fully and follow: {nextStepFile} (step-v-11-holistic-quality-validation.md)
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All FRs extracted from PRD
- Each FR scored on all 5 SMART criteria (1-5 scale)
- FRs with scores < 3 flagged for improvement
- Improvement suggestions provided for low-scoring FRs
- Scoring table built with all FR scores
- Overall quality assessment calculated
- Findings reported to validation report
- Auto-proceeds to next validation step
- Subprocess attempted with graceful degradation
### ❌ SYSTEM FAILURE:
- Not scoring all FRs on all SMART criteria
- Missing improvement suggestions for low-scoring FRs
- Not building scoring table
- Not calculating overall quality metrics
- Not reporting findings to validation report
- Not auto-proceeding
**Master Rule:** FRs should be high-quality, not just present. SMART framework provides objective quality measure.

View File

@ -1,264 +0,0 @@
---
name: 'step-v-11-holistic-quality-validation'
description: 'Holistic Quality Assessment - Assess PRD as cohesive, compelling document - is it a good PRD?'
# File references (ONLY variables used in this step)
nextStepFile: './step-v-12-completeness-validation.md'
prdFile: '{prd_file_path}'
validationReportPath: '{validation_report_path}'
---
# Step 11: Holistic Quality Assessment
## STEP GOAL:
Assess the PRD as a cohesive, compelling document - evaluating document flow, dual audience effectiveness (humans and LLMs), BMAD PRD principles compliance, and overall quality rating.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
### Role Reinforcement:
- ✅ You are a Validation Architect and Quality Assurance Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in systematic validation, not collaborative dialogue
- ✅ You bring analytical rigor and document quality expertise
- ✅ This step runs autonomously - no user input needed
- ✅ Uses Advanced Elicitation for multi-perspective evaluation
### Step-Specific Rules:
- 🎯 Focus ONLY on holistic document quality assessment
- 🚫 FORBIDDEN to validate individual components (done in previous steps)
- 💬 Approach: Multi-perspective evaluation using Advanced Elicitation
- 🚪 This is a validation sequence step - auto-proceeds when complete
## EXECUTION PROTOCOLS:
- 🎯 Use Advanced Elicitation for multi-perspective assessment
- 🎯 Evaluate document flow, dual audience, BMAD principles
- 💾 Append comprehensive assessment to validation report
- 📖 Display "Proceeding to next check..." and load next step
- 🚫 FORBIDDEN to pause or request user input
## CONTEXT BOUNDARIES:
- Available context: Complete PRD file, validation report with findings from steps 1-10
- Focus: Holistic quality - the WHOLE document
- Limits: Don't re-validate individual components, don't pause for user input
- Dependencies: Steps 1-10 completed - all systematic checks done
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Attempt Sub-Process with Advanced Elicitation
**Try to use Task tool to spawn a subprocess using Advanced Elicitation:**
"Perform holistic quality assessment on this PRD using multi-perspective evaluation:
**Advanced Elicitation workflow:**
Invoke the `bmad-advanced-elicitation` skill
**Evaluate the PRD from these perspectives:**
**1. Document Flow & Coherence:**
- Read entire PRD
- Evaluate narrative flow - does it tell a cohesive story?
- Check transitions between sections
- Assess consistency - is it coherent throughout?
- Evaluate readability - is it clear and well-organized?
**2. Dual Audience Effectiveness:**
**For Humans:**
- Executive-friendly: Can executives understand vision and goals quickly?
- Developer clarity: Do developers have clear requirements to build from?
- Designer clarity: Do designers understand user needs and flows?
- Stakeholder decision-making: Can stakeholders make informed decisions?
**For LLMs:**
- Machine-readable structure: Is the PRD structured for LLM consumption?
- UX readiness: Can an LLM generate UX designs from this?
- Architecture readiness: Can an LLM generate architecture from this?
- Epic/Story readiness: Can an LLM break down into epics and stories?
**3. BMAD PRD Principles Compliance:**
- Information density: Every sentence carries weight?
- Measurability: Requirements testable?
- Traceability: Requirements trace to sources?
- Domain awareness: Domain-specific considerations included?
- Zero anti-patterns: No filler or wordiness?
- Dual audience: Works for both humans and LLMs?
- Markdown format: Proper structure and formatting?
**4. Overall Quality Rating:**
Rate the PRD on 5-point scale:
- Excellent (5/5): Exemplary, ready for production use
- Good (4/5): Strong with minor improvements needed
- Adequate (3/5): Acceptable but needs refinement
- Needs Work (2/5): Significant gaps or issues
- Problematic (1/5): Major flaws, needs substantial revision
**5. Top 3 Improvements:**
Identify the 3 most impactful improvements to make this a great PRD
Return comprehensive assessment with all perspectives, rating, and top 3 improvements."
**Graceful degradation (if no Task tool or Advanced Elicitation unavailable):**
- Perform holistic assessment directly in current context
- Read complete PRD
- Evaluate document flow, coherence, transitions
- Assess dual audience effectiveness
- Check BMAD principles compliance
- Assign overall quality rating
- Identify top 3 improvements
### 2. Synthesize Assessment
**Compile findings from multi-perspective evaluation:**
**Document Flow & Coherence:**
- Overall assessment: [Excellent/Good/Adequate/Needs Work/Problematic]
- Key strengths: [list]
- Key weaknesses: [list]
**Dual Audience Effectiveness:**
- For Humans: [assessment]
- For LLMs: [assessment]
- Overall dual audience score: [1-5]
**BMAD Principles Compliance:**
- Principles met: [count]/7
- Principles with issues: [list]
**Overall Quality Rating:** [1-5 with label]
**Top 3 Improvements:**
1. [Improvement 1]
2. [Improvement 2]
3. [Improvement 3]
### 3. Report Holistic Quality Findings to Validation Report
Append to validation report:
```markdown
## Holistic Quality Assessment
### Document Flow & Coherence
**Assessment:** [Excellent/Good/Adequate/Needs Work/Problematic]
**Strengths:**
{List key strengths}
**Areas for Improvement:**
{List key weaknesses}
### Dual Audience Effectiveness
**For Humans:**
- Executive-friendly: [assessment]
- Developer clarity: [assessment]
- Designer clarity: [assessment]
- Stakeholder decision-making: [assessment]
**For LLMs:**
- Machine-readable structure: [assessment]
- UX readiness: [assessment]
- Architecture readiness: [assessment]
- Epic/Story readiness: [assessment]
**Dual Audience Score:** {score}/5
### BMAD PRD Principles Compliance
| Principle | Status | Notes |
|-----------|--------|-------|
| Information Density | [Met/Partial/Not Met] | {notes} |
| Measurability | [Met/Partial/Not Met] | {notes} |
| Traceability | [Met/Partial/Not Met] | {notes} |
| Domain Awareness | [Met/Partial/Not Met] | {notes} |
| Zero Anti-Patterns | [Met/Partial/Not Met] | {notes} |
| Dual Audience | [Met/Partial/Not Met] | {notes} |
| Markdown Format | [Met/Partial/Not Met] | {notes} |
**Principles Met:** {count}/7
### Overall Quality Rating
**Rating:** {rating}/5 - {label}
**Scale:**
- 5/5 - Excellent: Exemplary, ready for production use
- 4/5 - Good: Strong with minor improvements needed
- 3/5 - Adequate: Acceptable but needs refinement
- 2/5 - Needs Work: Significant gaps or issues
- 1/5 - Problematic: Major flaws, needs substantial revision
### Top 3 Improvements
1. **{Improvement 1}**
{Brief explanation of why and how}
2. **{Improvement 2}**
{Brief explanation of why and how}
3. **{Improvement 3}**
{Brief explanation of why and how}
### Summary
**This PRD is:** {one-sentence overall assessment}
**To make it great:** Focus on the top 3 improvements above.
```
### 4. Display Progress and Auto-Proceed
Display: "**Holistic Quality Assessment Complete**
Overall Rating: {rating}/5 - {label}
**Proceeding to final validation checks...**"
Without delay, read fully and follow: {nextStepFile} (step-v-12-completeness-validation.md)
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Advanced Elicitation used for multi-perspective evaluation (or graceful degradation)
- Document flow & coherence assessed
- Dual audience effectiveness evaluated (humans and LLMs)
- BMAD PRD principles compliance checked
- Overall quality rating assigned (1-5 scale)
- Top 3 improvements identified
- Comprehensive assessment reported to validation report
- Auto-proceeds to next validation step
- Subprocess attempted with graceful degradation
### ❌ SYSTEM FAILURE:
- Not using Advanced Elicitation for multi-perspective evaluation
- Missing document flow assessment
- Missing dual audience evaluation
- Not checking all BMAD principles
- Not assigning overall quality rating
- Missing top 3 improvements
- Not reporting comprehensive assessment to validation report
- Not auto-proceeding
**Master Rule:** This evaluates the WHOLE document, not just components. Answers "Is this a good PRD?" and "What would make it great?"

View File

@ -1,242 +0,0 @@
---
name: 'step-v-12-completeness-validation'
description: 'Completeness Check - Final comprehensive completeness check before report generation'
# File references (ONLY variables used in this step)
nextStepFile: './step-v-13-report-complete.md'
prdFile: '{prd_file_path}'
prdFrontmatter: '{prd_frontmatter}'
validationReportPath: '{validation_report_path}'
---
# Step 12: Completeness Validation
## STEP GOAL:
Final comprehensive completeness check - validate no template variables remain, each section has required content, section-specific completeness, and frontmatter is properly populated.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Validation Architect and Quality Assurance Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in systematic validation, not collaborative dialogue
- ✅ You bring attention to detail and completeness verification
- ✅ This step runs autonomously - no user input needed
### Step-Specific Rules:
- 🎯 Focus ONLY on completeness verification
- 🚫 FORBIDDEN to validate quality (done in step 11) or other aspects
- 💬 Approach: Systematic checklist-style verification
- 🚪 This is a validation sequence step - auto-proceeds when complete
## EXECUTION PROTOCOLS:
- 🎯 Check template completeness (no variables remaining)
- 🎯 Validate content completeness (each section has required content)
- 🎯 Validate section-specific completeness
- 🎯 Validate frontmatter completeness
- 💾 Append completeness matrix to validation report
- 📖 Display "Proceeding to final step..." and load next step
- 🚫 FORBIDDEN to pause or request user input
## CONTEXT BOUNDARIES:
- Available context: Complete PRD file, frontmatter, validation report
- Focus: Completeness verification only (final gate)
- Limits: Don't assess quality, don't pause for user input
- Dependencies: Steps 1-11 completed - all validation checks done
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Attempt Sub-Process Validation
**Try to use Task tool to spawn a subprocess:**
"Perform completeness validation on this PRD - final gate check:
**1. Template Completeness:**
- Scan PRD for any remaining template variables
- Look for: {variable}, {{variable}}, {placeholder}, [placeholder], etc.
- List any found with line numbers
**2. Content Completeness:**
- Executive Summary: Has vision statement? ({key content})
- Success Criteria: All criteria measurable? ({metrics present})
- Product Scope: In-scope and out-of-scope defined? ({both present})
- User Journeys: User types identified? ({users listed})
- Functional Requirements: FRs listed with proper format? ({FRs present})
- Non-Functional Requirements: NFRs with metrics? ({NFRs present})
For each section: Is required content present? (Yes/No/Partial)
**3. Section-Specific Completeness:**
- Success Criteria: Each has specific measurement method?
- User Journeys: Cover all user types?
- Functional Requirements: Cover MVP scope?
- Non-Functional Requirements: Each has specific criteria?
**4. Frontmatter Completeness:**
- stepsCompleted: Populated?
- classification: Present (domain, projectType)?
- inputDocuments: Tracked?
- date: Present?
Return completeness matrix with status for each check."
**Graceful degradation (if no Task tool):**
- Manually scan for template variables
- Manually check each section for required content
- Manually verify frontmatter fields
- Build completeness matrix
### 2. Build Completeness Matrix
**Template Completeness:**
- Template variables found: count
- List if any found
**Content Completeness by Section:**
- Executive Summary: Complete / Incomplete / Missing
- Success Criteria: Complete / Incomplete / Missing
- Product Scope: Complete / Incomplete / Missing
- User Journeys: Complete / Incomplete / Missing
- Functional Requirements: Complete / Incomplete / Missing
- Non-Functional Requirements: Complete / Incomplete / Missing
- Other sections: [List completeness]
**Section-Specific Completeness:**
- Success criteria measurable: All / Some / None
- Journeys cover all users: Yes / Partial / No
- FRs cover MVP scope: Yes / Partial / No
- NFRs have specific criteria: All / Some / None
**Frontmatter Completeness:**
- stepsCompleted: Present / Missing
- classification: Present / Missing
- inputDocuments: Present / Missing
- date: Present / Missing
**Overall completeness:**
- Sections complete: X/Y
- Critical gaps: [list if any]
### 3. Report Completeness Findings to Validation Report
Append to validation report:
```markdown
## Completeness Validation
### Template Completeness
**Template Variables Found:** {count}
{If count > 0, list variables with line numbers}
{If count = 0, note: No template variables remaining ✓}
### Content Completeness by Section
**Executive Summary:** [Complete/Incomplete/Missing]
{If incomplete or missing, note specific gaps}
**Success Criteria:** [Complete/Incomplete/Missing]
{If incomplete or missing, note specific gaps}
**Product Scope:** [Complete/Incomplete/Missing]
{If incomplete or missing, note specific gaps}
**User Journeys:** [Complete/Incomplete/Missing]
{If incomplete or missing, note specific gaps}
**Functional Requirements:** [Complete/Incomplete/Missing]
{If incomplete or missing, note specific gaps}
**Non-Functional Requirements:** [Complete/Incomplete/Missing]
{If incomplete or missing, note specific gaps}
### Section-Specific Completeness
**Success Criteria Measurability:** [All/Some/None] measurable
{If Some or None, note which criteria lack metrics}
**User Journeys Coverage:** [Yes/Partial/No] - covers all user types
{If Partial or No, note missing user types}
**FRs Cover MVP Scope:** [Yes/Partial/No]
{If Partial or No, note scope gaps}
**NFRs Have Specific Criteria:** [All/Some/None]
{If Some or None, note which NFRs lack specificity}
### Frontmatter Completeness
**stepsCompleted:** [Present/Missing]
**classification:** [Present/Missing]
**inputDocuments:** [Present/Missing]
**date:** [Present/Missing]
**Frontmatter Completeness:** {complete_fields}/4
### Completeness Summary
**Overall Completeness:** {percentage}% ({complete_sections}/{total_sections})
**Critical Gaps:** [count] [list if any]
**Minor Gaps:** [count] [list if any]
**Severity:** [Critical if template variables exist or critical sections missing, Warning if minor gaps, Pass if complete]
**Recommendation:**
[If Critical] "PRD has completeness gaps that must be addressed before use. Fix template variables and complete missing sections."
[If Warning] "PRD has minor completeness gaps. Address minor gaps for complete documentation."
[If Pass] "PRD is complete with all required sections and content present."
```
### 4. Display Progress and Auto-Proceed
Display: "**Completeness Validation Complete**
Overall Completeness: {percentage}% ({severity})
**Proceeding to final step...**"
Without delay, read fully and follow: {nextStepFile} (step-v-13-report-complete.md)
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Scanned for template variables systematically
- Validated each section for required content
- Validated section-specific completeness (measurability, coverage, scope)
- Validated frontmatter completeness
- Completeness matrix built with all checks
- Severity assessed correctly
- Findings reported to validation report
- Auto-proceeds to final step
- Subprocess attempted with graceful degradation
### ❌ SYSTEM FAILURE:
- Not scanning for template variables
- Missing section-specific completeness checks
- Not validating frontmatter
- Not building completeness matrix
- Not reporting findings to validation report
- Not auto-proceeding
**Master Rule:** Final gate to ensure document is complete before presenting findings. Template variables or critical gaps must be fixed.

View File

@ -1,232 +0,0 @@
---
name: 'step-v-13-report-complete'
description: 'Validation Report Complete - Finalize report, summarize findings, present to user, offer next steps'
# File references (ONLY variables used in this step)
validationReportPath: '{validation_report_path}'
prdFile: '{prd_file_path}'
---
# Step 13: Validation Report Complete
## STEP GOAL:
Finalize validation report, summarize all findings from steps 1-12, present summary to user conversationally, and offer actionable next steps.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
### Role Reinforcement:
- ✅ You are a Validation Architect and Quality Assurance Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring synthesis and summary expertise
- ✅ This is the FINAL step - requires user interaction
### Step-Specific Rules:
- 🎯 Focus ONLY on summarizing findings and presenting options
- 🚫 FORBIDDEN to perform additional validation
- 💬 Approach: Conversational summary with clear next steps
- 🚪 This is the final step - no next step after this
## EXECUTION PROTOCOLS:
- 🎯 Load complete validation report
- 🎯 Summarize all findings from steps 1-12
- 🎯 Update report frontmatter with final status
- 💬 Present summary to user conversationally
- 💬 Offer menu options for next actions
- 🚫 FORBIDDEN to proceed without user selection
## CONTEXT BOUNDARIES:
- Available context: Complete validation report with findings from all validation steps
- Focus: Summary and presentation only (no new validation)
- Limits: Don't add new findings, just synthesize existing
- Dependencies: Steps 1-12 completed - all validation checks done
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Complete Validation Report
Read the entire validation report from {validationReportPath}
Extract all findings from:
- Format Detection (Step 2)
- Parity Analysis (Step 2B, if applicable)
- Information Density (Step 3)
- Product Brief Coverage (Step 4)
- Measurability (Step 5)
- Traceability (Step 6)
- Implementation Leakage (Step 7)
- Domain Compliance (Step 8)
- Project-Type Compliance (Step 9)
- SMART Requirements (Step 10)
- Holistic Quality (Step 11)
- Completeness (Step 12)
### 2. Update Report Frontmatter with Final Status
Update validation report frontmatter:
```yaml
---
validationTarget: '{prd_path}'
validationDate: '{current_date}'
inputDocuments: [list of documents]
validationStepsCompleted: ['step-v-01-discovery', 'step-v-02-format-detection', 'step-v-03-density-validation', 'step-v-04-brief-coverage-validation', 'step-v-05-measurability-validation', 'step-v-06-traceability-validation', 'step-v-07-implementation-leakage-validation', 'step-v-08-domain-compliance-validation', 'step-v-09-project-type-validation', 'step-v-10-smart-validation', 'step-v-11-holistic-quality-validation', 'step-v-12-completeness-validation']
validationStatus: COMPLETE
holisticQualityRating: '{rating from step 11}'
overallStatus: '{Pass/Warning/Critical based on all findings}'
---
```
### 3. Create Summary of Findings
**Overall Status:**
- Determine from all validation findings
- **Pass:** All critical checks pass, minor warnings acceptable
- **Warning:** Some issues found but PRD is usable
- **Critical:** Major issues that prevent PRD from being fit for purpose
**Quick Results Table:**
- Format: [classification]
- Information Density: [severity]
- Measurability: [severity]
- Traceability: [severity]
- Implementation Leakage: [severity]
- Domain Compliance: [status]
- Project-Type Compliance: [compliance score]
- SMART Quality: [percentage]
- Holistic Quality: [rating/5]
- Completeness: [percentage]
**Critical Issues:** List from all validation steps
**Warnings:** List from all validation steps
**Strengths:** List positives from all validation steps
**Holistic Quality Rating:** From step 11
**Top 3 Improvements:** From step 11
**Recommendation:** Based on overall status
### 4. Present Summary to User Conversationally
Display:
"**✓ PRD Validation Complete**
**Overall Status:** {Pass/Warning/Critical}
**Quick Results:**
{Present quick results table with key findings}
**Critical Issues:** {count or "None"}
{If any, list briefly}
**Warnings:** {count or "None"}
{If any, list briefly}
**Strengths:**
{List key strengths}
**Holistic Quality:** {rating}/5 - {label}
**Top 3 Improvements:**
1. {Improvement 1}
2. {Improvement 2}
3. {Improvement 3}
**Recommendation:**
{Based on overall status:
- Pass: "PRD is in good shape. Address minor improvements to make it great."
- Warning: "PRD is usable but has issues that should be addressed. Review warnings and improve where needed."
- Critical: "PRD has significant issues that should be fixed before use. Focus on critical issues above."}
**What would you like to do next?**"
### 5. Present MENU OPTIONS
Display:
**[R] Review Detailed Findings** - Walk through validation report section by section
**[E] Use Edit Workflow** - Use validation report with Edit workflow for systematic improvements
**[F] Fix Simpler Items** - Immediate fixes for simple issues (anti-patterns, leakage, missing headers)
**[X] Exit** - Exit and Suggest Next Steps.
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- Only proceed based on user selection
#### Menu Handling Logic:
- **IF R (Review Detailed Findings):**
- Walk through validation report section by section
- Present findings from each validation step
- Allow user to ask questions
- After review, return to menu
- **IF E (Use Edit Workflow):**
- Explain: "The Edit workflow (steps-e/) can use this validation report to systematically address issues. Edit mode will guide you through discovering what to edit, reviewing the PRD, and applying targeted improvements."
- Offer: "Would you like to launch Edit mode now? It will help you fix validation findings systematically."
- If yes: Read fully and follow: `./steps-e/step-e-01-discovery.md`
- If no: Return to menu
- **IF F (Fix Simpler Items):**
- Offer immediate fixes for:
- Template variables (fill in with appropriate content)
- Conversational filler (remove wordy phrases)
- Implementation leakage (remove technology names from FRs/NFRs)
- Missing section headers (add ## headers)
- Ask: "Which simple fixes would you like me to make?"
- If user specifies fixes, make them and update validation report
- Return to menu
- **IF X (Exit):**
- Display: "**Validation Report Saved:** {validationReportPath}"
- Display: "**Summary:** {overall status} - {recommendation}"
- PRD Validation complete. Invoke the `bmad-help` skill.
- **IF Any other:** Help user, then redisplay menu
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Complete validation report loaded successfully
- All findings from steps 1-12 summarized
- Report frontmatter updated with final status
- Overall status determined correctly (Pass/Warning/Critical)
- Quick results table presented
- Critical issues, warnings, and strengths listed
- Holistic quality rating included
- Top 3 improvements presented
- Clear recommendation provided
- Menu options presented with clear explanations
- User can review findings, get help, or exit
### ❌ SYSTEM FAILURE:
- Not loading complete validation report
- Missing summary of findings
- Not updating report frontmatter
- Not determining overall status
- Missing menu options
- Unclear next steps
**Master Rule:** User needs clear summary and actionable next steps. Edit workflow is best for complex issues; immediate fixes available for simpler ones.

View File

@ -1,65 +0,0 @@
---
name: validate-prd
description: 'Validate a PRD against standards. Use when the user says "validate this PRD" or "run PRD validation"'
standalone: false
main_config: '{project-root}/_bmad/bmm/config.yaml'
validateWorkflow: './steps-v/step-v-01-discovery.md'
---
# PRD Validate Workflow
**Goal:** Validate existing PRDs against BMAD standards through comprehensive review.
**Your Role:** Validation Architect and Quality Assurance Specialist.
You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
## WORKFLOW ARCHITECTURE
This uses **step-file architecture** for disciplined execution:
### Core Principles
- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
- **Append-Only Building**: Build documents by appending content as directed to the output file
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
6. **LOAD NEXT**: When directed, read fully and follow the next step file
### Critical Rules (NO EXCEPTIONS)
- 🛑 **NEVER** load multiple step files simultaneously
- 📖 **ALWAYS** read entire step file before execution
- 🚫 **NEVER** skip steps or optimize the sequence
- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
- 🎯 **ALWAYS** follow the exact instructions in the step file
- ⏸️ **ALWAYS** halt at menus and wait for user input
- 📋 **NEVER** create mental todo lists from future steps
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from {main_config} and resolve:
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
- `communication_language`, `document_output_language`, `user_skill_level`
- `date` as system-generated current datetime
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
### 2. Route to Validate Workflow
"**Validate Mode: Validating an existing PRD against BMAD standards.**"
Then read fully and follow: `{validateWorkflow}` (steps-v/step-v-01-discovery.md)

View File

@ -36,10 +36,12 @@ When you are in this persona and the user calls a skill, this persona must carry
## On Activation
1. **Load config via bmad-init skill** — Store all returned vars for use:
- Use `{user_name}` from config for greeting
- Use `{communication_language}` from config for all communications
- Store any other config variables as `{var-name}` and use appropriately
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
2. **Continue with steps below:**
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.

View File

@ -33,17 +33,15 @@
- ⏸️ **ALWAYS** halt at menus and wait for user input
- 📋 **NEVER** create mental todo lists from future steps
---
## Activation
## INITIALIZATION SEQUENCE
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
### 1. Module Configuration Loading
Load and read full config from {project-root}/_bmad/bmm/config.yaml and resolve:
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`, `communication_language`, `document_output_language`
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### 2. First Step EXECUTION
2. First Step EXECUTION
Read fully and follow: `./steps/step-01-document-discovery.md` to begin the workflow.

View File

@ -16,22 +16,16 @@ This uses **micro-file architecture** for disciplined execution:
- Append-only document building through conversation
- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
---
## Activation
## INITIALIZATION
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
### Configuration Loading
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
- `communication_language`, `document_output_language`, `user_skill_level`
- `date` as system-generated current datetime
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
---
## EXECUTION
2. EXECUTION
Read fully and follow: `./steps/step-01-init.md` to begin the workflow.

View File

@ -37,17 +37,15 @@ This uses **step-file architecture** for disciplined execution:
- ⏸️ **ALWAYS** halt at menus and wait for user input
- 📋 **NEVER** create mental todo lists from future steps
---
## Activation
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from {project-root}/_bmad/bmm/config.yaml and resolve:
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`, `communication_language`, `document_output_language`
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### 2. First Step EXECUTION
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
2. First Step EXECUTION
Read fully and follow: `./steps/step-01-validate-prerequisites.md` to begin the workflow.

View File

@ -18,25 +18,21 @@ This uses **micro-file architecture** for disciplined execution:
---
## INITIALIZATION
## Activation
### Configuration Loading
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- `project_name`, `output_folder`, `user_name`
- `communication_language`, `document_output_language`, `user_skill_level`
- `date` as system-generated current datetime
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
### Paths
- `output_file` = `{output_folder}/project-context.md`
---
## EXECUTION
EXECUTION
Load and execute `./steps/step-01-discover.md` to begin the workflow.

View File

@ -46,10 +46,12 @@ When you are in this persona and the user calls a skill, this persona must carry
## On Activation
1. **Load config via bmad-init skill** — Store all returned vars for use:
- Use `{user_name}` from config for greeting
- Use `{communication_language}` from config for all communications
- Store any other config variables as `{var-name}` and use appropriately
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
2. **Continue with steps below:**
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.

View File

@ -43,10 +43,12 @@ When you are in this persona and the user calls a skill, this persona must carry
## On Activation
1. **Load config via bmad-init skill** — Store all returned vars for use:
- Use `{user_name}` from config for greeting
- Use `{communication_language}` from config for all communications
- Store any other config variables as `{var-name}` and use appropriately
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
2. **Continue with steps below:**
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.

View File

@ -35,10 +35,12 @@ When you are in this persona and the user calls a skill, this persona must carry
## On Activation
1. **Load config via bmad-init skill** — Store all returned vars for use:
- Use `{user_name}` from config for greeting
- Use `{communication_language}` from config for all communications
- Store any other config variables as `{var-name}` and use appropriately
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
2. **Continue with steps below:**
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.

View File

@ -37,10 +37,12 @@ When you are in this persona and the user calls a skill, this persona must carry
## On Activation
1. **Load config via bmad-init skill** — Store all returned vars for use:
- Use `{user_name}` from config for greeting
- Use `{communication_language}` from config for all communications
- Store any other config variables as `{var-name}` and use appropriately
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
- Use `{document_output_language}` for output documents
- Use `{planning_artifacts}` for output location and artifact scanning
- Use `{project_knowledge}` for additional context scanning
2. **Continue with steps below:**
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.

View File

@ -12,7 +12,8 @@ BMad Method,bmad-brainstorming,Brainstorm Project,BP,Expert guided facilitation
BMad Method,bmad-market-research,Market Research,MR,"Market analysis competitive landscape customer needs and trends.",,1-analysis,,,false,"planning_artifacts|project-knowledge",research documents
BMad Method,bmad-domain-research,Domain Research,DR,Industry domain deep dive subject matter expertise and terminology.,,1-analysis,,,false,"planning_artifacts|project_knowledge",research documents
BMad Method,bmad-technical-research,Technical Research,TR,Technical feasibility architecture options and implementation approaches.,,1-analysis,,,false,"planning_artifacts|project_knowledge",research documents
BMad Method,bmad-product-brief,Create Brief,CB,A guided experience to nail down your product idea.,,1-analysis,,,false,planning_artifacts,product brief
BMad Method,bmad-product-brief,Create Brief,CB,An expert guided experience to nail down your product idea in a brief. a gentler approach than PRFAQ when you are already sure of your concept and nothing will sway you.,,-A,1-analysis,,,false,planning_artifacts,product brief
BMad Method,bmad-prfaq,PRFAQ Challenge,WB,Working Backwards guided experience to forge and stress-test your product concept to ensure you have a great product that users will love and need through the PRFAQ gauntlet to determine feasibility and alignment with user needs. alternative to product brief.,,-H,1-analysis,,,false,planning_artifacts,prfaq document
BMad Method,bmad-create-prd,Create PRD,CP,Expert led facilitation to produce your Product Requirements Document.,,2-planning,,,true,planning_artifacts,prd
BMad Method,bmad-validate-prd,Validate PRD,VP,,,[path],2-planning,bmad-create-prd,,false,planning_artifacts,prd validation report
BMad Method,bmad-edit-prd,Edit PRD,EP,,,[path],2-planning,bmad-validate-prd,,false,planning_artifacts,updated prd

Can't render this file because it has a wrong number of fields in line 2.

View File

@ -1,7 +1,6 @@
---
name: bmad-advanced-elicitation
description: 'Push the LLM to reconsider, refine, and improve its recent output. Use when user asks for deeper critique or mentions a known deeper critique method, e.g. socratic, first principles, pre-mortem, red team.'
agent_party: '{project-root}/_bmad/_config/agent-manifest.csv'
---
# Advanced Elicitation
@ -36,7 +35,7 @@ When invoked from another prompt or process:
### Step 1: Method Registry Loading
**Action:** Load and read `./methods.csv` and `{agent_party}`
**Action:** Load and read `./methods.csv` and '{project-root}/_bmad/_config/agent-manifest.csv'
#### CSV Structure

View File

@ -1,7 +1,6 @@
---
name: bmad-distillator
description: Lossless LLM-optimized compression of source documents. Use when the user requests to 'distill documents' or 'create a distillate'.
argument-hint: "[to create provide input paths] [--validate distillate-path to confirm distillate is lossless and optimized]"
---
# Distillator: A Document Distillation Engine

View File

@ -81,18 +81,18 @@ When the same fact appears in both a brief and discovery notes:
**Brief says:**
```
bmad-init must always be included as a base skill in every bundle
bmad-help must always be included as a base skill in every bundle
```
**Discovery notes say:**
```
bmad-init must always be included as a base skill in every bundle/install
(solves bootstrapping problem)
bmad-help must always be included as a base skill in every bundle/install
(solves discoverability problem)
```
**Distillate keeps the more contextual version:**
```
- bmad-init: always included as base skill in every bundle (solves bootstrapping)
- bmad-help: always included as base skill in every bundle (solves discoverability)
```
### Decision/Rationale Compression
@ -128,7 +128,7 @@ parts: 1
## Core Concept
- BMAD Next-Gen Installer: replaces monolithic Node.js CLI with skill-based plugin architecture for distributing BMAD methodology across 40+ AI platforms
- Three layers: self-describing plugins (bmad-manifest.json), cross-platform install via Vercel skills CLI (MIT), runtime registration via bmad-init skill
- Three layers: self-describing plugins (bmad-manifest.json), cross-platform install via Vercel skills CLI (MIT), runtime registration via bmad-setup skill
- Transforms BMAD from dev-only methodology into open platform for any domain (creative, therapeutic, educational, personal)
## Problem
@ -141,7 +141,7 @@ parts: 1
- Plugins: skill bundles with Anthropic plugin standard as base format + bmad-manifest.json extending for BMAD-specific metadata (installer options, capabilities, help integration, phase ordering, dependencies)
- Existing manifest example: `{"module-code":"bmm","replaces-skill":"bmad-create-product-brief","capabilities":[{"name":"create-brief","menu-code":"CB","supports-headless":true,"phase-name":"1-analysis","after":["brainstorming"],"before":["create-prd"],"is-required":true}]}`
- Vercel skills CLI handles platform translation; integration pattern (wrap/fork/call) is PRD decision
- bmad-init: global skill scanning installed bmad-manifest.json files, registering capabilities, configuring project settings; always included as base skill in every bundle (solves bootstrapping)
- bmad-setup: global skill scanning installed bmad-manifest.json files, registering capabilities, configuring project settings; always included as base skill in every bundle (solves bootstrapping)
- bmad-update: plugin update path without full reinstall; technical approach (diff/replace/preserve customizations) is PRD decision
- Distribution tiers: (1) NPX installer wrapping skills CLI for technical users, (2) zip bundle + platform-specific README for non-technical users, (3) future marketplace
- Non-technical path has honest friction: "copy to right folder" requires knowing where; per-platform README instructions; improves over time as low-code space matures
@ -161,13 +161,13 @@ parts: 1
- Zero (or near-zero) custom platform directory code; delegated to skills CLI ecosystem
- Installation verified on top platforms by volume; skills CLI handles long tail
- Non-technical install path validated with non-developer users
- bmad-init discovers/registers all plugins from manifests; clear errors for malformed manifests
- bmad-setup discovers/registers all plugins from manifests; clear errors for malformed manifests
- At least one external module author successfully publishes plugin using manifest system
- bmad-update works without full reinstall
- Existing CLI users have documented migration path
## Scope
- In: manifest spec, bmad-init, bmad-update, Vercel CLI integration, NPX installer, zip bundles, migration path
- In: manifest spec, bmad-setup, bmad-update, Vercel CLI integration, NPX installer, zip bundles, migration path
- Out: BMAD Builder, marketplace web platform, skill conversion (prerequisite, separate), one-click install for all platforms, monetization, quality certification process (gated-submission principle is architectural requirement; process defined separately)
- Deferred: CI/CD integration, telemetry for module authors, air-gapped enterprise install, zip bundle integrity verification (checksums/signing), deeper non-technical platform integrations
@ -214,7 +214,7 @@ parts: 1
## Opportunities
- Module authors as acquisition channel: each published plugin distributes BMAD to creator's audience
- CI/CD integration: bmad-init as pipeline one-liner increases stickiness
- CI/CD integration: bmad-setup as pipeline one-liner increases stickiness
- Educational institutions: structured methodology + non-technical install → university AI curriculum
- Skill composability: mixing BMAD modules with third-party skills for custom methodology stacks

View File

@ -1,100 +0,0 @@
---
name: bmad-init
description: "Initialize BMad project configuration and load config variables. Use when any skill needs module-specific configuration values, or when setting up a new BMad project."
argument-hint: "[--module=module_code] [--vars=var1:default1,var2] [--skill-path=/path/to/calling/skill]"
---
## Overview
This skill is the configuration entry point for all BMad skills. It has two modes:
- **Fast path**: Config exists for the requested module — returns vars as JSON. Done.
- **Init path**: Config is missing — walks the user through configuration, writes config files, then returns vars.
Every BMad skill should call this on activation to get its config vars. The caller never needs to know whether init happened — they just get their config back.
The script `bmad_init.py` is located in this skill's `scripts/` directory. Locate and run it using python for all commands below.
## On Activation — Fast Path
Run the `bmad_init.py` script with the `load` subcommand. Pass `--project-root` set to the project root directory.
- If a module code was provided by the calling skill, include `--module {module_code}`
- To load all vars, include `--all`
- To request specific variables with defaults, use `--vars var1:default1,var2`
- If no module was specified, omit `--module` to get core vars only
**If the script returns JSON vars** — store them as `{var-name}` and return to the calling skill. Done.
**If the script returns an error or `init_required`** — proceed to the Init Path below.
## Init Path — First-Time Setup
When the fast path fails (config missing for a module), run this init flow.
### Step 1: Check what needs setup
Run `bmad_init.py` with the `check` subcommand, passing `--module {module_code}`, `--skill-path {calling_skill_path}`, and `--project-root`.
The response tells you what's needed:
- `"status": "ready"` — Config is fine. Re-run load.
- `"status": "no_project"` — Can't find project root. Ask user to confirm the project path.
- `"status": "core_missing"` — Core config doesn't exist. Must ask core questions first.
- `"status": "module_missing"` — Core exists but module config doesn't. Ask module questions.
The response includes:
- `core_module` — Core module.yaml questions (when core setup needed)
- `target_module` — Target module.yaml questions (when module setup needed, discovered from `--skill-path` or `_bmad/{module}/`)
- `core_vars` — Existing core config values (when core exists but module doesn't)
### Step 2: Ask core questions (if `core_missing`)
The check response includes `core_module` with header, subheader, and variable definitions.
1. Show the `header` and `subheader` to the user
2. For each variable, present the `prompt` and `default`
3. For variables with `single-select`, show the options as a numbered list
4. For variables with multi-line `prompt` (array), show all lines
5. Let the user accept defaults or provide values
### Step 3: Ask module questions (if module was requested)
The check response includes `target_module` with the module's questions. Variables may reference core answers in their defaults (e.g., `{output_folder}`).
1. Resolve defaults by running `bmad_init.py` with the `resolve-defaults` subcommand, passing `--module {module_code}`, `--core-answers '{core_answers_json}'`, and `--project-root`
2. Show the module's `header` and `subheader`
3. For each variable, present the prompt with resolved default
4. For `single-select` variables, show options as a numbered list
### Step 4: Write config
Collect all answers and run `bmad_init.py` with the `write` subcommand, passing `--answers '{all_answers_json}'` and `--project-root`.
The `--answers` JSON format:
```json
{
"core": {
"user_name": "BMad",
"communication_language": "English",
"document_output_language": "English",
"output_folder": "_bmad-output"
},
"bmb": {
"bmad_builder_output_folder": "_bmad-output/skills",
"bmad_builder_reports": "_bmad-output/reports"
}
}
```
Note: Pass the **raw user answers** (before result template expansion). The script applies result templates and `{project-root}` expansion when writing.
The script:
- Creates `_bmad/core/config.yaml` with core values (if core answers provided)
- Creates `_bmad/{module}/config.yaml` with core values + module values (result-expanded)
- Creates any directories listed in the module.yaml `directories` array
### Step 5: Return vars
After writing, re-run `bmad_init.py` with the `load` subcommand (same as the fast path) to return resolved vars. Store returned vars as `{var-name}` and return them to the calling skill.

View File

@ -1,25 +0,0 @@
code: core
name: "BMad Core Module"
header: "BMad Core Configuration"
subheader: "Configure the core settings for your BMad installation.\nThese settings will be used across all installed bmad skills, workflows, and agents."
user_name:
prompt: "What should agents call you? (Use your name or a team name)"
default: "BMad"
result: "{value}"
communication_language:
prompt: "What language should agents use when chatting with you?"
default: "English"
result: "{value}"
document_output_language:
prompt: "Preferred document output language?"
default: "English"
result: "{value}"
output_folder:
prompt: "Where should output files be saved?"
default: "_bmad-output"
result: "{project-root}/{value}"

View File

@ -1,624 +0,0 @@
# /// script
# requires-python = ">=3.10"
# dependencies = ["pyyaml"]
# ///
#!/usr/bin/env python3
"""
BMad Init — Project configuration bootstrap and config loader.
Config files (flat YAML per module):
- _bmad/core/config.yaml (core settings — user_name, language, output_folder, etc.)
- _bmad/{module}/config.yaml (module settings + core values merged in)
Usage:
# Fast path — load all vars for a module (includes core vars)
python bmad_init.py load --module bmb --all --project-root /path
# Load specific vars with optional defaults
python bmad_init.py load --module bmb --vars var1:default1,var2 --project-root /path
# Load core only
python bmad_init.py load --all --project-root /path
# Check if init is needed
python bmad_init.py check --project-root /path
python bmad_init.py check --module bmb --skill-path /path/to/skill --project-root /path
# Resolve module defaults given core answers
python bmad_init.py resolve-defaults --module bmb --core-answers '{"output_folder":"..."}' --project-root /path
# Write config from answered questions
python bmad_init.py write --answers '{"core": {...}, "bmb": {...}}' --project-root /path
"""
import argparse
import json
import os
import sys
from pathlib import Path
import yaml
# =============================================================================
# Project Root Detection
# =============================================================================
def find_project_root(llm_provided=None):
"""
Find project root by looking for _bmad folder.
Args:
llm_provided: Path explicitly provided via --project-root.
Returns:
Path to project root, or None if not found.
"""
if llm_provided:
candidate = Path(llm_provided)
if (candidate / '_bmad').exists():
return candidate
# First run — _bmad won't exist yet but LLM path is still valid
if candidate.is_dir():
return candidate
for start_dir in [Path.cwd(), Path(__file__).resolve().parent]:
current_dir = start_dir
while current_dir != current_dir.parent:
if (current_dir / '_bmad').exists():
return current_dir
current_dir = current_dir.parent
return None
# =============================================================================
# Module YAML Loading
# =============================================================================
def load_module_yaml(path):
"""
Load and parse a module.yaml file, separating metadata from variable definitions.
Returns:
Dict with 'meta' (code, name, etc.) and 'variables' (var definitions)
and 'directories' (list of dir templates), or None on failure.
"""
try:
with open(path, 'r', encoding='utf-8') as f:
raw = yaml.safe_load(f)
except Exception:
return None
if not raw or not isinstance(raw, dict):
return None
meta_keys = {'code', 'name', 'description', 'default_selected', 'header', 'subheader'}
meta = {}
variables = {}
directories = []
for key, value in raw.items():
if key == 'directories':
directories = value if isinstance(value, list) else []
elif key in meta_keys:
meta[key] = value
elif isinstance(value, dict) and 'prompt' in value:
variables[key] = value
# Skip comment-only entries (## var_name lines become None values)
return {'meta': meta, 'variables': variables, 'directories': directories}
def find_core_module_yaml():
"""Find the core module.yaml bundled with this skill."""
return Path(__file__).resolve().parent.parent / 'resources' / 'core-module.yaml'
def find_target_module_yaml(module_code, project_root, skill_path=None):
"""
Find module.yaml for a given module code.
Search order:
1. skill_path/assets/module.yaml (calling skill's assets)
2. skill_path/module.yaml (calling skill's root)
3. _bmad/{module_code}/module.yaml (installed module location)
"""
search_paths = []
if skill_path:
sp = Path(skill_path)
search_paths.append(sp / 'assets' / 'module.yaml')
search_paths.append(sp / 'module.yaml')
if project_root and module_code:
search_paths.append(Path(project_root) / '_bmad' / module_code / 'module.yaml')
for path in search_paths:
if path.exists():
return path
return None
# =============================================================================
# Config Loading (Flat per-module files)
# =============================================================================
def load_config_file(path):
"""Load a flat YAML config file. Returns dict or None."""
try:
with open(path, 'r', encoding='utf-8') as f:
data = yaml.safe_load(f)
return data if isinstance(data, dict) else None
except Exception:
return None
def load_module_config(module_code, project_root):
"""Load config for a specific module from _bmad/{module}/config.yaml."""
config_path = Path(project_root) / '_bmad' / module_code / 'config.yaml'
return load_config_file(config_path)
def resolve_project_root_placeholder(value, project_root):
"""Replace {project-root} placeholder with actual path."""
if not value or not isinstance(value, str):
return value
if '{project-root}' not in value:
return value
# Strip the {project-root} token to inspect what remains, so we can
# correctly handle absolute paths stored as "{project-root}//absolute/path"
# (produced by the "{project-root}/{value}" template applied to an absolute value).
suffix = value.replace('{project-root}', '', 1)
# Strip the one path separator that follows the token (if any)
if suffix.startswith('/') or suffix.startswith('\\'):
remainder = suffix[1:]
else:
remainder = suffix
if os.path.isabs(remainder):
# The original value was an absolute path stored with a {project-root}/ prefix.
# Return the absolute path directly — no joining needed.
return remainder
# Relative path: join with project root and normalize to resolve any .. segments.
return os.path.normpath(os.path.join(str(project_root), remainder))
def parse_var_specs(vars_string):
"""
Parse variable specs: var_name:default_value,var_name2:default_value2
No default = returns null if missing.
"""
if not vars_string:
return []
specs = []
for spec in vars_string.split(','):
spec = spec.strip()
if not spec:
continue
if ':' in spec:
parts = spec.split(':', 1)
specs.append({'name': parts[0].strip(), 'default': parts[1].strip()})
else:
specs.append({'name': spec, 'default': None})
return specs
# =============================================================================
# Template Expansion
# =============================================================================
def expand_template(value, context):
"""
Expand {placeholder} references in a string using context dict.
Supports: {project-root}, {value}, {output_folder}, {directory_name}, etc.
"""
if not value or not isinstance(value, str):
return value
result = value
for key, val in context.items():
placeholder = '{' + key + '}'
if placeholder in result and val is not None:
result = result.replace(placeholder, str(val))
return result
def apply_result_template(var_def, raw_value, context):
"""
Apply a variable's result template to transform the raw user answer.
E.g., result: "{project-root}/{value}" with value="_bmad-output"
becomes "/Users/foo/project/_bmad-output"
"""
result_template = var_def.get('result')
if not result_template:
return raw_value
# If the user supplied an absolute path and the template would prefix it with
# "{project-root}/", skip the template entirely to avoid producing a broken path
# like "/my/project//absolute/path".
if isinstance(raw_value, str) and os.path.isabs(raw_value):
return raw_value
ctx = dict(context)
ctx['value'] = raw_value
result = expand_template(result_template, ctx)
# Normalize the resulting path to resolve any ".." segments (e.g. when the user
# entered a relative path such as "../../outside-dir").
if isinstance(result, str) and '{' not in result and os.path.isabs(result):
result = os.path.normpath(result)
return result
# =============================================================================
# Load Command (Fast Path)
# =============================================================================
def cmd_load(args):
"""Load config vars — the fast path."""
project_root = find_project_root(llm_provided=args.project_root)
if not project_root:
print(json.dumps({'error': 'Project root not found (_bmad folder not detected)'}),
file=sys.stderr)
sys.exit(1)
module_code = args.module or 'core'
# Load the module's config (which includes core vars)
config = load_module_config(module_code, project_root)
if config is None:
print(json.dumps({
'init_required': True,
'missing_module': module_code,
}), file=sys.stderr)
sys.exit(1)
# Resolve {project-root} in all values
for key in config:
config[key] = resolve_project_root_placeholder(config[key], project_root)
if args.all:
print(json.dumps(config, indent=2))
else:
var_specs = parse_var_specs(args.vars)
if not var_specs:
print(json.dumps({'error': 'Either --vars or --all must be specified'}),
file=sys.stderr)
sys.exit(1)
result = {}
for spec in var_specs:
val = config.get(spec['name'])
if val is not None and val != '':
result[spec['name']] = val
elif spec['default'] is not None:
result[spec['name']] = spec['default']
else:
result[spec['name']] = None
print(json.dumps(result, indent=2))
# =============================================================================
# Check Command
# =============================================================================
def cmd_check(args):
"""Check if config exists and return status with module.yaml questions if needed."""
project_root = find_project_root(llm_provided=args.project_root)
if not project_root:
print(json.dumps({
'status': 'no_project',
'message': 'No project root found. Provide --project-root to bootstrap.',
}, indent=2))
return
project_root = Path(project_root)
module_code = args.module
# Check core config
core_config = load_module_config('core', project_root)
core_exists = core_config is not None
# If no module requested, just check core
if not module_code or module_code == 'core':
if core_exists:
print(json.dumps({'status': 'ready', 'project_root': str(project_root)}, indent=2))
else:
core_yaml_path = find_core_module_yaml()
core_module = load_module_yaml(core_yaml_path) if core_yaml_path.exists() else None
print(json.dumps({
'status': 'core_missing',
'project_root': str(project_root),
'core_module': core_module,
}, indent=2))
return
# Module requested — check if its config exists
module_config = load_module_config(module_code, project_root)
if module_config is not None:
print(json.dumps({'status': 'ready', 'project_root': str(project_root)}, indent=2))
return
# Module config missing — find its module.yaml for questions
target_yaml_path = find_target_module_yaml(
module_code, project_root, skill_path=args.skill_path
)
target_module = load_module_yaml(target_yaml_path) if target_yaml_path else None
result = {
'project_root': str(project_root),
}
if not core_exists:
result['status'] = 'core_missing'
core_yaml_path = find_core_module_yaml()
result['core_module'] = load_module_yaml(core_yaml_path) if core_yaml_path.exists() else None
else:
result['status'] = 'module_missing'
result['core_vars'] = core_config
result['target_module'] = target_module
if target_yaml_path:
result['target_module_yaml_path'] = str(target_yaml_path)
print(json.dumps(result, indent=2))
# =============================================================================
# Resolve Defaults Command
# =============================================================================
def cmd_resolve_defaults(args):
"""Given core answers, resolve a module's variable defaults."""
project_root = find_project_root(llm_provided=args.project_root)
if not project_root:
print(json.dumps({'error': 'Project root not found'}), file=sys.stderr)
sys.exit(1)
try:
core_answers = json.loads(args.core_answers)
except json.JSONDecodeError as e:
print(json.dumps({'error': f'Invalid JSON in --core-answers: {e}'}),
file=sys.stderr)
sys.exit(1)
# Build context for template expansion
context = {
'project-root': str(project_root),
'directory_name': Path(project_root).name,
}
context.update(core_answers)
# Find and load the module's module.yaml
module_code = args.module
target_yaml_path = find_target_module_yaml(
module_code, project_root, skill_path=args.skill_path
)
if not target_yaml_path:
print(json.dumps({'error': f'No module.yaml found for module: {module_code}'}),
file=sys.stderr)
sys.exit(1)
module_def = load_module_yaml(target_yaml_path)
if not module_def:
print(json.dumps({'error': f'Failed to parse module.yaml at: {target_yaml_path}'}),
file=sys.stderr)
sys.exit(1)
# Resolve defaults in each variable
resolved_vars = {}
for var_name, var_def in module_def['variables'].items():
default = var_def.get('default', '')
resolved_default = expand_template(str(default), context)
resolved_vars[var_name] = dict(var_def)
resolved_vars[var_name]['default'] = resolved_default
result = {
'module_code': module_code,
'meta': module_def['meta'],
'variables': resolved_vars,
'directories': module_def['directories'],
}
print(json.dumps(result, indent=2))
# =============================================================================
# Write Command
# =============================================================================
def cmd_write(args):
"""Write config files from answered questions."""
project_root = find_project_root(llm_provided=args.project_root)
if not project_root:
if args.project_root:
project_root = Path(args.project_root)
else:
print(json.dumps({'error': 'Project root not found and --project-root not provided'}),
file=sys.stderr)
sys.exit(1)
project_root = Path(project_root)
try:
answers = json.loads(args.answers)
except json.JSONDecodeError as e:
print(json.dumps({'error': f'Invalid JSON in --answers: {e}'}),
file=sys.stderr)
sys.exit(1)
context = {
'project-root': str(project_root),
'directory_name': project_root.name,
}
# Load module.yaml definitions to get result templates
core_yaml_path = find_core_module_yaml()
core_def = load_module_yaml(core_yaml_path) if core_yaml_path.exists() else None
files_written = []
dirs_created = []
# Process core answers first (needed for module config expansion)
core_answers_raw = answers.get('core', {})
core_config = {}
if core_answers_raw and core_def:
for var_name, raw_value in core_answers_raw.items():
var_def = core_def['variables'].get(var_name, {})
expanded = apply_result_template(var_def, raw_value, context)
core_config[var_name] = expanded
# Write core config
core_dir = project_root / '_bmad' / 'core'
core_dir.mkdir(parents=True, exist_ok=True)
core_config_path = core_dir / 'config.yaml'
# Merge with existing if present
existing = load_config_file(core_config_path) or {}
existing.update(core_config)
_write_config_file(core_config_path, existing, 'CORE')
files_written.append(str(core_config_path))
elif core_answers_raw:
# No core_def available — write raw values
core_config = dict(core_answers_raw)
core_dir = project_root / '_bmad' / 'core'
core_dir.mkdir(parents=True, exist_ok=True)
core_config_path = core_dir / 'config.yaml'
existing = load_config_file(core_config_path) or {}
existing.update(core_config)
_write_config_file(core_config_path, existing, 'CORE')
files_written.append(str(core_config_path))
# Update context with resolved core values for module expansion
context.update(core_config)
# Process module answers
for module_code, module_answers_raw in answers.items():
if module_code == 'core':
continue
# Find module.yaml for result templates
target_yaml_path = find_target_module_yaml(
module_code, project_root, skill_path=args.skill_path
)
module_def = load_module_yaml(target_yaml_path) if target_yaml_path else None
# Build module config: start with core values, then add module values
# Re-read core config to get the latest (may have been updated above)
latest_core = load_module_config('core', project_root) or core_config
module_config = dict(latest_core)
for var_name, raw_value in module_answers_raw.items():
if module_def:
var_def = module_def['variables'].get(var_name, {})
expanded = apply_result_template(var_def, raw_value, context)
else:
expanded = raw_value
module_config[var_name] = expanded
context[var_name] = expanded # Available for subsequent template expansion
# Write module config
module_dir = project_root / '_bmad' / module_code
module_dir.mkdir(parents=True, exist_ok=True)
module_config_path = module_dir / 'config.yaml'
existing = load_config_file(module_config_path) or {}
existing.update(module_config)
module_name = module_def['meta'].get('name', module_code.upper()) if module_def else module_code.upper()
_write_config_file(module_config_path, existing, module_name)
files_written.append(str(module_config_path))
# Create directories declared in module.yaml
if module_def and module_def.get('directories'):
for dir_template in module_def['directories']:
dir_path = expand_template(dir_template, context)
if dir_path:
Path(dir_path).mkdir(parents=True, exist_ok=True)
dirs_created.append(dir_path)
result = {
'status': 'written',
'files_written': files_written,
'dirs_created': dirs_created,
}
print(json.dumps(result, indent=2))
def _write_config_file(path, data, module_label):
"""Write a config YAML file with a header comment."""
from datetime import datetime, timezone
with open(path, 'w', encoding='utf-8') as f:
f.write(f'# {module_label} Module Configuration\n')
f.write(f'# Generated by bmad-init\n')
f.write(f'# Date: {datetime.now(timezone.utc).isoformat()}\n\n')
yaml.safe_dump(data, f, default_flow_style=False, allow_unicode=True, sort_keys=False)
# =============================================================================
# CLI Entry Point
# =============================================================================
def main():
parser = argparse.ArgumentParser(
description='BMad Init — Project configuration bootstrap and config loader.'
)
subparsers = parser.add_subparsers(dest='command')
# --- load ---
load_parser = subparsers.add_parser('load', help='Load config vars (fast path)')
load_parser.add_argument('--module', help='Module code (omit for core only)')
load_parser.add_argument('--vars', help='Comma-separated vars with optional defaults')
load_parser.add_argument('--all', action='store_true', help='Return all config vars')
load_parser.add_argument('--project-root', help='Project root path')
# --- check ---
check_parser = subparsers.add_parser('check', help='Check if init is needed')
check_parser.add_argument('--module', help='Module code to check (optional)')
check_parser.add_argument('--skill-path', help='Path to the calling skill folder')
check_parser.add_argument('--project-root', help='Project root path')
# --- resolve-defaults ---
resolve_parser = subparsers.add_parser('resolve-defaults',
help='Resolve module defaults given core answers')
resolve_parser.add_argument('--module', required=True, help='Module code')
resolve_parser.add_argument('--core-answers', required=True, help='JSON string of core answers')
resolve_parser.add_argument('--skill-path', help='Path to calling skill folder')
resolve_parser.add_argument('--project-root', help='Project root path')
# --- write ---
write_parser = subparsers.add_parser('write', help='Write config files')
write_parser.add_argument('--answers', required=True, help='JSON string of all answers')
write_parser.add_argument('--skill-path', help='Path to calling skill (for module.yaml lookup)')
write_parser.add_argument('--project-root', help='Project root path')
args = parser.parse_args()
if args.command is None:
parser.print_help()
sys.exit(1)
commands = {
'load': cmd_load,
'check': cmd_check,
'resolve-defaults': cmd_resolve_defaults,
'write': cmd_write,
}
handler = commands.get(args.command)
if handler:
handler(args)
else:
parser.print_help()
sys.exit(1)
if __name__ == '__main__':
main()

View File

@ -1,393 +0,0 @@
# /// script
# requires-python = ">=3.10"
# dependencies = ["pyyaml"]
# ///
#!/usr/bin/env python3
"""Unit tests for bmad_init.py"""
import json
import os
import shutil
import sys
import tempfile
import unittest
from pathlib import Path
sys.path.insert(0, str(Path(__file__).parent.parent))
from bmad_init import (
find_project_root,
parse_var_specs,
resolve_project_root_placeholder,
expand_template,
apply_result_template,
load_module_yaml,
find_core_module_yaml,
find_target_module_yaml,
load_config_file,
load_module_config,
)
class TestFindProjectRoot(unittest.TestCase):
def test_finds_bmad_folder(self):
temp_dir = tempfile.mkdtemp()
try:
(Path(temp_dir) / '_bmad').mkdir()
original_cwd = os.getcwd()
try:
os.chdir(temp_dir)
result = find_project_root()
self.assertEqual(result.resolve(), Path(temp_dir).resolve())
finally:
os.chdir(original_cwd)
finally:
shutil.rmtree(temp_dir)
def test_llm_provided_with_bmad(self):
temp_dir = tempfile.mkdtemp()
try:
(Path(temp_dir) / '_bmad').mkdir()
result = find_project_root(llm_provided=temp_dir)
self.assertEqual(result.resolve(), Path(temp_dir).resolve())
finally:
shutil.rmtree(temp_dir)
def test_llm_provided_without_bmad_still_returns_dir(self):
"""First-run case: LLM provides path but _bmad doesn't exist yet."""
temp_dir = tempfile.mkdtemp()
try:
result = find_project_root(llm_provided=temp_dir)
self.assertEqual(result.resolve(), Path(temp_dir).resolve())
finally:
shutil.rmtree(temp_dir)
class TestParseVarSpecs(unittest.TestCase):
def test_vars_with_defaults(self):
specs = parse_var_specs('var1:value1,var2:value2')
self.assertEqual(len(specs), 2)
self.assertEqual(specs[0]['name'], 'var1')
self.assertEqual(specs[0]['default'], 'value1')
def test_vars_without_defaults(self):
specs = parse_var_specs('var1,var2')
self.assertEqual(len(specs), 2)
self.assertIsNone(specs[0]['default'])
def test_mixed_vars(self):
specs = parse_var_specs('required_var,var2:default2')
self.assertIsNone(specs[0]['default'])
self.assertEqual(specs[1]['default'], 'default2')
def test_colon_in_default(self):
specs = parse_var_specs('path:{project-root}/some/path')
self.assertEqual(specs[0]['default'], '{project-root}/some/path')
def test_empty_string(self):
self.assertEqual(parse_var_specs(''), [])
def test_none(self):
self.assertEqual(parse_var_specs(None), [])
class TestResolveProjectRootPlaceholder(unittest.TestCase):
def test_resolve_placeholder(self):
result = resolve_project_root_placeholder('{project-root}/output', Path('/test'))
self.assertEqual(result, '/test/output')
def test_no_placeholder(self):
result = resolve_project_root_placeholder('/absolute/path', Path('/test'))
self.assertEqual(result, '/absolute/path')
def test_none(self):
self.assertIsNone(resolve_project_root_placeholder(None, Path('/test')))
def test_non_string(self):
self.assertEqual(resolve_project_root_placeholder(42, Path('/test')), 42)
def test_absolute_path_stored_with_prefix(self):
"""Absolute output_folder entered by user is stored as '{project-root}//abs/path'
by the '{project-root}/{value}' template. It must resolve to '/abs/path', not
'/project//abs/path'."""
result = resolve_project_root_placeholder(
'{project-root}//Users/me/outside', Path('/Users/me/myproject')
)
self.assertEqual(result, '/Users/me/outside')
def test_relative_path_with_traversal_is_normalized(self):
"""A relative path like '../../sibling' produces '{project-root}/../../sibling'
after the template. It must resolve to the normalized absolute path, not the
un-normalized string '/project/../../sibling'."""
result = resolve_project_root_placeholder(
'{project-root}/../../sibling', Path('/Users/me/myproject')
)
self.assertEqual(result, '/Users/sibling')
def test_relative_path_one_level_up(self):
result = resolve_project_root_placeholder(
'{project-root}/../outside-outputs', Path('/project/root')
)
self.assertEqual(result, '/project/outside-outputs')
def test_standard_relative_path_unchanged(self):
"""Normal in-project relative paths continue to work correctly."""
result = resolve_project_root_placeholder(
'{project-root}/_bmad-output', Path('/project/root')
)
self.assertEqual(result, '/project/root/_bmad-output')
class TestExpandTemplate(unittest.TestCase):
def test_basic_expansion(self):
result = expand_template('{project-root}/output', {'project-root': '/test'})
self.assertEqual(result, '/test/output')
def test_multiple_placeholders(self):
result = expand_template(
'{output_folder}/planning',
{'output_folder': '_bmad-output', 'project-root': '/test'}
)
self.assertEqual(result, '_bmad-output/planning')
def test_none_value(self):
self.assertIsNone(expand_template(None, {}))
def test_non_string(self):
self.assertEqual(expand_template(42, {}), 42)
class TestApplyResultTemplate(unittest.TestCase):
def test_with_result_template(self):
var_def = {'result': '{project-root}/{value}'}
result = apply_result_template(var_def, '_bmad-output', {'project-root': '/test'})
self.assertEqual(result, '/test/_bmad-output')
def test_without_result_template(self):
result = apply_result_template({}, 'raw_value', {})
self.assertEqual(result, 'raw_value')
def test_value_only_template(self):
var_def = {'result': '{value}'}
result = apply_result_template(var_def, 'English', {})
self.assertEqual(result, 'English')
def test_absolute_value_skips_project_root_template(self):
"""When the user enters an absolute path, the '{project-root}/{value}' template
must not be applied — doing so would produce '/project//absolute/path'."""
var_def = {'result': '{project-root}/{value}'}
result = apply_result_template(
var_def, '/Users/me/shared-outputs', {'project-root': '/Users/me/myproject'}
)
self.assertEqual(result, '/Users/me/shared-outputs')
def test_relative_traversal_value_is_normalized(self):
"""A relative path like '../../outside' combined with the project-root template
must produce a clean normalized absolute path, not '/project/../../outside'."""
var_def = {'result': '{project-root}/{value}'}
result = apply_result_template(
var_def, '../../outside-dir', {'project-root': '/Users/me/myproject'}
)
self.assertEqual(result, '/Users/outside-dir')
def test_relative_one_level_up_is_normalized(self):
var_def = {'result': '{project-root}/{value}'}
result = apply_result_template(
var_def, '../sibling-outputs', {'project-root': '/project/root'}
)
self.assertEqual(result, '/project/sibling-outputs')
def test_normal_relative_value_unchanged(self):
"""Standard in-project relative paths still produce the expected joined path."""
var_def = {'result': '{project-root}/{value}'}
result = apply_result_template(
var_def, '_bmad-output', {'project-root': '/project/root'}
)
self.assertEqual(result, '/project/root/_bmad-output')
class TestLoadModuleYaml(unittest.TestCase):
def setUp(self):
self.temp_dir = tempfile.mkdtemp()
def tearDown(self):
shutil.rmtree(self.temp_dir)
def test_loads_core_module_yaml(self):
path = Path(self.temp_dir) / 'module.yaml'
path.write_text(
'code: core\n'
'name: "BMad Core Module"\n'
'header: "Core Config"\n'
'user_name:\n'
' prompt: "What should agents call you?"\n'
' default: "BMad"\n'
' result: "{value}"\n'
)
result = load_module_yaml(path)
self.assertIsNotNone(result)
self.assertEqual(result['meta']['code'], 'core')
self.assertEqual(result['meta']['name'], 'BMad Core Module')
self.assertIn('user_name', result['variables'])
self.assertEqual(result['variables']['user_name']['prompt'], 'What should agents call you?')
def test_loads_module_with_directories(self):
path = Path(self.temp_dir) / 'module.yaml'
path.write_text(
'code: bmm\n'
'name: "BMad Method"\n'
'project_name:\n'
' prompt: "Project name?"\n'
' default: "{directory_name}"\n'
' result: "{value}"\n'
'directories:\n'
' - "{planning_artifacts}"\n'
)
result = load_module_yaml(path)
self.assertEqual(result['directories'], ['{planning_artifacts}'])
def test_returns_none_for_missing(self):
result = load_module_yaml(Path(self.temp_dir) / 'nonexistent.yaml')
self.assertIsNone(result)
def test_returns_none_for_empty(self):
path = Path(self.temp_dir) / 'empty.yaml'
path.write_text('')
result = load_module_yaml(path)
self.assertIsNone(result)
class TestFindCoreModuleYaml(unittest.TestCase):
def test_returns_path_to_resources(self):
path = find_core_module_yaml()
self.assertTrue(str(path).endswith('resources/core-module.yaml'))
class TestFindTargetModuleYaml(unittest.TestCase):
def setUp(self):
self.temp_dir = tempfile.mkdtemp()
self.project_root = Path(self.temp_dir)
def tearDown(self):
shutil.rmtree(self.temp_dir)
def test_finds_in_skill_assets(self):
skill_path = self.project_root / 'skills' / 'test-skill'
assets = skill_path / 'assets'
assets.mkdir(parents=True)
(assets / 'module.yaml').write_text('code: test\n')
result = find_target_module_yaml('test', self.project_root, str(skill_path))
self.assertIsNotNone(result)
self.assertTrue(str(result).endswith('assets/module.yaml'))
def test_finds_in_skill_root(self):
skill_path = self.project_root / 'skills' / 'test-skill'
skill_path.mkdir(parents=True)
(skill_path / 'module.yaml').write_text('code: test\n')
result = find_target_module_yaml('test', self.project_root, str(skill_path))
self.assertIsNotNone(result)
def test_finds_in_bmad_module_dir(self):
module_dir = self.project_root / '_bmad' / 'mymod'
module_dir.mkdir(parents=True)
(module_dir / 'module.yaml').write_text('code: mymod\n')
result = find_target_module_yaml('mymod', self.project_root)
self.assertIsNotNone(result)
def test_returns_none_when_not_found(self):
result = find_target_module_yaml('missing', self.project_root)
self.assertIsNone(result)
def test_skill_path_takes_priority(self):
"""Skill assets module.yaml takes priority over _bmad/{module}/."""
skill_path = self.project_root / 'skills' / 'test-skill'
assets = skill_path / 'assets'
assets.mkdir(parents=True)
(assets / 'module.yaml').write_text('code: test\nname: from-skill\n')
module_dir = self.project_root / '_bmad' / 'test'
module_dir.mkdir(parents=True)
(module_dir / 'module.yaml').write_text('code: test\nname: from-bmad\n')
result = find_target_module_yaml('test', self.project_root, str(skill_path))
self.assertTrue('assets' in str(result))
class TestLoadConfigFile(unittest.TestCase):
def setUp(self):
self.temp_dir = tempfile.mkdtemp()
def tearDown(self):
shutil.rmtree(self.temp_dir)
def test_loads_flat_yaml(self):
path = Path(self.temp_dir) / 'config.yaml'
path.write_text('user_name: Test\ncommunication_language: English\n')
result = load_config_file(path)
self.assertEqual(result['user_name'], 'Test')
def test_returns_none_for_missing(self):
result = load_config_file(Path(self.temp_dir) / 'missing.yaml')
self.assertIsNone(result)
class TestLoadModuleConfig(unittest.TestCase):
def setUp(self):
self.temp_dir = tempfile.mkdtemp()
self.project_root = Path(self.temp_dir)
bmad_core = self.project_root / '_bmad' / 'core'
bmad_core.mkdir(parents=True)
(bmad_core / 'config.yaml').write_text(
'user_name: TestUser\n'
'communication_language: English\n'
'document_output_language: English\n'
'output_folder: "{project-root}/_bmad-output"\n'
)
bmad_bmb = self.project_root / '_bmad' / 'bmb'
bmad_bmb.mkdir(parents=True)
(bmad_bmb / 'config.yaml').write_text(
'user_name: TestUser\n'
'communication_language: English\n'
'document_output_language: English\n'
'output_folder: "{project-root}/_bmad-output"\n'
'bmad_builder_output_folder: "{project-root}/_bmad-output/skills"\n'
'bmad_builder_reports: "{project-root}/_bmad-output/reports"\n'
)
def tearDown(self):
shutil.rmtree(self.temp_dir)
def test_load_core(self):
result = load_module_config('core', self.project_root)
self.assertIsNotNone(result)
self.assertEqual(result['user_name'], 'TestUser')
def test_load_module_includes_core_vars(self):
result = load_module_config('bmb', self.project_root)
self.assertIsNotNone(result)
# Module-specific var
self.assertIn('bmad_builder_output_folder', result)
# Core vars also present
self.assertEqual(result['user_name'], 'TestUser')
def test_missing_module(self):
result = load_module_config('nonexistent', self.project_root)
self.assertIsNone(result)
if __name__ == '__main__':
unittest.main()

View File

@ -1,6 +1,123 @@
---
name: bmad-party-mode
description: 'Orchestrates group discussions between all installed BMAD agents, enabling natural multi-agent conversations. Use when user requests party mode.'
description: 'Orchestrates group discussions between installed BMAD agents, enabling natural multi-agent conversations where each agent is a real subagent with independent thinking. Use when user requests party mode, wants multiple agent perspectives, group discussion, roundtable, or multi-agent conversation about their project.'
---
Follow the instructions in ./workflow.md.
# Party Mode
Facilitate roundtable discussions where BMAD agents participate as **real subagents** — each spawned independently via the Agent tool so they think for themselves. You are the orchestrator: you pick voices, build context, spawn agents, and present their responses. You never generate agent responses yourself.
## Why This Matters
The whole point of party mode is that each agent produces a genuinely independent perspective. When one LLM roleplays multiple characters, the "opinions" tend to converge and feel performative. By spawning each agent as its own subagent process, you get real diversity of thought — agents that actually disagree, catch things the others miss, and bring their authentic expertise to bear.
## Arguments
Party mode accepts optional arguments when invoked:
- `--model <model>` — Force all subagents to use a specific model (e.g. `--model haiku`, `--model opus`). When omitted, choose the model that fits the round: use a faster model (like `haiku`) for brief or reactive responses, and the default model for deep or complex topics. Match model weight to the depth of thinking the round requires.
- `--solo` — Run without subagents. Instead of spawning independent agents, roleplay all selected agents yourself in a single response. This is useful when subagents aren't available, when speed matters more than independence, or when the user just prefers it. Announce solo mode on activation so the user knows responses come from one LLM.
## On Activation
1. **Parse arguments** — check for `--model` and `--solo` flags from the user's invocation.
2. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- Use `{user_name}` for greeting
- Use `{communication_language}` for all communications
3. **Read the agent manifest** at `{project-root}/_bmad/_config/agent-manifest.csv`. Build an internal roster of available agents with their displayName, title, icon, role, identity, communicationStyle, and principles.
4. **Load project context** — search for `**/project-context.md`. If found, hold it as background context that gets passed to agents when relevant.
5. **Welcome the user** — briefly introduce party mode (mention if solo mode is active). Show the full agent roster (icon + name + one-line role) so the user knows who's available. Ask what they'd like to discuss.
## The Core Loop
For each user message:
### 1. Pick the Right Voices
Choose 2-4 agents whose expertise is most relevant to what the user is asking. Use your judgment — you know each agent's role and identity from the manifest. Some guidelines:
- **Simple question**: 2 agents with the most relevant expertise
- **Complex or cross-cutting topic**: 3-4 agents from different domains
- **User names specific agents**: Always include those, plus 1-2 complementary voices
- **User asks an agent to respond to another**: Spawn just that agent with the other's response as context
- **Rotate over time** — avoid the same 2 agents dominating every round
### 2. Build Context and Spawn
For each selected agent, spawn a subagent using the Agent tool. Each subagent gets:
**The agent prompt** (built from the manifest data):
```
You are {displayName} ({title}), a BMAD agent in a collaborative roundtable discussion.
## Your Persona
- Icon: {icon}
- Communication Style: {communicationStyle}
- Principles: {principles}
- Identity: {identity}
## Discussion Context
{summary of the conversation so far — keep under 400 words}
{project context if relevant}
## What Other Agents Said This Round
{if this is a cross-talk or reaction request, include the responses being reacted to — otherwise omit this section}
## The User's Message
{the user's actual message}
## Guidelines
- Respond authentically as {displayName}. Your perspective should reflect your genuine expertise.
- Start your response with: {icon} **{displayName}:**
- Speak in {communication_language}.
- Scale your response to the substance — don't pad. If you have a brief point, make it briefly.
- Disagree with other agents when your expertise tells you to. Don't hedge or be polite about it.
- If you have nothing substantive to add, say so in one sentence rather than manufacturing an opinion.
- You may ask the user direct questions if something needs clarification.
- Do NOT use tools. Just respond with your perspective.
```
**Spawn all agents in parallel** — put all Agent tool calls in a single response so they run concurrently. If `--model` was specified, use that model for all subagents. Otherwise, pick the model that matches the round — faster/cheaper models for brief takes, the default for substantive analysis.
**Solo mode** — if `--solo` is active, skip spawning. Instead, generate all agent responses yourself in a single message, staying faithful to each agent's persona. Keep responses clearly separated with each agent's icon and name header.
### 3. Present Responses
Collect all agent responses and present them to the user as-is. Don't summarize, edit, or reorder them. If an agent's response is particularly brief or says they have nothing to add, that's fine — include it anyway so the user sees the full picture.
After presenting, you can optionally add a brief orchestrator note if it would help — like flagging a clear disagreement worth exploring, or noting an agent whose perspective might be relevant but wasn't included this round.
### 4. Handle Follow-ups
The user drives what happens next. Common patterns:
| User says... | You do... |
|---|---|
| Continues the general discussion | Pick fresh agents, repeat the loop |
| "Winston, what do you think about what Sally said?" | Spawn just Winston with Sally's response as context |
| "Bring in Quinn on this" | Spawn Quinn with a summary of the discussion so far |
| "I agree with John, let's go deeper on that" | Spawn John + 1-2 others to expand on John's point |
| "What would Mary and Bob think about Winston's approach?" | Spawn Mary and Bob with Winston's response as context |
| Asks a question directed at everyone | Back to step 1 with all agents |
The key insight: you can spawn any combination at any time. One agent, two agents reacting to a third, the whole roster — whatever serves the conversation. Each spawn is cheap and independent.
## Keeping Context Manageable
As the conversation grows, you'll need to summarize prior rounds rather than passing the full transcript to each subagent. Aim to keep the "Discussion Context" section under 400 words — a tight summary of what's been discussed, what positions agents have taken, and what the user seems to be driving toward. Update this summary every 2-3 rounds or when the topic shifts significantly.
## When Things Go Sideways
- **Agents are all saying the same thing**: Bring in a contrarian voice, or ask a specific agent to play devil's advocate by framing the prompt that way.
- **Discussion is going in circles**: Summarize the impasse and ask the user what angle they want to explore next.
- **User seems disengaged**: Ask directly — continue, change topic, or wrap up?
- **Agent gives a weak response**: Don't retry. Present it and let the user decide if they want more from that agent.
## Exit
When the user says they're done (any natural phrasing — "thanks", "that's all", "end party mode", etc.), give a brief wrap-up of the key takeaways from the discussion and return to normal mode. Don't force exit triggers — just read the room.

Some files were not shown because too many files have changed in this diff Show More