mirror of
https://github.com/bmad-code-org/BMAD-METHOD.git
synced 2026-08-28 19:20:41 +08:00
feat: streamline core to a 5-skill kernel with standalone skill modules
Core installs 14 -> 5 catalog-visible skills; atoms exit to standalone modules; installer gains real dependency resolution; zero npm deps. - Merge bmad-editorial-review-prose/-structure into bmad-editorial-review (structure models JIT-loaded, new customize.toml) - Merge bmad-review-adversarial-general/-edge-case-hunter/-verification-gap into bmad-review as selectable lenses; hidden husk-forwarders remain at the old IDs (no catalog rows) so gds/loop/os-utils keep working - Move bmad-brainstorming, bmad-party-mode, bmad-forge-idea out of core to src/standalone-skills/ as single-skill modules; add bmad-analysis bundle module (curated dependency list over the atoms) - Move bmad-spec into bmm (2-plan-workflows) - Modernize bmad-advanced-elicitation: uv run, customize.toml, methods pick offloaded to scripts/pick_methods.py (with tests) - Delete bmad-index-docs, bmad-shard-doc (removes the tree's only external npm dependency), and the four deprecation shims (bmad-create-prd, bmad-edit-prd, bmad-validate-prd, bmad-create-architecture); all added to removals.txt - Installer: activate the dependencies field (recursive union into selectedModules, cycle-guarded, warn on unknown), config-driven picker visibility; core stays force-installed - bmm module.yaml declares deps on the three atoms - Docs updated across all locales; new reference/standalone-skills.md; shard-doc how-tos removed
This commit is contained in:
Brian Madison
@@ -19,18 +19,18 @@
|
||||
},
|
||||
"skills": [
|
||||
"./src/core-skills/bmad-help",
|
||||
"./src/core-skills/bmad-brainstorming",
|
||||
"./src/core-skills/bmad-customize",
|
||||
"./src/core-skills/bmad-spec",
|
||||
"./src/core-skills/bmad-party-mode",
|
||||
"./src/core-skills/bmad-shard-doc",
|
||||
"./src/core-skills/bmad-advanced-elicitation",
|
||||
"./src/core-skills/bmad-editorial-review",
|
||||
"./src/core-skills/bmad-editorial-review-prose",
|
||||
"./src/core-skills/bmad-editorial-review-structure",
|
||||
"./src/core-skills/bmad-index-docs",
|
||||
"./src/core-skills/bmad-review",
|
||||
"./src/core-skills/bmad-review-adversarial-general",
|
||||
"./src/core-skills/bmad-review-edge-case-hunter",
|
||||
"./src/core-skills/bmad-review-verification-gap"
|
||||
"./src/core-skills/bmad-review-verification-gap",
|
||||
"./src/standalone-skills/bmad-brainstorming/bmad-brainstorming",
|
||||
"./src/standalone-skills/bmad-party-mode/bmad-party-mode",
|
||||
"./src/standalone-skills/bmad-forge-idea/bmad-forge-idea"
|
||||
]
|
||||
},
|
||||
{
|
||||
@@ -53,13 +53,10 @@
|
||||
"./src/bmm-skills/2-plan-workflows/bmad-agent-pm",
|
||||
"./src/bmm-skills/2-plan-workflows/bmad-agent-ux-designer",
|
||||
"./src/bmm-skills/2-plan-workflows/bmad-prd",
|
||||
"./src/bmm-skills/2-plan-workflows/bmad-create-prd",
|
||||
"./src/bmm-skills/2-plan-workflows/bmad-edit-prd",
|
||||
"./src/bmm-skills/2-plan-workflows/bmad-validate-prd",
|
||||
"./src/bmm-skills/2-plan-workflows/bmad-spec",
|
||||
"./src/bmm-skills/2-plan-workflows/bmad-ux",
|
||||
"./src/bmm-skills/3-solutioning/bmad-agent-architect",
|
||||
"./src/bmm-skills/3-solutioning/bmad-architecture",
|
||||
"./src/bmm-skills/3-solutioning/bmad-create-architecture",
|
||||
"./src/bmm-skills/3-solutioning/bmad-check-implementation-readiness",
|
||||
"./src/bmm-skills/3-solutioning/bmad-create-epics-and-stories",
|
||||
"./src/bmm-skills/3-solutioning/bmad-generate-project-context",
|
||||
|
||||
@@ -65,7 +65,7 @@ Critical warnings only — data loss, security issues
|
||||
| Skill | Agent | Purpose |
|
||||
| ------------ | ------- | ------------------------------------ |
|
||||
| `bmad-brainstorming` | Analyst | Brainstorm a new project |
|
||||
| `bmad-create-prd` | PM | Create Product Requirements Document |
|
||||
| `bmad-prd` | PM | Create Product Requirements Document |
|
||||
```
|
||||
|
||||
## Folder Structure Blocks
|
||||
|
||||
@@ -65,7 +65,7 @@ Pouze kritická varování — ztráta dat, bezpečnostní problémy
|
||||
| Skill | Agent | Účel |
|
||||
| -------------------- | ------- | ------------------------------------ |
|
||||
| `bmad-brainstorming` | Analytik | Brainstorming nového projektu |
|
||||
| `bmad-create-prd` | PM | Vytvoření dokumentu požadavků (PRD) |
|
||||
| `bmad-prd` | PM | Vytvoření dokumentu požadavků (PRD) |
|
||||
```
|
||||
|
||||
## Bloky struktury složek
|
||||
|
||||
@@ -21,7 +21,7 @@ Soubor `project-context.md` toto řeší dokumentací toho, co agenti potřebuj
|
||||
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-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
|
||||
@@ -34,7 +34,7 @@ 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, před architekturou** | Ručně, před `bmad-architecture` | Dokumentujte vaše technické preference, aby je architekt respektoval |
|
||||
| **Nový projekt, po architektuře** | Přes `bmad-generate-project-context` nebo ručně | Zachyťte architektonická rozhodnutí pro implementační agenty |
|
||||
| **Existující projekt** | Přes `bmad-generate-project-context` | Objevte existující vzory, aby agenti dodržovali zavedené konvence |
|
||||
| **Quick Flow projekt** | Před nebo během `bmad-quick-dev` | Zajistěte, aby rychlá implementace respektovala vaše vzory |
|
||||
|
||||
@@ -1,78 +0,0 @@
|
||||
---
|
||||
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
|
||||
@@ -52,7 +52,7 @@ Každý skill je adresář obsahující soubor `SKILL.md`. Například instalace
|
||||
.claude/skills/
|
||||
├── bmad-help/
|
||||
│ └── SKILL.md
|
||||
├── bmad-create-prd/
|
||||
├── bmad-prd/
|
||||
│ └── SKILL.md
|
||||
├── bmad-agent-dev/
|
||||
│ └── SKILL.md
|
||||
@@ -93,8 +93,8 @@ Workflow skills spouštějí strukturovaný, vícekrokový proces bez předchoz
|
||||
| --- | --- |
|
||||
| `bmad-product-brief` | Vytvoření product briefu — řízené discovery, když je váš koncept jasný |
|
||||
| `bmad-prfaq` | [Working Backwards PRFAQ](../explanation/analysis-phase.md#prfaq-working-backwards) výzva pro zátěžový test vašeho produktového konceptu |
|
||||
| `bmad-create-prd` | Vytvoření dokumentu požadavků (PRD) |
|
||||
| `bmad-create-architecture` | Návrh systémové architektury |
|
||||
| `bmad-prd` | Vytvoření dokumentu požadavků (PRD) |
|
||||
| `bmad-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 |
|
||||
@@ -120,11 +120,11 @@ 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.
|
||||
Základní modul zahrnuje 5 vestavěných nástrojů — nápovědu, revize, zdokonalování a přizpůsobení — a volitelný balíček BMad Analysis přidává samostatné myšlenkové skills (brainstorming, forge idea, party mode). 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.
|
||||
Všechny skills používají prefix `bmad-` následovaný popisným názvem (např. `bmad-dev`, `bmad-prd`, `bmad-help`). Viz [Moduly](./modules.md) pro dostupné moduly.
|
||||
|
||||
## Řešení problémů
|
||||
|
||||
|
||||
+157
-188
@@ -1,31 +1,39 @@
|
||||
---
|
||||
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ů.
|
||||
description: Reference vestavěných skills základního modulu, plus samostatné myšlenkové skills a balíček BMad Analysis.
|
||||
sidebar:
|
||||
order: 3
|
||||
---
|
||||
|
||||
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.
|
||||
Každá instalace BMad zahrnuje **základní modul** — malou sadu skills, které fungují napříč všemi projekty, všemi moduly a všemi fázemi. Tato stránka pokrývá těchto pět základních skills, plus **samostatné myšlenkové skills** (brainstorming, forge idea, party mode), které se instalují zvlášť jako vlastní moduly — nejsnadněji přes balíček **BMad Analysis**.
|
||||
|
||||
:::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.
|
||||
Spusťte jakýkoli 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-spec`](#bmad-spec) | Workflow | Distill any intent input into a SPEC kernel and companions, the canonical contract for downstream work (translation pending) |
|
||||
| [`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 |
|
||||
**Základní modul (vždy nainstalován):**
|
||||
|
||||
| Nástroj | Účel |
|
||||
| --- | --- |
|
||||
| [`bmad-help`](#bmad-help) | Kontextové poradenství, co dělat dál |
|
||||
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | Iterativní zdokonalování LLM výstupu |
|
||||
| [`bmad-editorial-review`](#bmad-editorial-review) | Dvoufázová redakční revize — nejprve struktura, pak text |
|
||||
| [`bmad-review`](#bmad-review) | Kritická revize z více perspektiv — adversariální, hraniční případy a mezery ve verifikaci |
|
||||
| [`bmad-customize`](#bmad-customize) | Vytváření a ověřování přizpůsobení BMad |
|
||||
|
||||
**Samostatné myšlenkové skills (instalované přes [balíček BMad Analysis](../../reference/standalone-skills.md) nebo jednotlivě):**
|
||||
|
||||
| Nástroj | Účel |
|
||||
| --- | --- |
|
||||
| [`bmad-brainstorming`](#bmad-brainstorming) | Facilitace interaktivních brainstormingových sezení |
|
||||
| [`bmad-forge-idea`](#bmad-forge-idea) | Zátěžový test nápadu, dokud se nezpevní, nepotvrdí, nebo levně nezemře |
|
||||
| [`bmad-party-mode`](#bmad-party-mode) | Orchestrace skupinových diskuzí více agentů |
|
||||
|
||||
:::note[Přesunuto a odstraněno]
|
||||
`bmad-spec` se nyní dodává s modulem BMM jako plánovací workflow Fáze 2 — viz [Mapa workflow](./workflow-map.md). Utility `bmad-shard-doc` a `bmad-index-docs` byly odstraněny. Dřívější skills `bmad-editorial-review-prose`, `bmad-editorial-review-structure`, `bmad-review-adversarial-general`, `bmad-review-edge-case-hunter` a `bmad-review-verification-gap` jsou sloučeny do `bmad-editorial-review` a `bmad-review`; staré identifikátory se stále rozliší přes skryté přesměrování kvůli kompatibilitě.
|
||||
:::
|
||||
|
||||
## bmad-help
|
||||
|
||||
@@ -49,7 +57,115 @@ Spusťte jakýkoli základní nástroj zadáním jeho názvu skillu (např. `bma
|
||||
|
||||
**Výstup:** Prioritizovaný seznam doporučených dalších kroků s příkazy skills
|
||||
|
||||
## bmad-brainstorming
|
||||
## bmad-advanced-elicitation
|
||||
|
||||
**Přiměje LLM přehodnotit, zdokonalit a vylepšit svůj nedávný výstup.** — Sdílený zdokonalovací checkpoint BMad: ostatní skills jej vyvolávají při přirozených pauzách a vy jej můžete zavolat přímo na cokoli nedávného v konverzaci.
|
||||
|
||||
**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í
|
||||
- Chcete známou metodu jménem — sokratovská, první principy, pre-mortem, red team
|
||||
|
||||
**Jak to funguje:**
|
||||
|
||||
1. Cílí na nejnovější výstup v konverzaci, pokud jej nenasměrujete jinam
|
||||
2. Nabídne krátké menu elicitačních metod nejlépe odpovídajících obsahu
|
||||
3. Aplikuje zvolené metody na cíl
|
||||
4. Vrátí vylepšenou verzi, aby vyvolávající tok pokračoval tam, kde se zastavil
|
||||
|
||||
**Vstup:** Nedávný výstup ke zdokonalení (výchozí), nebo jakýkoli obsah, na který ukážete; volitelně pojmenovaná metoda
|
||||
|
||||
**Výstup:** Vylepšená verze obsahu s aplikovanými zlepšeními
|
||||
|
||||
## bmad-editorial-review
|
||||
|
||||
**Dvoufázová redakční revize — nejprve struktura, pak text.** — Klinický editor, který reviduje tvar dokumentu i jeho věty a vrací navrhované opravy, jež řádek po řádku přijímáte nebo odmítáte. Obsah je nedotknutelný: nikdy nezpochybňuje vaše myšlenky, jen jejich organizaci a vyjádření.
|
||||
|
||||
**Použijte když:**
|
||||
|
||||
- Napsali jste dokument a chcete jej zpřísnit a vyladit
|
||||
- Dokument vznikl z více podprocesů a potřebuje strukturální soudržnost
|
||||
- Chcete zkrátit délku při zachování srozumitelnosti
|
||||
- Potřebujete opravy srozumitelnosti bez stylistických zásahů
|
||||
|
||||
**Jak to funguje:**
|
||||
|
||||
1. **Strukturální fáze** — navrhuje škrty, sloučení, přesuny a zhuštění; ptá se, zda tvar dokumentu slouží jeho účelu
|
||||
2. **Textová fáze** — koriguje komunikační problémy bránící porozumění, s Microsoft Writing Style Guide jako výchozí baseline (dodaný průvodce stylem má přednost)
|
||||
3. Ve výchozím stavu běží obě fáze, nejprve struktura; požádejte o revizi jen struktury nebo jen textu, chcete-li spustit jednu
|
||||
4. Navrhuje, nikdy neprovádí — o přijetí rozhoduje autor
|
||||
|
||||
**Vstup:**
|
||||
|
||||
- `content` (povinné) — Dokument k revizi
|
||||
- `style_guide` (volitelné) — Projektově specifický průvodce stylem
|
||||
- `reader_type` (volitelné) — `humans` (výchozí) pro srozumitelnost/plynulost, nebo `llm` pro přesnost/konzistenci
|
||||
- `purpose` / `target_audience` / `length_target` (volitelné) — kalibrují strukturální fázi
|
||||
|
||||
**Výstup:** Tabulka nálezů s navrhovanými opravami, plus odhad zkrácení při navržených strukturálních změnách
|
||||
|
||||
## bmad-review
|
||||
|
||||
**Kritická revize z více perspektiv nad jakýmkoli diffem, dokumentem nebo artefaktem.** — Spouští nezávislé revizní perspektivy — každou s vlastní metodou a postojem — a hlásí každý nález v jednom kanonickém tvaru. Nula nálezů je platný výsledek; nikdy nedoplňuje, aby vypadal důkladně.
|
||||
|
||||
**Dodávané perspektivy:**
|
||||
|
||||
| Perspektiva | Metoda |
|
||||
| --- | --- |
|
||||
| **Adversariální** | Skeptická revize předpokládající existenci problémů — hledá, co chybí, ne jen co je špatně |
|
||||
| **Hraniční případy** | Projde každou větvící se cestu a hraniční podmínku, hlásí pouze neošetřené cesty |
|
||||
| **Mezery ve verifikaci** | Hledá změněné chování, které by mohlo regredovat, aniž by to spolehlivá verifikace zachytila |
|
||||
|
||||
**Použijte když:**
|
||||
|
||||
- Potřebujete zajištění kvality před finalizací výstupu
|
||||
- Chcete vyčerpávající pokrytí hraničních případů kódu nebo logiky
|
||||
- Chcete vědět, zda je změna dostatečně ověřena
|
||||
- Chcete všechny tři perspektivy najednou (výchozí chování)
|
||||
|
||||
**Jak to funguje:**
|
||||
|
||||
1. Načte obsah a identifikuje jeho typ — diff, soubor, funkce nebo dokument
|
||||
2. Vybere perspektivy: ty, které pojmenujete, nebo každou povolenou perspektivu odpovídající obsahu
|
||||
3. Spustí každou perspektivu nezávisle — paralelně přes subagenty, pokud to platforma podporuje
|
||||
4. Sestaví jeden seznam nálezů; překryv mezi perspektivami je signál, ne duplikace
|
||||
|
||||
**Vstup:**
|
||||
|
||||
- `content` (povinné) — Diff, větev, nezakomitované změny, soubor, specifikace, story nebo jakýkoli dokument
|
||||
- `lenses` (volitelné) — jeden nebo více kódů či názvů perspektiv; výchozí je plná revize
|
||||
- `also_consider` (volitelné) — Další oblasti k zvážení
|
||||
|
||||
**Výstup:** JSON pole nálezů a/nebo markdown report seskupený podle perspektiv. Vlastní perspektivy lze přidat — a dodávané doladit či vypnout — přes `customize.toml` skillu
|
||||
|
||||
## bmad-customize
|
||||
|
||||
**Vytváření a ověřování přizpůsobení.** — Pomůže vám změnit chování nainstalovaného BMad agenta nebo workflow bez ručního psaní TOML.
|
||||
|
||||
**Použijte když:**
|
||||
|
||||
- Chcete změnit chování agenta nebo workflow
|
||||
- Potřebujete přidat trvalé fakty, aktivační hooky nebo vlastní položky menu
|
||||
- Chcete, aby byl správný rozsah přepisu vybrán a ověřen automaticky
|
||||
|
||||
**Jak to funguje:**
|
||||
|
||||
1. Skenuje nainstalované BMad skills pro přizpůsobitelné plochy
|
||||
2. Vybere správný rozsah pro požadovanou změnu
|
||||
3. Zapíše přepisové soubory pod `_bmad/custom/`
|
||||
4. Ověří sloučenou konfiguraci
|
||||
|
||||
**Vstup:** Popis požadovaného přizpůsobení v přirozeném jazyce
|
||||
|
||||
**Výstup:** TOML přepisové soubory pod `_bmad/custom/`. Podrobný návod viz [Jak přizpůsobit BMad](../how-to/customize-bmad.md)
|
||||
|
||||
## Samostatné myšlenkové skills
|
||||
|
||||
Tři skills níže nejsou součástí základního modulu. Každý je vlastním modulem s jediným skillem, skrytým ve výběru instalátoru, a dorazí buď přes viditelný balíček **BMad Analysis**, nebo když jej jiný modul deklaruje jako závislost. Jak to funguje, viz [Samostatné skills a závislosti modulů](../../reference/standalone-skills.md).
|
||||
|
||||
### 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í.
|
||||
|
||||
@@ -65,17 +181,38 @@ Spusťte jakýkoli základní nástroj zadáním jeho názvu skillu (např. `bma
|
||||
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
|
||||
**Výstup:** samostatný `brainstorm.html` jako památka na sezení, volitelný `brainstorm-intent.md` pro navazující skills a záznam sezení `.memlog.md`
|
||||
|
||||
:::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
|
||||
### bmad-forge-idea
|
||||
|
||||
**Zátěžový test nápadu, dokud se nezpevní, nepotvrdí, nebo levně nezemře.** — Adversariální tazatel žene napůl zformovaný nápad otázku po otázce, do každého větvení přivádí dvě postavy, dokud to, co přežije, není něco, na čem můžete s přesvědčením stavět.
|
||||
|
||||
**Použijte když:**
|
||||
|
||||
- Máte nápad a chcete jej otestovat, než do něj investujete
|
||||
- Chcete upřímný pohled na to, zda jej zabít
|
||||
- Potřebujete myšlenkového partnera, který se vzepře, místo aby souhlasil
|
||||
|
||||
**Jak to funguje:**
|
||||
|
||||
1. Předem stanoví cíl a podle něj směruje dotazování
|
||||
2. Pracuje otázku po otázce v pořadí závislostí a předkládá doporučenou odpověď, proti které se lze vymezit
|
||||
3. Do každého větvení přivádí dva hlasy — jeden z vaší nainstalované sestavy, jeden vyvolaný tématem
|
||||
4. Zpochybňuje mlhavé pojmy a testuje tvrzení proti materiálu existujícího projektu
|
||||
5. Končí jako Zpevněný, Zabitý nebo Jasnější, se samostatným reportem, který si můžete ponechat
|
||||
|
||||
**Vstup:** Nápad z jakékoli domény — funkce, byznys model, výzkumná hypotéza, životní rozhodnutí
|
||||
|
||||
**Výstup:** Destilát `forged-idea.md`, když se nápad zpevní (volitelné), plus `forge-report.html` z každého běhu
|
||||
|
||||
### 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í.
|
||||
|
||||
@@ -96,171 +233,3 @@ Kouzlo se děje v nápadech 50–100. Workflow povzbuzuje generování 100+ náp
|
||||
**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-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
|
||||
|
||||
@@ -36,7 +36,7 @@ Definujte, co budovat a pro koho.
|
||||
|
||||
| Workflow | Účel | Produkuje |
|
||||
| --------------------------- | ---------------------------------------- | ------------ |
|
||||
| `bmad-create-prd` | Definice požadavků (FR/NFR) | `PRD.md` |
|
||||
| `bmad-prd` | Definice požadavků (FR/NFR) | `PRD.md` |
|
||||
| `bmad-ux` | Návrh uživatelského zážitku (když záleží na UX) | `DESIGN.md`, `EXPERIENCE.md` |
|
||||
|
||||
## Fáze 3: Solutioning
|
||||
@@ -45,7 +45,7 @@ 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-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 |
|
||||
|
||||
|
||||
@@ -114,7 +114,7 @@ BMad-Help detekuje, co jste dokončili, a doporučí přesně, co dělat dál. M
|
||||
:::
|
||||
|
||||
:::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).
|
||||
Každý workflow má **skill**, který vyvoláte jménem ve vašem IDE (např. `bmad-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]
|
||||
@@ -143,7 +143,7 @@ Všechny workflow v této fázi jsou volitelné:
|
||||
|
||||
**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`)
|
||||
2. Spusťte workflow `bmad-prd` (`bmad-prd`)
|
||||
3. Výstup: `PRD.md`
|
||||
|
||||
**Pro Quick Flow cestu:**
|
||||
@@ -157,7 +157,7 @@ Pokud má váš projekt uživatelské rozhraní, vyvolejte **UX-Designer agenta*
|
||||
|
||||
**Vytvoření architektury**
|
||||
1. Vyvolejte **Architect agenta** (`bmad-agent-architect`) v novém chatu
|
||||
2. Spusťte `bmad-create-architecture` (`bmad-create-architecture`)
|
||||
2. Spusťte `bmad-architecture` (`bmad-architecture`)
|
||||
3. Výstup: Dokument architektury s technickými rozhodnutími
|
||||
|
||||
**Vytvoření epiců a stories**
|
||||
@@ -225,8 +225,8 @@ váš-projekt/
|
||||
| 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-prd` | `bmad-prd` | PM | Vytvoření dokumentu požadavků (PRD) |
|
||||
| `bmad-architecture` | `bmad-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í |
|
||||
|
||||
@@ -13,6 +13,8 @@ Run `bmad-forge-idea` and an exacting interrogator goes to work on your idea, on
|
||||
|
||||
What you walk away with is sharper thinking. A distilled `forged-idea.md` is only ever one possible exit, and the session never herds you toward "shall we build it?"
|
||||
|
||||
Forge Idea is a standalone skill module. It installs with the **BMad Analysis** pack (select `BMad Analysis` in the installer) or whenever another installed module depends on it — see [Standalone Skills & Module Dependencies](../reference/standalone-skills.md).
|
||||
|
||||
## Why Pressure-Test Early
|
||||
|
||||
The enemy is the hole you can't see in your own idea. An unexamined assumption or an unresolved branch is a crack, and a crack you miss now resurfaces later — in the build, or the launch, when it costs far more to fix.
|
||||
@@ -57,7 +59,7 @@ Reach for the forge when you already hold an idea and want it hardened or killed
|
||||
| `bmad-prfaq` | You've committed to a product and want it proven customer-first | A Working Backwards coach |
|
||||
| `bmad-brainstorming` | You have no idea yet and need to generate options | A facilitation coach |
|
||||
| `bmad-party-mode` | You want your agents to discuss or decide together | Your whole roster in one conversation |
|
||||
| `bmad-review-adversarial-general` | You have an artifact and need its flaws found | A reviewer who must find issues |
|
||||
| `bmad-review` | You have an artifact and need its flaws found | A multi-lens reviewer hunting real issues |
|
||||
|
||||
## Example
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ The `project-context.md` file solves this by documenting what agents need to kno
|
||||
Every implementation workflow automatically loads `project-context.md` if it exists. The architect workflow also loads it to respect your technical preferences when designing the architecture.
|
||||
|
||||
**Loaded by these workflows:**
|
||||
- `bmad-create-architecture` — respects technical preferences during solutioning
|
||||
- `bmad-architecture` — respects technical preferences during solutioning
|
||||
- `bmad-create-story` — informs story creation with project patterns
|
||||
- `bmad-dev-story` — guides implementation decisions
|
||||
- `bmad-code-review` — validates against project standards
|
||||
@@ -34,7 +34,7 @@ The `project-context.md` file is useful at any stage of a project:
|
||||
|
||||
| Scenario | When to Create | Purpose |
|
||||
|----------|----------------|---------|
|
||||
| **New project, before architecture** | Manually, before `bmad-create-architecture` | Document your technical preferences so the architect respects them |
|
||||
| **New project, before architecture** | Manually, before `bmad-architecture` | Document your technical preferences so the architect respects them |
|
||||
| **New project, after architecture** | Via `bmad-generate-project-context` or manually | Capture architecture decisions for implementation agents |
|
||||
| **Existing project** | Via `bmad-generate-project-context` | Discover existing patterns so agents follow established conventions |
|
||||
| **Quick Flow project** | Before or during `bmad-quick-dev` | Ensure quick implementation respects your patterns |
|
||||
|
||||
@@ -21,7 +21,7 @@ Le fichier `project-context.md` résout ce problème en documentant ce que les a
|
||||
Chaque workflow d’implémentation charge automatiquement `project-context.md` s’il existe. Le workflow architecte le charge également pour respecter vos préférences techniques lors de la conception de l’architecture.
|
||||
|
||||
**Chargé par ces workflows :**
|
||||
- `bmad-create-architecture` — respecte les préférences techniques pendant la phase de solutioning
|
||||
- `bmad-architecture` — respecte les préférences techniques pendant la phase de solutioning
|
||||
- `bmad-create-story` — informe la création de stories avec les patterns du projet
|
||||
- `bmad-dev-story` — guide les décisions d’implémentation
|
||||
- `bmad-code-review` — valide par rapport aux standards du projet
|
||||
@@ -34,7 +34,7 @@ Le fichier `project-context.md` est utile à n’importe quel stade d’un proje
|
||||
|
||||
| Scénario | Quand Créer | Objectif |
|
||||
|------------------------------------------|-----------------------------------------------------|---------------------------------------------------------------------------------------|
|
||||
| **Nouveau projet, avant l’architecture** | Manuellement, avant `bmad-create-architecture` | Documenter vos préférences techniques pour que l’architecte les respecte |
|
||||
| **Nouveau projet, avant l’architecture** | Manuellement, avant `bmad-architecture` | Documenter vos préférences techniques pour que l’architecte les respecte |
|
||||
| **Nouveau projet, après l’architecture** | Via `bmad-generate-project-context` ou manuellement | Capturer les décisions d’architecture pour les agents d’implémentation |
|
||||
| **Projet existant** | Via `bmad-generate-project-context` | Découvrir les patterns existants pour que les agents suivent les conventions établies |
|
||||
| **Projet Quick Dev** | Avant ou pendant `bmad-quick-dev` | Garantir que l’implémentation rapide respecte vos patterns |
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: 'Comment étendre BMad pour votre organisation'
|
||||
description: Six patterns de personnalisation qui remodèlent BMad sans créer de fork — règles applicables aux agents, conventions de workflow, publication externe, remplacements de templates, modifications du registre des agents et patterns d’intégration avancés
|
||||
sidebar:
|
||||
order: 11
|
||||
order: 10
|
||||
---
|
||||
|
||||
Le système de personnalisation de BMad permet à une organisation d’adapter les comportements sans modifier les fichiers installés ni forker les skills. Ce guide présente six recettes qui couvrent la plupart des besoins en entreprise.
|
||||
|
||||
@@ -1,78 +0,0 @@
|
||||
---
|
||||
title: "Guide de Division de Documents"
|
||||
description: Diviser les fichiers markdown volumineux en fichiers plus petits et organisés pour une meilleure gestion du contexte
|
||||
sidebar:
|
||||
order: 10
|
||||
---
|
||||
|
||||
Utilisez l’outil `bmad-shard-doc` si vous avez besoin de diviser des fichiers markdown volumineux en fichiers plus petits et organisés pour une meilleure gestion du contexte.
|
||||
|
||||
:::caution[Déprécié]
|
||||
Ceci n’est plus recommandé, et bientôt avec les workflows mis à jour et la plupart des LLM et outils majeurs supportant les sous-processus, cela deviendra inutile.
|
||||
:::
|
||||
|
||||
## Quand l’Utiliser
|
||||
|
||||
Utilisez ceci uniquement si vous remarquez que votre combinaison outil / modèle ne parvient pas à charger et lire tous les documents en entrée lorsque c’est nécessaire.
|
||||
|
||||
## Qu’est-ce que la Division de Documents ?
|
||||
|
||||
La division de documents divise les fichiers markdown volumineux en fichiers plus petits et organisés basés sur les titres de niveau 2 (`## Titre`).
|
||||
|
||||
### Architecture
|
||||
|
||||
```text
|
||||
Avant Division :
|
||||
_bmad-output/planning-artifacts/
|
||||
└── PRD.md (fichier volumineux de 50k tokens)
|
||||
|
||||
Après Division :
|
||||
_bmad-output/planning-artifacts/
|
||||
└── prd/
|
||||
├── index.md # Table des matières avec descriptions
|
||||
├── overview.md # Section 1
|
||||
├── user-requirements.md # Section 2
|
||||
├── technical-requirements.md # Section 3
|
||||
└── ... # Sections supplémentaires
|
||||
```
|
||||
|
||||
## Étapes
|
||||
|
||||
### 1. Exécuter l’Outil Shard-Doc
|
||||
|
||||
```bash
|
||||
/bmad-shard-doc
|
||||
```
|
||||
|
||||
### 2. Suivre le Processus Interactif
|
||||
|
||||
```text
|
||||
Agent : Quel document souhaitez-vous diviser ?
|
||||
Utilisateur : docs/PRD.md
|
||||
|
||||
Agent : Destination par défaut : docs/prd/
|
||||
Accepter la valeur par défaut ? [y/n]
|
||||
Utilisateur : y
|
||||
|
||||
Agent : Division de PRD.md...
|
||||
✓ 12 fichiers de section créés
|
||||
✓ index.md généré
|
||||
✓ Terminé !
|
||||
```
|
||||
|
||||
## Comment Fonctionne la Découverte de Workflow
|
||||
|
||||
Les workflows BMad utilisent un **système de découverte double** :
|
||||
|
||||
1. **Essaye d’abord le document entier** - Rechercher `document-name.md`
|
||||
2. **Vérifie la version divisée** - Rechercher `document-name/index.md`
|
||||
3. **Règle de priorité** - Le document entier a la priorité si les deux existent - supprimez le document entier si vous souhaitez que la version divisée soit utilisée à la place
|
||||
|
||||
## Support des Workflows
|
||||
|
||||
Tous les workflows BMM prennent en charge les deux formats :
|
||||
|
||||
- Documents entiers
|
||||
- Documents divisés
|
||||
- Détection automatique
|
||||
- Transparent pour l’utilisateur
|
||||
@@ -94,7 +94,7 @@ Les skills de workflow exécutent un processus structuré en plusieurs étapes s
|
||||
| `bmad-product-brief` | Créer ou mettre à jour un product brief[^3] — découverte guidée lorsque votre concept est clair |
|
||||
| `bmad-prfaq` | Défi [PRFAQ Working Backwards](../explanation/analysis-phase.md#prfaq-working-backwards) pour éprouver votre concept produit |
|
||||
| `bmad-prd` | Créer, mettre à jour ou valider un PRD[^1] |
|
||||
| `bmad-create-architecture` | Concevoir l’architecture système |
|
||||
| `bmad-architecture` | Concevoir l’architecture système |
|
||||
| `bmad-create-epics-and-stories` | Créer des epics et des stories |
|
||||
| `bmad-dev-story` | Implémenter une story |
|
||||
| `bmad-code-review` | Effectuer une revue de code |
|
||||
@@ -120,7 +120,7 @@ bmad-help Quelles sont mes options pour le design UX ?
|
||||
|
||||
**Autres tâches et outils principaux**
|
||||
|
||||
Le module principal inclut 12 outils intégrés — specs, revues, brainstorming, personnalisation, gestion de documents, et plus. Consultez [Outils principaux](./core-tools.md) pour la référence complète.
|
||||
Le module principal inclut 5 outils intégrés — aide, revues, raffinement et personnalisation — et le pack optionnel BMad Analysis ajoute les compétences de réflexion autonomes (brainstorming, forge idea, party mode). Consultez [Outils principaux](./core-tools.md) pour la référence complète.
|
||||
|
||||
## Convention de nommage
|
||||
|
||||
|
||||
+174
-259
@@ -1,92 +1,234 @@
|
||||
---
|
||||
title: Outils Principaux
|
||||
description: Référence pour toutes les tâches et tous les workflows intégrés disponibles dans chaque installation BMad sans modules supplémentaires.
|
||||
description: Référence des compétences intégrées du module principal, plus les compétences de réflexion autonomes et le pack BMad Analysis.
|
||||
sidebar:
|
||||
order: 3
|
||||
---
|
||||
|
||||
Chaque installation BMad comprend un ensemble de compétences principales utilisables en complément de tout ce que vous faites — des tâches et des workflows autonomes qui fonctionnent dans tous les projets, tous les modules et toutes les phases. Elles restent toujours disponibles, quels que soient les modules optionnels que vous installez.
|
||||
Chaque installation BMad comprend le **module principal** — un petit ensemble de compétences qui fonctionnent dans tous les projets, tous les modules et toutes les phases. Cette page couvre ces cinq compétences principales, ainsi que les **compétences de réflexion autonomes** (brainstorming, forge idea, party mode) qui s’installent séparément en tant que modules à part entière — le plus simplement via le pack **BMad Analysis**.
|
||||
|
||||
:::tip[Raccourci Rapide]
|
||||
Exécutez n’importe quel outil principal en tapant son nom de compétence (par ex., `bmad-help`) dans votre IDE. Aucune session d’agent requise.
|
||||
Exécutez n’importe quel outil en tapant son nom de compétence (par ex., `bmad-help`) dans votre IDE. Aucune session d’agent requise.
|
||||
:::
|
||||
|
||||
## Vue d’ensemble
|
||||
|
||||
| Outil | Type | Objectif |
|
||||
|-----------------------------------------------------------------------|----------|-------------------------------------------------------------------------------|
|
||||
| [`bmad-help`](#bmad-help) | Tâche | Obtenir des conseils contextuels sur la prochaine étape |
|
||||
| [`bmad-brainstorming`](#bmad-brainstorming) | Workflow | Faciliter des sessions de brainstorming interactives |
|
||||
| [`bmad-party-mode`](#bmad-party-mode) | Workflow | Orchestrer des discussions de groupe multi-agents |
|
||||
| [`bmad-spec`](#bmad-spec) | Workflow | Distiller toute formulation d’intention en un noyau SPEC et fichiers associés |
|
||||
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | Tâche | Soumettre la sortie LLM à des méthodes de raffinement itératives |
|
||||
| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | Tâche | Revue cynique qui traque ce qui manque et ce qui ne va pas |
|
||||
| [`bmad-review-edge-case-hunter`](#bmad-review-edge-case-hunter) | Tâche | Analyse exhaustive des chemins de branchement pour les cas limites non gérés |
|
||||
| [`bmad-editorial-review-prose`](#bmad-editorial-review-prose) | Tâche | Correction éditoriale clinique pour la clarté de communication |
|
||||
| [`bmad-editorial-review-structure`](#bmad-editorial-review-structure) | Tâche | Édition structurelle — coupes, fusions et réorganisation |
|
||||
| [`bmad-shard-doc`](#bmad-shard-doc) | Tâche | Diviser les fichiers markdown volumineux en sections organisées |
|
||||
| [`bmad-index-docs`](#bmad-index-docs) | Tâche | Générer ou mettre à jour un index de tous les documents dans un dossier |
|
||||
| [`bmad-customize`](#bmad-customize) | Tâche | Créer et vérifier des personnalisations BMad |
|
||||
**Module principal (toujours installé) :**
|
||||
|
||||
| Outil | Objectif |
|
||||
| --- | --- |
|
||||
| [`bmad-help`](#bmad-help) | Obtenir des conseils contextuels sur la prochaine étape |
|
||||
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | Soumettre la sortie LLM à des méthodes de raffinement itératives |
|
||||
| [`bmad-editorial-review`](#bmad-editorial-review) | Revue éditoriale en deux passes — structure, puis prose |
|
||||
| [`bmad-review`](#bmad-review) | Revue critique multi-perspectives — contradictoire, cas limites et lacunes de vérification |
|
||||
| [`bmad-customize`](#bmad-customize) | Créer et vérifier des personnalisations BMad |
|
||||
|
||||
**Compétences de réflexion autonomes (installées via le [pack BMad Analysis](../../reference/standalone-skills.md) ou individuellement) :**
|
||||
|
||||
| Outil | Objectif |
|
||||
| --- | --- |
|
||||
| [`bmad-brainstorming`](#bmad-brainstorming) | Faciliter des sessions de brainstorming interactives |
|
||||
| [`bmad-forge-idea`](#bmad-forge-idea) | Éprouver une idée jusqu’à ce qu’elle se consolide, se confirme ou meure à moindre coût |
|
||||
| [`bmad-party-mode`](#bmad-party-mode) | Orchestrer des discussions de groupe multi-agents |
|
||||
|
||||
:::note[Déplacés et supprimés]
|
||||
`bmad-spec` fait désormais partie du module BMM comme workflow de planification de Phase 2 — voir la [Carte des Workflows](./workflow-map.md). Les utilitaires `bmad-shard-doc` et `bmad-index-docs` ont été supprimés. Les anciennes compétences `bmad-editorial-review-prose`, `bmad-editorial-review-structure`, `bmad-review-adversarial-general`, `bmad-review-edge-case-hunter` et `bmad-review-verification-gap` sont fusionnées dans `bmad-editorial-review` et `bmad-review` ; les anciens identifiants restent résolus via des redirections masquées pour la compatibilité.
|
||||
:::
|
||||
|
||||
## bmad-help
|
||||
|
||||
**Votre guide intelligent pour la suite.** — Inspecte l’état de votre projet, détecte ce qui a été fait et recommande la prochaine étape requise ou facultative.
|
||||
|
||||
**À utiliser quand :**
|
||||
**À utiliser quand :**
|
||||
|
||||
- Vous avez terminé un workflow et voulez savoir quoi faire ensuite
|
||||
- Vous êtes nouveau sur BMad et avez besoin d’orientation
|
||||
- Vous êtes bloqué et voulez des conseils contextuels
|
||||
- Vous avez installé de nouveaux modules et voulez voir ce qui est disponible
|
||||
|
||||
**Fonctionnement :**
|
||||
**Fonctionnement :**
|
||||
|
||||
1. Analyse votre projet pour détecter les artefacts existants (PRD, architecture, stories, etc.)
|
||||
2. Détecte quels modules sont installés et leurs workflows disponibles
|
||||
3. Recommande les prochaines étapes par ordre de priorité — étapes requises d’abord, puis facultatives
|
||||
4. Présente chaque recommandation avec la commande de compétence et une brève description
|
||||
|
||||
**Entrée :** Requête optionnelle en langage naturel (par ex., `bmad-help J'ai une idée de SaaS, par où commencer ?`)
|
||||
**Entrée :** Requête optionnelle en langage naturel (par ex., `bmad-help J'ai une idée de SaaS, par où commencer ?`)
|
||||
|
||||
**Sortie :** Liste priorisée des prochaines étapes recommandées avec les commandes de compétence
|
||||
**Sortie :** Liste priorisée des prochaines étapes recommandées avec les commandes de compétence
|
||||
|
||||
## bmad-brainstorming
|
||||
## bmad-advanced-elicitation
|
||||
|
||||
**Pousse le LLM à reconsidérer, raffiner et améliorer sa sortie récente.** — Le point de contrôle de raffinement partagé de BMad : d’autres compétences l’invoquent aux pauses naturelles, et vous pouvez l’appeler directement sur tout contenu récent de la conversation.
|
||||
|
||||
**À utiliser quand :**
|
||||
|
||||
- La sortie du LLM semble superficielle ou générique
|
||||
- Vous voulez explorer un sujet sous plusieurs angles analytiques
|
||||
- Vous raffinez un document critique et souhaitez une réflexion plus approfondie
|
||||
- Vous voulez une méthode connue par son nom — socratique, premiers principes, pré-mortem, red team
|
||||
|
||||
**Fonctionnement :**
|
||||
|
||||
1. Cible la sortie la plus récente de la conversation, sauf si vous la pointez ailleurs
|
||||
2. Propose un court menu de méthodes d’élicitation adaptées au contenu
|
||||
3. Applique les méthodes choisies sur la cible
|
||||
4. Restitue la version améliorée pour que le flux appelant reprenne où il s’était arrêté
|
||||
|
||||
**Entrée :** La sortie récente à raffiner (par défaut), ou tout contenu que vous désignez ; éventuellement une méthode nommée
|
||||
|
||||
**Sortie :** Version améliorée du contenu avec les améliorations appliquées
|
||||
|
||||
## bmad-editorial-review
|
||||
|
||||
**Revue éditoriale en deux passes — structure, puis prose.** — Un éditeur clinique qui examine la forme d’un document et ses phrases, et propose des corrections que vous acceptez ou refusez ligne par ligne. Le contenu est sacré : il ne remet jamais en question vos idées, seulement leur organisation et leur expression.
|
||||
|
||||
**À utiliser quand :**
|
||||
|
||||
- Vous avez rédigé un document et voulez le resserrer et le polir
|
||||
- Un document issu de plusieurs sous-processus a besoin de cohérence structurelle
|
||||
- Vous voulez réduire la longueur tout en préservant la compréhension
|
||||
- Vous voulez des corrections de clarté sans modifier les choix stylistiques
|
||||
|
||||
**Fonctionnement :**
|
||||
|
||||
1. **Passe structure** — propose des coupes, fusions, déplacements et condensations ; interroge si la forme du document sert son objectif
|
||||
2. **Passe prose** — corrige les problèmes de communication qui nuisent à la compréhension, avec le Microsoft Writing Style Guide comme référence (un guide de style fourni prévaut)
|
||||
3. Exécute les deux passes, structure d’abord, par défaut ; demandez une revue structure seule ou prose seule pour n’en exécuter qu’une
|
||||
4. Propose, n’exécute jamais — l’auteur décide de ce qu’il accepte
|
||||
|
||||
**Entrée :**
|
||||
|
||||
- `content` (requis) — Document à réviser
|
||||
- `style_guide` (optionnel) — Guide de style spécifique au projet
|
||||
- `reader_type` (optionnel) — `humans` (par défaut) pour clarté/fluidité, ou `llm` pour précision/consistance
|
||||
- `purpose` / `target_audience` / `length_target` (optionnel) — calibrent la passe structure
|
||||
|
||||
**Sortie :** Tableau de constatations avec corrections suggérées, plus une estimation de réduction lorsque des changements structurels sont proposés
|
||||
|
||||
## bmad-review
|
||||
|
||||
**Revue critique multi-perspectives sur tout diff, document ou artefact.** — Exécute des perspectives de revue indépendantes — chacune avec sa méthode et sa posture propres — et rapporte chaque constatation dans un format canonique unique. Zéro constatation est un résultat valide ; il ne remplit jamais pour paraître exhaustif.
|
||||
|
||||
**Les perspectives livrées :**
|
||||
|
||||
| Perspective | Méthode |
|
||||
| --- | --- |
|
||||
| **Contradictoire** | Revue sceptique qui part du principe que des problèmes existent — traque ce qui manque, pas seulement ce qui ne va pas |
|
||||
| **Cas limites** | Parcourt chaque chemin de branchement et condition aux limites, ne rapporte que les chemins non gérés |
|
||||
| **Lacunes de vérification** | Trouve les comportements modifiés qui pourraient régresser sans qu’une vérification fiable ne le détecte |
|
||||
|
||||
**À utiliser quand :**
|
||||
|
||||
- Vous avez besoin d’assurance qualité avant de finaliser un livrable
|
||||
- Vous voulez une couverture exhaustive des cas limites d’un code ou d’une logique
|
||||
- Vous voulez savoir si un changement est correctement vérifié
|
||||
- Vous voulez les trois perspectives à la fois (le comportement par défaut)
|
||||
|
||||
**Fonctionnement :**
|
||||
|
||||
1. Charge le contenu et identifie son type — diff, fichier, fonction ou document
|
||||
2. Sélectionne les perspectives : celles que vous nommez, ou toutes les perspectives activées adaptées au contenu
|
||||
3. Exécute chaque perspective indépendamment — en parallèle via des sous-agents lorsque la plateforme le permet
|
||||
4. Assemble une liste unique de constatations ; le chevauchement entre perspectives est un signal, pas une duplication
|
||||
|
||||
**Entrée :**
|
||||
|
||||
- `content` (requis) — Diff, branche, changements non commités, fichier, spécification, story ou tout document
|
||||
- `lenses` (optionnel) — un ou plusieurs codes ou noms de perspectives ; par défaut, revue complète
|
||||
- `also_consider` (optionnel) — Domaines supplémentaires à garder à l’esprit
|
||||
|
||||
**Sortie :** Liste de constatations JSON (chaque constatation porte `lens`, `location`, `trigger_condition`, `guard_snippet`, `potential_consequence`) et/ou rapport markdown groupé par perspective
|
||||
|
||||
:::note[Utilisé par d’autres workflows]
|
||||
Les workflows de Code Review d’autres modules exécutent ces perspectives automatiquement. Des perspectives personnalisées peuvent être ajoutées — et celles livrées ajustées ou désactivées — via le `customize.toml` de la compétence.
|
||||
:::
|
||||
|
||||
## bmad-customize
|
||||
|
||||
**Créer et vérifier des personnalisations.** — Vous aide à modifier le comportement d’un agent ou d’un workflow BMad installé sans avoir à écrire de TOML manuellement.
|
||||
|
||||
**À utiliser quand :**
|
||||
|
||||
- Vous souhaitez modifier le comportement d’un agent ou d’un workflow
|
||||
- Vous devez ajouter des faits persistants, des hooks d’activation ou des éléments de menu personnalisés
|
||||
- Vous voulez que le bon périmètre de surcharge soit sélectionné et vérifié automatiquement
|
||||
|
||||
**Fonctionnement :**
|
||||
|
||||
1. Analyse les skills BMad installés pour identifier les surfaces personnalisables
|
||||
2. Sélectionne le bon périmètre pour le changement demandé
|
||||
3. Écrit les fichiers de surcharge sous `_bmad/custom/`
|
||||
4. Vérifie la configuration fusionnée
|
||||
|
||||
**Entrée :** Description en langage naturel de la personnalisation souhaitée
|
||||
|
||||
**Sortie :** Fichiers de surcharge TOML sous `_bmad/custom/`
|
||||
|
||||
Pour un guide détaillé sur la personnalisation de BMad, consultez [Comment personnaliser BMad](../how-to/customize-bmad.md).
|
||||
|
||||
## Compétences de Réflexion Autonomes
|
||||
|
||||
Les trois compétences ci-dessous ne font pas partie du module principal. Chacune est son propre module mono-compétence, masqué dans le sélecteur de l’installateur, et arrive soit via le pack visible **BMad Analysis**, soit lorsqu’un autre module la déclare comme dépendance. Voir [Compétences Autonomes et Dépendances de Modules](../../reference/standalone-skills.md) pour le fonctionnement.
|
||||
|
||||
### bmad-brainstorming
|
||||
|
||||
**Génère des idées variées grâce à des techniques créatives interactives.** — Une session de brainstorming facilitée qui charge des méthodes d’idéation éprouvées à partir d’une bibliothèque de techniques et vous guide vers plus de 100 idées avant de les organiser.
|
||||
|
||||
**À utiliser quand :**
|
||||
**À utiliser quand :**
|
||||
|
||||
- Vous commencez un nouveau projet et devez explorer l’espace problème
|
||||
- Vous êtes bloqué dans la génération d’idées et avez besoin de créativité structurée
|
||||
- Vous voulez utiliser des cadres d’idéation éprouvés (SCAMPER, brainstorming inversé, etc.)
|
||||
|
||||
**Fonctionnement :**
|
||||
**Fonctionnement :**
|
||||
|
||||
1. Configure une session de brainstorming avec votre sujet
|
||||
2. Charge les techniques créatives à partir d’une bibliothèque de méthodes
|
||||
3. Vous guide de technique en technique, en générant des idées
|
||||
4. Applique un protocole anti-biais — bascule de domaine créatif toutes les 10 idées pour éviter les biais de regroupement
|
||||
5. Produit un document de session en mode ajout uniquement avec toutes les idées organisées par technique
|
||||
|
||||
**Entrée :** Sujet de brainstorming ou énoncé de problème, fichier de contexte optionnel
|
||||
**Entrée :** Sujet de brainstorming ou énoncé de problème, fichier de contexte optionnel
|
||||
|
||||
**Sortie :** `brainstorming-session-{date}.md` avec toutes les idées générées
|
||||
**Sortie :** un `brainstorm.html` autonome comme souvenir de la session, un `brainstorm-intent.md` optionnel pour les compétences en aval, et un enregistrement de session `.memlog.md`
|
||||
|
||||
:::note[Cible de Quantité]
|
||||
La magie se produit dans les idées 50–100. Le workflow encourage la génération de plus de 100 idées avant organisation.
|
||||
:::
|
||||
|
||||
## bmad-party-mode
|
||||
### bmad-forge-idea
|
||||
|
||||
**Éprouve une idée jusqu’à ce qu’elle se consolide, se confirme ou meure à moindre coût.** — Un interrogateur contradictoire fait avancer une idée à moitié formée une question à la fois, en amenant deux personnages à chaque embranchement, jusqu’à ce que ce qui survit soit quelque chose sur quoi vous pouvez agir avec conviction.
|
||||
|
||||
**À utiliser quand :**
|
||||
|
||||
- Vous tenez une idée et voulez la mettre à l’épreuve avant d’y investir
|
||||
- Vous voulez un avis honnête sur l’opportunité de l’abandonner
|
||||
- Vous avez besoin d’un partenaire de réflexion qui résiste au lieu d’acquiescer
|
||||
|
||||
**Fonctionnement :**
|
||||
|
||||
1. Établit l’objectif dès le départ et oriente le questionnement en conséquence
|
||||
2. Travaille une question à la fois, dans l’ordre des dépendances, en posant une réponse recommandée à contester
|
||||
3. Amène deux voix à chaque embranchement — une de votre effectif installé, une évoquée par le sujet
|
||||
4. Conteste les termes flous et confronte les affirmations au matériau d’un projet existant
|
||||
5. Aboutit à Consolidée, Abandonnée ou Clarifiée, avec un rapport autonome que vous pouvez conserver
|
||||
|
||||
**Entrée :** L’idée, dans n’importe quel domaine — une fonctionnalité, un modèle économique, une hypothèse de recherche, une décision de vie
|
||||
|
||||
**Sortie :** Un distillat `forged-idea.md` quand une idée se consolide (optionnel), plus un souvenir `forge-report.html` à chaque exécution
|
||||
|
||||
### bmad-party-mode
|
||||
|
||||
**Orchestre des discussions de groupe multi-agents.** — Charge tous les agents BMad installés et facilite une conversation naturelle où chaque agent apporte son expertise et sa personnalité uniques.
|
||||
|
||||
**À utiliser quand :**
|
||||
**À utiliser quand :**
|
||||
|
||||
- Vous avez besoin de multiples perspectives d’experts sur une décision
|
||||
- Vous voulez que les agents remettent en question les hypothèses des autres
|
||||
- Vous explorez un sujet complexe qui couvre plusieurs domaines
|
||||
|
||||
**Fonctionnement :**
|
||||
**Fonctionnement :**
|
||||
|
||||
1. Charge le manifeste d’agents avec toutes les personnalités d’agents installées
|
||||
2. Analyse votre sujet pour sélectionner les 2–3 agents les plus pertinents
|
||||
@@ -94,233 +236,6 @@ La magie se produit dans les idées 50–100. Le workflow encourage la générat
|
||||
4. Alterne la participation des agents pour garantir des perspectives variées
|
||||
5. Quittez avec `goodbye`, `end party` ou `quit`
|
||||
|
||||
**Entrée :** Sujet de discussion ou question, ainsi que la spécification des personas que vous souhaitez faire participer (optionnel)
|
||||
**Entrée :** Sujet de discussion ou question, ainsi que la spécification des personas que vous souhaitez faire participer (optionnel)
|
||||
|
||||
**Sortie :** Conversation multi-agents en temps réel conservant la personnalité de chaque agent
|
||||
|
||||
## bmad-spec
|
||||
|
||||
**Distille toute formulation d’intention en un contrat SPEC canonique pour le travail en aval.** — Accepte un brief, un PRD, un GDD, un RFC, un brain dump, une transcription, un dossier UX ou une entrée multi-source mixte et produit un `SPEC.md` structuré autour d’un noyau de cinq champs (Pourquoi, Capacités, Contraintes, Non-objectifs, Signal de succès) ainsi que des fichiers compagnons pour le contenu essentiel qui ne trouve pas sa place dans le noyau.
|
||||
|
||||
**À utiliser quand :**
|
||||
|
||||
- Vous devez verrouiller le QUOI avant le COMMENT pour tout type de travail (logiciel, game design, recherche, éditorial, politique, entreprise)
|
||||
- Vous souhaitez un contrat succinct optimisé pour les LLM, sans fioritures, que les compétences en aval peuvent consommer sans relire chaque artefact en amont
|
||||
- Vous voulez valider ou mettre à jour une spécification existante
|
||||
|
||||
**Fonctionnement :**
|
||||
|
||||
1. Lit l’entrée et tout document annexe lié
|
||||
2. Distille en un noyau à cinq champs via un modèle configurable ; redirige l’excédent vers des fichiers compagnons correctement nommés
|
||||
3. Exécute une auto-validation en deux passes (règles de cohérence, puis préservation de chaque affirmation essentielle de la source)
|
||||
4. Écrit `SPEC.md`, les compagnons associés, et un `.memlog.md` sous `{output_folder}/specs/spec-{slug}/`
|
||||
|
||||
La loi Spec impose huit règles : les capacités expriment à la fois l’intention et le critère de succès ; les intentions décrivent le QUOI, pas le COMMENT ; les contraintes guident réellement les décisions ; les non-objectifs sont explicites ; les signaux de succès sont concrets ; les identifiants de capacité sont stables ; chaque affirmation essentielle de la source est préservée ; la rédaction est concise.
|
||||
|
||||
**Entrée :**
|
||||
|
||||
- `input` (requis) — Chemin ou texte fourni directement. Idée vague, brain dump, PRD, GDD, RFC, brief, transcription, dossier de maquettes, multi-source mixte
|
||||
- `slug` (optionnel) — Requis uniquement lorsque l’entrée est succincte et qu’aucun slug ne peut être dérivé du nom de fichier source
|
||||
- `target_spec_path` (optionnel) — Définir pour mettre à jour une spécification existante au lieu d’en créer une nouvelle
|
||||
|
||||
**Sortie :** Dossier de spécification contenant `SPEC.md`, les éventuels fichiers compagnons, et un `.memlog.md`. Les appelants en mode headless reçoivent une réponse JSON avec le statut du résultat et la liste des fichiers écrits ou modifiés.
|
||||
|
||||
:::note[Contrat de mutation]
|
||||
`bmad-spec` est le seul outil autorisé à écrire `SPEC.md` et les fichiers compagnons de la spécification. Les autres compétences produisent leurs propres artefacts natifs et invoquent `bmad-spec` en mode headless lorsqu’elles ont besoin d’exprimer une intention sous forme de contrat canonique ou de proposer des mises à jour.
|
||||
:::
|
||||
|
||||
|
||||
## bmad-advanced-elicitation
|
||||
|
||||
**Soumet la sortie du LLM à des méthodes de raffinement itératives.** — Sélectionne à partir d’une bibliothèque de techniques d’élicitation pour améliorer systématiquement le contenu en plusieurs passages.
|
||||
|
||||
**À utiliser quand :**
|
||||
|
||||
- La sortie du LLM semble superficielle ou générique
|
||||
- Vous voulez explorer un sujet sous plusieurs angles analytiques
|
||||
- Vous raffinez un document critique et souhaitez une réflexion plus approfondie
|
||||
|
||||
**Fonctionnement :**
|
||||
|
||||
1. Charge le registre de méthodes avec plus de 5 techniques d’élicitation
|
||||
2. Sélectionne les 5 méthodes les mieux adaptées selon le type de contenu et la complexité
|
||||
3. Présente un menu interactif — choisissez une méthode, remélangez, ou listez tout
|
||||
4. Applique la méthode sélectionnée pour améliorer le contenu
|
||||
5. Affiche à nouveau les options d’amélioration itérative jusqu’à ce que vous sélectionniez « Procéder »
|
||||
|
||||
**Entrée :** Section de contenu à améliorer
|
||||
|
||||
**Sortie :** Version améliorée du contenu avec les améliorations appliquées
|
||||
|
||||
## bmad-review-adversarial-general
|
||||
|
||||
**Revue contradictoire qui part du principe que des problèmes existent et les traque.** — Adopte un regard de réviseur sceptique et blasé, sans aucune tolérance pour le travail bâclé. Cherche ce qui manque, pas seulement ce qui ne va pas.
|
||||
|
||||
**À utiliser quand :**
|
||||
|
||||
- Vous avez besoin d’assurance qualité avant de finaliser un livrable
|
||||
- Vous voulez éprouver une spécification, une story ou un document
|
||||
- Vous voulez trouver des lacunes de couverture que les revues optimistes manquent
|
||||
|
||||
**Fonctionnement :**
|
||||
|
||||
1. Lit le contenu avec un regard contradictoire et critique
|
||||
2. Identifie les problèmes sur les plans de l’exhaustivité, de la justesse et de la qualité
|
||||
3. Recherche spécifiquement ce qui manque — pas seulement ce qui est présent et faux
|
||||
4. Doit trouver un minimum de 10 problèmes ou réanalyser plus en profondeur
|
||||
|
||||
**Entrée :**
|
||||
|
||||
- `content` (requis) — Diff, spécification, story, document ou tout artefact
|
||||
- `also_consider` (optionnel) — Domaines supplémentaires à garder à l’esprit
|
||||
|
||||
**Sortie :** Liste markdown de plus de 10 constatations avec descriptions
|
||||
|
||||
## bmad-review-edge-case-hunter
|
||||
|
||||
**Parcourt tous les chemins de branchement et les conditions limites, ne signale que les cas non gérés.** — Méthodologie pure de traçage de chemin[^1] qui dérive mécaniquement les classes de cas limites. Orthogonale à la revue contradictoire — centrée sur la méthode, pas sur l’attitude.
|
||||
|
||||
**À utiliser quand :**
|
||||
|
||||
- Vous souhaitez une couverture exhaustive des cas limites pour le code ou la logique
|
||||
- Vous avez besoin d’un complément à la revue contradictoire (méthodologie différente, résultats différents)
|
||||
- Vous révisez un diff ou une fonction pour des conditions limites
|
||||
|
||||
**Fonctionnement :**
|
||||
|
||||
1. Énumère tous les chemins de branchement dans le contenu
|
||||
2. Dérive mécaniquement les classes de cas limites : else/default manquants, entrées non protégées, erreurs off-by-one, dépassements arithmétiques, conversions de type implicites, conditions de concurrence, dépassements de délai
|
||||
3. Teste chaque chemin face aux protections existantes
|
||||
4. Ne signale que les chemins non gérés — ignore silencieusement les chemins gérés
|
||||
|
||||
**Entrée :**
|
||||
|
||||
- `content` (obligatoire) — Diff, fichier complet ou fonction
|
||||
- `also_consider` (facultatif) — Domaines supplémentaires à garder à l’esprit
|
||||
|
||||
**Sortie :** Tableau JSON des résultats, chacun avec `location`, `trigger_condition`, `guard_snippet` et `potential_consequence`
|
||||
|
||||
:::note[Revue Complémentaire]
|
||||
Exécutez à la fois `bmad-review-adversarial-general` et `bmad-review-edge-case-hunter` pour une couverture orthogonale. La revue contradictoire détecte les problèmes de qualité et de complétude ; le chasseur de cas limites détecte les chemins non gérés.
|
||||
:::
|
||||
|
||||
## bmad-editorial-review-prose
|
||||
|
||||
**Correction éditoriale clinique centrée sur la clarté de communication.** — Analyse le texte pour détecter les problèmes qui nuisent à la compréhension. Applique le Microsoft Writing Style Guide comme référence de base. Préserve la voix de l’auteur.
|
||||
|
||||
**À utiliser quand :**
|
||||
|
||||
- Vous avez rédigé un document et souhaitez en polir le style
|
||||
- Vous devez assurer la clarté pour un public spécifique
|
||||
- Vous voulez des corrections de communication sans modifier les choix stylistiques
|
||||
|
||||
**Fonctionnement :**
|
||||
|
||||
1. Lit le contenu en ignorant les blocs de code et le frontmatter
|
||||
2. Identifie les problèmes de communication (pas les préférences de style)
|
||||
3. Dédoublonne les occurrences d’un même problème à différents endroits
|
||||
4. Produit un tableau de corrections en trois colonnes
|
||||
|
||||
**Entrée :**
|
||||
|
||||
- `content` (obligatoire) — Markdown, texte brut ou XML
|
||||
- `style_guide` (facultatif) — Guide de style spécifique au projet
|
||||
- `reader_type` (facultatif) — `humans` (par défaut) pour clarté/fluide, ou `llm` pour précision/consistance
|
||||
|
||||
**Sortie :** Tableau Markdown en trois colonnes : Texte original | Texte révisé | Modifications
|
||||
|
||||
## bmad-editorial-review-structure
|
||||
|
||||
**Édition structurelle — propose des coupes, fusions, réorganisations et condensations.** — Révise l’organisation du document et propose des changements substantiels pour améliorer la clarté et le flux avant la correction éditoriale.
|
||||
|
||||
**À utiliser quand :**
|
||||
|
||||
- Un document a été produit par plusieurs sous-processus et nécessite une cohérence structurelle
|
||||
- Vous voulez réduire la longueur du document tout en préservant la compréhension
|
||||
- Vous devez identifier les violations de portée ou les informations critiques enfouies
|
||||
|
||||
**Fonctionnement :**
|
||||
|
||||
1. Analyse le document contre 5 modèles de structure (Tutoriel, Référence, Explication, Prompt, Stratégique)
|
||||
2. Identifie les redondances, violations de portée et informations enfouies
|
||||
3. Produit des recommandations priorisées : COUPER, FUSIONNER, DÉPLACER, CONDENSER, QUESTIONNER, PRÉSERVER
|
||||
4. Estime la réduction totale en mots et en pourcentage
|
||||
|
||||
**Entrée :**
|
||||
|
||||
- `content` (requis) — Document à réviser
|
||||
- `purpose` (optionnel) — Objectif prévu (par ex., « tutoriel de démarrage rapide »)
|
||||
- `target_audience` (optionnel) — Qui lit ceci
|
||||
- `reader_type` (optionnel) — `humans` ou `llm`
|
||||
- `length_target` (optionnel) — Réduction cible (par ex., « 30% plus court »)
|
||||
|
||||
**Sortie :** Résumé du document, liste de recommandations priorisées et réduction estimée
|
||||
|
||||
## bmad-shard-doc
|
||||
|
||||
**Fractionne les fichiers markdown volumineux en sections organisées.** — Utilise les en-têtes de niveau 2 comme points de découpe pour créer un dossier de fichiers de sections autonomes avec un index.
|
||||
|
||||
**À utiliser quand :**
|
||||
|
||||
- Un document markdown est devenu trop volumineux pour être géré efficacement (plus de 500 lignes)
|
||||
- Vous voulez découper un document monolithique en sections navigables
|
||||
- Vous avez besoin de fichiers séparés pour l’édition parallèle ou la gestion de contexte LLM
|
||||
|
||||
**Fonctionnement :**
|
||||
|
||||
1. Valide que le fichier source existe et est au format markdown
|
||||
2. Découpe sur les en-têtes de niveau 2 (`##`) en fichiers de sections numérotées
|
||||
3. Crée un `index.md` avec le manifeste de sections et les liens
|
||||
4. Vous invite à supprimer, archiver ou conserver l’original
|
||||
|
||||
**Entrée :** Chemin du fichier markdown source, dossier de destination optionnel
|
||||
|
||||
**Sortie :** Dossier avec `index.md` et `01-{section}.md`, `02-{section}.md`, etc.
|
||||
|
||||
## bmad-index-docs
|
||||
|
||||
**Génère ou met à jour un index de tous les documents dans un dossier.** — Analyse un répertoire, lit chaque fichier pour comprendre son objectif et produit un `index.md` organisé avec liens et descriptions.
|
||||
|
||||
**À utiliser quand :**
|
||||
|
||||
- Vous avez besoin d’un index léger pour un scan LLM rapide des documents disponibles
|
||||
- Un dossier de documentation a grandi et nécessite une table des matières organisée
|
||||
- Vous voulez un aperçu auto-généré qui reste à jour
|
||||
|
||||
**Fonctionnement :**
|
||||
|
||||
1. Analyse le répertoire cible pour tous les fichiers non cachés
|
||||
2. Lit chaque fichier pour comprendre son objectif réel
|
||||
3. Groupe les fichiers par type, objectif ou sous-répertoire
|
||||
4. Génère des descriptions concises (3–10 mots chacune)
|
||||
|
||||
**Entrée :** Chemin du dossier cible
|
||||
|
||||
**Sortie :** `index.md` avec listes de fichiers organisées, liens relatifs et brèves descriptions
|
||||
|
||||
## bmad-customize
|
||||
|
||||
**Créer et vérifier des personnalisations.** — Vous aide à modifier le comportement d’un agent ou d’un workflow BMad installé sans avoir à écrire de TOML manuellement.
|
||||
|
||||
**À utiliser quand :**
|
||||
|
||||
- Vous souhaitez modifier le comportement d’un agent ou d’un workflow
|
||||
- Vous devez ajouter des faits persistants, des hooks d’activation ou des éléments de menu personnalisés
|
||||
- Vous voulez que le bon périmètre de surcharge soit sélectionné et vérifié automatiquement
|
||||
|
||||
**Fonctionnement :**
|
||||
|
||||
1. Analyse les skills BMad installés pour identifier les surfaces personnalisables
|
||||
2. Sélectionne le bon périmètre pour le changement demandé
|
||||
3. Écrit les fichiers de surcharge sous `_bmad/custom/`
|
||||
4. Vérifie la configuration fusionnée
|
||||
|
||||
**Entrée :** Description en langage naturel de la personnalisation souhaitée
|
||||
|
||||
**Sortie :** Fichiers de surcharge TOML sous `_bmad/custom/`
|
||||
|
||||
Pour un guide détaillé sur la personnalisation de BMad, consultez [Comment personnaliser BMad](../how-to/customize-bmad.md).
|
||||
|
||||
## Glossaire
|
||||
|
||||
[^1]: Path-tracing : méthode d’analyse qui suit systématiquement tous les chemins d’exécution possibles dans un programme pour identifier les cas non gérés.
|
||||
**Sortie :** Conversation multi-agents en temps réel conservant la personnalité de chaque agent
|
||||
|
||||
@@ -68,7 +68,7 @@ Décidez comment le construire et décomposez le travail en stories.
|
||||
|
||||
| Workflow | Objectif | Livrable |
|
||||
|---------------------------------------|---------------------------------------------------|---------------------------------|
|
||||
| `bmad-create-architecture` | Rendez explicites les décisions techniques | `architecture.md` avec ADRs[^2] |
|
||||
| `bmad-architecture` | Rendez explicites les décisions techniques | `architecture.md` avec ADRs[^2] |
|
||||
| `bmad-create-epics-and-stories` | Décomposez les exigences en tâches implémentables | Fichiers d’epic avec stories |
|
||||
| `bmad-check-implementation-readiness` | Jalon de validation avant implémentation | Décision OK / RÉSERVES / ÉCHEC |
|
||||
|
||||
|
||||
@@ -170,7 +170,7 @@ Si votre projet comporte une interface utilisateur, invoquez l'**agent UX Design
|
||||
**Créer l’architecture**
|
||||
|
||||
1. Invoquez l'**agent Architecte** (`bmad-agent-architect`) dans un nouveau chat
|
||||
2. Exécutez `bmad-create-architecture` (`bmad-create-architecture`)
|
||||
2. Exécutez `bmad-architecture` (`bmad-architecture`)
|
||||
3. Résultat : document d’architecture avec les décisions techniques
|
||||
|
||||
**Créer les epics et les stories**
|
||||
@@ -240,7 +240,7 @@ your-project/
|
||||
|---------------------------------------|---------------------------------------|-----------|-----------------------------------------------------------------|
|
||||
| **`bmad-help`** ⭐ | `bmad-help` | Tous | **Votre guide intelligent — posez n’importe quelle question !** |
|
||||
| `bmad-prd` | `bmad-prd` | Tous | Créer, mettre à jour ou valider un PRD |
|
||||
| `bmad-create-architecture` | `bmad-create-architecture` | Architect | Créer le document d’architecture |
|
||||
| `bmad-architecture` | `bmad-architecture` | Architect | Créer le document d’architecture |
|
||||
| `bmad-generate-project-context` | `bmad-generate-project-context` | Analyst | Créer le fichier de contexte projet |
|
||||
| `bmad-create-epics-and-stories` | `bmad-create-epics-and-stories` | PM | Décomposer le PRD en epics |
|
||||
| `bmad-check-implementation-readiness` | `bmad-check-implementation-readiness` | Architect | Valider la cohérence de la planification |
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: 'How to Expand BMad for Your Organization'
|
||||
description: Six customization patterns that reshape BMad without forking — agent-wide rules, workflow conventions, external publishing, template swaps, agent roster changes, and advanced integration patterns
|
||||
sidebar:
|
||||
order: 11
|
||||
order: 10
|
||||
---
|
||||
|
||||
BMad's customization surface lets an organization reshape behavior without editing installed files or forking skills. This guide walks through six recipes that cover most enterprise needs.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: "Pressure-Test an Idea"
|
||||
description: Use the bmad-forge-idea skill to harden, prove, or kill an idea before you invest in it
|
||||
sidebar:
|
||||
order: 12
|
||||
order: 11
|
||||
---
|
||||
|
||||
Use the `bmad-forge-idea` skill to put a half-formed idea under adversarial questioning. It either survives with earned conviction or dies cheaply.
|
||||
@@ -28,7 +28,7 @@ None. The forge runs in plain conversation. Installed agents and a configured pe
|
||||
|
||||
### 1. Invoke the skill
|
||||
|
||||
Type `bmad-forge-idea` in your IDE, or say "forge an idea" or "pressure-test this." Name the idea in the same message or wait for the first question.
|
||||
Type `bmad-forge-idea` in your IDE, or say "forge an idea" or "pressure-test this." Name the idea in the same message or wait for the first question. If the skill isn't installed, select the **BMad Analysis** module in the installer — it brings in `bmad-forge-idea` along with `bmad-brainstorming` and `bmad-party-mode`.
|
||||
|
||||
### 2. State your goal
|
||||
|
||||
|
||||
@@ -1,78 +0,0 @@
|
||||
---
|
||||
title: 'Document Sharding Guide'
|
||||
description: Split large markdown files into smaller organized files for better context management
|
||||
sidebar:
|
||||
order: 10
|
||||
---
|
||||
|
||||
Use the `bmad-shard-doc` tool if you need to split large markdown files into smaller, organized files for better context management.
|
||||
|
||||
:::caution[Deprecated]
|
||||
This is no longer recommended, and soon with updated workflows and most major LLMs and tools supporting subprocesses this will be unnecessary.
|
||||
:::
|
||||
|
||||
## When to Use This
|
||||
|
||||
Only use this if you notice your chosen tool / model combination is failing to load and read all the documents as input when needed.
|
||||
|
||||
## What is Document Sharding?
|
||||
|
||||
Document sharding splits large markdown files into smaller, organized files based on level 2 headings (`## Heading`).
|
||||
|
||||
### Architecture
|
||||
|
||||
```text
|
||||
Before Sharding:
|
||||
_bmad-output/planning-artifacts/
|
||||
└── PRD.md (large 50k token file)
|
||||
|
||||
After Sharding:
|
||||
_bmad-output/planning-artifacts/
|
||||
└── prd/
|
||||
├── index.md # Table of contents with descriptions
|
||||
├── overview.md # Section 1
|
||||
├── user-requirements.md # Section 2
|
||||
├── technical-requirements.md # Section 3
|
||||
└── ... # Additional sections
|
||||
```
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Run the Shard-Doc Tool
|
||||
|
||||
```bash
|
||||
/bmad-shard-doc
|
||||
```
|
||||
|
||||
### 2. Follow the Interactive Process
|
||||
|
||||
```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!
|
||||
```
|
||||
|
||||
## How Workflow Discovery Works
|
||||
|
||||
BMad workflows use a **dual discovery system**:
|
||||
|
||||
1. **Try whole document first** - Look for `document-name.md`
|
||||
2. **Check for sharded version** - Look for `document-name/index.md`
|
||||
3. **Priority rule** - Whole document takes precedence if both exist - remove the whole document if you want the sharded to be used instead
|
||||
|
||||
## Workflow Support
|
||||
|
||||
All BMM workflows support both formats:
|
||||
|
||||
- Whole documents
|
||||
- Sharded documents
|
||||
- Automatic detection
|
||||
- Transparent to user
|
||||
@@ -95,7 +95,7 @@ Workflow skills run a structured, multi-step process without loading an agent pe
|
||||
| `bmad-prfaq` | [Working Backwards PRFAQ](../explanation/analysis-phase.md#prfaq-working-backwards) challenge to stress-test your product concept |
|
||||
| `bmad-prd` | Create, update, or validate a Product Requirements Document |
|
||||
| `bmad-ux` | Design user experience |
|
||||
| `bmad-create-architecture` | Design system architecture |
|
||||
| `bmad-architecture` | Design system architecture |
|
||||
| `bmad-create-epics-and-stories` | Create epics and stories |
|
||||
| `bmad-dev-story` | Implement a story |
|
||||
| `bmad-code-review` | Run a code review |
|
||||
@@ -122,7 +122,7 @@ bmad-help What are my options for UX design?
|
||||
|
||||
**Other Core Tasks and Tools**
|
||||
|
||||
The core module includes 12 built-in tools — specs, reviews, brainstorming, customization, document management, and more. See [Core Tools](./core-tools.md) for the complete reference.
|
||||
The core module includes 5 built-in tools — help, reviews, refinement, and customization — and the optional BMad Analysis pack adds the standalone thinking skills (brainstorming, forge idea, party mode). See [Core Tools](./core-tools.md) for the complete reference.
|
||||
|
||||
## Naming Convention
|
||||
|
||||
|
||||
+152
-262
@@ -1,33 +1,39 @@
|
||||
---
|
||||
title: Core Tools
|
||||
description: Reference for all built-in tasks and workflows available in every BMad installation without additional modules.
|
||||
description: Reference for the core module's built-in skills, plus the standalone thinking skills and the BMad Analysis pack.
|
||||
sidebar:
|
||||
order: 3
|
||||
---
|
||||
|
||||
Every BMad installation includes a set of core skills that can be used in conjunction with any anything you are doing — standalone tasks and workflows that work across all projects, all modules, and all phases. These are always available regardless of which optional modules you install.
|
||||
Every BMad installation includes the **core module** — a small set of skills that work across all projects, all modules, and all phases. This page covers those five core skills, plus the **standalone thinking skills** (brainstorming, forge idea, party mode) that install separately as their own modules — most easily via the **BMad Analysis** pack.
|
||||
|
||||
:::tip[Quick Path]
|
||||
Run any core tool by typing its skill name (e.g., `bmad-help`) in your IDE. No agent session required.
|
||||
Run any tool by typing its skill name (e.g., `bmad-help`) in your IDE. No agent session required.
|
||||
:::
|
||||
|
||||
## Overview
|
||||
|
||||
| Tool | Type | Purpose |
|
||||
| --- | --- | --- |
|
||||
| [`bmad-help`](#bmad-help) | Task | Get context-aware guidance on what to do next |
|
||||
| [`bmad-brainstorming`](#bmad-brainstorming) | Workflow | Facilitate interactive brainstorming sessions |
|
||||
| [`bmad-party-mode`](#bmad-party-mode) | Workflow | Orchestrate multi-agent group discussions |
|
||||
| [`bmad-forge-idea`](#bmad-forge-idea) | Workflow | Pressure-test an idea until it hardens, proves out, or dies cheaply |
|
||||
| [`bmad-spec`](#bmad-spec) | Workflow | Distill any intent input into a SPEC kernel and companions, the canonical contract for downstream work |
|
||||
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | Task | Push LLM output through iterative refinement methods |
|
||||
| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | Task | Cynical review that finds what's missing and what's wrong |
|
||||
| [`bmad-review-edge-case-hunter`](#bmad-review-edge-case-hunter) | Task | Exhaustive branching-path analysis for unhandled edge cases |
|
||||
| [`bmad-editorial-review-prose`](#bmad-editorial-review-prose) | Task | Clinical copy-editing for communication clarity |
|
||||
| [`bmad-editorial-review-structure`](#bmad-editorial-review-structure) | Task | Structural editing — cuts, merges, and reorganization |
|
||||
| [`bmad-shard-doc`](#bmad-shard-doc) | Task | Split large markdown files into organized sections |
|
||||
| [`bmad-index-docs`](#bmad-index-docs) | Task | Generate or update an index of all docs in a folder |
|
||||
| [`bmad-customize`](#bmad-customize) | Task | Create and verify BMad customization overrides |
|
||||
**Core module (always installed):**
|
||||
|
||||
| Tool | Purpose |
|
||||
| --- | --- |
|
||||
| [`bmad-help`](#bmad-help) | Get context-aware guidance on what to do next |
|
||||
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | Push LLM output through iterative refinement methods |
|
||||
| [`bmad-editorial-review`](#bmad-editorial-review) | Two-pass editorial review — structure, then prose |
|
||||
| [`bmad-review`](#bmad-review) | Multi-lens critical review — adversarial, edge-case, and verification-gap |
|
||||
| [`bmad-customize`](#bmad-customize) | Create and verify BMad customization overrides |
|
||||
|
||||
**Standalone thinking skills (installed via the [BMad Analysis pack](./standalone-skills.md) or individually):**
|
||||
|
||||
| Tool | Purpose |
|
||||
| --- | --- |
|
||||
| [`bmad-brainstorming`](#bmad-brainstorming) | Facilitate interactive brainstorming sessions |
|
||||
| [`bmad-forge-idea`](#bmad-forge-idea) | Pressure-test an idea until it hardens, proves out, or dies cheaply |
|
||||
| [`bmad-party-mode`](#bmad-party-mode) | Orchestrate multi-agent group discussions |
|
||||
|
||||
:::note[Moved and removed]
|
||||
`bmad-spec` now ships with the BMM module as a Phase 2 planning workflow — see the [Workflow Map](./workflow-map.md#phase-2-planning). The `bmad-shard-doc` and `bmad-index-docs` utilities have been removed. The former `bmad-editorial-review-prose`, `bmad-editorial-review-structure`, `bmad-review-adversarial-general`, `bmad-review-edge-case-hunter`, and `bmad-review-verification-gap` skills are merged into `bmad-editorial-review` and `bmad-review`; the old IDs still resolve via hidden forwarders for compatibility.
|
||||
:::
|
||||
|
||||
## bmad-help
|
||||
|
||||
@@ -51,7 +57,121 @@ Run any core tool by typing its skill name (e.g., `bmad-help`) in your IDE. No a
|
||||
|
||||
**Output:** Prioritized list of recommended next steps with skill commands
|
||||
|
||||
## bmad-brainstorming
|
||||
## bmad-advanced-elicitation
|
||||
|
||||
**Push the LLM to reconsider, refine, and improve its recent output.** — BMad's shared refinement checkpoint: other skills invoke it at natural pauses, and you can call it directly on anything recent in the conversation.
|
||||
|
||||
**Use it when:**
|
||||
|
||||
- LLM output feels shallow or generic
|
||||
- You want to explore a topic from multiple analytical angles
|
||||
- You're refining a critical document and want deeper thinking
|
||||
- You want a known method by name — Socratic, first principles, pre-mortem, red team
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. Targets the most recent output in the conversation unless you point it at something else
|
||||
2. Offers a short menu of best-fit elicitation methods for the content
|
||||
3. Applies the chosen methods against the target
|
||||
4. Hands back the improved version so the invoking flow resumes where it paused
|
||||
|
||||
**Input:** The recent output to refine (default), or any content you point it at; optionally a named method
|
||||
|
||||
**Output:** Enhanced version of the content with improvements applied
|
||||
|
||||
## bmad-editorial-review
|
||||
|
||||
**Two-pass editorial review — structure, then prose.** — A clinical editor that reviews a document's shape and its sentences, returning suggested fixes you accept or reject row by row. Content is sacrosanct: it never challenges your ideas, only how they're organized and expressed.
|
||||
|
||||
**Use it when:**
|
||||
|
||||
- You've drafted a document and want it tightened and polished
|
||||
- A document was produced from multiple subprocesses and needs structural coherence
|
||||
- You want to reduce length while preserving comprehension
|
||||
- You need clarity fixes without style-opinion changes
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. **Structure pass** — proposes cuts, merges, moves, and condensing; asks whether the document's shape serves its purpose
|
||||
2. **Prose pass** — copy-edits for communication issues that impede comprehension, using the Microsoft Writing Style Guide as the baseline (a provided style guide overrides it)
|
||||
3. Runs both passes, structure first, by default; ask for a structure-only or prose-only review to run one
|
||||
4. Proposes, never executes — the author decides what to accept
|
||||
|
||||
**Input:**
|
||||
|
||||
- `content` (required) — Document to review
|
||||
- `style_guide` (optional) — Project-specific style guide
|
||||
- `reader_type` (optional) — `humans` (default) for clarity/flow, or `llm` for precision/consistency
|
||||
- `purpose` / `target_audience` / `length_target` (optional) — calibrate the structure pass
|
||||
|
||||
**Output:** Findings table with suggested fixes, plus estimated reduction when structural changes are proposed
|
||||
|
||||
## bmad-review
|
||||
|
||||
**Multi-lens critical review over any diff, doc, or artifact.** — Runs independent review lenses — each a distinct method and stance — and reports every finding in one canonical shape. Zero findings is a valid outcome; it never pads to look thorough.
|
||||
|
||||
**The shipped lenses:**
|
||||
|
||||
| Lens | Method |
|
||||
| --- | --- |
|
||||
| **Adversarial** | Skeptical review that assumes problems exist — hunts what's missing, not just what's wrong |
|
||||
| **Edge case** | Walks every branching path and boundary condition, reports only unhandled paths |
|
||||
| **Verification gap** | Finds changed behavior that could regress without reliable verification catching it |
|
||||
|
||||
**Use it when:**
|
||||
|
||||
- You need quality assurance before finalizing a deliverable
|
||||
- You want exhaustive edge-case coverage of code or logic
|
||||
- You want to know whether a change is adequately verified
|
||||
- You want all three perspectives at once (the default)
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. Loads the content and identifies its type — diff, file, function, or document
|
||||
2. Selects lenses: the ones you name, or every enabled lens that fits the content
|
||||
3. Runs each lens independently — in parallel via subagents when the platform supports it
|
||||
4. Assembles one findings array; overlap between lenses is signal, not duplication
|
||||
|
||||
**Input:**
|
||||
|
||||
- `content` (required) — Diff, branch, uncommitted changes, file, spec, story, or any document
|
||||
- `lenses` (optional) — one or more lens codes or names; default is a full review
|
||||
- `also_consider` (optional) — Additional areas to keep in mind
|
||||
|
||||
**Output:** JSON findings array (each finding carries `lens`, `location`, `trigger_condition`, `guard_snippet`, `potential_consequence`) and/or a markdown report grouped by lens
|
||||
|
||||
:::note[Used by other workflows]
|
||||
Code Review workflows in other modules run these lenses automatically. Custom lenses can be added — and shipped ones tuned or disabled — through the skill's `customize.toml`.
|
||||
:::
|
||||
|
||||
## bmad-customize
|
||||
|
||||
**Create and verify customization overrides.** — Helps you change how an installed BMad agent or workflow behaves without hand-authoring TOML.
|
||||
|
||||
**Use it when:**
|
||||
|
||||
- You want to change an agent or workflow behavior
|
||||
- You need to add persistent facts, activation hooks, or custom menu items
|
||||
- You want the right override scope selected and verified automatically
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. Scans installed BMad skills for customizable surfaces
|
||||
2. Selects the right scope for your requested change
|
||||
3. Writes override files under `_bmad/custom/`
|
||||
4. Verifies the merged configuration
|
||||
|
||||
**Input:** Natural language description of the customization you want
|
||||
|
||||
**Output:** TOML override files under `_bmad/custom/`
|
||||
|
||||
For a detailed guide on customizing BMad, see [How to Customize BMad](../how-to/customize-bmad.md).
|
||||
|
||||
## Standalone Thinking Skills
|
||||
|
||||
The three skills below are not part of the core module. Each is its own single-skill module, hidden from the installer picker, and arrives either through the visible **BMad Analysis** pack or when another module declares it as a dependency. See [Standalone Skills & Module Dependencies](./standalone-skills.md) for how that works.
|
||||
|
||||
### bmad-brainstorming
|
||||
|
||||
**Generate diverse ideas through interactive creative techniques.** — A facilitated brainstorming session that loads proven ideation methods from a technique library and guides you toward 100+ ideas before organizing.
|
||||
|
||||
@@ -77,29 +197,7 @@ Run any core tool by typing its skill name (e.g., `bmad-help`) in your IDE. No a
|
||||
The magic happens in ideas 50–100. The workflow encourages generating 100+ ideas before organization.
|
||||
:::
|
||||
|
||||
## bmad-party-mode
|
||||
|
||||
**Orchestrate multi-agent group discussions.** — Loads all installed BMad agents and facilitates a natural conversation where each agent contributes from their unique expertise and personality.
|
||||
|
||||
**Use it when:**
|
||||
|
||||
- You need multiple expert perspectives on a decision
|
||||
- You want agents to challenge each other's assumptions
|
||||
- You're exploring a complex topic that spans multiple domains
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. Loads the agent manifest with all installed agent personalities
|
||||
2. Analyzes your topic to select 2–3 most relevant agents
|
||||
3. Agents take turns contributing, with natural cross-talk and disagreements
|
||||
4. Rotates agent participation to ensure diverse perspectives over time
|
||||
5. Exit with `goodbye`, `end party`, or `quit`
|
||||
|
||||
**Input:** Discussion topic or question, along with specification of personas you would like to participate (optional)
|
||||
|
||||
**Output:** Real-time multi-agent conversation with maintained agent personalities
|
||||
|
||||
## bmad-forge-idea
|
||||
### bmad-forge-idea
|
||||
|
||||
**Pressure-test an idea until it hardens, proves out, or dies cheaply.** — An adversarial interrogator drives a half-formed idea one question at a time, bringing two characters to every branch, until what survives is something you can act on with conviction.
|
||||
|
||||
@@ -121,232 +219,24 @@ The magic happens in ideas 50–100. The workflow encourages generating 100+ ide
|
||||
|
||||
**Output:** A `forged-idea.md` distillate when an idea hardens (optional), plus a `forge-report.html` keepsake every run
|
||||
|
||||
## bmad-spec
|
||||
### bmad-party-mode
|
||||
|
||||
**Distill any intent input into the canonical SPEC contract for downstream work.** Takes a brief, PRD, GDD, RFC, brain dump, transcript, UX folder, or mixed multi-source input and produces a `SPEC.md` carrying the five-field kernel (Why, Capabilities, Constraints, Non-goals, Success signal) plus companion files for load-bearing content that does not fit the kernel.
|
||||
**Orchestrate multi-agent group discussions.** — Loads all installed BMad agents and facilitates a natural conversation where each agent contributes from their unique expertise and personality.
|
||||
|
||||
**Use it when:**
|
||||
|
||||
- You need to lock the WHAT before the HOW for any kind of work (software, game design, research, editorial, policy, business).
|
||||
- You want a LLM Optimized succinct, no-fluff contract that downstream skills can consume without re-reading every upstream artifact.
|
||||
- You want to validate or update an existing spec.
|
||||
- You want to break a spec into an ordered list of stories for autonomous dispatch.
|
||||
- You need multiple expert perspectives on a decision
|
||||
- You want agents to challenge each other's assumptions
|
||||
- You're exploring a complex topic that spans multiple domains
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. Reads the input and any ancillary linked materials.
|
||||
2. Distills into the five-field kernel using a configurable template; routes overflow into appropriately-named companions.
|
||||
3. Runs a two-pass self-validate (coherence rules, then preservation of every load-bearing source claim).
|
||||
4. Writes `SPEC.md`, sibling companions, and a `.memlog.md` under `{output_folder}/specs/spec-{slug}/`.
|
||||
5. **Story Breakdown** (optional, interactive-only): on direct request, or as a once-per-run offer when the input reads as multiple independently shippable slices, walks the capabilities and constraints with you and writes `stories.yaml`.
|
||||
1. Loads the agent manifest with all installed agent personalities
|
||||
2. Analyzes your topic to select 2–3 most relevant agents
|
||||
3. Agents take turns contributing, with natural cross-talk and disagreements
|
||||
4. Rotates agent participation to ensure diverse perspectives over time
|
||||
5. Exit with `goodbye`, `end party`, or `quit`
|
||||
|
||||
Spec Law enforces eight rules: capabilities carry both intent and success; intents are WHAT not HOW; constraints actually bend decisions; non-goals are explicit; success signals are concrete; capability IDs are stable; every load-bearing source claim is preserved; prose is lean.
|
||||
**Input:** Discussion topic or question, along with specification of personas you would like to participate (optional)
|
||||
|
||||
**Input:**
|
||||
|
||||
- `input` (required) — path or inline text. Vague idea, brain dump, PRD, GDD, RFC, brief, transcript, mockup folder, mixed multi-source.
|
||||
- `slug` (optional) — required only when input is sparse and no slug is derivable from a source filename.
|
||||
- `target_spec_path` (optional) — set to update an existing spec instead of creating a new one.
|
||||
|
||||
**Output:** Spec folder containing `SPEC.md`, any companion files, a `.memlog.md`, and — if Story Breakdown ran — `stories.yaml`. Headless callers receive a JSON response with the result status and the list of files written or modified.
|
||||
|
||||
:::note[Mutation contract]
|
||||
`bmad-spec` is the only writer of `SPEC.md` and of spec-authored companions. Other skills produce their own native artifacts and invoke `bmad-spec` headless when they need to express intent as the canonical contract or propose updates.
|
||||
:::
|
||||
|
||||
:::note[stories.yaml]
|
||||
Optional, interactive-only output of Story Breakdown — never produced in headless mode, and skipped in interactive mode too unless requested or offered. A sibling of `SPEC.md`, not a companion: a flat list, one entry per story, in strict execution order (list order — there is no `depends_on` field). Each entry has `id`, `title`, `description`, and two independent, caller-only booleans set by the human at breakdown time — `spec_checkpoint` (pause for human review between planning and implementation) and `done_checkpoint` (pause after the story completes) — plus a free-text `invoke_dev_with` dispatch note. An `id` is pinned once that story's spec file exists; unstarted stories may still be renumbered or reordered. `bmad-dev-auto` reads a story's `title`/`description` via folder+id dispatch — see [Autonomous Development Loops](./dev-auto.md).
|
||||
:::
|
||||
|
||||
## bmad-advanced-elicitation
|
||||
|
||||
**Push LLM output through iterative refinement methods.** — Selects from a library of elicitation techniques to systematically improve content through multiple passes.
|
||||
|
||||
**Use it when:**
|
||||
|
||||
- LLM output feels shallow or generic
|
||||
- You want to explore a topic from multiple analytical angles
|
||||
- You're refining a critical document and want deeper thinking
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. Loads method registry with 5+ elicitation techniques
|
||||
2. Selects 5 best-fit methods based on content type and complexity
|
||||
3. Presents an interactive menu — pick a method, reshuffle, or list all
|
||||
4. Applies the selected method to enhance the content
|
||||
5. Re-presents options for iterative improvement until you select "Proceed"
|
||||
|
||||
**Input:** Content section to enhance
|
||||
|
||||
**Output:** Enhanced version of the content with improvements applied
|
||||
|
||||
## bmad-review-adversarial-general
|
||||
|
||||
**Cynical review that assumes problems exist and searches for them.** — Takes a skeptical, jaded reviewer perspective with zero patience for sloppy work. Looks for what's missing, not just what's wrong.
|
||||
|
||||
**Use it when:**
|
||||
|
||||
- You need quality assurance before finalizing a deliverable
|
||||
- You want to stress-test a spec, story, or document
|
||||
- You want to find gaps in coverage that optimistic reviews miss
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. Reads the content with a cynical, critical perspective
|
||||
2. Identifies issues across completeness, correctness, and quality
|
||||
3. Searches specifically for what's missing — not just what's present and wrong
|
||||
4. Must find a minimum of 10 issues or re-analyzes deeper
|
||||
|
||||
**Input:**
|
||||
|
||||
- `content` (required) — Diff, spec, story, doc, or any artifact
|
||||
- `also_consider` (optional) — Additional areas to keep in mind
|
||||
|
||||
**Output:** Markdown list of 10+ findings with descriptions
|
||||
|
||||
## bmad-review-edge-case-hunter
|
||||
|
||||
**Walk every branching path and boundary condition, report only unhandled cases.** — Pure path-tracing methodology that mechanically derives edge classes. Orthogonal to adversarial review — method-driven, not attitude-driven.
|
||||
|
||||
**Use it when:**
|
||||
|
||||
- You want exhaustive edge case coverage for code or logic
|
||||
- You need a complement to adversarial review (different methodology, different findings)
|
||||
- You're reviewing a diff or function for boundary conditions
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. Enumerates all branching paths in the content
|
||||
2. Derives edge classes mechanically: missing else/default, unguarded inputs, off-by-one, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
|
||||
3. Tests each path against existing guards
|
||||
4. Reports only unhandled paths — silently discards handled ones
|
||||
|
||||
**Input:**
|
||||
|
||||
- `content` (required) — Diff, full file, or function
|
||||
- `also_consider` (optional) — Additional areas to keep in mind
|
||||
|
||||
**Output:** JSON array of findings, each with `location`, `trigger_condition`, `guard_snippet`, and `potential_consequence`
|
||||
|
||||
**Deletion check (secondary):** When the diff removes meaningful code, the hunter also flags deletions that drop behavior or contracts without replacement, tagged `kind: deletion` in the same array.
|
||||
|
||||
:::note[Complementary Reviews]
|
||||
Run both `bmad-review-adversarial-general` and `bmad-review-edge-case-hunter` together for orthogonal coverage. The adversarial review catches quality and completeness issues; the edge case hunter catches unhandled paths.
|
||||
:::
|
||||
|
||||
## bmad-editorial-review-prose
|
||||
|
||||
**Clinical copy-editing focused on communication clarity.** — Reviews text for issues that impede comprehension. Applies Microsoft Writing Style Guide baseline. Preserves author voice.
|
||||
|
||||
**Use it when:**
|
||||
|
||||
- You've drafted a document and want to polish the writing
|
||||
- You need to ensure clarity for a specific audience
|
||||
- You want communication fixes without style opinion changes
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. Reads the content, skipping code blocks and frontmatter
|
||||
2. Identifies communication issues (not style preferences)
|
||||
3. Deduplicates same issues across multiple locations
|
||||
4. Produces a three-column fix table
|
||||
|
||||
**Input:**
|
||||
|
||||
- `content` (required) — Markdown, plain text, or XML
|
||||
- `style_guide` (optional) — Project-specific style guide
|
||||
- `reader_type` (optional) — `humans` (default) for clarity/flow, or `llm` for precision/consistency
|
||||
|
||||
**Output:** Three-column markdown table: Original Text | Revised Text | Changes
|
||||
|
||||
## bmad-editorial-review-structure
|
||||
|
||||
**Structural editing — proposes cuts, merges, moves, and condensing.** — Reviews document organization and proposes substantive changes to improve clarity and flow before copy editing.
|
||||
|
||||
**Use it when:**
|
||||
|
||||
- A document was produced from multiple subprocesses and needs structural coherence
|
||||
- You want to reduce document length while preserving comprehension
|
||||
- You need to identify scope violations or buried critical information
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. Analyzes document against 5 structure models (Tutorial, Reference, Explanation, Prompt, Strategic)
|
||||
2. Identifies redundancies, scope violations, and buried information
|
||||
3. Produces prioritized recommendations: CUT, MERGE, MOVE, CONDENSE, QUESTION, PRESERVE
|
||||
4. Estimates total reduction in words and percentage
|
||||
|
||||
**Input:**
|
||||
|
||||
- `content` (required) — Document to review
|
||||
- `purpose` (optional) — Intended purpose (e.g., "quickstart tutorial")
|
||||
- `target_audience` (optional) — Who reads this
|
||||
- `reader_type` (optional) — `humans` or `llm`
|
||||
- `length_target` (optional) — Target reduction (e.g., "30% shorter")
|
||||
|
||||
**Output:** Document summary, prioritized recommendation list, and estimated reduction
|
||||
|
||||
## bmad-shard-doc
|
||||
|
||||
**Split large markdown files into organized section files.** — Uses level-2 headers as split points to create a folder of self-contained section files with an index.
|
||||
|
||||
**Use it when:**
|
||||
|
||||
- A markdown document has grown too large to manage effectively (500+ lines)
|
||||
- You want to break a monolithic doc into navigable sections
|
||||
- You need separate files for parallel editing or LLM context management
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. Validates the source file exists and is markdown
|
||||
2. Splits on level-2 (`##`) headers into numbered section files
|
||||
3. Creates an `index.md` with section manifest and links
|
||||
4. Prompts you to delete, archive, or keep the original
|
||||
|
||||
**Input:** Source markdown file path, optional destination folder
|
||||
|
||||
**Output:** Folder with `index.md` and `01-{section}.md`, `02-{section}.md`, etc.
|
||||
|
||||
## bmad-index-docs
|
||||
|
||||
**Generate or update an index of all documents in a folder.** — Scans a directory, reads each file to understand its purpose, and produces an organized `index.md` with links and descriptions.
|
||||
|
||||
**Use it when:**
|
||||
|
||||
- You need a lightweight index for quick LLM scanning of available docs
|
||||
- A documentation folder has grown and needs an organized table of contents
|
||||
- You want an auto-generated overview that stays current
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. Scans the target directory for all non-hidden files
|
||||
2. Reads each file to understand its actual purpose
|
||||
3. Groups files by type, purpose, or subdirectory
|
||||
4. Generates concise descriptions (3–10 words each)
|
||||
|
||||
**Input:** Target folder path
|
||||
|
||||
**Output:** `index.md` with organized file listings, relative links, and brief descriptions
|
||||
|
||||
## bmad-customize
|
||||
|
||||
**Create and verify customization overrides.** — Helps you change how an installed BMad agent or workflow behaves without hand-authoring TOML.
|
||||
|
||||
**Use it when:**
|
||||
|
||||
- You want to change an agent or workflow behavior
|
||||
- You need to add persistent facts, activation hooks, or custom menu items
|
||||
- You want the right override scope selected and verified automatically
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. Scans installed BMad skills for customizable surfaces
|
||||
2. Selects the right scope for your requested change
|
||||
3. Writes override files under `_bmad/custom/`
|
||||
4. Verifies the merged configuration
|
||||
|
||||
**Input:** Natural language description of the customization you want
|
||||
|
||||
**Output:** TOML override files under `_bmad/custom/`
|
||||
|
||||
For a detailed guide on customizing BMad, see [How to Customize BMad](../how-to/customize-bmad.md).
|
||||
**Output:** Real-time multi-agent conversation with maintained agent personalities
|
||||
|
||||
@@ -11,6 +11,20 @@ BMad extends through official modules that you select during installation. These
|
||||
Run `npx bmad-method install` and select the modules you want. The installer handles downloading, configuration, and IDE integration automatically.
|
||||
:::
|
||||
|
||||
## BMad Analysis
|
||||
|
||||
The BMad thinking pack, built into the main `bmad-method` installer. A bundle module that ships no skills of its own — selecting it installs three standalone thinking skills via [module dependencies](./standalone-skills.md).
|
||||
|
||||
- **Code:** `bmad-analysis`
|
||||
|
||||
**Provides:**
|
||||
|
||||
- `bmad-brainstorming` -- facilitated ideation with a curated technique library
|
||||
- `bmad-forge-idea` -- pressure-test an idea until it hardens, proves out, or dies cheaply
|
||||
- `bmad-party-mode` -- round-table discussions between installed agents or custom personas
|
||||
|
||||
See [Core Tools](./core-tools.md#standalone-thinking-skills) for what each skill does.
|
||||
|
||||
## BMad Builder
|
||||
|
||||
Create custom agents, workflows, and domain-specific modules with guided assistance. BMad Builder is the meta-module for extending the framework itself.
|
||||
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: Standalone Skills & Module Dependencies
|
||||
description: How single-skill modules, hidden modules, and the module dependencies mechanism work — including the BMad Analysis pack.
|
||||
sidebar:
|
||||
order: 8
|
||||
---
|
||||
|
||||
Some BMad skills are not tied to the core module or to a domain suite like BMM. They ship as **standalone single-skill modules** — each with its own `module.yaml` and `module-help.csv` — and install on their own, either directly or because another module depends on them.
|
||||
|
||||
## Module dependencies
|
||||
|
||||
A module's `module.yaml` can declare a `dependencies` list of module codes:
|
||||
|
||||
```yaml
|
||||
code: bmad-analysis
|
||||
name: 'BMad Analysis'
|
||||
description: 'The BMad thinking pack ...'
|
||||
|
||||
dependencies:
|
||||
- bmad-brainstorming
|
||||
- bmad-party-mode
|
||||
- bmad-forge-idea
|
||||
```
|
||||
|
||||
When you select a module in the installer, the installer resolves the recursive union of its dependencies and installs those modules too. A dependency code the installer doesn't recognize produces a warning and is skipped — it never blocks the install.
|
||||
|
||||
## Hidden modules
|
||||
|
||||
A module can set `hidden: true` in its `module.yaml`. Hidden modules do not appear in the installer's module picker; they install only when another module declares them as a dependency, or when selected explicitly (for example, in a non-interactive install manifest).
|
||||
|
||||
This is how single-skill modules stay out of the picker without becoming unreachable: the picker stays short, and bundles or domain modules pull in exactly the atoms they need.
|
||||
|
||||
## The BMad Analysis pack
|
||||
|
||||
**BMad Analysis** (`bmad-analysis`) is a bundle module: it ships no skills of its own, only a `dependencies` list. Selecting it in the installer installs the three standalone thinking skills:
|
||||
|
||||
| Skill | Module code | Purpose |
|
||||
| --- | --- | --- |
|
||||
| `bmad-brainstorming` | `bmad-brainstorming` | Diverge — facilitated ideation with a curated technique library |
|
||||
| `bmad-forge-idea` | `bmad-forge-idea` | Pressure-test — persona-driven interrogation until an idea hardens or dies cheaply |
|
||||
| `bmad-party-mode` | `bmad-party-mode` | Multi-perspective — round-table discussions between installed agents or custom personas |
|
||||
|
||||
All three are hidden single-skill modules. Any other module can also declare them as dependencies and get them installed automatically.
|
||||
|
||||
Each skill is documented in [Core Tools](./core-tools.md#standalone-thinking-skills).
|
||||
|
||||
## Source layout
|
||||
|
||||
In the BMad Method repository, standalone skill modules live under `src/standalone-skills/`:
|
||||
|
||||
```text
|
||||
src/standalone-skills/
|
||||
├── bmad-analysis/ # bundle: module.yaml (dependencies only) + module-help.csv
|
||||
├── bmad-brainstorming/ # hidden single-skill module
|
||||
│ ├── module.yaml
|
||||
│ ├── module-help.csv
|
||||
│ └── bmad-brainstorming/ # the skill itself
|
||||
├── bmad-forge-idea/
|
||||
└── bmad-party-mode/
|
||||
```
|
||||
|
||||
Each standalone module reads the central BMad configuration (user name, communication language, output folder) from the shared four-layer TOML merge — none of them asks its own install questions.
|
||||
@@ -49,6 +49,7 @@ Define what to build and for whom.
|
||||
|-------------------------|-------------------------------------------------------------------------------------|---------------------------------------------------|
|
||||
| `bmad-prd` | Create, update, or validate a PRD — facilitated discovery, three intents in one skill | Create/Update: `prd.md`, `addendum.md`, `.memlog.md`; Validate: `validation-report.html` + `.md` |
|
||||
| `bmad-ux` | Design user experience (when UX matters) — DESIGN.md (visual) + EXPERIENCE.md (behavioral) spine pair | `DESIGN.md`, `EXPERIENCE.md`, `.memlog.md` |
|
||||
| `bmad-spec` | Distill any intent input (brief, PRD, transcript, brain dump, design folder) into a succinct SPEC.md contract + companions — locks the WHAT before the HOW | `SPEC.md` + companions under `{output_folder}/specs/spec-{slug}/`; optional `stories.yaml` |
|
||||
|
||||
:::tip[Three intents in one skill]
|
||||
`bmad-prd` handles the full PRD lifecycle. State your intent when invoking or the skill will ask:
|
||||
@@ -58,6 +59,10 @@ Define what to build and for whom.
|
||||
- **Validate** — critique a PRD against a configurable checklist and produce a structured HTML findings report
|
||||
:::
|
||||
|
||||
:::note[`bmad-spec`]
|
||||
`bmad-spec` produces the canonical machine contract: a five-field kernel (Why, Capabilities, Constraints, Non-goals, Success signal) plus companion files, validated so every load-bearing source claim is preserved. It is the only writer of `SPEC.md`; other skills invoke it headless when they need to express or update intent. On request it can also break a spec into an ordered `stories.yaml` for autonomous dispatch — see [Autonomous Development Loops](./dev-auto.md).
|
||||
:::
|
||||
|
||||
:::tip[Upstream: `bmad-product-brief`]
|
||||
`bmad-product-brief` (Phase 1) produces a `product-brief.md` that `bmad-prd` can source-extract during Discovery, reducing re-explanation and keeping the two documents aligned. Neither skill requires the other — start with `bmad-prd` directly if you already know what you're building.
|
||||
:::
|
||||
|
||||
@@ -138,8 +138,8 @@ Create it manually at `_bmad-output/project-context.md` or generate it after arc
|
||||
|
||||
All workflows in this phase are optional. [**Not sure which to use?**](../explanation/analysis-phase.md)
|
||||
|
||||
- **brainstorming** (`bmad-brainstorming`) — Guided ideation
|
||||
- **forge-idea** (`bmad-forge-idea`) — Pressure-test an idea until it hardens or dies cheaply
|
||||
- **brainstorming** (`bmad-brainstorming`) — Guided ideation _(installs with the BMad Analysis module)_
|
||||
- **forge-idea** (`bmad-forge-idea`) — Pressure-test an idea until it hardens or dies cheaply _(installs with the BMad Analysis module)_
|
||||
- **research** (`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`) — Market, domain, and technical research
|
||||
- **product-brief** (`bmad-product-brief`) — Recommended foundation document when your concept is clear
|
||||
- **prfaq** (`bmad-prfaq`) — Working Backwards challenge to stress-test your product concept customer-first
|
||||
@@ -171,7 +171,7 @@ If your project has a user interface, invoke the **UX-Designer agent** (`bmad-ag
|
||||
**Create Architecture**
|
||||
|
||||
1. Invoke the **Architect agent** (`bmad-agent-architect`) in a new chat
|
||||
2. Run `bmad-create-architecture` (`bmad-create-architecture`)
|
||||
2. Run `bmad-architecture` (`bmad-architecture`)
|
||||
3. Output: Architecture document with technical decisions
|
||||
|
||||
**Create Epics and Stories**
|
||||
@@ -241,7 +241,7 @@ your-project/
|
||||
| ------------------------------------- | ------------------------------------- | --------- | ------------------------------------------ |
|
||||
| **`bmad-help`** ⭐ | `bmad-help` | Any | **Your intelligent guide — ask anything!** |
|
||||
| `bmad-prd` | `bmad-prd` | Any | Create, update, or validate a PRD |
|
||||
| `bmad-create-architecture` | `bmad-create-architecture` | Architect | Create architecture document |
|
||||
| `bmad-architecture` | `bmad-architecture` | Architect | Create architecture document |
|
||||
| `bmad-generate-project-context` | `bmad-generate-project-context` | Analyst | Create project context file |
|
||||
| `bmad-create-epics-and-stories` | `bmad-create-epics-and-stories` | PM | Break down PRD into epics |
|
||||
| `bmad-check-implementation-readiness` | `bmad-check-implementation-readiness` | Architect | Validate planning cohesion |
|
||||
|
||||
@@ -65,7 +65,7 @@ Chỉ dùng cho cảnh báo nghiêm trọng — mất dữ liệu, vấn đề b
|
||||
| Skill | Agent | Mục đích |
|
||||
| ----- | ----- | -------- |
|
||||
| `bmad-brainstorming` | Analyst | Brainstorm cho dự án mới |
|
||||
| `bmad-create-prd` | PM | Tạo tài liệu yêu cầu sản phẩm |
|
||||
| `bmad-prd` | PM | Tạo tài liệu yêu cầu sản phẩm |
|
||||
```
|
||||
|
||||
## Khối cấu trúc thư mục
|
||||
|
||||
@@ -638,7 +638,7 @@ Ngoài QA workflow, Developer Agent còn hỗ trợ:
|
||||
|
||||
```bash
|
||||
# Trong hội thoại với Developer Agent
|
||||
bmad-review-edge-case-hunter
|
||||
bmad-review
|
||||
```
|
||||
|
||||
Phân tích toàn bộ nhánh điều kiện trong code để tìm:
|
||||
@@ -686,7 +686,7 @@ Dùng sau khi có một tài liệu quan trọng (PRD, Architecture) để tìm
|
||||
### 8.3. Adversarial Review — Review hoài nghi
|
||||
|
||||
```bash
|
||||
bmad-review-adversarial-general
|
||||
bmad-review
|
||||
```
|
||||
|
||||
Review kiểu "devil's advocate" — giả định vấn đề luôn tồn tại:
|
||||
@@ -694,14 +694,6 @@ Review kiểu "devil's advocate" — giả định vấn đề luôn tồn tại
|
||||
- Tìm những gì **còn thiếu**, không chỉ những gì sai
|
||||
- Trực giao với Edge Case Hunter
|
||||
|
||||
### 8.4. Shard Large Documents — Tách file lớn
|
||||
|
||||
```bash
|
||||
bmad-shard-doc
|
||||
```
|
||||
|
||||
Tách file markdown lớn thành các file phần nhỏ hơn, với index tự động.
|
||||
|
||||
---
|
||||
|
||||
## 9. Cấu trúc thư mục dự án
|
||||
|
||||
@@ -21,7 +21,7 @@ Tệp `project-context.md` giải quyết vấn đề này bằng cách tài li
|
||||
Mỗi workflow triển khai đều tự động nạp `project-context.md` nếu tệp tồn tại. Workflow architect cũng nạp tệp này để tôn trọng các ưu tiên kỹ thuật của bạn khi thiết kế kiến trúc.
|
||||
|
||||
**Được nạp bởi các workflow sau:**
|
||||
- `bmad-create-architecture` - tôn trọng ưu tiên kỹ thuật trong giai đoạn solutioning
|
||||
- `bmad-architecture` - tôn trọng ưu tiên kỹ thuật trong giai đoạn solutioning
|
||||
- `bmad-create-story` - đưa pattern của dự án vào quá trình tạo story
|
||||
- `bmad-dev-story` - định hướng các quyết định triển khai
|
||||
- `bmad-code-review` - đối chiếu với tiêu chuẩn của dự án
|
||||
@@ -34,7 +34,7 @@ Tệp `project-context.md` hữu ích ở bất kỳ giai đoạn nào của d
|
||||
|
||||
| Tình huống | Khi nào nên tạo | Mục đích |
|
||||
|----------|----------------|---------|
|
||||
| **Dự án mới, trước kiến trúc** | Tạo thủ công, trước `bmad-create-architecture` | Ghi lại ưu tiên kỹ thuật để architect tôn trọng |
|
||||
| **Dự án mới, trước kiến trúc** | Tạo thủ công, trước `bmad-architecture` | Ghi lại ưu tiên kỹ thuật để architect tôn trọng |
|
||||
| **Dự án mới, sau kiến trúc** | Qua `bmad-generate-project-context` hoặc tạo thủ công | Ghi lại quyết định kiến trúc cho các agent triển khai |
|
||||
| **Dự án hiện có** | Qua `bmad-generate-project-context` | Khám phá pattern hiện có để agent theo đúng quy ước |
|
||||
| **Dự án Quick Flow** | Trước hoặc trong `bmad-quick-dev` | Đảm bảo triển khai nhanh vẫn tôn trọng pattern của bạn |
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: 'Cách mở rộng BMad cho tổ chức của bạn'
|
||||
description: Năm mẫu tùy chỉnh giúp thay đổi BMad mà không cần fork, gồm quy tắc ở cấp agent, quy ước workflow, xuất bản ra hệ thống ngoài, thay template và điều chỉnh danh sách agent
|
||||
sidebar:
|
||||
order: 11
|
||||
order: 10
|
||||
---
|
||||
|
||||
Bề mặt tùy chỉnh của BMad cho phép một tổ chức định hình lại hành vi mà không phải sửa file đã cài hay fork skill. Hướng dẫn này trình bày năm công thức mẫu (recipe) bao phủ phần lớn nhu cầu ở môi trường doanh nghiệp.
|
||||
|
||||
@@ -1,78 +0,0 @@
|
||||
---
|
||||
title: "Hướng dẫn chia nhỏ tài liệu"
|
||||
description: Tách các tệp markdown lớn thành nhiều tệp nhỏ có tổ chức để quản lý context tốt hơn
|
||||
sidebar:
|
||||
order: 10
|
||||
---
|
||||
|
||||
Sử dụng công cụ `bmad-shard-doc` nếu bạn cần tách các tệp markdown lớn thành nhiều tệp nhỏ có tổ chức để quản lý context tốt hơn.
|
||||
|
||||
:::caution[Đã ngừng khuyến nghị]
|
||||
Đây không còn là cách được khuyến nghị, và trong thời gian tới khi workflow được cập nhật và đa số LLM/công cụ lớn hỗ trợ subprocesses, việc này sẽ không còn cần thiết.
|
||||
:::
|
||||
|
||||
## Khi nào nên dùng
|
||||
|
||||
Chỉ dùng cách này nếu bạn nhận thấy tổ hợp công cụ / model bạn đang dùng không thể nạp và đọc đầy đủ tất cả tài liệu đầu vào khi cần.
|
||||
|
||||
## Chia nhỏ tài liệu là gì?
|
||||
|
||||
Chia nhỏ tài liệu là việc tách các tệp markdown lớn thành nhiều tệp nhỏ có tổ chức dựa trên các tiêu đề cấp 2 (`## Tiêu đề`).
|
||||
|
||||
### Kiến trúc
|
||||
|
||||
```text
|
||||
Trước khi chia nhỏ:
|
||||
_bmad-output/planning-artifacts/
|
||||
└── PRD.md (tệp lớn 50k token)
|
||||
|
||||
Sau khi chia nhỏ:
|
||||
_bmad-output/planning-artifacts/
|
||||
└── prd/
|
||||
├── index.md # Mục lục kèm mô tả
|
||||
├── overview.md # Phần 1
|
||||
├── user-requirements.md # Phần 2
|
||||
├── technical-requirements.md # Phần 3
|
||||
└── ... # Các phần bổ sung
|
||||
```
|
||||
|
||||
## Các bước thực hiện
|
||||
|
||||
### 1. Chạy công cụ Shard-Doc
|
||||
|
||||
```bash
|
||||
/bmad-shard-doc
|
||||
```
|
||||
|
||||
### 2. Làm theo quy trình tương tác
|
||||
|
||||
```text
|
||||
Agent: Bạn muốn chia nhỏ tài liệu nào?
|
||||
User: docs/PRD.md
|
||||
|
||||
Agent: Thư mục đích mặc định: docs/prd/
|
||||
Chấp nhận mặc định? [y/n]
|
||||
User: y
|
||||
|
||||
Agent: Đang chia nhỏ PRD.md...
|
||||
✓ Đã tạo 12 tệp theo từng phần
|
||||
✓ Đã tạo index.md
|
||||
✓ Hoàn tất!
|
||||
```
|
||||
|
||||
## Cơ chế workflow tìm tài liệu
|
||||
|
||||
Workflow của BMad dùng **hệ thống phát hiện kép**:
|
||||
|
||||
1. **Thử tài liệu nguyên khối trước** - Tìm `document-name.md`
|
||||
2. **Kiểm tra bản đã chia nhỏ** - Tìm `document-name/index.md`
|
||||
3. **Quy tắc ưu tiên** - Bản nguyên khối được ưu tiên nếu cả hai cùng tồn tại; hãy xóa bản nguyên khối nếu bạn muốn workflow dùng bản đã chia nhỏ
|
||||
|
||||
## Hỗ trợ trong workflow
|
||||
|
||||
Tất cả workflow BMM đều hỗ trợ cả hai định dạng:
|
||||
|
||||
- Tài liệu nguyên khối
|
||||
- Tài liệu đã chia nhỏ
|
||||
- Tự động nhận diện
|
||||
- Trong suốt với người dùng
|
||||
@@ -52,7 +52,7 @@ Mỗi skill là một thư mục chứa file `SKILL.md`. Ví dụ với Claude C
|
||||
.claude/skills/
|
||||
├── bmad-help/
|
||||
│ └── SKILL.md
|
||||
├── bmad-create-prd/
|
||||
├── bmad-prd/
|
||||
│ └── SKILL.md
|
||||
├── bmad-agent-dev/
|
||||
│ └── SKILL.md
|
||||
@@ -93,8 +93,8 @@ Workflow skills chạy một quy trình có cấu trúc, nhiều bước mà kh
|
||||
| --- | --- |
|
||||
| `bmad-product-brief` | Tạo product brief — phiên discovery có hướng dẫn khi concept của bạn đã rõ |
|
||||
| `bmad-prfaq` | Bài kiểm tra [Working Backwards PRFAQ](../explanation/analysis-phase.md#prfaq-working-backwards) để stress-test concept sản phẩm |
|
||||
| `bmad-create-prd` | Tạo Product Requirements Document |
|
||||
| `bmad-create-architecture` | Thiết kế kiến trúc hệ thống |
|
||||
| `bmad-prd` | Tạo Product Requirements Document |
|
||||
| `bmad-architecture` | Thiết kế kiến trúc hệ thống |
|
||||
| `bmad-create-epics-and-stories` | Tạo epics và stories |
|
||||
| `bmad-dev-story` | Triển khai một story |
|
||||
| `bmad-code-review` | Chạy code review |
|
||||
@@ -120,11 +120,11 @@ bmad-help What are my options for UX design?
|
||||
|
||||
**Các task và tool lõi khác**
|
||||
|
||||
Module lõi có 11 công cụ tích hợp sẵn — review, nén tài liệu, brainstorming, quản lý tài liệu và nhiều hơn nữa. Xem [Core Tools](./core-tools.md) để có tài liệu tham chiếu đầy đủ.
|
||||
Module lõi có 5 công cụ tích hợp sẵn — trợ giúp, review, tinh luyện và tùy biến — và gói BMad Analysis tùy chọn bổ sung các skill tư duy độc lập (brainstorming, forge idea, party mode). Xem [Core Tools](./core-tools.md) để có tài liệu tham chiếu đầy đủ.
|
||||
|
||||
## Quy Ước Đặt Tên
|
||||
|
||||
Mọi skill đều dùng tiền tố `bmad-` theo sau là tên mô tả, ví dụ `bmad-agent-dev`, `bmad-create-prd`, `bmad-help`. Xem [Modules](./modules.md) để biết các module hiện có.
|
||||
Mọi skill đều dùng tiền tố `bmad-` theo sau là tên mô tả, ví dụ `bmad-agent-dev`, `bmad-prd`, `bmad-help`. Xem [Modules](./modules.md) để biết các module hiện có.
|
||||
|
||||
## Khắc Phục Sự Cố
|
||||
|
||||
|
||||
+157
-188
@@ -1,31 +1,39 @@
|
||||
---
|
||||
title: Công cụ cốt lõi
|
||||
description: Tài liệu tham chiếu cho mọi tác vụ và quy trình tích hợp sẵn có trong mọi bản cài BMad mà không cần module bổ sung.
|
||||
description: Tài liệu tham chiếu cho các skill tích hợp sẵn của module lõi, cùng các skill tư duy độc lập và gói BMad Analysis.
|
||||
sidebar:
|
||||
order: 3
|
||||
---
|
||||
|
||||
Mọi bản cài BMad đều bao gồm một tập skill cốt lõi có thể dùng cùng với bất cứ việc gì bạn đang làm, các tác vụ và quy trình độc lập hoạt động xuyên suốt mọi dự án, mọi module và mọi giai đoạn. Chúng luôn có sẵn bất kể bạn cài những module tùy chọn nào.
|
||||
Mọi bản cài BMad đều bao gồm **module lõi** — một tập nhỏ các skill hoạt động xuyên suốt mọi dự án, mọi module và mọi giai đoạn. Trang này bao quát 5 skill lõi đó, cùng các **skill tư duy độc lập** (brainstorming, forge idea, party mode) được cài riêng dưới dạng module độc lập — dễ nhất là qua gói **BMad Analysis**.
|
||||
|
||||
:::tip[Lối đi nhanh]
|
||||
Chạy bất kỳ công cụ cốt lõi nào bằng cách gõ tên skill của nó, ví dụ `bmad-help`, trong IDE của bạn. Không cần mở phiên agent trước.
|
||||
Chạy bất kỳ công cụ nào bằng cách gõ tên skill của nó, ví dụ `bmad-help`, trong IDE của bạn. Không cần mở phiên agent trước.
|
||||
:::
|
||||
|
||||
## Tổng Quan
|
||||
|
||||
| Công cụ | Loại | Mục đích |
|
||||
| --- | --- | --- |
|
||||
| [`bmad-help`](#bmad-help) | Tác vụ | Nhận hướng dẫn có ngữ cảnh về việc nên làm gì tiếp theo |
|
||||
| [`bmad-brainstorming`](#bmad-brainstorming) | Quy trình | Tổ chức các phiên brainstorming có tương tác |
|
||||
| [`bmad-party-mode`](#bmad-party-mode) | Quy trình | Điều phối thảo luận nhóm nhiều agent |
|
||||
| [`bmad-spec`](#bmad-spec) | Quy trình | Distill any intent input into a SPEC kernel and companions, the canonical contract for downstream work (translation pending) |
|
||||
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | Tác vụ | Đẩy đầu ra của LLM qua các vòng tinh luyện lặp |
|
||||
| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | Tác vụ | Rà soát hoài nghi để tìm chỗ thiếu và chỗ sai |
|
||||
| [`bmad-review-edge-case-hunter`](#bmad-review-edge-case-hunter) | Tác vụ | Phân tích toàn bộ nhánh rẽ để tìm trường hợp biên chưa được xử lý |
|
||||
| [`bmad-editorial-review-prose`](#bmad-editorial-review-prose) | Tác vụ | Biên tập câu chữ nhằm tăng độ rõ ràng khi giao tiếp |
|
||||
| [`bmad-editorial-review-structure`](#bmad-editorial-review-structure) | Tác vụ | Biên tập cấu trúc — cắt, gộp và tổ chức lại |
|
||||
| [`bmad-shard-doc`](#bmad-shard-doc) | Tác vụ | Tách file markdown lớn thành các phần có tổ chức |
|
||||
| [`bmad-index-docs`](#bmad-index-docs) | Tác vụ | Tạo hoặc cập nhật mục lục cho toàn bộ tài liệu trong một thư mục |
|
||||
**Module lõi (luôn được cài):**
|
||||
|
||||
| Công cụ | Mục đích |
|
||||
| --- | --- |
|
||||
| [`bmad-help`](#bmad-help) | Nhận hướng dẫn có ngữ cảnh về việc nên làm gì tiếp theo |
|
||||
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | Đẩy đầu ra của LLM qua các vòng tinh luyện lặp |
|
||||
| [`bmad-editorial-review`](#bmad-editorial-review) | Review biên tập hai lượt — cấu trúc trước, câu chữ sau |
|
||||
| [`bmad-review`](#bmad-review) | Review phản biện đa lăng kính — hoài nghi, ca biên và lỗ hổng kiểm chứng |
|
||||
| [`bmad-customize`](#bmad-customize) | Tạo và kiểm tra các tùy biến BMad |
|
||||
|
||||
**Skill tư duy độc lập (cài qua [gói BMad Analysis](../../reference/standalone-skills.md) hoặc riêng lẻ):**
|
||||
|
||||
| Công cụ | Mục đích |
|
||||
| --- | --- |
|
||||
| [`bmad-brainstorming`](#bmad-brainstorming) | Tổ chức các phiên brainstorming có tương tác |
|
||||
| [`bmad-forge-idea`](#bmad-forge-idea) | Thử lửa một ý tưởng cho đến khi nó cứng cáp, được chứng thực hoặc chết với chi phí thấp |
|
||||
| [`bmad-party-mode`](#bmad-party-mode) | Điều phối thảo luận nhóm nhiều agent |
|
||||
|
||||
:::note[Đã chuyển và đã gỡ]
|
||||
`bmad-spec` giờ đi kèm module BMM như một workflow lập kế hoạch Giai đoạn 2 — xem [Bản đồ Workflow](./workflow-map.md). Các tiện ích `bmad-shard-doc` và `bmad-index-docs` đã bị gỡ bỏ. Các skill cũ `bmad-editorial-review-prose`, `bmad-editorial-review-structure`, `bmad-review-adversarial-general`, `bmad-review-edge-case-hunter` và `bmad-review-verification-gap` đã được gộp vào `bmad-editorial-review` và `bmad-review`; các ID cũ vẫn hoạt động qua cơ chế chuyển tiếp ẩn để giữ tương thích.
|
||||
:::
|
||||
|
||||
## bmad-help
|
||||
|
||||
@@ -49,7 +57,115 @@ Chạy bất kỳ công cụ cốt lõi nào bằng cách gõ tên skill của n
|
||||
|
||||
**Đầu ra:** Danh sách ưu tiên các bước tiếp theo được khuyến nghị kèm lệnh skill
|
||||
|
||||
## bmad-brainstorming
|
||||
## bmad-advanced-elicitation
|
||||
|
||||
**Đẩy LLM xem xét lại, tinh luyện và cải thiện đầu ra gần nhất của nó.** Đây là điểm dừng tinh luyện dùng chung của BMad: các skill khác gọi nó tại các điểm nghỉ tự nhiên, và bạn có thể gọi trực tiếp lên bất kỳ nội dung nào gần đây trong cuộc hội thoại.
|
||||
|
||||
**Dùng khi:**
|
||||
|
||||
- Đầu ra của LLM còn nông hoặc quá chung chung
|
||||
- Bạn muốn khám phá một chủ đề từ nhiều góc phân tích khác nhau
|
||||
- Bạn đang tinh chỉnh một tài liệu quan trọng và cần chiều sâu hơn
|
||||
- Bạn muốn gọi đích danh một phương pháp — Socratic, first principles, pre-mortem, red team
|
||||
|
||||
**Cách hoạt động:**
|
||||
|
||||
1. Mặc định nhắm vào đầu ra gần nhất trong hội thoại, trừ khi bạn chỉ định nội dung khác
|
||||
2. Đưa ra một menu ngắn các phương pháp elicitation phù hợp nhất với nội dung
|
||||
3. Áp dụng các phương pháp đã chọn lên mục tiêu
|
||||
4. Trả lại phiên bản đã cải thiện để luồng gọi tiếp tục từ chỗ tạm dừng
|
||||
|
||||
**Đầu vào:** Đầu ra gần nhất cần tinh luyện (mặc định), hoặc bất kỳ nội dung nào bạn chỉ định; tùy chọn kèm tên phương pháp
|
||||
|
||||
**Đầu ra:** Phiên bản nội dung đã được nâng cấp
|
||||
|
||||
## bmad-editorial-review
|
||||
|
||||
**Review biên tập hai lượt — cấu trúc trước, câu chữ sau.** Một biên tập viên lâm sàng review cả hình khối của tài liệu lẫn từng câu chữ, trả về các đề xuất sửa để bạn chấp nhận hoặc từ chối theo từng dòng. Nội dung là bất khả xâm phạm: nó không bao giờ chất vấn ý tưởng của bạn, chỉ cách tổ chức và diễn đạt.
|
||||
|
||||
**Dùng khi:**
|
||||
|
||||
- Bạn đã có bản nháp và muốn siết chặt, trau chuốt nó
|
||||
- Tài liệu được ghép từ nhiều quy trình con và cần sự mạch lạc về cấu trúc
|
||||
- Bạn muốn giảm độ dài mà vẫn giữ được khả năng hiểu
|
||||
- Bạn muốn sửa cho rõ nghĩa mà không áp đặt gu phong cách
|
||||
|
||||
**Cách hoạt động:**
|
||||
|
||||
1. **Lượt cấu trúc** — đề xuất cắt, gộp, di chuyển và cô đọng; đặt câu hỏi liệu hình khối tài liệu có phục vụ mục đích của nó
|
||||
2. **Lượt câu chữ** — biên tập các vấn đề giao tiếp cản trở việc hiểu, dùng Microsoft Writing Style Guide làm nền (style guide bạn cung cấp sẽ được ưu tiên)
|
||||
3. Mặc định chạy cả hai lượt, cấu trúc trước; yêu cầu review chỉ cấu trúc hoặc chỉ câu chữ nếu muốn chạy một lượt
|
||||
4. Chỉ đề xuất, không bao giờ tự sửa — tác giả quyết định chấp nhận gì
|
||||
|
||||
**Đầu vào:**
|
||||
|
||||
- `content` *(bắt buộc)* — Tài liệu cần review
|
||||
- `style_guide` *(tùy chọn)* — Style guide riêng của dự án
|
||||
- `reader_type` *(tùy chọn)* — `humans` mặc định cho độ rõ và nhịp đọc, hoặc `llm` cho độ chính xác và nhất quán
|
||||
- `purpose` / `target_audience` / `length_target` *(tùy chọn)* — hiệu chỉnh lượt cấu trúc
|
||||
|
||||
**Đầu ra:** Bảng phát hiện kèm đề xuất sửa, cộng ước tính mức rút gọn khi có đề xuất thay đổi cấu trúc
|
||||
|
||||
## bmad-review
|
||||
|
||||
**Review phản biện đa lăng kính trên bất kỳ diff, tài liệu hay artifact nào.** Chạy các lăng kính review độc lập — mỗi lăng kính một phương pháp và lập trường riêng — và báo cáo mọi phát hiện theo một định dạng chuẩn duy nhất. Không phát hiện gì cũng là kết quả hợp lệ; nó không bao giờ độn thêm cho có vẻ kỹ lưỡng.
|
||||
|
||||
**Các lăng kính đi kèm:**
|
||||
|
||||
| Lăng kính | Phương pháp |
|
||||
| --- | --- |
|
||||
| **Hoài nghi (Adversarial)** | Review hoài nghi mặc định vấn đề luôn tồn tại — săn phần còn thiếu, không chỉ phần sai |
|
||||
| **Ca biên (Edge case)** | Đi qua mọi nhánh rẽ và điều kiện biên, chỉ báo cáo các đường chưa được xử lý |
|
||||
| **Lỗ hổng kiểm chứng (Verification gap)** | Tìm hành vi đã thay đổi có thể hồi quy mà không có kiểm chứng đáng tin cậy nào bắt được |
|
||||
|
||||
**Dùng khi:**
|
||||
|
||||
- Bạn cần bảo đảm chất lượng trước khi chốt một deliverable
|
||||
- Bạn muốn phủ kín các ca biên của code hoặc logic
|
||||
- Bạn muốn biết một thay đổi đã được kiểm chứng đầy đủ chưa
|
||||
- Bạn muốn cả ba góc nhìn cùng lúc (mặc định)
|
||||
|
||||
**Cách hoạt động:**
|
||||
|
||||
1. Nạp nội dung và nhận diện loại — diff, file, hàm hoặc tài liệu
|
||||
2. Chọn lăng kính: những cái bạn nêu tên, hoặc mọi lăng kính đang bật phù hợp với nội dung
|
||||
3. Chạy từng lăng kính độc lập — song song qua subagent khi nền tảng hỗ trợ
|
||||
4. Gom về một danh sách phát hiện duy nhất; trùng lặp giữa các lăng kính là tín hiệu, không phải lặp thừa
|
||||
|
||||
**Đầu vào:**
|
||||
|
||||
- `content` *(bắt buộc)* — Diff, branch, thay đổi chưa commit, file, spec, story hoặc bất kỳ tài liệu nào
|
||||
- `lenses` *(tùy chọn)* — một hoặc nhiều mã/tên lăng kính; mặc định là review đầy đủ
|
||||
- `also_consider` *(tùy chọn)* — Các vùng bổ sung cần để ý
|
||||
|
||||
**Đầu ra:** Mảng phát hiện JSON và/hoặc báo cáo markdown nhóm theo lăng kính. Có thể thêm lăng kính tùy biến — và tinh chỉnh hoặc tắt các lăng kính đi kèm — qua `customize.toml` của skill
|
||||
|
||||
## bmad-customize
|
||||
|
||||
**Tạo và kiểm tra các tùy biến.** Giúp bạn thay đổi hành vi của một agent hoặc workflow BMad đã cài mà không phải tự viết TOML.
|
||||
|
||||
**Dùng khi:**
|
||||
|
||||
- Bạn muốn thay đổi hành vi của một agent hoặc workflow
|
||||
- Bạn cần thêm các dữ kiện bền vững, hook kích hoạt hoặc mục menu tùy biến
|
||||
- Bạn muốn phạm vi override đúng được chọn và kiểm tra tự động
|
||||
|
||||
**Cách hoạt động:**
|
||||
|
||||
1. Quét các skill BMad đã cài để tìm các bề mặt có thể tùy biến
|
||||
2. Chọn phạm vi phù hợp cho thay đổi bạn yêu cầu
|
||||
3. Ghi các file override dưới `_bmad/custom/`
|
||||
4. Kiểm tra cấu hình sau khi hợp nhất
|
||||
|
||||
**Đầu vào:** Mô tả bằng ngôn ngữ tự nhiên về tùy biến bạn muốn
|
||||
|
||||
**Đầu ra:** Các file override TOML dưới `_bmad/custom/`. Xem hướng dẫn chi tiết tại [Cách tùy biến BMad](../how-to/customize-bmad.md)
|
||||
|
||||
## Các skill tư duy độc lập
|
||||
|
||||
Ba skill dưới đây không thuộc module lõi. Mỗi cái là một module đơn skill riêng, được ẩn khỏi bộ chọn của trình cài đặt, và đến qua gói **BMad Analysis** hiển thị hoặc khi một module khác khai báo nó làm dependency. Xem [Skill độc lập và Dependency giữa các Module](../../reference/standalone-skills.md) để hiểu cơ chế.
|
||||
|
||||
### bmad-brainstorming
|
||||
|
||||
**Tạo ra nhiều ý tưởng đa dạng bằng các kỹ thuật sáng tạo có tương tác.** Đây là một phiên động não có điều phối, nạp các phương pháp phát ý tưởng đã được kiểm chứng từ thư viện kỹ thuật và dẫn bạn đến 100+ ý tưởng trước khi bắt đầu sắp xếp.
|
||||
|
||||
@@ -65,17 +181,38 @@ Chạy bất kỳ công cụ cốt lõi nào bằng cách gõ tên skill của n
|
||||
2. Nạp các kỹ thuật sáng tạo từ thư viện phương pháp
|
||||
3. Dẫn bạn đi qua từng kỹ thuật để tạo ý tưởng
|
||||
4. Áp dụng giao thức chống thiên lệch — cứ mỗi 10 ý tưởng lại đổi miền sáng tạo để tránh gom cụm
|
||||
5. Tạo một tài liệu phiên làm việc chỉ thêm vào, trong đó mọi ý tưởng được tổ chức theo kỹ thuật
|
||||
|
||||
**Đầu vào:** Chủ đề brainstorming hoặc phát biểu vấn đề, cùng file context tùy chọn
|
||||
|
||||
**Đầu ra:** `brainstorming-session-{date}.md` chứa toàn bộ ý tưởng được tạo ra
|
||||
**Đầu ra:** một trang `brainstorm.html` độc lập làm kỷ vật của phiên, file `brainstorm-intent.md` tùy chọn cho các skill hạ nguồn, và bản ghi phiên `.memlog.md`
|
||||
|
||||
:::note[Mục tiêu về số lượng]
|
||||
Điểm bứt phá thường nằm ở vùng ý tưởng thứ 50-100. Workflow này khuyến khích bạn tạo 100+ ý tưởng trước khi sắp xếp.
|
||||
:::
|
||||
|
||||
## bmad-party-mode
|
||||
### bmad-forge-idea
|
||||
|
||||
**Thử lửa một ý tưởng cho đến khi nó cứng cáp, được chứng thực hoặc chết với chi phí thấp.** Một người chất vấn phản biện dồn một ý tưởng còn dang dở đi từng câu hỏi một, đưa hai nhân vật vào mỗi nhánh rẽ, cho đến khi thứ sống sót là điều bạn có thể hành động với niềm tin chắc chắn.
|
||||
|
||||
**Dùng khi:**
|
||||
|
||||
- Bạn có một ý tưởng và muốn stress-test nó trước khi đầu tư
|
||||
- Bạn muốn một đánh giá thẳng thắn về việc có nên bỏ nó không
|
||||
- Bạn cần một người đồng hành tư duy biết phản bác thay vì gật đầu
|
||||
|
||||
**Cách hoạt động:**
|
||||
|
||||
1. Xác lập mục tiêu ngay từ đầu và lái việc chất vấn theo mục tiêu đó
|
||||
2. Làm việc từng câu hỏi một theo thứ tự phụ thuộc, đặt sẵn một câu trả lời khuyến nghị để bạn phản bác
|
||||
3. Đưa hai giọng nói vào mỗi nhánh — một từ đội hình đã cài của bạn, một do chủ đề gợi lên
|
||||
4. Chất vấn các thuật ngữ mơ hồ và kiểm tra các luận điểm dựa trên tư liệu của dự án hiện có
|
||||
5. Kết thúc ở trạng thái Hardened (cứng cáp), Killed (bị loại) hoặc Clearer (rõ hơn), kèm báo cáo độc lập bạn có thể giữ lại
|
||||
|
||||
**Đầu vào:** Ý tưởng thuộc bất kỳ lĩnh vực nào — một tính năng, mô hình kinh doanh, giả thuyết nghiên cứu, quyết định cuộc sống
|
||||
|
||||
**Đầu ra:** Bản chưng cất `forged-idea.md` khi ý tưởng cứng cáp (tùy chọn), cộng một `forge-report.html` làm kỷ vật cho mỗi lần chạy
|
||||
|
||||
### bmad-party-mode
|
||||
|
||||
**Điều phối thảo luận nhóm nhiều agent.** Công cụ này nạp toàn bộ agent BMad đã cài và tạo một cuộc trao đổi tự nhiên, nơi mỗi agent đóng góp từ góc nhìn chuyên môn và cá tính riêng.
|
||||
|
||||
@@ -96,171 +233,3 @@ Chạy bất kỳ công cụ cốt lõi nào bằng cách gõ tên skill của n
|
||||
**Đầu vào:** Chủ đề hoặc câu hỏi thảo luận, cùng thông tin về các persona bạn muốn tham gia nếu có
|
||||
|
||||
**Đầu ra:** Cuộc hội thoại nhiều agent theo thời gian thực, vẫn giữ nguyên cá tính từng agent
|
||||
|
||||
## bmad-advanced-elicitation
|
||||
|
||||
**Đẩy đầu ra của LLM qua các phương pháp tinh luyện lặp.** Công cụ này chọn từ thư viện kỹ thuật elicitation để cải thiện nội dung một cách có hệ thống qua nhiều lượt.
|
||||
|
||||
**Dùng khi:**
|
||||
|
||||
- Đầu ra của LLM còn nông hoặc quá chung chung
|
||||
- Bạn muốn khám phá một chủ đề từ nhiều góc phân tích khác nhau
|
||||
- Bạn đang tinh chỉnh một tài liệu quan trọng và cần chiều sâu hơn
|
||||
|
||||
**Cách hoạt động:**
|
||||
|
||||
1. Nạp registry phương pháp với hơn 5 kỹ thuật elicitation
|
||||
2. Chọn ra 5 phương pháp phù hợp nhất dựa trên loại nội dung và độ phức tạp
|
||||
3. Hiển thị menu tương tác — chọn một phương pháp, xáo lại, hoặc liệt kê tất cả
|
||||
4. Áp dụng phương pháp đã chọn để nâng cấp nội dung
|
||||
5. Tiếp tục đưa ra lựa chọn cho các vòng cải thiện tiếp theo cho đến khi bạn chọn "Proceed"
|
||||
|
||||
**Đầu vào:** Phần nội dung cần cải thiện
|
||||
|
||||
**Đầu ra:** Phiên bản nội dung đã được nâng cấp
|
||||
|
||||
## bmad-review-adversarial-general
|
||||
|
||||
**Kiểu review hoài nghi, mặc định cho rằng vấn đề luôn tồn tại và phải đi tìm chúng.** Công cụ này đứng ở góc nhìn của một reviewer khó tính, thiếu kiên nhẫn với sản phẩm cẩu thả. Nó tìm xem còn thiếu gì, không chỉ tìm cái gì sai.
|
||||
|
||||
**Dùng khi:**
|
||||
|
||||
- Bạn cần bảo đảm chất lượng trước khi chốt một deliverable
|
||||
- Bạn muốn stress-test một spec, story hoặc tài liệu
|
||||
- Bạn muốn tìm lỗ hổng bao phủ mà các review lạc quan thường bỏ sót
|
||||
|
||||
**Cách hoạt động:**
|
||||
|
||||
1. Đọc nội dung với góc nhìn hoài nghi và khắt khe
|
||||
2. Xác định vấn đề về độ đầy đủ, độ đúng và chất lượng
|
||||
3. Chủ động tìm phần còn thiếu chứ không chỉ phần hiện diện nhưng sai
|
||||
4. Phải tìm được tối thiểu 10 vấn đề, nếu không sẽ phân tích sâu hơn
|
||||
|
||||
**Đầu vào:**
|
||||
|
||||
- `content` *(bắt buộc)* — Diff, spec, story, tài liệu hoặc bất kỳ artifact nào
|
||||
- `also_consider` *(tùy chọn)* — Các vùng bổ sung cần để ý
|
||||
|
||||
**Đầu ra:** Danh sách markdown gồm 10+ phát hiện kèm mô tả
|
||||
|
||||
## bmad-review-edge-case-hunter
|
||||
|
||||
**Đi qua mọi nhánh rẽ và điều kiện biên, chỉ báo cáo những trường hợp chưa được xử lý.** Đây là phương pháp thuần túy dựa trên truy vết đường đi, suy ra các lớp edge case một cách cơ học. Nó trực giao với adversarial review — khác phương pháp, không khác thái độ.
|
||||
|
||||
**Dùng khi:**
|
||||
|
||||
- Bạn muốn bao phủ edge case toàn diện cho code hoặc logic
|
||||
- Bạn cần một phương pháp bổ sung cho adversarial review
|
||||
- Bạn đang review diff hoặc function để tìm điều kiện biên
|
||||
|
||||
**Cách hoạt động:**
|
||||
|
||||
1. Liệt kê toàn bộ nhánh rẽ trong nội dung
|
||||
2. Suy ra cơ học các lớp edge case: thiếu else/default, input không được gác, off-by-one, tràn số học, ép kiểu ngầm, race condition, lỗ hổng timeout
|
||||
3. Đối chiếu từng đường đi với các guard hiện có
|
||||
4. Chỉ báo cáo các đường đi chưa được xử lý, âm thầm bỏ qua những trường hợp đã được che chắn
|
||||
|
||||
**Đầu vào:**
|
||||
|
||||
- `content` *(bắt buộc)* — Diff, toàn file hoặc function
|
||||
- `also_consider` *(tùy chọn)* — Các vùng bổ sung cần lưu ý
|
||||
|
||||
**Đầu ra:** Mảng JSON các phát hiện, mỗi phát hiện có `location`, `trigger_condition`, `guard_snippet` và `potential_consequence`
|
||||
|
||||
:::note[Các kiểu review bổ trợ nhau]
|
||||
Hãy chạy cả `bmad-review-adversarial-general` và `bmad-review-edge-case-hunter` để có độ bao phủ trực giao. Adversarial review bắt lỗi về chất lượng và độ đầy đủ; edge case hunter bắt các đường đi chưa được xử lý.
|
||||
:::
|
||||
|
||||
## bmad-editorial-review-prose
|
||||
|
||||
**Biên tập câu chữ kiểu lâm sàng, tập trung vào độ rõ ràng khi truyền đạt.** Công cụ này review văn bản để tìm ra các vấn đề cản trở việc hiểu. Nó dùng Microsoft Writing Style Guide làm nền và vẫn giữ giọng văn của tác giả.
|
||||
|
||||
**Dùng khi:**
|
||||
|
||||
- Bạn đã có bản nháp tài liệu và muốn trau chuốt câu chữ
|
||||
- Bạn cần đảm bảo độ rõ ràng cho một nhóm độc giả cụ thể
|
||||
- Bạn muốn sửa lỗi giao tiếp mà không áp đặt gu phong cách cá nhân
|
||||
|
||||
**Cách hoạt động:**
|
||||
|
||||
1. Đọc nội dung, bỏ qua code block và frontmatter
|
||||
2. Xác định các vấn đề cản trở hiểu nghĩa, không phải các sở thích phong cách
|
||||
3. Khử trùng lặp những lỗi giống nhau xuất hiện nhiều nơi
|
||||
4. Tạo bảng sửa lỗi ba cột
|
||||
|
||||
**Đầu vào:**
|
||||
|
||||
- `content` *(bắt buộc)* — Markdown, văn bản thường hoặc XML
|
||||
- `style_guide` *(tùy chọn)* — Style guide riêng của dự án
|
||||
- `reader_type` *(tùy chọn)* — `humans` mặc định cho độ rõ và nhịp đọc, hoặc `llm` cho độ chính xác và nhất quán
|
||||
|
||||
**Đầu ra:** Bảng markdown ba cột: Original Text | Revised Text | Changes
|
||||
|
||||
## bmad-editorial-review-structure
|
||||
|
||||
**Biên tập cấu trúc — đề xuất cắt, gộp, di chuyển và cô đọng.** Công cụ này review cách tổ chức tài liệu và đề xuất thay đổi mang tính nội dung để tăng độ rõ ràng và luồng đọc trước khi chỉnh câu chữ.
|
||||
|
||||
**Dùng khi:**
|
||||
|
||||
- Một tài liệu được ghép từ nhiều nguồn con và cần tính nhất quán về cấu trúc
|
||||
- Bạn muốn rút gọn độ dài tài liệu nhưng vẫn giữ được khả năng hiểu
|
||||
- Bạn cần phát hiện chỗ lệch phạm vi hoặc thông tin quan trọng bị chôn vùi
|
||||
|
||||
**Cách hoạt động:**
|
||||
|
||||
1. Phân tích tài liệu theo 5 mô hình cấu trúc: Tutorial, Reference, Explanation, Prompt, Strategic
|
||||
2. Xác định phần dư thừa, lệch phạm vi và thông tin bị chìm
|
||||
3. Tạo danh sách khuyến nghị theo mức ưu tiên: CUT, MERGE, MOVE, CONDENSE, QUESTION, PRESERVE
|
||||
4. Ước tính số từ và phần trăm có thể giảm
|
||||
|
||||
**Đầu vào:**
|
||||
|
||||
- `content` *(bắt buộc)* — Tài liệu cần review
|
||||
- `purpose` *(tùy chọn)* — Mục đích mong muốn, ví dụ "quickstart tutorial"
|
||||
- `target_audience` *(tùy chọn)* — Ai sẽ đọc tài liệu này
|
||||
- `reader_type` *(tùy chọn)* — `humans` hoặc `llm`
|
||||
- `length_target` *(tùy chọn)* — Mục tiêu rút gọn, ví dụ "ngắn hơn 30%"
|
||||
|
||||
**Đầu ra:** Tóm tắt tài liệu, danh sách khuyến nghị ưu tiên và ước tính mức giảm
|
||||
|
||||
## bmad-shard-doc
|
||||
|
||||
**Tách file markdown lớn thành các file phần có tổ chức.** Công cụ này dùng các header cấp 2 làm điểm cắt để tạo ra một thư mục gồm các file phần tự chứa cùng một file chỉ mục.
|
||||
|
||||
**Dùng khi:**
|
||||
|
||||
- Một file markdown đã quá lớn để quản lý hiệu quả, thường trên 500 dòng
|
||||
- Bạn muốn chia một tài liệu nguyên khối thành các phần dễ điều hướng
|
||||
- Bạn cần các file riêng để chỉnh sửa song song hoặc quản lý context cho LLM
|
||||
|
||||
**Cách hoạt động:**
|
||||
|
||||
1. Xác nhận file nguồn tồn tại và là markdown
|
||||
2. Tách tại các header cấp 2 `##` thành các file phần được đánh số
|
||||
3. Tạo `index.md` chứa danh sách phần và liên kết
|
||||
4. Hỏi bạn có muốn xóa, lưu trữ hay giữ file gốc không
|
||||
|
||||
**Đầu vào:** Đường dẫn file markdown nguồn, cùng thư mục đích tùy chọn
|
||||
|
||||
**Đầu ra:** Một thư mục gồm `index.md` và các file `01-{section}.md`, `02-{section}.md`, v.v.
|
||||
|
||||
## bmad-index-docs
|
||||
|
||||
**Tạo hoặc cập nhật mục lục cho toàn bộ tài liệu trong một thư mục.** Công cụ này quét thư mục, đọc từng file để hiểu mục đích của nó, rồi tạo `index.md` có tổ chức với liên kết và mô tả.
|
||||
|
||||
**Dùng khi:**
|
||||
|
||||
- Bạn cần một chỉ mục nhẹ để LLM quét nhanh các tài liệu hiện có
|
||||
- Một thư mục tài liệu đã lớn và cần bảng mục lục có tổ chức
|
||||
- Bạn muốn một cái nhìn tổng quan được tạo tự động và luôn theo kịp hiện trạng
|
||||
|
||||
**Cách hoạt động:**
|
||||
|
||||
1. Quét thư mục đích để lấy mọi file không ẩn
|
||||
2. Đọc từng file để hiểu đúng mục đích thực tế của nó
|
||||
3. Nhóm file theo loại, mục đích hoặc thư mục con
|
||||
4. Tạo mô tả ngắn gọn, thường từ 3-10 từ cho mỗi file
|
||||
|
||||
**Đầu vào:** Đường dẫn thư mục đích
|
||||
|
||||
**Đầu ra:** `index.md` chứa danh sách file có tổ chức, liên kết tương đối và mô tả ngắn
|
||||
|
||||
@@ -36,7 +36,7 @@ Xác định cần xây gì và xây cho ai.
|
||||
|
||||
| Quy trình | Mục đích | Tạo ra |
|
||||
| --------------------------- | ---------------------------------------- | ------------ |
|
||||
| `bmad-create-prd` | Xác định yêu cầu (FR/NFR) | `PRD.md` |
|
||||
| `bmad-prd` | Xác định yêu cầu (FR/NFR) | `PRD.md` |
|
||||
| `bmad-ux` | Thiết kế trải nghiệm người dùng khi UX là yếu tố quan trọng | `DESIGN.md`, `EXPERIENCE.md` |
|
||||
|
||||
## Giai đoạn 3: Định hình giải pháp
|
||||
@@ -45,7 +45,7 @@ Quyết định cách xây và chia nhỏ công việc thành các story.
|
||||
|
||||
| Quy trình | Mục đích | Tạo ra |
|
||||
| ----------------------------------------- | ------------------------------------------ | --------------------------- |
|
||||
| `bmad-create-architecture` | Làm rõ các quyết định kỹ thuật | `architecture.md` kèm ADR |
|
||||
| `bmad-architecture` | Làm rõ các quyết định kỹ thuật | `architecture.md` kèm ADR |
|
||||
| `bmad-create-epics-and-stories` | Phân rã yêu cầu thành các phần việc có thể triển khai | Các file epic chứa các story |
|
||||
| `bmad-check-implementation-readiness` | Cổng kiểm tra trước khi triển khai | Quyết định PASS/CONCERNS/FAIL |
|
||||
|
||||
|
||||
@@ -114,7 +114,7 @@ BMad-Help sẽ nhận biết bạn đã làm đến đâu và đề xuất chín
|
||||
:::
|
||||
|
||||
:::note[Cách Nạp Agent Và Chạy Workflow]
|
||||
Mỗi workflow có một **skill** được gọi bằng tên trong IDE của bạn, ví dụ `bmad-create-prd`. Công cụ AI sẽ nhận diện tên `bmad-*` và chạy nó, bạn không cần nạp agent riêng. Bạn cũng có thể gọi trực tiếp skill của agent để trò chuyện tổng quát, ví dụ `bmad-agent-pm` cho PM agent.
|
||||
Mỗi workflow có một **skill** được gọi bằng tên trong IDE của bạn, ví dụ `bmad-prd`. Công cụ AI sẽ nhận diện tên `bmad-*` và chạy nó, bạn không cần nạp agent riêng. Bạn cũng có thể gọi trực tiếp skill của agent để trò chuyện tổng quát, ví dụ `bmad-agent-pm` cho PM agent.
|
||||
:::
|
||||
|
||||
:::caution[Chat Mới]
|
||||
@@ -143,7 +143,7 @@ Tất cả workflow trong phase này đều là tùy chọn. [**Chưa chắc nê
|
||||
|
||||
**Với nhánh BMad Method và Enterprise:**
|
||||
1. Gọi **PM agent** (`bmad-agent-pm`) trong một chat mới
|
||||
2. Chạy workflow `bmad-create-prd` (`bmad-create-prd`)
|
||||
2. Chạy workflow `bmad-prd` (`bmad-prd`)
|
||||
3. Kết quả: `PRD.md`
|
||||
|
||||
**Với nhánh Quick Flow:**
|
||||
@@ -157,7 +157,7 @@ Nếu dự án của bạn có giao diện người dùng, hãy gọi **UX-Desig
|
||||
|
||||
**Tạo Architecture**
|
||||
1. Gọi **Architect agent** (`bmad-agent-architect`) trong một chat mới
|
||||
2. Chạy `bmad-create-architecture` (`bmad-create-architecture`)
|
||||
2. Chạy `bmad-architecture` (`bmad-architecture`)
|
||||
3. Kết quả: tài liệu kiến trúc chứa các quyết định kỹ thuật
|
||||
|
||||
**Tạo Epics và Stories**
|
||||
@@ -225,8 +225,8 @@ your-project/
|
||||
| Workflow | Lệnh | Agent | Mục đích |
|
||||
| ------------------------------------- | ------------------------------------------ | --------- | ----------------------------------------------- |
|
||||
| **`bmad-help`** ⭐ | `bmad-help` | Bất kỳ | **Người dẫn đường thông minh của bạn — hỏi gì cũng được!** |
|
||||
| `bmad-create-prd` | `bmad-create-prd` | PM | Tạo tài liệu yêu cầu sản phẩm |
|
||||
| `bmad-create-architecture` | `bmad-create-architecture` | Architect | Tạo tài liệu kiến trúc |
|
||||
| `bmad-prd` | `bmad-prd` | PM | Tạo tài liệu yêu cầu sản phẩm |
|
||||
| `bmad-architecture` | `bmad-architecture` | Architect | Tạo tài liệu kiến trúc |
|
||||
| `bmad-generate-project-context` | `bmad-generate-project-context` | Analyst | Tạo file project context |
|
||||
| `bmad-create-epics-and-stories` | `bmad-create-epics-and-stories` | PM | Phân rã PRD thành epics |
|
||||
| `bmad-check-implementation-readiness` | `bmad-check-implementation-readiness` | Architect | Kiểm tra độ nhất quán của kế hoạch |
|
||||
|
||||
@@ -65,7 +65,7 @@ Critical warnings only — data loss, security issues
|
||||
| Skill | Agent | Purpose |
|
||||
| -------------------- | ------- | ------------------------------------ |
|
||||
| `bmad-brainstorming` | Analyst | Brainstorm a new project |
|
||||
| `bmad-create-prd` | PM | Create Product Requirements Document |
|
||||
| `bmad-prd` | PM | Create Product Requirements Document |
|
||||
```
|
||||
|
||||
## 文件结构块（Folder Structure）
|
||||
|
||||
@@ -57,7 +57,7 @@ forge 是有声的。话题一定，每个分支都会来两个角色，而不
|
||||
| `bmad-prfaq` | 已承诺做产品，要 customer-first 验证 | Working Backwards 教练 |
|
||||
| `bmad-brainstorming` | 还没有想法，要生成选项 | 引导教练 |
|
||||
| `bmad-party-mode` | 要让 agent 一起讨论或决策 | 整个 roster 同场 |
|
||||
| `bmad-review-adversarial-general` | 有 artifact，要找 flaw | 必须找问题的 reviewer |
|
||||
| `bmad-review` | 有 artifact，要找 flaw | 必须找问题的 reviewer |
|
||||
|
||||
## 示例
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ sidebar:
|
||||
多数实现相关工作流会自动加载 `project-context.md`（若存在），并把它作为共享上下文参与决策。
|
||||
|
||||
**常见加载方包括：**
|
||||
- `bmad-create-architecture`：在 solutioning 时纳入你的技术偏好
|
||||
- `bmad-architecture`：在 solutioning 时纳入你的技术偏好
|
||||
- `bmad-create-story`：按项目约定拆分和描述 story
|
||||
- `bmad-dev-story`：约束实现路径和代码风格
|
||||
- `bmad-code-review`：按项目标准做一致性校验
|
||||
@@ -32,7 +32,7 @@ sidebar:
|
||||
|
||||
| 场景 | 建议时机 | 目标 |
|
||||
|----------|----------------|---------|
|
||||
| **新项目（架构前）** | 在 `bmad-create-architecture` 前手动创建 | 先声明技术偏好，避免架构偏航 |
|
||||
| **新项目（架构前）** | 在 `bmad-architecture` 前手动创建 | 先声明技术偏好，避免架构偏航 |
|
||||
| **新项目（架构后）** | 通过 `bmad-generate-project-context` 生成并补充 | 把架构决策转成可执行规则 |
|
||||
| **既有项目** | 先生成，再人工校对 | 让智能体学习现有约定而非重造体系 |
|
||||
| **Quick Flow 场景** | 在 `bmad-quick-dev` 前或过程中维护 | 弥补跳过完整规划带来的上下文缺口 |
|
||||
|
||||
@@ -172,5 +172,4 @@ npx bmad-method install
|
||||
|
||||
## 后续步骤
|
||||
|
||||
- [文档分片指南](./shard-large-documents.md) - 了解如何管理超长文档
|
||||
- [命令参考](../reference/commands.md) - 查看可用命令和工作流入口
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: "如何为组织扩展 BMad"
|
||||
description: 五个自定义方案，无需 fork 即可重塑 BMad——涵盖智能体全局规则、工作流约定、外部发布、模板替换和花名册变更
|
||||
sidebar:
|
||||
order: 11
|
||||
order: 10
|
||||
---
|
||||
|
||||
BMad 的自定义机制让组织无需编辑已安装文件或 fork 技能就能重塑行为。本指南介绍五个方案，覆盖大部分企业级需求。
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: "压测一个想法"
|
||||
description: 用 bmad-forge-idea skill 在投入之前强化、验证或淘汰一个想法
|
||||
sidebar:
|
||||
order: 12
|
||||
order: 11
|
||||
---
|
||||
|
||||
用 `bmad-forge-idea` skill 把半成型的想法放到对抗式提问下。要么带着 earned conviction 活下来，要么廉价地死掉。
|
||||
|
||||
@@ -1,82 +0,0 @@
|
||||
---
|
||||
title: "文档分片指南"
|
||||
description: 将大型 Markdown 文件拆分为更小的组织化文件，以更好地管理上下文
|
||||
sidebar:
|
||||
order: 10
|
||||
---
|
||||
|
||||
当单个 Markdown 文档过大、影响模型读取时，可使用 `bmad-shard-doc` 工作流把文档拆成按章节组织的小文件，降低上下文压力。
|
||||
|
||||
:::caution[已弃用]
|
||||
这是兼容性方案，默认不推荐。随着工作流更新，以及主流模型/工具逐步支持子进程（subprocesses），很多场景将不再需要手动分片。
|
||||
:::
|
||||
|
||||
## 何时使用
|
||||
|
||||
- 你确认当前工具/模型在关键步骤无法一次读入完整文档
|
||||
- 文档体量已明显影响工作流稳定性或响应质量
|
||||
- 你需要保留原文结构，但希望按 `##` 章节拆分维护
|
||||
|
||||
## 什么是文档分片？
|
||||
|
||||
文档分片会按二级标题（`## Heading`）把大型 Markdown 文件拆成多个子文件，并生成一个 `index.md` 作为入口。
|
||||
|
||||
### 架构
|
||||
|
||||
```text
|
||||
分片前：
|
||||
_bmad-output/planning-artifacts/
|
||||
└── PRD.md（大型 50k token 文件）
|
||||
|
||||
分片后：
|
||||
_bmad-output/planning-artifacts/
|
||||
└── prd/
|
||||
├── index.md # 带有描述的目录
|
||||
├── overview.md # 第 1 节
|
||||
├── user-requirements.md # 第 2 节
|
||||
├── technical-requirements.md # 第 3 节
|
||||
└── ... # 其他章节
|
||||
```
|
||||
|
||||
## 步骤
|
||||
|
||||
### 1. 运行 `bmad-shard-doc` 工作流
|
||||
|
||||
```bash
|
||||
/bmad-shard-doc
|
||||
```
|
||||
|
||||
### 2. 按交互流程完成分片
|
||||
|
||||
```text
|
||||
智能体：你想分片哪个文档？
|
||||
用户：docs/PRD.md
|
||||
|
||||
智能体：默认目标位置：docs/prd/
|
||||
接受默认值？[y/n]
|
||||
用户：y
|
||||
|
||||
智能体：正在分片 PRD.md...
|
||||
✓ 已创建 12 个章节文件
|
||||
✓ 已生成 index.md
|
||||
✓ 完成！
|
||||
```
|
||||
|
||||
## 工作流发现机制
|
||||
|
||||
BMad 工作流使用**双重发现机制**：
|
||||
|
||||
1. **先查完整文档** - 查找 `document-name.md`
|
||||
2. **再查分片入口** - 查找 `document-name/index.md`
|
||||
3. **优先级规则** - 若两者并存，默认优先完整文档；若你要强制使用分片版本，请删除或重命名完整文档
|
||||
|
||||
## 你将获得
|
||||
|
||||
- 原始完整文档（可保留，但不建议与分片长期并存；并存时默认优先读取完整文档）
|
||||
- 分片目录（如 `document-name/index.md` + 各章节文件）
|
||||
- 对工作流透明的自动识别行为（无需额外配置）
|
||||
|
||||
## 后续步骤
|
||||
|
||||
- [如何自定义 BMad](./customize-bmad.md) - 了解高级配置与工作流定制边界
|
||||
- [如何升级到 v6](./upgrade-to-v6.md) - 在迁移过程中处理文档与目录结构变化
|
||||
@@ -46,7 +46,7 @@ sidebar:
|
||||
.claude/skills/
|
||||
├── bmad-help/
|
||||
│ └── SKILL.md
|
||||
├── bmad-create-prd/
|
||||
├── bmad-prd/
|
||||
│ └── SKILL.md
|
||||
├── bmad-agent-dev/
|
||||
│ └── SKILL.md
|
||||
@@ -85,8 +85,8 @@ skill 目录名就是调用名，例如 `bmad-agent-dev/` 对应 skill `bmad-age
|
||||
|
||||
| 示例 skill | 用途 |
|
||||
| --- | --- |
|
||||
| `bmad-create-prd` | 创建 PRD |
|
||||
| `bmad-create-architecture` | 创建架构方案 |
|
||||
| `bmad-prd` | 创建 PRD |
|
||||
| `bmad-architecture` | 创建架构方案 |
|
||||
| `bmad-create-epics-and-stories` | 拆分 epics/stories |
|
||||
| `bmad-dev-story` | 实现指定 story |
|
||||
| `bmad-code-review` | 代码评审 |
|
||||
@@ -104,7 +104,7 @@ skill 目录名就是调用名，例如 `bmad-agent-dev/` 对应 skill `bmad-age
|
||||
|
||||
## 命名规则
|
||||
|
||||
所有技能统一以 `bmad-` 开头，后接语义化名称（如 `bmad-agent-dev`、`bmad-create-prd`、`bmad-help`）。
|
||||
所有技能统一以 `bmad-` 开头，后接语义化名称（如 `bmad-agent-dev`、`bmad-prd`、`bmad-help`）。
|
||||
|
||||
## 故障排查
|
||||
|
||||
|
||||
+115
-142
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: "核心工具"
|
||||
description: 每个 BMad 安装默认可用的任务与 workflow 参考。
|
||||
description: 核心模块内置 skills 参考，以及独立思考类 skills 与 BMad Analysis 包。
|
||||
sidebar:
|
||||
order: 3
|
||||
---
|
||||
|
||||
核心工具是跨模块可复用的一组通用能力：不依赖特定业务项目，也不要求先进入某个智能体角色。只要安装了 BMad，你就可以直接调用它们。
|
||||
每个 BMad 安装都包含 **核心模块** —— 一小组跨项目、跨模块、跨阶段通用的 skills。本页覆盖这 5 个核心 skills，以及作为独立模块单独安装的 **独立思考类 skills**（brainstorming、forge idea、party mode）—— 最简单的安装方式是选择 **BMad Analysis** 包。
|
||||
|
||||
:::tip[快速入口]
|
||||
在 IDE 中直接输入工具 skill 名（例如 `bmad-help`）即可调用，无需先加载智能体。
|
||||
@@ -13,19 +13,27 @@ sidebar:
|
||||
|
||||
## 概览
|
||||
|
||||
| 工具 | 类型 | 主要用途 |
|
||||
| --- | --- | --- |
|
||||
| [`bmad-help`](#bmad-help) | Task | 基于项目上下文推荐下一步 |
|
||||
| [`bmad-brainstorming`](#bmad-brainstorming) | Workflow | 引导式头脑风暴与想法扩展 |
|
||||
| [`bmad-party-mode`](#bmad-party-mode) | Workflow | 多智能体协作讨论 |
|
||||
| [`bmad-spec`](#bmad-spec) | Workflow | Distill any intent input into a SPEC kernel and companions, the canonical contract for downstream work (translation pending) |
|
||||
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | Task | 通过多轮技法增强 LLM 输出 |
|
||||
| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | Task | 对抗式问题发现审查 |
|
||||
| [`bmad-review-edge-case-hunter`](#bmad-review-edge-case-hunter) | Task | 边界与分支路径穷举审查 |
|
||||
| [`bmad-editorial-review-prose`](#bmad-editorial-review-prose) | Task | 文案可读性与表达清晰度审查 |
|
||||
| [`bmad-editorial-review-structure`](#bmad-editorial-review-structure) | Task | 文档结构裁剪、合并与重组建议 |
|
||||
| [`bmad-shard-doc`](#bmad-shard-doc) | Task | 将大文档拆分为章节文件 |
|
||||
| [`bmad-index-docs`](#bmad-index-docs) | Task | 为目录生成/更新文档索引 |
|
||||
**核心模块（始终安装）：**
|
||||
|
||||
| 工具 | 主要用途 |
|
||||
| --- | --- |
|
||||
| [`bmad-help`](#bmad-help) | 基于项目上下文推荐下一步 |
|
||||
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | 通过多轮技法增强 LLM 输出 |
|
||||
| [`bmad-editorial-review`](#bmad-editorial-review) | 两阶段编辑审查 —— 先结构、后文字 |
|
||||
| [`bmad-review`](#bmad-review) | 多视角批判性审查 —— 对抗、边界条件与验证缺口 |
|
||||
| [`bmad-customize`](#bmad-customize) | 创建并验证 BMad 自定义覆盖 |
|
||||
|
||||
**独立思考类 skills（通过 [BMad Analysis 包](../../reference/standalone-skills.md) 或单独安装）：**
|
||||
|
||||
| 工具 | 主要用途 |
|
||||
| --- | --- |
|
||||
| [`bmad-brainstorming`](#bmad-brainstorming) | 引导式头脑风暴与想法扩展 |
|
||||
| [`bmad-forge-idea`](#bmad-forge-idea) | 压力测试一个想法，直到它站得住、被证实或低成本地淘汰 |
|
||||
| [`bmad-party-mode`](#bmad-party-mode) | 多智能体协作讨论 |
|
||||
|
||||
:::note[迁移与移除]
|
||||
`bmad-spec` 现随 BMM 模块作为第 2 阶段规划 workflow 发布 —— 见[工作流地图](./workflow-map.md)。`bmad-shard-doc` 与 `bmad-index-docs` 已移除。原 `bmad-editorial-review-prose`、`bmad-editorial-review-structure`、`bmad-review-adversarial-general`、`bmad-review-edge-case-hunter`、`bmad-review-verification-gap` 已合并进 `bmad-editorial-review` 与 `bmad-review`；旧 ID 仍可通过隐藏转发器解析，保持兼容。
|
||||
:::
|
||||
|
||||
## bmad-help
|
||||
|
||||
@@ -44,7 +52,81 @@ sidebar:
|
||||
**输入：** 可选自然语言问题（如 `bmad-help 我该先做 PRD 还是 architecture？`）
|
||||
**输出：** 带 skill 名称的下一步建议列表
|
||||
|
||||
## bmad-brainstorming
|
||||
## bmad-advanced-elicitation
|
||||
|
||||
**定位：** 对已有 LLM 输出做第二轮深挖与改写强化。
|
||||
|
||||
**适用场景：**
|
||||
- 结果“看起来对”，但深度不够
|
||||
- 想从多个思维框架交叉审视同一内容
|
||||
- 想按名字调用已知方法 —— 苏格拉底式、第一性原理、事前验尸、红队
|
||||
|
||||
**工作机制：**
|
||||
1. 默认针对会话中最近一次输出，也可指向其他内容
|
||||
2. 给出与内容匹配的候选技法短菜单
|
||||
3. 应用所选技法进行强化
|
||||
4. 交回改进版本，调用方流程从暂停处继续
|
||||
|
||||
**输入：** 待增强内容（默认最近输出），可选指定方法名
|
||||
**输出：** 增强后的内容版本
|
||||
|
||||
## bmad-editorial-review
|
||||
|
||||
**定位：** 两阶段编辑审查 —— 先审结构，再审文字；只改表达，不动观点。
|
||||
|
||||
**适用场景：**
|
||||
- 文档已成稿，想要收紧和打磨
|
||||
- 多个子流程拼出的文档需要结构上的连贯性
|
||||
- 想在保留可理解性的前提下缩减篇幅
|
||||
|
||||
**工作机制：**
|
||||
1. **结构阶段** —— 提出删减、合并、移动与压缩建议，检验文档形态是否服务于其目的
|
||||
2. **文字阶段** —— 以 Microsoft Writing Style Guide 为基线（提供的风格指南优先），修复影响理解的表达问题
|
||||
3. 默认两阶段依次执行；可只要求结构或文字单项审查
|
||||
4. 只提建议、不直接改写 —— 是否采纳由作者决定
|
||||
|
||||
**输入：** `content`（必填），`style_guide` / `reader_type` / `purpose` / `target_audience` / `length_target`（可选）
|
||||
**输出：** 修订建议表；提出结构性修改时附预计压缩幅度
|
||||
|
||||
## bmad-review
|
||||
|
||||
**定位：** 面向任意 diff、文档或产物的多视角批判性审查。各视角独立运行，统一输出。零发现是合法结果，绝不为“看起来彻底”而凑数。
|
||||
|
||||
**内置视角：**
|
||||
|
||||
| 视角 | 方法 |
|
||||
| --- | --- |
|
||||
| **对抗（Adversarial）** | 假设问题存在的怀疑式审查 —— 主动找缺失，而非只纠错 |
|
||||
| **边界条件（Edge case）** | 走遍每条分支路径与边界条件，只报告未处理的路径 |
|
||||
| **验证缺口（Verification gap）** | 找出可能回归且缺乏可靠验证兜底的行为变更 |
|
||||
|
||||
**工作机制：**
|
||||
1. 加载内容并识别类型 —— diff、文件、函数或文档
|
||||
2. 选择视角：你指定的，或所有适配内容的已启用视角
|
||||
3. 各视角独立运行 —— 平台支持时通过子代理并行
|
||||
4. 汇总为一个 findings 列表；视角间重叠是信号而非重复
|
||||
|
||||
**输入：** `content`（必填），`lenses`（可选，默认全量审查），`also_consider`（可选）
|
||||
**输出：** JSON findings 数组和/或按视角分组的 markdown 报告。可通过 skill 的 `customize.toml` 增加自定义视角，或调整/停用内置视角
|
||||
|
||||
## bmad-customize
|
||||
|
||||
**定位：** 无需手写 TOML，即可修改已安装 BMad 智能体或 workflow 的行为。
|
||||
|
||||
**工作机制：**
|
||||
1. 扫描已安装 BMad skills 的可自定义面
|
||||
2. 为你的变更选择合适的覆盖范围
|
||||
3. 在 `_bmad/custom/` 下写入覆盖文件
|
||||
4. 验证合并后的配置
|
||||
|
||||
**输入：** 用自然语言描述想要的自定义
|
||||
**输出：** `_bmad/custom/` 下的 TOML 覆盖文件。详见[如何自定义 BMad](../how-to/customize-bmad.md)
|
||||
|
||||
## 独立思考类 skills
|
||||
|
||||
以下三个 skills 不属于核心模块。每个都是独立的单 skill 模块，在安装器中默认隐藏，通过可见的 **BMad Analysis** 包安装，或在其他模块声明依赖时自动带入。详见 [Standalone Skills 与模块依赖](../../reference/standalone-skills.md)。
|
||||
|
||||
### bmad-brainstorming
|
||||
|
||||
**定位：** 用结构化创意技法快速扩展想法池。
|
||||
|
||||
@@ -57,12 +139,26 @@ sidebar:
|
||||
1. 建立主题会话
|
||||
2. 从方法库选择创意技法
|
||||
3. 逐轮引导产出并记录想法
|
||||
4. 生成可追溯的会话文档
|
||||
4. 每 10 个想法切换创意领域，防止聚集偏差
|
||||
|
||||
**输入：** 主题或问题陈述（可附上下文文件）
|
||||
**输出：** `brainstorming-session-{date}.md`
|
||||
**输出：** 自包含的 `brainstorm.html` 会话纪念页、可选的 `brainstorm-intent.md`（供下游 skills 使用）与 `.memlog.md` 会话记录
|
||||
|
||||
## bmad-party-mode
|
||||
### bmad-forge-idea
|
||||
|
||||
**定位：** 压力测试一个想法，直到它站得住、被证实或低成本地淘汰。
|
||||
|
||||
**工作机制：**
|
||||
1. 先确立目标，并据此调整提问方向
|
||||
2. 按依赖顺序一次一个问题，先摆出推荐答案供你反驳
|
||||
3. 每个分支引入两个角色声音 —— 一个来自已安装的角色阵容，一个由话题临时召唤
|
||||
4. 挑战模糊措辞，并用现有项目材料检验论断
|
||||
5. 以 Hardened（站住了）、Killed（淘汰）或 Clearer（更清晰）收尾，附可留存的报告
|
||||
|
||||
**输入：** 任何领域的想法 —— 功能、商业模式、研究假设、人生决定
|
||||
**输出：** 想法站住时的 `forged-idea.md` 提炼稿（可选），加上每次运行的 `forge-report.html`
|
||||
|
||||
### bmad-party-mode
|
||||
|
||||
**定位：** 让多个智能体围绕同一议题协作讨论。
|
||||
|
||||
@@ -80,129 +176,6 @@ sidebar:
|
||||
**输入：** 讨论主题（可指定希望参与的角色）
|
||||
**输出：** 多智能体实时对话过程
|
||||
|
||||
## bmad-advanced-elicitation
|
||||
|
||||
**定位：** 对已有 LLM 输出做第二轮深挖与改写强化。
|
||||
|
||||
**适用场景：**
|
||||
- 结果“看起来对”，但深度不够
|
||||
- 想从多个思维框架交叉审视同一内容
|
||||
- 在交付前提升论证质量与完整性
|
||||
|
||||
**工作机制：**
|
||||
1. 加载启发技法库
|
||||
2. 选择匹配内容的候选技法
|
||||
3. 交互式选择并应用技法
|
||||
4. 多轮迭代直到你确认收敛
|
||||
|
||||
**输入：** 待增强内容片段
|
||||
**输出：** 增强后的内容版本
|
||||
|
||||
## bmad-review-adversarial-general
|
||||
|
||||
**定位：** 假设问题存在，主动寻找遗漏与风险。
|
||||
|
||||
**适用场景：**
|
||||
- 文档/规格/实现即将交付前
|
||||
- 想补足“乐观审查”容易漏掉的问题
|
||||
- 需要对关键变更做压力测试
|
||||
|
||||
**工作机制：**
|
||||
1. 以怀疑视角检查内容
|
||||
2. 从完整性、正确性、质量三个维度找问题
|
||||
3. 强制关注“缺失内容”，而非仅纠错
|
||||
|
||||
**输入：** `content`（必填），`also_consider`（可选）
|
||||
**输出：** 结构化问题清单
|
||||
|
||||
## bmad-review-edge-case-hunter
|
||||
|
||||
**定位：** 穷举分支路径与边界条件，只报告未覆盖情况。
|
||||
|
||||
**适用场景：**
|
||||
- 审查核心逻辑的边界健壮性
|
||||
- 对 diff 做路径级覆盖检查
|
||||
- 与 adversarial review 形成互补
|
||||
|
||||
**工作机制：**
|
||||
1. 枚举所有分支路径
|
||||
2. 推导边界类别（missing default、off-by-one、竞态等）
|
||||
3. 检查每条路径是否已有防护
|
||||
4. 仅输出未处理路径
|
||||
|
||||
**输入：** `content`（必填），`also_consider`（可选）
|
||||
**输出：** JSON 发现列表（含触发条件与潜在后果）
|
||||
|
||||
## bmad-editorial-review-prose
|
||||
|
||||
**定位：** 聚焦表达清晰度的文案审查，不替你改写个人风格。
|
||||
|
||||
**适用场景：**
|
||||
- 内容可用，但读起来费劲
|
||||
- 需要针对特定读者提升可理解性
|
||||
- 想做“表达修复”而非“立场重写”
|
||||
|
||||
**工作机制：**
|
||||
1. 跳过 frontmatter 与代码块读取正文
|
||||
2. 标记影响理解的表达问题
|
||||
3. 去重同类问题并输出修订建议
|
||||
|
||||
**输入：** `content`（必填），`style_guide`（可选），`reader_type`（可选）
|
||||
**输出：** 三列表（原文 / 修改后 / 说明）
|
||||
|
||||
## bmad-editorial-review-structure
|
||||
|
||||
**定位：** 处理文档结构问题：裁剪、合并、重排、精简。
|
||||
|
||||
**适用场景：**
|
||||
- 文档是多来源拼接，结构不连贯
|
||||
- 想在不丢信息前提下降低篇幅
|
||||
- 重要信息被埋在低优先级段落
|
||||
|
||||
**工作机制：**
|
||||
1. 按结构模型分析文档组织
|
||||
2. 识别冗余、越界与信息埋没
|
||||
3. 输出优先级建议与压缩预估
|
||||
|
||||
**输入：** `content`（必填），`purpose`/`target_audience`/`reader_type`/`length_target`（可选）
|
||||
**输出：** 结构建议清单 + 预计缩减量
|
||||
|
||||
## bmad-shard-doc
|
||||
|
||||
**定位：** 把超大 Markdown 文档拆成可维护章节。
|
||||
|
||||
**适用场景：**
|
||||
- 单文件过大（常见 500+ 行）
|
||||
- 需要并行编辑或分段维护
|
||||
- 希望降低 LLM 读取成本
|
||||
|
||||
**工作机制：**
|
||||
1. 校验源文件
|
||||
2. 按 `##` 二级标题分片
|
||||
3. 生成 `index.md` 与编号章节
|
||||
4. 提示保留/归档/删除原文件
|
||||
|
||||
**输入：** 源文件路径（可选目标目录）
|
||||
**输出：** 分片目录（含 `index.md`）
|
||||
|
||||
## bmad-index-docs
|
||||
|
||||
**定位：** 为目录自动生成可导航文档索引。
|
||||
|
||||
**适用场景：**
|
||||
- 文档目录持续增长，需要统一入口
|
||||
- 想给 LLM 或新人快速提供全局视图
|
||||
- 需要保持索引与目录同步
|
||||
|
||||
**工作机制：**
|
||||
1. 扫描目录内非隐藏文件
|
||||
2. 读取文件并提炼用途
|
||||
3. 按类型/主题组织条目
|
||||
4. 生成描述简洁的 `index.md`
|
||||
|
||||
**输入：** 目标目录路径
|
||||
**输出：** 更新后的 `index.md`
|
||||
|
||||
## 相关参考
|
||||
|
||||
- [技能（Skills）参考](./commands.md)
|
||||
|
||||
@@ -31,7 +31,7 @@ BMad Method（BMM）通过分阶段 workflow 逐步构建上下文，让智能
|
||||
|
||||
| Workflow | 目的 | 产出 |
|
||||
| --- | --- | --- |
|
||||
| `bmad-create-prd` | 明确 FR/NFR 与范围边界 | `PRD.md` |
|
||||
| `bmad-prd` | 明确 FR/NFR 与范围边界 | `PRD.md` |
|
||||
| `bmad-ux` | 在 UX 复杂场景下补齐交互与体验方案 | `DESIGN.md`, `EXPERIENCE.md` |
|
||||
|
||||
## 阶段 3：解决方案设计（Solutioning）
|
||||
@@ -40,7 +40,7 @@ BMad Method（BMM）通过分阶段 workflow 逐步构建上下文，让智能
|
||||
|
||||
| Workflow | 目的 | 产出 |
|
||||
| --- | --- | --- |
|
||||
| `bmad-create-architecture` | 显式记录技术决策与架构边界 | `architecture.md`（含 ADR） |
|
||||
| `bmad-architecture` | 显式记录技术决策与架构边界 | `architecture.md`（含 ADR） |
|
||||
| `bmad-create-epics-and-stories` | 将需求拆分为可实施的 epics/stories | epics 文件与 story 条目 |
|
||||
| `bmad-check-implementation-readiness` | 实施前 gate 检查 | PASS / CONCERNS / FAIL 结论 |
|
||||
|
||||
|
||||
@@ -114,7 +114,7 @@ BMad-Help 将检测你已完成的内容，并准确推荐下一步该做什么
|
||||
:::
|
||||
|
||||
:::note[如何加载智能体和运行工作流]
|
||||
每个工作流都可以通过技能名直接调用（例如 `bmad-create-prd`）。你的 AI IDE 会识别 `bmad-*` 技能并执行，无需额外单独加载智能体。你也可以直接调用智能体技能进行通用对话（例如 PM 智能体用 `bmad-agent-pm`）。
|
||||
每个工作流都可以通过技能名直接调用（例如 `bmad-prd`）。你的 AI IDE 会识别 `bmad-*` 技能并执行，无需额外单独加载智能体。你也可以直接调用智能体技能进行通用对话（例如 PM 智能体用 `bmad-agent-pm`）。
|
||||
:::
|
||||
|
||||
:::caution[新对话]
|
||||
@@ -142,7 +142,7 @@ BMad-Help 将检测你已完成的内容，并准确推荐下一步该做什么
|
||||
|
||||
**对于 BMad Method 和 Enterprise 路径：**
|
||||
1. 在新对话中调用 **PM 智能体**（`bmad-agent-pm`）
|
||||
2. 运行 `bmad-create-prd` 工作流（`bmad-create-prd`）
|
||||
2. 运行 `bmad-prd` 工作流（`bmad-prd`）
|
||||
3. 输出：`PRD.md`
|
||||
|
||||
**对于 Quick Flow 路径：**
|
||||
@@ -156,7 +156,7 @@ BMad-Help 将检测你已完成的内容，并准确推荐下一步该做什么
|
||||
|
||||
**创建架构**
|
||||
1. 在新对话中调用 **Architect 智能体**（`bmad-agent-architect`）
|
||||
2. 运行 `bmad-create-architecture`（`bmad-create-architecture`）
|
||||
2. 运行 `bmad-architecture`（`bmad-architecture`）
|
||||
3. 输出：包含技术决策的架构文档
|
||||
|
||||
**创建史诗和故事**
|
||||
@@ -224,8 +224,8 @@ your-project/
|
||||
| 工作流 | 命令 | 智能体 | 目的 |
|
||||
| ----------------------------------- | --------------------------------------- | -------- | -------------------------------------------- |
|
||||
| **`bmad-help`** ⭐ | `bmad-help` | 任意 | **你的智能向导 —— 随时询问任何问题！** |
|
||||
| `bmad-create-prd` | `bmad-create-prd` | PM | 创建产品需求文档 |
|
||||
| `bmad-create-architecture` | `bmad-create-architecture` | Architect | 创建架构文档 |
|
||||
| `bmad-prd` | `bmad-prd` | PM | 创建产品需求文档 |
|
||||
| `bmad-architecture` | `bmad-architecture` | Architect | 创建架构文档 |
|
||||
| `bmad-generate-project-context` | `bmad-generate-project-context` | Analyst | 创建项目上下文文件 |
|
||||
| `bmad-create-epics-and-stories` | `bmad-create-epics-and-stories` | PM | 将 PRD 分解为史诗 |
|
||||
| `bmad-check-implementation-readiness` | `bmad-check-implementation-readiness` | Architect | 验证规划一致性 |
|
||||
|
||||
@@ -68,3 +68,14 @@ bmad-investigate
|
||||
# bmad-auto-setup: renamed to bmad-loop-setup as part of the bmad-auto ->
|
||||
# bmad-loop module rename (BMad Automator's replacement).
|
||||
bmad-auto-setup
|
||||
|
||||
# Removed skills (core streamline, post-v6.10.0)
|
||||
# bmad-index-docs, bmad-shard-doc: retired outright.
|
||||
bmad-index-docs
|
||||
bmad-shard-doc
|
||||
# Deprecated PRD shims removed; bmad-prd covers create/edit/validate.
|
||||
bmad-create-prd
|
||||
bmad-edit-prd
|
||||
bmad-validate-prd
|
||||
# Deprecated shim removed; bmad-architecture replaced it.
|
||||
bmad-create-architecture
|
||||
|
||||
@@ -53,7 +53,7 @@ run_folder_pattern = "brief-{project_name}-{date}"
|
||||
# findings before the user sees the draft. Encodes standards, not options.
|
||||
#
|
||||
# Examples:
|
||||
# "skill:bmad-editorial-review-prose"
|
||||
# "skill:bmad-editorial-review"
|
||||
# "file:{project-root}/_bmad/style-guides/company-voice.md"
|
||||
# "Convert all dates to ISO 8601 format."
|
||||
#
|
||||
@@ -64,9 +64,9 @@ run_folder_pattern = "brief-{project_name}-{date}"
|
||||
#
|
||||
# Override the array in team/user TOML to add additional standards. Append-only:
|
||||
# base entries cannot be removed or replaced (resolver has no removal mechanism).
|
||||
# The default entry runs both editorial passes in order: structure, then prose.
|
||||
doc_standards = [
|
||||
"skill:bmad-editorial-review-structure",
|
||||
"skill:bmad-editorial-review-prose",
|
||||
"skill:bmad-editorial-review",
|
||||
]
|
||||
|
||||
# External-source registry. Natural-language directives describing knowledge
|
||||
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
name: bmad-create-prd
|
||||
description: 'DEPRECATED — consolidated into bmad-prd create intent - this skill will be removed in v7 in favor of `bmad-prd`.'
|
||||
---
|
||||
|
||||
# DEPRECATED — forwards to bmad-prd (create intent)
|
||||
|
||||
This skill was consolidated into `bmad-prd`. It is retained as a thin compatibility shim so existing invocations by name and `_bmad/custom/bmad-create-prd.toml` override files keep working. New work should invoke `bmad-prd` directly — it detects create / update / validate intent from the conversation.
|
||||
|
||||
## On Activation
|
||||
|
||||
1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-create-prd.toml` and `bmad-create-prd.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
|
||||
|
||||
2. Load `{project-root}/_bmad/bmm/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
|
||||
|
||||
3. Emit a deprecation notice to the user in `{communication_language}`:
|
||||
|
||||
> Notice: `bmad-create-prd` is deprecated and will be removed in a future release. It now forwards to `bmad-prd` with create intent. To silence this notice and access the full new customization surface (`prd_template`, `validation_checklist`, `doc_standards`, `external_sources`, `external_handoffs`, `output_dir`, `output_folder_name`), migrate `_bmad/custom/bmad-create-prd.toml` to `_bmad/custom/bmad-prd.toml` and invoke `bmad-prd` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_bmad/custom/bmad-prd.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
|
||||
|
||||
4. Invoke `bmad-prd` with the following context. Pass these as the activating context so `bmad-prd` honors them instead of resolving its own customization from scratch:
|
||||
|
||||
- **Intent:** `create` — skip `bmad-prd`'s usual intent detection step.
|
||||
- **Pre-resolved legacy customization** — use these in place of resolving from `bmad-prd`'s own `customize.toml` for the four legacy fields. For everything else (`prd_template`, `validation_checklist`, `validation_report_template`, `doc_standards`, `output_dir`, `output_folder_name`, `external_sources`, `external_handoffs`), use `bmad-prd`'s own defaults and overrides as normal:
|
||||
- `activation_steps_prepend` = the resolved value from step 1
|
||||
- `activation_steps_append` = the resolved value from step 1
|
||||
- `persistent_facts` = the resolved value from step 1
|
||||
- `on_complete` = the resolved value from step 1
|
||||
- **Original user input:** forward whatever the user said when invoking this skill verbatim.
|
||||
|
||||
`bmad-prd` takes the workflow from here. Do not execute any further steps in this shim.
|
||||
@@ -1,41 +0,0 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-create-prd. Mirrors the
|
||||
# agent customization shape under the [workflow] namespace.
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins • arrays (persistent_facts, activation_steps_*): append
|
||||
# arrays-of-tables with `code`/`id`: replace matching items, append new ones.
|
||||
|
||||
# Steps to run before the standard activation (config load, greet).
|
||||
# Overrides append. Use for pre-flight loads, compliance checks, etc.
|
||||
|
||||
activation_steps_prepend = []
|
||||
|
||||
# Steps to run after greet but before the workflow begins.
|
||||
# Overrides append. Use for context-heavy setup that should happen
|
||||
# once the user has been acknowledged.
|
||||
|
||||
activation_steps_append = []
|
||||
|
||||
# Persistent facts the workflow keeps in mind for the whole run
|
||||
# (standards, compliance constraints, stylistic guardrails).
|
||||
# Distinct from the runtime memory sidecar — these are static context
|
||||
# loaded on activation. Overrides append.
|
||||
#
|
||||
# Each entry is either:
|
||||
# - a literal sentence, e.g. "All PRDs must include a regulatory-risk section."
|
||||
# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
|
||||
# (glob patterns are supported; the file's contents are loaded and treated as facts).
|
||||
|
||||
persistent_facts = [
|
||||
"file:{project-root}/**/project-context.md",
|
||||
]
|
||||
|
||||
# Scalar: executed when the workflow reaches Step 12 (Workflow Completion),
|
||||
# after the PRD is finalized and workflow status is updated. Override wins.
|
||||
# Leave empty for no custom post-completion behavior.
|
||||
|
||||
on_complete = ""
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
name: bmad-edit-prd
|
||||
description: 'DEPRECATED — consolidated into bmad-prd update intent - this skill will be removed in v7 in favor of `bmad-prd`.'
|
||||
---
|
||||
|
||||
# DEPRECATED — forwards to bmad-prd (update intent)
|
||||
|
||||
This skill was consolidated into `bmad-prd`. It is retained as a thin compatibility shim so existing invocations by name and `_bmad/custom/bmad-edit-prd.toml` override files keep working. New work should invoke `bmad-prd` directly — it detects create / update / validate intent from the conversation.
|
||||
|
||||
## On Activation
|
||||
|
||||
1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-edit-prd.toml` and `bmad-edit-prd.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
|
||||
|
||||
2. Load `{project-root}/_bmad/bmm/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
|
||||
|
||||
3. Emit a deprecation notice to the user in `{communication_language}`:
|
||||
|
||||
> Notice: `bmad-edit-prd` is deprecated and will be removed in a future release. It now forwards to `bmad-prd` with update intent. To silence this notice and access the full new customization surface (`prd_template`, `validation_checklist`, `doc_standards`, `external_sources`, `external_handoffs`, `output_dir`, `output_folder_name`), migrate `_bmad/custom/bmad-edit-prd.toml` to `_bmad/custom/bmad-prd.toml` and invoke `bmad-prd` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_bmad/custom/bmad-prd.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
|
||||
|
||||
4. Invoke `bmad-prd` with the following context. Pass these as the activating context so `bmad-prd` honors them instead of resolving its own customization from scratch:
|
||||
|
||||
- **Intent:** `update` — skip `bmad-prd`'s usual intent detection step.
|
||||
- **Pre-resolved legacy customization** — use these in place of resolving from `bmad-prd`'s own `customize.toml` for the four legacy fields. For everything else (`prd_template`, `validation_checklist`, `validation_report_template`, `doc_standards`, `output_dir`, `output_folder_name`, `external_sources`, `external_handoffs`), use `bmad-prd`'s own defaults and overrides as normal:
|
||||
- `activation_steps_prepend` = the resolved value from step 1
|
||||
- `activation_steps_append` = the resolved value from step 1
|
||||
- `persistent_facts` = the resolved value from step 1
|
||||
- `on_complete` = the resolved value from step 1
|
||||
- **Original user input:** forward whatever the user said when invoking this skill verbatim (the target PRD path, the change signal, etc.).
|
||||
|
||||
`bmad-prd` takes the workflow from here. Do not execute any further steps in this shim.
|
||||
@@ -1,42 +0,0 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-edit-prd. Mirrors the
|
||||
# agent customization shape under the [workflow] namespace.
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins • arrays (persistent_facts, activation_steps_*): append
|
||||
# arrays-of-tables with `code`/`id`: replace matching items, append new ones.
|
||||
|
||||
# Steps to run before the standard activation (config load, greet).
|
||||
# Overrides append. Use for pre-flight loads, compliance checks, etc.
|
||||
|
||||
activation_steps_prepend = []
|
||||
|
||||
# Steps to run after greet but before the workflow begins.
|
||||
# Overrides append. Use for context-heavy setup that should happen
|
||||
# once the user has been acknowledged.
|
||||
|
||||
activation_steps_append = []
|
||||
|
||||
# Persistent facts the workflow keeps in mind for the whole run
|
||||
# (standards, compliance constraints, stylistic guardrails).
|
||||
# Distinct from the runtime memory sidecar — these are static context
|
||||
# loaded on activation. Overrides append.
|
||||
#
|
||||
# Each entry is either:
|
||||
# - a literal sentence, e.g. "All PRDs must include a regulatory-risk section."
|
||||
# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
|
||||
# (glob patterns are supported; the file's contents are loaded and treated as facts).
|
||||
|
||||
persistent_facts = [
|
||||
"file:{project-root}/**/project-context.md",
|
||||
]
|
||||
|
||||
# Scalar: executed when the workflow reaches Step E-4 (Complete & Validate) and the
|
||||
# user exits via [S] Summary or [X] Exit — not on [V] Validate (which chains to
|
||||
# bmad-validate-prd) or [E] Edit More (which loops back). Override wins.
|
||||
# Leave empty for no custom post-completion behavior.
|
||||
|
||||
on_complete = ""
|
||||
@@ -71,7 +71,7 @@ run_folder_pattern = "prd-{project_name}-{date}"
|
||||
# findings before the user sees the draft. Encodes standards, not options.
|
||||
#
|
||||
# Examples:
|
||||
# "skill:bmad-editorial-review-prose"
|
||||
# "skill:bmad-editorial-review"
|
||||
# "file:{project-root}/_bmad/style-guides/company-voice.md"
|
||||
# "Convert all dates to ISO 8601 format."
|
||||
#
|
||||
@@ -82,9 +82,9 @@ run_folder_pattern = "prd-{project_name}-{date}"
|
||||
#
|
||||
# Override the array in team/user TOML to add additional standards. Append-only:
|
||||
# base entries cannot be removed or replaced (resolver has no removal mechanism).
|
||||
# The default entry runs both editorial passes in order: structure, then prose.
|
||||
doc_standards = [
|
||||
"skill:bmad-editorial-review-structure",
|
||||
"skill:bmad-editorial-review-prose",
|
||||
"skill:bmad-editorial-review",
|
||||
]
|
||||
|
||||
# External-source registry. Natural-language directives describing knowledge
|
||||
|
||||
+1
-1
@@ -20,7 +20,7 @@ Multiple skills may call to update the same spec over time.
|
||||
|
||||
1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. On failure, read `{skill-root}/customize.toml` directly.
|
||||
2. Run `{workflow.activation_steps_prepend}`. Treat `{workflow.persistent_facts}` as foundational context (`file:` entries are loaded).
|
||||
3. Load `{project-root}/_bmad/core/config.yaml` (and `config.user.yaml` if present), root level and `bmm` section. Resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`.
|
||||
3. Resolve config: `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root}` (merges `_bmad/config.toml`, `_bmad/config.user.toml`, and the `_bmad/custom/` overrides). From the merged JSON resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{project_name}` (under `core`), `{planning_artifacts}` (under `modules.bmm`), and `{date}`.
|
||||
4. Detect mode. **Headless** when any of: no TTY, programmatic caller (another skill or non-interactive runner), or the first message pre-supplies all inputs and asks for an artifact path back. **Interactive** otherwise. In interactive mode, greet by `{user_name}` in `{communication_language}`, stay in that language, and mention that `bmad-party-mode` and `bmad-advanced-elicitation` are available for deeper exploration on any field.
|
||||
|
||||
Run `{workflow.activation_steps_append}`.
|
||||
@@ -78,9 +78,9 @@ creative_tools = [
|
||||
# Polish passes applied to DESIGN.md and EXPERIENCE.md at finalize.
|
||||
# Entries: `skill:NAME`, `file:PATH`, or plain text directive.
|
||||
# Suggested order: structural → content/voice → prose mechanics.
|
||||
# The default entry runs both editorial passes in order: structure, then prose.
|
||||
doc_standards = [
|
||||
"skill:bmad-editorial-review-structure",
|
||||
"skill:bmad-editorial-review-prose",
|
||||
"skill:bmad-editorial-review",
|
||||
]
|
||||
|
||||
# Information retrieval registry. Consulted on demand when the conversation
|
||||
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
name: bmad-validate-prd
|
||||
description: 'DEPRECATED — consolidated into bmad-prd validate intent - this skill will be removed in v7 in favor of `bmad-prd`.'
|
||||
---
|
||||
|
||||
# DEPRECATED — forwards to bmad-prd (validate intent)
|
||||
|
||||
This skill was consolidated into `bmad-prd`. It is retained as a thin compatibility shim so existing invocations by name and `_bmad/custom/bmad-validate-prd.toml` override files keep working. New work should invoke `bmad-prd` directly — it detects create / update / validate intent from the conversation.
|
||||
|
||||
## On Activation
|
||||
|
||||
1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-validate-prd.toml` and `bmad-validate-prd.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
|
||||
|
||||
2. Load `{project-root}/_bmad/bmm/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
|
||||
|
||||
3. Emit a deprecation notice to the user in `{communication_language}`:
|
||||
|
||||
> Notice: `bmad-validate-prd` is deprecated and will be removed in a future release. It now forwards to `bmad-prd` with validate intent. To silence this notice and access the full new customization surface (`prd_template`, `validation_checklist`, `doc_standards`, `external_sources`, `external_handoffs`, `output_dir`, `output_folder_name`), migrate `_bmad/custom/bmad-validate-prd.toml` to `_bmad/custom/bmad-prd.toml` and invoke `bmad-prd` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_bmad/custom/bmad-prd.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
|
||||
|
||||
4. Invoke `bmad-prd` with the following context. Pass these as the activating context so `bmad-prd` honors them instead of resolving its own customization from scratch:
|
||||
|
||||
- **Intent:** `validate` — skip `bmad-prd`'s usual intent detection step.
|
||||
- **Pre-resolved legacy customization** — use these in place of resolving from `bmad-prd`'s own `customize.toml` for the four legacy fields. For everything else (`prd_template`, `validation_checklist`, `validation_report_template`, `doc_standards`, `output_dir`, `output_folder_name`, `external_sources`, `external_handoffs`), use `bmad-prd`'s own defaults and overrides as normal:
|
||||
- `activation_steps_prepend` = the resolved value from step 1
|
||||
- `activation_steps_append` = the resolved value from step 1
|
||||
- `persistent_facts` = the resolved value from step 1
|
||||
- `on_complete` = the resolved value from step 1
|
||||
- **Original user input:** forward whatever the user said when invoking this skill verbatim (the target PRD path, etc.).
|
||||
|
||||
`bmad-prd` takes the workflow from here. Do not execute any further steps in this shim.
|
||||
@@ -1,42 +0,0 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-validate-prd. Mirrors the
|
||||
# agent customization shape under the [workflow] namespace.
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins • arrays (persistent_facts, activation_steps_*): append
|
||||
# arrays-of-tables with `code`/`id`: replace matching items, append new ones.
|
||||
|
||||
# Steps to run before the standard activation (config load, greet).
|
||||
# Overrides append. Use for pre-flight loads, compliance checks, etc.
|
||||
|
||||
activation_steps_prepend = []
|
||||
|
||||
# Steps to run after greet but before the workflow begins.
|
||||
# Overrides append. Use for context-heavy setup that should happen
|
||||
# once the user has been acknowledged.
|
||||
|
||||
activation_steps_append = []
|
||||
|
||||
# Persistent facts the workflow keeps in mind for the whole run
|
||||
# (standards, compliance constraints, stylistic guardrails).
|
||||
# Distinct from the runtime memory sidecar — these are static context
|
||||
# loaded on activation. Overrides append.
|
||||
#
|
||||
# Each entry is either:
|
||||
# - a literal sentence, e.g. "All PRDs must include a regulatory-risk section."
|
||||
# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
|
||||
# (glob patterns are supported; the file's contents are loaded and treated as facts).
|
||||
|
||||
persistent_facts = [
|
||||
"file:{project-root}/**/project-context.md",
|
||||
]
|
||||
|
||||
# Scalar: executed when the workflow reaches Step 13 (Validation Report Complete) and
|
||||
# the user exits via [X] Exit — not on [E] Use Edit Workflow (which chains to
|
||||
# bmad-edit-prd), [R] Review (which loops within), or [F] Fix (which loops within).
|
||||
# Override wins. Leave empty for no custom post-completion behavior.
|
||||
|
||||
on_complete = ""
|
||||
@@ -48,10 +48,10 @@ Writes go through the shared script (don't read the file back except on resume):
|
||||
|
||||
## On Activation
|
||||
|
||||
**Forwarded activation:** if a caller (e.g. the `bmad-create-architecture` shim) invoked you with a stated intent and pre-resolved customization fields, honor them verbatim — skip your own intent inference, use the supplied values for those named fields, and resolve only the remaining fields from your own `customize.toml`.
|
||||
**Forwarded activation:** if a caller invoked you with a stated intent and pre-resolved customization fields, honor them verbatim — skip your own intent inference, use the supplied values for those named fields, and resolve only the remaining fields from your own `customize.toml`.
|
||||
|
||||
1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow` (on failure read `{skill-root}/customize.toml`, use defaults). Run `{workflow.activation_steps_prepend}`, then `{workflow.activation_steps_append}`. Hold `{workflow.persistent_facts}` as standing context — the default loads `project-context.md`, load-bearing for brownfield — and consult `{workflow.external_sources}` on demand.
|
||||
2. Load `{project-root}/_bmad/bmm/config.yaml` (+ `config.user.yaml`) for `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`; missing keys take neutral defaults, never block.
|
||||
2. Resolve config: `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root}` (merges `_bmad/config.toml`, `_bmad/config.user.toml`, and the `_bmad/custom/` overrides). From the merged JSON resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{project_name}` (under `core`), `{planning_artifacts}` (under `modules.bmm`), and `{date}`; missing keys take neutral defaults, never block.
|
||||
3. Headless (no interactive user) → follow `references/headless.md` for the whole run. Otherwise greet `{user_name}` in `{communication_language}`. Detect the intent from the conversation and input — **create** (the default), **update** an existing spine, or **validate** one (see those sections). If the real ask is requirements / UX / a capability contract / epic breakdown / an agent, invoke the `bmad-prd`, `bmad-ux`, `bmad-spec`, `bmad-create-epics-and-stories`, or `bmad-workflow-builder` (if the BMad Builder module is installed) skill instead.
|
||||
4. If a run folder for this target already exists under `{workflow.spine_output_path}`, offer to resume from its memlog rather than restart.
|
||||
5. Interactive create: offer the working mode in `{communication_language}` — **Coaching path** (default) or **Fast path** (see *How you work*) — before any drafting; default to Coaching unless the user asks for speed.
|
||||
|
||||
@@ -59,9 +59,9 @@ run_folder_pattern = "architecture-{project_name}-{date}"
|
||||
# short, structured outputs, which are terse and carry decisions in AD-n blocks and diagrams by
|
||||
# design. Each entry is a `skill:`, `file:`, or plain-text directive applied before the user sees
|
||||
# the polished draft. Suggested order: structural passes first, prose mechanics last. Append-only.
|
||||
# The default entry runs both editorial passes in order: structure, then prose.
|
||||
doc_standards = [
|
||||
"skill:bmad-editorial-review-structure",
|
||||
"skill:bmad-editorial-review-prose",
|
||||
"skill:bmad-editorial-review",
|
||||
]
|
||||
|
||||
# External-source registry. Natural-language directives describing knowledge bases, MCP tools, or
|
||||
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
name: bmad-create-architecture
|
||||
description: 'DEPRECATED — consolidated into bmad-architecture create intent - this skill will be removed in v7 in favor of `bmad-architecture`.'
|
||||
---
|
||||
|
||||
# DEPRECATED — forwards to bmad-architecture (create intent)
|
||||
|
||||
This skill was consolidated into `bmad-architecture`. It is retained as a thin compatibility shim so existing invocations by name and `_bmad/custom/bmad-create-architecture.toml` override files keep working. New work should invoke `bmad-architecture` directly — it detects create / update / validate intent from the conversation.
|
||||
|
||||
## On Activation
|
||||
|
||||
1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-create-architecture.toml` and `bmad-create-architecture.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
|
||||
|
||||
2. Load `{project-root}/_bmad/bmm/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
|
||||
|
||||
3. Emit a deprecation notice to the user in `{communication_language}`:
|
||||
|
||||
> Notice: `bmad-create-architecture` is deprecated and will be removed in a future release. It now forwards to `bmad-architecture` with create intent. To silence this notice and access the full new customization surface (`spine_template`, `spine_output_path`, `run_folder_pattern`, `doc_standards`, `external_sources`, `external_handoffs`, `finalize_reviewers`), migrate `_bmad/custom/bmad-create-architecture.toml` to `_bmad/custom/bmad-architecture.toml` and invoke `bmad-architecture` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_bmad/custom/bmad-architecture.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
|
||||
|
||||
4. Invoke `bmad-architecture` with the following context. Pass these as the activating context so `bmad-architecture` honors them instead of resolving its own customization from scratch:
|
||||
|
||||
- **Intent:** `create` — skip `bmad-architecture`'s usual intent detection step.
|
||||
- **Pre-resolved legacy customization** — use these in place of resolving from `bmad-architecture`'s own `customize.toml` for the four legacy fields. For everything else (`spine_template`, `spine_output_path`, `run_folder_pattern`, `doc_standards`, `external_sources`, `external_handoffs`, `finalize_reviewers`), use `bmad-architecture`'s own defaults and overrides as normal:
|
||||
- `activation_steps_prepend` = the resolved value from step 1
|
||||
- `activation_steps_append` = the resolved value from step 1
|
||||
- `persistent_facts` = the resolved value from step 1
|
||||
- `on_complete` = the resolved value from step 1
|
||||
- **Original user input:** forward whatever the user said when invoking this skill verbatim.
|
||||
|
||||
`bmad-architecture` takes the workflow from here. Do not execute any further steps in this shim.
|
||||
@@ -1,41 +0,0 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-create-architecture. Mirrors the
|
||||
# agent customization shape under the [workflow] namespace.
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins • arrays (persistent_facts, activation_steps_*): append
|
||||
# arrays-of-tables with `code`/`id`: replace matching items, append new ones.
|
||||
|
||||
# Steps to run before the standard activation (config load, greet).
|
||||
# Overrides append. Use for pre-flight loads, compliance checks, etc.
|
||||
|
||||
activation_steps_prepend = []
|
||||
|
||||
# Steps to run after greet but before the workflow begins.
|
||||
# Overrides append. Use for context-heavy setup that should happen
|
||||
# once the user has been acknowledged.
|
||||
|
||||
activation_steps_append = []
|
||||
|
||||
# Persistent facts the workflow keeps in mind for the whole run
|
||||
# (standards, compliance constraints, stylistic guardrails).
|
||||
# Distinct from the runtime memory sidecar — these are static context
|
||||
# loaded on activation. Overrides append.
|
||||
#
|
||||
# Each entry is either:
|
||||
# - a literal sentence, e.g. "Our org is AWS-only -- do not propose GCP or Azure."
|
||||
# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
|
||||
# (glob patterns are supported; the file's contents are loaded and treated as facts).
|
||||
|
||||
persistent_facts = [
|
||||
"file:{project-root}/**/project-context.md",
|
||||
]
|
||||
|
||||
# Scalar: executed when the workflow reaches Step 8 (Architecture Completion & Handoff),
|
||||
# after the architecture document frontmatter is updated and next-steps guidance is given.
|
||||
# Override wins. Leave empty for no custom post-completion behavior.
|
||||
|
||||
on_complete = ""
|
||||
@@ -52,7 +52,7 @@ name = "Blind Hunter"
|
||||
instruction = """
|
||||
Launch a subagent with no prior conversation context, with this prompt:
|
||||
|
||||
> Invoke the `bmad-review-adversarial-general` skill on this diff:
|
||||
> Invoke the `bmad-review` skill with only the `adversarial` lens on this diff:
|
||||
>
|
||||
> {diff_output}
|
||||
"""
|
||||
@@ -63,7 +63,7 @@ name = "Edge Case Hunter"
|
||||
instruction = """
|
||||
Launch a subagent with no prior conversation context, with this prompt:
|
||||
|
||||
> Invoke the `bmad-review-edge-case-hunter` skill on this diff:
|
||||
> Invoke the `bmad-review` skill with only the `edge-case` lens on this diff:
|
||||
>
|
||||
> {diff_output}
|
||||
"""
|
||||
@@ -74,7 +74,7 @@ name = "Verification Gap Reviewer"
|
||||
instruction = """
|
||||
Launch a subagent with no prior conversation context, with this prompt:
|
||||
|
||||
> Invoke the `bmad-review-verification-gap` skill on this diff:
|
||||
> Invoke the `bmad-review` skill with only the `verification-gap` lens on this diff:
|
||||
>
|
||||
> {diff_output}
|
||||
"""
|
||||
|
||||
@@ -63,7 +63,7 @@ name = "Blind Hunter"
|
||||
instruction = """
|
||||
Launch a subagent with no prior conversation context, with this prompt:
|
||||
|
||||
> Invoke the `bmad-review-adversarial-general` skill on this diff:
|
||||
> Invoke the `bmad-review` skill with only the `adversarial` lens on this diff:
|
||||
>
|
||||
> {diff_output}
|
||||
"""
|
||||
@@ -74,7 +74,7 @@ name = "Edge Case Hunter"
|
||||
instruction = """
|
||||
Launch a subagent with no prior conversation context, with this prompt:
|
||||
|
||||
> Invoke the `bmad-review-edge-case-hunter` skill on this diff:
|
||||
> Invoke the `bmad-review` skill with only the `edge-case` lens on this diff:
|
||||
>
|
||||
> {diff_output}
|
||||
"""
|
||||
@@ -85,7 +85,7 @@ name = "Verification Gap Reviewer"
|
||||
instruction = """
|
||||
Launch a subagent with no prior conversation context, with this prompt:
|
||||
|
||||
> Invoke the `bmad-review-verification-gap` skill on this diff:
|
||||
> Invoke the `bmad-review` skill with only the `verification-gap` lens on this diff:
|
||||
>
|
||||
> {diff_output}
|
||||
"""
|
||||
|
||||
@@ -44,7 +44,7 @@ name = "Blind Hunter"
|
||||
instruction = """
|
||||
Launch a subagent with no prior conversation context, with this prompt:
|
||||
|
||||
> Invoke the `bmad-review-adversarial-general` skill on this diff:
|
||||
> Invoke the `bmad-review` skill with only the `adversarial` lens on this diff:
|
||||
>
|
||||
> {diff_output}
|
||||
"""
|
||||
@@ -55,7 +55,7 @@ name = "Edge Case Hunter"
|
||||
instruction = """
|
||||
Launch a subagent with no prior conversation context, with this prompt:
|
||||
|
||||
> Invoke the `bmad-review-edge-case-hunter` skill on this diff:
|
||||
> Invoke the `bmad-review` skill with only the `edge-case` lens on this diff:
|
||||
>
|
||||
> {diff_output}
|
||||
"""
|
||||
@@ -66,7 +66,7 @@ name = "Verification Gap Reviewer"
|
||||
instruction = """
|
||||
Launch a subagent with no prior conversation context, with this prompt:
|
||||
|
||||
> Invoke the `bmad-review-verification-gap` skill on this diff:
|
||||
> Invoke the `bmad-review` skill with only the `verification-gap` lens on this diff:
|
||||
>
|
||||
> {diff_output}
|
||||
"""
|
||||
@@ -79,5 +79,5 @@ name = "Blind Hunter"
|
||||
instruction = """
|
||||
Launch a subagent with no prior conversation context, with this prompt:
|
||||
|
||||
> Invoke the `bmad-review-adversarial-general` skill on the changed files.
|
||||
> Invoke the `bmad-review` skill with only the `adversarial` lens on the changed files.
|
||||
"""
|
||||
|
||||
@@ -3,13 +3,14 @@ BMad Method,_meta,,,,,,,,,false,https://docs.bmad-method.org/llms.txt,
|
||||
BMad Method,bmad-document-project,Document Project,DP,Analyze an existing project to produce useful documentation.,,,anytime,,,false,project-knowledge,*
|
||||
BMad Method,bmad-generate-project-context,Generate Project Context,GPC,Scan existing codebase to generate a lean LLM-optimized project-context.md. Essential for brownfield projects.,,,anytime,,,false,output_folder,project context
|
||||
BMad Method,bmad-quick-dev,Quick Dev,QQ,Unified intent-in code-out workflow: clarify plan implement review and present.,,,anytime,,,false,implementation_artifacts,spec and project implementation
|
||||
BMad Method,bmad-spec,Spec,SPC,"Use to distill any intent input (brief, PRD, transcript, brain dump, design folder, mixed multi-source) into a succinct, no-fluff SPEC.md contract + companions that downstream work derives from. Locks the WHAT before the HOW. Works for software, game design, research, editorial, policy, business, anything intent-bearing. Validation mode also available.",,[path],anytime,,,false,{output_folder}/specs/spec-{slug},SPEC.md + companion files
|
||||
BMad Method,bmad-correct-course,Correct Course,CC,Navigate significant changes. May recommend start over update PRD redo architecture sprint planning or correct epics and stories.,,,anytime,,,false,planning_artifacts,change proposal
|
||||
BMad Method,bmad-agent-tech-writer,Write Document,WD,"Describe in detail what you want, and the agent will follow documentation best practices. Multi-turn conversation with subprocess for research/review.",write,,anytime,,,false,project-knowledge,document
|
||||
BMad Method,bmad-agent-tech-writer,Update Standards,US,Update agent memory documentation-standards.md with your specific preferences if you discover missing document conventions.,update-standards,,anytime,,,false,_bmad/_memory/tech-writer-sidecar,standards
|
||||
BMad Method,bmad-agent-tech-writer,Mermaid Generate,MG,Create a Mermaid diagram based on user description. Will suggest diagram types if not specified.,mermaid,,anytime,,,false,planning_artifacts,mermaid diagram
|
||||
BMad Method,bmad-agent-tech-writer,Validate Document,VD,Review the specified document against documentation standards and best practices. Returns specific actionable improvement suggestions organized by priority.,validate,[path],anytime,,,false,planning_artifacts,validation report
|
||||
BMad Method,bmad-agent-tech-writer,Explain Concept,EC,Create clear technical explanations with examples and diagrams for complex concepts.,explain,[topic],anytime,,,false,project_knowledge,explanation
|
||||
BMad Method,bmad-brainstorming,Brainstorm Project,BP,Expert guided facilitation through a single or multiple techniques.,,,1-analysis,,,false,planning_artifacts,brainstorming session
|
||||
BMad Method,bmad-brainstorming,Brainstorm Project,BP,Expert guided facilitation through a single or multiple techniques.,,,1-analysis,,,false,{output_folder}/brainstorming,brainstorming session
|
||||
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
|
||||
|
||||
|
@@ -3,6 +3,12 @@ name: "BMad Method"
|
||||
description: "Full-lifecycle AI agile development: analysis, planning, architecture, implementation"
|
||||
default_selected: true # This module will be selected by default for new installations
|
||||
|
||||
# Standalone skill modules installed with bmm — bmm skills offer these at checkpoints.
|
||||
dependencies:
|
||||
- bmad-brainstorming
|
||||
- bmad-party-mode
|
||||
- bmad-forge-idea
|
||||
|
||||
# Variables from Core Config inserted:
|
||||
## user_name
|
||||
## project_name
|
||||
|
||||
@@ -5,72 +5,39 @@ description: 'Push the LLM to reconsider, refine, and improve its recent output.
|
||||
|
||||
# Advanced Elicitation
|
||||
|
||||
**Goal:** Push the LLM to reconsider, refine, and improve its recent output.
|
||||
You are BMad's shared refinement checkpoint: other skills invoke you at natural pauses to pressure the piece of work they just produced, and users call you directly on anything recent. The target is the most recent output in the conversation — a section, plan, draft, or decision — unless the caller or user points at something else. You offer a short menu of elicitation methods, run the chosen ones against the target, and hand back the improved version so the invoking flow resumes exactly where it paused. Work in the surrounding session's communication language.
|
||||
|
||||
---
|
||||
## Conventions
|
||||
|
||||
## CRITICAL LLM INSTRUCTIONS
|
||||
- Bare paths (e.g. `assets/methods.csv`) resolve from `{skill-root}` (where `customize.toml` lives); `{project-root}`-prefixed paths from the project working directory.
|
||||
- `{workflow.<name>}` resolves to fields in the merged `customize.toml` `[workflow]` table.
|
||||
|
||||
- **MANDATORY:** Execute ALL steps in the flow section IN EXACT ORDER
|
||||
- DO NOT skip steps or change the sequence
|
||||
- HALT immediately when halt-conditions are met
|
||||
- Each action within a step is a REQUIRED action to complete that step
|
||||
- Sections outside flow (validation, output, critical-context) provide essential context - review and apply throughout execution
|
||||
- **YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the `communication_language`**
|
||||
## On Activation
|
||||
|
||||
---
|
||||
1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. On failure, read `{skill-root}/customize.toml` directly and use defaults.
|
||||
2. Hold every `{workflow.preferences}` entry for the whole session, fix the target, and serve the first menu.
|
||||
|
||||
## INTEGRATION (When Invoked Indirectly)
|
||||
## Serving the Catalog
|
||||
|
||||
When invoked from another prompt or process:
|
||||
|
||||
1. Receive or review the current section content that was just generated
|
||||
2. Apply elicitation methods iteratively to enhance that specific content
|
||||
3. Return the enhanced version back when user selects 'x' to proceed and return back
|
||||
4. The enhanced content replaces the original section content in the output document
|
||||
|
||||
---
|
||||
|
||||
## FLOW
|
||||
|
||||
### Step 1: Method Registry Loading
|
||||
|
||||
**Action:** Load `./methods.csv` for elicitation methods. If party-mode may participate, resolve the agent roster via:
|
||||
`scripts/pick_methods.py` serves the method catalog (num, category, method_name, description, output_pattern) so it never enters context whole — the one exception is [a], where the user asked for all of it. Invoke as:
|
||||
|
||||
```bash
|
||||
python3 {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key agents
|
||||
uv run {skill-root}/scripts/pick_methods.py --file {workflow.methods_file} <command>
|
||||
```
|
||||
|
||||
The resolver merges four layers in order: `_bmad/config.toml` (installer base, team-scoped), `_bmad/config.user.toml` (installer base, user-scoped), `_bmad/custom/config.toml` (team overrides), and `_bmad/custom/config.user.toml` (personal overrides). Each entry under `agents` is keyed by the agent's `code` and carries `name`, `title`, `icon`, `description`, `module`, and `team`.
|
||||
If `{workflow.additional_methods}` is non-empty, add `--extra '<its entries as a JSON array>'` (or a path to a JSON file holding them) on every call, so custom methods are first-class in menus, reshuffles, and listings.
|
||||
|
||||
#### CSV Structure
|
||||
- `categories` — category names + counts, the cheap map.
|
||||
- `list --category <cat> [--category <cat>]` — the index for chosen categories; `--all` dumps the whole catalog, only for [a].
|
||||
- `show <name-or-num> [...]` — full rows by name or num.
|
||||
- `random -n 5 --spread [--exclude <name>]...` — a category-diverse random draw.
|
||||
|
||||
- **category:** Method grouping (core, structural, risk, etc.)
|
||||
- **method_name:** Display name for the method
|
||||
- **description:** Rich explanation of what the method does, when to use it, and why it's valuable
|
||||
- **output_pattern:** Flexible flow guide using arrows (e.g., "analysis -> insights -> action")
|
||||
**First menu:** run `categories`, pick the 2–4 categories that fit the target (risk before a launch, technical for code, collaboration when stakeholders compete, creative when the content is flat), `list` them, and hand-pick five methods that attack the target from different angles — honoring `{workflow.preferences}`. **Reshuffle:** `random -n 5 --spread`, excluding everything already offered.
|
||||
|
||||
#### Context Analysis
|
||||
|
||||
- Use conversation history
|
||||
- Analyze: content type, complexity, stakeholder needs, risk level, and creative potential
|
||||
|
||||
#### Smart Selection
|
||||
|
||||
1. Analyze context: Content type, complexity, stakeholder needs, risk level, creative potential
|
||||
2. Parse descriptions: Understand each method's purpose from the rich descriptions in CSV
|
||||
3. Select 5 methods: Choose methods that best match the context based on their descriptions
|
||||
4. Balance approach: Include mix of foundational and specialized techniques as appropriate
|
||||
|
||||
---
|
||||
|
||||
### Step 2: Present Options and Handle Responses
|
||||
|
||||
#### Display Format
|
||||
## The Menu
|
||||
|
||||
```
|
||||
**Advanced Elicitation Options**
|
||||
_If party mode is active, agents will join in._
|
||||
Choose a number (1-5), [r] to Reshuffle, [a] List All, or [x] to Proceed:
|
||||
|
||||
1. [Method Name]
|
||||
@@ -83,60 +50,16 @@ a. List all methods with descriptions
|
||||
x. Proceed / No Further Actions
|
||||
```
|
||||
|
||||
#### Response Handling
|
||||
This menu is the interface other skills and their users rely on — keep its options and behavior stable. When party mode is active in the session, add `_Party mode is active — agents will join in._` under the heading. Handle the response:
|
||||
|
||||
**Case 1-5 (User selects a numbered method):**
|
||||
- **1–5** — run that method (several numbers: in sequence), then re-present the menu.
|
||||
- **r** — reshuffle as above and re-present.
|
||||
- **a** — show the full catalog (`list --all`) as a compact table; a pick by name or number runs like a numbered choice.
|
||||
- **x** — done. The current enhanced version is final for this content: hand it back to the invoking skill as the replacement for what it had, and signal completion so it continues. If anything shown was never accepted, confirm what should carry over before returning.
|
||||
- **Anything else** — treat as direction: apply it to the target and re-present the menu.
|
||||
|
||||
- Execute the selected method using its description from the CSV
|
||||
- Adapt the method's complexity and output format based on the current context
|
||||
- Apply the method creatively to the current section content being enhanced
|
||||
- Display the enhanced version showing what the method revealed or improved
|
||||
- **CRITICAL:** Ask the user if they would like to apply the changes to the doc (y/n/other) and HALT to await response.
|
||||
- **CRITICAL:** ONLY if Yes, apply the changes. IF No, discard your memory of the proposed changes. If any other reply, try best to follow the instructions given by the user.
|
||||
- **CRITICAL:** Re-present the same 1-5,r,x prompt to allow additional elicitations
|
||||
## Running a Method
|
||||
|
||||
**Case r (Reshuffle):**
|
||||
Use the method's description as its intent and its output_pattern as a flexible flow guide; scale depth to the target — a paragraph gets a light pass, an architecture decision gets the full treatment. Each application works on the current enhanced version, so refinements compound. Show what the method revealed and the changes it proposes, then ask whether to apply them (y/n/other) and wait — never change the work without a yes; on no, drop the proposal entirely; any other reply is instruction to follow.
|
||||
|
||||
- Select 5 random methods from methods.csv, present new list with same prompt format
|
||||
- When selecting, try to think and pick a diverse set of methods covering different categories and approaches, with 1 and 2 being potentially the most useful for the document or section being discovered
|
||||
|
||||
**Case x (Proceed):**
|
||||
|
||||
- Complete elicitation and proceed
|
||||
- Return the fully enhanced content back to the invoking skill
|
||||
- The enhanced content becomes the final version for that section
|
||||
- Signal completion back to the invoking skill to continue with next section
|
||||
|
||||
**Case a (List All):**
|
||||
|
||||
- List all methods with their descriptions from the CSV in a compact table
|
||||
- Allow user to select any method by name or number from the full list
|
||||
- After selection, execute the method as described in the Case 1-5 above
|
||||
|
||||
**Case: Direct Feedback:**
|
||||
|
||||
- Apply changes to current section content and re-present choices
|
||||
|
||||
**Case: Multiple Numbers:**
|
||||
|
||||
- Execute methods in sequence on the content, then re-offer choices
|
||||
|
||||
---
|
||||
|
||||
### Step 3: Execution Guidelines
|
||||
|
||||
- **Method execution:** Use the description from CSV to understand and apply each method
|
||||
- **Output pattern:** Use the pattern as a flexible guide (e.g., "paths -> evaluation -> selection")
|
||||
- **Dynamic adaptation:** Adjust complexity based on content needs (simple to sophisticated)
|
||||
- **Creative application:** Interpret methods flexibly based on context while maintaining pattern consistency
|
||||
- Focus on actionable insights
|
||||
- **Stay relevant:** Tie elicitation to specific content being analyzed (the current section from the document being created unless user indicates otherwise)
|
||||
- **Identify personas:** For single or multi-persona methods, clearly identify viewpoints, and use party members if available in memory already
|
||||
- **Critical loop behavior:** Always re-offer the 1-5,r,a,x choices after each method execution
|
||||
- Continue until user selects 'x' to proceed with enhanced content, confirm or ask the user what should be accepted from the session
|
||||
- Each method application builds upon previous enhancements
|
||||
- **Content preservation:** Track all enhancements made during elicitation
|
||||
- **Iterative enhancement:** Each selected method (1-5) should:
|
||||
1. Apply to the current enhanced version of the content
|
||||
2. Show the improvements made
|
||||
3. Return to the prompt for additional elicitations or completion
|
||||
When a method casts personas (round tables, panels, debates), reuse party members already in the session if party mode is active; otherwise resolve installed agents on demand via `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key agents` (a four-layer merge of `_bmad/config.toml`, `config.user.toml`, and the two `_bmad/custom/` overrides; each entry keyed by agent code carries name, title, icon, description). If neither yields a fit, invent named viewpoints suited to the content.
|
||||
|
||||
@@ -0,0 +1,54 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-advanced-elicitation.
|
||||
#
|
||||
# Override files (not edited here):
|
||||
# {project-root}/_bmad/custom/bmad-advanced-elicitation.toml (team)
|
||||
# {project-root}/_bmad/custom/bmad-advanced-elicitation.user.toml (personal)
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins • plain arrays: append
|
||||
# arrays of tables keyed by `code`: matching key replaces, new keys append
|
||||
|
||||
# The elicitation method catalog served by scripts/pick_methods.py
|
||||
# (columns: num,category,method_name,description,output_pattern). Swap the path
|
||||
# in team/user TOML to ship a different catalog. Kept `{skill-root}`-anchored so
|
||||
# it resolves regardless of the working directory (pick_methods.py is always
|
||||
# invoked with `--file {workflow.methods_file}`).
|
||||
methods_file = "{skill-root}/assets/methods.csv"
|
||||
|
||||
# Persistent preferences the refiner honors for every session — methods to
|
||||
# favor or avoid, how pushback should land, house rules for applying changes.
|
||||
# Literal sentences; append-merges, so team and personal preferences both apply.
|
||||
#
|
||||
# Examples (set in team/user override TOML):
|
||||
# preferences = [
|
||||
# "Lead with a risk-category method for anything touching production systems.",
|
||||
# "Never offer roleplay or persona methods.",
|
||||
# ]
|
||||
preferences = []
|
||||
|
||||
# Extra methods — and whole new categories — merged into the catalog without
|
||||
# editing the shipped CSV. Passed to pick_methods.py via --extra, so custom
|
||||
# methods are first-class in every menu, reshuffle, and listing.
|
||||
#
|
||||
# Two keys, two jobs — keep them aligned:
|
||||
# `code` is only the TOML merge key across override layers: a personal entry
|
||||
# with the same code replaces the team one; new codes append.
|
||||
# `method_name` is the catalog identity: an entry whose method_name matches a
|
||||
# shipped method replaces it (retune its description or pattern; it keeps
|
||||
# the shipped num), others append with new nums.
|
||||
# To override another layer's entry, reuse its `code`. Two entries with
|
||||
# different codes but the same method_name both survive the TOML merge, and
|
||||
# only the later one reaches the catalog.
|
||||
#
|
||||
# Example (set in team/user override TOML):
|
||||
# [[workflow.additional_methods]]
|
||||
# code = "regulatory-inversion"
|
||||
# category = "domain-specific"
|
||||
# method_name = "Regulatory Inversion"
|
||||
# description = "Start from the compliance constraint and ask what becomes possible only because of it - turns the rule into a generative frame"
|
||||
# output_pattern = "constraint → possibilities → design"
|
||||
additional_methods = []
|
||||
@@ -0,0 +1,226 @@
|
||||
#!/usr/bin/env python3
|
||||
# /// script
|
||||
# requires-python = ">=3.10"
|
||||
# ///
|
||||
"""Serve the elicitation method catalog without loading it all into context.
|
||||
|
||||
The catalog is a CSV (num, category, method_name, description, output_pattern).
|
||||
`description` is a one-line gist — enough to run the method; `output_pattern` is
|
||||
a flexible flow guide (e.g. "assumptions → truths → new approach").
|
||||
|
||||
Commands:
|
||||
categories list category names + counts (the cheap entry point)
|
||||
list --category C [...] the index (num/category/name/gist) for those categories
|
||||
list --all the whole catalog at once — deliberate; large, avoid interactively
|
||||
show NAME_OR_NUM [...] full row for each method, matched by name or num
|
||||
random [-n N] [--category C ...] [--exclude NAME ...] [--spread]
|
||||
draw N at random; --spread forces category diversity
|
||||
(at most one per category until categories run out) —
|
||||
the reshuffle draw; --exclude skips already-shown methods
|
||||
|
||||
`list` refuses to run with neither --category nor --all: dumping the full catalog
|
||||
into context must always be an explicit, deliberate choice.
|
||||
|
||||
`--extra SPEC` merges additional methods (customize.toml's `additional_methods`)
|
||||
into every command. SPEC is either a JSON array literal (starts with `[`) or a
|
||||
path to a JSON file; each item is {code, category, method_name, description,
|
||||
output_pattern}. An extra whose method_name matches a catalog row
|
||||
(case-insensitive) REPLACES it and keeps that row's num — retune a shipped
|
||||
method; others append and get the next free nums, so new methods and whole new
|
||||
categories are first-class and number-addressable everywhere.
|
||||
|
||||
Default output is lean tab-separated text for an LLM to read; --json for structured.
|
||||
"""
|
||||
import argparse
|
||||
import csv
|
||||
import json
|
||||
import random
|
||||
import sys
|
||||
from pathlib import Path
|
||||
|
||||
DEFAULT_FILE = Path(__file__).resolve().parent.parent / "assets" / "methods.csv"
|
||||
FIELDS = ("num", "category", "method_name", "description", "output_pattern")
|
||||
|
||||
|
||||
def load(file: Path) -> list[dict]:
|
||||
with open(file, newline="", encoding="utf-8") as f:
|
||||
rows = list(csv.DictReader(f))
|
||||
for r in rows:
|
||||
for k in FIELDS:
|
||||
r.setdefault(k, "")
|
||||
r[k] = (r.get(k) or "").strip()
|
||||
return rows
|
||||
|
||||
|
||||
def load_extra(spec: str) -> list[dict]:
|
||||
"""Parse the --extra overlay: a JSON array literal or a path to a JSON file."""
|
||||
text = spec if spec.lstrip().startswith("[") else Path(spec).read_text(encoding="utf-8")
|
||||
data = json.loads(text)
|
||||
rows = []
|
||||
for item in data:
|
||||
row = {k: str(item.get(k) or "").strip() for k in FIELDS}
|
||||
row["code"] = str(item.get("code") or "").strip() # kept for traceability
|
||||
rows.append(row)
|
||||
return rows
|
||||
|
||||
|
||||
def merge_extra(rows: list[dict], extras: list[dict]) -> list[dict]:
|
||||
"""Extras replace a catalog row with the same method_name (case-insensitive),
|
||||
otherwise append — so overrides can retune shipped methods or grow the catalog.
|
||||
A replacement inherits the shipped row's num; appended extras get the next
|
||||
free nums, so every merged method stays addressable by number."""
|
||||
merged = list(rows)
|
||||
index = {r["method_name"].lower(): i for i, r in enumerate(merged)}
|
||||
for e in extras:
|
||||
key = e["method_name"].lower()
|
||||
if key in index:
|
||||
e = dict(e)
|
||||
e["num"] = e["num"] or merged[index[key]]["num"]
|
||||
merged[index[key]] = e
|
||||
else:
|
||||
index[key] = len(merged)
|
||||
merged.append(dict(e))
|
||||
next_num = max((int(r["num"]) for r in merged if r["num"].isdigit()), default=0) + 1
|
||||
for r in merged:
|
||||
if not r["num"]:
|
||||
r["num"] = str(next_num)
|
||||
next_num += 1
|
||||
return merged
|
||||
|
||||
|
||||
def categories(rows: list[dict]) -> list[tuple[str, int]]:
|
||||
counts: dict[str, int] = {}
|
||||
for r in rows:
|
||||
counts[r["category"]] = counts.get(r["category"], 0) + 1
|
||||
return sorted(counts.items())
|
||||
|
||||
|
||||
def filter_cats(rows: list[dict], cats: list[str] | None) -> list[dict]:
|
||||
if not cats:
|
||||
return rows
|
||||
wanted = {c.lower() for c in cats}
|
||||
return [r for r in rows if r["category"].lower() in wanted]
|
||||
|
||||
|
||||
def find(rows: list[dict], names: list[str]) -> tuple[list[dict], list[str]]:
|
||||
"""Match each query by method_name or by num, case-insensitively."""
|
||||
by_key: dict[str, dict] = {}
|
||||
for r in rows:
|
||||
by_key[r["method_name"].lower()] = r
|
||||
if r["num"]:
|
||||
by_key.setdefault(r["num"], r)
|
||||
found, missing = [], []
|
||||
for n in names:
|
||||
r = by_key.get(n.strip().lower())
|
||||
(found if r else missing).append(r if r else n)
|
||||
return found, missing
|
||||
|
||||
|
||||
def exclude(rows: list[dict], names: list[str] | None) -> list[dict]:
|
||||
if not names:
|
||||
return rows
|
||||
skip = {n.strip().lower() for n in names}
|
||||
return [r for r in rows if r["method_name"].lower() not in skip]
|
||||
|
||||
|
||||
def spread_sample(rows: list[dict], n: int, rng: random.Random | None = None) -> list[dict]:
|
||||
"""Draw n methods with maximum category diversity: shuffle the categories,
|
||||
take one random method per category round-robin, wrapping only when there
|
||||
are fewer categories than picks."""
|
||||
rng = rng or random
|
||||
by_cat: dict[str, list[dict]] = {}
|
||||
for r in rows:
|
||||
by_cat.setdefault(r["category"], []).append(r)
|
||||
buckets = list(by_cat.values())
|
||||
rng.shuffle(buckets)
|
||||
for b in buckets:
|
||||
rng.shuffle(b)
|
||||
out: list[dict] = []
|
||||
while buckets and len(out) < n:
|
||||
exhausted = []
|
||||
for b in buckets:
|
||||
if len(out) >= n:
|
||||
break
|
||||
out.append(b.pop())
|
||||
if not b:
|
||||
exhausted.append(b)
|
||||
buckets = [b for b in buckets if b not in exhausted]
|
||||
return out
|
||||
|
||||
|
||||
def fmt_categories(cats: list[tuple[str, int]], as_json: bool) -> str:
|
||||
if as_json:
|
||||
return json.dumps([{"category": c, "count": n} for c, n in cats])
|
||||
return "\n".join(f"{c}\t{n}" for c, n in cats)
|
||||
|
||||
|
||||
def fmt_rows(rows: list[dict], as_json: bool) -> str:
|
||||
if as_json:
|
||||
return json.dumps([{k: r[k] for k in FIELDS} for r in rows])
|
||||
return "\n".join(
|
||||
f"{r['num']}\t{r['category']}\t{r['method_name']}\t{r['description']}\t{r['output_pattern']}"
|
||||
for r in rows
|
||||
)
|
||||
|
||||
|
||||
def main(argv: list[str] | None = None) -> int:
|
||||
p = argparse.ArgumentParser(description=__doc__, formatter_class=argparse.RawDescriptionHelpFormatter)
|
||||
p.add_argument("--file", type=Path, default=DEFAULT_FILE, help="method CSV (default: sibling assets/methods.csv)")
|
||||
p.add_argument("--extra", help="additional methods: a JSON array literal or a path to a JSON file")
|
||||
p.add_argument("--json", action="store_true", help="emit structured JSON instead of lean text")
|
||||
sub = p.add_subparsers(dest="cmd", required=True)
|
||||
sub.add_parser("categories", help="list category names + counts")
|
||||
pl = sub.add_parser("list", help="the index for chosen categories (needs --category or --all)")
|
||||
pl.add_argument("--category", action="append", help="filter to a category (repeatable)")
|
||||
pl.add_argument("--all", action="store_true", help="dump the entire catalog (deliberate; large)")
|
||||
ps = sub.add_parser("show", help="full row for each named method")
|
||||
ps.add_argument("names", nargs="+", help="method names or nums")
|
||||
pr = sub.add_parser("random", help="draw methods at random")
|
||||
pr.add_argument("-n", type=int, default=1, help="how many (default 1)")
|
||||
pr.add_argument("--category", action="append", help="restrict to a category (repeatable)")
|
||||
pr.add_argument("--exclude", action="append", help="method name to skip (repeatable) — e.g. already shown")
|
||||
pr.add_argument("--spread", action="store_true", help="force category diversity across the draw")
|
||||
args = p.parse_args(argv)
|
||||
|
||||
if not args.file.is_file():
|
||||
print(f"error: method file not found: {args.file}", file=sys.stderr)
|
||||
return 2
|
||||
rows = load(args.file)
|
||||
if args.extra:
|
||||
try:
|
||||
rows = merge_extra(rows, load_extra(args.extra))
|
||||
except (OSError, ValueError) as e:
|
||||
print(f"error: could not read --extra: {e}", file=sys.stderr)
|
||||
return 2
|
||||
|
||||
if args.cmd == "categories":
|
||||
print(fmt_categories(categories(rows), args.json))
|
||||
elif args.cmd == "list":
|
||||
if not args.category and not args.all:
|
||||
print(
|
||||
"error: `list` needs --category (one or more) — or --all to dump the whole "
|
||||
"catalog on purpose. Use `categories` for the cheap map, or `random` to draw blind.",
|
||||
file=sys.stderr,
|
||||
)
|
||||
return 2
|
||||
print(fmt_rows(filter_cats(rows, args.category), args.json))
|
||||
elif args.cmd == "show":
|
||||
found, missing = find(rows, args.names)
|
||||
for m in missing:
|
||||
print(f"# not found: {m}", file=sys.stderr)
|
||||
if not found:
|
||||
return 1
|
||||
print(fmt_rows(found, args.json))
|
||||
elif args.cmd == "random":
|
||||
pool = exclude(filter_cats(rows, args.category), args.exclude)
|
||||
if not pool:
|
||||
print("# no methods match", file=sys.stderr)
|
||||
return 1
|
||||
n = max(0, min(args.n, len(pool))) # clamp: never crash on a negative or oversized -n
|
||||
picks = spread_sample(pool, n) if args.spread else random.sample(pool, n)
|
||||
print(fmt_rows(picks, args.json))
|
||||
return 0
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
sys.exit(main())
|
||||
@@ -0,0 +1,228 @@
|
||||
# /// script
|
||||
# requires-python = ">=3.10"
|
||||
# dependencies = ["pytest>=8.0"]
|
||||
# ///
|
||||
"""Tests for pick_methods.py.
|
||||
|
||||
Run: uv run scripts/tests/test_pick_methods.py
|
||||
or: uv run --with pytest -m pytest scripts/tests/test_pick_methods.py
|
||||
"""
|
||||
import json
|
||||
import random
|
||||
import sys
|
||||
from pathlib import Path
|
||||
|
||||
import pytest
|
||||
|
||||
sys.path.insert(0, str(Path(__file__).resolve().parent.parent))
|
||||
import pick_methods # noqa: E402
|
||||
|
||||
CSV = """num,category,method_name,description,output_pattern
|
||||
1,risk,Pre-mortem Analysis,Imagine future failure then work backwards,failure → causes → prevention
|
||||
2,risk,Assumption Audit,List and stress-test every assumption,list → rate → stress-test
|
||||
3,core,First Principles Analysis,Rebuild from fundamental truths,assumptions → truths → new approach
|
||||
4,core,Socratic Questioning,Targeted questions reveal hidden assumptions,questions → revelations → understanding
|
||||
5,creative,SCAMPER Method,Seven creativity lenses,S→C→A→M→P→E→R
|
||||
"""
|
||||
|
||||
EXTRA = [
|
||||
{
|
||||
"code": "reg-inversion",
|
||||
"category": "domain",
|
||||
"method_name": "Regulatory Inversion",
|
||||
"description": "Start from the compliance constraint",
|
||||
"output_pattern": "constraint → possibility",
|
||||
},
|
||||
{
|
||||
"code": "premortem-lite",
|
||||
"category": "risk",
|
||||
"method_name": "Pre-mortem Analysis",
|
||||
"description": "RETUNED pre-mortem",
|
||||
"output_pattern": "failure → prevention",
|
||||
},
|
||||
]
|
||||
|
||||
|
||||
@pytest.fixture
|
||||
def lib(tmp_path):
|
||||
csv_path = tmp_path / "methods.csv"
|
||||
csv_path.write_text(CSV, encoding="utf-8")
|
||||
return csv_path
|
||||
|
||||
|
||||
def rows(lib):
|
||||
return pick_methods.load(lib)
|
||||
|
||||
|
||||
# --- load / merge -----------------------------------------------------------
|
||||
|
||||
def test_load_all_fields_present(lib):
|
||||
r = rows(lib)
|
||||
assert len(r) == 5
|
||||
assert r[0]["method_name"] == "Pre-mortem Analysis"
|
||||
assert all(set(pick_methods.FIELDS) <= set(row) for row in r)
|
||||
|
||||
|
||||
def test_load_extra_json_literal_and_file(tmp_path, lib):
|
||||
literal = pick_methods.load_extra(json.dumps(EXTRA))
|
||||
f = tmp_path / "extra.json"
|
||||
f.write_text(json.dumps(EXTRA), encoding="utf-8")
|
||||
from_file = pick_methods.load_extra(str(f))
|
||||
assert literal == from_file
|
||||
assert literal[0]["method_name"] == "Regulatory Inversion"
|
||||
assert literal[0]["num"] == "" # missing fields normalize to empty
|
||||
assert literal[0]["code"] == "reg-inversion" # code survives loading
|
||||
|
||||
|
||||
def test_merge_extra_replaces_by_name_and_appends(lib):
|
||||
merged = pick_methods.merge_extra(rows(lib), pick_methods.load_extra(json.dumps(EXTRA)))
|
||||
assert len(merged) == 6 # 5 shipped, 1 replaced in place, 1 appended
|
||||
premortem = next(r for r in merged if r["method_name"] == "Pre-mortem Analysis")
|
||||
assert premortem["description"] == "RETUNED pre-mortem"
|
||||
assert premortem["num"] == "1" # replacement inherits the shipped num
|
||||
appended = next(r for r in merged if r["method_name"] == "Regulatory Inversion")
|
||||
assert appended["num"] == "6" # appended extras get the next free num
|
||||
assert dict(pick_methods.categories(merged))["domain"] == 1 # new category is first-class
|
||||
|
||||
|
||||
def test_extras_are_addressable_by_num(lib):
|
||||
merged = pick_methods.merge_extra(rows(lib), pick_methods.load_extra(json.dumps(EXTRA)))
|
||||
found, missing = pick_methods.find(merged, ["6", "1"])
|
||||
assert [r["method_name"] for r in found] == ["Regulatory Inversion", "Pre-mortem Analysis"]
|
||||
assert missing == []
|
||||
|
||||
|
||||
# --- categories / filter / find / exclude -----------------------------------
|
||||
|
||||
def test_categories_counts_sorted(lib):
|
||||
assert pick_methods.categories(rows(lib)) == [("core", 2), ("creative", 1), ("risk", 2)]
|
||||
|
||||
|
||||
def test_filter_is_case_insensitive(lib):
|
||||
got = pick_methods.filter_cats(rows(lib), ["RISK"])
|
||||
assert {r["method_name"] for r in got} == {"Pre-mortem Analysis", "Assumption Audit"}
|
||||
|
||||
|
||||
def test_filter_none_returns_all(lib):
|
||||
assert len(pick_methods.filter_cats(rows(lib), None)) == 5
|
||||
|
||||
|
||||
def test_find_by_name_num_and_missing(lib):
|
||||
found, missing = pick_methods.find(rows(lib), ["scamper method", "3", "Nope"])
|
||||
assert [r["method_name"] for r in found] == ["SCAMPER Method", "First Principles Analysis"]
|
||||
assert missing == ["Nope"]
|
||||
|
||||
|
||||
def test_exclude_skips_named(lib):
|
||||
got = pick_methods.exclude(rows(lib), ["pre-mortem analysis", "SCAMPER Method"])
|
||||
assert {r["method_name"] for r in got} == {
|
||||
"Assumption Audit", "First Principles Analysis", "Socratic Questioning",
|
||||
}
|
||||
|
||||
|
||||
# --- spread sampling ---------------------------------------------------------
|
||||
|
||||
def test_spread_hits_distinct_categories(lib):
|
||||
for seed in range(20):
|
||||
picks = pick_methods.spread_sample(rows(lib), 3, random.Random(seed))
|
||||
assert len({r["category"] for r in picks}) == 3
|
||||
|
||||
|
||||
def test_spread_wraps_when_categories_run_out(lib):
|
||||
picks = pick_methods.spread_sample(rows(lib), 5, random.Random(0))
|
||||
assert len(picks) == 5
|
||||
assert len({r["method_name"] for r in picks}) == 5 # no duplicates
|
||||
|
||||
|
||||
def test_spread_clamps_to_pool(lib):
|
||||
assert len(pick_methods.spread_sample(rows(lib), 99, random.Random(0))) == 5
|
||||
|
||||
|
||||
# --- CLI ---------------------------------------------------------------------
|
||||
|
||||
def run(args, lib, capsys):
|
||||
code = pick_methods.main(["--file", str(lib), *args])
|
||||
captured = capsys.readouterr()
|
||||
return code, captured.out, captured.err
|
||||
|
||||
|
||||
def test_cli_categories(lib, capsys):
|
||||
code, out, _ = run(["categories"], lib, capsys)
|
||||
assert code == 0
|
||||
assert "risk\t2" in out
|
||||
|
||||
|
||||
def test_cli_list_requires_scope(lib, capsys):
|
||||
code, _, err = run(["list"], lib, capsys)
|
||||
assert code == 2
|
||||
assert "--category" in err
|
||||
|
||||
|
||||
def test_cli_list_category_and_all(lib, capsys):
|
||||
code, out, _ = run(["list", "--category", "core"], lib, capsys)
|
||||
assert code == 0 and len(out.strip().splitlines()) == 2
|
||||
assert "Socratic Questioning" in out and "SCAMPER" not in out
|
||||
code, out, _ = run(["list", "--all"], lib, capsys)
|
||||
assert code == 0 and "SCAMPER" in out
|
||||
|
||||
|
||||
def test_cli_show_found_and_missing(lib, capsys):
|
||||
code, out, err = run(["show", "Assumption Audit", "Ghost"], lib, capsys)
|
||||
assert code == 0
|
||||
assert "stress-test" in out
|
||||
assert "not found: Ghost" in err
|
||||
code, _, _ = run(["show", "Ghost"], lib, capsys)
|
||||
assert code == 1
|
||||
|
||||
|
||||
def test_cli_random_spread_exclude(lib, capsys):
|
||||
code, out, _ = run(
|
||||
["random", "-n", "3", "--spread", "--exclude", "SCAMPER Method"], lib, capsys
|
||||
)
|
||||
assert code == 0
|
||||
lines = [ln for ln in out.strip().splitlines() if ln]
|
||||
assert len(lines) == 3
|
||||
assert "SCAMPER" not in out
|
||||
|
||||
|
||||
def test_cli_random_clamps_and_empty_pool(lib, capsys):
|
||||
code, out, _ = run(["random", "-n", "99"], lib, capsys)
|
||||
assert code == 0 and len(out.strip().splitlines()) == 5
|
||||
code, _, err = run(["random", "--category", "nope"], lib, capsys)
|
||||
assert code == 1 and "no methods match" in err
|
||||
|
||||
|
||||
def test_cli_extra_inline_json(lib, capsys):
|
||||
code, out, _ = run(
|
||||
["--extra", json.dumps(EXTRA), "list", "--category", "domain"], lib, capsys
|
||||
)
|
||||
assert code == 0 and "Regulatory Inversion" in out
|
||||
|
||||
|
||||
def test_cli_bad_extra_and_missing_file(tmp_path, lib, capsys):
|
||||
code, _, err = run(["--extra", str(tmp_path / "gone.json"), "categories"], lib, capsys)
|
||||
assert code == 2 and "--extra" in err
|
||||
code = pick_methods.main(["--file", str(tmp_path / "gone.csv"), "categories"])
|
||||
assert code == 2
|
||||
|
||||
|
||||
def test_cli_json_output(lib, capsys):
|
||||
code, out, _ = run(["--json", "show", "1"], lib, capsys)
|
||||
assert code == 0
|
||||
data = json.loads(out)
|
||||
assert data[0]["method_name"] == "Pre-mortem Analysis"
|
||||
|
||||
|
||||
# --- shipped catalog integration ----------------------------------------------
|
||||
|
||||
def test_shipped_catalog_loads_clean():
|
||||
shipped = pick_methods.DEFAULT_FILE
|
||||
assert shipped.is_file(), f"shipped catalog missing: {shipped}"
|
||||
r = pick_methods.load(shipped)
|
||||
assert len(r) >= 60
|
||||
for row in r:
|
||||
assert row["category"] and row["method_name"] and row["description"], row
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
sys.exit(pytest.main([__file__, "-q"]))
|
||||
@@ -1,239 +0,0 @@
|
||||
# BMad Brainstorming Catalog — Deep Analysis
|
||||
|
||||
> Analysis of the brainstorming library (`assets/brain-methods.csv`) and the selection
|
||||
> experience (`assets/brain-selector.html`, generated by `scripts/brain.py`). Companion
|
||||
> data: `method-matrix.csv` (every method tagged on 4 axes).
|
||||
>
|
||||
> **Status (implemented, uncommitted for review):** CSV extended with `provenance` /
|
||||
> `good_for` / `audience` columns; 8 researched `classic` methods added (108 total);
|
||||
> `brain.py` now renders a "Proven & Professional" lead group, super-group ordering, a
|
||||
> "Great for" goal filter, and a per-category "Invent a … technique" card; convergence
|
||||
> shipped as `references/converge.md` (diverge → converge → finalize) and wired into
|
||||
> `SKILL.md`. Sections below are the rationale.
|
||||
|
||||
---
|
||||
|
||||
## 1. TL;DR
|
||||
|
||||
The catalog is strong, distinctive, and well-built. The opportunities are not "more methods" so much as **navigation and intent**:
|
||||
|
||||
1. **The selector sorts categories alphabetically.** There is no ordering/grouping layer, so the well-known professional methods (SCAMPER, Six Hats, Five Whys, etc.) are scattered across four categories and buried below `Absurdist` and `Biomimetic`. Enterprise users meet whimsy before they meet anything they recognize. → **Add a grouping + ordering layer; lead with a "Proven & Professional" group.**
|
||||
2. **Nothing connects the user's stated goal to technique choice.** The skill asks for the goal up front but then offers an alphabetical wall. The single highest-value addition is a **goal → technique affinity layer** so "I'm adding a feature to a brownfield app" surfaces a different short-list than "planning a sabbatical."
|
||||
3. **The catalog is 100% divergent (generative).** There is essentially no *convergence* (prioritize / cluster / decide). This is partly a sound principle and partly a real gap — see §5.
|
||||
4. **Real overlap exists**, but it's mostly "same cognitive move, different costume." Four mechanisms (perspective-shift, constraint, analogy, inversion) account for ~60 of 100 methods; sensory, questioning, systems, and time-shift are comparatively thin.
|
||||
5. **Descriptions should stay terse** — the brevity is correct. Only two targeted fixes are warranted: the `collaborative` category silently assumes multiple humans, and ~10 "vibe-only" methods lack an output anchor.
|
||||
6. **Per-category "invent on the fly" is a good idea** — but implement it as a generated synthetic card per section, not 13 near-duplicate CSV rows.
|
||||
|
||||
---
|
||||
|
||||
## 2. Method — how this was analyzed
|
||||
|
||||
Each of the 100 methods was tagged on **four independent axes** (see `method-matrix.csv`). Category alone only captures *aesthetic/mechanism*; these four axes are what expose grouping, overlap, gaps, and the goal-routing opportunity.
|
||||
|
||||
| Axis | Values | Answers |
|
||||
|---|---|---|
|
||||
| **Provenance** | `classic` · `signature` · `playful` | What goes in the enterprise "proven" group? |
|
||||
| **Mechanism** (primary + secondary) | inversion · analogy · perspective · constraint · decomposition · time-shift · systems · sensory · questioning · combination · provocation · convergence | Where is the catalog redundant vs thin? |
|
||||
| **Goal affinity** (multi) | feature · novel · personal · strategy · planning · diagnosis · unstuck | Given the user's goal, what should we recommend? |
|
||||
| **Audience** | solo · group · either | What breaks in a 1:1 user+LLM session? |
|
||||
|
||||
---
|
||||
|
||||
## 3. Findings
|
||||
|
||||
### 3a. Provenance — the "proven & professional" set exists, but is scattered
|
||||
|
||||
The methods an innovation consultant or enterprise facilitator would recognize by name are spread across `structured`, `deep`, `creative`, and `collaborative`. The **canonical core (~22)**:
|
||||
|
||||
> SCAMPER · Six Thinking Hats · Mind Mapping · Lotus Blossom · Crazy 8s · Disney Method ·
|
||||
> Starbursting · Morphological Analysis · Five Whys · Laddering · Causal Loop Mapping ·
|
||||
> First Principles · Reverse Brainstorming · Assumption Reversal · Worst Possible Idea ·
|
||||
> Provocation (PO) · Question Storming · Brainwriting/Round Robin · Yes-And · Random Stimulation ·
|
||||
> Role Playing · Analogical Thinking
|
||||
|
||||
A second tier is *recognizable-adjacent* (Concept Blending, Forced Relationships, Decision Tree, Solution Matrix, Failure Analysis/pre-mortem, Devil's Advocate, 1000x Budget). Everything else is `signature` (BMad-original, serious) or `playful` (the delight layer — `wild`, `absurdist`, `theatrical`, much of `quantum`/`cultural`).
|
||||
|
||||
**Recommendation — lead with "Proven & Professional."** Three ways to implement (pick in review):
|
||||
|
||||
- **Option A — Tag + generated lead section (recommended).** Add a `provenance` column to the CSV. `brain.py` renders a synthetic **"Proven & Professional"** section *first* (pulling all `classic`-tagged methods, cross-category), then the existing categories grouped and ordered (see §7). A method keeps its home category and also appears in the lead group. Pro: zero loss of mechanism categorization; enterprise sees credibility first. Con: those ~22 methods appear twice on the browse page (arguably fine — or filter them out of their home category).
|
||||
- **Option B — New `classic` category.** Move the ~22 into a single first category. Pro: simplest. Con: destroys the mechanism grouping (SCAMPER is *also* structured; Five Whys is *also* deep), and the category becomes a grab-bag.
|
||||
- **Option C — Two-level groups only, no provenance tag.** Reorder the 13 categories into super-groups (§7) so "serious" comes first, but don't pull classics out. Pro: cleanest data model. Con: doesn't actually cluster the *named* methods — they stay scattered within their categories.
|
||||
|
||||
My pick: **A.** It satisfies "professional methods grouped and shown first" literally, without flattening the taxonomy that makes the rest of the catalog shine.
|
||||
|
||||
### 3b. Mechanism — the catalog has four over-served "spines"
|
||||
|
||||
Primary-mechanism distribution across the 100:
|
||||
|
||||
| Mechanism | ~count | Read |
|
||||
|---|---|---|
|
||||
| **perspective-shift** | ~18 | Over-served. Role Playing, Six Hats, Persona, Alien, Ancestor Council, Inner Child, Future Self, Drunk Uncle, Golden Retriever, Infomercial… all "adopt another viewpoint," differentiated only by *who*. |
|
||||
| **constraint** | ~16 | Over-served. What If, the entire `constraint` category, 1000x, Post-Scarcity, Parallel Universe, Zombie, Quantum Tunneling, Permission Giving… all "add/remove/exaggerate a limit." |
|
||||
| **analogy / transfer** | ~12 | Healthy. Analogical, Metaphor, Cross-Pollination, Trait Transfer, Nature's Solutions, Fusion Cuisine, Proverb, Random Stimulation. |
|
||||
| **inversion** | ~11 | Healthy but clustered. Reverse, Assumption Reversal, Worst Idea, Anti-Solution, Failure Analysis, Devil's Advocate, Cursed Genie, Villain's Monologue, Trickster. |
|
||||
| **combination** | ~9 | Fine. |
|
||||
| **decomposition** | ~9 | Fine. |
|
||||
| **systems / emergence** | ~7 | Thin-ish (concentrated in `quantum`/`biomimetic`). |
|
||||
| **time-shift** | ~6 | Thin. |
|
||||
| **questioning** | ~5 | Thin. |
|
||||
| **sensory / intuitive** | ~5 | Thin (all in `introspective_delight`). |
|
||||
| **convergence** | ~1 | **Effectively absent** (only Superposition Collapse). See §5. |
|
||||
|
||||
**Takeaway:** the redundancy is not a defect to delete — the *costume* (a villain's monologue vs. a courtroom vs. "make it worse") is exactly what makes a 30th inversion technique feel fresh to a user. But a curator should know the catalog leans hard on perspective + constraint, and that **convergence is the one genuinely empty cell.** New methods (§6) should target the thin cells, not the spines.
|
||||
|
||||
### 3c. Goal affinity — the headline missing capability
|
||||
|
||||
`SKILL.md` already opens with *"what are we brainstorming, and what's the goal?"* — but that goal never routes technique selection. Mapping the matrix's `goal_affinity` tags gives a ready recommendation table. This is what powers "AI picks N" intelligently and what an enterprise user wants:
|
||||
|
||||
| Goal | Strong default techniques (lead picks **bold**) |
|
||||
|---|---|
|
||||
| **Build a feature** (greenfield/brownfield) | **First Principles**, **SCAMPER**, **Morphological Analysis**, Crazy 8s, Solution Matrix, Reverse Brainstorming, One Feature Only, Ship in 60 Minutes, Chaos Engineering, Cursed Genie (edge cases), Persona Journey, *+ new: Job to Be Done, Follow the Anomaly* |
|
||||
| **Novel concept / new product** | **Concept Blending**, **Cross-Pollination**, **Forced Relationships**, What If, Trait Transfer, Nature's Solutions, Fusion Cuisine, Emerging Tech Collision, Crank the Dial to 11, Quantum Tunneling |
|
||||
| **Personal / life decision** | **Future Self Interview**, **Values Archaeology**, **Laddering**, Six Hats, Ancestor Council, Proverb Mining, Mythic Frameworks, the `introspective_delight` set, *+ new: Build on What Works* |
|
||||
| **Strategy / positioning** | **Six Thinking Hats**, **Failure Analysis** (pre-mortem), Field Lines, Ecosystem Thinking, Utopia vs Dystopia, 1000x Budget, Disney Method, Relativity Frame Shift, Infomercial at 3AM, Predator & Prey |
|
||||
| **Concrete planning** (event/project) | **Mind Mapping**, **Lotus Blossom**, Morphological Analysis, Decision Tree, Six Hats, $0 Mandate, Constraint Roulette, Time Horizon Ladder |
|
||||
| **Root-cause / diagnosis** | **Five Whys**, **Causal Loop Mapping**, Failure Analysis, Constraint Mapping, Question Storming, Starbursting, Anti-Solution, Alien Anthropologist |
|
||||
| **Get unstuck / break fixation** | **Random Stimulation**, **Provocation**, **Worst Possible Idea**, Crank the Dial to 11, Constraint Roulette, Three Rounds of Stupid, Drunk History, most of `wild`/`absurdist`/`theatrical` |
|
||||
|
||||
**Recommendation:** persist this as machine-readable affinity (a `goals` column on the CSV, sourced from `method-matrix.csv`), then (1) have the skill recommend a batch from the up-front goal, and (2) let the composer page filter/highlight "great for: [your goal]." This is the single change that most improves both enterprise and casual use.
|
||||
|
||||
### 3d. Audience — the `collaborative` category quietly assumes a room of people
|
||||
|
||||
5 of the 8 `collaborative` methods (Round Robin, Relay Race, Hot Potato, Fold the Paper, Steal & Upgrade) are written for *multiple humans passing artifacts*. In the default 1:1 user+LLM session they don't translate without the coach silently reinterpreting them. This is the one place the catalog can mislead. Options: tag `audience`, and either (a) add a one-clause solo adaptation to each, or (b) have the skill note "this one shines with a group" when picked solo. Low effort, removes the only real footgun.
|
||||
|
||||
### 3e. Description anchoring — keep terse, fix ~12 specifically
|
||||
|
||||
The deliberate brevity is **right** — the gist + a creative LLM beats over-specification, and it matches the catalog's house style. Do **not** bulk-expand. Two surgical passes only:
|
||||
|
||||
1. **Group-dependent `collaborative` methods** (§3d) — add a short solo-mode clause or an audience tag.
|
||||
2. **~10 "vibe-only" methods** where the *evocation is great but the output is ambiguous*, so different LLM runs would diverge wildly: e.g. **Field Lines**, **Observer Effect**, **Guerrilla Gardening Ideas**, **Emergent Thinking**, **Entanglement Thinking**, **Elemental Forces**. A tiny "…so that ___" outcome clause anchors the deliverable without killing the brevity. Example: *Guerrilla Gardening Ideas* → add "…**so you surface where an unsanctioned, low-visibility pilot could prove the idea before anyone can veto it**."
|
||||
|
||||
Everything crisp (Five Whys, SCAMPER, First Principles, Crazy 8s) stays untouched.
|
||||
|
||||
---
|
||||
|
||||
## 4. Quick wins vs structural changes
|
||||
|
||||
| Change | Effort | Impact | Type |
|
||||
|---|---|---|---|
|
||||
| Goal→technique affinity (`goals` column + recommendation) | Med | **High** | structural |
|
||||
| "Proven & Professional" lead group + category ordering | Med | **High** (enterprise) | structural |
|
||||
| Per-category "invent in the spirit" card (§6) | Low | Med | quick win |
|
||||
| Convergence mini-set (§5) | Low–Med | Med–High | structural (philosophy) |
|
||||
| `audience` tag + collaborative fix (§3d) | Low | Med | quick win |
|
||||
| ~12 description anchors (§3e) | Low | Low–Med | quick win |
|
||||
| New gap-filling methods (§6) | Low | Med | additive |
|
||||
|
||||
---
|
||||
|
||||
## 5. Divergent vs convergent — the answer, and a recommendation
|
||||
|
||||
**What it is.** Divergent = generate (quantity, novelty, breadth). Convergent = evaluate, cluster, prioritize, decide. A complete creative process needs both (cf. the Double Diamond, Osborn-Parnes CPS): diverge wide, *then* converge to a choice.
|
||||
|
||||
**Where the catalog stands.** All 100 methods are divergent. `SKILL.md` explicitly enforces divergence ("resist concluding… the urge to organize is the enemy of divergence"), and the only convergent-flavored technique is Quantum → *Superposition Collapse*. Synthesis is deferred entirely to `references/finalize.md` at wrap-up.
|
||||
|
||||
**Is that a mistake?** Mostly a *good instinct taken to a defensible extreme.* Separating generation from judgment is the foundational brainstorming rule — premature convergence is the #1 killer of ideas, so a divergence-pure generator is legitimate. But the consequence is that the user has **no technique to pick when they're ready to narrow** — they hit "100 ideas" and the tool's stance is "keep going," with only the wrap-up doing light synthesis. For project/feature/life-decision work especially, people *do* want to land.
|
||||
|
||||
**Recommendation — add a small, fenced convergence set, never mixed into the divergent flow.** Keep divergence pure during generation; offer convergence only at wrap-up or on explicit request ("okay, help me narrow"). Concretely: a new `converge` category (4 methods, §6), tagged `mechanism=convergence`, surfaced by `finalize.md` / on demand — not in the default 3–4 sweet-spot batch. This completes the loop while honoring the separate-generation-from-judgment principle. **This is a philosophy decision for you to confirm** — it's the one recommendation that changes what the skill *is*, not just what's in the library.
|
||||
|
||||
---
|
||||
|
||||
## 6. Proposed new methods (fill the thin cells)
|
||||
|
||||
Targeting the under-served mechanisms (§3b), the empty convergence cell (§5), and the goal gaps (§3c). CSV-style (`category, name, description`) so they can drop straight in:
|
||||
|
||||
**Feature/product & enterprise gaps (mechanism: questioning/decomposition):**
|
||||
- `structured, Job to Be Done, "Ask what the user is really hiring this to do; brainstorm around that underlying job, not the feature you assumed"`
|
||||
- `structured, Empathy Map, "Map what the user says, thinks, does, and feels around the problem; mine each quadrant for the unmet need hiding there"`
|
||||
- `deep, Follow the Anomaly, "Start from one surprising number or outlier and ideate only from what would explain it or exploit it"`
|
||||
|
||||
**Strengths-based (the missing positive frame — Appreciative Inquiry is a glaring classic-tier omission):**
|
||||
- `deep, Build on What Works, "Name what's already succeeding and why, then ideate how to amplify and extend it instead of fixing what's broken"`
|
||||
|
||||
**Convergence set (new `converge` category — only if §5 is adopted):**
|
||||
- `converge, Impact Effort Triage, "Plot every idea by impact against effort; harvest the high-impact, low-effort quadrant first and quarantine the rest"`
|
||||
- `converge, Forced Ranking, "Make the ideas fight: each must beat another to survive to a ranked top-N, no ties allowed"`
|
||||
- `converge, NUF Test, "Score each idea New, Useful, Feasible 1-10; the totals expose the quiet winners and the dazzling dead-ends"`
|
||||
- `converge, Affinity Clustering, "Group the raw ideas into themes, name each cluster, then ideate fresh at the theme level"`
|
||||
|
||||
(Optional, lower priority: `structured, Storyboarding` for sequenced/experience ideation.)
|
||||
|
||||
---
|
||||
|
||||
## 7. Category roster & ordering recommendations
|
||||
|
||||
**Ordering (replace alphabetical with a deliberate progression):** add a `CATEGORY_ORDER` + `GROUP` map in `brain.py` (mirroring the existing `_HUES` map — derived for the shipped set, alphabetical fallback for custom catalogs). Proposed super-groups, in order:
|
||||
|
||||
1. **Proven & Professional** — the `classic` lead section (§3a, Option A)
|
||||
2. **Structured & Analytical** — structured, deep
|
||||
3. **Creative & Generative** — creative, biomimetic, cultural, speculative_future, quantum
|
||||
4. **Wild & Playful** — wild, absurdist, theatrical, constraint
|
||||
5. **Introspective & Personal** — introspective_delight, collaborative
|
||||
6. **Decide & Converge** — converge *(if §5 adopted)*
|
||||
|
||||
**Roster notes:**
|
||||
- No category should be deleted. The overlap (§3b) is intentional costume variety.
|
||||
- `quantum` and `cultural` are the most abstract/uneven — a couple of their members (Field Lines, Observer Effect) are the vaguest in the whole set; anchor per §3e rather than cut.
|
||||
- `constraint` is excellent and tight — leave as is.
|
||||
|
||||
---
|
||||
|
||||
## 8. Per-category "invent in the spirit of this category"
|
||||
|
||||
You asked whether each category should also offer an on-the-fly invented technique in its own spirit. **Yes — but don't add 13 near-duplicate rows to the CSV.** The composer already has a global **Invent N** stepper, and `brain.py` already generates section markup from the catalog. So:
|
||||
|
||||
> Have `brain.py` append **one synthetic card per category section** — a dashed "✨ Invent a *{Category}* technique" card. Selecting it emits a paste directive like `invent 1 (in the spirit of {category})`, reused by the existing Inventive-Flow plumbing in `SKILL.md` (which already handles `invent N` and offering keepers to `additional_techniques`).
|
||||
|
||||
Benefits: CSV stays a clean library of *real* techniques; behavior is consistent everywhere; it leverages plumbing that already exists; and it gives the user the "surprise me, but on-theme" affordance per category without library bloat.
|
||||
|
||||
---
|
||||
|
||||
## 9. Open decisions for BMad (in priority order)
|
||||
|
||||
1. **Goal-affinity layer** — adopt the `goals` column + recommendation routing? (Highest impact.)
|
||||
2. **Proven & Professional grouping** — Option A (tag + generated lead section, recommended), B, or C? (§3a)
|
||||
3. **Convergence** — add the fenced `converge` set, or stay divergence-pure? (§5 — philosophy decision.)
|
||||
4. **New methods** — approve the §6 set? Which ones?
|
||||
5. **Per-category invent card** — approve the generated-card approach? (§8)
|
||||
6. **Description anchoring** — approve the targeted ~12 (incl. collaborative fix), keep everything else terse? (§3e)
|
||||
7. **Category ordering / super-groups** — adopt §7?
|
||||
|
||||
Once you mark these, the implementation is: extend the CSV schema (`provenance`, `good_for`, `audience` columns — additive, backward-compatible with `brain.py`'s `DictReader`), add the ordering/grouping + synthetic-card logic to `brain.py`, regenerate `brain-selector.html`, update the relevant `SKILL.md` / `references/*` flow, and run `scripts/tests/`.
|
||||
|
||||
---
|
||||
|
||||
## 10. Revised convergence architecture (per BMad direction)
|
||||
|
||||
**Decision locked:** convergence is **not** a CSV category of selectable cards. It's a **reference phase**, mirroring `references/finalize.md`. The catalog stays a pure *divergent* library; convergence lives in `references/converge.md`.
|
||||
|
||||
**Flow:** diverge (pick & run techniques) → **converge** (`references/converge.md`, on demand or once divergence is spent) → **finalize** (`references/finalize.md`, last). The coach already does ad-hoc convergence implicitly; this makes it an explicit, repeatable phase, and `converge.md` ends by instructing the coach to load `finalize.md` to synthesize and produce artifacts.
|
||||
|
||||
`references/converge.md` contents — a tight set of real, established convergence moves (the coach picks what fits, never dumps a menu):
|
||||
|
||||
- **Affinity Clustering (KJ method)** — group the raw ideas into themes, name each cluster, surface the through-line.
|
||||
- **Dot Voting / Multivoting** — heat-map the favorites; discuss why the hot spots are hot.
|
||||
- **Impact–Effort Matrix** — plot each idea on impact vs effort; harvest high-impact/low-effort first.
|
||||
- **NUF Test** — score New, Useful, Feasible (1–10 each); totals expose quiet winners and dazzling dead-ends.
|
||||
- **PMI (Plus / Minus / Interesting)** — de Bono's fast evaluator for pressure-testing a single strong candidate.
|
||||
- *(optional)* **MoSCoW** (Must/Should/Could/Won't) for product scoping; **Nominal Group Technique** when it's genuinely a group.
|
||||
|
||||
`SKILL.md` change: at the point where a divergent batch is spent, offer "keep diverging / converge & decide / wrap up" — "converge & decide" loads `converge.md`; wrap-up still goes to `finalize.md`.
|
||||
|
||||
## 11. Researched gap-filling additions (real, established methods)
|
||||
|
||||
Web-researched (sources below), chosen to fill the **thin mechanism cells** (questioning, diagnosis, time-shift, empathy) — *not* the over-served spines — and all `classic`-tier, so they also strengthen the "Proven & Professional" group. CSV-style, ready to drop in:
|
||||
|
||||
| Category | Technique | Gist (house style) | Fills |
|
||||
|---|---|---|---|
|
||||
| structured | **How Might We** | "Reframe the problem as a batch of 'How might we…' opportunity questions first, then ideate against the sharpest one" | questioning / problem-framing (design-thinking staple, currently absent) |
|
||||
| deep | **TRIZ Contradiction** | "Name the core contradiction — what only improves by making something else worse — then brainstorm ways to win both instead of trading off" | engineering/feature (no systematic technical method today) |
|
||||
| deep | **Fishbone Diagram** | "Branch the problem's spine into cause categories — people, process, tools, environment — and mine each bone for contributing causes" | diagnosis (named classic complementing Five Whys / Causal Loop) |
|
||||
| structured | **Backcasting** | "Fix the finished future in vivid detail, then work backward step by step to the one move you'd have to make first" | strategy/planning time-shift (serious counterpart to playful future methods) |
|
||||
| speculative_future | **Scenario Cross** | "Pick two high-impact uncertainties, cross them into four futures, and ideate the move that wins in every one" | strategy (2×2 scenario planning — the serious sibling of the playful speculative set) |
|
||||
| structured | **Job to Be Done** | "Ask what the user is really hiring this to do, then ideate around that underlying job, not the feature you assumed" | feature/empathy (enterprise staple) |
|
||||
| structured | **Empathy Map** | "Map what the user says, thinks, does, and feels around the problem; mine each quadrant for the unmet need" | empathy/feature |
|
||||
| deep | **Build on What Works** | "Name what's already succeeding and why, then ideate how to amplify and extend it instead of fixing what's broken" | strengths-based (Appreciative Inquiry — a glaring classic-tier omission) |
|
||||
|
||||
Deliberately **not** added (would deepen an already over-served spine or duplicate): Synectics (≈ analogy/metaphor), SWOT (analysis, not ideation), Rolestorming (≈ Role Playing), Brainwalking/Braindumping (≈ Brainwriting), Pre-mortem (≈ Failure Analysis).
|
||||
|
||||
**Sources:** [IxDF — essential ideation techniques](https://ixdf.org/literature/article/introduction-to-the-essential-ideation-techniques-which-are-the-heart-of-design-thinking) · [Quality Magazine — TRIZ](https://www.qualitymag.com/articles/98566-triz-the-backbone-of-innovation-and-problem-solving) · [ASQ — Fishbone/Ishikawa](https://asq.org/quality-resources/fishbone) · [Futures Platform — 2×2 scenario matrix](https://www.futuresplatform.com/blog/2x2-scenario-planning-matrix-guideline) · [NN/g — Dot Voting](https://www.nngroup.com/articles/dot-voting/) · [Quality Gurus — divergent vs convergent](https://www.qualitygurus.com/divergent-vs-convergent-thinking/)
|
||||
@@ -1,109 +0,0 @@
|
||||
category,technique,provenance,mechanism_primary,mechanism_secondary,goal_affinity,audience
|
||||
collaborative,Yes And Building,classic,combination,perspective,novel|unstuck|planning,group
|
||||
collaborative,Brain Writing Round Robin,classic,combination,decomposition,novel|feature,group
|
||||
collaborative,Random Stimulation,classic,analogy,,unstuck|novel,either
|
||||
collaborative,Role Playing,classic,perspective,,strategy|personal|feature,either
|
||||
collaborative,Ideation Relay Race,playful,combination,,unstuck,group
|
||||
collaborative,Idea Hot Potato,playful,combination,,unstuck,group
|
||||
collaborative,Steal And Upgrade,signature,combination,analogy,novel|unstuck,group
|
||||
collaborative,Fold The Paper,playful,combination,,unstuck|novel,group
|
||||
creative,What If Scenarios,signature,constraint,,novel|strategy|unstuck,either
|
||||
creative,Analogical Thinking,signature,analogy,,feature|novel|diagnosis,either
|
||||
creative,First Principles Thinking,classic,decomposition,,feature|novel|diagnosis|strategy,either
|
||||
creative,Forced Relationships,signature,combination,analogy,novel|unstuck,either
|
||||
creative,Time Shifting,signature,time-shift,perspective,novel|unstuck,either
|
||||
creative,Metaphor Mapping,signature,analogy,,novel|diagnosis,either
|
||||
creative,Cross-Pollination,signature,analogy,,novel|feature|strategy,either
|
||||
creative,Concept Blending,signature,combination,,novel,either
|
||||
creative,Reverse Brainstorming,classic,inversion,,diagnosis|feature|unstuck,either
|
||||
creative,Sensory Exploration,signature,sensory,,novel|unstuck,either
|
||||
deep,Five Whys,classic,questioning,,diagnosis,either
|
||||
deep,Provocation Technique,classic,provocation,inversion,unstuck|novel,either
|
||||
deep,Assumption Reversal,classic,inversion,,novel|diagnosis|strategy,either
|
||||
deep,Question Storming,classic,questioning,,diagnosis|strategy|unstuck,either
|
||||
deep,Constraint Mapping,signature,constraint,decomposition,feature|strategy|diagnosis,either
|
||||
deep,Failure Analysis,signature,inversion,diagnosis,diagnosis|strategy|feature,either
|
||||
deep,Emergent Thinking,signature,systems,,strategy|novel,either
|
||||
deep,Causal Loop Mapping,classic,systems,,diagnosis|strategy,either
|
||||
deep,Morphological Analysis,classic,decomposition,combination,feature|novel|planning,either
|
||||
deep,Laddering,classic,questioning,decomposition,personal|strategy|diagnosis,either
|
||||
introspective_delight,Inner Child Conference,signature,perspective,sensory,personal|unstuck,solo
|
||||
introspective_delight,Shadow Work Mining,signature,sensory,,personal|diagnosis,solo
|
||||
introspective_delight,Values Archaeology,signature,questioning,,personal|strategy,solo
|
||||
introspective_delight,Future Self Interview,signature,perspective,time-shift,personal,solo
|
||||
introspective_delight,Body Wisdom Dialogue,signature,sensory,,personal,solo
|
||||
introspective_delight,Permission Giving,signature,provocation,constraint,personal|unstuck,solo
|
||||
introspective_delight,Secret Wish Confession,signature,sensory,,personal,solo
|
||||
introspective_delight,Mood Weather Report,signature,sensory,,personal|unstuck,solo
|
||||
structured,SCAMPER Method,classic,combination,decomposition,feature|novel,either
|
||||
structured,Six Thinking Hats,classic,perspective,,strategy|diagnosis|planning|personal,either
|
||||
structured,Decision Tree Mapping,signature,decomposition,,planning|strategy|diagnosis,either
|
||||
structured,Solution Matrix,signature,decomposition,,feature|planning,either
|
||||
structured,Trait Transfer,signature,analogy,,novel|feature,either
|
||||
structured,Lotus Blossom,classic,decomposition,,feature|planning|novel,either
|
||||
structured,Worst Possible Idea,classic,inversion,,unstuck|novel,either
|
||||
structured,Disney Method,classic,perspective,,feature|strategy|planning,either
|
||||
structured,Starbursting,classic,questioning,,feature|planning|diagnosis,either
|
||||
structured,Mind Mapping,classic,decomposition,,planning|novel|feature,either
|
||||
structured,Crazy 8s,classic,combination,,feature|novel|unstuck,either
|
||||
theatrical,Time Travel Talk Show,playful,perspective,time-shift,novel|personal,either
|
||||
theatrical,Alien Anthropologist,playful,perspective,,diagnosis|unstuck|strategy,either
|
||||
theatrical,Dream Fusion Laboratory,signature,constraint,time-shift,novel|unstuck,either
|
||||
theatrical,Emotion Orchestra,playful,sensory,perspective,personal|strategy,either
|
||||
theatrical,Parallel Universe Cafe,playful,constraint,,novel|unstuck,either
|
||||
theatrical,Persona Journey,signature,perspective,,feature|strategy,either
|
||||
theatrical,Devil's Advocate Courtroom,signature,inversion,perspective,strategy|diagnosis,group
|
||||
wild,Chaos Engineering,signature,inversion,constraint,feature|diagnosis|strategy,either
|
||||
wild,Guerrilla Gardening Ideas,playful,analogy,,strategy|unstuck,either
|
||||
wild,Pirate Code Brainstorm,playful,combination,analogy,novel|unstuck,either
|
||||
wild,Zombie Apocalypse Planning,playful,constraint,,feature|strategy|unstuck,either
|
||||
wild,Drunk History Retelling,playful,perspective,,unstuck|diagnosis,either
|
||||
wild,Anti-Solution,signature,inversion,,diagnosis|unstuck,either
|
||||
wild,Elemental Forces,playful,perspective,analogy,novel|unstuck,either
|
||||
biomimetic,Nature's Solutions,signature,analogy,,feature|novel,either
|
||||
biomimetic,Ecosystem Thinking,signature,systems,,strategy|diagnosis,either
|
||||
biomimetic,Evolutionary Pressure,signature,systems,,feature|novel,either
|
||||
biomimetic,Predator & Prey,signature,perspective,inversion,strategy|feature,either
|
||||
biomimetic,Metamorphosis Stages,signature,time-shift,decomposition,novel|strategy,either
|
||||
biomimetic,Swarm Logic,signature,systems,,feature|strategy,either
|
||||
quantum,Observer Effect,signature,systems,perspective,strategy|diagnosis,either
|
||||
quantum,Entanglement Thinking,signature,systems,,diagnosis|strategy,either
|
||||
quantum,Superposition Collapse,signature,convergence,decomposition,strategy|diagnosis,either
|
||||
quantum,Relativity Frame Shift,signature,perspective,,strategy|novel,either
|
||||
quantum,Field Lines,signature,systems,,strategy,either
|
||||
quantum,Quantum Tunneling,signature,constraint,,unstuck|novel,either
|
||||
cultural,Indigenous Wisdom,signature,perspective,analogy,personal|strategy|novel,either
|
||||
cultural,Fusion Cuisine,signature,combination,analogy,novel,either
|
||||
cultural,Ritual Innovation,signature,analogy,,novel|personal,either
|
||||
cultural,Mythic Frameworks,signature,analogy,perspective,strategy|personal|novel,either
|
||||
cultural,Proverb Mining,signature,analogy,,personal|strategy,either
|
||||
cultural,Ancestor Council,signature,perspective,,personal|strategy,either
|
||||
cultural,Trickster's Gambit,playful,inversion,provocation,unstuck|strategy,either
|
||||
absurdist,Villain's Monologue,playful,inversion,perspective,diagnosis|strategy|unstuck,either
|
||||
absurdist,Explain It to a Golden Retriever,playful,perspective,,unstuck|diagnosis|feature,either
|
||||
absurdist,Infomercial at 3AM,playful,perspective,,strategy|novel,either
|
||||
absurdist,Drunk Uncle at Thanksgiving,playful,perspective,,unstuck|diagnosis,either
|
||||
absurdist,Cursed Genie,playful,inversion,,diagnosis|feature,either
|
||||
absurdist,Three Rounds of Stupid,playful,provocation,,unstuck|novel,either
|
||||
constraint,Kill the Crown Jewel,signature,constraint,,feature|strategy|unstuck,either
|
||||
constraint,1000x Budget,signature,constraint,,novel|strategy,either
|
||||
constraint,Ship in 60 Minutes,signature,constraint,,feature|planning|unstuck,either
|
||||
constraint,The $0 Mandate,signature,constraint,,planning|strategy|feature,either
|
||||
constraint,One Feature Only,signature,constraint,,feature|strategy,either
|
||||
constraint,Crank the Dial to 11,signature,constraint,,novel|unstuck,either
|
||||
constraint,Constraint Roulette,signature,constraint,,unstuck|feature,either
|
||||
speculative_future,Time Horizon Ladder,signature,time-shift,,strategy|planning|novel,either
|
||||
speculative_future,Post-Scarcity Test,signature,constraint,,novel|strategy,either
|
||||
speculative_future,Utopia vs Dystopia Split-Screen,signature,perspective,inversion,strategy|diagnosis,either
|
||||
speculative_future,Sci-Fi Artifact From the Future,signature,time-shift,perspective,novel|feature,either
|
||||
speculative_future,Emerging Tech Collision,signature,combination,,novel|feature|strategy,either
|
||||
speculative_future,What-If-The-World-Changed Card Flip,signature,constraint,,novel|unstuck,either
|
||||
speculative_future,Future Anthropologist Dig,signature,time-shift,perspective,strategy|novel,either
|
||||
structured,How Might We,classic,questioning,,feature|novel|strategy|diagnosis,either
|
||||
structured,Job to Be Done,classic,perspective,questioning,feature|strategy|novel,either
|
||||
structured,Empathy Map,classic,perspective,,feature|personal,either
|
||||
structured,Backcasting,classic,time-shift,,strategy|planning|novel,either
|
||||
deep,TRIZ Contradiction,classic,inversion,decomposition,feature|novel|diagnosis,either
|
||||
deep,Fishbone Diagram,classic,decomposition,systems,diagnosis,either
|
||||
deep,Build on What Works,classic,perspective,systems,personal|strategy,either
|
||||
speculative_future,Scenario Cross,classic,constraint,systems,strategy|planning,either
|
||||
|
@@ -31,7 +31,7 @@ Load `_bmad/config.toml` and `_bmad/config.user.toml` from `{project-root}` for
|
||||
## Step 2: Discovery
|
||||
|
||||
```
|
||||
python3 {skill-root}/scripts/list_customizable_skills.py --project-root {project-root}
|
||||
uv run {skill-root}/scripts/list_customizable_skills.py --project-root {project-root}
|
||||
```
|
||||
|
||||
Use `--extra-root <path>` (repeatable) if the user has skills installed in additional locations.
|
||||
@@ -87,7 +87,7 @@ Default by character (policy → team, personal → user), confirm before writin
|
||||
3. Write. Create `{project-root}/_bmad/custom/` if needed.
|
||||
4. Verify:
|
||||
```
|
||||
python3 {project-root}/_bmad/scripts/resolve_customization.py --skill <install-path> --key <agent-or-workflow>
|
||||
uv run {project-root}/_bmad/scripts/resolve_customization.py --skill <install-path> --key <agent-or-workflow>
|
||||
```
|
||||
Show the merged output, point out the changed fields.
|
||||
|
||||
|
||||
@@ -1,86 +1,6 @@
|
||||
---
|
||||
name: bmad-editorial-review-prose
|
||||
description: 'Clinical copy-editor that reviews text for communication issues. Use when user says review for prose or improve the prose'
|
||||
description: 'Deprecated — forwards to bmad-editorial-review.'
|
||||
---
|
||||
|
||||
# Editorial Review - Prose
|
||||
|
||||
**Goal:** Review text for communication issues that impede comprehension and output suggested fixes in a three-column table.
|
||||
|
||||
**Your Role:** You are a clinical copy-editor: precise, professional, neither warm nor cynical. Apply Microsoft Writing Style Guide principles as your baseline. Focus on communication issues that impede comprehension — not style preferences. NEVER rewrite for preference — only fix genuine issues. Follow ALL steps in the STEPS section IN EXACT ORDER. DO NOT skip steps or change the sequence. HALT immediately when halt-conditions are met. Each action within a step is a REQUIRED action to complete that step.
|
||||
|
||||
**CONTENT IS SACROSANCT:** Never challenge ideas — only clarify how they're expressed.
|
||||
|
||||
**Inputs:**
|
||||
- **content** (required) — Cohesive unit of text to review (markdown, plain text, or text-heavy XML)
|
||||
- **style_guide** (optional) — Project-specific style guide. When provided, overrides all generic principles in this task (except CONTENT IS SACROSANCT). The style guide is the final authority on tone, structure, and language choices.
|
||||
- **reader_type** (optional, default: `humans`) — `humans` for standard editorial, `llm` for precision focus
|
||||
|
||||
|
||||
## PRINCIPLES
|
||||
|
||||
1. **Minimal intervention:** Apply the smallest fix that achieves clarity
|
||||
2. **Preserve structure:** Fix prose within existing structure, never restructure
|
||||
3. **Skip code/markup:** Detect and skip code blocks, frontmatter, structural markup
|
||||
4. **When uncertain:** Flag with a query rather than suggesting a definitive change
|
||||
5. **Deduplicate:** Same issue in multiple places = one entry with locations listed
|
||||
6. **No conflicts:** Merge overlapping fixes into single entries
|
||||
7. **Respect author voice:** Preserve intentional stylistic choices
|
||||
|
||||
> **STYLE GUIDE OVERRIDE:** If a style_guide input is provided, it overrides ALL generic principles in this task (including the Microsoft Writing Style Guide baseline and reader_type-specific priorities). The ONLY exception is CONTENT IS SACROSANCT — never change what ideas say, only how they're expressed. When style guide conflicts with this task, style guide wins.
|
||||
|
||||
|
||||
## STEPS
|
||||
|
||||
### Step 1: Validate Input
|
||||
|
||||
- Check if content is empty or contains fewer than 3 words
|
||||
- If empty or fewer than 3 words: **HALT** with error: "Content too short for editorial review (minimum 3 words required)"
|
||||
- Validate reader_type is `humans` or `llm` (or not provided, defaulting to `humans`)
|
||||
- If reader_type is invalid: **HALT** with error: "Invalid reader_type. Must be 'humans' or 'llm'"
|
||||
- Identify content type (markdown, plain text, XML with text)
|
||||
- Note any code blocks, frontmatter, or structural markup to skip
|
||||
|
||||
### Step 2: Analyze Style
|
||||
|
||||
- Analyze the style, tone, and voice of the input text
|
||||
- Note any intentional stylistic choices to preserve (informal tone, technical jargon, rhetorical patterns)
|
||||
- Calibrate review approach based on reader_type:
|
||||
- If `llm`: Prioritize unambiguous references, consistent terminology, explicit structure, no hedging
|
||||
- If `humans`: Prioritize clarity, flow, readability, natural progression
|
||||
|
||||
### Step 3: Editorial Review (CRITICAL)
|
||||
|
||||
- If style_guide provided: Consult style_guide now and note its key requirements — these override default principles for this review
|
||||
- Review all prose sections (skip code blocks, frontmatter, structural markup)
|
||||
- Identify communication issues that impede comprehension
|
||||
- For each issue, determine the minimal fix that achieves clarity
|
||||
- Deduplicate: If same issue appears multiple times, create one entry listing all locations
|
||||
- Merge overlapping issues into single entries (no conflicting suggestions)
|
||||
- For uncertain fixes, phrase as query: "Consider: [suggestion]?" rather than definitive change
|
||||
- Preserve author voice — do not "improve" intentional stylistic choices
|
||||
|
||||
### Step 4: Output Results
|
||||
|
||||
- If issues found: Output a three-column markdown table with all suggested fixes
|
||||
- If no issues found: Output "No editorial issues identified"
|
||||
|
||||
**Output format:**
|
||||
|
||||
| Original Text | Revised Text | Changes |
|
||||
|---------------|--------------|---------|
|
||||
| The exact original passage | The suggested revision | Brief explanation of what changed and why |
|
||||
|
||||
**Example:**
|
||||
|
||||
| Original Text | Revised Text | Changes |
|
||||
|---------------|--------------|---------|
|
||||
| The system will processes data and it handles errors. | The system processes data and handles errors. | Fixed subject-verb agreement ("will processes" to "processes"); removed redundant "it" |
|
||||
| Users can chose from options (lines 12, 45, 78) | Users can choose from options | Fixed spelling: "chose" to "choose" (appears in 3 locations) |
|
||||
|
||||
|
||||
## HALT CONDITIONS
|
||||
|
||||
- HALT with error if content is empty or fewer than 3 words
|
||||
- HALT with error if reader_type is not `humans` or `llm`
|
||||
- If no issues found after thorough review, output "No editorial issues identified" (this is valid completion, not an error)
|
||||
Invoke `bmad-editorial-review` in prose-only mode with the same target and inputs.
|
||||
|
||||
@@ -1,179 +1,6 @@
|
||||
---
|
||||
name: bmad-editorial-review-structure
|
||||
description: 'Structural editor that proposes cuts, reorganization, and simplification while preserving comprehension. Use when user requests structural review or editorial review of structure'
|
||||
description: 'Deprecated — forwards to bmad-editorial-review.'
|
||||
---
|
||||
|
||||
# Editorial Review - Structure
|
||||
|
||||
**Goal:** Review document structure and propose substantive changes to improve clarity and flow -- run this BEFORE copy editing.
|
||||
|
||||
**Your Role:** You are a structural editor focused on HIGH-VALUE DENSITY. Brevity IS clarity: concise writing respects limited attention spans and enables effective scanning. Every section must justify its existence -- cut anything that delays understanding. True redundancy is failure. Follow ALL steps in the STEPS section IN EXACT ORDER. DO NOT skip steps or change the sequence. HALT immediately when halt-conditions are met. Each action within a step is a REQUIRED action to complete that step.
|
||||
|
||||
> **STYLE GUIDE OVERRIDE:** If a style_guide input is provided, it overrides ALL generic principles in this task (including human-reader-principles, llm-reader-principles, reader_type-specific priorities, structure-models selection, and the Microsoft Writing Style Guide baseline). The ONLY exception is CONTENT IS SACROSANCT -- never change what ideas say, only how they're expressed. When style guide conflicts with this task, style guide wins.
|
||||
|
||||
**Inputs:**
|
||||
- **content** (required) -- Document to review (markdown, plain text, or structured content)
|
||||
- **style_guide** (optional) -- Project-specific style guide. When provided, overrides all generic principles in this task (except CONTENT IS SACROSANCT). The style guide is the final authority on tone, structure, and language choices.
|
||||
- **purpose** (optional) -- Document's intended purpose (e.g., 'quickstart tutorial', 'API reference', 'conceptual overview')
|
||||
- **target_audience** (optional) -- Who reads this? (e.g., 'new users', 'experienced developers', 'decision makers')
|
||||
- **reader_type** (optional, default: "humans") -- 'humans' (default) preserves comprehension aids; 'llm' optimizes for precision and density
|
||||
- **length_target** (optional) -- Target reduction (e.g., '30% shorter', 'half the length', 'no limit')
|
||||
|
||||
## Principles
|
||||
|
||||
- Comprehension through calibration: Optimize for the minimum words needed to maintain understanding
|
||||
- Front-load value: Critical information comes first; nice-to-know comes last (or goes)
|
||||
- One source of truth: If information appears identically twice, consolidate
|
||||
- Scope discipline: Content that belongs in a different document should be cut or linked
|
||||
- Propose, don't execute: Output recommendations -- user decides what to accept
|
||||
- **CONTENT IS SACROSANCT: Never challenge ideas -- only optimize how they're organized.**
|
||||
|
||||
## Human-Reader Principles
|
||||
|
||||
These elements serve human comprehension and engagement -- preserve unless clearly wasteful:
|
||||
|
||||
- Visual aids: Diagrams, images, and flowcharts anchor understanding
|
||||
- Expectation-setting: "What You'll Learn" helps readers confirm they're in the right place
|
||||
- Reader's Journey: Organize content biologically (linear progression), not logically (database)
|
||||
- Mental models: Overview before details prevents cognitive overload
|
||||
- Warmth: Encouraging tone reduces anxiety for new users
|
||||
- Whitespace: Admonitions and callouts provide visual breathing room
|
||||
- Summaries: Recaps help retention; they're reinforcement, not redundancy
|
||||
- Examples: Concrete illustrations make abstract concepts accessible
|
||||
- Engagement: "Flow" techniques (transitions, variety) are functional, not "fluff" -- they maintain attention
|
||||
|
||||
## LLM-Reader Principles
|
||||
|
||||
When reader_type='llm', optimize for PRECISION and UNAMBIGUITY:
|
||||
|
||||
- Dependency-first: Define concepts before usage to minimize hallucination risk
|
||||
- Cut emotional language, encouragement, and orientation sections
|
||||
- IF concept is well-known from training (e.g., "conventional commits", "REST APIs"): Reference the standard -- don't re-teach it. ELSE: Be explicit -- don't assume the LLM will infer correctly.
|
||||
- Use consistent terminology -- same word for same concept throughout
|
||||
- Eliminate hedging ("might", "could", "generally") -- use direct statements
|
||||
- Prefer structured formats (tables, lists, YAML) over prose
|
||||
- Reference known standards ("conventional commits", "Google style guide") to leverage training
|
||||
- STILL PROVIDE EXAMPLES even for known standards -- grounds the LLM in your specific expectation
|
||||
- Unambiguous references -- no unclear antecedents ("it", "this", "the above")
|
||||
- Note: LLM documents may be LONGER than human docs in some areas (more explicit) while shorter in others (no warmth)
|
||||
|
||||
## Structure Models
|
||||
|
||||
### Tutorial/Guide (Linear)
|
||||
**Applicability:** Tutorials, detailed guides, how-to articles, walkthroughs
|
||||
- Prerequisites: Setup/Context MUST precede action
|
||||
- Sequence: Steps must follow strict chronological or logical dependency order
|
||||
- Goal-oriented: clear 'Definition of Done' at the end
|
||||
|
||||
### Reference/Database
|
||||
**Applicability:** API docs, glossaries, configuration references, cheat sheets
|
||||
- Random Access: No narrative flow required; user jumps to specific item
|
||||
- MECE: Topics are Mutually Exclusive and Collectively Exhaustive
|
||||
- Consistent Schema: Every item follows identical structure (e.g., Signature to Params to Returns)
|
||||
|
||||
### Explanation (Conceptual)
|
||||
**Applicability:** Deep dives, architecture overviews, conceptual guides, whitepapers, project context
|
||||
- Abstract to Concrete: Definition to Context to Implementation/Example
|
||||
- Scaffolding: Complex ideas built on established foundations
|
||||
|
||||
### Prompt/Task Definition (Functional)
|
||||
**Applicability:** BMAD tasks, prompts, system instructions, XML definitions
|
||||
- Meta-first: Inputs, usage constraints, and context defined before instructions
|
||||
- Separation of Concerns: Instructions (logic) separate from Data (content)
|
||||
- Step-by-step: Execution flow must be explicit and ordered
|
||||
|
||||
### Strategic/Context (Pyramid)
|
||||
**Applicability:** PRDs, research reports, proposals, decision records
|
||||
- Top-down: Conclusion/Status/Recommendation starts the document
|
||||
- Grouping: Supporting context grouped logically below the headline
|
||||
- Ordering: Most critical information first
|
||||
- MECE: Arguments/Groups are Mutually Exclusive and Collectively Exhaustive
|
||||
- Evidence: Data supports arguments, never leads
|
||||
|
||||
## STEPS
|
||||
|
||||
### Step 1: Validate Input
|
||||
|
||||
- Check if content is empty or contains fewer than 3 words
|
||||
- If empty or fewer than 3 words, HALT with error: "Content too short for substantive review (minimum 3 words required)"
|
||||
- Validate reader_type is "humans" or "llm" (or not provided, defaulting to "humans")
|
||||
- If reader_type is invalid, HALT with error: "Invalid reader_type. Must be 'humans' or 'llm'"
|
||||
- Identify document type and structure (headings, sections, lists, etc.)
|
||||
- Note the current word count and section count
|
||||
|
||||
### Step 2: Understand Purpose
|
||||
|
||||
- If purpose was provided, use it; otherwise infer from content
|
||||
- If target_audience was provided, use it; otherwise infer from content
|
||||
- Identify the core question the document answers
|
||||
- State in one sentence: "This document exists to help [audience] accomplish [goal]"
|
||||
- Select the most appropriate structural model from Structure Models based on purpose/audience
|
||||
- Note reader_type and which principles apply (Human-Reader Principles or LLM-Reader Principles)
|
||||
|
||||
### Step 3: Structural Analysis (CRITICAL)
|
||||
|
||||
- If style_guide provided, consult style_guide now and note its key requirements -- these override default principles for this analysis
|
||||
- Map the document structure: list each major section with its word count
|
||||
- Evaluate structure against the selected model's primary rules (e.g., 'Does recommendation come first?' for Pyramid)
|
||||
- For each section, answer: Does this directly serve the stated purpose?
|
||||
- If reader_type='humans', for each comprehension aid (visual, summary, example, callout), answer: Does this help readers understand or stay engaged?
|
||||
- Identify sections that could be: cut entirely, merged with another, moved to a different location, or split
|
||||
- Identify true redundancies: identical information repeated without purpose (not summaries or reinforcement)
|
||||
- Identify scope violations: content that belongs in a different document
|
||||
- Identify burying: critical information hidden deep in the document
|
||||
|
||||
### Step 4: Flow Analysis
|
||||
|
||||
- Assess the reader's journey: Does the sequence match how readers will use this?
|
||||
- Identify premature detail: explanation given before the reader needs it
|
||||
- Identify missing scaffolding: complex ideas without adequate setup
|
||||
- Identify anti-patterns: FAQs that should be inline, appendices that should be cut, overviews that repeat the body verbatim
|
||||
- If reader_type='humans', assess pacing: Is there enough whitespace and visual variety to maintain attention?
|
||||
|
||||
### Step 5: Generate Recommendations
|
||||
|
||||
- Compile all findings into prioritized recommendations
|
||||
- Categorize each recommendation: CUT (remove entirely), MERGE (combine sections), MOVE (reorder), CONDENSE (shorten significantly), QUESTION (needs author decision), PRESERVE (explicitly keep -- for elements that might seem cuttable but serve comprehension)
|
||||
- For each recommendation, state the rationale in one sentence
|
||||
- Estimate impact: how many words would this save (or cost, for PRESERVE)?
|
||||
- If length_target was provided, assess whether recommendations meet it
|
||||
- If reader_type='humans' and recommendations would cut comprehension aids, flag with warning: "This cut may impact reader comprehension/engagement"
|
||||
|
||||
### Step 6: Output Results
|
||||
|
||||
- Output document summary (purpose, audience, reader_type, current length)
|
||||
- Output the recommendation list in priority order
|
||||
- Output estimated total reduction if all recommendations accepted
|
||||
- If no recommendations, output: "No substantive changes recommended -- document structure is sound"
|
||||
|
||||
Use the following output format:
|
||||
|
||||
```markdown
|
||||
## Document Summary
|
||||
- **Purpose:** [inferred or provided purpose]
|
||||
- **Audience:** [inferred or provided audience]
|
||||
- **Reader type:** [selected reader type]
|
||||
- **Structure model:** [selected structure model]
|
||||
- **Current length:** [X] words across [Y] sections
|
||||
|
||||
## Recommendations
|
||||
|
||||
### 1. [CUT/MERGE/MOVE/CONDENSE/QUESTION/PRESERVE] - [Section or element name]
|
||||
**Rationale:** [One sentence explanation]
|
||||
**Impact:** ~[X] words
|
||||
**Comprehension note:** [If applicable, note impact on reader understanding]
|
||||
|
||||
### 2. ...
|
||||
|
||||
## Summary
|
||||
- **Total recommendations:** [N]
|
||||
- **Estimated reduction:** [X] words ([Y]% of original)
|
||||
- **Meets length target:** [Yes/No/No target specified]
|
||||
- **Comprehension trade-offs:** [Note any cuts that sacrifice reader engagement for brevity]
|
||||
```
|
||||
|
||||
## HALT CONDITIONS
|
||||
|
||||
- HALT with error if content is empty or fewer than 3 words
|
||||
- HALT with error if reader_type is not "humans" or "llm"
|
||||
- If no structural issues found, output "No substantive changes recommended" (this is valid completion, not an error)
|
||||
Invoke `bmad-editorial-review` in structure-only mode with the same target and inputs.
|
||||
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
name: bmad-editorial-review
|
||||
description: 'Two-pass editorial review of a document — structure then prose. Use when user says "editorial review", "review the structure", or "review the prose".'
|
||||
---
|
||||
|
||||
# Editorial Review
|
||||
|
||||
Review a document as a clinical editor and return suggested fixes the author can accept or reject row by row. Two passes: **structure** (cuts, merges, moves, condensing — does the document's shape serve its purpose?) then **prose** (copy-edit for communication issues that impede comprehension). Run both, structure first, by default; run only one when the user asks for a structure-only or prose-only review.
|
||||
|
||||
**CONTENT IS SACROSANCT.** Never challenge ideas — only how they're organized and expressed. Propose, don't execute: the author decides what to accept.
|
||||
|
||||
The baseline is the Microsoft Writing Style Guide. A provided style guide overrides every generic principle here — including that baseline and the reader calibration — except CONTENT IS SACROSANCT.
|
||||
|
||||
## Conventions
|
||||
|
||||
- Bare paths and `{skill-root}` resolve from this skill's installed directory; `{project-root}` is the project working directory.
|
||||
- `{workflow.<name>}` resolves to fields in `customize.toml`'s `[workflow]` table (overrides win per BMad merge rules).
|
||||
|
||||
## On Activation
|
||||
|
||||
1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. On failure, read `{skill-root}/customize.toml` directly and use defaults.
|
||||
2. Gather inputs: the content (required — a path or pasted text), plus whatever the request states: purpose, target audience, length target, reader type, style guide. Request-level values win; `{workflow.reader_type}` and `{workflow.style_guide}` fill what the request leaves unstated. Treat `{workflow.review_guidance}` entries as standing review directives. In both `style_guide` and `review_guidance`, a value prefixed `file:` is a path — load that file and use its contents.
|
||||
3. Infer purpose and audience from the content when not provided, and open the output with your one-sentence read — "this document exists to help [audience] accomplish [goal]" — so the author can correct a wrong premise before acting on the findings.
|
||||
|
||||
## Reader calibration
|
||||
|
||||
- **humans** (default): clarity, flow, natural progression. Comprehension aids — examples, summaries, visuals, expectation-setting, warmth — are functional, not fluff; preserve them unless clearly wasteful, and flag any recommendation that would cut one.
|
||||
- **llm**: precision and unambiguity. Consistent terminology, dependency-first ordering, no hedging, no unclear antecedents; reference well-known standards instead of re-teaching them, but still ground each with an example. An LLM-targeted document may run longer where explicitness pays and shorter where warmth was cut.
|
||||
|
||||
## Structure pass
|
||||
|
||||
Load `references/structure-models.md`, pick the model matching the document's purpose, and evaluate the document against it. Hunt for: sections that don't serve the stated purpose, true redundancy (identical information with no reinforcement value), scope violations (content that belongs in a different document), buried critical information, premature detail, and missing scaffolding. Brevity is clarity — every section must justify its existence — but comprehension sets the floor: optimize for the minimum words that maintain understanding. Tag each finding CUT, MERGE, MOVE, CONDENSE, QUESTION, or PRESERVE (explicitly keep something that looks cuttable but serves comprehension), and estimate its word impact.
|
||||
|
||||
## Prose pass
|
||||
|
||||
Copy-edit for communication issues that impede comprehension — never rewrite for preference, and apply the smallest fix that achieves clarity. Fix prose within the existing structure (shape problems belong to the structure pass). Skip code blocks, frontmatter, and structural markup. Preserve the author's voice and intentional stylistic choices. Deduplicate: the same issue in several places is one row listing all locations. Phrase uncertain fixes as "Consider: …?" rather than definitive changes.
|
||||
|
||||
## Output
|
||||
|
||||
One findings table serves both passes:
|
||||
|
||||
| Pass | Original Text | Revised Text | Changes |
|
||||
|------|---------------|---------------|---------|
|
||||
| structure | §Setup — full section (~180 words) | MERGE into §Installation | Duplicates the install steps; one source of truth (saves ~150 words) |
|
||||
| prose | The system will processes data and it handles errors. | The system processes data and handles errors. | Fixed subject-verb agreement; removed redundant "it" |
|
||||
|
||||
Structure rows name the section or passage in **Original Text** and carry the tagged disposition (with move target or condensed rewrite) in **Revised Text**; prose rows quote the exact text and its revision. Above the table, give the purpose/audience read plus — when the structure pass ran — the chosen structure model and estimated total reduction. A pass that finds nothing is a valid result; say so. Honor `{workflow.output_preferences}` for where and how findings land; the default is this table in chat.
|
||||
@@ -0,0 +1,46 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-editorial-review.
|
||||
#
|
||||
# Override files (not edited here):
|
||||
# {project-root}/_bmad/custom/bmad-editorial-review.toml (team)
|
||||
# {project-root}/_bmad/custom/bmad-editorial-review.user.toml (personal)
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins • arrays: append
|
||||
|
||||
# Default reader the review calibrates for when the request doesn't say:
|
||||
# "humans" clarity, flow, comprehension aids preserved
|
||||
# "llm" precision, consistent terminology, no hedging
|
||||
# A reader type stated in the request wins for that run.
|
||||
reader_type = "humans"
|
||||
|
||||
# Style guide that overrides the Microsoft Writing Style Guide baseline and
|
||||
# every generic principle in the skill except CONTENT IS SACROSANCT. Either a
|
||||
# `file:`-prefixed path to a style guide document, or the rules inline as text.
|
||||
# Empty = baseline only.
|
||||
#
|
||||
# Examples (set in team/user override TOML):
|
||||
# style_guide = "file:{project-root}/_bmad/style-guides/company-voice.md"
|
||||
# style_guide = "Sentence-case headings. No Oxford comma. Address the reader as 'you'."
|
||||
style_guide = ""
|
||||
|
||||
# Where and how findings land. Freeform directive; empty = present the
|
||||
# findings table in chat.
|
||||
#
|
||||
# Examples:
|
||||
# output_preferences = "Write the findings table to <target>-review.md beside the reviewed document."
|
||||
# output_preferences = "Cap output at the 20 highest-impact findings."
|
||||
output_preferences = ""
|
||||
|
||||
# Standing review directives applied on every run alongside the skill's own
|
||||
# principles. Each entry is a literal sentence or a `file:`-prefixed path/glob
|
||||
# whose contents load as directives.
|
||||
#
|
||||
# Examples:
|
||||
# "Flag passive voice in headings."
|
||||
# "Second-person imperative is the house voice; never suggest changing it."
|
||||
# "file:{project-root}/docs/terminology.md"
|
||||
review_guidance = []
|
||||
@@ -0,0 +1,44 @@
|
||||
# Structure Models
|
||||
|
||||
Reference shapes for the structure pass. Pick the one matching the document's purpose and evaluate the document against its rules; a document that fits none cleanly is judged against the closest model, with the mismatch itself noted as a finding when the shape fights the purpose.
|
||||
|
||||
## Tutorial/Guide (Linear)
|
||||
|
||||
**Applicability:** Tutorials, detailed guides, how-to articles, walkthroughs
|
||||
|
||||
- Prerequisites: setup/context MUST precede action
|
||||
- Sequence: steps follow strict chronological or logical dependency order
|
||||
- Goal-oriented: clear "Definition of Done" at the end
|
||||
|
||||
## Reference/Database
|
||||
|
||||
**Applicability:** API docs, glossaries, configuration references, cheat sheets
|
||||
|
||||
- Random access: no narrative flow required; the reader jumps to a specific item
|
||||
- MECE: topics are Mutually Exclusive and Collectively Exhaustive
|
||||
- Consistent schema: every item follows an identical structure (e.g., Signature → Params → Returns)
|
||||
|
||||
## Explanation (Conceptual)
|
||||
|
||||
**Applicability:** Deep dives, architecture overviews, conceptual guides, whitepapers, project context
|
||||
|
||||
- Abstract to concrete: Definition → Context → Implementation/Example
|
||||
- Scaffolding: complex ideas built on established foundations
|
||||
|
||||
## Prompt/Task Definition (Functional)
|
||||
|
||||
**Applicability:** BMad skills and workflows, prompts, system instructions, agent definitions
|
||||
|
||||
- Meta-first: inputs, usage constraints, and context defined before instructions
|
||||
- Separation of concerns: instructions (logic) separate from data (content)
|
||||
- Explicit flow: execution order is stated, never implied
|
||||
|
||||
## Strategic/Context (Pyramid)
|
||||
|
||||
**Applicability:** PRDs, research reports, proposals, decision records
|
||||
|
||||
- Top-down: conclusion/status/recommendation starts the document
|
||||
- Grouping: supporting context grouped logically below the headline
|
||||
- Ordering: most critical information first
|
||||
- MECE: arguments/groups are Mutually Exclusive and Collectively Exhaustive
|
||||
- Evidence: data supports arguments, never leads
|
||||
@@ -23,7 +23,7 @@ When this skill completes, the user should:
|
||||
## Data Sources
|
||||
|
||||
- **Catalog**: `{project-root}/_bmad/_config/bmad-help.csv` — assembled manifest of all installed module skills
|
||||
- **Config**: Run `uv run --python 3.11 {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root}` and use the merged JSON to resolve `output-location` variables and read `core.communication_language` and `modules.bmm.project_knowledge`. The resolver merges `_bmad/config.toml`, `_bmad/config.user.toml`, `_bmad/custom/config.toml`, and `_bmad/custom/config.user.toml` in that order.
|
||||
- **Config**: Run `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root}` and use the merged JSON to resolve `output-location` variables and read `core.communication_language` and `modules.bmm.project_knowledge`. The resolver merges `_bmad/config.toml`, `_bmad/config.user.toml`, `_bmad/custom/config.toml`, and `_bmad/custom/config.user.toml` in that order.
|
||||
- **Artifacts**: Files matching `outputs` patterns at resolved `output-location` paths reveal which steps are possibly completed; their content may also provide grounding context for recommendations
|
||||
- **Project knowledge**: If `project_knowledge` resolves to an existing path, read it for grounding context. Never fabricate project-specific details.
|
||||
- **Module docs**: Rows with `_meta` in the `skill` column carry a URL or path in `output-location` pointing to the module's documentation (e.g., llms.txt). Fetch and use these to answer general questions about that module.
|
||||
@@ -72,4 +72,5 @@ For each recommended item, present:
|
||||
- Present all output in `{communication_language}`
|
||||
- Recommend running each skill in a **fresh context window**
|
||||
- Match the user's tone — conversational when they're casual, structured when they want specifics
|
||||
- When the user asks for brainstorming, ideation, or other thinking tools that aren't installed, mention that the bmad-analysis pack (brainstorm, pressure-test, multi-perspective) can be added via the installer
|
||||
- If the active module is ambiguous, retrieve all meta rows remote sources to find relevant info also to help answer their question
|
||||
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
name: bmad-index-docs
|
||||
description: 'Generates or updates an index.md to reference all docs in the folder. Use if user requests to create or update an index of all files in a specific folder'
|
||||
---
|
||||
|
||||
# Index Docs
|
||||
|
||||
**Goal:** Generate or update an index.md to reference all docs in a target folder.
|
||||
|
||||
|
||||
## EXECUTION
|
||||
|
||||
### Step 1: Scan Directory
|
||||
|
||||
- List all files and subdirectories in the target location
|
||||
|
||||
### Step 2: Group Content
|
||||
|
||||
- Organize files by type, purpose, or subdirectory
|
||||
|
||||
### Step 3: Generate Descriptions
|
||||
|
||||
- Read each file to understand its actual purpose and create brief (3-10 word) descriptions based on the content, not just the filename
|
||||
|
||||
### Step 4: Create/Update Index
|
||||
|
||||
- Write or update index.md with organized file listings
|
||||
|
||||
|
||||
## OUTPUT FORMAT
|
||||
|
||||
```markdown
|
||||
# Directory Index
|
||||
|
||||
## Files
|
||||
|
||||
- **[filename.ext](./filename.ext)** - Brief description
|
||||
- **[another-file.ext](./another-file.ext)** - Brief description
|
||||
|
||||
## Subdirectories
|
||||
|
||||
### subfolder/
|
||||
|
||||
- **[file1.ext](./subfolder/file1.ext)** - Brief description
|
||||
- **[file2.ext](./subfolder/file2.ext)** - Brief description
|
||||
|
||||
### another-folder/
|
||||
|
||||
- **[file3.ext](./another-folder/file3.ext)** - Brief description
|
||||
```
|
||||
|
||||
|
||||
## HALT CONDITIONS
|
||||
|
||||
- HALT if target directory does not exist or is inaccessible
|
||||
- HALT if user does not have write permissions to create index.md
|
||||
|
||||
|
||||
## VALIDATION
|
||||
|
||||
- Use relative paths starting with ./
|
||||
- Group similar files together
|
||||
- Read file contents to generate accurate descriptions - don't guess from filenames
|
||||
- Keep descriptions concise but informative (3-10 words)
|
||||
- Sort alphabetically within groups
|
||||
- Skip hidden files (starting with .) unless specified
|
||||
@@ -1,37 +1,6 @@
|
||||
---
|
||||
name: bmad-review-adversarial-general
|
||||
description: 'Perform a Cynical Review and produce a findings report. Use when the user requests a critical review of something'
|
||||
description: 'Deprecated — forwards to bmad-review.'
|
||||
---
|
||||
|
||||
# Adversarial Review (General)
|
||||
|
||||
**Goal:** Cynically review content and produce findings.
|
||||
|
||||
**Your Role:** You are a cynical, jaded reviewer with zero patience for sloppy work. The content was submitted by a clueless weasel and you expect to find problems. Be skeptical of everything. Look for what's missing, not just what's wrong. Use a precise, professional tone — no profanity or personal attacks.
|
||||
|
||||
**Inputs:**
|
||||
- **content** — Content to review: diff, spec, story, doc, or any artifact
|
||||
- **also_consider** (optional) — Areas to keep in mind during review alongside normal adversarial analysis
|
||||
|
||||
|
||||
## EXECUTION
|
||||
|
||||
### Step 1: Receive Content
|
||||
|
||||
- Load the content to review from provided input or context
|
||||
- If content to review is empty, ask for clarification and abort
|
||||
- Identify content type (diff, branch, uncommitted changes, document, etc.)
|
||||
|
||||
### Step 2: Adversarial Analysis
|
||||
|
||||
Review with extreme skepticism — assume problems exist. Find at least ten issues to fix or improve in the provided content.
|
||||
|
||||
### Step 3: Present Findings
|
||||
|
||||
Output findings as a Markdown list: descriptions only, no severity, priority, or ranking.
|
||||
|
||||
|
||||
## HALT CONDITIONS
|
||||
|
||||
- HALT if zero findings — this is suspicious, re-analyze or ask for guidance
|
||||
- HALT if content is empty or unreadable
|
||||
Merged into `bmad-review`. Invoke the `bmad-review` skill on the same content with only the `adversarial` lens, passing through any `also_consider` areas. Present the findings as a Markdown list — descriptions only, no severity, priority, or ranking; no JSON block.
|
||||
|
||||
@@ -1,73 +1,6 @@
|
||||
---
|
||||
name: bmad-review-edge-case-hunter
|
||||
description: 'Walk every branching path and boundary condition in content, report only unhandled edge cases. Orthogonal to adversarial review - method-driven not attitude-driven. Use when you need exhaustive edge-case analysis of code, specs, or diffs.'
|
||||
description: 'Deprecated — forwards to bmad-review.'
|
||||
---
|
||||
|
||||
# Edge Case Hunter Review
|
||||
|
||||
**Goal:** You are a pure path tracer. Never comment on whether code is good or bad; only list missing handling.
|
||||
When a diff is provided, scan only the diff hunks and list boundaries that are directly reachable from the changed lines and lack an explicit guard in the diff.
|
||||
When no diff is provided (full file or function), treat the entire provided content as the scope.
|
||||
Ignore the rest of the codebase unless the provided content explicitly references external functions.
|
||||
A brief secondary deletion check runs as Step 4 when the diff removes code.
|
||||
|
||||
**Inputs:**
|
||||
- **content** — Content to review: diff, full file, or function
|
||||
- **also_consider** (optional) — Areas to keep in mind during review alongside normal edge-case analysis
|
||||
|
||||
**MANDATORY: Execute steps in the Execution section IN EXACT ORDER. DO NOT skip steps or change the sequence. When a halt condition triggers, follow its specific instruction exactly. Each action within a step is a REQUIRED action to complete that step.**
|
||||
|
||||
**Your method is exhaustive path enumeration — mechanically walk every branch, not hunt by intuition. Report ONLY paths and conditions that lack handling — discard handled ones silently. Do NOT editorialize or add filler. Do not assign severity labels, rankings, or priority levels.**
|
||||
|
||||
|
||||
## EXECUTION
|
||||
|
||||
### Step 1: Receive Content
|
||||
|
||||
- Load the content to review strictly from provided input
|
||||
- If content is empty, or cannot be decoded as text, return `[{"location":"N/A","trigger_condition":"Input empty or undecodable","guard_snippet":"Provide valid content to review","potential_consequence":"Review skipped — no analysis performed"}]` and stop
|
||||
- Identify content type (diff, full file, or function) to determine scope rules
|
||||
|
||||
### Step 2: Exhaustive Path Analysis
|
||||
|
||||
**Walk every branching path and boundary condition within scope — report only unhandled ones.**
|
||||
|
||||
- If `also_consider` input was provided, incorporate those areas into the analysis
|
||||
- Walk all branching paths: control flow (conditionals, loops, error handlers, early returns) and domain boundaries (where values, states, or conditions transition). Derive the relevant edge classes from the content itself — don't rely on a fixed checklist. Examples: missing else/default, unguarded inputs, off-by-one loops, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
|
||||
- Consider implicit branches: the diff special-cases or changes the handling of one or more members of a fixed set of values — enums, status codes, sentinels, type tags, flags, value ranges. The rest of the set is implicit branches (e.g. the diff changes the `RED` and `YELLOW` cases of a `RED`/`YELLOW`/`GREEN` enum; `GREEN` is the implicit branch)
|
||||
- For each path: determine whether the content handles it
|
||||
- Collect only the unhandled paths as findings — discard handled ones silently
|
||||
|
||||
### Step 3: Validate Completeness
|
||||
|
||||
- Revisit every edge class from Step 2 — e.g., missing else/default, null/empty inputs, off-by-one loops, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
|
||||
- Add any newly found unhandled paths to findings; discard confirmed-handled ones
|
||||
|
||||
### Step 4: Deletion Check
|
||||
|
||||
If the diff removed or replaced meaningful code (ignore pure renames and whitespace): load `references/deletion-check.md` and follow it.
|
||||
|
||||
### Step 5: Present Findings
|
||||
|
||||
Output all findings as a single JSON array following the Output Format specification exactly.
|
||||
|
||||
|
||||
## OUTPUT FORMAT
|
||||
|
||||
Return ONLY a valid JSON array of objects. Each edge-case finding contains exactly these four fields:
|
||||
|
||||
```json
|
||||
[{
|
||||
"location": "file:start-end (or file:line when single line, or file:hunk when exact line unavailable)",
|
||||
"trigger_condition": "one-line description (max 15 words)",
|
||||
"guard_snippet": "minimal code sketch that closes the gap (single-line escaped string, no raw newlines or unescaped quotes)",
|
||||
"potential_consequence": "what could actually go wrong (max 15 words)"
|
||||
}]
|
||||
```
|
||||
|
||||
No extra text, no explanations, no markdown wrapping. An empty array `[]` is valid when nothing is found. Deletion findings from Step 4, if any, go in the same array with the extra fields defined in `references/deletion-check.md`.
|
||||
|
||||
|
||||
## HALT CONDITIONS
|
||||
|
||||
- If content is empty or cannot be decoded as text, return `[{"location":"N/A","trigger_condition":"Input empty or undecodable","guard_snippet":"Provide valid content to review","potential_consequence":"Review skipped — no analysis performed"}]` and stop
|
||||
Merged into `bmad-review`. Invoke the `bmad-review` skill on the same content with only the `edge-case` lens, passing through any `also_consider` areas. Output ONLY the raw findings JSON array in the legacy shape: the four standard fields (plus `kind`/`confidence` on deletion findings), no `lens` field, no markdown wrapping, no extra text. `[]` is valid when nothing is found.
|
||||
|
||||
@@ -1,14 +0,0 @@
|
||||
# Deletion Check
|
||||
|
||||
Secondary pass for the Edge Case Hunter — runs only when the diff removed meaningful code. Subordinate to the edge-case pass; findings are usually few or none.
|
||||
|
||||
For each chunk of removed or replaced code (ignore pure renames and whitespace), ask: did it carry behavior or a contract that the change neither re-established nor intentionally retired? Add a finding for any resulting regression, orphaned reference, or newly-dead code. Skip anything already covered by your edge-case findings.
|
||||
|
||||
Append each finding to the same JSON array as the edge-case findings, with the four standard fields plus:
|
||||
|
||||
- `kind`: `"deletion"`
|
||||
- `confidence`: `"high"`, `"medium"`, or `"low"` — these are inferences; rate them
|
||||
|
||||
For a deletion finding the standard fields read as: `location` = the removed item; `trigger_condition` = the behavior or contract it enforced; `guard_snippet` = where or how to re-establish it; `potential_consequence` = the regression or orphan.
|
||||
|
||||
Add nothing if nothing qualifies.
|
||||
@@ -1,106 +1,6 @@
|
||||
---
|
||||
name: bmad-review-verification-gap
|
||||
description: 'Review a code change for changed behavior that could regress without reliable verification catching it. Use when checking whether a change is adequately verified.'
|
||||
description: 'Deprecated — forwards to bmad-review.'
|
||||
---
|
||||
|
||||
# Verification Gap Review
|
||||
|
||||
**Goal:** Find changed behavior that could break without reliable verification catching it. Ask one question — "if the behavior this change is supposed to produce broke where it's actually used, would verification fail?" Do not hunt for correctness bugs, but report genuine problems you notice while tracing verification.
|
||||
|
||||
The main verification gap shapes are:
|
||||
|
||||
1. **Regression gap:** the changed code regresses where it's used, and no test covering that use would fail.
|
||||
2. **Missing-adoption gap:** a place that should now use the new behavior doesn't; it handles the same case its own way, or not at all, and no test would flag the omission.
|
||||
3. **Broken-verification gap:** a test appears to cover the changed behavior, but would not actually protect it because it is skipped, flaky, not run in the normal verification path, or too weak to observe the regression.
|
||||
|
||||
## Evidence Rules
|
||||
|
||||
- Read a test before claiming what it covers, runs, asserts, or misses.
|
||||
- Before claiming no test exists, search the whole repo by the symbol under test and by import references; expected file locations are not enough.
|
||||
- Never assert what you did not verify. If a finding cannot be grounded, drop it.
|
||||
- In a finding, say what you actually checked — "none of the tests I read cover this" — and show how far you looked. Say a test doesn't exist anywhere only when the symbol/import-reference search actually shows that.
|
||||
- Do not assign severity, confidence, priority, or ranking.
|
||||
|
||||
## Review Sequence
|
||||
|
||||
### Step 1: Screen for behavioral change
|
||||
|
||||
If the change is non-behavioral, stop here and output the clean result (see Output Format). Call it non-behavioral only when the changed code does not alter return values, thrown errors, caller-visible side effects, or observable state (including iteration order and emitted messages). After the changed code meets that test, stop; do not inspect callers or tests for extra confirmation.
|
||||
|
||||
Common non-behavioral examples: formatting, comments, whitespace; pure renames; trivial getters/setters and pass-throughs; type-only or compiler-enforced changes with no runtime effect; etc.
|
||||
|
||||
### Step 2: Find the behavior that changed
|
||||
|
||||
Identify what behavior changed compared to the previous version: output, side effect, branch, error path, schema/event shape, config default, validation/authorization rule, external contract, etc. If the change affects more than one behavior, handle each separately.
|
||||
|
||||
Treat broad-impact changes as behavioral even when no single changed line looks important: dependency, toolchain, build/config, data-file, etc.
|
||||
|
||||
### Step 3: Trace where that behavior is used
|
||||
|
||||
Trace the changed behavior to the places that observe it. Start with direct callers and registered entry points (routes, commands, DI), contract consumers (schemas, events, APIs, database readers), and reverse-dependency info if already available.
|
||||
|
||||
Follow a path only while the changed behavior is reachable and unverified. Stop when a test at that boundary would fail, the consumer does not observe the changed behavior, or the next hop is guesswork (dynamic dispatch, reflection, outside-repo consumers, etc.). Prefer the nearest observable boundary, often one to three hops away, especially across contract, integration, or service edges. If there are more than five similar consumers, group obvious repeats and check representative paths; expand only when a consumer observes the behavior differently.
|
||||
|
||||
### Step 4: Qualify the consumer, then check its test
|
||||
|
||||
For each consumer, name the smallest realistic regression this consumer would observe: invert the branch, drop the default, omit the field, return the old error code, skip the integration call, etc. This is the Demonstration. If no such regression exists, drop the path; untested downstream code is not a finding.
|
||||
|
||||
A `Missing-adoption gap` qualifies not by the adoption failure alone but by a supersession signal: the change gives clear evidence the new behavior is meant to replace the local one — PR intent, naming or docs, a replaced sibling site, deleted duplicate logic, or a test defining the new rule — and the local site shares the same observable contract. Without a supersession signal and a shared observable contract, it is a refactor suggestion, not a verification-gap finding. Once both hold, check whether any test for that site would flag the non-adoption; missing coverage of the non-adoption is the gap itself, not a disqualifier.
|
||||
|
||||
Find and read the relevant test. Ask whether the Demonstration would make an assertion fail.
|
||||
|
||||
- If yes, the behavior is verified. No finding.
|
||||
- For a regression-style Demonstration: if no test runs the path, the test is skipped/flaky/not run normally, or the test runs the code without checking the changed result, report a `Regression gap` or `Broken-verification gap`.
|
||||
- For a qualifying Missing-adoption case: if none of the site tests you found assert it adopts the new behavior, report a `Missing-adoption gap`.
|
||||
|
||||
A test counts only if it runs normally and an assertion observes the changed output, branch, or contract. These do not count: no execution; success/no-throw/snapshot-only checks; mock/log-call checks; human-only checks; tests that mock away the integration; e2e tests that pass through without checking the changed output; stale assertions or fixtures.
|
||||
|
||||
Common patterns:
|
||||
|
||||
- **Caller-path gap** — helper test covers the branch, but caller values skip it.
|
||||
- **Contract drift** — payload/schema/event changes must be verified at the consumer.
|
||||
- **Migration compatibility** — tests only create new-format rows or fresh schemas.
|
||||
- **Phantom exception** — handled partial-failure path has no test.
|
||||
- **Missing-adoption gap** — sibling site should use the new rule/helper and does not.
|
||||
- **Removed verification** — deleted test or weakened assertion leaves behavior unpinned.
|
||||
|
||||
### Step 5: Confirm each finding is real
|
||||
|
||||
Before writing a finding, re-open the specific tests or search results the finding relies on. Verify the Demonstration would not make any test you checked fail, or that the absence claim is backed by the symbol/import-reference search. Do not claim more than you verified; drop any finding you cannot ground.
|
||||
|
||||
Do not report: compiler/type-checker-enforced cases; behavior already verified by an integration, contract, or e2e test; implementation-detail or mock-only tests; low coverage or a missing test file by itself; legacy untested code the change did not affect.
|
||||
|
||||
Report genuine problems you noticed while tracing verification, even if they are not verification gaps. Put them under `Other findings` in the output. This permits reporting what you already reached, not extra hunting.
|
||||
|
||||
## OUTPUT FORMAT
|
||||
|
||||
Emit each verification-gap finding as one block. No general advice, no severity or confidence.
|
||||
|
||||
```markdown
|
||||
### <one-line title naming the gap>
|
||||
|
||||
- **Changed surface:** the exact behavior or contract that changed — `file:line`.
|
||||
- **Impacted consumer or site:** named concretely with `file:line` (e.g. "the `createInvoice` mutation used by the billing dashboard at `billing/dashboard.ts:88`," not "callers of this function").
|
||||
- **Existing test evidence:**
|
||||
- `Regression gap`: what the relevant test actually asserts, with `file:line`; or, if none, the symbol/import-reference searches run and their result.
|
||||
- `Missing-adoption gap`: tests for the impacted site, and whether any assert it adopts the new behavior.
|
||||
- `Broken-verification gap`: the apparent test or verification path, and why it does not count.
|
||||
- **Missing verification:** the precise assertion or check that's absent.
|
||||
- **Demonstration:**
|
||||
- `Regression gap` / `Broken-verification gap`: the concrete regression that would ship undetected, and why the tests you checked would not fail.
|
||||
- `Missing-adoption gap`: the case the site mishandles by not adopting the new behavior, and that none of the tests you read assert adoption.
|
||||
- **Consequence:** the concrete thing that ships wrong — a regression the checked evidence would not catch, or a site that should use the new behavior and doesn't.
|
||||
- **Suggested test shape:** (optional) the kind of test that would close the gap, fit to the repo's own way of verifying — don't impose a generic test pyramid.
|
||||
```
|
||||
|
||||
If you noticed genuine non-gap problems while tracing verification, append:
|
||||
|
||||
```markdown
|
||||
## Other findings
|
||||
|
||||
- <description only; no severity, confidence, priority, or ranking>
|
||||
```
|
||||
|
||||
When you find no verification gaps and no other findings, output exactly this single line, not an empty response:
|
||||
|
||||
`No verification gaps found.`
|
||||
Merged into `bmad-review`. Invoke the `bmad-review` skill on the same content with only the `verification-gap` lens. Present the markdown rendering only (no JSON block), listing any `gap_shape: "other"` findings under an `## Other findings` heading. When there are no findings at all, output exactly this single line: `No verification gaps found.`
|
||||
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
name: bmad-review
|
||||
description: 'Multi-lens critical review — adversarial, edge-case, and verification-gap passes over any diff, doc, or artifact, run singly or together. Use when the user says "review this", "critical review", "hunt edge cases", or "check verification gaps".'
|
||||
---
|
||||
|
||||
# BMad Review
|
||||
|
||||
Review content through independent lenses — each a distinct method and stance — and report findings in one canonical shape. Report what is real: zero findings is a valid outcome, never pad to look thorough.
|
||||
|
||||
## Inputs
|
||||
|
||||
- **content** — what to review: a diff, branch, uncommitted changes, file, spec, story, or any document. Args: `[path]`.
|
||||
- **lenses** (optional) — one or more lens codes or names. Default: every applicable lens (a full review).
|
||||
- **also_consider** (optional) — areas to keep in mind alongside each lens's normal analysis.
|
||||
|
||||
## Conventions
|
||||
|
||||
- Bare paths (e.g. `references/lens-edge-case.md`) resolve from `{skill-root}` — this skill's installed directory, where `customize.toml` lives. `{project-root}` resolves to the project working directory.
|
||||
- `{workflow.<name>}` values come from the resolved customization.
|
||||
|
||||
## Execution
|
||||
|
||||
1. **Resolve customization:** `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. On failure, read `{skill-root}/customize.toml` directly and use defaults.
|
||||
2. **Load the content.** If it is empty or cannot be decoded as text: when the caller expects the raw findings JSON array (e.g. the legacy edge-case forwarder), return `[{"location":"N/A","trigger_condition":"Input empty or undecodable","guard_snippet":"Provide valid content to review","potential_consequence":"Review skipped — no analysis performed"}]` (no `lens` field) and stop; otherwise say what's wrong and ask for reviewable content. Identify the content type — diff, file, function, document — since scope rules and lens applicability depend on it.
|
||||
3. **Select lenses** from `{workflow.lenses}`. A lens with an empty `instruction` is disabled. If the user or caller named lenses, run exactly those. Otherwise run every enabled lens whose `when` fits the content (empty `when` = always fits).
|
||||
4. **Run each selected lens independently** — each sees the content and `also_consider`, never another lens's findings. Follow each lens's `instruction`; the shipped lenses load their reference file just-in-time, so load only what runs. When subagents are available, spawn one per lens in parallel: give it the lens `instruction` with `{skill-root}` and paths resolved absolute, the content or where to read it, any `also_consider` areas, and the constraint "Return ONLY the findings JSON array — no other output." Otherwise run the lenses sequentially yourself, completing one before starting the next.
|
||||
5. **Assemble and present** per Output below. Keep every lens's findings — overlap between lenses is signal, not duplication; note it in the markdown report rather than deduping.
|
||||
|
||||
## Output
|
||||
|
||||
One JSON array holding every finding from every lens. Each finding carries:
|
||||
|
||||
- `lens` — the code of the lens that produced it
|
||||
- `location` — where in the content (file:line-range for code, section for documents)
|
||||
- `trigger_condition` — the problem, or the condition that exposes it, in one line
|
||||
- `guard_snippet` — the concrete fix, guard, or missing check
|
||||
- `potential_consequence` — what goes wrong if it ships as-is
|
||||
|
||||
Each lens file refines these semantics for its findings and may add lens-specific fields (e.g. `kind`/`confidence` on deletion findings, `gap_shape`/`consumer`/`evidence` on verification-gap findings). `[]` is valid when nothing is found. No severity, priority, or ranking anywhere.
|
||||
|
||||
Present per `{workflow.output_format}` — `"json"` (the raw array in a fenced json block), `"markdown"`, or `"both"` — unless the caller requested a specific shape; a legacy forwarder's output contract always wins. The markdown report groups findings by lens: a short block per finding rendering the fields plus any extras worth surfacing, one line for a lens that found nothing, and a plain clean statement when the whole review is clean.
|
||||
|
||||
When `{workflow.report_path}` is set, write the report there; otherwise present it in chat.
|
||||
@@ -0,0 +1,54 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-review.
|
||||
#
|
||||
# Override files (not edited here):
|
||||
# {project-root}/_bmad/custom/bmad-review.toml (team)
|
||||
# {project-root}/_bmad/custom/bmad-review.user.toml (personal)
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins
|
||||
# arrays of tables keyed by `code`: matching key replaces, new keys append
|
||||
|
||||
# How findings are presented when the caller doesn't say: "json" (the raw
|
||||
# findings array only), "markdown" (the human report only), or "both".
|
||||
output_format = "both"
|
||||
|
||||
# Where to write the review report. Empty = present in chat only. Accepts
|
||||
# {project-root}-prefixed paths.
|
||||
report_path = ""
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Review lenses. Each lens is an independent pass over the content with its
|
||||
# own method and stance. `instruction` is the lens's whole execution recipe —
|
||||
# the shipped lenses load a reference file from the skill root, but an
|
||||
# override may inline any prompt. `when` (optional) gates whether the lens
|
||||
# joins a default full review; an explicitly requested lens always runs.
|
||||
# Empty `instruction` disables a lens. Keyed by `code`: an override with a
|
||||
# matching code replaces the shipped lens, a new code appends.
|
||||
#
|
||||
# Example (add an org-specific lens in team/user override TOML):
|
||||
# [[workflow.lenses]]
|
||||
# code = "accessibility"
|
||||
# name = "Accessibility"
|
||||
# when = "UI code or user-facing documents."
|
||||
# instruction = "Review against WCAG 2.2 AA. Emit findings in the canonical fields."
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
[[workflow.lenses]]
|
||||
code = "adversarial"
|
||||
name = "Adversarial"
|
||||
instruction = "Load `references/lens-adversarial.md` from the skill root and follow it."
|
||||
|
||||
[[workflow.lenses]]
|
||||
code = "edge-case"
|
||||
name = "Edge-Case Hunter"
|
||||
instruction = "Load `references/lens-edge-case.md` from the skill root and follow it."
|
||||
|
||||
[[workflow.lenses]]
|
||||
code = "verification-gap"
|
||||
name = "Verification Gap"
|
||||
when = "Code changes reviewed inside a repo where tests can be searched and read. Skip for prose documents or content with no verification surface."
|
||||
instruction = "Load `references/lens-verification-gap.md` from the skill root and follow it."
|
||||
@@ -0,0 +1,18 @@
|
||||
# Adversarial Lens
|
||||
|
||||
You are a cynical, jaded reviewer with zero patience for sloppy work. Assume the content was submitted carelessly and that problems exist — your job is to find them. Be skeptical of every claim, assumption, and omission. Look for what's missing, not just what's wrong. Precise, professional tone — no profanity or personal attacks.
|
||||
|
||||
This lens is attitude-driven and general-purpose: weaknesses, gaps, inconsistencies, unstated assumptions, unsupported claims, missing error handling, unaddressed risks — whatever the content type exposes. If `also_consider` areas were provided, weigh them alongside the normal analysis.
|
||||
|
||||
Hunt hard, but report only what is real. Every finding must point at something concrete in the content; never pad the list to look thorough. Zero findings is a valid outcome when the content genuinely holds up.
|
||||
|
||||
## Findings shape
|
||||
|
||||
Emit each finding with the canonical fields:
|
||||
|
||||
- `location` — where in the content (file:line for code, section or heading for documents, "general" when it spans the whole artifact)
|
||||
- `trigger_condition` — the problem, in one line
|
||||
- `guard_snippet` — the concrete fix or improvement
|
||||
- `potential_consequence` — what goes wrong if it ships unaddressed
|
||||
|
||||
No severity, priority, or ranking.
|
||||
@@ -0,0 +1,52 @@
|
||||
# Edge-Case Lens
|
||||
|
||||
You are a pure path tracer. Never comment on whether the content is good or bad; only list missing handling. Your method is exhaustive path enumeration — mechanically walk every branch, not hunt by intuition. Report ONLY paths and conditions that lack handling — discard handled ones silently. Do not editorialize or add filler.
|
||||
|
||||
**Scope rules:**
|
||||
|
||||
- When the content is a diff, scan only the diff hunks and list boundaries that are directly reachable from the changed lines and lack an explicit guard in the diff.
|
||||
- When it is not a diff (full file, function, or document), the entire provided content is the scope.
|
||||
- Ignore the rest of the codebase unless the provided content explicitly references external functions.
|
||||
|
||||
## Step 1: Exhaustive path analysis
|
||||
|
||||
Walk every branching path and boundary condition within scope — report only unhandled ones.
|
||||
|
||||
- If `also_consider` areas were provided, incorporate them into the analysis
|
||||
- Walk all branching paths: control flow (conditionals, loops, error handlers, early returns) and domain boundaries (where values, states, or conditions transition). Derive the relevant edge classes from the content itself — don't rely on a fixed checklist. Examples: missing else/default, unguarded inputs, off-by-one loops, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
|
||||
- Consider implicit branches: the diff special-cases or changes the handling of one or more members of a fixed set of values — enums, status codes, sentinels, type tags, flags, value ranges. The rest of the set is implicit branches (e.g. the diff changes the `RED` and `YELLOW` cases of a `RED`/`YELLOW`/`GREEN` enum; `GREEN` is the implicit branch)
|
||||
- For each path: determine whether the content handles it
|
||||
- Collect only the unhandled paths as findings — discard handled ones silently
|
||||
|
||||
## Step 2: Validate completeness
|
||||
|
||||
- Revisit every edge class from Step 1 — e.g., missing else/default, null/empty inputs, off-by-one loops, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
|
||||
- Add any newly found unhandled paths to findings; discard confirmed-handled ones
|
||||
|
||||
## Step 3: Deletion check
|
||||
|
||||
Runs only when the diff removed or replaced meaningful code (ignore pure renames and whitespace). Subordinate to the edge-case pass; findings are usually few or none.
|
||||
|
||||
For each chunk of removed or replaced code, ask: did it carry behavior or a contract that the change neither re-established nor intentionally retired? Add a finding for any resulting regression, orphaned reference, or newly-dead code. Skip anything already covered by your edge-case findings. Add nothing if nothing qualifies.
|
||||
|
||||
Deletion findings go in the same array with the four standard fields plus:
|
||||
|
||||
- `kind`: `"deletion"`
|
||||
- `confidence`: `"high"`, `"medium"`, or `"low"` — these are inferences; rate them
|
||||
|
||||
For a deletion finding the standard fields read as: `location` = the removed item; `trigger_condition` = the behavior or contract it enforced; `guard_snippet` = where or how to re-establish it; `potential_consequence` = the regression or orphan.
|
||||
|
||||
## Findings shape
|
||||
|
||||
Each edge-case finding contains exactly these four fields:
|
||||
|
||||
```json
|
||||
[{
|
||||
"location": "file:start-end (or file:line when single line, or file:hunk when exact line unavailable)",
|
||||
"trigger_condition": "one-line description (max 15 words)",
|
||||
"guard_snippet": "minimal code sketch that closes the gap (single-line escaped string, no raw newlines or unescaped quotes)",
|
||||
"potential_consequence": "what could actually go wrong (max 15 words)"
|
||||
}]
|
||||
```
|
||||
|
||||
An empty array is valid when nothing is found. Do not assign severity labels, rankings, or priority levels.
|
||||
@@ -0,0 +1,82 @@
|
||||
# Verification-Gap Lens
|
||||
|
||||
**Goal:** Find changed behavior that could break without reliable verification catching it. Ask one question — "if the behavior this change is supposed to produce broke where it's actually used, would verification fail?" Do not hunt for correctness bugs, but report genuine problems you notice while tracing verification.
|
||||
|
||||
The main verification gap shapes are:
|
||||
|
||||
1. **Regression gap:** the changed code regresses where it's used, and no test covering that use would fail.
|
||||
2. **Missing-adoption gap:** a place that should now use the new behavior doesn't; it handles the same case its own way, or not at all, and no test would flag the omission.
|
||||
3. **Broken-verification gap:** a test appears to cover the changed behavior, but would not actually protect it because it is skipped, flaky, not run in the normal verification path, or too weak to observe the regression.
|
||||
|
||||
## Evidence rules
|
||||
|
||||
- Read a test before claiming what it covers, runs, asserts, or misses.
|
||||
- Before claiming no test exists, search the whole repo by the symbol under test and by import references; expected file locations are not enough.
|
||||
- Never assert what you did not verify. If a finding cannot be grounded, drop it.
|
||||
- In a finding, say what you actually checked — "none of the tests I read cover this" — and show how far you looked. Say a test doesn't exist anywhere only when the symbol/import-reference search actually shows that.
|
||||
- Do not assign severity, confidence, priority, or ranking.
|
||||
|
||||
## Review sequence
|
||||
|
||||
### Step 1: Screen for behavioral change
|
||||
|
||||
If the change is non-behavioral, stop here and return zero findings (`[]`); when the output format includes a markdown report, note there that the change is non-behavioral (a caller's exact zero-findings output contract wins over this note). Call it non-behavioral only when the changed code does not alter return values, thrown errors, caller-visible side effects, or observable state (including iteration order and emitted messages). After the changed code meets that test, stop; do not inspect callers or tests for extra confirmation.
|
||||
|
||||
Common non-behavioral examples: formatting, comments, whitespace; pure renames; trivial getters/setters and pass-throughs; type-only or compiler-enforced changes with no runtime effect; etc.
|
||||
|
||||
### Step 2: Find the behavior that changed
|
||||
|
||||
Identify what behavior changed compared to the previous version: output, side effect, branch, error path, schema/event shape, config default, validation/authorization rule, external contract, etc. If the change affects more than one behavior, handle each separately.
|
||||
|
||||
Treat broad-impact changes as behavioral even when no single changed line looks important: dependency, toolchain, build/config, data-file, etc.
|
||||
|
||||
### Step 3: Trace where that behavior is used
|
||||
|
||||
Trace the changed behavior to the places that observe it. Start with direct callers and registered entry points (routes, commands, DI), contract consumers (schemas, events, APIs, database readers), and reverse-dependency info if already available.
|
||||
|
||||
Follow a path only while the changed behavior is reachable and unverified. Stop when a test at that boundary would fail, the consumer does not observe the changed behavior, or the next hop is guesswork (dynamic dispatch, reflection, outside-repo consumers, etc.). Prefer the nearest observable boundary, often one to three hops away, especially across contract, integration, or service edges. If there are more than five similar consumers, group obvious repeats and check representative paths; expand only when a consumer observes the behavior differently.
|
||||
|
||||
### Step 4: Qualify the consumer, then check its test
|
||||
|
||||
For each consumer, name the smallest realistic regression this consumer would observe: invert the branch, drop the default, omit the field, return the old error code, skip the integration call, etc. This is the Demonstration. If no such regression exists, drop the path; untested downstream code is not a finding.
|
||||
|
||||
A `Missing-adoption gap` qualifies not by the adoption failure alone but by a supersession signal: the change gives clear evidence the new behavior is meant to replace the local one — PR intent, naming or docs, a replaced sibling site, deleted duplicate logic, or a test defining the new rule — and the local site shares the same observable contract. Without a supersession signal and a shared observable contract, it is a refactor suggestion, not a verification-gap finding. Once both hold, check whether any test for that site would flag the non-adoption; missing coverage of the non-adoption is the gap itself, not a disqualifier.
|
||||
|
||||
Find and read the relevant test. Ask whether the Demonstration would make an assertion fail.
|
||||
|
||||
- If yes, the behavior is verified. No finding.
|
||||
- For a regression-style Demonstration: if no test runs the path, the test is skipped/flaky/not run normally, or the test runs the code without checking the changed result, report a `Regression gap` or `Broken-verification gap`.
|
||||
- For a qualifying Missing-adoption case: if none of the site tests you found assert it adopts the new behavior, report a `Missing-adoption gap`.
|
||||
|
||||
A test counts only if it runs normally and an assertion observes the changed output, branch, or contract. These do not count: no execution; success/no-throw/snapshot-only checks; mock/log-call checks; human-only checks; tests that mock away the integration; e2e tests that pass through without checking the changed output; stale assertions or fixtures.
|
||||
|
||||
Common patterns:
|
||||
|
||||
- **Caller-path gap** — helper test covers the branch, but caller values skip it.
|
||||
- **Contract drift** — payload/schema/event changes must be verified at the consumer.
|
||||
- **Migration compatibility** — tests only create new-format rows or fresh schemas.
|
||||
- **Phantom exception** — handled partial-failure path has no test.
|
||||
- **Missing-adoption gap** — sibling site should use the new rule/helper and does not.
|
||||
- **Removed verification** — deleted test or weakened assertion leaves behavior unpinned.
|
||||
|
||||
### Step 5: Confirm each finding is real
|
||||
|
||||
Before writing a finding, re-open the specific tests or search results the finding relies on. Verify the Demonstration would not make any test you checked fail, or that the absence claim is backed by the symbol/import-reference search. Do not claim more than you verified; drop any finding you cannot ground.
|
||||
|
||||
Do not report: compiler/type-checker-enforced cases; behavior already verified by an integration, contract, or e2e test; implementation-detail or mock-only tests; low coverage or a missing test file by itself; legacy untested code the change did not affect.
|
||||
|
||||
Report genuine problems you noticed while tracing verification, even if they are not verification gaps — emit them as findings with `gap_shape: "other"`. This permits reporting what you already reached, not extra hunting.
|
||||
|
||||
## Findings shape
|
||||
|
||||
Emit each gap with the canonical fields plus this lens's extras:
|
||||
|
||||
- `location` — the changed surface: the exact behavior or contract that changed, `file:line`
|
||||
- `trigger_condition` — the gap, in one line
|
||||
- `guard_snippet` — the missing verification: the precise assertion or check that's absent, optionally with the test shape that would close it, fit to the repo's own way of verifying — don't impose a generic test pyramid
|
||||
- `potential_consequence` — the concrete thing that ships wrong: the regression the checked evidence would not catch, or the site that should use the new behavior and doesn't, with why the tests you checked would not fail
|
||||
- `gap_shape` — `"regression-gap"`, `"missing-adoption-gap"`, `"broken-verification-gap"`, or `"other"`
|
||||
- `consumer` — the impacted consumer or site, named concretely with `file:line` (e.g. "the `createInvoice` mutation used by the billing dashboard at `billing/dashboard.ts:88`", not "callers of this function")
|
||||
- `evidence` — what you actually checked: what the relevant test asserts with `file:line`; or, if none, the symbol/import-reference searches run and their result; for a broken-verification gap, the apparent test and why it does not count
|
||||
|
||||
For `gap_shape: "other"` findings the four canonical fields suffice (description only); `consumer` and `evidence` are optional. An empty array is valid when the change is non-behavioral or every changed behavior is verified.
|
||||
@@ -1,105 +0,0 @@
|
||||
---
|
||||
name: bmad-shard-doc
|
||||
description: 'Splits large markdown documents into smaller, organized files based on level 2 (default) sections. Use if the user says perform shard document'
|
||||
---
|
||||
|
||||
# Shard Document
|
||||
|
||||
**Goal:** Split large markdown documents into smaller, organized files based on level 2 sections using `npx @kayvan/markdown-tree-parser`.
|
||||
|
||||
## CRITICAL RULES
|
||||
|
||||
- MANDATORY: Execute ALL steps in the EXECUTION section IN EXACT ORDER
|
||||
- DO NOT skip steps or change the sequence
|
||||
- HALT immediately when halt-conditions are met
|
||||
- Each action within a step is a REQUIRED action to complete that step
|
||||
|
||||
## EXECUTION
|
||||
|
||||
### Step 1: Get Source Document
|
||||
|
||||
- Ask user for the source document path if not provided already
|
||||
- Verify file exists and is accessible
|
||||
- Verify file is markdown format (.md extension)
|
||||
- If file not found or not markdown: HALT with error message
|
||||
|
||||
### Step 2: Get Destination Folder
|
||||
|
||||
- Determine default destination: same location as source file, folder named after source file without .md extension
|
||||
- Example: `/path/to/architecture.md` --> `/path/to/architecture/`
|
||||
- Ask user for the destination folder path (`[y]` to confirm use of default: `[suggested-path]`, else enter a new path)
|
||||
- If user accepts default: use the suggested destination path
|
||||
- If user provides custom path: use the custom destination path
|
||||
- Verify destination folder exists or can be created
|
||||
- Check write permissions for destination
|
||||
- If permission denied: HALT with error message
|
||||
|
||||
### Step 3: Execute Sharding
|
||||
|
||||
- Inform user that sharding is beginning
|
||||
- Execute command: `npx @kayvan/markdown-tree-parser explode [source-document] [destination-folder]`
|
||||
- Capture command output and any errors
|
||||
- If command fails: HALT and display error to user
|
||||
|
||||
### Step 4: Verify Output
|
||||
|
||||
- Check that destination folder contains sharded files
|
||||
- Verify index.md was created in destination folder
|
||||
- Count the number of files created
|
||||
- If no files created: HALT with error message
|
||||
|
||||
### Step 5: Report Completion
|
||||
|
||||
- Display completion report to user including:
|
||||
- Source document path and name
|
||||
- Destination folder path
|
||||
- Number of section files created
|
||||
- Confirmation that index.md was created
|
||||
- Any tool output or warnings
|
||||
- Inform user that sharding completed successfully
|
||||
|
||||
### Step 6: Handle Original Document
|
||||
|
||||
> **Critical:** Keeping both the original and sharded versions defeats the purpose of sharding and can cause confusion.
|
||||
|
||||
Present user with options for the original document:
|
||||
|
||||
> What would you like to do with the original document `[source-document-name]`?
|
||||
>
|
||||
> Options:
|
||||
> - `[d]` Delete - Remove the original (recommended - shards can always be recombined)
|
||||
> - `[m]` Move to archive - Move original to a backup/archive location
|
||||
> - `[k]` Keep - Leave original in place (NOT recommended - defeats sharding purpose)
|
||||
>
|
||||
> Your choice (d/m/k):
|
||||
|
||||
#### If user selects `d` (delete)
|
||||
|
||||
- Delete the original source document file
|
||||
- Confirm deletion to user: "Original document deleted: [source-document-path]"
|
||||
- Note: The document can be reconstructed from shards by concatenating all section files in order
|
||||
|
||||
#### If user selects `m` (move)
|
||||
|
||||
- Determine default archive location: same directory as source, in an `archive` subfolder
|
||||
- Example: `/path/to/architecture.md` --> `/path/to/archive/architecture.md`
|
||||
- Ask: Archive location (`[y]` to use default: `[default-archive-path]`, or provide custom path)
|
||||
- If user accepts default: use default archive path
|
||||
- If user provides custom path: use custom archive path
|
||||
- Create archive directory if it does not exist
|
||||
- Move original document to archive location
|
||||
- Confirm move to user: "Original document moved to: [archive-path]"
|
||||
|
||||
#### If user selects `k` (keep)
|
||||
|
||||
- Display warning to user:
|
||||
- Keeping both original and sharded versions is NOT recommended
|
||||
- The discover_inputs protocol may load the wrong version
|
||||
- Updates to one will not reflect in the other
|
||||
- Duplicate content taking up space
|
||||
- Consider deleting or archiving the original document
|
||||
- Confirm user choice: "Original document kept at: [source-document-path]"
|
||||
|
||||
## HALT CONDITIONS
|
||||
|
||||
- HALT if npx command fails or produces no output files
|
||||
@@ -1,14 +1,7 @@
|
||||
module,skill,display-name,menu-code,description,action,args,phase,preceded-by,followed-by,required,output-location,outputs
|
||||
Core,_meta,,,,,,,,,false,https://docs.bmad-method.org/llms.txt,
|
||||
Core,bmad-brainstorming,Brainstorming,BSP,Use early in ideation or when stuck generating ideas.,,,anytime,,,false,{output_folder}/brainstorming,brainstorming session
|
||||
Core,bmad-party-mode,Party Mode,PM,Orchestrate multi-agent discussions when you need multiple perspectives or want agents to collaborate.,,,anytime,,,false,,
|
||||
Core,bmad-help,BMad Help,BH,,,,anytime,,,false,,
|
||||
Core,bmad-index-docs,Index Docs,ID,Use when LLM needs to understand available docs without loading everything.,,,anytime,,,false,,
|
||||
Core,bmad-shard-doc,Shard Document,SD,Use when doc becomes too large (>500 lines) to manage effectively.,,[path],anytime,,,false,,
|
||||
Core,bmad-editorial-review-prose,Editorial Review - Prose,EP,Use after drafting to polish written content.,,[path],anytime,,,false,report located with target document,three-column markdown table with suggested fixes
|
||||
Core,bmad-editorial-review-structure,Editorial Review - Structure,ES,Use when doc produced from multiple subprocesses or needs structural improvement.,,[path],anytime,,,false,report located with target document,
|
||||
Core,bmad-review-adversarial-general,Adversarial Review,AR,"Use for quality assurance or before finalizing deliverables. Code Review in other modules runs this automatically, but also useful for document reviews.",,[path],anytime,,,false,,
|
||||
Core,bmad-review-edge-case-hunter,Edge Case Hunter Review,ECH,Use alongside adversarial review for orthogonal coverage — method-driven not attitude-driven.,,[path],anytime,,,false,,
|
||||
Core,bmad-spec,Spec,SP,"Use to distill any intent input (brief, PRD, transcript, brain dump, design folder, mixed multi-source) into a succinct, no-fluff SPEC.md contract + companions that downstream work derives from. Locks the WHAT before the HOW. Works for software, game design, research, editorial, policy, business, anything intent-bearing. Validation mode also available.",,[path],anytime,,,false,{output_folder}/specs/spec-{slug},SPEC.md + companion files
|
||||
Core,bmad-customize,BMad Customize,BC,"Use when you want to change how an agent or workflow behaves — add persistent facts, swap templates, insert activation hooks, or customize menus. Scans what's customizable, picks the right scope (agent vs workflow), writes the override to _bmad/custom/, and verifies the merge. No TOML hand-authoring required.",,,anytime,,,false,{project-root}/_bmad/custom,TOML override files
|
||||
Core,bmad-forge-idea,Forge Idea,FI,"Use to pressure-test and harden an idea — software, business, creative, research, or life — until it proves out, hardens into something buildable, or dies cheaply. Persona-driven interrogation; optional handoff to bmad-spec or bmad-quick-dev.",,,anytime,,,false,{output_folder}/forge,refined-idea brief (optional)
|
||||
Core,bmad-advanced-elicitation,Advanced Elicitation,AE,"Use at any checkpoint to push a just-produced draft, section, or plan past its first version — pick from a menu of elicitation methods (pre-mortem, first principles, red team, socratic) and apply the improvements.",,,anytime,,,false,,
|
||||
Core,bmad-editorial-review,Editorial Review,ED,"Two-pass editorial review — structure (cuts, merges, moves) then prose copy-edit. Runs both passes by default; ask for either alone. Use after drafting to tighten and polish any document.",,[path],anytime,,,false,,findings table with suggested fixes
|
||||
Core,bmad-review,Review,RV,"Multi-lens critical review — adversarial, edge-case, and verification-gap lenses over any diff, doc, or artifact; run one lens, several, or all. Code Review in other modules runs the lenses automatically; also useful for document and spec reviews.",,[path],anytime,,,false,,findings JSON array + markdown report
|
||||
|
||||
|
@@ -0,0 +1,13 @@
|
||||
# BMad Analysis
|
||||
|
||||
A bundle module. It ships no skills of its own — selecting it in the installer pulls in three standalone thinking skills via the `dependencies` list in `module.yaml`:
|
||||
|
||||
- **bmad-brainstorming** — diverge and generate ideas with facilitated techniques
|
||||
- **bmad-forge-idea** — pressure-test an idea until it hardens, proves out, or dies cheaply
|
||||
- **bmad-party-mode** — multi-perspective roundtable discussions between agents or custom personas
|
||||
|
||||
The three skills live as hidden single-skill modules under `src/standalone-skills/`. They can also be installed individually; this bundle is the visible picker entry that brings them in as a set.
|
||||
|
||||
## Adding skills to the pack
|
||||
|
||||
Add the new skill as its own module under `src/standalone-skills/<name>/` (with its own `module.yaml` and `module-help.csv`, marked `hidden: true`), then append its module code to `dependencies` in this module's `module.yaml`. Queued candidates: research, prfaq.
|
||||
@@ -0,0 +1,2 @@
|
||||
module,skill,display-name,menu-code,description,action,args,phase,preceded-by,followed-by,required,output-location,outputs
|
||||
BMad Analysis,_meta,,,"The BMad thinking pack — a bundle with no skills of its own. Installing it pulls in three standalone skills: bmad-brainstorming (diverge and generate ideas), bmad-forge-idea (pressure-test an idea until it hardens or dies cheaply), and bmad-party-mode (multi-perspective agent roundtable). Each skill documents itself in its own module.",,,,,,false,,
|
||||
|
@@ -0,0 +1,11 @@
|
||||
code: bmad-analysis
|
||||
name: "BMad Analysis"
|
||||
description: "The BMad thinking pack: diverge with structured brainstorming, pressure-test ideas until they harden or die cheaply, and gather multi-perspective input from an agent roundtable."
|
||||
default_selected: false
|
||||
|
||||
# Bundle module — ships no skills of its own. Selecting it installs the
|
||||
# standalone skill modules below via the dependencies mechanism.
|
||||
dependencies:
|
||||
- bmad-brainstorming
|
||||
- bmad-party-mode
|
||||
- bmad-forge-idea
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user