Compare commits
32 Commits
1f38437d5d
...
53a4314a8c
| Author | SHA1 | Date |
|---|---|---|
Nikolas Hor
|
53a4314a8c | |
梁山河
|
090bfea9b2 | |
github-actions[bot]
|
fce9d6c0c8 | |
Brian
|
3acd1a7912 | |
|
Brian
|
8cac7f9210 | |
|
Brian Madison
|
0cdfd7564f | |
|
梁山河
|
c350e5b9d8 | |
|
梁山河
|
0d7d7dae04 | |
|
Brian
|
a04635efe0 | |
|
梁山河
|
94831cbb1e | |
|
梁山河
|
8b0754106d | |
|
梁山河
|
90d9d880b6 | |
lif
|
0c245474c4 | |
Murat K Ozcan
|
303e7ae290 | |
Alex Verkhovsky
|
48152507e2 | |
|
Alex Verkhovsky
|
b3cf338118 | |
|
Alex Verkhovsky
|
fc2b253ab5 | |
|
Alex Verkhovsky
|
ac5cb9de5c | |
|
Alex Verkhovsky
|
980d2904f4 | |
|
梁山河
|
76fb7e067b | |
|
梁山河
|
ad2eb0e127 | |
|
Alex Verkhovsky
|
7e97b7e7f3 | |
|
梁山河
|
ba2a5cc6a0 | |
|
梁山河
|
347f459d5d | |
|
梁山河
|
eb72361720 | |
|
Alex Verkhovsky
|
e3f935fd6d | |
|
Alex Verkhovsky
|
10282a4a14 | |
|
Alex Verkhovsky
|
a59ae5c842 | |
|
Alex Verkhovsky
|
ad9cb7a177 | |
|
Alex Verkhovsky
|
93a1e1dc46 | |
|
Alex Verkhovsky
|
31ae226bb4 | |
|
Alex Verkhovsky
|
c28206dca4 |
20
CHANGELOG.md
20
CHANGELOG.md
|
|
@ -1,5 +1,25 @@
|
|||
# Changelog
|
||||
|
||||
## v6.2.1 - 2026-03-24
|
||||
|
||||
### 🎁 Highlights
|
||||
|
||||
* Full rewrite of code-review skill with sharded step-file architecture, three parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor), and interactive post-review triage (#2007, #2013, #2055)
|
||||
* Quick Dev workflow overhaul: smart intent cascade, self-check gate, VS Code integration, clickable spec links, and spec rename (#2105, #2104, #2039, #2085, #2109)
|
||||
* Add review trail generation with clickable `path:line` stops in spec file (#2033)
|
||||
* Add clickable spec links using spec-file-relative markdown format (#2085, #2049)
|
||||
* Preserve tracking identifiers in spec slug derivation (#2108)
|
||||
* Deterministic skill validator with 19 rules across 6 categories, integrated into CI (#1981, #1982, #2004, #2002, #2051)
|
||||
* Complete French (fr-FR) documentation translation (#2073)
|
||||
* Add Ona platform support (#1968)
|
||||
* Rename tech-spec → spec across templates and all documentation (#2109)
|
||||
|
||||
### 📚 Documentation
|
||||
|
||||
* Complete French (fr-FR) translation of all documentation with workflow diagrams (#2073)
|
||||
* Refine Chinese (zh-CN) documentation: epic stories, how-to guides, getting-started, entry copy, help, anchor links (#2092–#2099, #2072)
|
||||
* Add Chinese translation for core-tools reference (#2002)
|
||||
|
||||
## v6.2.0 - 2026-03-15
|
||||
|
||||
### 🎁 Highlights
|
||||
|
|
|
|||
59
README_CN.md
59
README_CN.md
|
|
@ -5,20 +5,20 @@
|
|||
[](https://nodejs.org)
|
||||
[](https://discord.gg/gk8jAdXWmj)
|
||||
|
||||
**突破性敏捷 AI 驱动开发方法** — 简称 “BMAD 方法论” ，BMAD方法论是由多个模块生态构成的AI驱动敏捷开发模块系统，这是最佳且最全面的敏捷 AI 驱动开发框架，具备真正的规模自适应人工智能，可适应快速开发，适应企业规模化开发。
|
||||
**筑梦架构（Build More Architect Dreams）** —— 简称 “BMAD 方法”，面向 BMad 模块生态的 AI 驱动敏捷开发方法。它会随项目复杂度调整工作深度，从日常 bug 修复到企业级系统建设都能适配。
|
||||
|
||||
**100% 免费且开源。** 无付费。无内容门槛。无封闭 Discord。我们赋能每个人，我们将为全球现在在人工智能领域发展的普通人提供公平的学习机会。
|
||||
**100% 免费且开源。** 没有付费墙，没有封闭内容，也没有封闭 Discord。我们希望每个人都能平等获得高质量的人机协作开发方法。
|
||||
|
||||
## 为什么选择 BMad 方法？
|
||||
|
||||
传统 AI 工具替你思考，产生平庸的结果。BMad 智能体和辅助工作流充当专家协作者，引导你通过结构化流程，与 AI 的合作发挥最佳思维，产出最有效优秀的结果。
|
||||
传统 AI 工具常常替你思考，结果往往止于“能用”。BMad 通过专业智能体和引导式工作流，让 AI 成为协作者：流程有结构，决策有依据，产出更稳定。
|
||||
|
||||
- **AI 智能帮助** — 随时使用 `bmad-help` 获取下一步指导
|
||||
- **规模-领域自适应** — 根据项目复杂度自动调整规划深度
|
||||
- **结构化工作流** — 基于分析、规划、架构和实施的敏捷最佳实践
|
||||
- **专业智能体** — 12+ 领域专家（PM、架构师、开发者、UX、Scrum Master 等）
|
||||
- **派对模式** — 将多个智能体角色带入一个会话进行协作和讨论
|
||||
- **完整生命周期** — 从想法开始（头脑风暴）到部署发布
|
||||
- **AI 智能引导** —— 随时调用 `bmad-help` 获取下一步建议
|
||||
- **规模与领域自适应** —— 按项目复杂度自动调整规划深度
|
||||
- **结构化工作流** —— 覆盖分析、规划、架构、实施全流程
|
||||
- **专业角色智能体** —— 提供 PM、架构师、开发者、UX、Scrum Master 等 12+ 角色
|
||||
- **派对模式** —— 多个智能体可在同一会话协作讨论
|
||||
- **完整生命周期** —— 从头脑风暴一路到交付上线
|
||||
|
||||
[在 **docs.bmad-method.org** 了解更多](https://docs.bmad-method.org/zh-cn/)
|
||||
|
||||
|
|
@ -26,7 +26,7 @@
|
|||
|
||||
## 🚀 BMad 的下一步是什么？
|
||||
|
||||
**V6 已到来，我们才刚刚开始！** BMad 方法正在快速发展，包括跨平台智能体团队和子智能体集成、技能架构、BMad Builder v1、开发循环自动化等优化，以及更多正在开发中的功能。
|
||||
**V6 已经上线，而这只是开始。** BMad 仍在快速演进：跨平台智能体团队与子智能体集成、Skills 架构、BMad Builder v1、Dev Loop 自动化等能力都在持续推进。
|
||||
|
||||
**[📍 查看完整路线图 →](https://docs.bmad-method.org/zh-cn/roadmap/)**
|
||||
|
||||
|
|
@ -40,7 +40,7 @@
|
|||
npx bmad-method install
|
||||
```
|
||||
|
||||
> 想要最新的预发布版本？使用 `npx bmad-method@next install`。相比默认安装，可能会有更多变更。
|
||||
> 想体验最新预发布版本？可使用 `npx bmad-method@next install`。它比默认版本更新更快，也可能更容易发生变化。
|
||||
|
||||
按照安装程序提示操作，然后在项目文件夹中打开你的 AI IDE（Claude Code、Cursor 等）。
|
||||
|
||||
|
|
@ -52,19 +52,19 @@ npx bmad-method install --directory /path/to/project --modules bmm --tools claud
|
|||
|
||||
[查看非交互式安装选项](https://docs.bmad-method.org/zh-cn/how-to/non-interactive-installation/)
|
||||
|
||||
> **不确定该做什么？** 运行 `bmad-help` — 它会准确告诉你下一步做什么以及什么是可选的。你也可以问诸如 `bmad-help 我刚刚完成了架构设计，接下来该做什么？` 之类的问题。
|
||||
> **不确定下一步？** 直接问 `bmad-help`。它会告诉你“必做什么、可选什么”，例如：`bmad-help 我刚完成架构设计，接下来做什么？`
|
||||
|
||||
## 模块
|
||||
|
||||
BMad 方法通过官方模块扩展到专业领域。可在安装期间或之后的任何时间使用。
|
||||
BMad 可通过官方模块扩展到不同专业场景。你可以在安装时选择，也可以后续随时补装。
|
||||
|
||||
| Module | Purpose |
|
||||
| ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- |
|
||||
| **[BMad Method (BMM)](https://github.com/bmad-code-org/BMAD-METHOD)** | 包含 34+ 工作流的核心框架 |
|
||||
| **[BMad Builder (BMB)](https://github.com/bmad-code-org/bmad-builder)** | 创建自定义 BMad 智能体和工作流 |
|
||||
| **[Test Architect (TEA)](https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise)** | 基于风险的测试策略和自动化 |
|
||||
| **[Game Dev Studio (BMGD)](https://github.com/bmad-code-org/bmad-module-game-dev-studio)** | 游戏开发工作流（Unity、Unreal、Godot） |
|
||||
| **[Creative Intelligence Suite (CIS)](https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite)** | 创新、头脑风暴、设计思维 |
|
||||
| 模块 | 用途 |
|
||||
| ----------------------------------------------------------------------------------------------------------------- | ---------------------------- |
|
||||
| **[BMad Method (BMM)](https://github.com/bmad-code-org/BMAD-METHOD)** | 核心框架，内含 34+ 工作流 |
|
||||
| **[BMad Builder (BMB)](https://github.com/bmad-code-org/bmad-builder)** | 创建自定义 BMad 智能体与工作流 |
|
||||
| **[Test Architect (TEA)](https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise)** | 基于风险的测试策略与自动化 |
|
||||
| **[Game Dev Studio (BMGD)](https://github.com/bmad-code-org/bmad-module-game-dev-studio)** | 游戏开发工作流（Unity/Unreal/Godot） |
|
||||
| **[Creative Intelligence Suite (CIS)](https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite)** | 创新、头脑风暴、设计思维 |
|
||||
|
||||
## 文档
|
||||
|
||||
|
|
@ -72,10 +72,9 @@ BMad 方法通过官方模块扩展到专业领域。可在安装期间或之后
|
|||
|
||||
**快速链接：**
|
||||
- [入门教程](https://docs.bmad-method.org/zh-cn/tutorials/getting-started/)
|
||||
- [从先前版本升级](https://docs.bmad-method.org/zh-cn/how-to/upgrade-to-v6/)
|
||||
- [从旧版本升级](https://docs.bmad-method.org/zh-cn/how-to/upgrade-to-v6/)
|
||||
- [测试架构师文档（英文）](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/)
|
||||
|
||||
|
||||
## 社区
|
||||
|
||||
- [Discord](https://discord.gg/gk8jAdXWmj) — 获取帮助、分享想法、协作
|
||||
|
|
@ -85,9 +84,9 @@ BMad 方法通过官方模块扩展到专业领域。可在安装期间或之后
|
|||
|
||||
## 支持 BMad
|
||||
|
||||
BMad 对每个人都是免费的 — 并且永远如此。如果你想支持开发：
|
||||
BMad 对所有人免费，而且会一直免费。如果你愿意支持项目发展：
|
||||
|
||||
- ⭐ 请点击此页面右上角附近的项目星标图标
|
||||
- ⭐ 给仓库点个 Star
|
||||
- ☕ [请我喝咖啡](https://buymeacoffee.com/bmad) — 为开发提供动力
|
||||
- 🏢 企业赞助 — 在 Discord 上私信
|
||||
- 🎤 演讲与媒体 — 可参加会议、播客、采访（在 Discord 上联系 BM）
|
||||
|
|
@ -107,15 +106,3 @@ MIT 许可证 — 详见 [LICENSE](LICENSE)。
|
|||
[](https://github.com/bmad-code-org/BMAD-METHOD/graphs/contributors)
|
||||
|
||||
请参阅 [CONTRIBUTORS.md](CONTRIBUTORS.md) 了解贡献者信息。
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **workflow**：工作流。指一系列有序的任务或步骤，用于完成特定目标。
|
||||
- **CI/CD**：持续集成/持续部署。一种自动化软件开发实践，用于频繁集成代码更改并自动部署。
|
||||
- **IDE**：集成开发环境。提供代码编辑、调试、构建等功能的软件开发工具。
|
||||
- **PM**：产品经理。负责产品规划、需求管理和团队协调的角色。
|
||||
- **UX**：用户体验。指用户在使用产品或服务过程中的整体感受和交互体验。
|
||||
- **Scrum Master**：Scrum 主管。敏捷开发 Scrum 框架中的角色，负责促进团队遵循 Scrum 流程。
|
||||
- **PRD**：产品需求文档。详细描述产品功能、需求和规格的文档。
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ Critical warnings only — data loss, security issues
|
|||
| Phase | Name | What Happens |
|
||||
| ----- | -------- | -------------------------------------------- |
|
||||
| 1 | Analysis | Brainstorm, research *(optional)* |
|
||||
| 2 | Planning | Requirements — PRD or tech-spec *(required)* |
|
||||
| 2 | Planning | Requirements — PRD or spec *(required)* |
|
||||
```
|
||||
|
||||
**Skills:**
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Yes! Quick Flow works great for established projects. It will:
|
|||
- Auto-detect your existing stack
|
||||
- Analyze existing code patterns
|
||||
- Detect conventions and ask for confirmation
|
||||
- Generate context-rich tech-spec that respects existing code
|
||||
- Generate context-rich spec that respects existing code
|
||||
|
||||
Perfect for bug fixes and small features in existing codebases.
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ Perfect for bug fixes and small features in existing codebases.
|
|||
Quick Flow detects your conventions and asks: "Should I follow these existing conventions?" You decide:
|
||||
|
||||
- **Yes** → Maintain consistency with current codebase
|
||||
- **No** → Establish new standards (document why in tech-spec)
|
||||
- **No** → Establish new standards (document why in spec)
|
||||
|
||||
BMM respects your choice — it won't force modernization, but it will offer it.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Every implementation workflow automatically loads `project-context.md` if it exi
|
|||
- `bmad-create-story` — informs story creation with project patterns
|
||||
- `bmad-dev-story` — guides implementation decisions
|
||||
- `bmad-code-review` — validates against project standards
|
||||
- `bmad-quick-dev` — applies patterns when implementing tech-specs
|
||||
- `bmad-quick-dev` — applies patterns when implementing specs
|
||||
- `bmad-sprint-planning`, `bmad-retrospective`, `bmad-correct-course` — provides project-wide context
|
||||
|
||||
## When to Create It
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ Ajouter un contexte persistant que l'agent gardera toujours en mémoire :
|
|||
```yaml
|
||||
memories:
|
||||
- 'Travaille au Krusty Krab'
|
||||
- 'Célébrité préférée : David Hasslehoff'
|
||||
- 'Célébrité préférée : David Hasselhoff'
|
||||
- 'Appris dans l’Epic 1 que ce n’est pas cool de faire semblant que les tests ont passé'
|
||||
```
|
||||
|
||||
|
|
@ -127,7 +127,7 @@ prompts:
|
|||
|
||||
### 3. Appliquer vos modifications
|
||||
|
||||
Après modification, recompilez l'agent pour appliquer les changements :
|
||||
Après modification, réinstallez pour appliquer les changements :
|
||||
|
||||
```bash
|
||||
npx bmad-method install
|
||||
|
|
@ -137,17 +137,16 @@ L'installateur détecte l'installation existante et propose ces options :
|
|||
|
||||
| Option | Ce qu'elle fait |
|
||||
| ----------------------------------- | ---------------------------------------------------------------------- |
|
||||
| **Quick Update** | Met à jour tous les modules vers la dernière version et recompile tous les agents |
|
||||
| **Recompile Agents** | Applique uniquement les personnalisations, sans mettre à jour les fichiers de modules |
|
||||
| **Quick Update** | Met à jour tous les modules vers la dernière version et applique les personnalisations |
|
||||
| **Modify BMad Installation** | Flux d'installation complet pour ajouter ou supprimer des modules |
|
||||
|
||||
Pour des modifications de personnalisation uniquement, **Recompile Agents** est l'option la plus rapide.
|
||||
Pour des modifications de personnalisation uniquement, **Quick Update** est l'option la plus rapide.
|
||||
|
||||
## Résolution des problèmes
|
||||
|
||||
**Les modifications n'apparaissent pas ?**
|
||||
|
||||
- Exécutez `npx bmad-method install` et sélectionnez **Recompile Agents** pour appliquer les modifications
|
||||
- Exécutez `npx bmad-method install` et sélectionnez **Quick Update** pour appliquer les modifications
|
||||
- Vérifiez que votre syntaxe YAML est valide (l'indentation compte)
|
||||
- Assurez-vous d'avoir modifié le bon fichier `.customize.yaml` pour l'agent
|
||||
|
||||
|
|
@ -160,7 +159,7 @@ Pour des modifications de personnalisation uniquement, **Recompile Agents** est
|
|||
**Besoin de réinitialiser un agent ?**
|
||||
|
||||
- Effacez ou supprimez le fichier `.customize.yaml` de l'agent
|
||||
- Exécutez `npx bmad-method install` et sélectionnez **Recompile Agents** pour restaurer les valeurs par défaut
|
||||
- Exécutez `npx bmad-method install` et sélectionnez **Quick Update** pour restaurer les valeurs par défaut
|
||||
|
||||
## Personnalisation des workflows
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Nécessite [Node.js](https://nodejs.org) v20+ et `npx` (inclus avec npm).
|
|||
| `--modules <modules>` | IDs de modules séparés par des virgules | `--modules bmm,bmb` |
|
||||
| `--tools <outils>` | IDs d'outils/IDE séparés par des virgules (utilisez `none` pour ignorer) | `--tools claude-code,cursor` ou `--tools none` |
|
||||
| `--custom-content <chemins>` | Chemins vers des modules personnalisés séparés par des virgules | `--custom-content ~/my-module,~/another-module` |
|
||||
| `--action <type>` | Action pour les installations existantes : `install` (par défaut), `update`, `quick-update`, ou `compile-agents` | `--action quick-update` |
|
||||
| `--action <type>` | Action pour les installations existantes : `install` (par défaut), `update`, ou `quick-update` | `--action quick-update` |
|
||||
|
||||
### Configuration principale
|
||||
|
||||
|
|
@ -121,7 +121,7 @@ npx bmad-method install \
|
|||
## Ce que vous obtenez
|
||||
|
||||
- Un répertoire `_bmad/` entièrement configuré dans votre projet
|
||||
- Des agents et des flux de travail compilés pour vos modules et outils sélectionnés
|
||||
- Des agents et des flux de travail configurés pour vos modules et outils sélectionnés
|
||||
- Un dossier `_bmad-output/` pour les artefacts générés
|
||||
|
||||
## Validation et gestion des erreurs
|
||||
|
|
@ -132,7 +132,7 @@ BMad valide toutes les options fournis :
|
|||
- **Modules** — Avertit des IDs de modules invalides (mais n'échoue pas)
|
||||
- **Tools** — Avertit des IDs d'outils invalides (mais n'échoue pas)
|
||||
- **Custom Content** — Chaque chemin doit contenir un fichier `module.yaml` valide
|
||||
- **Action** — Doit être l'une des suivantes : `install`, `update`, `quick-update`, `compile-agents`
|
||||
- **Action** — Doit être l'une des suivantes : `install`, `update`, `quick-update`
|
||||
|
||||
Les valeurs invalides entraîneront soit :
|
||||
1. L’affichage d’un message d'erreur suivi d’un exit (pour les options critiques comme le répertoire)
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ Sautez les phases 1-3 pour les travaux de faible envergure et bien compris.
|
|||
|
||||
| Workflow | Objectif | Produit |
|
||||
|------------------|-------------------------------------------------------------------------------------|-----------------------|
|
||||
| `bmad-quick-dev` | Flux rapide unifié — clarifie l'intention, planifie, implémente, révise et présente | `tech-spec.md` + code |
|
||||
| `bmad-quick-dev` | Flux rapide unifié — clarifie l'intention, planifie, implémente, révise et présente | `spec-*.md` + code |
|
||||
|
||||
## Gestion du Contexte
|
||||
|
||||
|
|
|
|||
|
|
@ -135,7 +135,7 @@ Créez-le manuellement dans `_bmad-output/project-context.md` ou générez-le ap
|
|||
|
||||
Tous les workflows de cette phase sont optionnels :
|
||||
- **brainstorming** (`bmad-brainstorming`) — Idéation guidée
|
||||
- **research** (`bmad-research`) — Recherche marché et technique
|
||||
- **research** (`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`) — Recherche marché, domaine et technique
|
||||
- **create-product-brief** (`bmad-create-product-brief`) — Document de base recommandé
|
||||
|
||||
### Phase 2 : Planification (Requis)
|
||||
|
|
@ -233,13 +233,13 @@ your-project/
|
|||
## Questions fréquentes
|
||||
|
||||
**Ai-je toujours besoin d'une architecture ?**
|
||||
Uniquement pour les voies méthode BMad et Enterprise. Quick Dev passe directement de la spécification technique (tech-spec) à l'implémentation.
|
||||
Uniquement pour les voies méthode BMad et Enterprise. Quick Dev passe directement de la spécification technique (spec) à l'implémentation.
|
||||
|
||||
**Puis-je modifier mon plan plus tard ?**
|
||||
Oui. Utilisez `bmad-correct-course` pour gérer les changements de périmètre.
|
||||
|
||||
**Et si je veux d'abord faire du brainstorming ?**
|
||||
Invoquez l'agent Analyst (`bmad-analyst`) et exécutez `bmad-brainstorming` (`bmad-brainstorming`) avant de commencer votre PRD.
|
||||
Invoquez l'agent Analyst (`bmad-agent-analyst`) et exécutez `bmad-brainstorming` (`bmad-brainstorming`) avant de commencer votre PRD.
|
||||
|
||||
**Dois-je suivre un ordre strict ?**
|
||||
Pas strictement. Une fois que vous maîtrisez le flux, vous pouvez exécuter les workflows directement en utilisant la référence rapide ci-dessus.
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ Add persistent context the agent will always remember:
|
|||
```yaml
|
||||
memories:
|
||||
- 'Works at Krusty Krab'
|
||||
- 'Favorite Celebrity: David Hasslehoff'
|
||||
- 'Favorite Celebrity: David Hasselhoff'
|
||||
- 'Learned in Epic 1 that it is not cool to just pretend that tests have passed'
|
||||
```
|
||||
|
||||
|
|
@ -128,7 +128,7 @@ prompts:
|
|||
|
||||
### 3. Apply Your Changes
|
||||
|
||||
After editing, recompile the agent to apply changes:
|
||||
After editing, reinstall to apply changes:
|
||||
|
||||
```bash
|
||||
npx bmad-method install
|
||||
|
|
@ -138,17 +138,16 @@ The installer detects the existing installation and offers these options:
|
|||
|
||||
| Option | What It Does |
|
||||
| ---------------------------- | ------------------------------------------------------------------- |
|
||||
| **Quick Update** | Updates all modules to the latest version and recompiles all agents |
|
||||
| **Recompile Agents** | Applies customizations only, without updating module files |
|
||||
| **Quick Update** | Updates all modules to the latest version and applies customizations |
|
||||
| **Modify BMad Installation** | Full installation flow for adding or removing modules |
|
||||
|
||||
For customization-only changes, **Recompile Agents** is the fastest option.
|
||||
For customization-only changes, **Quick Update** is the fastest option.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Changes not appearing?**
|
||||
|
||||
- Run `npx bmad-method install` and select **Recompile Agents** to apply changes
|
||||
- Run `npx bmad-method install` and select **Quick Update** to apply changes
|
||||
- Check that your YAML syntax is valid (indentation matters)
|
||||
- Verify you edited the correct `.customize.yaml` file for the agent
|
||||
|
||||
|
|
@ -161,7 +160,7 @@ For customization-only changes, **Recompile Agents** is the fastest option.
|
|||
**Need to reset an agent?**
|
||||
|
||||
- Clear or delete the agent's `.customize.yaml` file
|
||||
- Run `npx bmad-method install` and select **Recompile Agents** to restore defaults
|
||||
- Run `npx bmad-method install` and select **Quick Update** to restore defaults
|
||||
|
||||
## Workflow Customization
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Requires [Node.js](https://nodejs.org) v20+ and `npx` (included with npm).
|
|||
| `--modules <modules>` | Comma-separated module IDs | `--modules bmm,bmb` |
|
||||
| `--tools <tools>` | Comma-separated tool/IDE IDs (use `none` to skip) | `--tools claude-code,cursor` or `--tools none` |
|
||||
| `--custom-content <paths>` | Comma-separated paths to custom modules | `--custom-content ~/my-module,~/another-module` |
|
||||
| `--action <type>` | Action for existing installations: `install` (default), `update`, `quick-update`, or `compile-agents` | `--action quick-update` |
|
||||
| `--action <type>` | Action for existing installations: `install` (default), `update`, or `quick-update` | `--action quick-update` |
|
||||
|
||||
### Core Configuration
|
||||
|
||||
|
|
@ -121,7 +121,7 @@ npx bmad-method install \
|
|||
## What You Get
|
||||
|
||||
- A fully configured `_bmad/` directory in your project
|
||||
- Compiled agents and workflows for your selected modules and tools
|
||||
- Agents and workflows configured for your selected modules and tools
|
||||
- A `_bmad-output/` folder for generated artifacts
|
||||
|
||||
## Validation and Error Handling
|
||||
|
|
@ -132,7 +132,7 @@ BMad validates all provided flags:
|
|||
- **Modules** — Warns about invalid module IDs (but won't fail)
|
||||
- **Tools** — Warns about invalid tool IDs (but won't fail)
|
||||
- **Custom Content** — Each path must contain a valid `module.yaml` file
|
||||
- **Action** — Must be one of: `install`, `update`, `quick-update`, `compile-agents`
|
||||
- **Action** — Must be one of: `install`, `update`, `quick-update`
|
||||
|
||||
Invalid values will either:
|
||||
1. Show an error and exit (for critical options like directory)
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ Skip phases 1-3 for small, well-understood work.
|
|||
|
||||
| Workflow | Purpose | Produces |
|
||||
| ------------------ | --------------------------------------------------------------------------- | ---------------------- |
|
||||
| `bmad-quick-dev` | Unified quick flow — clarify intent, plan, implement, review, and present | `tech-spec.md` + code |
|
||||
| `bmad-quick-dev` | Unified quick flow — clarify intent, plan, implement, review, and present | `spec-*.md` + code |
|
||||
|
||||
## Context Management
|
||||
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ BMad helps you build software through guided workflows with specialized AI agent
|
|||
| Phase | Name | What Happens |
|
||||
| ----- | -------------- | --------------------------------------------------- |
|
||||
| 1 | Analysis | Brainstorming, research, product brief *(optional)* |
|
||||
| 2 | Planning | Create requirements (PRD or tech-spec) |
|
||||
| 2 | Planning | Create requirements (PRD or spec) |
|
||||
| 3 | Solutioning | Design architecture *(BMad Method/Enterprise only)* |
|
||||
| 4 | Implementation | Build epic by epic, story by story |
|
||||
|
||||
|
|
@ -114,7 +114,7 @@ BMad-Help will detect what you've completed and recommend exactly what to do nex
|
|||
:::
|
||||
|
||||
:::note[How to Load Agents and Run Workflows]
|
||||
Each workflow has a **skill** you invoke by name in your IDE (e.g., `bmad-create-prd`). Your AI tool will recognize the `bmad-*` name and run it — you don't need to load agents separately. You can also invoke an agent skill directly for general conversation (e.g., `bmad-pm` for the PM agent).
|
||||
Each workflow has a **skill** you invoke by name in your IDE (e.g., `bmad-create-prd`). Your AI tool will recognize the `bmad-*` name and run it — you don't need to load agents separately. You can also invoke an agent skill directly for general conversation (e.g., `bmad-agent-pm` for the PM agent).
|
||||
:::
|
||||
|
||||
:::caution[Fresh Chats]
|
||||
|
|
@ -135,13 +135,13 @@ Create it manually at `_bmad-output/project-context.md` or generate it after arc
|
|||
|
||||
All workflows in this phase are optional:
|
||||
- **brainstorming** (`bmad-brainstorming`) — Guided ideation
|
||||
- **research** (`bmad-research`) — Market and technical research
|
||||
- **research** (`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`) — Market, domain, and technical research
|
||||
- **create-product-brief** (`bmad-create-product-brief`) — Recommended foundation document
|
||||
|
||||
### Phase 2: Planning (Required)
|
||||
|
||||
**For BMad Method and Enterprise tracks:**
|
||||
1. Invoke the **PM agent** (`bmad-pm`) in a new chat
|
||||
1. Invoke the **PM agent** (`bmad-agent-pm`) in a new chat
|
||||
2. Run the `bmad-create-prd` workflow (`bmad-create-prd`)
|
||||
3. Output: `PRD.md`
|
||||
|
||||
|
|
@ -149,13 +149,13 @@ All workflows in this phase are optional:
|
|||
- Run `bmad-quick-dev` — it handles planning and implementation in a single workflow, skip to implementation
|
||||
|
||||
:::note[UX Design (Optional)]
|
||||
If your project has a user interface, invoke the **UX-Designer agent** (`bmad-ux-designer`) and run the UX design workflow (`bmad-create-ux-design`) after creating your PRD.
|
||||
If your project has a user interface, invoke the **UX-Designer agent** (`bmad-agent-ux-designer`) and run the UX design workflow (`bmad-create-ux-design`) after creating your PRD.
|
||||
:::
|
||||
|
||||
### Phase 3: Solutioning (BMad Method/Enterprise)
|
||||
|
||||
**Create Architecture**
|
||||
1. Invoke the **Architect agent** (`bmad-architect`) in a new chat
|
||||
1. Invoke the **Architect agent** (`bmad-agent-architect`) in a new chat
|
||||
2. Run `bmad-create-architecture` (`bmad-create-architecture`)
|
||||
3. Output: Architecture document with technical decisions
|
||||
|
||||
|
|
@ -165,12 +165,12 @@ If your project has a user interface, invoke the **UX-Designer agent** (`bmad-ux
|
|||
Epics and stories are now created *after* architecture. This produces better quality stories because architecture decisions (database, API patterns, tech stack) directly affect how work should be broken down.
|
||||
:::
|
||||
|
||||
1. Invoke the **PM agent** (`bmad-pm`) in a new chat
|
||||
1. Invoke the **PM agent** (`bmad-agent-pm`) in a new chat
|
||||
2. Run `bmad-create-epics-and-stories` (`bmad-create-epics-and-stories`)
|
||||
3. The workflow uses both PRD and Architecture to create technically-informed stories
|
||||
|
||||
**Implementation Readiness Check** *(Highly Recommended)*
|
||||
1. Invoke the **Architect agent** (`bmad-architect`) in a new chat
|
||||
1. Invoke the **Architect agent** (`bmad-agent-architect`) in a new chat
|
||||
2. Run `bmad-check-implementation-readiness` (`bmad-check-implementation-readiness`)
|
||||
3. Validates cohesion across all planning documents
|
||||
|
||||
|
|
@ -180,7 +180,7 @@ Once planning is complete, move to implementation. **Each workflow should run in
|
|||
|
||||
### Initialize Sprint Planning
|
||||
|
||||
Invoke the **SM agent** (`bmad-sm`) and run `bmad-sprint-planning` (`bmad-sprint-planning`). This creates `sprint-status.yaml` to track all epics and stories.
|
||||
Invoke the **SM agent** (`bmad-agent-sm`) and run `bmad-sprint-planning` (`bmad-sprint-planning`). This creates `sprint-status.yaml` to track all epics and stories.
|
||||
|
||||
### The Build Cycle
|
||||
|
||||
|
|
@ -192,7 +192,7 @@ For each story, repeat this cycle with fresh chats:
|
|||
| 2 | DEV | `bmad-dev-story` | `bmad-dev-story` | Implement the story |
|
||||
| 3 | DEV | `bmad-code-review` | `bmad-code-review` | Quality validation *(recommended)* |
|
||||
|
||||
After completing all stories in an epic, invoke the **SM agent** (`bmad-sm`) and run `bmad-retrospective` (`bmad-retrospective`).
|
||||
After completing all stories in an epic, invoke the **SM agent** (`bmad-agent-sm`) and run `bmad-retrospective` (`bmad-retrospective`).
|
||||
|
||||
## What You've Accomplished
|
||||
|
||||
|
|
@ -237,13 +237,13 @@ your-project/
|
|||
## Common Questions
|
||||
|
||||
**Do I always need architecture?**
|
||||
Only for BMad Method and Enterprise tracks. Quick Flow skips from tech-spec to implementation.
|
||||
Only for BMad Method and Enterprise tracks. Quick Flow skips from spec to implementation.
|
||||
|
||||
**Can I change my plan later?**
|
||||
Yes. The SM agent has a `bmad-correct-course` workflow (`bmad-correct-course`) for handling scope changes.
|
||||
|
||||
**What if I want to brainstorm first?**
|
||||
Invoke the Analyst agent (`bmad-analyst`) and run `bmad-brainstorming` (`bmad-brainstorming`) before starting your PRD.
|
||||
Invoke the Analyst agent (`bmad-agent-analyst`) and run `bmad-brainstorming` (`bmad-brainstorming`) before starting your PRD.
|
||||
|
||||
**Do I need to follow a strict order?**
|
||||
Not strictly. Once you learn the flow, you can run workflows directly using the Quick Reference above.
|
||||
|
|
|
|||
|
|
@ -4,6 +4,6 @@ template: splash
|
|||
---
|
||||
|
||||
|
||||
您查找的页面不存在或已被移动。
|
||||
你访问的页面不存在，或已被移动。
|
||||
|
||||
[返回首页](./index.md)
|
||||
[返回中文首页](./index.md)
|
||||
|
|
|
|||
|
|
@ -1,25 +1,25 @@
|
|||
---
|
||||
title: "Documentation Style Guide"
|
||||
description: Project-specific documentation conventions based on Google style and Diataxis structure
|
||||
description: 基于 Google 文档风格与 Diataxis 的项目文档规范
|
||||
---
|
||||
|
||||
This project adheres to the [Google Developer Documentation Style Guide](https://developers.google.com/style) and uses [Diataxis](https://diataxis.fr/) to structure content. Only project-specific conventions follow.
|
||||
本项目遵循 [Google Developer Documentation Style Guide](https://developers.google.com/style)，并使用 [Diataxis](https://diataxis.fr/) 组织文档。以下仅补充项目级约束。
|
||||
|
||||
## Project-Specific Rules
|
||||
## 项目特定规则
|
||||
|
||||
| Rule | Specification |
|
||||
| -------------------------------- | ---------------------------------------- |
|
||||
| No horizontal rules (`---`) | Fragments reading flow |
|
||||
| No `####` headers | Use bold text or admonitions instead |
|
||||
| No "Related" or "Next:" sections | Sidebar handles navigation |
|
||||
| No deeply nested lists | Break into sections instead |
|
||||
| No code blocks for non-code | Use admonitions for dialogue examples |
|
||||
| No bold paragraphs for callouts | Use admonitions instead |
|
||||
| 1-2 admonitions per section max | Tutorials allow 3-4 per major section |
|
||||
| Table cells / list items | 1-2 sentences max |
|
||||
| Header budget | 8-12 `##` per doc; 2-3 `###` per section |
|
||||
| 规则 | 规范 |
|
||||
| --- | --- |
|
||||
| 禁用水平分割线（`---`） | 会打断阅读流 |
|
||||
| 禁用 `####` 标题 | 用加粗短句或 admonition 替代 |
|
||||
| 避免 “Related/Next” 章节 | 交给侧边栏导航 |
|
||||
| 避免深层嵌套列表 | 拆成新段落或新小节 |
|
||||
| 非代码内容不要放代码块 | 对话/提示用 admonition |
|
||||
| 不用整段粗体做提醒 | 统一用 admonition |
|
||||
| 每节 1-2 个 admonition | 教程大节可放宽到 3-4 个 |
|
||||
| 表格单元格/列表项 | 控制在 1-2 句 |
|
||||
| 标题预算 | 每篇约 8-12 个 `##`，每节 2-3 个 `###` |
|
||||
|
||||
## Admonitions (Starlight Syntax)
|
||||
## 提示块（Starlight 语法）
|
||||
|
||||
```md
|
||||
:::tip[Title]
|
||||
|
|
@ -39,38 +39,38 @@ Critical warnings only — data loss, security issues
|
|||
:::
|
||||
```
|
||||
|
||||
### Standard Uses
|
||||
### 标准用途
|
||||
|
||||
| Admonition | Use For |
|
||||
| ------------------------ | ----------------------------- |
|
||||
| `:::note[Prerequisites]` | Dependencies before starting |
|
||||
| `:::tip[Quick Path]` | TL;DR summary at document top |
|
||||
| `:::caution[Important]` | Critical caveats |
|
||||
| `:::note[Example]` | Command/response examples |
|
||||
| 提示块 | 适用场景 |
|
||||
| --- | --- |
|
||||
| `:::note[Prerequisites]` | 开始前依赖与前置条件 |
|
||||
| `:::tip[Quick Path]` | 文档顶部 TL;DR |
|
||||
| `:::caution[Important]` | 关键风险提醒 |
|
||||
| `:::note[Example]` | 命令/响应示例说明 |
|
||||
|
||||
## Standard Table Formats
|
||||
## 标准表格模板
|
||||
|
||||
**Phases:**
|
||||
**阶段（Phases）：**
|
||||
|
||||
```md
|
||||
| Phase | Name | What Happens |
|
||||
| ----- | -------- | -------------------------------------------- |
|
||||
| 1 | Analysis | Brainstorm, research *(optional)* |
|
||||
| 2 | Planning | Requirements — PRD or tech-spec *(required)* |
|
||||
| 2 | Planning | Requirements — PRD or spec *(required)* |
|
||||
```
|
||||
|
||||
**Commands:**
|
||||
**技能（Skills）：**
|
||||
|
||||
```md
|
||||
| Command | Agent | Purpose |
|
||||
| ------------ | ------- | ------------------------------------ |
|
||||
| `brainstorm` | Analyst | Brainstorm a new project |
|
||||
| `prd` | PM | Create Product Requirements Document |
|
||||
| Skill | Agent | Purpose |
|
||||
| -------------------- | ------- | ------------------------------------ |
|
||||
| `bmad-brainstorming` | Analyst | Brainstorm a new project |
|
||||
| `bmad-create-prd` | PM | Create Product Requirements Document |
|
||||
```
|
||||
|
||||
## Folder Structure Blocks
|
||||
## 文件结构块（Folder Structure）
|
||||
|
||||
Show in "What You've Accomplished" sections:
|
||||
用于 “What You've Accomplished” 类章节：
|
||||
|
||||
````md
|
||||
```
|
||||
|
|
@ -85,223 +85,223 @@ your-project/
|
|||
```
|
||||
````
|
||||
|
||||
## Tutorial Structure
|
||||
## 教程（Tutorial）结构
|
||||
|
||||
```text
|
||||
1. Title + Hook (1-2 sentences describing outcome)
|
||||
2. Version/Module Notice (info or warning admonition) (optional)
|
||||
3. What You'll Learn (bullet list of outcomes)
|
||||
4. Prerequisites (info admonition)
|
||||
5. Quick Path (tip admonition - TL;DR summary)
|
||||
6. Understanding [Topic] (context before steps - tables for phases/agents)
|
||||
7. Installation (optional)
|
||||
1. Title + Hook（1-2 句结果导向开场）
|
||||
2. Version/Module Notice（可选，信息或警告提示块）
|
||||
3. What You'll Learn（结果清单）
|
||||
4. Prerequisites（前置条件提示块）
|
||||
5. Quick Path（TL;DR 提示块）
|
||||
6. Understanding [Topic]（步骤前的背景说明，可配表格）
|
||||
7. Installation（可选）
|
||||
8. Step 1: [First Major Task]
|
||||
9. Step 2: [Second Major Task]
|
||||
10. Step 3: [Third Major Task]
|
||||
11. What You've Accomplished (summary + folder structure)
|
||||
12. Quick Reference (commands table)
|
||||
13. Common Questions (FAQ format)
|
||||
14. Getting Help (community links)
|
||||
15. Key Takeaways (tip admonition)
|
||||
11. What You've Accomplished（总结 + 文件结构）
|
||||
12. Quick Reference（skills 表）
|
||||
13. Common Questions（FAQ）
|
||||
14. Getting Help（社区入口）
|
||||
15. Key Takeaways（末尾 tip 提示块）
|
||||
```
|
||||
|
||||
### Tutorial Checklist
|
||||
### 教程检查清单
|
||||
|
||||
- [ ] Hook describes outcome in 1-2 sentences
|
||||
- [ ] "What You'll Learn" section present
|
||||
- [ ] Prerequisites in admonition
|
||||
- [ ] Quick Path TL;DR admonition at top
|
||||
- [ ] Tables for phases, commands, agents
|
||||
- [ ] "What You've Accomplished" section present
|
||||
- [ ] Quick Reference table present
|
||||
- [ ] Common Questions section present
|
||||
- [ ] Getting Help section present
|
||||
- [ ] Key Takeaways admonition at end
|
||||
- [ ] Hook 用 1-2 句明确结果
|
||||
- [ ] 包含 “What You'll Learn”
|
||||
- [ ] 前置条件放在 admonition
|
||||
- [ ] 顶部有 Quick Path TL;DR
|
||||
- [ ] 关键信息用 phases/skills/agents 表格
|
||||
- [ ] 包含 “What You've Accomplished”
|
||||
- [ ] 包含 Quick Reference 表
|
||||
- [ ] 包含 Common Questions
|
||||
- [ ] 包含 Getting Help
|
||||
- [ ] 末尾包含 Key Takeaways 提示块
|
||||
|
||||
## How-To Structure
|
||||
## How-to 结构
|
||||
|
||||
```text
|
||||
1. Title + Hook (one sentence: "Use the `X` workflow to...")
|
||||
2. When to Use This (bullet list of scenarios)
|
||||
3. When to Skip This (optional)
|
||||
4. Prerequisites (note admonition)
|
||||
5. Steps (numbered ### subsections)
|
||||
6. What You Get (output/artifacts produced)
|
||||
7. Example (optional)
|
||||
8. Tips (optional)
|
||||
9. Next Steps (optional)
|
||||
1. Title + Hook（单句，形如 "Use the `X` workflow to..."）
|
||||
2. When to Use This（3-5 条场景）
|
||||
3. When to Skip This（可选）
|
||||
4. Prerequisites（note 提示块）
|
||||
5. Steps（编号 `###` 动词开头）
|
||||
6. What You Get（产出物说明）
|
||||
7. Example（可选）
|
||||
8. Tips（可选）
|
||||
9. Next Steps（可选）
|
||||
```
|
||||
|
||||
### How-To Checklist
|
||||
### How-to 检查清单
|
||||
|
||||
- [ ] Hook starts with "Use the `X` workflow to..."
|
||||
- [ ] "When to Use This" has 3-5 bullet points
|
||||
- [ ] Prerequisites listed
|
||||
- [ ] Steps are numbered `###` subsections with action verbs
|
||||
- [ ] "What You Get" describes output artifacts
|
||||
- [ ] Hook 以 “Use the `X` workflow to...” 开头
|
||||
- [ ] “When to Use This” 有 3-5 条场景
|
||||
- [ ] 明确前置条件
|
||||
- [ ] 步骤为编号 `###` 子标题且动词开头
|
||||
- [ ] “What You Get” 明确产出物
|
||||
|
||||
## Explanation Structure
|
||||
## Explanation 结构
|
||||
|
||||
### Types
|
||||
### 类型
|
||||
|
||||
| Type | Example |
|
||||
| ----------------- | ----------------------------- |
|
||||
| **Index/Landing** | `core-concepts/index.md` |
|
||||
| **Concept** | `what-are-agents.md` |
|
||||
| **Feature** | `quick-dev.md` |
|
||||
| **Philosophy** | `why-solutioning-matters.md` |
|
||||
| **FAQ** | `established-projects-faq.md` |
|
||||
| 类型 | 示例 |
|
||||
| --- | --- |
|
||||
| **Index/Landing** | `core-concepts/index.md` |
|
||||
| **Concept** | `what-are-agents.md` |
|
||||
| **Feature** | `quick-dev.md` |
|
||||
| **Philosophy** | `why-solutioning-matters.md` |
|
||||
| **FAQ** | `established-projects-faq.md` |
|
||||
|
||||
### General Template
|
||||
### 通用模板
|
||||
|
||||
```text
|
||||
1. Title + Hook (1-2 sentences)
|
||||
2. Overview/Definition (what it is, why it matters)
|
||||
3. Key Concepts (### subsections)
|
||||
4. Comparison Table (optional)
|
||||
5. When to Use / When Not to Use (optional)
|
||||
6. Diagram (optional - mermaid, 1 per doc max)
|
||||
7. Next Steps (optional)
|
||||
1. Title + Hook（1-2 句）
|
||||
2. Overview/Definition（是什么，为什么重要）
|
||||
3. Key Concepts（`###` 小节）
|
||||
4. Comparison Table（可选）
|
||||
5. When to Use / When Not to Use（可选）
|
||||
6. Diagram（可选，单文档最多 1 个 mermaid）
|
||||
7. Next Steps（可选）
|
||||
```
|
||||
|
||||
### Index/Landing Pages
|
||||
### Index/Landing 页面
|
||||
|
||||
```text
|
||||
1. Title + Hook (one sentence)
|
||||
2. Content Table (links with descriptions)
|
||||
3. Getting Started (numbered list)
|
||||
4. Choose Your Path (optional - decision tree)
|
||||
1. Title + Hook（单句）
|
||||
2. Content Table（链接 + 描述）
|
||||
3. Getting Started（编号步骤）
|
||||
4. Choose Your Path（可选，决策树）
|
||||
```
|
||||
|
||||
### Concept Explainers
|
||||
### 概念解释页（Concept）
|
||||
|
||||
```text
|
||||
1. Title + Hook (what it is)
|
||||
2. Types/Categories (### subsections) (optional)
|
||||
1. Title + Hook（定义性开场）
|
||||
2. Types/Categories（可选，`###`）
|
||||
3. Key Differences Table
|
||||
4. Components/Parts
|
||||
5. Which Should You Use?
|
||||
6. Creating/Customizing (pointer to how-to guides)
|
||||
6. Creating/Customizing（指向 how-to）
|
||||
```
|
||||
|
||||
### Feature Explainers
|
||||
### 功能解释页（Feature）
|
||||
|
||||
```text
|
||||
1. Title + Hook (what it does)
|
||||
2. Quick Facts (optional - "Perfect for:", "Time to:")
|
||||
1. Title + Hook（功能作用）
|
||||
2. Quick Facts（可选）
|
||||
3. When to Use / When Not to Use
|
||||
4. How It Works (mermaid diagram optional)
|
||||
4. How It Works（可选 mermaid）
|
||||
5. Key Benefits
|
||||
6. Comparison Table (optional)
|
||||
7. When to Graduate/Upgrade (optional)
|
||||
6. Comparison Table（可选）
|
||||
7. When to Graduate/Upgrade（可选）
|
||||
```
|
||||
|
||||
### Philosophy/Rationale Documents
|
||||
### 原理/哲学页（Philosophy）
|
||||
|
||||
```text
|
||||
1. Title + Hook (the principle)
|
||||
1. Title + Hook（核心原则）
|
||||
2. The Problem
|
||||
3. The Solution
|
||||
4. Key Principles (### subsections)
|
||||
4. Key Principles（`###`）
|
||||
5. Benefits
|
||||
6. When This Applies
|
||||
```
|
||||
|
||||
### Explanation Checklist
|
||||
### Explanation 检查清单
|
||||
|
||||
- [ ] Hook states what document explains
|
||||
- [ ] Content in scannable `##` sections
|
||||
- [ ] Comparison tables for 3+ options
|
||||
- [ ] Diagrams have clear labels
|
||||
- [ ] Links to how-to guides for procedural questions
|
||||
- [ ] 2-3 admonitions max per document
|
||||
- [ ] Hook 清楚说明“本文解释什么”
|
||||
- [ ] 内容分布在可扫读的 `##` 区块
|
||||
- [ ] 3 个以上选项时使用对比表
|
||||
- [ ] 图示有清晰标签
|
||||
- [ ] 程序性问题链接到 how-to
|
||||
- [ ] 每篇控制在 2-3 个 admonition
|
||||
|
||||
## Reference Structure
|
||||
## Reference 结构
|
||||
|
||||
### Types
|
||||
### 类型
|
||||
|
||||
| Type | Example |
|
||||
| ----------------- | --------------------- |
|
||||
| **Index/Landing** | `workflows/index.md` |
|
||||
| **Catalog** | `agents/index.md` |
|
||||
| **Deep-Dive** | `document-project.md` |
|
||||
| **Configuration** | `core-tasks.md` |
|
||||
| **Glossary** | `glossary/index.md` |
|
||||
| **Comprehensive** | `bmgd-workflows.md` |
|
||||
| 类型 | 示例 |
|
||||
| --- | --- |
|
||||
| **Index/Landing** | `workflows/index.md` |
|
||||
| **Catalog** | `agents/index.md` |
|
||||
| **Deep-Dive** | `document-project.md` |
|
||||
| **Configuration** | `core-tasks.md` |
|
||||
| **Glossary** | `glossary/index.md` |
|
||||
| **Comprehensive** | `bmgd-workflows.md` |
|
||||
|
||||
### Reference Index Pages
|
||||
### Reference 索引页
|
||||
|
||||
```text
|
||||
1. Title + Hook (one sentence)
|
||||
2. Content Sections (## for each category)
|
||||
- Bullet list with links and descriptions
|
||||
1. Title + Hook（单句）
|
||||
2. Content Sections（每类一个 `##`）
|
||||
- 链接 + 简短描述
|
||||
```
|
||||
|
||||
### Catalog Reference
|
||||
### Catalog 参考页
|
||||
|
||||
```text
|
||||
1. Title + Hook
|
||||
2. Items (## for each item)
|
||||
- Brief description (one sentence)
|
||||
- **Commands:** or **Key Info:** as flat list
|
||||
3. Universal/Shared (## section) (optional)
|
||||
2. Items（每项一个 `##`）
|
||||
- 单句说明
|
||||
- **Skills:** 或 **Key Info:** 平铺列表
|
||||
3. Universal/Shared（可选）
|
||||
```
|
||||
|
||||
### Item Deep-Dive Reference
|
||||
### Deep-Dive 参考页
|
||||
|
||||
```text
|
||||
1. Title + Hook (one sentence purpose)
|
||||
2. Quick Facts (optional note admonition)
|
||||
- Module, Command, Input, Output as list
|
||||
3. Purpose/Overview (## section)
|
||||
4. How to Invoke (code block)
|
||||
5. Key Sections (## for each aspect)
|
||||
- Use ### for sub-options
|
||||
6. Notes/Caveats (tip or caution admonition)
|
||||
1. Title + Hook（单句说明用途）
|
||||
2. Quick Facts（可选 note 提示块）
|
||||
- Module, Skill, Input, Output
|
||||
3. Purpose/Overview（`##`）
|
||||
4. How to Invoke（代码块）
|
||||
5. Key Sections（每个方面一个 `##`）
|
||||
- 子选项使用 `###`
|
||||
6. Notes/Caveats（tip/caution）
|
||||
```
|
||||
|
||||
### Configuration Reference
|
||||
### Configuration 参考页
|
||||
|
||||
```text
|
||||
1. Title + Hook
|
||||
2. Table of Contents (jump links if 4+ items)
|
||||
3. Items (## for each config/task)
|
||||
- **Bold summary** — one sentence
|
||||
- **Use it when:** bullet list
|
||||
- **How it works:** numbered steps (3-5 max)
|
||||
- **Output:** expected result (optional)
|
||||
2. Table of Contents（可选，4 项以上建议）
|
||||
3. Items（每项一个 `##`）
|
||||
- **Bold summary**（单句）
|
||||
- **Use it when:** 场景列表
|
||||
- **How it works:** 3-5 步
|
||||
- **Output:**（可选）
|
||||
```
|
||||
|
||||
### Comprehensive Reference Guide
|
||||
### 综合参考页（Comprehensive）
|
||||
|
||||
```text
|
||||
1. Title + Hook
|
||||
2. Overview (## section)
|
||||
- Diagram or table showing organization
|
||||
3. Major Sections (## for each phase/category)
|
||||
- Items (### for each item)
|
||||
- Standardized fields: Command, Agent, Input, Output, Description
|
||||
4. Next Steps (optional)
|
||||
2. Overview（`##`）
|
||||
- 用图或表解释组织方式
|
||||
3. Major Sections（每个阶段/类别一个 `##`）
|
||||
- Items（每项 `###`）
|
||||
- 统一字段：Skill, Agent, Input, Output, Description
|
||||
4. Next Steps（可选）
|
||||
```
|
||||
|
||||
### Reference Checklist
|
||||
### Reference 检查清单
|
||||
|
||||
- [ ] Hook states what document references
|
||||
- [ ] Structure matches reference type
|
||||
- [ ] Items use consistent structure throughout
|
||||
- [ ] Tables for structured/comparative data
|
||||
- [ ] Links to explanation docs for conceptual depth
|
||||
- [ ] 1-2 admonitions max
|
||||
- [ ] Hook 说明“本文引用什么”
|
||||
- [ ] 结构匹配参考页类型
|
||||
- [ ] 条目结构前后一致
|
||||
- [ ] 结构化信息优先表格表达
|
||||
- [ ] 概念深度指向 explanation 页面
|
||||
- [ ] 每篇 1-2 个 admonition
|
||||
|
||||
## Glossary Structure
|
||||
## Glossary 结构
|
||||
|
||||
Starlight generates right-side "On this page" navigation from headers:
|
||||
Starlight 右侧 “On this page” 来自标题层级：
|
||||
|
||||
- Categories as `##` headers — appear in right nav
|
||||
- Terms in tables — compact rows, not individual headers
|
||||
- No inline TOC — right sidebar handles navigation
|
||||
- 分类使用 `##`（会进入右侧导航）
|
||||
- 术语放在表格行中（不要给每个术语单独标题）
|
||||
- 不要再写内联 TOC
|
||||
|
||||
### Table Format
|
||||
### 表格模板
|
||||
|
||||
```md
|
||||
## Category Name
|
||||
|
|
@ -312,17 +312,17 @@ Starlight generates right-side "On this page" navigation from headers:
|
|||
| **Workflow** | Multi-step guided process that orchestrates AI agent activities to produce deliverables. |
|
||||
```
|
||||
|
||||
### Definition Rules
|
||||
### 定义规则
|
||||
|
||||
| Do | Don't |
|
||||
| ----------------------------- | ------------------------------------------- |
|
||||
| Start with what it IS or DOES | Start with "This is..." or "A [term] is..." |
|
||||
| Keep to 1-2 sentences | Write multi-paragraph explanations |
|
||||
| Bold term name in cell | Use plain text for terms |
|
||||
| 推荐 | 避免 |
|
||||
| --- | --- |
|
||||
| 直接写“它是什么/做什么” | 以 “This is...” 或 “A [term] is...” 开头 |
|
||||
| 控制在 1-2 句 | 多段长解释 |
|
||||
| 术语名称加粗 | 术语用普通文本 |
|
||||
|
||||
### Context Markers
|
||||
### 语境标记（Context Markers）
|
||||
|
||||
Add italic context at definition start for limited-scope terms:
|
||||
在定义开头用斜体标记适用范围：
|
||||
|
||||
- `*Quick Flow only.*`
|
||||
- `*BMad Method/Enterprise.*`
|
||||
|
|
@ -330,16 +330,16 @@ Add italic context at definition start for limited-scope terms:
|
|||
- `*BMGD.*`
|
||||
- `*Established projects.*`
|
||||
|
||||
### Glossary Checklist
|
||||
### Glossary 检查清单
|
||||
|
||||
- [ ] Terms in tables, not individual headers
|
||||
- [ ] Terms alphabetized within categories
|
||||
- [ ] Definitions 1-2 sentences
|
||||
- [ ] Context markers italicized
|
||||
- [ ] Term names bolded in cells
|
||||
- [ ] No "A [term] is..." definitions
|
||||
- [ ] 术语以表格维护，不用独立标题
|
||||
- [ ] 同分类内按字母序排序
|
||||
- [ ] 定义控制在 1-2 句
|
||||
- [ ] 语境标记使用斜体
|
||||
- [ ] 术语名称在单元格中加粗
|
||||
- [ ] 避免 “A [term] is...” 句式
|
||||
|
||||
## FAQ Sections
|
||||
## FAQ 章节模板
|
||||
|
||||
```md
|
||||
## Questions
|
||||
|
|
@ -353,18 +353,18 @@ Only for BMad Method and Enterprise tracks. Quick Flow skips to implementation.
|
|||
|
||||
### Can I change my plan later?
|
||||
|
||||
Yes. The SM agent has a `correct-course` workflow for handling scope changes.
|
||||
Yes. The SM agent has a `bmad-correct-course` workflow for handling scope changes.
|
||||
|
||||
**Have a question not answered here?** [Open an issue](...) or ask in [Discord](...).
|
||||
```
|
||||
|
||||
## Validation Commands
|
||||
## 校验命令
|
||||
|
||||
Before submitting documentation changes:
|
||||
提交文档改动前，建议执行：
|
||||
|
||||
```bash
|
||||
npm run docs:fix-links # Preview link format fixes
|
||||
npm run docs:fix-links -- --write # Apply fixes
|
||||
npm run docs:validate-links # Check links exist
|
||||
npm run docs:build # Verify no build errors
|
||||
npm run docs:fix-links # 预览链接修复结果
|
||||
npm run docs:fix-links -- --write # 写回链接修复
|
||||
npm run docs:validate-links # 校验链接是否存在
|
||||
npm run docs:build # 校验站点构建
|
||||
```
|
||||
|
|
|
|||
|
|
@ -5,58 +5,55 @@ sidebar:
|
|||
order: 6
|
||||
---
|
||||
|
||||
让 LLM 重新审视它刚刚生成的内容。你选择一种推理方法，它将该方法应用于自己的输出，然后你决定是否保留改进。
|
||||
高级启发（advanced elicitation）是“第二轮思考”机制：不是笼统地让模型“再来一次”，而是让它按指定推理方法重审自己的输出。
|
||||
|
||||
## 什么是高级启发？
|
||||
## 它是什么
|
||||
|
||||
结构化的第二轮处理。与其要求 AI "再试一次" 或 "做得更好"，不如选择一种特定的推理方法，让 AI 通过该视角重新审视自己的输出。
|
||||
你先有一版输出（方案、文案、分析或规范），再通过某种推理框架做二次审视，例如：
|
||||
- 事前复盘（Pre-mortem）
|
||||
- 第一性原理
|
||||
- 逆向思维（Inversion）
|
||||
- 红队/蓝队
|
||||
- 苏格拉底式追问
|
||||
|
||||
这种区别很重要。模糊的请求会产生模糊的修订。命名的方法会强制采用特定的攻击角度，揭示出通用重试会遗漏的见解。
|
||||
这种“带方法名的重审”通常比“再优化一下”更有效，因为它会强制模型从特定角度进攻已有答案。
|
||||
|
||||
## 何时使用
|
||||
## 什么时候使用
|
||||
|
||||
- 在工作流生成内容后，你想要替代方案
|
||||
- 当输出看起来还可以，但你怀疑还有更深层次的内容
|
||||
- 对假设进行压力测试或发现弱点
|
||||
- 对于重新思考有帮助的高风险内容
|
||||
- 你已有可用初稿，但怀疑还不够扎实
|
||||
- 你想压力测试关键假设或找潜在漏洞
|
||||
- 你面对高风险内容，需要更高置信度
|
||||
- 你想要替代解法，而不是同义改写
|
||||
|
||||
工作流在决策点提供高级启发——在 LLM 生成某些内容后，系统会询问你是否要运行它。
|
||||
## 它如何运行
|
||||
|
||||
## 工作原理
|
||||
1. 模型先给出若干与你内容相关的方法候选
|
||||
2. 你选择一种（或重抽）
|
||||
3. 模型按该方法重审并展示改进
|
||||
4. 你决定采纳、丢弃、继续下一轮或结束
|
||||
|
||||
1. LLM 为你的内容建议 5 种相关方法
|
||||
2. 你选择一种（或重新洗牌以获取不同选项）
|
||||
3. 应用方法，显示改进
|
||||
4. 接受或丢弃，重复或继续
|
||||
|
||||
## 内置方法
|
||||
|
||||
有数十种推理方法可用。几个示例：
|
||||
|
||||
- **事前复盘** - 假设项目已经失败，反向推导找出原因
|
||||
- **第一性原理思维** - 剥离假设，从基本事实重建
|
||||
- **逆向思维** - 询问如何保证失败，然后避免这些事情
|
||||
- **红队对蓝队** - 攻击你自己的工作，然后为它辩护
|
||||
- **苏格拉底式提问** - 用"为什么？"和"你怎么知道？"挑战每个主张
|
||||
- **约束移除** - 放下所有约束，看看有什么变化，然后有选择地加回
|
||||
- **利益相关者映射** - 从每个利益相关者的角度重新评估
|
||||
- **类比推理** - 在其他领域找到平行案例并应用其教训
|
||||
|
||||
还有更多。AI 会为你的内容选择最相关的选项——你选择运行哪一个。
|
||||
|
||||
:::tip[从这里开始]
|
||||
对于任何规范或计划，事前复盘都是一个很好的首选。它始终能找到标准审查会遗漏的空白。
|
||||
:::tip[实战建议]
|
||||
做规格、方案或计划时，先跑一次“事前复盘”通常收益最高，容易提前暴露隐藏风险。
|
||||
:::
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
如果你还处在方向发散阶段，可先用 [头脑风暴](./brainstorming.md)；如果你需要多角色权衡讨论，可用 [派对模式](./party-mode.md)。在进入实现前做问题发现时，可结合 [对抗性评审](./adversarial-review.md)。
|
||||
|
||||
- **LLM**：大语言模型。一种基于深度学习的自然语言处理模型，能够理解和生成人类语言。
|
||||
- **elicitation**：启发。在人工智能与提示工程中，指通过特定方法引导模型生成更高质量或更符合预期的输出。
|
||||
- **pre-mortem analysis**：事前复盘。一种风险管理技术，假设项目已经失败，然后反向推导可能的原因，以提前识别和预防潜在问题。
|
||||
- **first principles thinking**：第一性原理思维。一种将复杂问题分解为最基本事实或假设，然后从这些基本要素重新构建解决方案的思维方式。
|
||||
- **inversion**：逆向思维。通过思考如何导致失败来避免失败，从而找到成功路径的思维方式。
|
||||
- **red team vs blue team**：红队对蓝队。一种模拟对抗的方法，红队负责攻击和发现问题，蓝队负责防御和解决问题。
|
||||
- **socratic questioning**：苏格拉底式提问。一种通过连续提问来揭示假设、澄清概念和深入思考的对话方法。
|
||||
- **stakeholder mapping**：利益相关者映射。识别并分析项目中所有利益相关者及其利益、影响和关系的系统性方法。
|
||||
- **analogical reasoning**：类比推理。通过将当前问题与已知相似领域的问题进行比较，从而借鉴解决方案或见解的推理方式。
|
||||
## 与相近模式的区别
|
||||
|
||||
| 模式 | 核心目标 | 典型输入 | 典型输出 |
|
||||
| ----- | ----- | ----- | ----- |
|
||||
| `advanced elicitation` | 二次推理与补强 | 已有初稿/方案 | 风险更清晰、论证更完整的改进版 |
|
||||
| `bmad-brainstorming` | 发散创意并收敛 | 目标模糊或方向开放 | 想法池与行动方向 |
|
||||
| `bmad-party-mode` | 多角色讨论权衡 | 需要跨角色协同判断 | 多视角共识或争议点 |
|
||||
|
||||
## 使用边界
|
||||
|
||||
- 它不能替代原始输入质量：初稿太空，二次推理也会受限
|
||||
- 它会产出更多“可疑问题”，需要你做人工判别
|
||||
- 连续多轮会出现收益递减，建议在关键决策点使用
|
||||
|
||||
## 继续阅读
|
||||
|
||||
- [头脑风暴](./brainstorming.md)
|
||||
- [派对模式](./party-mode.md)
|
||||
- [对抗性评审](./adversarial-review.md)
|
||||
|
|
|
|||
|
|
@ -1,71 +1,73 @@
|
|||
---
|
||||
title: "对抗性评审"
|
||||
description: 防止懒惰"看起来不错"评审的强制推理技术
|
||||
description: 防止懒惰“看起来不错”评审的强制推理技术
|
||||
sidebar:
|
||||
order: 5
|
||||
---
|
||||
|
||||
通过要求发现问题来强制进行更深入的分析。
|
||||
对抗性评审（adversarial review）是一种“强制找问题”的评审方法：不允许直接“Looks good”，必须给出可验证发现，或者明确解释为什么没有发现。
|
||||
|
||||
## 什么是对抗性评审？
|
||||
## 它是什么
|
||||
|
||||
一种评审技术，评审者*必须*发现问题。不允许"看起来不错"。评审者采取怀疑态度——假设问题存在并找到它们。
|
||||
常规评审容易落入确认偏差：快速扫一遍，没有明显报错，就批准。
|
||||
对抗性评审反过来要求评审者先假设“问题存在”，再去定位证据。
|
||||
|
||||
这不是为了消极。而是为了强制进行真正的分析，而不是对提交的内容进行草率浏览并盖章批准。
|
||||
|
||||
**核心规则：**你必须发现问题。零发现会触发停止——重新分析或解释原因。
|
||||
核心规则：
|
||||
- 必须产出问题发现或明确的无发现理由
|
||||
- 发现要具体、可追溯、可操作
|
||||
- 评审对象是工件本身，而不是作者意图
|
||||
|
||||
## 为什么有效
|
||||
|
||||
普通评审容易受到确认偏差的影响。你浏览工作，没有发现突出的问题，就批准了它。"发现问题"的指令打破了这种模式：
|
||||
|
||||
- **强制彻底性**——在你足够努力地查看以发现问题之前，不能批准
|
||||
- **捕捉遗漏**——"这里缺少什么？"成为一个自然的问题
|
||||
- **提高信号质量**——发现是具体且可操作的，而不是模糊的担忧
|
||||
- **信息不对称**——在新的上下文中运行评审（无法访问原始推理），以便你评估的是工件，而不是意图
|
||||
- 强制深入阅读，减少“浏览式批准”
|
||||
- 更容易发现“缺了什么”，不只看“写错了什么”
|
||||
- 发现通常更结构化，便于后续分诊与修复
|
||||
- 在新上下文评审时，能降低“先入为主”偏差
|
||||
|
||||
## 在哪里使用
|
||||
|
||||
对抗性评审出现在 BMad 工作流程的各个地方——代码评审、实施就绪检查、规范验证等。有时它是必需步骤，有时是可选的（如高级启发或派对模式）。该模式适应任何需要审查的工件。
|
||||
它不是某个单一 workflow 独占，而是一种可复用评审模式，常见于：
|
||||
- 代码评审
|
||||
- 规范/方案评审
|
||||
- 实施就绪检查
|
||||
- 高风险改动复核
|
||||
|
||||
## 需要人工过滤
|
||||
## 你需要知道的限制
|
||||
|
||||
因为 AI 被*指示*要发现问题，它就会发现问题——即使问题不存在。预期会有误报：伪装成问题的吹毛求疵、对意图的误解，或完全幻觉化的担忧。
|
||||
因为系统被要求“必须找问题”，它会提高召回率，也会提高误报率。
|
||||
你会看到：
|
||||
- 吹毛求疵型发现
|
||||
- 语义误解型发现
|
||||
- 偶发幻觉型发现
|
||||
|
||||
**你决定什么是真实的。**审查每个发现，忽略噪音，修复重要的内容。
|
||||
所以它本质上是**高召回、需人工分诊**的策略，而不是“自动真理机”。
|
||||
|
||||
## 示例
|
||||
|
||||
而不是：
|
||||
|
||||
> "身份验证实现看起来合理。已批准。"
|
||||
|
||||
对抗性评审产生：
|
||||
|
||||
> 1. **高** - `login.ts:47` - 失败尝试没有速率限制
|
||||
> 2. **高** - 会话令牌存储在 localStorage 中（易受 XSS 攻击）
|
||||
> 3. **中** - 密码验证仅在客户端进行
|
||||
> 4. **中** - 失败登录尝试没有审计日志
|
||||
> 5. **低** - 魔法数字 `3600` 应该是 `SESSION_TIMEOUT_SECONDS`
|
||||
|
||||
第一个评审可能会遗漏安全漏洞。第二个发现了四个。
|
||||
|
||||
## 迭代和收益递减
|
||||
|
||||
在处理发现后，考虑再次运行。第二轮通常会捕获更多。第三轮也不总是无用的。但每一轮都需要时间，最终你会遇到收益递减——只是吹毛求疵和虚假发现。
|
||||
|
||||
:::tip[更好的评审]
|
||||
假设问题存在。寻找缺失的内容，而不仅仅是错误的内容。
|
||||
:::caution[关键心法]
|
||||
把发现分成三类：必须修、可延后、可忽略。评审质量的关键不在”发现数量”，而在分诊质量。
|
||||
:::
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
如果你想把该策略放进快速实现节奏中，可参见 [快速开发](./quick-dev.md)；若要做多轮推理补强，可参见 [高级启发](./advanced-elicitation.md)。整体流程位置请见 [工作流地图](../reference/workflow-map.md)。
|
||||
|
||||
- **adversarial review**：对抗性评审。一种强制评审者必须发现问题的评审技术，旨在防止草率批准。
|
||||
- **confirmation bias**：确认偏差。倾向于寻找、解释和记忆符合自己已有信念的信息的心理倾向。
|
||||
- **information asymmetry**：信息不对称。交易或评审中一方拥有比另一方更多或更好信息的情况。
|
||||
- **false positives**：误报。错误地将不存在的问题识别为存在的问题。
|
||||
- **diminishing returns**：收益递减。在投入持续增加的情况下，产出增长逐渐减少的现象。
|
||||
- **XSS**：跨站脚本攻击（Cross-Site Scripting）。一种安全漏洞，攻击者可在网页中注入恶意脚本。
|
||||
- **localStorage**：本地存储。浏览器提供的 Web Storage API，用于在客户端存储键值对数据。
|
||||
- **magic number**：魔法数字。代码中直接出现的未命名数值常量，缺乏语义含义。
|
||||
## 与 Quick Dev 的关系
|
||||
|
||||
`bmad-quick-dev` 关注执行效率与边界控制；对抗性评审关注问题发现质量。
|
||||
一个解决“跑得稳不稳”，一个解决“看得深不深”，两者互补而非替代。
|
||||
|
||||
## 示例（对比）
|
||||
|
||||
普通评审可能是：
|
||||
> “实现基本没问题，先过。”
|
||||
|
||||
对抗性评审更像：
|
||||
> 1. HIGH：`login.ts` 缺失失败重试限流
|
||||
> 2. HIGH：会话令牌存储在 `localStorage`，存在 XSS 风险
|
||||
> 3. MEDIUM：失败登录缺少审计日志
|
||||
> 4. LOW：魔法数字 `3600` 建议替换为命名常量
|
||||
|
||||
重点不是“更凶”，而是“更可执行”。
|
||||
|
||||
## 继续阅读
|
||||
|
||||
- [快速开发](./quick-dev.md)
|
||||
- [高级启发](./advanced-elicitation.md)
|
||||
- [工作流地图](../reference/workflow-map.md)
|
||||
|
|
|
|||
|
|
@ -5,39 +5,59 @@ sidebar:
|
|||
order: 2
|
||||
---
|
||||
|
||||
通过引导式探索释放你的创造力。
|
||||
`bmad-brainstorming` 是一个“思考引导”工作流：它不替你拍脑袋给答案，而是用结构化提问把你的想法挖出来、扩展开、再收敛成可执行方向。
|
||||
|
||||
## 什么是头脑风暴？
|
||||
## 它是什么
|
||||
|
||||
运行 `brainstorming`，你就拥有了一位创意引导者，帮助你从自身挖掘想法——而不是替你生成想法。AI 充当教练和向导，使用经过验证的技术，创造让你最佳思维涌现的条件。
|
||||
头脑风暴（brainstorming）适合”我有方向，但还不够清晰”的阶段。你会和 AI 进行来回探索：
|
||||
- 明确问题和约束
|
||||
- 生成备选想法
|
||||
- 对想法分组和优先级排序
|
||||
- 形成下一步行动
|
||||
|
||||
**适用于：**
|
||||
产出通常是一份可回看的会话文档，便于继续深化或与团队同步。
|
||||
|
||||
- 突破创意瓶颈
|
||||
- 生成产品或功能想法
|
||||
- 从新角度探索问题
|
||||
- 将原始概念发展为行动计划
|
||||
## 什么时候使用
|
||||
|
||||
## 工作原理
|
||||
- 你卡在创意瓶颈，知道问题但想不到可行解
|
||||
- 你要做新功能或新产品，需要更多备选方案
|
||||
- 你希望从不同角度挑战既有假设
|
||||
- 你希望把“模糊想法”推进到“可执行方向”
|
||||
|
||||
1. **设置** - 定义主题、目标、约束
|
||||
2. **选择方法** - 自己选择技术、获取 AI 推荐、随机选择或遵循渐进式流程
|
||||
3. **引导** - 通过探索性问题和协作式教练引导完成技术
|
||||
4. **组织** - 将想法按主题分组并确定优先级
|
||||
5. **行动** - 为顶级想法制定下一步和成功指标
|
||||
## 不适合的场景
|
||||
|
||||
所有内容都会被记录在会议文档中，你可以稍后参考或与利益相关者分享。
|
||||
- 你已经有清晰方案，只差落地实现
|
||||
- 你需要的是对现有文本做二次推理校验
|
||||
- 你需要多角色辩论来做跨职能权衡
|
||||
|
||||
:::note[你的想法]
|
||||
每个想法都来自你。工作流程创造洞察的条件——你是源头。
|
||||
在这些场景下，更合适的是：
|
||||
- `advanced elicitation`：对已有输出做结构化二次推理
|
||||
- `bmad-party-mode`：让多个角色在同一会话内讨论权衡
|
||||
|
||||
## 它怎么推进思考
|
||||
|
||||
1. **设定主题**：定义目标、边界、约束
|
||||
2. **选择方法**：手动选、让 AI 推荐、随机抽取或渐进流程
|
||||
3. **引导展开**：通过连续问题挖掘更多可能性
|
||||
4. **组织收敛**：按主题聚类并排序
|
||||
5. **行动化**：给重点方向定义下一步和衡量标准
|
||||
|
||||
:::note[核心原则]
|
||||
想法来源于你，workflow 负责构建“更容易产生好想法”的过程。
|
||||
:::
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
想继续深化现有输出，可参考 [高级启发](./advanced-elicitation.md)；需要多角色协同讨论，可参考 [派对模式](./party-mode.md)。若要查看它在整体流程中的位置，请参见 [工作流地图](../reference/workflow-map.md)。
|
||||
|
||||
- **brainstorming**：头脑风暴。一种集体或个人的创意生成方法，通过自由联想和发散思维产生大量想法。
|
||||
- **ideation**：构思。产生想法、概念或解决方案的过程。
|
||||
- **facilitator**：引导者。在会议或工作坊中引导讨论、促进参与并帮助达成目标的人。
|
||||
- **creative blocks**：创意瓶颈。在创意过程中遇到的思维停滞或灵感枯竭状态。
|
||||
- **probing questions**：探索性问题。旨在深入挖掘信息、激发思考或揭示潜在见解的问题。
|
||||
- **stakeholders**：利益相关者。对项目或决策有利益关系或受其影响的个人或群体。
|
||||
## 与相近模式的区别
|
||||
|
||||
| 模式 | 核心目标 | 输入状态 | 典型输出 |
|
||||
| ----- | ----- | ----- | ----- |
|
||||
| `bmad-brainstorming` | 发散并收敛想法 | 方向模糊、问题开放 | 想法清单、优先级、下一步 |
|
||||
| `advanced elicitation` | 对已有内容做二次推理 | 已有初稿或方案 | 改进版内容与推理补强 |
|
||||
| `bmad-party-mode` | 多角色协同讨论与对齐 | 涉及多方权衡的议题 | 角色视角下的共识或分歧 |
|
||||
|
||||
## 继续阅读
|
||||
|
||||
- [高级启发](./advanced-elicitation.md)
|
||||
- [派对模式](./party-mode.md)
|
||||
- [工作流地图](../reference/workflow-map.md)
|
||||
|
|
|
|||
|
|
@ -1,60 +1,64 @@
|
|||
---
|
||||
title: "既有项目常见问题"
|
||||
description: 关于在既有项目上使用 BMad 方法的常见问题
|
||||
description: 关于在既有项目上使用 BMad Method 的常见问题
|
||||
sidebar:
|
||||
order: 8
|
||||
---
|
||||
关于使用 BMad 方法（BMM）在既有项目上工作的常见问题的快速解答。
|
||||
关于在 established projects（既有项目）中使用 BMad Method 的高频问题，快速说明如下。
|
||||
|
||||
## 问题
|
||||
|
||||
- [我必须先运行 document-project 吗？](#我必须先运行-document-project-吗)
|
||||
- [如果我忘记运行 document-project 怎么办？](#如果我忘记运行-document-project-怎么办)
|
||||
- [我可以在既有项目上使用快速流程吗？](#我可以在既有项目上使用快速流程吗)
|
||||
- [如果我的现有代码不遵循最佳实践怎么办？](#如果我的现有代码不遵循最佳实践怎么办)
|
||||
- [我必须先运行文档梳理工作流吗？](#我必须先运行文档梳理工作流吗)
|
||||
- [如果我忘了运行文档梳理怎么办？](#如果我忘了运行文档梳理怎么办)
|
||||
- [既有项目可以直接用 Quick Flow 吗？](#既有项目可以直接用-quick-flow-吗)
|
||||
- [如果现有代码不符合最佳实践怎么办？](#如果现有代码不符合最佳实践怎么办)
|
||||
- [什么时候该从 Quick Flow 切到完整方法？](#什么时候该从-quick-flow-切到完整方法)
|
||||
|
||||
### 我必须先运行 document-project 吗？
|
||||
### 我必须先运行文档梳理工作流吗？
|
||||
|
||||
强烈推荐，特别是如果：
|
||||
不绝对必须，但通常强烈建议先运行 `bmad-document-project`，尤其当：
|
||||
- 项目文档缺失或明显过时
|
||||
- 新成员或智能体难以快速理解现有系统
|
||||
- 你希望后续 `workflow` 基于真实现状而不是猜测执行
|
||||
|
||||
- 没有现有文档
|
||||
- 文档已过时
|
||||
- AI 智能体需要关于现有代码的上下文
|
||||
如果你已有完整且最新的文档（包含 `docs/index.md`），并且能通过其他方式提供足够上下文，也可以跳过。
|
||||
|
||||
如果你拥有全面且最新的文档，包括 `docs/index.md`，或者将使用其他工具或技术来帮助智能体发现现有系统，则可以跳过此步骤。
|
||||
### 如果我忘了运行文档梳理怎么办？
|
||||
|
||||
### 如果我忘记运行 document-project 怎么办？
|
||||
可以随时补跑，不影响你继续推进当前任务。很多团队会在迭代中期或里程碑后再运行一次，用来把”代码现状”回写到文档里。
|
||||
|
||||
不用担心——你可以随时执行。你甚至可以在项目期间或项目之后执行，以帮助保持文档最新。
|
||||
### 既有项目可以直接用 Quick Flow 吗？
|
||||
|
||||
### 我可以在既有项目上使用快速流程吗？
|
||||
可以。Quick Flow（例如 `bmad-quick-dev`）在既有项目里通常很高效，尤其适合：
|
||||
- 小功能增量
|
||||
- 缺陷修复
|
||||
- 风险可控的局部改动
|
||||
|
||||
可以！快速流程在既有项目上效果很好。它将：
|
||||
它会尝试识别现有技术栈、代码模式和约定，并据此生成更贴近现状的实现方案。
|
||||
|
||||
- 自动检测你的现有技术栈
|
||||
- 分析现有代码模式
|
||||
- 检测约定并请求确认
|
||||
- 生成尊重现有代码的上下文丰富的技术规范
|
||||
### 如果现有代码不符合最佳实践怎么办？
|
||||
|
||||
非常适合现有代码库中的错误修复和小功能。
|
||||
工作流会优先问你：“是否沿用当前约定？”你可以主动选择：
|
||||
- **沿用**：优先保持一致性，降低短期改动风险
|
||||
- **升级**：建立新标准，并在 tech-spec 或架构中写明迁移理由与范围
|
||||
|
||||
### 如果我的现有代码不遵循最佳实践怎么办？
|
||||
BMad Method 不会强制“立即现代化”，而是把决策权交给你。
|
||||
|
||||
快速流程会检测你的约定并询问："我应该遵循这些现有约定吗？"你决定：
|
||||
### 什么时候该从 Quick Flow 切到完整方法？
|
||||
|
||||
- **是** → 与当前代码库保持一致
|
||||
- **否** → 建立新标准（在技术规范中记录原因）
|
||||
当任务出现以下信号时，建议从 Quick Flow 升级到完整 BMad Method：
|
||||
- 改动跨多个 `epic` 或多个子系统
|
||||
- 需要明确 `architecture` 决策，否则容易冲突
|
||||
- 涉及较大协作面、较高回归风险或复杂验收要求
|
||||
|
||||
BMM 尊重你的选择——它不会强制现代化，但会提供现代化选项。
|
||||
如果你不确定，先让 `bmad-help` 判断当前阶段更稳妥的 workflow。
|
||||
|
||||
**有未在此处回答的问题吗？** 请[提出问题](https://github.com/bmad-code-org/BMAD-METHOD/issues)或在 [Discord](https://discord.gg/gk8jAdXWmj) 中提问，以便我们添加它！
|
||||
**还有问题？** 欢迎在 [GitHub Issues](https://github.com/bmad-code-org/BMAD-METHOD/issues) 或 [Discord](https://discord.gg/gk8jAdXWmj) 提问。
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
如果你想了解这套接入方式的操作步骤，可继续阅读 [How-to：既有项目](../how-to/established-projects.md) 与 [How-to：项目上下文](../how-to/project-context.md)。想理解快速流程在方法论中的定位，可参见 [快速开发](./quick-dev.md)。
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **Quick Flow**：快速流程。BMad 方法中的一种工作流程，用于快速处理既有项目。
|
||||
- **tech-spec**：技术规范。描述技术实现细节和标准的文档。
|
||||
- **stack**：技术栈。项目所使用的技术组合，包括框架、库、工具等。
|
||||
- **conventions**：约定。代码库中遵循的编码风格、命名规则等规范。
|
||||
- **modernization**：现代化。将旧代码或系统更新为更现代的技术和最佳实践的过程。
|
||||
## 继续阅读
|
||||
|
||||
- [既有项目（How-to）](../how-to/established-projects.md)
|
||||
- [项目上下文（Explanation）](./project-context.md)
|
||||
- [管理项目上下文（How-to）](../how-to/project-context.md)
|
||||
|
|
|
|||
|
|
@ -5,75 +5,56 @@ sidebar:
|
|||
order: 7
|
||||
---
|
||||
|
||||
将所有 AI 智能体汇聚到一次对话中。
|
||||
`bmad-party-mode` 用于多角色协作讨论：把 PM、架构、开发、UX 等视角放到同一轮对话里，快速暴露分歧、对齐取舍。
|
||||
|
||||
## 什么是 Party Mode？
|
||||
## 它是什么
|
||||
|
||||
运行 `party-mode`，你的整个 AI 团队就齐聚一堂——PM、架构师、开发者、UX 设计师，任何你需要的人。BMad Master 负责编排，根据每条消息选择相关的智能体。智能体以角色身份回应，彼此同意、反对，并在彼此的想法基础上继续构建。
|
||||
Party Mode 不是单角色问答，也不是单文档改写。它更像一次”有主持人的多方评审会”：
|
||||
- BMad Master 根据你的问题调度相关角色
|
||||
- 各角色以自身关注点回应
|
||||
- 角色间会互相补充、质疑、修正
|
||||
|
||||
对话可以持续到你想要的时间。提出追问、对答案提出质疑、引导讨论方向——这是与智能体之间真正的来回交流，直到你完成目标。
|
||||
你可以连续追问，直到形成可执行结论。
|
||||
|
||||
**适用于：**
|
||||
## 什么时候使用
|
||||
|
||||
- 需要权衡的重大决策
|
||||
- 头脑风暴会议
|
||||
- 出现问题时的复盘
|
||||
- 冲刺回顾与规划
|
||||
- 面临高影响决策，且存在明确 trade-off
|
||||
- 需要跨角色快速对齐（产品、技术、交互、测试）
|
||||
- 出现故障或争议，需要复盘责任和改进方向
|
||||
- 做 sprint 规划或回顾，需要多视角共识
|
||||
|
||||
## 示例
|
||||
## 不适合的场景
|
||||
|
||||
### 指出糟糕的架构
|
||||
- 你只需要单一角色的直接执行（例如仅改一段文案）
|
||||
- 你已有明确决策，只需进入实现
|
||||
- 你需要的是对同一输出做深度二次推理
|
||||
|
||||
**You:** "好了团队，我们上个冲刺是一场灾难。认证服务宕机了三次。谁搞砸了这件事？"
|
||||
这些场景通常更适合：
|
||||
- `bmad-quick-dev`（直接进入实现）
|
||||
- `advanced elicitation`（二次推理补强）
|
||||
|
||||
**Architect:** "设计本身是合理的——分布式认证，有适当的回退机制。如果实现偏离了规范……"
|
||||
## 价值与边界
|
||||
|
||||
**Dev:** "我完全按照架构文档执行的。规范没有考虑到并发会话失效的竞态条件。"
|
||||
Party Mode 的价值在于”更快看见盲区”：
|
||||
- 优势：视角多、分歧显性、对齐速度快
|
||||
- 代价：讨论信息量大，需要你主动控节奏和收敛
|
||||
|
||||
**PM:** "你们两个都忽略了更大的问题——我们没有在 PRD 中验证会话管理需求。这是我的错，没有发现这一点。"
|
||||
|
||||
**TEA:** "我也应该在集成测试中发现这一点。测试场景没有覆盖并发失效。"
|
||||
|
||||
### 创意头脑风暴
|
||||
|
||||
**You:** "我们如何让入职体验变得神奇，而不是无聊？"
|
||||
|
||||
**UX Designer:** "从渐进式披露开始——在用户需要时揭示功能，而不是在教程中一次性展示所有内容。"
|
||||
|
||||
**Storyteller:** "如果入职是一个故事会怎样？每一步都揭示一个角色的旅程——用户就是英雄。"
|
||||
|
||||
**Game Designer:** "在此基础上——如果第一个'任务'实际上是解决一个真实的用户问题会怎样？他们通过做有价值的事情来学习。"
|
||||
|
||||
### 技术决策
|
||||
|
||||
**You:** "MVP 用单体还是微服务？"
|
||||
|
||||
**Architect:** "从单体开始。微服务会增加你在 1000 用户时不需要的复杂性。"
|
||||
|
||||
**PM:** "同意。上市时间比理论上的可扩展性更重要。"
|
||||
|
||||
**Dev:** "单体，但要有清晰的模块边界。如果需要，我们以后可以提取服务。"
|
||||
|
||||
:::tip[Better Decisions]
|
||||
通过多元视角做出更好的决策。欢迎来到 party mode。
|
||||
:::caution[使用建议]
|
||||
先给清晰议题，再给决策约束（时间、风险、成本、成功标准），讨论质量会明显更高。
|
||||
:::
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
若你的目标是结构化发散创意，可先参考 [头脑风暴](./brainstorming.md)；若你已经有初稿并想做二次推理补强，可参考 [高级启发](./advanced-elicitation.md)。完整阶段位置见 [工作流地图](../reference/workflow-map.md)。
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **PM**：产品经理（Product Manager）。
|
||||
- **Architect**：架构师。
|
||||
- **Dev**：开发者（Developer）。
|
||||
- **UX Designer**：用户体验设计师。
|
||||
- **TEA**：测试工程师（Test Engineer/Automation）。
|
||||
- **PRD**：产品需求文档（Product Requirements Document）。
|
||||
- **MVP**：最小可行产品（Minimum Viable Product）。
|
||||
- **monolith**：单体架构。一种将应用程序构建为单一、统一单元的架构风格。
|
||||
- **microservices**：微服务。一种将应用程序构建为一组小型、独立服务的架构风格。
|
||||
- **progressive disclosure**：渐进式披露。一种交互设计模式，仅在用户需要时显示信息或功能。
|
||||
- **post-mortem**：复盘。对事件或项目进行事后分析，以了解发生了什么以及如何改进。
|
||||
- **sprint**：冲刺。敏捷开发中的固定时间周期，通常为 1-4 周。
|
||||
- **race condition**：竞态条件。当多个进程或线程同时访问和操作共享数据时，系统行为取决于执行顺序的一种情况。
|
||||
- **fallback**：回退机制。当主要方法失败时使用的备用方案。
|
||||
- **time to market**：上市时间。产品从概念到推向市场所需的时间。
|
||||
## 与相近模式的区别
|
||||
|
||||
| 模式 | 核心目标 | 最佳场景 | 输出形态 |
|
||||
| ----- | ----- | ----- | ----- |
|
||||
| `bmad-party-mode` | 多角色对齐与权衡 | 跨职能决策、复盘、规划 | 共识点、争议点、决策建议 |
|
||||
| `bmad-brainstorming` | 发散创意并收敛 | 方向探索、创意卡点 | 想法池与优先级 |
|
||||
| `advanced elicitation` | 对现有输出做二次推理 | 规格/方案补强 | 改进版内容与风险补充 |
|
||||
|
||||
## 继续阅读
|
||||
|
||||
- [头脑风暴](./brainstorming.md)
|
||||
- [高级启发](./advanced-elicitation.md)
|
||||
- [工作流地图](../reference/workflow-map.md)
|
||||
|
|
|
|||
|
|
@ -5,133 +5,114 @@ sidebar:
|
|||
order: 4
|
||||
---
|
||||
|
||||
当多个 AI 智能体实现系统的不同部分时，它们可能会做出相互冲突的技术决策。架构文档通过建立共享标准来防止这种情况。
|
||||
当多个 AI 智能体并行实现系统时，冲突并不罕见。`architecture` 的作用，就是在 `solutioning` 阶段先统一关键决策，避免到 `epic/story` 实施时才暴露分歧。
|
||||
|
||||
## 常见冲突类型
|
||||
## 冲突最常出现在哪些地方
|
||||
|
||||
### API 风格冲突
|
||||
|
||||
没有架构时：
|
||||
- 智能体 A 使用 REST，路径为 `/users/{id}`
|
||||
没有架构约束时：
|
||||
- 智能体 A 使用 REST，路径是 `/users/{id}`
|
||||
- 智能体 B 使用 GraphQL mutations
|
||||
- 结果：API 模式不一致，消费者困惑
|
||||
- 结果：接口模式不一致，调用方和集成层都变复杂
|
||||
|
||||
有架构时：
|
||||
- ADR 指定："所有客户端-服务器通信使用 GraphQL"
|
||||
- 所有智能体遵循相同的模式
|
||||
有架构约束时：
|
||||
- ADR 明确规定：“客户端与服务端统一使用 GraphQL”
|
||||
- 所有智能体遵循同一套 API 规则
|
||||
|
||||
### 数据库设计冲突
|
||||
### 数据库与命名冲突
|
||||
|
||||
没有架构时：
|
||||
- 智能体 A 使用 snake_case 列名
|
||||
- 智能体 B 使用 camelCase 列名
|
||||
- 结果：模式不一致，查询混乱
|
||||
没有架构约束时：
|
||||
- 智能体 A 使用 `snake_case` 列名
|
||||
- 智能体 B 使用 `camelCase` 列名
|
||||
- 结果：schema 不一致，查询与迁移成本上升
|
||||
|
||||
有架构时：
|
||||
- 标准文档指定命名约定
|
||||
- 所有智能体遵循相同的模式
|
||||
有架构约束时：
|
||||
- 标准文档统一命名约定和迁移策略
|
||||
- 所有智能体按同一模式实现
|
||||
|
||||
### 状态管理冲突
|
||||
|
||||
没有架构时：
|
||||
- 智能体 A 使用 Redux 管理全局状态
|
||||
没有架构约束时：
|
||||
- 智能体 A 使用 Redux
|
||||
- 智能体 B 使用 React Context
|
||||
- 结果：多种状态管理方法，复杂度增加
|
||||
- 结果：状态层碎片化，维护复杂度增加
|
||||
|
||||
有架构时：
|
||||
- ADR 指定状态管理方法
|
||||
- 所有智能体一致实现
|
||||
有架构约束时：
|
||||
- ADR 明确状态管理方案
|
||||
- 不同 `story` 的实现保持一致
|
||||
|
||||
## 架构如何防止冲突
|
||||
## architecture 如何前置消解冲突
|
||||
|
||||
### 1. 通过 ADR 明确决策
|
||||
### 1. 用 ADR 固化关键决策
|
||||
|
||||
每个重要的技术选择都记录以下内容：
|
||||
- 上下文（为什么这个决策很重要）
|
||||
- 考虑的选项（有哪些替代方案）
|
||||
- 决策（我们选择了什么）
|
||||
- 理由（为什么选择它）
|
||||
- 后果（接受的权衡）
|
||||
每个关键技术选择都至少包含：
|
||||
- 背景（为什么要做这个决策）
|
||||
- 备选方案（有哪些选择）
|
||||
- 最终决策（采用什么）
|
||||
- 理由（为什么这样选）
|
||||
- 后果（接受哪些权衡）
|
||||
|
||||
### 2. FR/NFR 特定指导
|
||||
### 2. 把 FR/NFR 映射到技术实现
|
||||
|
||||
架构将每个功能需求映射到技术方法：
|
||||
- FR-001：用户管理 → GraphQL mutations
|
||||
- FR-002：移动应用 → 优化查询
|
||||
`architecture` 不是抽象原则清单，而是把需求落到可执行方案：
|
||||
- FR-001（用户管理）→ GraphQL mutations
|
||||
- FR-002（移动端性能）→ 查询裁剪与缓存策略
|
||||
|
||||
### 3. 标准和约定
|
||||
### 3. 统一基础约定
|
||||
|
||||
明确记录以下内容：
|
||||
至少覆盖以下共识：
|
||||
- 目录结构
|
||||
- 命名约定
|
||||
- 代码组织
|
||||
- 测试模式
|
||||
- 代码组织方式
|
||||
- 测试策略
|
||||
|
||||
## 架构作为共享上下文
|
||||
## architecture 是所有 epic 的共享上下文
|
||||
|
||||
将架构视为所有智能体在实现之前阅读的共享上下文：
|
||||
把架构文档看作每个智能体在实施前都要阅读的“公共协议”：
|
||||
|
||||
```text
|
||||
PRD："构建什么"
|
||||
PRD: "做什么"
|
||||
↓
|
||||
架构："如何构建"
|
||||
architecture: "如何做"
|
||||
↓
|
||||
智能体 A 阅读架构 → 实现 Epic 1
|
||||
智能体 B 阅读架构 → 实现 Epic 2
|
||||
智能体 C 阅读架构 → 实现 Epic 3
|
||||
智能体 A 读 architecture → 实现 Epic 1
|
||||
智能体 B 读 architecture → 实现 Epic 2
|
||||
智能体 C 读 architecture → 实现 Epic 3
|
||||
↓
|
||||
结果：一致的实现
|
||||
结果：实现一致、集成顺畅
|
||||
```
|
||||
|
||||
## Key ADR Topics
|
||||
## 优先写清的 ADR 主题
|
||||
|
||||
防止冲突的常见决策：
|
||||
|
||||
| Topic | Example Decision |
|
||||
| 主题 | 示例决策 |
|
||||
| ---------------- | -------------------------------------------- |
|
||||
| API Style | GraphQL vs REST vs gRPC |
|
||||
| Database | PostgreSQL vs MongoDB |
|
||||
| Auth | JWT vs Sessions |
|
||||
| State Management | Redux vs Context vs Zustand |
|
||||
| Styling | CSS Modules vs Tailwind vs Styled Components |
|
||||
| Testing | Jest + Playwright vs Vitest + Cypress |
|
||||
| API 风格 | GraphQL vs REST vs gRPC |
|
||||
| 数据存储 | PostgreSQL vs MongoDB |
|
||||
| 认证机制 | JWT vs Session |
|
||||
| 状态管理 | Redux vs Context vs Zustand |
|
||||
| 样式方案 | CSS Modules vs Tailwind vs Styled Components |
|
||||
| 测试体系 | Jest + Playwright vs Vitest + Cypress |
|
||||
|
||||
## 避免的反模式
|
||||
## 常见误区
|
||||
|
||||
:::caution[常见错误]
|
||||
- **隐式决策** — "我们边做边确定 API 风格"会导致不一致
|
||||
- **过度文档化** — 记录每个次要选择会导致分析瘫痪
|
||||
- **过时架构** — 文档写一次后从不更新，导致智能体遵循过时的模式
|
||||
- **隐式决策**：边写边定规则，最终通常会分叉
|
||||
- **过度文档化**：把每个小选择都写 ADR，造成分析瘫痪
|
||||
- **架构陈旧**：文档不更新，智能体继续按过时规则实现
|
||||
:::
|
||||
|
||||
:::tip[正确方法]
|
||||
- 记录跨越 epic 边界的决策
|
||||
- 专注于容易产生冲突的领域
|
||||
- 随着学习更新架构
|
||||
- 对重大变更使用 `correct-course`
|
||||
:::tip[更稳妥的做法]
|
||||
- 先记录跨 `epic`、高冲突概率的决策
|
||||
- 把精力放在”会影响多个 story 的规则”
|
||||
- 随着项目演进持续更新架构文档
|
||||
- 出现重大偏移时使用 `bmad-correct-course`
|
||||
:::
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
如需先理解为什么要在实施前做 solutioning，可阅读 [为什么解决方案设计很重要](./why-solutioning-matters.md)；如果你想把这些约束落地到项目执行，可继续看 [项目上下文](./project-context.md)。流程全景见 [工作流地图](../reference/workflow-map.md)。
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **ADR**：架构决策记录（Architecture Decision Record）。用于记录重要架构决策及其背景、选项和后果的文档。
|
||||
- **FR**：功能需求（Functional Requirement）。系统必须具备的功能或行为。
|
||||
- **NFR**：非功能需求（Non-Functional Requirement）。系统性能、安全性、可扩展性等质量属性。
|
||||
- **Epic**：史诗。大型功能或用户故事的集合，通常需要多个迭代完成。
|
||||
- **snake_case**：蛇形命名法。单词之间用下划线连接，所有字母小写的命名风格。
|
||||
- **camelCase**：驼峰命名法。除第一个单词外，每个单词首字母大写的命名风格。
|
||||
- **GraphQL mutations**：GraphQL 变更操作。用于修改服务器数据的 GraphQL 操作类型。
|
||||
- **Redux**：JavaScript 状态管理库。用于管理应用全局状态的可预测状态容器。
|
||||
- **React Context**：React 上下文 API。用于在组件树中传递数据而无需逐层传递 props。
|
||||
- **Zustand**：轻量级状态管理库。用于 React 应用的简单状态管理解决方案。
|
||||
- **CSS Modules**：CSS 模块。将 CSS 作用域限制在组件内的技术。
|
||||
- **Tailwind**：Tailwind CSS。实用优先的 CSS 框架。
|
||||
- **Styled Components**：样式化组件。使用 JavaScript 编写样式的 React 库。
|
||||
- **Jest**：JavaScript 测试框架。用于编写和运行测试的工具。
|
||||
- **Playwright**：端到端测试框架。用于自动化浏览器测试的工具。
|
||||
- **Vitest**：Vite 原生测试框架。快速且轻量的单元测试工具。
|
||||
- **Cypress**：端到端测试框架。用于 Web 应用测试的工具。
|
||||
- **gRPC**：远程过程调用框架。Google 开发的高性能 RPC 框架。
|
||||
- **JWT**：JSON Web Token。用于身份验证的开放标准令牌。
|
||||
- **PRD**：产品需求文档（Product Requirements Document）。描述产品功能、需求和目标的文档。
|
||||
## 继续阅读
|
||||
|
||||
- [为什么解决方案阶段很重要](./why-solutioning-matters.md)
|
||||
- [项目上下文](./project-context.md)
|
||||
- [工作流地图](../reference/workflow-map.md)
|
||||
|
|
|
|||
|
|
@ -1,55 +1,51 @@
|
|||
---
|
||||
title: "项目上下文"
|
||||
description: project-context.md 如何使用项目的规则和偏好指导 AI 智能体
|
||||
description: project-context.md 如何使用项目规则和偏好指导 AI 智能体
|
||||
sidebar:
|
||||
order: 7
|
||||
---
|
||||
|
||||
`project-context.md` 文件是您的项目面向 AI 智能体的实施指南。类似于其他开发系统中的"宪法"，它记录了确保所有工作流中代码生成一致的规则、模式和偏好。
|
||||
`project-context.md` 是面向 AI 智能体的项目级上下文文件。它的定位不是教程步骤，而是“实现约束说明”：把你的技术偏好、架构边界和工程约定沉淀成可复用规则，让不同工作流、不同智能体在多个 `story` 中做出一致决策。
|
||||
|
||||
## 它的作用
|
||||
## project context 解决什么问题
|
||||
|
||||
AI 智能体不断做出实施决策——遵循哪些模式、如何组织代码、使用哪些约定。如果没有明确指导，它们可能会：
|
||||
- 遵循与您的代码库不匹配的通用最佳实践
|
||||
- 在不同的用户故事中做出不一致的决策
|
||||
- 错过项目特定的需求或约束
|
||||
没有统一上下文时，智能体往往会：
|
||||
- 套用通用最佳实践，而不是你的项目约定
|
||||
- 在不同 `story` 中做出不一致实现
|
||||
- 漏掉代码里不易推断的隐性约束
|
||||
|
||||
`project-context.md` 文件通过以简洁、针对 LLM 优化的格式记录智能体需要了解的内容来解决这个问题。
|
||||
有 `project-context.md` 时，这些高频偏差会明显减少，因为关键规则在进入实现前已经被显式声明。
|
||||
|
||||
## 它的工作原理
|
||||
## 它如何被工作流使用
|
||||
|
||||
每个实施工作流都会自动加载 `project-context.md`（如果存在）。架构师工作流也会加载它，以便在设计架构时尊重您的技术偏好。
|
||||
多数实现相关工作流会自动加载 `project-context.md`（若存在），并把它作为共享上下文参与决策。
|
||||
|
||||
**由以下工作流加载：**
|
||||
- `create-architecture` — 在解决方案设计期间尊重技术偏好
|
||||
- `create-story` — 使用项目模式指导用户故事创建
|
||||
- `dev-story` — 指导实施决策
|
||||
- `code-review` — 根据项目标准进行验证
|
||||
- `quick-dev` — 在实施技术规范时应用模式
|
||||
- `sprint-planning`、`retrospective`、`correct-course` — 提供项目范围的上下文
|
||||
**常见加载方包括：**
|
||||
- `bmad-create-architecture`：在 solutioning 时纳入你的技术偏好
|
||||
- `bmad-create-story`：按项目约定拆分和描述 story
|
||||
- `bmad-dev-story`：约束实现路径和代码风格
|
||||
- `bmad-code-review`：按项目标准做一致性校验
|
||||
- `bmad-quick-dev`：在快速实现中避免偏离既有模式
|
||||
- `bmad-sprint-planning`、`bmad-retrospective`、`bmad-correct-course`：读取项目级背景
|
||||
|
||||
## 何时创建
|
||||
## 什么时候建立或更新
|
||||
|
||||
`project-context.md` 文件在项目的任何阶段都很有用：
|
||||
|
||||
| 场景 | 何时创建 | 目的 |
|
||||
| 场景 | 建议时机 | 目标 |
|
||||
|----------|----------------|---------|
|
||||
| **新项目，架构之前** | 手动，在 `create-architecture` 之前 | 记录您的技术偏好，以便架构师尊重它们 |
|
||||
| **新项目，架构之后** | 通过 `generate-project-context` 或手动 | 捕获架构决策，供实施智能体使用 |
|
||||
| **现有项目** | 通过 `generate-project-context` | 发现现有模式，以便智能体遵循既定约定 |
|
||||
| **快速流程项目** | 在 `quick-dev` 之前或期间 | 确保快速实施尊重您的模式 |
|
||||
| **新项目（架构前）** | 在 `bmad-create-architecture` 前手动创建 | 先声明技术偏好，避免架构偏航 |
|
||||
| **新项目（架构后）** | 通过 `bmad-generate-project-context` 生成并补充 | 把架构决策转成可执行规则 |
|
||||
| **既有项目** | 先生成，再人工校对 | 让智能体学习现有约定而非重造体系 |
|
||||
| **Quick Flow 场景** | 在 `bmad-quick-dev` 前或过程中维护 | 弥补跳过完整规划带来的上下文缺口 |
|
||||
|
||||
:::tip[推荐]
|
||||
对于新项目，如果您有强烈的技术偏好，请在架构之前手动创建。否则，在架构之后生成它以捕获这些决策。
|
||||
:::tip[推荐做法]
|
||||
如果你有强技术偏好（例如数据库、状态管理、目录规范），尽量在架构前写入。否则可在架构后生成，再按项目现实补齐。
|
||||
:::
|
||||
|
||||
## 文件内容
|
||||
## 应该写哪些内容
|
||||
|
||||
该文件有两个主要部分：
|
||||
建议聚焦两类信息：**技术栈与版本**、**关键实现规则**。原则是记录“智能体不容易从代码片段直接推断”的内容。
|
||||
|
||||
### 技术栈与版本
|
||||
|
||||
记录项目使用的框架、语言和工具及其具体版本：
|
||||
### 1. 技术栈与版本
|
||||
|
||||
```markdown
|
||||
## Technology Stack & Versions
|
||||
|
|
@ -60,9 +56,7 @@ AI 智能体不断做出实施决策——遵循哪些模式、如何组织代
|
|||
- Styling: Tailwind CSS with custom design tokens
|
||||
```
|
||||
|
||||
### 关键实施规则
|
||||
|
||||
记录智能体可能忽略的模式和约定：
|
||||
### 2. 关键实现规则
|
||||
|
||||
```markdown
|
||||
## Critical Implementation Rules
|
||||
|
|
@ -73,104 +67,30 @@ AI 智能体不断做出实施决策——遵循哪些模式、如何组织代
|
|||
|
||||
**Code Organization:**
|
||||
- Components in `/src/components/` with co-located `.test.tsx`
|
||||
- Utilities in `/src/lib/` for reusable pure functions
|
||||
- API calls use the `apiClient` singleton — never fetch directly
|
||||
|
||||
**Testing Patterns:**
|
||||
- Unit tests focus on business logic, not implementation details
|
||||
- Integration tests use MSW to mock API responses
|
||||
- E2E tests cover critical user journeys only
|
||||
|
||||
**Framework-Specific:**
|
||||
- All async operations use the `handleError` wrapper for consistent error handling
|
||||
- Feature flags accessed via `featureFlag()` from `@/lib/flags`
|
||||
- New routes follow the file-based routing pattern in `/src/app/`
|
||||
```
|
||||
|
||||
专注于那些**不明显**的内容——智能体可能无法从阅读代码片段中推断出来的内容。不要记录普遍适用的标准实践。
|
||||
## 常见误解
|
||||
|
||||
## 创建文件
|
||||
- **误解 1：它是操作手册。**
|
||||
不是。操作步骤请看 how-to；这里强调的是规则与边界。
|
||||
- **误解 2：写得越全越好。**
|
||||
不对。冗长且泛化的“最佳实践”会稀释有效约束。
|
||||
- **误解 3：写一次就结束。**
|
||||
这是动态文件。架构变化、约定变化后要同步更新。
|
||||
|
||||
您有三个选择：
|
||||
## 文件位置
|
||||
|
||||
### 手动创建
|
||||
默认位置是 `_bmad-output/project-context.md`。工作流优先在该位置查找，也会扫描项目内的 `**/project-context.md`。
|
||||
|
||||
在 `_bmad-output/project-context.md` 创建文件并添加您的规则：
|
||||
## 继续阅读
|
||||
|
||||
```bash
|
||||
# In your project root
|
||||
mkdir -p _bmad-output
|
||||
touch _bmad-output/project-context.md
|
||||
```
|
||||
如需可执行步骤说明，请阅读 [How-to：项目上下文](../how-to/project-context.md)；如果你在既有项目落地这套机制，可参考 [既有项目常见问题](./established-projects-faq.md)。整体流程定位见 [工作流地图](../reference/workflow-map.md)。
|
||||
|
||||
使用您的技术栈和实施规则编辑它。架构师和实施工作流将自动查找并加载它。
|
||||
|
||||
### 架构后生成
|
||||
|
||||
在完成架构后运行 `generate-project-context` 工作流：
|
||||
|
||||
```bash
|
||||
/bmad-bmm-generate-project-context
|
||||
```
|
||||
|
||||
这将扫描您的架构文档和项目文件，生成一个捕获所做决策的上下文文件。
|
||||
|
||||
### 为现有项目生成
|
||||
|
||||
对于现有项目，运行 `generate-project-context` 以发现现有模式：
|
||||
|
||||
```bash
|
||||
/bmad-bmm-generate-project-context
|
||||
```
|
||||
|
||||
该工作流分析您的代码库以识别约定，然后生成一个您可以审查和优化的上下文文件。
|
||||
|
||||
## 为什么重要
|
||||
|
||||
没有 `project-context.md`，智能体会做出可能与您的项目不匹配的假设：
|
||||
|
||||
| 没有上下文 | 有上下文 |
|
||||
|----------------|--------------|
|
||||
| 使用通用模式 | 遵循您的既定约定 |
|
||||
| 用户故事之间风格不一致 | 实施一致 |
|
||||
| 可能错过项目特定的约束 | 尊重所有技术需求 |
|
||||
| 每个智能体独立决策 | 所有智能体遵循相同规则 |
|
||||
|
||||
这对于以下情况尤其重要：
|
||||
- **快速流程** — 跳过 PRD 和架构，因此上下文文件填补了空白
|
||||
- **团队项目** — 确保所有智能体遵循相同的标准
|
||||
- **现有项目** — 防止破坏既定模式
|
||||
|
||||
## 编辑和更新
|
||||
|
||||
`project-context.md` 文件是一个动态文档。在以下情况下更新它：
|
||||
|
||||
- 架构决策发生变化
|
||||
- 建立了新的约定
|
||||
- 模式在实施过程中演变
|
||||
- 您从智能体行为中发现差距
|
||||
|
||||
您可以随时手动编辑它，或者在重大更改后重新运行 `generate-project-context` 来更新它。
|
||||
|
||||
:::note[文件位置]
|
||||
默认位置是 `_bmad-output/project-context.md`。工作流在那里搜索它，并且还会检查项目中任何位置的 `**/project-context.md`。
|
||||
:::
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **workflow**：工作流。指一系列自动化或半自动化的任务流程。
|
||||
- **PRD**：产品需求文档（Product Requirements Document）。描述产品功能、需求和目标的文档。
|
||||
- **LLM**：大语言模型（Large Language Model）。指基于深度学习的自然语言处理模型。
|
||||
- **singleton**：单例。一种设计模式，确保一个类只有一个实例。
|
||||
- **E2E**：端到端（End-to-End）。指从用户角度出发的完整测试流程。
|
||||
- **MSW**：Mock Service Worker。用于模拟 API 响应的库。
|
||||
- **Vitest**：基于 Vite 的单元测试框架。
|
||||
- **Playwright**：端到端测试框架。
|
||||
- **Zustand**：轻量级状态管理库。
|
||||
- **Redux**：JavaScript 应用状态管理库。
|
||||
- **Tailwind CSS**：实用优先的 CSS 框架。
|
||||
- **TypeScript**：JavaScript 的超集，添加了静态类型。
|
||||
- **React**：用于构建用户界面的 JavaScript 库。
|
||||
- **Node.js**：基于 Chrome V8 引擎的 JavaScript 运行时。
|
||||
- [管理项目上下文（How-to）](../how-to/project-context.md)
|
||||
- [既有项目常见问题](./established-projects-faq.md)
|
||||
- [工作流地图](../reference/workflow-map.md)
|
||||
|
|
|
|||
|
|
@ -5,69 +5,84 @@ sidebar:
|
|||
order: 2
|
||||
---
|
||||
|
||||
输入意图，输出代码变更，尽可能少的人机交互轮次——同时不牺牲质量。
|
||||
|
||||
它让模型在检查点之间运行更长时间，只有在任务无法在没有人类判断的情况下安全继续时，或者需要审查最终结果时，才会让人类介入。
|
||||
`bmad-quick-dev` 的目标很直接：在保证质量边界的前提下，把“意图到代码”的人机往返轮次降到最低。
|
||||
|
||||
|
||||
|
||||
## 为什么需要这个功能
|
||||
## 它解决什么问题
|
||||
|
||||
人机交互轮次既必要又昂贵。
|
||||
纯人工频繁盯流程会拖慢速度，纯自动又容易偏航。Quick Dev 做的是中间解：
|
||||
- 在关键节点保留人工判断
|
||||
- 在可控区间放大模型自主执行时长
|
||||
- 通过规范与审查把偏航风险收回来
|
||||
|
||||
当前的 LLM 仍然会以可预测的方式失败：它们误读意图、用自信的猜测填补空白、偏离到不相关的工作中，并生成嘈杂的审查输出。与此同时，持续的人工干预限制了开发速度。人类注意力是瓶颈。
|
||||
## Quick Dev 的核心机制
|
||||
|
||||
`bmad-quick-dev` 重新平衡了这种权衡。它信任模型在更长的时间段内无监督运行，但前提是工作流已经创建了足够强的边界来确保安全。
|
||||
### 1. 先把意图压缩成单一目标
|
||||
|
||||
## 核心设计
|
||||
无论输入来自几句话、issue 链接、计划稿，还是 `epics.md` 的 `story`，都要先压缩成一个可执行目标。
|
||||
目标不清晰时，后续自动化越强，偏差成本越高。
|
||||
|
||||
### 1. 首先压缩意图
|
||||
### 2. 选择最小安全路径
|
||||
|
||||
工作流首先让人类和模型将请求压缩成一个连贯的目标。输入可以从粗略的意图表达开始，但在工作流自主运行之前，它必须变得足够小、足够清晰、没有矛盾。
|
||||
目标明确后，workflow 会判断：
|
||||
- 是不是“零爆炸半径”的 one-shot 变更
|
||||
- 还是必须先走 planning 再实现
|
||||
|
||||
意图可以以多种形式出现：几句话、一个错误追踪器链接、计划模式的输出、从聊天会话复制的文本，甚至来自 BMAD 自己的 `epics.md` 的故事编号。在最后一种情况下，工作流不会理解 BMAD 故事跟踪语义，但它仍然可以获取故事本身并继续执行。
|
||||
原则是：能走短路径就不走长路径，但不能为了快跳过必要边界。
|
||||
|
||||
这个工作流并不会消除人类的控制。它将其重新定位到少数几个高价值时刻：
|
||||
### 3. 在边界内长时自主执行
|
||||
|
||||
- **意图澄清** - 将混乱的请求转化为一个没有隐藏矛盾的连贯目标
|
||||
- **规范审批** - 确认冻结的理解是正确要构建的东西
|
||||
- **最终产品审查** - 主要检查点，人类在最后决定结果是否可接受
|
||||
当目标与规范足够清晰，模型会承担更长段的连续实现。
|
||||
这一步省下的是“重复确认成本”，不是“质量成本”。
|
||||
|
||||
### 2. 路由到最小安全路径
|
||||
### 4. 在正确层级修复问题
|
||||
|
||||
一旦目标清晰，工作流就会决定这是一个真正的单次变更还是需要更完整的路径。小的、零爆炸半径的变更可以直接进入实现。其他所有内容都需要经过规划，这样模型在独自运行更长时间之前就有更强的边界。
|
||||
Quick Dev 会区分问题来源：
|
||||
- **意图层问题**：需求理解本身不对
|
||||
- **规范层问题**：tech-spec 边界不够强
|
||||
- **实现层问题**：本地代码缺陷
|
||||
|
||||
### 3. 以更少的监督运行更长时间
|
||||
只有实现层问题才直接补代码；上层问题要回到对应层级重做。
|
||||
|
||||
在那个路由决策之后，模型可以自己承担更多工作。在更完整的路径上，批准的规范成为模型在较少监督下执行的边界，这正是设计的全部意义。
|
||||
### 5. 只在必要时拉回人工
|
||||
|
||||
### 4. 在正确的层诊断失败
|
||||
人类主要在三个高杠杆时刻介入：
|
||||
- 意图澄清
|
||||
- 规范确认
|
||||
- 最终结果审查
|
||||
|
||||
如果实现是错误的，因为意图是错误的，修补代码是错误的修复。如果代码是错误的，因为规范太弱，修补差异也是错误的修复。工作流旨在诊断失败从系统的哪个层面进入，回到那个层面，并从那里重新生成。
|
||||
## 为什么它和“普通自动化”不一样
|
||||
|
||||
审查发现用于确定问题来自意图、规范生成还是本地实现。只有真正的本地问题才会在本地修补。
|
||||
Quick Dev 不追求“全自动”，而是追求“最少但有效的人类判断”。
|
||||
它把人工注意力从大量低价值确认，转移到少量高价值决策。
|
||||
|
||||
### 5. 只在需要时让人类回来
|
||||
## 与对抗性评审的关系
|
||||
|
||||
意图访谈是人机交互，但它不是与重复检查点相同类型的中断。工作流试图将那些重复检查点保持在最低限度。在初始意图塑造之后，人类主要在工作流无法在没有判断的情况下安全继续时，以及在最后需要审查结果时才回来。
|
||||
Quick Dev 是执行节奏设计；`adversarial review` 是审查策略。二者经常配合：
|
||||
- Quick Dev 负责高效推进实现
|
||||
- 对抗性评审负责提高问题发现率并做分诊
|
||||
|
||||
- **意图差距解决** - 当审查证明工作流无法安全推断出原本意图时重新介入
|
||||
也就是说，Quick Dev 解决“怎么更快且更稳地跑”，对抗性评审解决“怎么更狠地查问题”。
|
||||
|
||||
其他一切都是更长自主执行的候选。这种权衡是经过深思熟虑的。旧模式在持续监督上花费更多的人类注意力。快速开发在模型上投入更多信任，但将人类注意力保留在人类推理具有最高杠杆作用的时刻。
|
||||
## 适用边界
|
||||
|
||||
## 为什么审查系统很重要
|
||||
**适合：**
|
||||
- 目标可定义、可验收的实现任务
|
||||
- 希望减少流程摩擦但不放弃质量门
|
||||
|
||||
审查阶段不仅仅是为了发现错误。它是为了在不破坏动力的情况下路由修正。
|
||||
**不适合：**
|
||||
- 目标长期模糊且频繁变化
|
||||
- 团队尚未接受“先规格后长时执行”的工作方式
|
||||
|
||||
这个工作流在能够生成子智能体的平台上效果最好，或者至少可以通过命令行调用另一个 LLM 并等待结果。如果你的平台本身不支持这一点，你可以添加一个技能来做。无上下文子智能体是审查设计的基石。
|
||||
:::tip[实践建议]
|
||||
先把成功标准写清楚，再启用 Quick Dev。目标越清楚，自动化收益越大。
|
||||
:::
|
||||
|
||||
智能体审查经常以两种方式出错：
|
||||
## 继续阅读
|
||||
|
||||
- 它们生成太多发现，迫使人类在噪音中筛选
|
||||
- 它们通过提出不相关的问题并使每次运行变成临时清理项目来使当前变更脱轨
|
||||
想进一步理解审查策略，可继续阅读 [对抗性评审](./adversarial-review.md)；需要对已有输出进行第二轮推理时，可参考 [高级启发](./advanced-elicitation.md)。若要查看它在完整流程中的位置，请参见 [工作流地图](../reference/workflow-map.md)。
|
||||
|
||||
快速开发通过将审查视为分诊来解决这两个问题。
|
||||
|
||||
一些发现属于当前变更。一些不属于。如果一个发现是附带的而不是与当前工作有因果关系，工作流可以推迟它，而不是强迫人类立即处理它。这使运行保持专注，并防止随机的分支话题消耗注意力的预算。
|
||||
|
||||
那个分诊有时会不完美。这是可以接受的。通常，误判一些发现比用成千上万个低价值的审查评论淹没人类要好。系统正在优化信号质量，而不是详尽的召回率。
|
||||
- [对抗性评审](./adversarial-review.md)
|
||||
- [高级启发](./advanced-elicitation.md)
|
||||
- [工作流地图](../reference/workflow-map.md)
|
||||
|
|
|
|||
|
|
@ -5,54 +5,53 @@ sidebar:
|
|||
order: 3
|
||||
---
|
||||
|
||||
Phase 3（solutioning）把“要做什么”（planning 产出）转成“如何实现”（`architecture` 设计 + 工作拆分）。它的核心价值是：在开发前先把跨 `epic` 的关键技术决策写清楚，让后续 `story` 实施保持一致。
|
||||
|
||||
阶段 3（解决方案）将构建**什么**（来自规划）转化为**如何**构建（技术设计）。该阶段通过在实施开始前记录架构决策，防止多史诗项目中的智能体冲突。
|
||||
|
||||
## 没有解决方案阶段的问题
|
||||
## 不做 solutioning 会出现什么问题
|
||||
|
||||
```text
|
||||
智能体 1 使用 REST API 实现史诗 1
|
||||
智能体 2 使用 GraphQL 实现史诗 2
|
||||
结果：API 设计不一致，集成噩梦
|
||||
智能体 1 使用 REST API 实现 Epic 1
|
||||
智能体 2 使用 GraphQL 实现 Epic 2
|
||||
结果：API 设计不一致，集成成本暴涨
|
||||
```
|
||||
|
||||
当多个智能体在没有共享架构指导的情况下实现系统的不同部分时，它们会做出可能冲突的独立技术决策。
|
||||
当多个智能体在没有共享 `architecture` 指南的前提下并行实现不同 `epic`，它们会各自做局部最优决策，最后在集成阶段发生冲突。
|
||||
|
||||
## 有解决方案阶段的解决方案
|
||||
## 做了 solutioning 后会发生什么
|
||||
|
||||
```text
|
||||
架构工作流决定："所有 API 使用 GraphQL"
|
||||
所有智能体遵循架构决策
|
||||
结果：实现一致，无冲突
|
||||
architecture 工作流先定规则："所有 API 使用 GraphQL"
|
||||
所有智能体按同一套决策实现 story
|
||||
结果：实现一致，集成顺滑
|
||||
```
|
||||
|
||||
通过明确记录技术决策，所有智能体都能一致地实现，集成变得简单直接。
|
||||
solutioning 的本质不是“多写一份文档”，而是把高冲突风险决策前置，作为所有 `story` 的共享上下文。
|
||||
|
||||
## 解决方案阶段 vs 规划阶段
|
||||
## solutioning 与 planning 的边界
|
||||
|
||||
| 方面 | 规划（阶段 2） | 解决方案（阶段 3） |
|
||||
| 方面 | Planning（阶段 2） | Solutioning（阶段 3） |
|
||||
| -------- | ----------------------- | --------------------------------- |
|
||||
| 问题 | 做什么和为什么？ | 如何做？然后是什么工作单元？ |
|
||||
| 输出 | FRs/NFRs（需求） | 架构 + 史诗/用户故事 |
|
||||
| 智能体 | PM | 架构师 → PM |
|
||||
| 核心问题 | 做什么，为什么做？ | 如何做，再如何拆分工作？ |
|
||||
| 输出物 | FRs/NFRs（需求） | `architecture` + `epic/story` 拆分 |
|
||||
| 主导角色 | PM | Architect → PM |
|
||||
| 受众 | 利益相关者 | 开发人员 |
|
||||
| 文档 | PRD（FRs/NFRs） | 架构 + 史诗文件 |
|
||||
| 层级 | 业务逻辑 | 技术设计 + 工作分解 |
|
||||
| 文档 | PRD（FRs/NFRs） | 架构文档 + epics 文件 |
|
||||
| 决策层级 | 业务目标与范围 | 技术策略与实现边界 |
|
||||
|
||||
## 核心原则
|
||||
|
||||
**使技术决策明确且有文档记录**，以便所有智能体一致地实现。
|
||||
**让跨 `epic` 的关键技术决策显式、可追溯、可复用。**
|
||||
|
||||
这可以防止：
|
||||
这能直接降低：
|
||||
- API 风格冲突（REST vs GraphQL）
|
||||
- 数据库设计不一致
|
||||
- 状态管理分歧
|
||||
- 命名约定不匹配
|
||||
- 安全方法差异
|
||||
- 数据模型与命名约定不一致
|
||||
- 状态管理方案分裂
|
||||
- 安全策略分叉
|
||||
- 中后期返工成本
|
||||
|
||||
## 何时需要解决方案阶段
|
||||
## 什么时候需要 solutioning
|
||||
|
||||
| 流程 | 需要解决方案阶段？ |
|
||||
| 流程 | 需要 solutioning？ |
|
||||
|-------|----------------------|
|
||||
| Quick Flow | 否 - 完全跳过 |
|
||||
| BMad Method Simple | 可选 |
|
||||
|
|
@ -60,31 +59,26 @@ sidebar:
|
|||
| Enterprise | 是 |
|
||||
|
||||
:::tip[经验法则]
|
||||
如果你有多个可能由不同智能体实现的史诗，你需要解决方案阶段。
|
||||
只要需求会拆成多个 `epic`，并且可能由不同智能体并行实现，就应该做 solutioning。
|
||||
:::
|
||||
|
||||
## 跳过的代价
|
||||
## 跳过 solutioning 的代价
|
||||
|
||||
在复杂项目中跳过解决方案阶段会导致：
|
||||
在复杂项目中跳过该阶段，常见后果是：
|
||||
|
||||
- **集成问题**在冲刺中期发现
|
||||
- **返工**由于实现冲突
|
||||
- **开发时间更长**整体
|
||||
- **技术债务**来自不一致模式
|
||||
- **集成问题**在冲刺中期暴露
|
||||
- **返工**由实现冲突引发
|
||||
- **整体研发周期拉长**
|
||||
- **技术债务**因模式不一致持续累积
|
||||
|
||||
:::caution[成本倍增]
|
||||
在解决方案阶段发现对齐问题比在实施期间发现要快 10 倍。
|
||||
在 solutioning 阶段发现对齐问题，通常比在实施中后期才发现更快、更便宜。
|
||||
:::
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
想进一步理解冲突是如何发生并被架构约束消除的，可继续阅读 [防止智能体冲突](./preventing-agent-conflicts.md)。如果你要把这些约束落到执行层，请结合 [项目上下文](./project-context.md) 与 [工作流地图](../reference/workflow-map.md) 一起阅读。
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **epic**：史诗。在敏捷开发中，指一个大型的工作项，可分解为多个用户故事。
|
||||
- **REST API**：表述性状态传递应用程序接口。一种基于 HTTP 协议的 Web API 设计风格。
|
||||
- **GraphQL**：一种用于 API 的查询语言和运行时环境。
|
||||
- **FRs/NFRs**：功能需求/非功能需求。Functional Requirements/Non-Functional Requirements 的缩写。
|
||||
- **PRD**：产品需求文档。Product Requirements Document 的缩写。
|
||||
- **PM**：产品经理。Product Manager 的缩写。
|
||||
- **sprint**：冲刺。敏捷开发中的固定时间周期，通常为 1-4 周。
|
||||
- **technical debt**：技术债务。指为了短期目标而选择的不完美技术方案，未来需要付出额外成本来修复。
|
||||
## 继续阅读
|
||||
|
||||
- [防止智能体冲突](./preventing-agent-conflicts.md)
|
||||
- [项目上下文](./project-context.md)
|
||||
- [工作流地图](../reference/workflow-map.md)
|
||||
|
|
|
|||
|
|
@ -5,56 +5,56 @@ sidebar:
|
|||
order: 7
|
||||
---
|
||||
|
||||
使用 `.customize.yaml` 文件来调整智能体行为、角色和菜单，同时在更新过程中保留您的更改。
|
||||
使用 `.customize.yaml` 文件，自定义智能体（agent）的行为、角色（persona）和菜单，同时在后续更新中保留你的改动。
|
||||
|
||||
## 何时使用此功能
|
||||
|
||||
- 您想要更改智能体的名称、个性或沟通风格
|
||||
- 您需要智能体记住项目特定的上下文
|
||||
- 您想要添加自定义菜单项来触发您自己的工作流或提示
|
||||
- 您希望智能体在每次启动时执行特定操作
|
||||
- 你想修改智能体名称、身份设定或沟通风格
|
||||
- 你需要让智能体长期记住项目约束和背景信息
|
||||
- 你希望增加自定义菜单项，触发自己的工作流或提示
|
||||
- 你希望智能体每次启动都先执行固定动作
|
||||
|
||||
:::note[前置条件]
|
||||
- 在项目中安装了 BMad（参见[如何安装 BMad](./install-bmad.md)）
|
||||
- 已在项目中安装 BMad（参见[如何安装 BMad](./install-bmad.md)）
|
||||
- 用于编辑 YAML 文件的文本编辑器
|
||||
:::
|
||||
|
||||
:::caution[保护您的自定义配置]
|
||||
始终使用此处描述的 `.customize.yaml` 文件，而不是直接编辑智能体文件。安装程序在更新期间会覆盖智能体文件，但会保留您的 `.customize.yaml` 更改。
|
||||
始终通过 `.customize.yaml` 自定义，不要直接改动智能体源文件。安装程序在更新时会覆盖智能体文件，但会保留 `.customize.yaml` 的内容。
|
||||
:::
|
||||
|
||||
## 步骤
|
||||
|
||||
### 1. 定位自定义文件
|
||||
|
||||
安装后，在以下位置为每个智能体找到一个 `.customize.yaml` 文件：
|
||||
安装完成后，每个已安装智能体都会在下面目录生成一个 `.customize.yaml`：
|
||||
|
||||
```text
|
||||
_bmad/_config/agents/
|
||||
├── core-bmad-master.customize.yaml
|
||||
├── bmm-dev.customize.yaml
|
||||
├── bmm-pm.customize.yaml
|
||||
└── ...（每个已安装的智能体一个文件）
|
||||
└── ...（每个已安装智能体一个文件）
|
||||
```
|
||||
|
||||
### 2. 编辑自定义文件
|
||||
|
||||
打开您想要修改的智能体的 `.customize.yaml` 文件。每个部分都是可选的——只自定义您需要的内容。
|
||||
打开目标智能体的 `.customize.yaml`。各段都可选，只改你需要的部分即可。
|
||||
|
||||
| 部分 | 行为 | 用途 |
|
||||
| 部分 | 作用方式 | 用途 |
|
||||
| ------------------ | -------- | ---------------------------------------------- |
|
||||
| `agent.metadata` | 替换 | 覆盖智能体的显示名称 |
|
||||
| `persona` | 替换 | 设置角色、身份、风格和原则 |
|
||||
| `memories` | 追加 | 添加智能体始终会记住的持久上下文 |
|
||||
| `menu` | 追加 | 为工作流或提示添加自定义菜单项 |
|
||||
| `critical_actions` | 追加 | 定义智能体的启动指令 |
|
||||
| `prompts` | 追加 | 创建可重复使用的提示供菜单操作使用 |
|
||||
| `agent.metadata` | 覆盖 | 覆盖智能体显示名称 |
|
||||
| `persona` | 覆盖 | 设置角色、身份、风格和原则 |
|
||||
| `memories` | 追加 | 添加智能体长期记忆的上下文 |
|
||||
| `menu` | 追加 | 增加指向工作流或提示的菜单项 |
|
||||
| `critical_actions` | 追加 | 定义智能体启动时要执行的动作 |
|
||||
| `prompts` | 追加 | 创建可复用提示，供菜单 `action` 引用 |
|
||||
|
||||
标记为 **替换** 的部分会完全覆盖智能体的默认设置。标记为 **追加** 的部分会添加到现有配置中。
|
||||
标记为 **覆盖** 的部分会完全替换默认配置；标记为 **追加** 的部分会在默认配置基础上累加。
|
||||
|
||||
**智能体名称**
|
||||
**智能体名称（`agent.metadata`）**
|
||||
|
||||
更改智能体的自我介绍方式：
|
||||
修改智能体的显示名称：
|
||||
|
||||
```yaml
|
||||
agent:
|
||||
|
|
@ -62,9 +62,9 @@ agent:
|
|||
name: 'Spongebob' # 默认值："Amelia"
|
||||
```
|
||||
|
||||
**角色**
|
||||
**角色（`persona`）**
|
||||
|
||||
替换智能体的个性、角色和沟通风格：
|
||||
替换智能体的人设、职责和沟通风格：
|
||||
|
||||
```yaml
|
||||
persona:
|
||||
|
|
@ -76,22 +76,22 @@ persona:
|
|||
- 'Favor composition over inheritance'
|
||||
```
|
||||
|
||||
`persona` 部分会替换整个默认角色，因此如果您设置它，请包含所有四个字段。
|
||||
`persona` 会覆盖默认整段配置，所以启用时请把四个字段都填全。
|
||||
|
||||
**记忆**
|
||||
**记忆（`memories`）**
|
||||
|
||||
添加智能体将始终记住的持久上下文：
|
||||
添加智能体会长期记住的上下文：
|
||||
|
||||
```yaml
|
||||
memories:
|
||||
- 'Works at Krusty Krab'
|
||||
- 'Favorite Celebrity: David Hasslehoff'
|
||||
- 'Favorite Celebrity: David Hasselhoff'
|
||||
- 'Learned in Epic 1 that it is not cool to just pretend that tests have passed'
|
||||
```
|
||||
|
||||
**菜单项**
|
||||
**菜单项（`menu`）**
|
||||
|
||||
向智能体的显示菜单添加自定义条目。每个条目需要一个 `trigger`、一个目标（`workflow` 路径或 `action` 引用）和一个 `description`：
|
||||
给智能体菜单添加自定义项。每个条目都需要 `trigger`、目标（`workflow` 路径或 `action` 引用）和 `description`：
|
||||
|
||||
```yaml
|
||||
menu:
|
||||
|
|
@ -103,18 +103,18 @@ menu:
|
|||
description: Deploy to production
|
||||
```
|
||||
|
||||
**关键操作**
|
||||
**启动关键动作（`critical_actions`）**
|
||||
|
||||
定义智能体启动时运行的指令：
|
||||
定义智能体启动时执行的指令：
|
||||
|
||||
```yaml
|
||||
critical_actions:
|
||||
- 'Check the CI Pipelines with the XYZ Skill and alert user on wake if anything is urgently needing attention'
|
||||
```
|
||||
|
||||
**自定义提示**
|
||||
**可复用提示（`prompts`）**
|
||||
|
||||
创建可重复使用的提示，菜单项可以通过 `action="#id"` 引用：
|
||||
创建可复用提示，菜单项可通过 `action="#id"` 调用：
|
||||
|
||||
```yaml
|
||||
prompts:
|
||||
|
|
@ -126,57 +126,51 @@ prompts:
|
|||
3. Execute deployment script
|
||||
```
|
||||
|
||||
### 3. 应用您的更改
|
||||
### 3. 应用更改
|
||||
|
||||
编辑后，重新编译智能体以应用更改：
|
||||
编辑完成后，重新安装以应用配置：
|
||||
|
||||
```bash
|
||||
npx bmad-method install
|
||||
```
|
||||
|
||||
安装程序会检测现有安装并提供以下选项：
|
||||
安装程序会识别现有安装，并给出以下选项：
|
||||
|
||||
| Option | What It Does |
|
||||
| 选项 | 作用 |
|
||||
| ---------------------------- | ------------------------------------------------------------------- |
|
||||
| **Quick Update** | 将所有模块更新到最新版本并重新编译所有智能体 |
|
||||
| **Recompile Agents** | 仅应用自定义配置，不更新模块文件 |
|
||||
| **Modify BMad Installation** | 用于添加或删除模块的完整安装流程 |
|
||||
| **Quick Update** | 更新所有模块到最新版本，并应用你的自定义配置 |
|
||||
| **Modify BMad Installation** | 进入完整安装流程，用于增删模块 |
|
||||
|
||||
对于仅自定义配置的更改，**Recompile Agents** 是最快的选项。
|
||||
如果只是调整 `.customize.yaml`，优先选 **Quick Update**。
|
||||
|
||||
## 故障排除
|
||||
## 故障排查
|
||||
|
||||
**更改未生效？**
|
||||
**改动没有生效？**
|
||||
|
||||
- 运行 `npx bmad-method install` 并选择 **Recompile Agents** 以应用更改
|
||||
- 检查您的 YAML 语法是否有效（缩进很重要）
|
||||
- 验证您编辑的是该智能体正确的 `.customize.yaml` 文件
|
||||
- 运行 `npx bmad-method install` 并选择 **Quick Update** 以应用更改
|
||||
- 检查 YAML 语法是否正确（尤其是缩进）
|
||||
- 确认你编辑的是目标智能体对应的 `.customize.yaml`
|
||||
|
||||
**智能体无法加载？**
|
||||
|
||||
- 使用在线 YAML 验证器检查 YAML 语法错误
|
||||
- 确保在取消注释后没有留下空字段
|
||||
- 尝试恢复到原始模板并重新构建
|
||||
- 确保取消注释后没有遗留空字段
|
||||
- 可先回退到模板，再逐项恢复自定义配置
|
||||
|
||||
**需要重置智能体？**
|
||||
**需要重置某个智能体？**
|
||||
|
||||
- 清空或删除智能体的 `.customize.yaml` 文件
|
||||
- 运行 `npx bmad-method install` 并选择 **Recompile Agents** 以恢复默认设置
|
||||
- 运行 `npx bmad-method install` 并选择 **Quick Update** 以恢复默认设置
|
||||
|
||||
## 工作流自定义
|
||||
|
||||
对现有 BMad Method 工作流和技能的自定义即将推出。
|
||||
对现有 BMad Method 工作流和技能的深度自定义能力即将推出。
|
||||
|
||||
## 模块自定义
|
||||
|
||||
关于构建扩展模块和自定义现有模块的指南即将推出。
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
## 后续步骤
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **workflow**：工作流。指一系列有序的任务或步骤，用于完成特定目标。
|
||||
- **persona**：角色。指智能体的身份、个性、沟通风格和行为原则的集合。
|
||||
- **memory**：记忆。指智能体持久存储的上下文信息，用于在对话中保持连贯性。
|
||||
- **critical action**：关键操作。指智能体启动时必须执行的指令或任务。
|
||||
- **prompt**：提示。指发送给智能体的输入文本，用于引导其生成特定响应或执行特定操作。
|
||||
- [文档分片指南](./shard-large-documents.md) - 了解如何管理超长文档
|
||||
- [命令参考](../reference/commands.md) - 查看可用命令和工作流入口
|
||||
|
|
|
|||
|
|
@ -5,9 +5,9 @@ sidebar:
|
|||
order: 6
|
||||
---
|
||||
|
||||
在现有项目和遗留代码库上工作时，有效使用 BMad Method。
|
||||
当你在现有项目或遗留代码库上工作时，本指南帮助你更稳妥地使用 BMad Method。
|
||||
|
||||
本指南涵盖了使用 BMad Method 接入现有项目的核心工作流程。
|
||||
如果你是从零开始的新项目，建议先看[快速入门](../tutorials/getting-started.md)；本文主要面向既有项目接入场景。
|
||||
|
||||
:::note[前置条件]
|
||||
- 已安装 BMad Method（`npx bmad-method install`）
|
||||
|
|
@ -23,16 +23,16 @@ sidebar:
|
|||
- `_bmad-output/planning-artifacts/`
|
||||
- `_bmad-output/implementation-artifacts/`
|
||||
|
||||
## 步骤 2：创建项目上下文
|
||||
## 步骤 2：创建项目上下文（project context）
|
||||
|
||||
:::tip[推荐用于既有项目]
|
||||
生成 `project-context.md` 以捕获你现有代码库的模式和约定。这确保 AI 智能体在实施变更时遵循你既定的实践。
|
||||
生成 `project-context.md`，梳理现有代码库的模式与约定，确保 AI 智能体在实施变更时遵循你既有的工程实践。
|
||||
:::
|
||||
|
||||
运行生成项目上下文工作流程：
|
||||
运行生成项目上下文工作流：
|
||||
|
||||
```bash
|
||||
/bmad-bmm-generate-project-context
|
||||
bmad-generate-project-context
|
||||
```
|
||||
|
||||
这将扫描你的代码库以识别：
|
||||
|
|
@ -40,9 +40,10 @@ sidebar:
|
|||
- 代码组织模式
|
||||
- 命名约定
|
||||
- 测试方法
|
||||
- 框架特定模式
|
||||
- 框架相关模式
|
||||
|
||||
你可以查看和完善生成的文件，或者如果你更喜欢，可以在 `_bmad-output/project-context.md` 手动创建它。
|
||||
你可以先审阅并完善生成内容；如果更希望手动维护，也可以直接在
|
||||
`_bmad-output/project-context.md` 创建并编辑。
|
||||
|
||||
[了解更多关于项目上下文](../explanation/project-context.md)
|
||||
|
||||
|
|
@ -55,80 +56,63 @@ sidebar:
|
|||
- 架构
|
||||
- 任何其他相关的项目信息
|
||||
|
||||
对于复杂项目，考虑使用 `document-project` 工作流程。它提供运行时变体，将扫描你的整个项目并记录其实际当前状态。
|
||||
对于复杂项目，可考虑使用 `bmad-document-project` 工作流。它会扫描整个项目并记录当前真实状态。
|
||||
|
||||
## 步骤 3：获取帮助
|
||||
## 步骤 4：获取帮助
|
||||
|
||||
### BMad-Help：你的起点
|
||||
### BMad-Help：默认起点
|
||||
|
||||
**随时运行 `bmad-help`，当你不确定下一步该做什么时。** 这个智能指南：
|
||||
**当你不确定下一步做什么时，随时运行 `bmad-help`。** 这个智能指南会：
|
||||
|
||||
- 检查你的项目以查看已经完成了什么
|
||||
- 根据你安装的模块显示选项
|
||||
- 检查项目当前状态，识别哪些工作已经完成
|
||||
- 根据你安装的模块给出可行选项
|
||||
- 理解自然语言查询
|
||||
|
||||
```
|
||||
bmad-help 我有一个现有的 Rails 应用，我应该从哪里开始？
|
||||
bmad-help quick-flow 和完整方法有什么区别？
|
||||
bmad-help 显示我有哪些可用的工作流程
|
||||
bmad-help Quick Flow 和完整方法有什么区别？
|
||||
bmad-help 显示我当前有哪些可用工作流
|
||||
```
|
||||
|
||||
BMad-Help 还会在**每个工作流程结束时自动运行**，提供关于下一步该做什么的清晰指导。
|
||||
BMad-Help 还会在**每个工作流结束时自动运行**，明确告诉你下一步该做什么。
|
||||
|
||||
### 选择你的方法
|
||||
|
||||
根据变更范围，你有两个主要选项：
|
||||
|
||||
| 范围 | 推荐方法 |
|
||||
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------- |
|
||||
| **小型更新或添加** | 运行 `bmad-quick-dev` 在单个工作流中澄清意图、规划、实现和审查。完整的四阶段 BMad Method 可能有些过度。 |
|
||||
| **重大变更或添加** | 从 BMad Method 开始，根据需要应用或多或少的严谨性。 |
|
||||
| 范围 | 推荐方法 |
|
||||
| --- | --- |
|
||||
| **小型更新或新增** | 运行 `bmad-quick-dev`，在单个工作流中完成意图澄清、规划、实现与审查。完整四阶段 BMad Method 往往过重。 |
|
||||
| **重大变更或新增** | 从完整 BMad Method 开始，再按项目风险和协作需求调整流程严谨度。 |
|
||||
|
||||
### 在创建 PRD 期间
|
||||
|
||||
在创建简报或直接进入 PRD 时，确保智能体：
|
||||
|
||||
- 查找并分析你现有的项目文档
|
||||
- 阅读关于你当前系统的适当上下文
|
||||
- 读取与你当前系统匹配的项目上下文（project context）
|
||||
|
||||
你可以明确地指导智能体，但目标是确保新功能与你的现有系统良好集成。
|
||||
你可以显式补充指令，但核心目标是让新功能与现有 architecture 和代码约束自然融合。
|
||||
|
||||
### UX 考量
|
||||
|
||||
UX 工作是可选的。决定不取决于你的项目是否有 UX，而取决于：
|
||||
UX 工作是可选项。是否需要进入 UX 流程，不取决于“项目里有没有 UX”，而取决于：
|
||||
|
||||
- 你是否将处理 UX 变更
|
||||
- 是否需要重要的新 UX 设计或模式
|
||||
- 你是否真的在做 UX 层面的变更
|
||||
- 是否需要新增重要的 UX 设计或交互模式
|
||||
|
||||
如果你的变更只是对你满意的现有屏幕进行简单更新，则不需要完整的 UX 流程。
|
||||
如果本次只是对现有页面做小幅调整，通常不需要完整 UX 流程。
|
||||
|
||||
### 架构考量
|
||||
### 架构考量（architecture）
|
||||
|
||||
在进行架构工作时，确保架构师：
|
||||
|
||||
- 使用适当的已记录文件
|
||||
- 扫描现有代码库
|
||||
- 使用正确且最新的文档输入
|
||||
- 扫描并理解现有代码库
|
||||
|
||||
在此处要密切注意，以防止重新发明轮子或做出与你现有架构不一致的决定。
|
||||
这一点非常关键：可避免“重复造轮子”，也能减少与现有架构冲突的设计决策。
|
||||
|
||||
## 更多信息
|
||||
|
||||
- **[快速修复](./quick-fixes.md)** - 错误修复和临时变更
|
||||
- **[既有项目 FAQ](../explanation/established-projects-faq.md)** - 关于在既有项目上工作的常见问题
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **BMad Method**：BMad 方法。一种结构化的软件开发方法论，用于指导从分析到实施的完整流程。
|
||||
- **PRD**：产品需求文档（Product Requirements Document）。描述产品功能、需求和目标的文档。
|
||||
- **epic**：史诗。大型功能或用户故事的集合，通常需要较长时间完成。
|
||||
- **story**：用户故事。描述用户需求的简短陈述，通常遵循"作为...我想要...以便于..."的格式。
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **IDE**：集成开发环境（Integrated Development Environment）。提供代码编辑、调试、构建等功能的软件工具。
|
||||
- **UX**：用户体验（User Experience）。用户在使用产品或服务过程中的整体感受和交互体验。
|
||||
- **tech-spec**：技术规范（Technical Specification）。描述技术实现细节、架构设计和开发标准的文档。
|
||||
- **quick-flow**：快速流程。BMad Method 中的一种简化工作流程，适用于小型变更或快速迭代。
|
||||
- **legacy codebase**：遗留代码库。指历史遗留的、可能缺乏文档或使用过时技术的代码集合。
|
||||
- **project context**：项目上下文。描述项目技术栈、约定、模式等背景信息的文档。
|
||||
- **artifact**：产物。在开发过程中生成的文档、代码或其他输出物。
|
||||
- **runtime variant**：运行时变体。在程序运行时可选择或切换的不同实现方式或配置。
|
||||
|
|
|
|||
|
|
@ -5,108 +5,109 @@ sidebar:
|
|||
order: 4
|
||||
---
|
||||
|
||||
## 从这里开始：BMad-Help
|
||||
## 先从 BMad-Help 开始
|
||||
|
||||
**获取关于 BMad 答案的最快方式是 `bmad-help`。** 这个智能指南可以回答超过 80% 的问题，并且直接在您的 IDE 中可用，方便您工作时使用。
|
||||
**获取 BMad 相关答案最快的方式是 `bmad-help` 技能。** 这个智能向导可以覆盖 80% 以上的常见问题，并且你在 IDE 里随时可用。
|
||||
|
||||
BMad-Help 不仅仅是一个查询工具——它：
|
||||
- **检查您的项目**以查看已完成的内容
|
||||
- **理解自然语言**——用简单的英语提问
|
||||
- **根据您安装的模块变化**——显示相关选项
|
||||
- **在工作流后自动运行**——告诉您接下来该做什么
|
||||
- **推荐第一个必需任务**——无需猜测从哪里开始
|
||||
BMad-Help 不只是查表工具，它还能：
|
||||
- **检查你的项目状态**，判断哪些步骤已经完成
|
||||
- **理解自然语言问题**，直接按日常表达提问即可
|
||||
- **根据已安装模块给出选项**，只展示与你当前场景相关的内容
|
||||
- **在工作流结束后自动运行**，明确告诉你下一步做什么
|
||||
- **指出第一个必做任务**，避免猜流程起点
|
||||
|
||||
### 如何使用 BMad-Help
|
||||
|
||||
只需使用斜杠命令运行它：
|
||||
在 AI 会话里直接输入：
|
||||
|
||||
```
|
||||
bmad-help
|
||||
```
|
||||
|
||||
或者结合自然语言查询：
|
||||
:::tip
|
||||
按平台不同，你也可以使用 `/bmad-help` 或 `$bmad-help`。但大多数情况下直接输入 `bmad-help` 就能工作。
|
||||
:::
|
||||
|
||||
也可以结合自然语言问题一起调用：
|
||||
|
||||
```
|
||||
bmad-help 我有一个 SaaS 想法并且知道所有功能。我应该从哪里开始？
|
||||
bmad-help 我在 UX 设计方面有哪些选择？
|
||||
bmad-help 我在 PRD 工作流上卡住了
|
||||
bmad-help 向我展示到目前为止已完成的内容
|
||||
bmad-help 我有一个 SaaS 想法并且已经知道主要功能，我该从哪里开始？
|
||||
bmad-help 我在 UX 设计方面有哪些选项？
|
||||
bmad-help 我卡在 PRD 工作流了
|
||||
bmad-help 帮我看看目前完成了什么
|
||||
```
|
||||
|
||||
BMad-Help 会回应：
|
||||
- 针对您情况的建议
|
||||
- 第一个必需任务是什么
|
||||
- 流程的其余部分是什么样的
|
||||
BMad-Help 通常会返回：
|
||||
- 针对你当前情况的建议路径
|
||||
- 第一个必做任务
|
||||
- 后续整体流程概览
|
||||
|
||||
---
|
||||
## 何时使用这篇指南
|
||||
|
||||
## 何时使用本指南
|
||||
|
||||
在以下情况下使用本节：
|
||||
- 您想了解 BMad 的架构或内部机制
|
||||
- 您需要 BMad-Help 提供范围之外的答案
|
||||
- 您在安装前研究 BMad
|
||||
- 您想直接探索源代码
|
||||
当你遇到以下情况时，可用本指南补充：
|
||||
- 想理解 BMad 的架构设计或内部机制
|
||||
- 需要超出 BMad-Help 覆盖范围的答案
|
||||
- 在安装前做技术调研
|
||||
- 想直接基于源码进行追问
|
||||
|
||||
## 步骤
|
||||
|
||||
### 1. 选择您的来源
|
||||
### 1. 选择信息来源
|
||||
|
||||
| 来源 | 最适合用于 | 示例 |
|
||||
| -------------------- | ----------------------------------------- | ---------------------------- |
|
||||
| **`_bmad` 文件夹** | BMad 如何工作——智能体、工作流、提示词 | "PM 智能体做什么？" |
|
||||
| **完整的 GitHub 仓库** | 历史、安装程序、架构 | "v6 中有什么变化？" |
|
||||
| **`llms-full.txt`** | 来自文档的快速概述 | "解释 BMad 的四个阶段" |
|
||||
| 来源 | 适合回答的问题 | 示例 |
|
||||
| --- | --- | --- |
|
||||
| **`_bmad` 文件夹** | 智能体、工作流、提示词如何工作 | “PM 智能体具体做什么？” |
|
||||
| **完整 GitHub 仓库** | 版本历史、安装器、整体架构 | “v6 主要改了什么？” |
|
||||
| **`llms-full.txt`** | 文档层面的快速全景理解 | “解释 BMad 的四个阶段” |
|
||||
|
||||
`_bmad` 文件夹在您安装 BMad 时创建。如果您还没有它，请改为克隆仓库。
|
||||
安装 BMad 后会生成 `_bmad` 文件夹；如果你还没有安装，可先克隆仓库。
|
||||
|
||||
### 2. 将您的 AI 指向来源
|
||||
### 2. 让 AI 读取来源
|
||||
|
||||
**如果您的 AI 可以读取文件（Claude Code、Cursor 等）：**
|
||||
**如果你的 AI 可以直接读文件（如 Claude Code、Cursor）：**
|
||||
|
||||
- **已安装 BMad：** 指向 `_bmad` 文件夹并直接提问
|
||||
- **想要更深入的上下文：** 克隆[完整仓库](https://github.com/bmad-code-org/BMAD-METHOD)
|
||||
- **已安装 BMad：** 直接让它读取 `_bmad` 并提问
|
||||
- **想看更深上下文：** 克隆[完整仓库](https://github.com/bmad-code-org/BMAD-METHOD)
|
||||
|
||||
**如果您使用 ChatGPT 或 Claude.ai：**
|
||||
**如果你使用 ChatGPT 或 Claude.ai：**
|
||||
|
||||
将 `llms-full.txt` 获取到您的会话中：
|
||||
把 `llms-full.txt` 加入会话上下文：
|
||||
|
||||
```text
|
||||
https://bmad-code-org.github.io/BMAD-METHOD/llms-full.txt
|
||||
```
|
||||
|
||||
|
||||
### 3. 提出您的问题
|
||||
### 3. 直接提问
|
||||
|
||||
:::note[示例]
|
||||
**问：** "告诉我用 BMad 构建某物的最快方式"
|
||||
**问：** “用 BMad 做一个需求到实现的最短路径是什么？”
|
||||
|
||||
**答：** 使用快速流程：运行 `bmad-quick-dev` — 它在单个工作流中澄清意图、规划、实现、审查和呈现结果，跳过完整的规划阶段。
|
||||
**答：** 使用 Quick Flow，运行 `bmad-quick-dev`。它会在一个工作流里完成意图澄清、计划、实现、审查与结果呈现，跳过完整规划阶段。
|
||||
:::
|
||||
|
||||
## 您将获得什么
|
||||
## 你将获得什么
|
||||
|
||||
关于 BMad 的直接答案——智能体如何工作、工作流做什么、为什么事物以这种方式构建——无需等待其他人回应。
|
||||
你可以快速拿到直接、可执行的答案：智能体怎么工作、工作流做什么、为什么这样设计，而不需要等待外部回复。
|
||||
|
||||
## 提示
|
||||
|
||||
- **验证令人惊讶的答案**——LLM 偶尔会出错。检查源文件或在 Discord 上询问。
|
||||
- **具体化**——"PRD 工作流的第 3 步做什么？"比"PRD 如何工作？"更好
|
||||
- **对“意外答案”做二次核验**：LLM 偶尔会答偏，建议回看源码或到 Discord 确认
|
||||
- **问题越具体越好**：例如“PRD 工作流第 3 步在做什么？”比“PRD 怎么用？”更高效
|
||||
|
||||
## 仍然卡住了？
|
||||
## 仍然卡住？
|
||||
|
||||
尝试了 LLM 方法但仍需要帮助？您现在有一个更好的问题可以问。
|
||||
如果你已经试过 LLM 方案但还需要协助，现在你通常已经能提出一个更清晰的问题。
|
||||
|
||||
| 频道 | 用于 |
|
||||
| ------------------------- | ------------------------------------------- |
|
||||
| `#bmad-method-help` | 快速问题（实时聊天） |
|
||||
| `help-requests` 论坛 | 详细问题（可搜索、持久） |
|
||||
| `#suggestions-feedback` | 想法和功能请求 |
|
||||
| `#report-bugs-and-issues` | 错误报告 |
|
||||
| 频道 | 适用场景 |
|
||||
| --- | --- |
|
||||
| `#bmad-method-help` | 快速问题（实时聊天） |
|
||||
| `help-requests` forum | 复杂问题（可检索、可沉淀） |
|
||||
| `#suggestions-feedback` | 建议与功能诉求 |
|
||||
| `#report-bugs-and-issues` | Bug 报告 |
|
||||
|
||||
**Discord：** [discord.gg/gk8jAdXWmj](https://discord.gg/gk8jAdXWmj)
|
||||
|
||||
**GitHub Issues：** [github.com/bmad-code-org/BMAD-METHOD/issues](https://github.com/bmad-code-org/BMAD-METHOD/issues)（用于明确的错误）
|
||||
**Discord：** [discord.gg/gk8jAdXWmj](https://discord.gg/gk8jAdXWmj)
|
||||
**GitHub Issues：** [github.com/bmad-code-org/BMAD-METHOD/issues](https://github.com/bmad-code-org/BMAD-METHOD/issues)（用于可复现问题）
|
||||
|
||||
*你！*
|
||||
*卡住*
|
||||
|
|
@ -132,13 +133,3 @@ https://bmad-code-org.github.io/BMAD-METHOD/llms-full.txt
|
|||
*今天？*
|
||||
|
||||
*—Claude*
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **LLM**：大语言模型。基于深度学习的自然语言处理模型，能够理解和生成人类语言。
|
||||
- **SaaS**：软件即服务。一种通过互联网提供软件应用的交付模式。
|
||||
- **UX**：用户体验。用户在使用产品或服务过程中建立的主观感受和评价。
|
||||
- **PRD**：产品需求文档。详细描述产品功能、特性和需求的正式文档。
|
||||
- **IDE**：集成开发环境。提供代码编辑、调试、构建等功能的软件开发工具。
|
||||
|
|
|
|||
|
|
@ -5,9 +5,9 @@ sidebar:
|
|||
order: 1
|
||||
---
|
||||
|
||||
使用 `npx bmad-method install` 命令在项目中设置 BMad，并选择你需要的模块和 AI 工具。
|
||||
使用 `npx bmad-method install` 在项目中安装 BMad，并按需选择模块和 AI 工具。
|
||||
|
||||
如果你想使用非交互式安装程序并在命令行中提供所有安装选项，请参阅[本指南](./non-interactive-installation.md)。
|
||||
如果你需要在命令行里一次性传入全部安装参数（例如 CI/CD 场景），请阅读[非交互式安装指南](./non-interactive-installation.md)。
|
||||
|
||||
## 何时使用
|
||||
|
||||
|
|
@ -29,7 +29,16 @@ sidebar:
|
|||
npx bmad-method install
|
||||
```
|
||||
|
||||
:::tip[最新版本]
|
||||
:::tip[想要最新预发布版本？]
|
||||
使用 `next` 发布标签：
|
||||
```bash
|
||||
npx bmad-method@next install
|
||||
```
|
||||
|
||||
这会更早拿到新改动，但相比默认安装通道，出现变动的概率也更高。
|
||||
:::
|
||||
|
||||
:::tip[前沿版本]
|
||||
要从主分支安装最新版本（可能不稳定）：
|
||||
```bash
|
||||
npx github:bmad-code-org/BMAD-METHOD install
|
||||
|
|
@ -51,7 +60,11 @@ npx github:bmad-code-org/BMAD-METHOD install
|
|||
- Cursor
|
||||
- 其他
|
||||
|
||||
每个工具都有自己的命令集成方式。安装程序会创建微小的提示文件来激活工作流和智能体——它只是将它们放在工具期望找到的位置。
|
||||
每种工具都有自己的 skills 集成方式。安装程序会生成用于激活工作流和智能体的轻量提示文件，并放到该工具约定的位置。
|
||||
|
||||
:::note[启用 Skills]
|
||||
某些平台需要你在设置中手动启用 skills 才会显示。如果你已经安装 BMad 但看不到 skills，请检查平台设置，或直接询问你的 AI 助手如何启用 skills。
|
||||
:::
|
||||
|
||||
### 4. 选择模块
|
||||
|
||||
|
|
@ -63,16 +76,25 @@ npx github:bmad-code-org/BMAD-METHOD install
|
|||
|
||||
## 你将获得
|
||||
|
||||
以下目录结构仅作示例。工具相关目录会随你选择的平台变化（例如可能是
|
||||
`.claude/skills`、`.cursor/skills` 或 `.kiro/skills`），并不一定会同时出现。
|
||||
|
||||
```text
|
||||
your-project/
|
||||
├── _bmad/
|
||||
│ ├── bmm/ # 你选择的模块
|
||||
│ │ └── config.yaml # 模块设置（如果你需要更改它们）
|
||||
│ ├── core/ # 必需的核心模块
|
||||
│ │ └── config.yaml # 模块设置（后续如需可修改）
|
||||
│ ├── core/ # 必需核心模块
|
||||
│ └── ...
|
||||
├── _bmad-output/ # 生成的工件
|
||||
├── .claude/ # Claude Code 命令（如果使用 Claude Code）
|
||||
└── .kiro/ # Kiro 引导文件（如果使用 Kiro）
|
||||
├── _bmad-output/ # 生成产物
|
||||
├── .claude/ # Claude Code skills（如使用 Claude Code）
|
||||
│ └── skills/
|
||||
│ ├── bmad-help/
|
||||
│ ├── bmad-persona/
|
||||
│ └── ...
|
||||
└── .cursor/ # Cursor skills（如使用 Cursor）
|
||||
└── skills/
|
||||
└── ...
|
||||
```
|
||||
|
||||
## 验证安装
|
||||
|
|
@ -96,10 +118,3 @@ bmad-help 对于 SaaS 项目我有哪些选项？
|
|||
|
||||
**安装程序工作正常但后续出现问题**——你的 AI 需要 BMad 上下文才能提供帮助。请参阅[如何获取关于 BMad 的答案](./get-answers-about-bmad.md)了解如何将你的 AI 指向正确的来源。
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **workflow**：工作流。指一系列有序的任务或步骤，用于完成特定目标。
|
||||
- **module**：模块。指软件系统中可独立开发、测试和维护的功能单元。
|
||||
- **artifact**：工件。指在软件开发过程中生成的任何输出，如文档、代码、配置文件等。
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
title: "非交互式安装"
|
||||
description: 使用命令行标志安装 BMad，适用于 CI/CD 流水线和自动化部署
|
||||
description: 使用命令行参数安装 BMad，适用于 CI/CD 流水线和自动化部署
|
||||
sidebar:
|
||||
order: 2
|
||||
---
|
||||
|
||||
使用命令行标志以非交互方式安装 BMad。这适用于：
|
||||
使用命令行参数（flags）以非交互方式安装 BMad。适用于以下场景：
|
||||
|
||||
## 使用场景
|
||||
|
||||
|
|
@ -18,21 +18,21 @@ sidebar:
|
|||
需要 [Node.js](https://nodejs.org) v20+ 和 `npx`（随 npm 附带）。
|
||||
:::
|
||||
|
||||
## 可用标志
|
||||
## 可用参数（Flags）
|
||||
|
||||
### 安装选项
|
||||
|
||||
| 标志 | 描述 | 示例 |
|
||||
| 参数 | 描述 | 示例 |
|
||||
|------|-------------|---------|
|
||||
| `--directory <path>` | 安装目录 | `--directory ~/projects/myapp` |
|
||||
| `--modules <modules>` | 逗号分隔的模块 ID | `--modules bmm,bmb` |
|
||||
| `--tools <tools>` | 逗号分隔的工具/IDE ID（使用 `none` 跳过） | `--tools claude-code,cursor` 或 `--tools none` |
|
||||
| `--custom-content <paths>` | 逗号分隔的自定义模块路径 | `--custom-content ~/my-module,~/another-module` |
|
||||
| `--action <type>` | 对现有安装的操作：`install`（默认）、`update`、`quick-update` 或 `compile-agents` | `--action quick-update` |
|
||||
| `--action <type>` | 对现有安装的操作：`install`（默认）、`update` 或 `quick-update` | `--action quick-update` |
|
||||
|
||||
### 核心配置
|
||||
|
||||
| 标志 | 描述 | 默认值 |
|
||||
| 参数 | 描述 | 默认值 |
|
||||
|------|-------------|---------|
|
||||
| `--user-name <name>` | 智能体使用的名称 | 系统用户名 |
|
||||
| `--communication-language <lang>` | 智能体通信语言 | 英语 |
|
||||
|
|
@ -41,14 +41,14 @@ sidebar:
|
|||
|
||||
### 其他选项
|
||||
|
||||
| 标志 | 描述 |
|
||||
| 参数 | 描述 |
|
||||
|------|-------------|
|
||||
| `-y, --yes` | 接受所有默认值并跳过提示 |
|
||||
| `-d, --debug` | 启用清单生成的调试输出 |
|
||||
|
||||
## 模块 ID
|
||||
|
||||
`--modules` 标志可用的模块 ID：
|
||||
`--modules` 参数可用的模块 ID：
|
||||
|
||||
- `bmm` — BMad Method Master
|
||||
- `bmb` — BMad Builder
|
||||
|
|
@ -57,7 +57,7 @@ sidebar:
|
|||
|
||||
## 工具/IDE ID
|
||||
|
||||
`--tools` 标志可用的工具 ID：
|
||||
`--tools` 参数可用的工具 ID：
|
||||
|
||||
**推荐：** `claude-code`、`cursor`
|
||||
|
||||
|
|
@ -67,8 +67,8 @@ sidebar:
|
|||
|
||||
| 模式 | 描述 | 示例 |
|
||||
|------|-------------|---------|
|
||||
| 完全非交互式 | 提供所有标志以跳过所有提示 | `npx bmad-method install --directory . --modules bmm --tools claude-code --yes` |
|
||||
| 半交互式 | 提供部分标志；BMad 提示其余部分 | `npx bmad-method install --directory . --modules bmm` |
|
||||
| 完全非交互式 | 提供所有参数以跳过所有提示 | `npx bmad-method install --directory . --modules bmm --tools claude-code --yes` |
|
||||
| 半交互式 | 提供部分参数；BMad 提示其余部分 | `npx bmad-method install --directory . --modules bmm` |
|
||||
| 仅使用默认值 | 使用 `-y` 接受所有默认值 | `npx bmad-method install --yes` |
|
||||
| 不包含工具 | 跳过工具/IDE 配置 | `npx bmad-method install --modules bmm --tools none` |
|
||||
|
||||
|
|
@ -121,18 +121,18 @@ npx bmad-method install \
|
|||
## 安装结果
|
||||
|
||||
- 项目中完全配置的 `_bmad/` 目录
|
||||
- 为所选模块和工具编译的智能体和工作流
|
||||
- 为所选模块和工具配置的智能体和工作流
|
||||
- 用于生成产物的 `_bmad-output/` 文件夹
|
||||
|
||||
## 验证和错误处理
|
||||
## 参数校验与错误处理
|
||||
|
||||
BMad 会验证所有提供的标志：
|
||||
BMad 会验证你提供的所有参数：
|
||||
|
||||
- **目录** — 必须是具有写入权限的有效路径
|
||||
- **模块** — 对无效的模块 ID 发出警告（但不会失败）
|
||||
- **工具** — 对无效的工具 ID 发出警告（但不会失败）
|
||||
- **自定义内容** — 每个路径必须包含有效的 `module.yaml` 文件
|
||||
- **操作** — 必须是以下之一：`install`、`update`、`quick-update`、`compile-agents`
|
||||
- **操作** — 必须是以下之一：`install`、`update`、`quick-update`
|
||||
|
||||
无效值将：
|
||||
1. 显示错误并退出（对于目录等关键选项）
|
||||
|
|
@ -141,14 +141,14 @@ BMad 会验证所有提供的标志：
|
|||
|
||||
:::tip[最佳实践]
|
||||
- 为 `--directory` 使用绝对路径以避免歧义
|
||||
- 在 CI/CD 流水线中使用前先在本地测试标志
|
||||
- 在 CI/CD 流水线中使用前先在本地测试参数
|
||||
- 结合 `-y` 实现真正的无人值守安装
|
||||
- 如果在安装过程中遇到问题，使用 `--debug`
|
||||
:::
|
||||
|
||||
## 故障排除
|
||||
|
||||
### 安装失败，提示"Invalid directory"
|
||||
### 安装失败，提示 `Invalid directory`
|
||||
|
||||
- 目录路径必须存在（或其父目录必须存在）
|
||||
- 您需要写入权限
|
||||
|
|
@ -167,15 +167,6 @@ BMad 会验证所有提供的标志：
|
|||
- 在 `module.yaml` 中有 `code` 字段
|
||||
|
||||
:::note[仍然卡住了？]
|
||||
使用 `--debug` 运行以获取详细输出，尝试交互模式以隔离问题，或在 <https://github.com/bmad-code-org/BMAD-METHOD/issues> 报告。
|
||||
使用 `--debug` 获取详细输出，尝试交互模式定位问题，或在 <https://github.com/bmad-code-org/BMAD-METHOD/issues> 提交反馈。
|
||||
:::
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **CI/CD**：持续集成/持续部署。一种自动化软件开发流程的实践，用于频繁集成代码更改并自动部署到生产环境。
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **module**：模块。软件系统中可独立开发、测试和维护的功能单元。
|
||||
- **IDE**：集成开发环境。提供代码编辑、调试、构建等功能的软件开发工具。
|
||||
- **npx**：Node Package eXecute。npm 包执行器，用于直接执行 npm 包而无需全局安装。
|
||||
- **workflow**：工作流。一系列有序的任务或步骤，用于完成特定的业务流程或开发流程。
|
||||
|
|
|
|||
|
|
@ -5,27 +5,30 @@ sidebar:
|
|||
order: 8
|
||||
---
|
||||
|
||||
使用 `project-context.md` 文件确保 AI 智能体在所有工作流程中遵循项目的技术偏好和实现规则。
|
||||
使用 `project-context.md`，确保 AI 智能体在各类工作流中遵循项目的技术偏好与实现规则。
|
||||
为了保证这份上下文始终可见，你也可以在工具上下文或 always-rules 文件（如 `AGENTS.md`）
|
||||
中加入这句：
|
||||
`Important project context and conventions are located in [path to project context]/project-context.md`
|
||||
|
||||
:::note[前置条件]
|
||||
- 已安装 BMad Method
|
||||
- 了解项目的技术栈和约定
|
||||
- 了解项目的技术栈与团队约定
|
||||
:::
|
||||
|
||||
## 何时使用
|
||||
|
||||
- 在开始架构设计之前有明确的技术偏好
|
||||
- 已完成架构设计并希望为实施捕获决策
|
||||
- 正在处理具有既定模式的现有代码库
|
||||
- 注意到智能体在不同用户故事中做出不一致的决策
|
||||
- 在开始架构（architecture）前，你已有明确的技术偏好
|
||||
- 已完成架构设计，希望把关键决策沉淀到实施阶段
|
||||
- 正在处理具有既定模式的既有代码库
|
||||
- 发现智能体在不同用户故事（story）之间决策不一致
|
||||
|
||||
## 步骤 1：选择方法
|
||||
## 步骤 1：选择路径
|
||||
|
||||
**手动创建** — 当您确切知道要记录哪些规则时最佳
|
||||
**手动创建** — 适合你已经明确知道要沉淀哪些规则
|
||||
|
||||
**架构后生成** — 最适合捕获解决方案制定过程中所做的决策
|
||||
**架构后生成** — 适合把 solutioning 阶段形成的架构决策沉淀下来
|
||||
|
||||
**为现有项目生成** — 最适合在现有代码库中发现模式
|
||||
**为既有项目生成** — 适合从现有代码库中自动发现团队约定与模式
|
||||
|
||||
## 步骤 2：创建文件
|
||||
|
||||
|
|
@ -38,17 +41,17 @@ mkdir -p _bmad-output
|
|||
touch _bmad-output/project-context.md
|
||||
```
|
||||
|
||||
添加技术栈和实现规则：
|
||||
然后补充技术栈与实现规则：
|
||||
|
||||
```markdown
|
||||
---
|
||||
project_name: 'MyProject'
|
||||
user_name: 'YourName'
|
||||
project_name: '我的项目'
|
||||
user_name: '你的名字'
|
||||
date: '2026-02-15'
|
||||
sections_completed: ['technology_stack', 'critical_rules']
|
||||
---
|
||||
|
||||
# AI 智能体的项目上下文
|
||||
# AI 智能体项目上下文
|
||||
|
||||
## 技术栈与版本
|
||||
|
||||
|
|
@ -60,93 +63,70 @@ sections_completed: ['technology_stack', 'critical_rules']
|
|||
## 关键实现规则
|
||||
|
||||
**TypeScript：**
|
||||
- 启用严格模式，不使用 `any` 类型
|
||||
- 公共 API 使用 `interface`，联合类型使用 `type`
|
||||
- 开启严格模式，禁止使用 `any` 类型
|
||||
- 对外 API 使用 `interface`，联合类型使用 `type`
|
||||
|
||||
**代码组织：**
|
||||
- 组件位于 `/src/components/` 并附带同位置测试
|
||||
- API 调用使用 `apiClient` 单例 — 绝不直接使用 fetch
|
||||
- 组件放在 `/src/components/`，并与测试文件同目录（co-located）
|
||||
- API 调用统一使用 `apiClient` 单例，不要直接使用 `fetch`
|
||||
|
||||
**测试：**
|
||||
- 单元测试专注于业务逻辑
|
||||
- 集成测试使用 MSW 进行 API 模拟
|
||||
- 单元测试聚焦业务逻辑
|
||||
- 集成测试使用 MSW 模拟 API
|
||||
```
|
||||
|
||||
### 选项 B：架构后生成
|
||||
|
||||
在新的聊天中运行工作流程：
|
||||
在新的会话中运行：
|
||||
|
||||
```bash
|
||||
/bmad-bmm-generate-project-context
|
||||
bmad-generate-project-context
|
||||
```
|
||||
|
||||
工作流程扫描架构文档和项目文件，生成捕获所做决策的上下文文件。
|
||||
该工作流会扫描架构文档和项目文件，生成能够反映已做决策的上下文文件。
|
||||
|
||||
### 选项 C：为现有项目生成
|
||||
### 选项 C：为既有项目生成
|
||||
|
||||
对于现有项目，运行：
|
||||
对于既有项目，运行：
|
||||
|
||||
```bash
|
||||
/bmad-bmm-generate-project-context
|
||||
bmad-generate-project-context
|
||||
```
|
||||
|
||||
工作流程分析代码库以识别约定，然后生成上下文文件供您审查和完善。
|
||||
该工作流会分析代码库中的约定，然后生成可供你审阅和完善的上下文文件。
|
||||
|
||||
## 步骤 3：验证内容
|
||||
|
||||
审查生成的文件并确保它捕获了：
|
||||
审查生成文件，并确认它覆盖了：
|
||||
|
||||
- 正确的技术版本
|
||||
- 实际约定（而非通用最佳实践）
|
||||
- 防止常见错误的规则
|
||||
- 框架特定的模式
|
||||
- 你的真实约定（不是通用最佳实践）
|
||||
- 能预防常见错误的规则
|
||||
- 框架相关模式
|
||||
|
||||
手动编辑以添加任何缺失内容或删除不准确之处。
|
||||
如果有缺漏或误判，直接手动补充和修正。
|
||||
|
||||
## 您将获得
|
||||
## 你将获得
|
||||
|
||||
一个 `project-context.md` 文件，它：
|
||||
一个 `project-context.md` 文件，它可以：
|
||||
|
||||
- 确保所有智能体遵循相同的约定
|
||||
- 防止在不同用户故事中做出不一致的决策
|
||||
- 为实施捕获架构决策
|
||||
- 作为项目模式和规则的参考
|
||||
- 确保所有智能体遵循相同约定
|
||||
- 避免在不同用户故事（story）中出现不一致决策
|
||||
- 为实施阶段保留架构决策
|
||||
- 作为项目模式与规则的长期参考
|
||||
|
||||
## 提示
|
||||
|
||||
:::tip[关注非显而易见的内容]
|
||||
记录智能体可能遗漏的模式，例如"在每个公共类、函数和变量上使用 JSDoc 风格注释"，而不是像"使用有意义的变量名"这样的通用实践，因为 LLM 目前已经知道这些。
|
||||
:::
|
||||
|
||||
:::tip[保持精简]
|
||||
此文件由每个实施工作流程加载。长文件会浪费上下文。不要包含仅适用于狭窄范围或特定用户故事或功能的内容。
|
||||
:::
|
||||
|
||||
:::tip[根据需要更新]
|
||||
当模式发生变化时手动编辑，或在重大架构更改后重新生成。
|
||||
:::
|
||||
|
||||
:::tip[适用于所有项目类型]
|
||||
对于快速流程和完整的 BMad Method 项目同样有用。
|
||||
:::tip[最佳实践]
|
||||
- **聚焦“不明显但重要”的规则**：优先记录智能体容易漏掉的项目约束，而不是
|
||||
“变量要有意义”这类通用建议。
|
||||
- **保持精简**：此文件会被多数实现工作流加载，过长会浪费上下文窗口。避免写入
|
||||
只适用于单一 story 的细节。
|
||||
- **按需更新**：当团队约定变化时手动更新，或在架构发生较大变化后重新生成。
|
||||
- **适用于 Quick Flow 与完整 BMad Method**：两种模式都可共享同一份项目上下文。
|
||||
:::
|
||||
|
||||
## 后续步骤
|
||||
|
||||
- [**项目上下文说明**](../explanation/project-context.md) — 了解其工作原理
|
||||
- [**工作流程图**](../reference/workflow-map.md) — 查看哪些工作流程加载项目上下文
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **workflow**：工作流程。指完成特定任务的一系列步骤或过程。
|
||||
- **codebase**：代码库。指项目的所有源代码和资源的集合。
|
||||
- **implementation**：实施。指将设计或架构转化为实际代码的过程。
|
||||
- **architecture**：架构。指系统的整体结构和设计。
|
||||
- **stack**：技术栈。指项目使用的技术组合，如编程语言、框架、工具等。
|
||||
- **convention**：约定。指团队或项目中遵循的编码规范和最佳实践。
|
||||
- **singleton**：单例。一种设计模式，确保类只有一个实例。
|
||||
- **co-located**：同位置。指相关文件（如测试文件）与主文件放在同一目录中。
|
||||
- **mocking**：模拟。在测试中用模拟对象替代真实对象的行为。
|
||||
- **context**：上下文。指程序运行时的环境信息或背景信息。
|
||||
- **LLM**：大语言模型。Large Language Model 的缩写，指大型语言模型。
|
||||
- [**项目上下文说明**](../explanation/project-context.md) - 了解其工作原理
|
||||
- [**工作流程图**](../reference/workflow-map.md) - 查看哪些工作流会加载项目上下文
|
||||
|
|
|
|||
|
|
@ -5,9 +5,9 @@ sidebar:
|
|||
order: 5
|
||||
---
|
||||
|
||||
使用 **Quick Dev** 进行 bug 修复、重构或小型针对性更改，这些操作不需要完整的 BMad Method。
|
||||
对于 bug 修复、重构或小范围改动，使用 **Quick Dev** 即可，不必走完整的 BMad Method。
|
||||
|
||||
## 何时使用此方法
|
||||
## 何时使用本指南
|
||||
|
||||
- 原因明确且已知的 bug 修复
|
||||
- 包含在少数文件中的小型重构（重命名、提取、重组）
|
||||
|
|
@ -21,13 +21,13 @@ sidebar:
|
|||
|
||||
## 步骤
|
||||
|
||||
### 1. 启动新的聊天
|
||||
### 1. 开启新会话
|
||||
|
||||
在 AI IDE 中打开一个**新的聊天会话**。重用之前工作流的会话可能导致上下文冲突。
|
||||
在 AI IDE 中开启一个**全新的聊天会话**。复用之前工作流留下的会话，容易引发上下文冲突。
|
||||
|
||||
### 2. 提供你的意图
|
||||
|
||||
Quick Dev 接受自由形式的意图——可以在调用之前、同时或之后提供。示例：
|
||||
Quick Dev 支持自由表达意图，你可以在调用前、调用时或调用后补充说明。示例：
|
||||
|
||||
```text
|
||||
run quick-dev — 修复允许空密码的登录验证 bug。
|
||||
|
|
@ -53,20 +53,20 @@ run quick-dev
|
|||
重构 UserService 以使用 async/await 而不是回调。
|
||||
```
|
||||
|
||||
纯文本、文件路径、GitHub issue URL、bug 跟踪器链接——任何 LLM 能解析为具体意图的内容都可以。
|
||||
纯文本、文件路径、GitHub issue 链接、缺陷跟踪地址都可以，只要 LLM 能解析成明确意图。
|
||||
|
||||
### 3. 回答问题并批准
|
||||
|
||||
Quick Dev 可能会提出澄清问题，或在实现之前呈现简短的规范供你批准。回答它的问题，并在你对计划满意时批准。
|
||||
Quick Dev 可能会先问澄清问题，或在实现前给出一份简短方案供你确认。回答问题后，在你认可方案时再批准继续。
|
||||
|
||||
### 4. 审查和推送
|
||||
|
||||
Quick Dev 实现更改、审查自己的工作、修复问题，并在本地提交。完成后，它会在编辑器中打开受影响的文件。
|
||||
Quick Dev 会实现改动、执行自检并修补问题，然后在本地提交。完成后，它会在编辑器中打开受影响文件。
|
||||
|
||||
- 浏览 diff 以确认更改符合你的意图
|
||||
- 如果看起来有问题，告诉智能体需要修复什么——它可以在同一会话中迭代
|
||||
- 快速浏览 diff，确认改动符合你的意图
|
||||
- 如果有偏差，直接告诉智能体要改什么，它可以在同一会话里继续迭代
|
||||
|
||||
满意后，推送提交。Quick Dev 会提供推送和创建 PR 的选项。
|
||||
确认无误后推送提交。Quick Dev 会提供推送和创建 PR 的选项。
|
||||
|
||||
:::caution[如果出现问题]
|
||||
如果推送的更改导致意外问题，请使用 `git revert HEAD` 干净地撤销最后一次提交。然后启动新聊天并再次运行 Quick Dev 以尝试不同的方法。
|
||||
|
|
@ -80,9 +80,9 @@ Quick Dev 实现更改、审查自己的工作、修复问题，并在本地提
|
|||
|
||||
## 延迟工作
|
||||
|
||||
Quick Dev 保持每次运行聚焦于单一目标。如果你的请求包含多个独立目标，或者审查发现了与你的更改无关的已有问题，Quick Dev 会将它们延迟到一个文件中（实现产物目录中的 `deferred-work.md`），而不是试图一次解决所有问题。
|
||||
Quick Dev 每次只聚焦一个目标。如果你的请求包含多个独立目标，或审查过程中发现与你本次改动无关的存量问题，Quick Dev 会把它们记录到 `deferred-work.md`（位于实现产物目录），而不是一次性全都处理。
|
||||
|
||||
运行后检查此文件——它是你的待办事项积压。每个延迟项目都可以稍后输入到新的 Quick Dev 运行中。
|
||||
每次运行后都建议看一下这个文件，它就是你的后续待办清单。你可以把其中任何一项在后续新的 Quick Dev 会话里单独处理。
|
||||
|
||||
## 何时升级到正式规划
|
||||
|
||||
|
|
@ -92,16 +92,4 @@ Quick Dev 保持每次运行聚焦于单一目标。如果你的请求包含多
|
|||
- 你不确定范围，需要先进行需求发现
|
||||
- 你需要为团队记录文档或架构决策
|
||||
|
||||
参见 [Quick Dev](../explanation/quick-dev.md) 了解 Quick Dev 如何融入 BMad Method。
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **Quick Dev**：快速开发。BMad Method 中的快速工作流，用于小型更改的完整实现周期。
|
||||
- **refactoring**：重构。在不改变代码外部行为的情况下改进其内部结构的过程。
|
||||
- **breaking changes**：破坏性更改。可能导致现有代码或功能不再正常工作的更改。
|
||||
- **test suite**：测试套件。一组用于验证软件功能的测试用例集合。
|
||||
- **CI pipeline**：CI 流水线。持续集成流水线，用于自动化构建、测试和部署代码。
|
||||
- **diff**：差异。文件或代码更改前后的对比。
|
||||
- **commit**：提交。将更改保存到版本控制系统的操作。
|
||||
- **conventional commit**：约定式提交。遵循标准格式的提交消息。
|
||||
参见 [Quick Dev](../explanation/quick-dev.md) 了解 Quick Dev 在 BMad Method 中的位置与边界。
|
||||
|
|
|
|||
|
|
@ -5,19 +5,21 @@ sidebar:
|
|||
order: 9
|
||||
---
|
||||
|
||||
如果需要将大型 Markdown 文件拆分为更小、组织良好的文件以更好地管理上下文，请使用 `shard-doc` 工具。
|
||||
当单个 Markdown 文档过大、影响模型读取时，可使用 `bmad-shard-doc` 工作流把文档拆成按章节组织的小文件，降低上下文压力。
|
||||
|
||||
:::caution[已弃用]
|
||||
不再推荐使用此方法，随着工作流程的更新以及大多数主要 LLM 和工具支持子进程，这很快将变得不再必要。
|
||||
这是兼容性方案，默认不推荐。随着工作流更新，以及主流模型/工具逐步支持子进程（subprocesses），很多场景将不再需要手动分片。
|
||||
:::
|
||||
|
||||
## 何时使用
|
||||
|
||||
仅当你发现所选工具/模型组合无法在需要时加载和读取所有文档作为输入时，才使用此方法。
|
||||
- 你确认当前工具/模型在关键步骤无法一次读入完整文档
|
||||
- 文档体量已明显影响工作流稳定性或响应质量
|
||||
- 你需要保留原文结构，但希望按 `##` 章节拆分维护
|
||||
|
||||
## 什么是文档分片？
|
||||
|
||||
文档分片根据二级标题（`## Heading`）将大型 Markdown 文件拆分为更小、组织良好的文件。
|
||||
文档分片会按二级标题（`## Heading`）把大型 Markdown 文件拆成多个子文件，并生成一个 `index.md` 作为入口。
|
||||
|
||||
### 架构
|
||||
|
||||
|
|
@ -38,16 +40,16 @@ _bmad-output/planning-artifacts/
|
|||
|
||||
## 步骤
|
||||
|
||||
### 1. 运行 Shard-Doc 工具
|
||||
### 1. 运行 `bmad-shard-doc` 工作流
|
||||
|
||||
```bash
|
||||
/bmad-shard-doc
|
||||
```
|
||||
|
||||
### 2. 遵循交互式流程
|
||||
### 2. 按交互流程完成分片
|
||||
|
||||
```text
|
||||
智能体：您想要分片哪个文档？
|
||||
智能体：你想分片哪个文档？
|
||||
用户：docs/PRD.md
|
||||
|
||||
智能体：默认目标位置：docs/prd/
|
||||
|
|
@ -60,27 +62,21 @@ _bmad-output/planning-artifacts/
|
|||
✓ 完成！
|
||||
```
|
||||
|
||||
## 工作流程发现机制
|
||||
## 工作流发现机制
|
||||
|
||||
BMad 工作流程使用**双重发现系统**：
|
||||
BMad 工作流使用**双重发现机制**：
|
||||
|
||||
1. **首先尝试完整文档** - 查找 `document-name.md`
|
||||
2. **检查分片版本** - 查找 `document-name/index.md`
|
||||
3. **优先级规则** - 如果两者都存在，完整文档优先 - 如果希望使用分片版本，请删除完整文档
|
||||
1. **先查完整文档** - 查找 `document-name.md`
|
||||
2. **再查分片入口** - 查找 `document-name/index.md`
|
||||
3. **优先级规则** - 若两者并存，默认优先完整文档；若你要强制使用分片版本，请删除或重命名完整文档
|
||||
|
||||
## 工作流程支持
|
||||
## 你将获得
|
||||
|
||||
所有 BMM 工作流程都支持这两种格式：
|
||||
- 原始完整文档（可保留，但不建议与分片长期并存；并存时默认优先读取完整文档）
|
||||
- 分片目录（如 `document-name/index.md` + 各章节文件）
|
||||
- 对工作流透明的自动识别行为（无需额外配置）
|
||||
|
||||
- 完整文档
|
||||
- 分片文档
|
||||
- 自动检测
|
||||
- 对用户透明
|
||||
## 后续步骤
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **sharding**：分片。将大型文档或数据集拆分为更小、更易管理的部分的过程。
|
||||
- **token**：令牌。在自然语言处理和大型语言模型中，文本的基本单位，通常对应单词或字符的一部分。
|
||||
- **subprocesses**：子进程。由主进程创建的独立执行单元，可以并行运行以执行特定任务。
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- [如何自定义 BMad](./customize-bmad.md) - 了解高级配置与工作流定制边界
|
||||
- [如何升级到 v6](./upgrade-to-v6.md) - 在迁移过程中处理文档与目录结构变化
|
||||
|
|
|
|||
|
|
@ -5,76 +5,83 @@ sidebar:
|
|||
order: 3
|
||||
---
|
||||
|
||||
使用 BMad 安装程序从 v4 升级到 v6，其中包括自动检测旧版安装和迁移辅助。
|
||||
使用 BMad 安装程序把 v4 升级到 v6。安装程序会自动识别旧安装，并提供迁移辅助，帮助你在已有项目中平滑过渡。
|
||||
|
||||
## 何时使用本指南
|
||||
|
||||
- 您已安装 BMad v4（`.bmad-method` 文件夹）
|
||||
- 您希望迁移到新的 v6 架构
|
||||
- 您有需要保留的现有规划产物
|
||||
- 你已安装 BMad v4（目录名通常是 `.bmad-method`）
|
||||
- 你准备迁移到 v6 的统一目录结构
|
||||
- 你有要保留的规划产物或进行中的开发工作
|
||||
|
||||
:::note[前置条件]
|
||||
- Node.js 20+
|
||||
- 现有的 BMad v4 安装
|
||||
- 现有 BMad v4 安装
|
||||
:::
|
||||
|
||||
::::caution[先备份再迁移]
|
||||
如果当前仓库里仍有未提交的重要变更，先完成提交或备份，再执行升级。
|
||||
::::
|
||||
|
||||
## 步骤
|
||||
|
||||
### 1. 运行安装程序
|
||||
|
||||
按照[安装程序说明](./install-bmad.md)操作。
|
||||
|
||||
### 2. 处理旧版安装
|
||||
### 2. 处理旧版安装目录
|
||||
|
||||
当检测到 v4 时，您可以：
|
||||
当检测到 v4 时，你有两种处理方式：
|
||||
|
||||
- 允许安装程序备份并删除 `.bmad-method`
|
||||
- 退出并手动处理清理
|
||||
- 允许安装程序自动备份并删除 `.bmad-method`
|
||||
- 先退出安装流程，再手动清理旧目录
|
||||
|
||||
如果您将 bmad method 文件夹命名为其他名称 - 您需要手动删除该文件夹。
|
||||
如果你把 BMad Method 目录改成了其他名字，需要你自己手动定位并删除。
|
||||
|
||||
### 3. 清理 IDE 命令
|
||||
### 3. 清理 IDE 命令与技能目录
|
||||
|
||||
手动删除旧版 v4 IDE 命令 - 例如如果您使用 claude，查找任何以 bmad 开头的嵌套文件夹并删除它们：
|
||||
手动删除旧版 v4 IDE 命令/技能目录。以 Claude Code 为例，请在旧目录中删除以 `bmad` 开头的嵌套目录：
|
||||
|
||||
- `.claude/commands/BMad/agents`
|
||||
- `.claude/commands/BMad/tasks`
|
||||
- `.claude/commands/`
|
||||
|
||||
v6 新技能会安装到：
|
||||
|
||||
- `.claude/skills/`
|
||||
|
||||
### 4. 迁移规划产物
|
||||
|
||||
**如果您有规划文档（Brief/PRD/UX/Architecture）：**
|
||||
**如果你有规划文档（Brief/PRD/UX/Architecture）：**
|
||||
|
||||
将它们移动到 `_bmad-output/planning-artifacts/` 并使用描述性名称：
|
||||
把它们移动到 `_bmad-output/planning-artifacts/`，并使用可读的文件名：
|
||||
|
||||
- 在文件名中包含 `PRD` 用于 PRD 文档
|
||||
- 相应地包含 `brief`、`architecture` 或 `ux-design`
|
||||
- 分片文档可以放在命名的子文件夹中
|
||||
- PRD 文档文件名包含 `PRD`
|
||||
- 其他文档按类型包含 `brief`、`architecture` 或 `ux-design`
|
||||
- 分片文档可放在命名清晰的子目录中
|
||||
|
||||
**如果您正在进行规划：** 考虑使用 v6 工作流重新开始。将现有文档作为输入——新的渐进式发现工作流配合网络搜索和 IDE 计划模式会产生更好的结果。
|
||||
**如果你仍在规划中：** 建议直接用 v6 工作流重启规划，把现有文档作为输入；新版渐进式发现流程配合 Web 搜索和 IDE 计划模式通常会得到更稳妥的结果。
|
||||
|
||||
### 5. 迁移进行中的开发
|
||||
### 5. 迁移进行中的开发工作
|
||||
|
||||
如果您已创建或实现了故事：
|
||||
如果你已经创建或实现了部分用户故事（story）：
|
||||
|
||||
1. 完成 v6 安装
|
||||
2. 将 `epics.md` 或 `epics/epic*.md` 放入 `_bmad-output/planning-artifacts/`
|
||||
3. 运行 Scrum Master 的 `sprint-planning` 工作流
|
||||
3. 运行 Scrum Master 的 `bmad-sprint-planning` 工作流
|
||||
4. 告诉 SM 哪些史诗/故事已经完成
|
||||
|
||||
## 您将获得
|
||||
## 你将获得
|
||||
|
||||
**v6 统一结构：**
|
||||
|
||||
```text
|
||||
your-project/
|
||||
├── _bmad/ # 单一安装文件夹
|
||||
│ ├── _config/ # 您的自定义配置
|
||||
├── _bmad/ # 单一安装目录
|
||||
│ ├── _config/ # 你的自定义配置
|
||||
│ │ └── agents/ # 智能体自定义文件
|
||||
│ ├── core/ # 通用核心框架
|
||||
│ ├── bmm/ # BMad Method 模块
|
||||
│ ├── bmb/ # BMad Builder
|
||||
│ └── cis/ # Creative Intelligence Suite
|
||||
└── _bmad-output/ # 输出文件夹（v4 中为 doc 文件夹）
|
||||
└── _bmad-output/ # 输出目录（v4 时代常见为 doc 目录）
|
||||
```
|
||||
|
||||
## 模块迁移
|
||||
|
|
@ -87,34 +94,18 @@ your-project/
|
|||
| `.bmad-infrastructure-devops` | 已弃用 — 新的 DevOps 智能体即将推出 |
|
||||
| `.bmad-creative-writing` | 未适配 — 新的 v6 模块即将推出 |
|
||||
|
||||
## 主要变更
|
||||
## 关键差异（旧名/新名）
|
||||
|
||||
| 概念 | v4 | v6 |
|
||||
| ------------ | --------------------------------------- | ------------------------------------ |
|
||||
| **核心** | `_bmad-core` 实际上是 BMad Method | `_bmad/core/` 是通用框架 |
|
||||
| **方法** | `_bmad-method` | `_bmad/bmm/` |
|
||||
| **配置** | 直接修改文件 | 每个模块使用 `config.yaml` |
|
||||
| **文档** | 需要设置分片或非分片 | 完全灵活，自动扫描 |
|
||||
| 概念 | v4（旧） | v6（新） | 迁移提示 |
|
||||
| ------------ | --------------------------------------- | ------------------------------------ | ------------------------------------ |
|
||||
| **核心框架** | `_bmad-core` 实际上承载的是 BMad Method | `_bmad/core/` 变成通用框架层 | 迁移时不要再把 `_bmad/core/` 当成 Method 本体 |
|
||||
| **方法模块** | `_bmad-method` | `_bmad/bmm/` | 旧脚本、路径引用需同步更新到 `bmm` |
|
||||
| **配置方式** | 直接改模块文件 | 每个模块通过 `config.yaml` 管理 | 优先改配置，不要直接改生成文件 |
|
||||
| **文档读取** | 需要手动区分分片/非分片 | 自动扫描完整文档与分片入口 | 只有在兼容性场景下才建议手动分片 |
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
## 后续建议
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **epic**：史诗。在敏捷开发中，指大型的工作项，可分解为多个用户故事。
|
||||
- **story**：故事。在敏捷开发中，指用户故事，描述用户需求的功能单元。
|
||||
- **Scrum Master**：Scrum 主管。敏捷开发 Scrum 框架中的角色，负责促进团队流程和移除障碍。
|
||||
- **sprint-planning**：冲刺规划。Scrum 框架中的会议，用于确定下一个冲刺期间要完成的工作。
|
||||
- **sharded**：分片。将大型文档拆分为多个较小的文件以便于管理和处理。
|
||||
- **PRD**：产品需求文档（Product Requirements Document）。描述产品功能、需求和特性的文档。
|
||||
- **Brief**：简报。概述项目目标、范围和关键信息的文档。
|
||||
- **UX**：用户体验（User Experience）。用户在使用产品或服务过程中的整体感受和交互体验。
|
||||
- **Architecture**：架构。系统的结构设计，包括组件、模块及其相互关系。
|
||||
- **BMGD**：BMad Game Development。BMad 游戏开发模块。
|
||||
- **DevOps**：开发运维（Development Operations）。结合开发和运维的实践，旨在缩短系统开发生命周期。
|
||||
- **BMad Method**：BMad 方法。BMad 框架的核心方法论模块。
|
||||
- **BMad Builder**：BMad 构建器。BMad 框架的构建工具。
|
||||
- **Creative Intelligence Suite**：创意智能套件。BMad 框架中的创意工具集合。
|
||||
- **IDE**：集成开发环境（Integrated Development Environment）。提供代码编辑、调试等功能的软件开发工具。
|
||||
- **progressive discovery**：渐进式发现。逐步深入探索和理解需求的过程。
|
||||
- **web search**：网络搜索。通过互联网检索信息的能力。
|
||||
- **plan mode**：计划模式。IDE 中的一种工作模式，用于规划和设计任务。
|
||||
- 升级完成后先运行 `bmad-help`，确认可用工作流与下一步建议
|
||||
- 如果是既有项目，补充或更新 `project-context.md`，减少后续实现偏差
|
||||
- 在继续开发前，先做一次关键链路验证（安装、命令触发、文档读取）
|
||||
- 继续阅读：[如何安装 BMad](./install-bmad.md)、[管理项目上下文](./project-context.md)
|
||||
|
|
|
|||
|
|
@ -1,55 +1,55 @@
|
|||
---
|
||||
title: 欢迎使用 BMad 方法
|
||||
description: 具备专业智能体、引导式工作流和智能规划的 AI 驱动开发框架
|
||||
description: 具备专业智能体、引导式工作流与智能规划的 AI 驱动开发框架
|
||||
---
|
||||
|
||||
BMad 方法（**B**reakthrough **M**ethod of **A**gile AI **D**riven Development，敏捷 AI 驱动开发的突破性方法）是 BMad 方法生态系统中的一个 AI 驱动开发框架模块，帮助您完成从构思和规划到智能体实现的整个软件开发过程。它提供专业的 AI 智能体、引导式工作流和智能规划，能够根据您项目的复杂度进行调整，无论是修复错误还是构建企业平台。
|
||||
BMad 方法（**B**uild **M**ore **A**rchitect **D**reams）是 BMad 方法生态中的 AI 驱动开发框架模块，覆盖从构思、规划到智能体实施的完整软件交付流程。它提供专业智能体、引导式工作流和可随项目复杂度调整的智能规划，无论是修复 bug 还是构建企业级平台都适用。
|
||||
|
||||
如果您熟悉使用 Claude、Cursor 或 GitHub Copilot 等 AI 编码助手，就可以开始使用了。
|
||||
如果你已经习惯使用 Claude、Cursor 或 GitHub Copilot 这类 AI 编码助手，现在就可以开始。
|
||||
|
||||
:::note[🚀 V6 已发布，我们才刚刚起步！]
|
||||
技能架构、BMad Builder v1、开发循环自动化以及更多功能正在开发中。**[查看路线图 →](/zh-cn/roadmap/)**
|
||||
:::
|
||||
|
||||
## 新手入门？从教程开始
|
||||
## 新手入门？先从教程开始
|
||||
|
||||
理解 BMad 的最快方式是亲自尝试。
|
||||
|
||||
- **[BMad 入门指南](./tutorials/getting-started.md)** — 安装并了解 BMad 的工作原理
|
||||
- **[工作流地图](./reference/workflow-map.md)** — BMM 阶段、工作流和上下文管理的可视化概览
|
||||
- **[BMad 入门教程](./tutorials/getting-started.md)** — 安装并理解 BMad 如何工作
|
||||
- **[工作流地图](./reference/workflow-map.md)** — BMM 阶段、工作流与上下文管理的全景视图
|
||||
|
||||
:::tip[只想直接上手？]
|
||||
安装 BMad 并运行 `bmad-help` — 它会根据您的项目和已安装的模块引导您完成所有操作。
|
||||
安装 BMad 后运行 `bmad-help`，它会根据你的项目状态和已安装模块给出下一步建议。
|
||||
:::
|
||||
|
||||
## 如何使用本文档
|
||||
## 如何使用这些文档
|
||||
|
||||
本文档根据您的目标分为四个部分：
|
||||
这些文档按你的目标分成四个部分：
|
||||
|
||||
| 部分 | 用途 |
|
||||
| ----------------- | ---------------------------------------------------------------------------------------------------------- |
|
||||
| **教程** | 以学习为导向。通过分步指南引导您构建内容。如果您是新手，请从这里开始。 |
|
||||
| **操作指南** | 以任务为导向。解决特定问题的实用指南。"如何自定义智能体？"等内容位于此处。 |
|
||||
| **说明** | 以理解为导向。深入探讨概念和架构。当您想知道*为什么*时阅读。 |
|
||||
| **参考** | 以信息为导向。智能体、工作流和配置的技术规范。 |
|
||||
| 部分 | 用途 |
|
||||
| --- | --- |
|
||||
| **教程** | 学习导向。通过分步引导带你做成一件事。第一次使用建议从这里开始。 |
|
||||
| **操作指南** | 任务导向。解决具体问题的实用文档，例如“如何自定义智能体”。 |
|
||||
| **说明** | 理解导向。深入讲解概念与架构，适合回答“为什么”。 |
|
||||
| **参考** | 信息导向。提供智能体、工作流和配置项的技术规格。 |
|
||||
|
||||
## 扩展和自定义
|
||||
## 扩展与自定义
|
||||
|
||||
想要使用自己的智能体、工作流或模块来扩展 BMad 吗？**[BMad Builder（英文）](https://bmad-builder-docs.bmad-method.org/)** 提供了创建自定义扩展的框架和工具，无论是为 BMad 添加新功能还是从头开始构建全新的模块。
|
||||
想用自己的智能体、工作流或模块扩展 BMad？**[BMad Builder（英文）](https://bmad-builder-docs.bmad-method.org/)** 提供了创建自定义扩展所需的框架与工具，无论是给 BMad 添加能力，还是从零构建新模块都可以。
|
||||
|
||||
## 您需要什么
|
||||
## 你需要准备什么
|
||||
|
||||
BMad 可与任何支持自定义系统提示词或项目上下文的 AI 编码助手配合使用。热门选项包括：
|
||||
BMad 可与任何支持自定义系统提示词或项目上下文的 AI 编码助手配合使用，常见选择包括：
|
||||
|
||||
- **[Claude Code](https://code.claude.com)** — Anthropic 的 CLI 工具（推荐）
|
||||
- **[Cursor](https://cursor.sh)** — AI 优先的代码编辑器
|
||||
- **[Codex CLI](https://github.com/openai/codex)** — OpenAI 的终端编码智能体
|
||||
|
||||
您应该熟悉版本控制、项目结构和敏捷工作流等基本软件开发概念。无需具备 BMad 风格智能体系统的先验经验——这正是本文档的作用。
|
||||
你需要了解一些基础软件工程概念，例如版本控制、项目结构和敏捷工作流。即使没有使用过 BMad 风格智能体系统，也可以从这些文档开始上手。
|
||||
|
||||
## 加入社区
|
||||
|
||||
获取帮助、分享您的构建内容，或为 BMad 做出贡献：
|
||||
获取帮助、分享成果，或参与贡献：
|
||||
|
||||
- **[Discord](https://discord.gg/gk8jAdXWmj)** — 与其他 BMad 用户聊天、提问、分享想法
|
||||
- **[GitHub](https://github.com/bmad-code-org/BMAD-METHOD)** — 源代码、问题和贡献
|
||||
|
|
@ -57,13 +57,4 @@ BMad 可与任何支持自定义系统提示词或项目上下文的 AI 编码
|
|||
|
||||
## 下一步
|
||||
|
||||
准备开始了吗？**[BMad 入门指南](./tutorials/getting-started.md)** 并构建您的第一个项目。
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **AI-driven**：AI 驱动。指由人工智能技术主导或驱动的系统或方法。
|
||||
- **workflow**：工作流。指一系列有序的任务或步骤，用于完成特定目标。
|
||||
- **prompt**：提示词。指输入给 AI 模型的指令或问题，用于引导其生成特定输出。
|
||||
- **context**：上下文。指在特定场景下理解信息所需的背景信息或环境。
|
||||
准备好开始了吗？**[从 BMad 入门教程开始](./tutorials/getting-started.md)**，构建你的第一个项目。
|
||||
|
|
|
|||
|
|
@ -1,41 +1,62 @@
|
|||
---
|
||||
title: "智能体"
|
||||
description: 默认 BMM 智能体及其菜单触发器和主要工作流
|
||||
description: 默认 BMM 智能体的 skill ID、触发器与主要 workflow 速查。
|
||||
sidebar:
|
||||
order: 2
|
||||
---
|
||||
|
||||
## 默认智能体
|
||||
本页列出 BMad Method 默认提供的 BMM（Agile 套件）智能体，包括它们的 skill ID、菜单触发器和主要 workflow。
|
||||
|
||||
本页列出了随 BMad Method 安装的默认 BMM（Agile 套件）智能体，以及它们的菜单触发器和主要工作流。
|
||||
## 默认智能体列表
|
||||
|
||||
## 注意事项
|
||||
| 智能体 | Skill ID | 触发器 | 主要 workflow |
|
||||
| --- | --- | --- | --- |
|
||||
| Analyst (Mary) | `bmad-analyst` | `BP`、`RS`、`CB`、`DP` | Brainstorm、Research、Create Brief、Document Project |
|
||||
| Product Manager (John) | `bmad-pm` | `CP`、`VP`、`EP`、`CE`、`IR`、`CC` | Create/Validate/Edit PRD、Create Epics and Stories、Implementation Readiness、Correct Course |
|
||||
| Architect (Winston) | `bmad-architect` | `CA`、`IR` | Create Architecture、Implementation Readiness |
|
||||
| Scrum Master (Bob) | `bmad-sm` | `SP`、`CS`、`ER`、`CC` | Sprint Planning、Create Story、Epic Retrospective、Correct Course |
|
||||
| Developer (Amelia) | `bmad-dev` | `DS`、`CR` | Dev Story、Code Review |
|
||||
| QA Engineer (Quinn) | `bmad-qa` | `QA` | Automate（为既有功能生成测试） |
|
||||
| Quick Flow Solo Dev (Barry) | `bmad-master` | `QD`、`CR` | Quick Dev、Code Review |
|
||||
| UX Designer (Sally) | `bmad-ux-designer` | `CU` | Create UX Design |
|
||||
| Technical Writer (Paige) | `bmad-tech-writer` | `DP`、`WD`、`US`、`MG`、`VD`、`EC` | Document Project、Write Document、Update Standards、Mermaid Generate、Validate Doc、Explain Concept |
|
||||
|
||||
- 触发器是显示在每个智能体菜单中的简短菜单代码（例如 `CP`）和模糊匹配。
|
||||
- 斜杠命令是单独生成的。斜杠命令列表及其定义位置请参阅[命令](./commands.md)。
|
||||
- QA（Quinn）是 BMM 中的轻量级测试自动化智能体。完整的测试架构师（TEA）位于其独立模块中。
|
||||
## 使用说明
|
||||
|
||||
| 智能体 | 触发 | 主要工作流 |
|
||||
| --------------------------- | --------------------------------- | --------------------------------------------------------------------------------------------------- |
|
||||
| Analyst (Mary) | `BP`, `RS`, `CB`, `DP` | 头脑风暴项目、研究、创建简报、文档化项目 |
|
||||
| Product Manager (John) | `CP`, `VP`, `EP`, `CE`, `IR`, `CC` | 创建/验证/编辑 PRD、创建史诗和用户故事、实施就绪、纠正方向 |
|
||||
| Architect (Winston) | `CA`, `IR` | 创建架构、实施就绪 |
|
||||
| Scrum Master (Bob) | `SP`, `CS`, `ER`, `CC` | 冲刺规划、创建用户故事、史诗回顾、纠正方向 |
|
||||
| Developer (Amelia) | `DS`, `CR` | 开发用户故事、代码评审 |
|
||||
| QA Engineer (Quinn) | `QA` | 自动化（为现有功能生成测试） |
|
||||
| Quick Flow Solo Dev (Barry) | `QD`, `CR` | 快速开发、代码评审 |
|
||||
| UX Designer (Sally) | `CU` | 创建 UX 设计 |
|
||||
| Technical Writer (Paige) | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | 文档化项目、撰写文档、更新标准、Mermaid 生成、验证文档、解释概念 |
|
||||
- `Skill ID` 是直接调用该智能体的名称（例如 `bmad-dev`）
|
||||
- 触发器是进入智能体会话后可使用的菜单短码
|
||||
- QA（Quinn）是 BMM 内置轻量测试角色；完整 TEA 能力位于独立模块
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
## 触发器类型
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **BMM**：BMad Method 中的默认智能体套件，涵盖敏捷开发流程中的各类角色。
|
||||
- **PRD**：产品需求文档（Product Requirements Document）。
|
||||
- **Epic**：史诗。大型功能或需求集合，可拆分为多个用户故事。
|
||||
- **Story**：用户故事。描述用户需求的简短陈述。
|
||||
- **Sprint**：冲刺。敏捷开发中的固定时间周期迭代。
|
||||
- **QA**：质量保证（Quality Assurance）。
|
||||
- **TEA**：测试架构师（Test Architect）。
|
||||
- **Mermaid**：一种用于生成图表和流程图的文本语法。
|
||||
### 工作流触发器（通常不需要额外参数）
|
||||
|
||||
多数触发器会直接启动结构化 workflow。你只需输入触发码，然后按流程提示提供信息。
|
||||
|
||||
示例：`CP`（Create PRD）、`DS`（Dev Story）、`CA`（Create Architecture）、`QD`（Quick Dev）
|
||||
|
||||
### 会话触发器（需要附带说明）
|
||||
|
||||
部分触发器进入自由对话模式，需要你在触发码后描述需求。
|
||||
|
||||
| 智能体 | 触发器 | 你需要提供的内容 |
|
||||
| --- | --- | --- |
|
||||
| Technical Writer (Paige) | `WD` | 要撰写的文档主题与目标 |
|
||||
| Technical Writer (Paige) | `US` | 要补充到标准中的偏好/规范 |
|
||||
| Technical Writer (Paige) | `MG` | 图示类型与图示内容描述 |
|
||||
| Technical Writer (Paige) | `VD` | 待验证文档与关注点 |
|
||||
| Technical Writer (Paige) | `EC` | 需要解释的概念名称 |
|
||||
|
||||
示例：
|
||||
|
||||
```text
|
||||
WD 写一份 Docker 部署指南
|
||||
MG 画一个认证流程的时序图
|
||||
EC 解释模块系统如何运作
|
||||
```
|
||||
|
||||
## 相关参考
|
||||
|
||||
- [技能（Skills）参考](./commands.md)
|
||||
- [工作流地图](./workflow-map.md)
|
||||
- [核心工具参考](./core-tools.md)
|
||||
|
|
|
|||
|
|
@ -1,166 +1,122 @@
|
|||
---
|
||||
title: "命令"
|
||||
description: BMad 斜杠命令参考——它们是什么、如何工作以及在哪里找到它们。
|
||||
title: "技能（Skills）"
|
||||
description: BMad 技能参考：它们是什么、如何生成以及如何调用。
|
||||
sidebar:
|
||||
order: 3
|
||||
---
|
||||
|
||||
斜杠命令是预构建的提示词，用于在 IDE 中加载智能体、运行工作流或执行任务。BMad 安装程序在安装时根据已安装的模块生成这些命令。如果您后续添加、删除或更改模块，请重新运行安装程序以保持命令同步（参见[故障排除](#troubleshooting)）。
|
||||
每次运行 `npx bmad-method install`，BMad 会基于你选择的模块生成一组 **skills**。你可以直接输入 skill 名称调用 workflow、任务、工具或智能体角色。
|
||||
|
||||
## 命令与智能体菜单触发器
|
||||
## Skills 与菜单触发器的区别
|
||||
|
||||
BMad 提供两种开始工作的方式，它们服务于不同的目的。
|
||||
|
||||
| 机制 | 调用方式 | 发生什么 |
|
||||
| 机制 | 调用方式 | 适用场景 |
|
||||
| --- | --- | --- |
|
||||
| **斜杠命令** | 在 IDE 中输入 `bmad-...` | 直接加载智能体、运行工作流或执行任务 |
|
||||
| **智能体菜单触发器** | 先加载智能体，然后输入简短代码（例如 `DS`） | 智能体解释代码并启动匹配的工作流，同时保持角色设定 |
|
||||
| **Skill** | 直接输入 skill 名（如 `bmad-help`） | 你已明确要运行哪个功能 |
|
||||
| **智能体菜单触发器** | 先加载智能体，再输入短触发码（如 `DS`） | 你在智能体会话内连续切换任务 |
|
||||
|
||||
智能体菜单触发器需要活动的智能体会话。当您知道要使用哪个工作流时，使用斜杠命令。当您已经与智能体一起工作并希望在不离开对话的情况下切换任务时，使用触发器。
|
||||
菜单触发器依赖“已激活的智能体会话”；skill 可独立运行。
|
||||
|
||||
## 命令如何生成
|
||||
## Skills 如何生成
|
||||
|
||||
当您运行 `npx bmad-method install` 时，安装程序会读取每个选定模块的清单，并为每个智能体、工作流、任务和工具编写一个命令文件。每个文件都是一个简短的 Markdown 提示词，指示 AI 加载相应的源文件并遵循其指令。
|
||||
安装程序会读取已选模块，为每个 agent / workflow / task / tool 生成一个 skill 目录，目录中包含 `SKILL.md` 入口文件。
|
||||
|
||||
安装程序为每种命令类型使用模板：
|
||||
|
||||
| 命令类型 | 生成的文件的作用 |
|
||||
| Skill 类型 | 生成行为 |
|
||||
| --- | --- |
|
||||
| **智能体启动器** | 加载智能体角色文件，激活其菜单，并保持角色设定 |
|
||||
| **工作流命令** | 加载工作流引擎（`workflow.xml`）并传递工作流配置 |
|
||||
| **任务命令** | 加载独立任务文件并遵循其指令 |
|
||||
| **工具命令** | 加载独立工具文件并遵循其指令 |
|
||||
| Agent launcher | 加载角色设定并激活菜单 |
|
||||
| Workflow skill | 加载 workflow 配置并执行步骤 |
|
||||
| Task skill | 执行独立任务 |
|
||||
| Tool skill | 执行独立工具 |
|
||||
|
||||
:::note[重新运行安装程序]
|
||||
如果您添加或删除模块，请再次运行安装程序。它会重新生成所有命令文件以匹配您当前的模块选择。
|
||||
:::note[模块变更后要重装]
|
||||
当你新增、删除或切换模块后，请重新运行安装程序，避免 skill 列表与模块状态不一致。
|
||||
:::
|
||||
|
||||
## 命令文件的位置
|
||||
## Skill 文件位置
|
||||
|
||||
安装程序将命令文件写入项目内 IDE 特定的目录中。确切路径取决于您在安装期间选择的 IDE。
|
||||
|
||||
| IDE / CLI | 命令目录 |
|
||||
| IDE / CLI | Skills 目录 |
|
||||
| --- | --- |
|
||||
| Claude Code | `.claude/commands/` |
|
||||
| Cursor | `.cursor/commands/` |
|
||||
| Windsurf | `.windsurf/workflows/` |
|
||||
| 其他 IDE | 请参阅安装程序输出中的目标路径 |
|
||||
| Claude Code | `.claude/skills/` |
|
||||
| Cursor | `.cursor/skills/` |
|
||||
| Windsurf | `.windsurf/skills/` |
|
||||
| 其他 IDE | 以安装器输出路径为准 |
|
||||
|
||||
所有 IDE 都在其命令目录中接收一组扁平的命令文件。例如，Claude Code 安装看起来像：
|
||||
示例（Claude Code）：
|
||||
|
||||
```text
|
||||
.claude/commands/
|
||||
├── bmad-agent-bmm-dev.md
|
||||
├── bmad-agent-bmm-pm.md
|
||||
├── bmad-bmm-create-prd.md
|
||||
├── bmad-editorial-review-prose.md
|
||||
├── bmad-help.md
|
||||
.claude/skills/
|
||||
├── bmad-help/
|
||||
│ └── SKILL.md
|
||||
├── bmad-create-prd/
|
||||
│ └── SKILL.md
|
||||
├── bmad-dev/
|
||||
│ └── SKILL.md
|
||||
└── ...
|
||||
```
|
||||
|
||||
文件名决定了 IDE 中的技能名称。例如，文件 `bmad-agent-bmm-dev.md` 注册技能 `bmad-agent-bmm-dev`。
|
||||
skill 目录名就是调用名，例如 `bmad-dev/` 对应 skill `bmad-dev`。
|
||||
|
||||
## 如何发现您的命令
|
||||
## 如何发现可用 skills
|
||||
|
||||
在 IDE 中输入 `/bmad` 并使用自动完成功能浏览可用命令。
|
||||
- 在 IDE 中直接输入 `bmad-` 前缀查看补全候选
|
||||
- 运行 `bmad-help` 获取基于当前项目状态的下一步建议
|
||||
- 打开 skills 目录查看完整清单（这是最权威来源）
|
||||
|
||||
运行 `bmad-help` 获取关于下一步的上下文感知指导。
|
||||
|
||||
:::tip[快速发现]
|
||||
项目中生成的命令文件夹是权威列表。在文件资源管理器中打开它们以查看每个命令及其描述。
|
||||
:::tip[快速定位]
|
||||
不确定该跑哪个 workflow 时，先执行 `bmad-help`，通常比人工翻文档更快。
|
||||
:::
|
||||
|
||||
## 命令类别
|
||||
## Skill 分类与示例
|
||||
|
||||
### 智能体命令
|
||||
### 智能体技能（Agent Skills）
|
||||
|
||||
智能体命令加载具有定义角色、沟通风格和工作流菜单的专业化 AI 角色。加载后，智能体保持角色设定并响应菜单触发器。
|
||||
加载一个角色化智能体，并保持其 persona 与菜单上下文。
|
||||
|
||||
| 示例命令 | 智能体 | 角色 |
|
||||
| 示例 skill | 角色 | 用途 |
|
||||
| --- | --- | --- |
|
||||
| `bmad-agent-bmm-dev` | Amelia（开发者） | 严格按照规范实现故事 |
|
||||
| `bmad-agent-bmm-pm` | John（产品经理） | 创建和验证 PRD |
|
||||
| `bmad-agent-bmm-architect` | Winston（架构师） | 设计系统架构 |
|
||||
| `bmad-agent-bmm-sm` | Bob（Scrum Master） | 管理冲刺和故事 |
|
||||
| `bmad-dev` | Developer（Amelia） | 按规范实现 story |
|
||||
| `bmad-pm` | Product Manager（John） | 创建与校验 PRD |
|
||||
| `bmad-architect` | Architect（Winston） | 架构设计与约束定义 |
|
||||
| `bmad-sm` | Scrum Master（Bob） | 冲刺与 story 流程管理 |
|
||||
|
||||
参见[智能体](./agents.md)获取默认智能体及其触发器的完整列表。
|
||||
完整列表见 [智能体参考](./agents.md)。
|
||||
|
||||
### 工作流命令
|
||||
### Workflow Skills
|
||||
|
||||
工作流命令运行结构化的多步骤过程，而无需先加载智能体角色。它们加载工作流引擎并传递特定的工作流配置。
|
||||
无需先加载 agent，直接运行结构化流程。
|
||||
|
||||
| 示例命令 | 目的 |
|
||||
| 示例 skill | 用途 |
|
||||
| --- | --- |
|
||||
| `bmad-bmm-create-prd` | 创建产品需求文档 |
|
||||
| `bmad-bmm-create-architecture` | 设计系统架构 |
|
||||
| `bmad-bmm-dev-story` | 实现故事 |
|
||||
| `bmad-bmm-code-review` | 运行代码审查 |
|
||||
| `bmad-bmm-quick-dev` | 统一快速流程 — 澄清意图、规划、实现、审查、呈现 |
|
||||
| `bmad-create-prd` | 创建 PRD |
|
||||
| `bmad-create-architecture` | 创建架构方案 |
|
||||
| `bmad-create-epics-and-stories` | 拆分 epics/stories |
|
||||
| `bmad-dev-story` | 实现指定 story |
|
||||
| `bmad-code-review` | 代码评审 |
|
||||
| `bmad-quick-dev` | 快速流程（澄清→规划→实现→审查→呈现） |
|
||||
|
||||
参见[工作流地图](./workflow-map.md)获取按阶段组织的完整工作流参考。
|
||||
按阶段查看见 [工作流地图](./workflow-map.md)。
|
||||
|
||||
### 任务和工具命令
|
||||
### Task / Tool Skills
|
||||
|
||||
任务和工具是独立的操作，不需要智能体或工作流上下文。
|
||||
独立任务，不依赖特定智能体上下文。
|
||||
|
||||
#### BMad-Help：您的智能向导
|
||||
**`bmad-help`** 是最常用入口：它会读取项目状态并给出“下一步建议 + 对应 skill”。
|
||||
|
||||
**`bmad-help`** 是您发现下一步操作的主要界面。它不仅仅是一个查找工具——它是一个智能助手，可以：
|
||||
更多核心任务和工具见 [核心工具参考](./core-tools.md)。
|
||||
|
||||
- **检查您的项目**以查看已经完成的工作
|
||||
- **理解自然语言查询**——用简单的英语提问
|
||||
- **根据已安装的模块而变化**——根据您拥有的内容显示选项
|
||||
- **在工作流后自动调用**——每个工作流都以清晰的下一步结束
|
||||
- **推荐第一个必需任务**——无需猜测从哪里开始
|
||||
## 命名规则
|
||||
|
||||
**示例：**
|
||||
所有技能统一以 `bmad-` 开头，后接语义化名称（如 `bmad-dev`、`bmad-create-prd`、`bmad-help`）。
|
||||
|
||||
```
|
||||
bmad-help
|
||||
bmad-help 我有一个 SaaS 想法并且知道所有功能。我应该从哪里开始？
|
||||
bmad-help 我在 UX 设计方面有哪些选择？
|
||||
bmad-help 我在 PRD 工作流上卡住了
|
||||
```
|
||||
## 故障排查
|
||||
|
||||
#### 其他任务和工具
|
||||
**安装后看不到 skills：** 某些 IDE 需要手动启用 skills，或重启 IDE 才会刷新。
|
||||
|
||||
| 示例命令 | 目的 |
|
||||
| --- | --- |
|
||||
| `bmad-shard-doc` | 将大型 Markdown 文件拆分为较小的部分 |
|
||||
| `bmad-index-docs` | 索引项目文档 |
|
||||
| `bmad-editorial-review-prose` | 审查文档散文质量 |
|
||||
**缺少预期 skill：** 可能模块未安装或安装时未勾选。重新运行安装程序并确认模块选择。
|
||||
|
||||
## 命名约定
|
||||
**已移除模块的 skills 仍存在：** 安装器不会自动清理历史目录。手动删除旧 skill 目录后再重装可获得干净结果。
|
||||
|
||||
命令名称遵循可预测的模式。
|
||||
## 相关参考
|
||||
|
||||
| 模式 | 含义 | 示例 |
|
||||
| --- | --- | --- |
|
||||
| `bmad-agent-<module>-<name>` | 智能体启动器 | `bmad-agent-bmm-dev` |
|
||||
| `bmad-<module>-<workflow>` | 工作流命令 | `bmad-bmm-create-prd` |
|
||||
| `bmad-<name>` | 核心任务或工具 | `bmad-help` |
|
||||
|
||||
模块代码：`bmm`（敏捷套件）、`bmb`（构建器）、`tea`（测试架构师）、`cis`（创意智能）、`gds`（游戏开发工作室）。参见[模块](./modules.md)获取描述。
|
||||
|
||||
## 故障排除
|
||||
|
||||
**安装后命令未出现。** 重启您的 IDE 或重新加载窗口。某些 IDE 会缓存命令列表，需要刷新才能获取新文件。
|
||||
|
||||
**预期的命令缺失。** 安装程序仅为您选择的模块生成命令。再次运行 `npx bmad-method install` 并验证您的模块选择。检查命令文件是否存在于预期目录中。
|
||||
|
||||
**已删除模块的命令仍然出现。** 安装程序不会自动删除旧的命令文件。从 IDE 的命令目录中删除过时的文件，或删除整个命令目录并重新运行安装程序以获取一组干净的命令。
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **slash command**：斜杠命令。以 `/` 开头的命令，用于在 IDE 中快速执行特定操作。
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **workflow**：工作流。一系列结构化的步骤，用于完成特定任务或流程。
|
||||
- **IDE**：集成开发环境。用于软件开发的综合应用程序，提供代码编辑、调试、构建等功能。
|
||||
- **persona**：角色设定。为智能体定义的特定角色、性格和行为方式。
|
||||
- **trigger**：触发器。用于启动特定操作或流程的机制。
|
||||
- **manifest**：清单。描述模块或组件的元数据文件。
|
||||
- **installer**：安装程序。用于安装和配置软件的工具。
|
||||
- **PRD**：产品需求文档。描述产品功能、需求和规范的文档。
|
||||
- **SaaS**：软件即服务。通过互联网提供软件服务的模式。
|
||||
- **UX**：用户体验。用户在使用产品或服务过程中的整体感受和交互体验。
|
||||
- [智能体参考](./agents.md)
|
||||
- [核心工具参考](./core-tools.md)
|
||||
- [模块参考](./modules.md)
|
||||
|
|
|
|||
|
|
@ -1,293 +1,233 @@
|
|||
---
|
||||
title: "核心工具"
|
||||
description: 每个 BMad 安装都自带的内置任务和工作流参考。
|
||||
description: 每个 BMad 安装默认可用的任务与 workflow 参考。
|
||||
sidebar:
|
||||
order: 2
|
||||
---
|
||||
|
||||
每个 BMad 安装都包含一组核心技能，可以配合你正在做的任何事情使用——跨项目、跨模块、跨阶段的独立任务和工作流。无论安装了哪些可选模块，这些工具始终可用。
|
||||
核心工具是跨模块可复用的一组通用能力：不依赖特定业务项目，也不要求先进入某个智能体角色。只要安装了 BMad，你就可以直接调用它们。
|
||||
|
||||
:::tip[快速上手]
|
||||
在 IDE 中输入技能名称（如 `bmad-help`）即可运行任意核心工具，无需启动智能体会话。
|
||||
:::tip[快速入口]
|
||||
在 IDE 中直接输入工具 skill 名（例如 `bmad-help`）即可调用，无需先加载智能体。
|
||||
:::
|
||||
|
||||
## 概览
|
||||
|
||||
| 工具 | 类型 | 用途 |
|
||||
| 工具 | 类型 | 主要用途 |
|
||||
| --- | --- | --- |
|
||||
| [`bmad-help`](#bmad-help) | 任务 | 根据上下文给出下一步建议 |
|
||||
| [`bmad-brainstorming`](#bmad-brainstorming) | 工作流 | 引导交互式头脑风暴 |
|
||||
| [`bmad-party-mode`](#bmad-party-mode) | 工作流 | 编排多智能体群组讨论 |
|
||||
| [`bmad-distillator`](#bmad-distillator) | 任务 | 无损的 LLM 优化文档压缩 |
|
||||
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | 任务 | 通过迭代精炼方法提升 LLM 输出质量 |
|
||||
| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | 任务 | 挑刺式审查——找出遗漏和问题 |
|
||||
| [`bmad-review-edge-case-hunter`](#bmad-review-edge-case-hunter) | 任务 | 穷举分支路径分析，找出未处理的边界情况 |
|
||||
| [`bmad-editorial-review-prose`](#bmad-editorial-review-prose) | 任务 | 临床式文案编辑，聚焦表达清晰度 |
|
||||
| [`bmad-editorial-review-structure`](#bmad-editorial-review-structure) | 任务 | 结构编辑——裁剪、合并与重组 |
|
||||
| [`bmad-shard-doc`](#bmad-shard-doc) | 任务 | 将大型 Markdown 文件拆分为有序章节 |
|
||||
| [`bmad-index-docs`](#bmad-index-docs) | 任务 | 生成或更新文件夹的文档索引 |
|
||||
| [`bmad-help`](#bmad-help) | Task | 基于项目上下文推荐下一步 |
|
||||
| [`bmad-brainstorming`](#bmad-brainstorming) | Workflow | 引导式头脑风暴与想法扩展 |
|
||||
| [`bmad-party-mode`](#bmad-party-mode) | Workflow | 多智能体协作讨论 |
|
||||
| [`bmad-distillator`](#bmad-distillator) | Task | 无损压缩文档，提升 LLM 消费效率 |
|
||||
| [`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
|
||||
|
||||
**你的智能向导，告诉你下一步该做什么。** — 检查项目状态，识别已完成的内容，推荐下一个必需或可选步骤。
|
||||
**定位：** 你的默认导航入口，告诉你“下一步该做什么”。
|
||||
|
||||
**适用场景：**
|
||||
- 刚完成一个 workflow，不确定如何衔接
|
||||
- 新接触项目，需要先看当前进度
|
||||
- 变更模块后，想知道可用能力和推荐顺序
|
||||
|
||||
- 完成了一个工作流，想知道接下来做什么
|
||||
- 刚接触 BMad，需要快速了解全貌
|
||||
- 卡住了，想要根据当前上下文获取建议
|
||||
- 安装了新模块，想看看有哪些可用功能
|
||||
**工作机制：**
|
||||
1. 扫描已存在产物（PRD、architecture、stories 等）
|
||||
2. 检测已安装模块及其可用 workflow
|
||||
3. 按优先级输出“必需步骤 + 可选步骤”
|
||||
|
||||
**工作原理：**
|
||||
|
||||
1. 扫描项目中已有的产出物（PRD、架构文档、用户故事等）
|
||||
2. 检测已安装的模块及其可用工作流
|
||||
3. 按优先级推荐下一步——必需步骤优先，可选步骤其次
|
||||
4. 每条推荐都附带技能命令和简要说明
|
||||
|
||||
**输入：** 可选的自然语言查询（如 `bmad-help I have a SaaS idea, where do I start?`）
|
||||
|
||||
**输出：** 按优先级排列的下一步推荐列表，附带技能命令
|
||||
**输入：** 可选自然语言问题（如 `bmad-help 我该先做 PRD 还是 architecture？`）
|
||||
**输出：** 带 skill 名称的下一步建议列表
|
||||
|
||||
## bmad-brainstorming
|
||||
|
||||
**通过交互式创意技法激发多样想法。** — 引导式头脑风暴会话，从技法库中加载经过验证的创意方法，引导你在整理之前先产出 100+ 个想法。
|
||||
**定位：** 用结构化创意技法快速扩展想法池。
|
||||
|
||||
**适用场景：**
|
||||
- 启动新主题，想先打开问题空间
|
||||
- 团队卡在同一思路，需要外部技法打破惯性
|
||||
- 需要把“模糊方向”变成可讨论候选方案
|
||||
|
||||
- 启动新项目，需要探索问题空间
|
||||
- 想法枯竭，需要结构化的创意引导
|
||||
- 想使用成熟的创意框架（SCAMPER、反向头脑风暴等）
|
||||
**工作机制：**
|
||||
1. 建立主题会话
|
||||
2. 从方法库选择创意技法
|
||||
3. 逐轮引导产出并记录想法
|
||||
4. 生成可追溯的会话文档
|
||||
|
||||
**工作原理：**
|
||||
|
||||
1. 围绕你的主题建立头脑风暴会话
|
||||
2. 从方法库中加载创意技法
|
||||
3. 逐个技法引导你产出想法
|
||||
4. 应用反偏差协议——每产出 10 个想法切换一次创意领域，防止想法扎堆
|
||||
5. 生成一份只追加的会话文档，所有想法按技法分类整理
|
||||
|
||||
**输入：** 头脑风暴主题或问题陈述，可选上下文文件
|
||||
|
||||
**输出：** `brainstorming-session-{date}.md`，包含所有产出的想法
|
||||
|
||||
:::note[数量目标]
|
||||
真正的好点子往往出现在第 50-100 个想法之间。工作流鼓励在整理之前先产出 100+ 个想法。
|
||||
:::
|
||||
**输入：** 主题或问题陈述（可附上下文文件）
|
||||
**输出：** `brainstorming-session-{date}.md`
|
||||
|
||||
## bmad-party-mode
|
||||
|
||||
**编排多智能体群组讨论。** — 加载所有已安装的 BMad 智能体，引导一场自然对话，每个智能体从各自的专业领域和角色特征出发发言。
|
||||
**定位：** 让多个智能体围绕同一议题协作讨论。
|
||||
|
||||
**适用场景：**
|
||||
- 决策涉及产品、架构、实现、质量等多视角
|
||||
- 希望不同角色显式冲突并暴露假设差异
|
||||
- 需要在短时间内收集多方案观点
|
||||
|
||||
- 需要多个专家视角来评估一个决策
|
||||
- 希望智能体互相质疑彼此的假设
|
||||
- 正在探索一个横跨多个领域的复杂话题
|
||||
**工作机制：**
|
||||
1. 读取已安装智能体清单
|
||||
2. 选取最相关的 2-3 个角色先发言
|
||||
3. 轮换角色、持续交叉讨论
|
||||
4. 使用 `goodbye` / `end party` / `quit` 结束
|
||||
|
||||
**工作原理：**
|
||||
|
||||
1. 加载智能体清单及所有已安装的智能体角色
|
||||
2. 分析你的话题，选出 2-3 个最相关的智能体
|
||||
3. 智能体轮流发言，自然地交叉讨论甚至争论
|
||||
4. 轮换参与的智能体，确保随时间推移覆盖多样视角
|
||||
5. 输入 `goodbye`、`end party` 或 `quit` 退出
|
||||
|
||||
**输入：** 讨论话题或问题，以及你希望参与的角色（可选）
|
||||
|
||||
**输出：** 实时多智能体对话，各智能体保持各自角色特征
|
||||
**输入：** 讨论主题（可指定希望参与的角色）
|
||||
**输出：** 多智能体实时对话过程
|
||||
|
||||
## bmad-distillator
|
||||
|
||||
**无损的 LLM 优化文档压缩。** — 生成信息密度高、token 高效的精馏文档，保留全部信息供下游 LLM 消费。可通过往返重构验证无损性。
|
||||
**定位：** 在不丢失信息前提下压缩文档，降低 token 成本。
|
||||
|
||||
**适用场景：**
|
||||
- 源文档超过上下文窗口
|
||||
- 需要把研究/规格材料转成高密度引用版本
|
||||
- 想验证压缩结果是否可逆
|
||||
|
||||
- 文档太大，超出 LLM 的上下文窗口
|
||||
- 需要研究资料、规格或规划产出物的 token 高效版本
|
||||
- 想验证压缩过程中没有丢失信息
|
||||
- 智能体需要频繁引用和检索其中的信息
|
||||
|
||||
**工作原理：**
|
||||
|
||||
1. **分析** — 读取源文档，识别信息密度和结构
|
||||
2. **压缩** — 将散文转为密集的要点格式，剥离装饰性排版
|
||||
3. **校验** — 检查完整性，确保原始信息全部保留
|
||||
4. **验证**（可选）— 往返重构测试，证明压缩无损
|
||||
**工作机制：**
|
||||
1. 分析源文档结构与信息密度
|
||||
2. 压缩为高密度结构化表达
|
||||
3. 校验信息完整性
|
||||
4. 可选执行往返重构验证（round-trip）
|
||||
|
||||
**输入：**
|
||||
- `source_documents`（必填）
|
||||
- `downstream_consumer`（可选）
|
||||
- `token_budget`（可选）
|
||||
- `--validate`（可选标志）
|
||||
|
||||
- `source_documents`（必填）— 文件路径、文件夹路径或 glob 模式
|
||||
- `downstream_consumer`（可选）— 消费方是什么（如 "PRD creation"）
|
||||
- `token_budget`（可选）— 大致目标大小
|
||||
- `--validate`（标志）— 运行往返重构测试
|
||||
|
||||
**输出：** 精馏 Markdown 文件，附带压缩比报告（如 "3.2:1"）
|
||||
**输出：** 精馏文档 + 压缩比报告
|
||||
|
||||
## bmad-advanced-elicitation
|
||||
|
||||
**通过迭代精炼方法提升 LLM 输出质量。** — 从启发技法库中选取合适的方法，通过多轮迭代系统性地改进内容。
|
||||
**定位：** 对已有 LLM 输出做第二轮深挖与改写强化。
|
||||
|
||||
**适用场景：**
|
||||
- 结果“看起来对”，但深度不够
|
||||
- 想从多个思维框架交叉审视同一内容
|
||||
- 在交付前提升论证质量与完整性
|
||||
|
||||
- LLM 输出感觉浅薄或千篇一律
|
||||
- 想从多个分析角度深挖一个话题
|
||||
- 正在打磨关键文档，需要更深层的思考
|
||||
**工作机制：**
|
||||
1. 加载启发技法库
|
||||
2. 选择匹配内容的候选技法
|
||||
3. 交互式选择并应用技法
|
||||
4. 多轮迭代直到你确认收敛
|
||||
|
||||
**工作原理：**
|
||||
|
||||
1. 加载包含 5+ 种启发技法的方法注册表
|
||||
2. 根据内容类型和复杂度选出 5 个最匹配的方法
|
||||
3. 呈现交互菜单——选一个方法、重新洗牌或列出全部
|
||||
4. 将选中的方法应用到内容上进行增强
|
||||
5. 重新呈现选项，反复迭代改进，直到你选择"继续"
|
||||
|
||||
**输入：** 待增强的内容段落
|
||||
|
||||
**输出：** 应用改进后的增强版内容
|
||||
**输入：** 待增强内容片段
|
||||
**输出：** 增强后的内容版本
|
||||
|
||||
## bmad-review-adversarial-general
|
||||
|
||||
**预设问题存在，然后去找出来的挑刺式审查。** — 以怀疑、挑剔的审查者视角，对粗糙工作零容忍。重点找遗漏，而不只是找错误。
|
||||
**定位：** 假设问题存在，主动寻找遗漏与风险。
|
||||
|
||||
**适用场景：**
|
||||
- 文档/规格/实现即将交付前
|
||||
- 想补足“乐观审查”容易漏掉的问题
|
||||
- 需要对关键变更做压力测试
|
||||
|
||||
- 在交付物定稿前需要质量保证
|
||||
- 想对规格、用户故事或文档进行压力测试
|
||||
- 想找到乐观审查容易忽略的覆盖盲区
|
||||
**工作机制：**
|
||||
1. 以怀疑视角检查内容
|
||||
2. 从完整性、正确性、质量三个维度找问题
|
||||
3. 强制关注“缺失内容”，而非仅纠错
|
||||
|
||||
**工作原理：**
|
||||
|
||||
1. 以挑剔、批判的视角阅读内容
|
||||
2. 从完整性、正确性和质量三个维度识别问题
|
||||
3. 专门寻找遗漏的内容——不只是已有内容中的错误
|
||||
4. 至少找出 10 个问题，否则进行更深层分析
|
||||
|
||||
**输入：**
|
||||
|
||||
- `content`（必填）— diff、规格、用户故事、文档或任意产出物
|
||||
- `also_consider`（可选）— 需要额外关注的领域
|
||||
|
||||
**输出：** 包含 10+ 条发现及描述的 Markdown 列表
|
||||
**输入：** `content`（必填），`also_consider`（可选）
|
||||
**输出：** 结构化问题清单
|
||||
|
||||
## bmad-review-edge-case-hunter
|
||||
|
||||
**遍历每条分支路径和边界条件，只报告未处理的情况。** — 纯路径追踪方法论，机械地推导边界类别。与对抗式审查正交——靠方法驱动，而非靠态度驱动。
|
||||
**定位：** 穷举分支路径与边界条件，只报告未覆盖情况。
|
||||
|
||||
**适用场景：**
|
||||
- 审查核心逻辑的边界健壮性
|
||||
- 对 diff 做路径级覆盖检查
|
||||
- 与 adversarial review 形成互补
|
||||
|
||||
- 想对代码或逻辑做穷举式边界覆盖
|
||||
- 需要与对抗式审查互补（不同方法论，不同发现）
|
||||
- 正在审查 diff 或函数的边界条件
|
||||
**工作机制：**
|
||||
1. 枚举所有分支路径
|
||||
2. 推导边界类别（missing default、off-by-one、竞态等）
|
||||
3. 检查每条路径是否已有防护
|
||||
4. 仅输出未处理路径
|
||||
|
||||
**工作原理：**
|
||||
|
||||
1. 枚举内容中所有分支路径
|
||||
2. 机械推导边界类别：缺失的 else/default、未防护的输入、差一错误、算术溢出、隐式类型转换、竞态条件、超时间隙
|
||||
3. 逐条路径检查现有防护
|
||||
4. 只报告未处理的路径——已处理的静默丢弃
|
||||
|
||||
**输入：**
|
||||
|
||||
- `content`（必填）— diff、完整文件或函数
|
||||
- `also_consider`（可选）— 需要额外关注的领域
|
||||
|
||||
**输出：** JSON 数组，每条发现包含 `location`、`trigger_condition`、`guard_snippet` 和 `potential_consequence`
|
||||
|
||||
:::note[互补审查]
|
||||
同时运行 `bmad-review-adversarial-general` 和 `bmad-review-edge-case-hunter` 可获得正交覆盖。对抗式审查捕捉质量和完整性问题；边界猎手捕捉未处理的路径。
|
||||
:::
|
||||
**输入：** `content`（必填），`also_consider`（可选）
|
||||
**输出：** JSON 发现列表（含触发条件与潜在后果）
|
||||
|
||||
## bmad-editorial-review-prose
|
||||
|
||||
**聚焦表达清晰度的临床式文案编辑。** — 审查文本中阻碍理解的问题，以 Microsoft 写作风格指南为基准，保留作者个人风格。
|
||||
**定位：** 聚焦表达清晰度的文案审查，不替你改写个人风格。
|
||||
|
||||
**适用场景：**
|
||||
- 内容可用，但读起来费劲
|
||||
- 需要针对特定读者提升可理解性
|
||||
- 想做“表达修复”而非“立场重写”
|
||||
|
||||
- 写完初稿想打磨文字
|
||||
- 需要确保内容对特定受众足够清晰
|
||||
- 只想修表达问题，不想改写风格偏好
|
||||
**工作机制：**
|
||||
1. 跳过 frontmatter 与代码块读取正文
|
||||
2. 标记影响理解的表达问题
|
||||
3. 去重同类问题并输出修订建议
|
||||
|
||||
**工作原理：**
|
||||
|
||||
1. 阅读内容，跳过代码块和 frontmatter
|
||||
2. 识别表达问题（不是风格偏好）
|
||||
3. 对多处出现的相同问题去重
|
||||
4. 生成三列修改表
|
||||
|
||||
**输入：**
|
||||
|
||||
- `content`（必填）— Markdown、纯文本或 XML
|
||||
- `style_guide`（可选）— 项目特定的写作风格指南
|
||||
- `reader_type`（可选）— `humans`（默认）注重清晰流畅，`llm` 注重精确一致
|
||||
|
||||
**输出：** 三列 Markdown 表格：原文 | 修改后 | 变更说明
|
||||
**输入：** `content`（必填），`style_guide`（可选），`reader_type`（可选）
|
||||
**输出：** 三列表（原文 / 修改后 / 说明）
|
||||
|
||||
## bmad-editorial-review-structure
|
||||
|
||||
**结构编辑——提出裁剪、合并、移动和精简建议。** — 审查文档组织结构，在文案编辑之前提出实质性调整建议，以改善清晰度和阅读流畅性。
|
||||
**定位：** 处理文档结构问题：裁剪、合并、重排、精简。
|
||||
|
||||
**适用场景：**
|
||||
- 文档是多来源拼接，结构不连贯
|
||||
- 想在不丢信息前提下降低篇幅
|
||||
- 重要信息被埋在低优先级段落
|
||||
|
||||
- 文档由多个子流程产出，需要结构上的连贯性
|
||||
- 想在保持可读性的前提下缩减文档篇幅
|
||||
- 需要识别范围越界或关键信息被埋没的情况
|
||||
**工作机制：**
|
||||
1. 按结构模型分析文档组织
|
||||
2. 识别冗余、越界与信息埋没
|
||||
3. 输出优先级建议与压缩预估
|
||||
|
||||
**工作原理：**
|
||||
|
||||
1. 将文档与 5 种结构模型对照分析（教程、参考、解释、提示词、战略）
|
||||
2. 识别冗余、范围越界和被埋没的信息
|
||||
3. 生成优先级排序的建议：裁剪、合并、移动、精简、质疑、保留
|
||||
4. 估算总缩减字数和百分比
|
||||
|
||||
**输入：**
|
||||
|
||||
- `content`（必填）— 待审查的文档
|
||||
- `purpose`（可选）— 预期用途（如 "quickstart tutorial"）
|
||||
- `target_audience`（可选）— 目标读者
|
||||
- `reader_type`（可选）— `humans` 或 `llm`
|
||||
- `length_target`（可选）— 目标缩减量（如 "30% shorter"）
|
||||
|
||||
**输出：** 文档摘要、优先级排序的建议列表，以及预估缩减量
|
||||
**输入：** `content`（必填），`purpose`/`target_audience`/`reader_type`/`length_target`（可选）
|
||||
**输出：** 结构建议清单 + 预计缩减量
|
||||
|
||||
## bmad-shard-doc
|
||||
|
||||
**将大型 Markdown 文件拆分为有序的章节文件。** — 以二级标题为分割点，创建一个包含独立章节文件和索引的文件夹。
|
||||
**定位：** 把超大 Markdown 文档拆成可维护章节。
|
||||
|
||||
**适用场景：**
|
||||
- 单文件过大（常见 500+ 行）
|
||||
- 需要并行编辑或分段维护
|
||||
- 希望降低 LLM 读取成本
|
||||
|
||||
- Markdown 文档过大，难以有效管理（500+ 行）
|
||||
- 想把单体文档拆分成可导航的章节
|
||||
- 需要独立文件以支持并行编辑或 LLM 上下文管理
|
||||
**工作机制：**
|
||||
1. 校验源文件
|
||||
2. 按 `##` 二级标题分片
|
||||
3. 生成 `index.md` 与编号章节
|
||||
4. 提示保留/归档/删除原文件
|
||||
|
||||
**工作原理：**
|
||||
|
||||
1. 验证源文件存在且是 Markdown 格式
|
||||
2. 按二级（`##`）标题分割为编号章节文件
|
||||
3. 创建 `index.md`，包含章节清单和链接
|
||||
4. 提示你选择删除、归档还是保留原文件
|
||||
|
||||
**输入：** 源 Markdown 文件路径，可选目标文件夹
|
||||
|
||||
**输出：** 包含 `index.md` 和 `01-{section}.md`、`02-{section}.md` 等文件的文件夹
|
||||
**输入：** 源文件路径（可选目标目录）
|
||||
**输出：** 分片目录（含 `index.md`）
|
||||
|
||||
## bmad-index-docs
|
||||
|
||||
**生成或更新文件夹中所有文档的索引。** — 扫描目录，读取每个文件以理解其用途，生成一份带链接和描述的有序 `index.md`。
|
||||
**定位：** 为目录自动生成可导航文档索引。
|
||||
|
||||
**适用场景：**
|
||||
- 文档目录持续增长，需要统一入口
|
||||
- 想给 LLM 或新人快速提供全局视图
|
||||
- 需要保持索引与目录同步
|
||||
|
||||
- 需要一个轻量索引供 LLM 快速扫描可用文档
|
||||
- 文档文件夹不断增长，需要一个有序的目录
|
||||
- 想要一份自动生成、能持续保持最新的概览
|
||||
**工作机制：**
|
||||
1. 扫描目录内非隐藏文件
|
||||
2. 读取文件并提炼用途
|
||||
3. 按类型/主题组织条目
|
||||
4. 生成描述简洁的 `index.md`
|
||||
|
||||
**工作原理：**
|
||||
**输入：** 目标目录路径
|
||||
**输出：** 更新后的 `index.md`
|
||||
|
||||
1. 扫描目标目录中所有非隐藏文件
|
||||
2. 读取每个文件以理解其实际用途
|
||||
3. 按类型、用途或子目录分组
|
||||
4. 生成简洁描述（每条 3-10 个词）
|
||||
## 相关参考
|
||||
|
||||
**输入：** 目标文件夹路径
|
||||
|
||||
**输出：** `index.md`，包含有序的文件列表、相对链接和简要描述
|
||||
- [技能（Skills）参考](./commands.md)
|
||||
- [智能体参考](./agents.md)
|
||||
- [工作流地图](./workflow-map.md)
|
||||
|
|
|
|||
|
|
@ -1,94 +1,94 @@
|
|||
---
|
||||
title: "官方模块"
|
||||
description: 用于构建自定义智能体、创意智能、游戏开发和测试的附加模块
|
||||
description: BMad 可选模块参考：能力边界、适用场景与外部资源
|
||||
sidebar:
|
||||
order: 4
|
||||
---
|
||||
|
||||
BMad 通过您在安装期间选择的官方模块进行扩展。这些附加模块为内置核心和 BMM（敏捷套件）之外的特定领域提供专门的智能体、工作流和任务。
|
||||
BMad 通过可选模块扩展能力。你可以在安装时按需选择模块，为当前项目增加特定领域的 `agent`、`workflow` 与 `skill`。
|
||||
|
||||
:::tip[安装模块]
|
||||
运行 `npx bmad-method install` 并选择您需要的模块。安装程序会自动处理下载、配置和 IDE 集成。
|
||||
运行 `npx bmad-method install`，在交互步骤中勾选所需模块。安装器会自动生成对应 skills 并写入当前 IDE 的 skills 目录。
|
||||
:::
|
||||
|
||||
## BMad Builder
|
||||
## 先看总览
|
||||
|
||||
在引导式协助下创建自定义智能体、工作流和特定领域的模块。BMad Builder 是用于扩展框架本身的元模块。
|
||||
| 模块 | 代码 | 最适合 | 核心能力 |
|
||||
| --- | --- | --- | --- |
|
||||
| BMad Builder | `bmb` | 扩展 BMad 本身 | 构建自定义 agent / workflow / module |
|
||||
| Creative Intelligence Suite | `cis` | 前期创意与问题探索 | 头脑风暴、设计思维、创新策略 |
|
||||
| Game Dev Studio | `gds` | 游戏方向研发 | 游戏设计文档、原型推进、叙事支持 |
|
||||
| Test Architect（TEA） | `tea` | 企业级测试治理 | 测试策略、可追溯性、质量门控 |
|
||||
|
||||
- **代码：** `bmb`
|
||||
- **npm：** [`bmad-builder`](https://www.npmjs.com/package/bmad-builder)
|
||||
- **GitHub：** [bmad-code-org/bmad-builder](https://github.com/bmad-code-org/bmad-builder)
|
||||
## BMad Builder（`bmb`）
|
||||
|
||||
**提供：**
|
||||
用于“构建 BMad”的元模块，重点是把你的方法沉淀成可复用能力。
|
||||
|
||||
- 智能体构建器 —— 创建具有自定义专业知识和工具访问权限的专用 AI 智能体
|
||||
- 工作流构建器 —— 设计包含步骤和决策点的结构化流程
|
||||
- 模块构建器 —— 将智能体和工作流打包为可共享、可发布的模块
|
||||
- 交互式设置，支持 YAML 配置和 npm 发布
|
||||
**你会得到：**
|
||||
- Agent Builder：创建具备特定专业能力的 agent
|
||||
- Workflow Builder：设计有步骤与决策点的 workflow
|
||||
- Module Builder：将 agent/workflow 打包为可发布模块
|
||||
- 交互式配置与发布支持（YAML + npm）
|
||||
|
||||
## 创意智能套件
|
||||
**外部资源（英文）：**
|
||||
- npm: [`bmad-builder`](https://www.npmjs.com/package/bmad-builder)
|
||||
- GitHub: [bmad-code-org/bmad-builder](https://github.com/bmad-code-org/bmad-builder)
|
||||
|
||||
用于早期开发阶段的结构化创意、构思和创新的 AI 驱动工具。该套件提供多个智能体，利用经过验证的框架促进头脑风暴、设计思维和问题解决。
|
||||
## Creative Intelligence Suite（`cis`）
|
||||
|
||||
- **代码：** `cis`
|
||||
- **npm：** [`bmad-creative-intelligence-suite`](https://www.npmjs.com/package/bmad-creative-intelligence-suite)
|
||||
- **GitHub：** [bmad-code-org/bmad-module-creative-intelligence-suite](https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite)
|
||||
用于前期探索与创意发散，帮助团队在进入规划前澄清问题与方向。
|
||||
|
||||
**提供：**
|
||||
**你会得到：**
|
||||
- 多个创意向 agent（如创新策略、设计思维、头脑风暴）
|
||||
- 问题重构与系统化思考支持
|
||||
- 常见构思框架（含 SCAMPER、逆向头脑风暴等）
|
||||
|
||||
- 创新策略师、设计思维教练和头脑风暴教练智能体
|
||||
- 问题解决者和创意问题解决者，用于系统性和横向思维
|
||||
- 故事讲述者和演示大师，用于叙事和推介
|
||||
- 构思框架，包括 SCAMPER、逆向头脑风暴和问题重构
|
||||
**外部资源（英文）：**
|
||||
- npm: [`bmad-creative-intelligence-suite`](https://www.npmjs.com/package/bmad-creative-intelligence-suite)
|
||||
- GitHub: [bmad-code-org/bmad-module-creative-intelligence-suite](https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite)
|
||||
|
||||
## 游戏开发工作室
|
||||
## Game Dev Studio（`gds`）
|
||||
|
||||
适用于 Unity、Unreal、Godot 和自定义引擎的结构化游戏开发工作流。通过 Quick Flow 支持快速原型制作，并通过史诗驱动的冲刺支持全面规模的生产。
|
||||
面向游戏开发场景，覆盖从概念到实现的结构化 workflow。
|
||||
|
||||
- **代码：** `gds`
|
||||
- **npm：** [`bmad-game-dev-studio`](https://www.npmjs.com/package/bmad-game-dev-studio)
|
||||
- **GitHub：** [bmad-code-org/bmad-module-game-dev-studio](https://github.com/bmad-code-org/bmad-module-game-dev-studio)
|
||||
**你会得到：**
|
||||
- 游戏设计文档（GDD）生成流程
|
||||
- 面向快速迭代的 Quick Dev 模式
|
||||
- 叙事设计支持（角色、对话、世界观）
|
||||
- 多引擎适配建议（Unity/Unreal/Godot 等）
|
||||
|
||||
**提供：**
|
||||
**外部资源（英文）：**
|
||||
- npm: [`bmad-game-dev-studio`](https://www.npmjs.com/package/bmad-game-dev-studio)
|
||||
- GitHub: [bmad-code-org/bmad-module-game-dev-studio](https://github.com/bmad-code-org/bmad-module-game-dev-studio)
|
||||
|
||||
- 游戏设计文档（GDD）生成工作流
|
||||
- 用于快速原型制作的 Quick Dev 模式
|
||||
- 针对角色、对话和世界构建的叙事设计支持
|
||||
- 覆盖 21+ 种游戏类型，并提供特定引擎的架构指导
|
||||
## Test Architect（TEA，`tea`）
|
||||
|
||||
## 测试架构师（TEA）
|
||||
面向高要求测试场景的独立模块。与内置 QA 相比，TEA 更强调策略、追溯与发布门控。
|
||||
|
||||
通过专家智能体和九个结构化工作流提供企业级测试策略、自动化指导和发布门控决策。TEA 远超内置 QA 智能体，提供基于风险的优先级排序和需求可追溯性。
|
||||
**你会得到：**
|
||||
- Murat 测试架构师 agent
|
||||
- 覆盖测试设计、ATDD、自动化、审查、追溯的 workflow
|
||||
- NFR 评估、CI 集成与测试框架脚手架
|
||||
- P0-P3 风险优先级策略与可选工具集成
|
||||
|
||||
- **代码：** `tea`
|
||||
- **npm：** [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
|
||||
- **GitHub：** [bmad-code-org/bmad-method-test-architecture-enterprise](https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise)
|
||||
**外部资源（英文）：**
|
||||
- 文档: [TEA Module Docs](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/)
|
||||
- npm: [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
|
||||
- GitHub: [bmad-code-org/bmad-method-test-architecture-enterprise](https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise)
|
||||
|
||||
**提供：**
|
||||
## 如何选择模块
|
||||
|
||||
- Murat 智能体（主测试架构师和质量顾问）
|
||||
- 用于测试设计、ATDD、自动化、测试审查和可追溯性的工作流
|
||||
- NFR 评估、CI 设置和框架脚手架
|
||||
- P0-P3 优先级排序，可选 Playwright Utils 和 MCP 集成
|
||||
- 你要“扩展框架能力”而不是只用框架：优先 `bmb`
|
||||
- 你还在探索方向、需要结构化创意过程：优先 `cis`
|
||||
- 你是游戏项目：优先 `gds`
|
||||
- 你需要测试治理、质量门控或审计追溯：优先 `tea`
|
||||
|
||||
## 社区模块
|
||||
:::note[模块可以组合安装]
|
||||
模块之间不是互斥关系。你可以按项目阶段增量安装，并在后续重新运行安装器同步 skills。
|
||||
:::
|
||||
|
||||
社区模块和模块市场即将推出。请查看 [BMad GitHub 组织](https://github.com/bmad-code-org) 获取最新更新。
|
||||
## 相关参考
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **workflow**：工作流。指一系列有序的任务或步骤，用于完成特定的业务流程或开发流程。
|
||||
- **module**：模块。指可独立开发、测试和部署的软件单元，用于扩展系统功能。
|
||||
- **meta-module**：元模块。指用于创建或扩展其他模块的模块，是模块的模块。
|
||||
- **ATDD**：验收测试驱动开发（Acceptance Test-Driven Development）。一种敏捷开发实践，在编写代码之前先编写验收测试。
|
||||
- **NFR**：非功能性需求（Non-Functional Requirement）。指系统在性能、安全性、可维护性等方面的质量属性要求。
|
||||
- **CI**：持续集成（Continuous Integration）。一种软件开发实践，频繁地将代码集成到主干分支，并进行自动化测试。
|
||||
- **MCP**：模型上下文协议（Model Context Protocol）。一种用于在 AI 模型与外部工具或服务之间进行通信的协议。
|
||||
- **SCAMPER**：一种创意思维技巧，包含替代、组合、调整、修改、其他用途、消除和重组七个维度。
|
||||
- **GDD**：游戏设计文档（Game Design Document）。用于描述游戏设计理念、玩法、机制等内容的详细文档。
|
||||
- **P0-P3**：优先级分级。P0 为最高优先级（关键），P3 为最低优先级（可选）。
|
||||
- **sprint**：冲刺。敏捷开发中的固定时间周期，通常为 1-4 周，用于完成预定的工作。
|
||||
- **epic**：史诗。敏捷开发中的大型工作项，可分解为多个用户故事或任务。
|
||||
- **Quick Flow**：快速流程。一种用于快速原型开发的工作流模式。
|
||||
- [测试选项](./testing.md)
|
||||
- [技能（Skills）参考](./commands.md)
|
||||
- [工作流地图](./workflow-map.md)
|
||||
|
|
|
|||
|
|
@ -1,122 +1,105 @@
|
|||
---
|
||||
title: "测试选项"
|
||||
description: 比较内置 QA 智能体（Quinn）与测试架构师（TEA）模块的测试自动化。
|
||||
description: 内置 QA（Quinn）与 TEA 模块对比：何时用哪个、各自边界是什么
|
||||
sidebar:
|
||||
order: 5
|
||||
---
|
||||
|
||||
BMad 提供两条测试路径：用于快速生成测试的内置 QA 智能体，以及用于企业级测试策略的可安装测试架构师模块。
|
||||
BMad 有两条测试路径：
|
||||
- **Quinn（内置 QA）**：快速生成可运行测试
|
||||
- **TEA（可选模块）**：企业级测试策略与治理能力
|
||||
|
||||
## 应该使用哪一个？
|
||||
## 该选 Quinn 还是 TEA？
|
||||
|
||||
| 因素 | Quinn（内置 QA） | TEA 模块 |
|
||||
| 维度 | Quinn（内置 QA） | TEA 模块 |
|
||||
| --- | --- | --- |
|
||||
| **最适合** | 中小型项目、快速覆盖 | 大型项目、受监管或复杂领域 |
|
||||
| **设置** | 无需安装——包含在 BMM 中 | 通过 `npx bmad-method install` 单独安装 |
|
||||
| **方法** | 快速生成测试，稍后迭代 | 先规划，再生成并保持可追溯性 |
|
||||
| **测试类型** | API 和 E2E 测试 | API、E2E、ATDD、NFR 等 |
|
||||
| **策略** | 快乐路径 + 关键边界情况 | 基于风险的优先级排序（P0-P3） |
|
||||
| **工作流数量** | 1（Automate） | 9（设计、ATDD、自动化、审查、可追溯性等） |
|
||||
| 最适合 | 中小项目、快速补覆盖 | 大型项目、受监管或复杂业务 |
|
||||
| 安装成本 | 无需额外安装（BMM 内置） | 需通过安装器单独选择 |
|
||||
| 方法 | 先生成测试，再迭代 | 先定义策略，再执行并追溯 |
|
||||
| 测试类型 | API + E2E | API、E2E、ATDD、NFR 等 |
|
||||
| 风险策略 | 快乐路径 + 关键边界 | P0-P3 风险优先级 |
|
||||
| workflow 数量 | 1（Automate） | 9（设计/自动化/审查/追溯等） |
|
||||
|
||||
:::tip[从 Quinn 开始]
|
||||
大多数项目应从 Quinn 开始。如果后续需要测试策略、质量门控或需求可追溯性，可并行安装 TEA。
|
||||
:::tip[默认建议]
|
||||
大多数项目先用 Quinn。只有当你需要质量门控、合规追溯或系统化测试治理时，再引入 TEA。
|
||||
:::
|
||||
|
||||
## 内置 QA 智能体（Quinn）
|
||||
## 内置 QA（Quinn）
|
||||
|
||||
Quinn 是 BMM（敏捷套件）模块中的内置 QA 智能体。它使用项目现有的测试框架快速生成可运行的测试——无需配置或额外安装。
|
||||
Quinn 是 BMM 内置 agent，目标是用你现有测试栈快速落地测试，不要求额外配置。
|
||||
|
||||
**触发方式：** `QA` 或 `bmad-bmm-qa-automate`
|
||||
**触发方式：**
|
||||
- 菜单触发器：`QA`
|
||||
- skill：`bmad-qa-generate-e2e-tests`
|
||||
|
||||
### Quinn 的功能
|
||||
### Quinn 会做什么
|
||||
|
||||
Quinn 运行单个工作流（Automate），包含五个步骤：
|
||||
Quinn 的 Automate 流程通常包含 5 步：
|
||||
1. 检测现有测试框架（如 Jest、Vitest、Playwright、Cypress）
|
||||
2. 确认待测功能（手动指定或自动发现）
|
||||
3. 生成 API 测试（状态码、结构、主路径与错误分支）
|
||||
4. 生成 E2E 测试（语义定位器 + 可见结果断言）
|
||||
5. 执行并修复基础失败项
|
||||
|
||||
1. **检测测试框架**——扫描 `package.json` 和现有测试文件以识别框架（Jest、Vitest、Playwright、Cypress 或任何标准运行器）。如果不存在，则分析项目技术栈并推荐一个。
|
||||
2. **识别功能**——询问要测试的内容或自动发现代码库中的功能。
|
||||
3. **生成 API 测试**——覆盖状态码、响应结构、快乐路径和 1-2 个错误情况。
|
||||
4. **生成 E2E 测试**——使用语义定位器和可见结果断言覆盖用户工作流。
|
||||
5. **运行并验证**——执行生成的测试并立即修复失败。
|
||||
**默认风格：**
|
||||
- 仅使用标准框架 API
|
||||
- UI 测试优先语义定位器（角色、标签、文本）
|
||||
- 测试互相独立，不依赖顺序
|
||||
- 避免硬编码等待/休眠
|
||||
|
||||
Quinn 会生成测试摘要，保存到项目的实现产物文件夹中。
|
||||
|
||||
### 测试模式
|
||||
|
||||
生成的测试遵循"简单且可维护"的理念：
|
||||
|
||||
- **仅使用标准框架 API**——不使用外部工具或自定义抽象
|
||||
- UI 测试使用**语义定位器**（角色、标签、文本而非 CSS 选择器）
|
||||
- **独立测试**，无顺序依赖
|
||||
- **无硬编码等待或休眠**
|
||||
- **清晰的描述**，可作为功能文档阅读
|
||||
|
||||
:::note[范围]
|
||||
Quinn 仅生成测试。如需代码审查和故事验证，请改用代码审查工作流（`CR`）。
|
||||
:::note[范围边界]
|
||||
Quinn 只负责“生成测试”。如需实现质量评审与故事验收，请配合代码审查 workflow（`CR` / `bmad-code-review`）。
|
||||
:::
|
||||
|
||||
### 何时使用 Quinn
|
||||
### 何时用 Quinn
|
||||
|
||||
- 为新功能或现有功能快速实现测试覆盖
|
||||
- 无需高级设置的初学者友好型测试自动化
|
||||
- 任何开发者都能阅读和维护的标准测试模式
|
||||
- 不需要全面测试策略的中小型项目
|
||||
- 要快速补齐某个功能的测试覆盖
|
||||
- 团队希望先获得可运行基线，再逐步增强
|
||||
- 项目暂不需要完整测试治理体系
|
||||
|
||||
## 测试架构师（TEA）模块
|
||||
## TEA（Test Architect）模块
|
||||
|
||||
TEA 是一个独立模块，提供专家智能体（Murat）和九个结构化工作流，用于企业级测试。它超越了测试生成，涵盖测试策略、基于风险的规划、质量门控和需求可追溯性。
|
||||
TEA 提供专家测试 agent（Murat）与 9 个结构化 workflow，覆盖策略、执行、审查、追溯和发布门控。
|
||||
|
||||
- **文档：** [TEA 模块文档（英文）](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/)
|
||||
- **安装：** `npx bmad-method install` 并选择 TEA 模块
|
||||
- **npm：** [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
|
||||
**外部资源（英文）：**
|
||||
- 文档: [TEA Module Docs](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/)
|
||||
- npm: [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
|
||||
|
||||
### TEA 提供的功能
|
||||
**安装：** `npx bmad-method install` 后选择 TEA 模块。
|
||||
|
||||
| Workflow | Purpose |
|
||||
### TEA 的 9 个 workflow
|
||||
|
||||
| Workflow | 用途 |
|
||||
| --- | --- |
|
||||
| Test Design | 创建与需求关联的全面测试策略 |
|
||||
| ATDD | 基于干系人标准的验收测试驱动开发 |
|
||||
| Automate | 使用高级模式和工具生成测试 |
|
||||
| Test Review | 根据策略验证测试质量和覆盖范围 |
|
||||
| Traceability | 将测试映射回需求，用于审计和合规 |
|
||||
| NFR Assessment | 评估非功能性需求（性能、安全性） |
|
||||
| CI Setup | 在持续集成管道中配置测试执行 |
|
||||
| Framework Scaffolding | 设置测试基础设施和项目结构 |
|
||||
| Release Gate | 基于数据做出发布/不发布决策 |
|
||||
| Test Design | 按需求建立测试策略 |
|
||||
| ATDD | 基于验收标准驱动测试设计 |
|
||||
| Automate | 使用高级模式生成自动化测试 |
|
||||
| Test Review | 评估测试质量与覆盖完整性 |
|
||||
| Traceability | 建立“需求—测试”追溯链路 |
|
||||
| NFR Assessment | 评估性能/安全等非功能需求 |
|
||||
| CI Setup | 配置 CI 中的测试执行 |
|
||||
| Framework Scaffolding | 搭建测试工程基础结构 |
|
||||
| Release Gate | 基于数据做发布/不发布决策 |
|
||||
|
||||
TEA 还支持 P0-P3 基于风险的优先级排序，以及与 Playwright Utils 和 MCP 工具的可选集成。
|
||||
### 何时用 TEA
|
||||
|
||||
### 何时使用 TEA
|
||||
- 需要合规、审计或强追溯能力
|
||||
- 需要跨功能做风险优先级管理
|
||||
- 发布前存在明确质量门控流程
|
||||
- 业务复杂，必须先建策略再写测试
|
||||
|
||||
- 需要需求可追溯性或合规文档的项目
|
||||
- 需要在多个功能间进行基于风险的测试优先级排序的团队
|
||||
- 发布前具有正式质量门控的企业环境
|
||||
- 在编写测试前必须规划测试策略的复杂领域
|
||||
- 已超出 Quinn 单一工作流方法的项目
|
||||
## 测试放在流程的哪个位置
|
||||
|
||||
## 测试如何融入工作流
|
||||
按 BMad workflow-map，测试位于阶段 4（实施）：
|
||||
|
||||
Quinn 的 Automate 工作流出现在 BMad 方法工作流图的第 4 阶段（实现）。典型序列：
|
||||
1. epic 内逐个 story：开发（`DS` / `bmad-dev-story`）+ 代码审查（`CR` / `bmad-code-review`）
|
||||
2. epic 完成后：用 Quinn 或 TEA 的 Automate 统一生成/补齐测试
|
||||
3. 最后执行复盘（`bmad-retrospective`）
|
||||
|
||||
1. 使用开发工作流（`DS`）实现一个故事
|
||||
2. 使用 Quinn（`QA`）或 TEA 的 Automate 工作流生成测试
|
||||
3. 使用代码审查（`CR`）验证实现
|
||||
Quinn 主要依据代码直接生成测试；TEA 可结合上游规划产物（如 PRD、architecture）实现更强追溯。
|
||||
|
||||
Quinn 直接从源代码工作，无需加载规划文档（PRD、架构）。TEA 工作流可以与上游规划产物集成以实现可追溯性。
|
||||
## 相关参考
|
||||
|
||||
有关测试在整体流程中的位置，请参阅[工作流图](./workflow-map.md)。
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **QA (Quality Assurance)**：质量保证。确保产品或服务满足质量要求的过程。
|
||||
- **E2E (End-to-End)**：端到端。测试整个系统从开始到结束的完整流程。
|
||||
- **ATDD (Acceptance Test-Driven Development)**：验收测试驱动开发。在编码前先编写验收测试的开发方法。
|
||||
- **NFR (Non-Functional Requirement)**：非功能性需求。描述系统如何运行而非做什么的需求，如性能、安全性等。
|
||||
- **P0-P3**：优先级级别。P0 为最高优先级，P3 为最低优先级，用于基于风险的测试排序。
|
||||
- **Happy path**：快乐路径。测试系统在理想条件下的正常工作流程。
|
||||
- **Semantic locators**：语义定位器。使用有意义的元素属性（如角色、标签、文本）而非 CSS 选择器来定位 UI 元素。
|
||||
- **Quality gates**：质量门控。在开发流程中设置的检查点，用于确保质量标准。
|
||||
- **Requirements traceability**：需求可追溯性。能够追踪需求从设计到测试再到实现的完整链路。
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **CI (Continuous Integration)**：持续集成。频繁地将代码集成到主干，并自动运行测试的实践。
|
||||
- **MCP (Model Context Protocol)**：模型上下文协议。用于在 AI 模型与外部工具之间通信的协议。
|
||||
- [官方模块](./modules.md)
|
||||
- [工作流地图](./workflow-map.md)
|
||||
- [智能体参考](./agents.md)
|
||||
|
|
|
|||
|
|
@ -1,103 +1,86 @@
|
|||
---
|
||||
title: "工作流程图"
|
||||
description: BMad Method 工作流程阶段与输出的可视化参考
|
||||
title: "工作流地图"
|
||||
description: BMad Method 各阶段 workflow 与产出速查
|
||||
sidebar:
|
||||
order: 1
|
||||
---
|
||||
|
||||
BMad Method（BMM）是 BMad 生态系统中的一个模块，旨在遵循上下文工程与规划的最佳实践。AI 智能体在清晰、结构化的上下文中表现最佳。BMM 系统在 4 个不同阶段中逐步构建该上下文——每个阶段以及每个阶段内的多个可选工作流程都会生成文档，这些文档为下一阶段提供信息，因此智能体始终知道要构建什么以及为什么。
|
||||
BMad Method（BMM）通过分阶段 workflow 逐步构建上下文，让智能体始终知道“做什么、为什么做、如何做”。这张地图用于快速查阅阶段目标、关键 workflow 和对应产出。
|
||||
|
||||
其基本原理和概念来自敏捷方法论，这些方法论在整个行业中被广泛用作思维框架，并取得了巨大成功。
|
||||
|
||||
如果您在任何时候不确定该做什么，`bmad-help` 命令将帮助您保持正轨或了解下一步该做什么。您也可以随时参考此文档以获取参考信息——但如果您已经安装了 BMad Method，`bmad-help` 是完全交互式的，速度要快得多。此外，如果您正在使用扩展了 BMad Method 或添加了其他互补非扩展模块的不同模块——`bmad-help` 会不断演进以了解所有可用内容，从而为您提供最佳即时建议。
|
||||
|
||||
最后的重要说明：以下每个工作流程都可以通过斜杠命令直接使用您选择的工具运行，或者先加载智能体，然后使用智能体菜单中的条目来运行。
|
||||
如果你不确定下一步，优先运行 `bmad-help`。它会基于你当前项目状态和已安装模块给出实时建议。
|
||||
|
||||
<iframe src="/workflow-map-diagram.html" title="BMad Method Workflow Map Diagram" width="100%" height="100%" style="border-radius: 8px; border: 1px solid #334155; min-height: 900px;"></iframe>
|
||||
|
||||
<p style="font-size: 0.8rem; text-align: right; margin-top: -0.5rem; margin-bottom: 1rem;">
|
||||
<a href="/workflow-map-diagram.html" target="_blank" rel="noopener noreferrer">在新标签页中打开图表 ↗</a>
|
||||
<a href="/workflow-map-diagram.html" target="_blank" rel="noopener noreferrer">在新标签页打开图表 ↗</a>
|
||||
</p>
|
||||
|
||||
## 阶段 1：分析（可选）
|
||||
|
||||
在投入规划之前探索问题空间并验证想法。
|
||||
在正式规划前，先验证问题空间与关键假设。
|
||||
|
||||
| 工作流程 | 目的 | 产出 |
|
||||
| ------------------------------- | -------------------------------------------------------------------------- | ------------------------- |
|
||||
| `bmad-brainstorming` | 在头脑风暴教练的引导协助下进行项目想法头脑风暴 | `brainstorming-report.md` |
|
||||
| `bmad-bmm-research` | 验证市场、技术或领域假设 | 研究发现 |
|
||||
| `bmad-bmm-create-product-brief` | 捕捉战略愿景 | `product-brief.md` |
|
||||
| Workflow | 目的 | 产出 |
|
||||
| --- | --- | --- |
|
||||
| `bmad-brainstorming` | 通过引导式创意方法扩展方案空间 | `brainstorming-report.md` |
|
||||
| `bmad-domain-research`、`bmad-market-research`、`bmad-technical-research` | 验证领域、市场与技术假设 | 研究发现 |
|
||||
| `bmad-create-product-brief` | 沉淀产品方向与战略愿景 | `product-brief.md` |
|
||||
|
||||
## 阶段 2：规划
|
||||
|
||||
定义要构建什么以及为谁构建。
|
||||
定义“为谁做、做什么”。
|
||||
|
||||
| 工作流程 | 目的 | 产出 |
|
||||
| --------------------------- | ---------------------------------------- | ------------ |
|
||||
| `bmad-bmm-create-prd` | 定义需求（FRs/NFRs） | `PRD.md` |
|
||||
| `bmad-bmm-create-ux-design` | 设计用户体验（当 UX 重要时） | `ux-spec.md` |
|
||||
| Workflow | 目的 | 产出 |
|
||||
| --- | --- | --- |
|
||||
| `bmad-create-prd` | 明确 FR/NFR 与范围边界 | `PRD.md` |
|
||||
| `bmad-create-ux-design` | 在 UX 复杂场景下补齐交互与体验方案 | `ux-spec.md` |
|
||||
|
||||
## 阶段 3：解决方案设计
|
||||
## 阶段 3：解决方案设计（Solutioning）
|
||||
|
||||
决定如何构建它并将工作分解为故事。
|
||||
定义“如何实现”并拆分可交付工作单元。
|
||||
|
||||
| 工作流程 | 目的 | 产出 |
|
||||
| ----------------------------------------- | ------------------------------------------ | --------------------------- |
|
||||
| `bmad-bmm-create-architecture` | 明确技术决策 | 包含 ADR 的 `architecture.md` |
|
||||
| `bmad-bmm-create-epics-and-stories` | 将需求分解为可实施的工作 | 包含故事的 Epic 文件 |
|
||||
| `bmad-bmm-check-implementation-readiness` | 实施前的关卡检查 | PASS/CONCERNS/FAIL 决策 |
|
||||
| Workflow | 目的 | 产出 |
|
||||
| --- | --- | --- |
|
||||
| `bmad-create-architecture` | 显式记录技术决策与架构边界 | `architecture.md`（含 ADR） |
|
||||
| `bmad-create-epics-and-stories` | 将需求拆分为可实施的 epics/stories | epics 文件与 story 条目 |
|
||||
| `bmad-check-implementation-readiness` | 实施前 gate 检查 | PASS / CONCERNS / FAIL 结论 |
|
||||
|
||||
## 阶段 4：实施
|
||||
|
||||
逐个故事地构建它。即将推出完整的阶段 4 自动化！
|
||||
按 story 节奏持续交付与校验。
|
||||
|
||||
| 工作流程 | 目的 | 产出 |
|
||||
| -------------------------- | ------------------------------------------------------------------------ | -------------------------------- |
|
||||
| `bmad-bmm-sprint-planning` | 初始化跟踪（每个项目一次，以排序开发周期） | `sprint-status.yaml` |
|
||||
| `bmad-bmm-create-story` | 准备下一个故事以供实施 | `story-[slug].md` |
|
||||
| `bmad-bmm-dev-story` | 实施该故事 | 工作代码 + 测试 |
|
||||
| `bmad-bmm-code-review` | 验证实施质量 | 批准或请求更改 |
|
||||
| `bmad-bmm-correct-course` | 处理冲刺中的重大变更 | 更新的计划或重新路由 |
|
||||
| `bmad-bmm-automate` | 为现有功能生成测试 - 在完整的 epic 完成后使用 | 端到端 UI 专注测试套件 |
|
||||
| `bmad-bmm-retrospective` | 在 epic 完成后回顾 | 经验教训 |
|
||||
| Workflow | 目的 | 产出 |
|
||||
| --- | --- | --- |
|
||||
| `bmad-sprint-planning` | 初始化迭代追踪（通常每项目一次） | `sprint-status.yaml` |
|
||||
| `bmad-create-story` | 准备下一个可实施 story | `story-[slug].md` |
|
||||
| `bmad-dev-story` | 按规范实现 story | 可运行代码与测试 |
|
||||
| `bmad-code-review` | 验证实现质量 | 通过或变更请求 |
|
||||
| `bmad-correct-course` | 处理中途重大方向调整 | 更新后的计划或重路由 |
|
||||
| `bmad-sprint-status` | 跟踪冲刺与 story 状态 | 状态更新 |
|
||||
| `bmad-retrospective` | epic 完成后复盘 | 经验与改进项 |
|
||||
|
||||
## 快速流程（并行轨道）
|
||||
## Quick Flow（并行快线）
|
||||
|
||||
对于小型、易于理解的工作，跳过阶段 1-3。
|
||||
当任务范围小且目标清晰时，可跳过阶段 1-3 直接推进：
|
||||
|
||||
| 工作流程 | 目的 | 产出 |
|
||||
| --------------------- | --------------------------------------------------------------------------- | --------------------------- |
|
||||
| `bmad-bmm-quick-dev` | 统一快速流程 — 澄清意图、规划、实现、审查和呈现 | `tech-spec.md` + 代码 |
|
||||
| Workflow | 目的 | 产出 |
|
||||
| --- | --- | --- |
|
||||
| `bmad-quick-dev` | 统一快流：意图澄清、规划、实现、审查、呈现 | `spec-*.md` + 代码变更 |
|
||||
|
||||
## 上下文管理
|
||||
|
||||
每个文档都成为下一阶段的上下文。PRD 告诉架构师哪些约束很重要。架构告诉开发智能体要遵循哪些模式。故事文件为实施提供专注、完整的上下文。没有这种结构，智能体会做出不一致的决策。
|
||||
每个阶段产出都会成为下一阶段输入：PRD 约束架构，架构约束开发，story 约束实现。没有这条链路，智能体更容易在跨 story 时出现不一致决策。
|
||||
|
||||
### 项目上下文
|
||||
|
||||
:::tip[推荐]
|
||||
创建 `project-context.md` 以确保 AI 智能体遵循您项目的规则和偏好。该文件就像您项目的宪法——它指导所有工作流程中的实施决策。这个可选文件可以在架构创建结束时生成，或者在现有项目中也可以生成它，以捕捉与当前约定保持一致的重要内容。
|
||||
:::tip[Project Context 建议]
|
||||
创建 `project-context.md`，把项目特有约定（技术栈、命名、组织、测试策略）写成共享规则，能显著降低实现偏差。
|
||||
:::
|
||||
|
||||
**如何创建它：**
|
||||
**创建方式：**
|
||||
- **手动创建**：在 `_bmad-output/project-context.md` 记录项目规则
|
||||
- **自动生成**：运行 `bmad-generate-project-context` 从架构或代码库提取
|
||||
|
||||
- **手动** — 使用您的技术栈和实施规则创建 `_bmad-output/project-context.md`
|
||||
- **生成它** — 运行 `bmad-bmm-generate-project-context` 以从您的架构或代码库自动生成
|
||||
## 相关参考
|
||||
|
||||
[**了解更多关于 project-context.md**](../explanation/project-context.md)
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **BMad Method (BMM)**：BMad 方法。BMad 生态系统中的一个模块，用于上下文工程与规划。
|
||||
- **FRs/NFRs**：功能需求/非功能需求。Functional Requirements/Non-Functional Requirements 的缩写。
|
||||
- **PRD**：产品需求文档。Product Requirements Document 的缩写。
|
||||
- **UX**：用户体验。User Experience 的缩写。
|
||||
- **ADR**：架构决策记录。Architecture Decision Record 的缩写。
|
||||
- **Epic**：史诗。大型功能或用户故事的集合，通常需要多个冲刺才能完成。
|
||||
- **Story**：用户故事。描述用户需求的简短陈述。
|
||||
- **Sprint**：冲刺。敏捷开发中的固定时间周期，用于完成预定的工作。
|
||||
- **Slug**：短标识符。URL 友好的标识符，通常用于文件命名。
|
||||
- **Context**：上下文。为 AI 智能体提供的环境信息和背景资料。
|
||||
- [命令与技能参考](./commands.md)
|
||||
- [智能体参考](./agents.md)
|
||||
- [核心工具参考](./core-tools.md)
|
||||
- [项目上下文说明](../explanation/project-context.md)
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
title: 路线图
|
||||
description: BMad 的下一步计划——功能、改进与社区贡献
|
||||
description: BMad 后续方向：功能演进、体验优化与社区生态
|
||||
---
|
||||
|
||||
# BMad 方法：公开路线图
|
||||
# BMad Method 公开路线图
|
||||
|
||||
BMad 方法、BMad 方法模块（BMM）和 BMad 构建器（BMB）正在持续演进。以下是我们正在开展的工作以及即将推出的内容。
|
||||
BMad Method、BMM（Agile 套件）与 BMad Builder 正在持续迭代。以下内容用于说明当前重点与下一阶段规划。
|
||||
|
||||
<div class="roadmap-container">
|
||||
|
||||
|
|
@ -14,139 +14,123 @@ BMad 方法、BMad 方法模块（BMM）和 BMad 构建器（BMB）正在持续
|
|||
<div class="roadmap-future">
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">🧩</span>
|
||||
<h4>通用技能架构</h4>
|
||||
<p>一个技能，任意平台。一次编写，随处运行。</p>
|
||||
<h4>通用 Skills 架构</h4>
|
||||
<p>同一 skill 在不同平台复用，降低跨工具维护成本。</p>
|
||||
</div>
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">🏗️</span>
|
||||
<h4>BMad 构建器 v1</h4>
|
||||
<p>打造生产级 AI 智能体与工作流，内置评估、团队协作与优雅降级。</p>
|
||||
<h4>BMad Builder v1</h4>
|
||||
<p>面向生产场景的 agent/workflow 构建能力，覆盖评估、协作与优雅降级。</p>
|
||||
</div>
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">🧠</span>
|
||||
<h4>项目上下文系统</h4>
|
||||
<p>AI 真正理解你的项目。框架感知的上下文，随代码库共同演进。</p>
|
||||
<h4>Project Context 系统</h4>
|
||||
<p>让 AI 在项目约束内工作：上下文随代码库变化持续更新。</p>
|
||||
</div>
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">📦</span>
|
||||
<h4>集中式技能</h4>
|
||||
<p>一次安装，随处使用。跨项目共享技能，告别文件杂乱。</p>
|
||||
<h4>集中式 Skills</h4>
|
||||
<p>减少项目内重复拷贝，支持跨项目共享与统一管理。</p>
|
||||
</div>
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">🔄</span>
|
||||
<h4>自适应技能</h4>
|
||||
<p>技能懂你的工具。为 Claude、Codex、Kimi、OpenCode 等提供优化变体，以及更多。</p>
|
||||
<h4>自适应 Skills</h4>
|
||||
<p>针对 Claude、Codex、Kimi、OpenCode 等平台提供优化变体。</p>
|
||||
</div>
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">📝</span>
|
||||
<h4>BMad 团队专业博客</h4>
|
||||
<p>来自团队的指南、文章与见解。即将上线。</p>
|
||||
<h4>BMad 团队博客</h4>
|
||||
<p>持续发布实践文章、方法拆解与落地经验。</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<h2 class="roadmap-section-title">入门阶段</h2>
|
||||
<h2 class="roadmap-section-title">近期规划</h2>
|
||||
|
||||
<div class="roadmap-future">
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">🏪</span>
|
||||
<h4>技能市场</h4>
|
||||
<p>发现、安装与更新社区构建的技能。一条 curl 命令即可获得超能力。</p>
|
||||
<h4>Skill 市场</h4>
|
||||
<p>发现、安装、更新社区技能，缩短能力接入路径。</p>
|
||||
</div>
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">🎨</span>
|
||||
<h4>工作流定制</h4>
|
||||
<p>打造属于你的工作流。集成 Jira、Linear、自定义输出——你的工作流，你的规则。</p>
|
||||
<h4>Workflow 定制</h4>
|
||||
<p>支持 Jira、Linear 与自定义产出对接，构建团队专属流程。</p>
|
||||
</div>
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">🚀</span>
|
||||
<h4>阶段 1-3 优化</h4>
|
||||
<p>通过子智能体上下文收集实现闪电般快速的规划。YOLO 模式遇上引导式卓越。</p>
|
||||
<p>通过子智能体上下文采集提升前期分析与规划效率。</p>
|
||||
</div>
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">🌐</span>
|
||||
<h4>企业级就绪</h4>
|
||||
<p>SSO、审计日志、团队工作空间。那些让企业点头同意的无聊但必要的东西。</p>
|
||||
<h4>企业级能力完善</h4>
|
||||
<p>补齐 SSO、审计日志、团队工作区等企业落地基础能力。</p>
|
||||
</div>
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">💎</span>
|
||||
<h4>社区模块爆发</h4>
|
||||
<p>娱乐、安全、治疗、角色扮演以及更多内容。扩展 BMad 方法平台。</p>
|
||||
<h4>社区模块扩展</h4>
|
||||
<p>覆盖更多垂直场景，持续扩展 BMad 模块生态。</p>
|
||||
</div>
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">⚡</span>
|
||||
<h4>开发循环自动化</h4>
|
||||
<p>可选的开发自动驾驶。让 AI 处理流程，同时保持质量高企。</p>
|
||||
<p>在可控质量边界内提升自动化程度，减少重复人工操作。</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<h2 class="roadmap-section-title">社区与团队</h2>
|
||||
<h2 class="roadmap-section-title">社区与团队计划</h2>
|
||||
|
||||
<div class="roadmap-future">
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">🎙️</span>
|
||||
<h4>BMad 方法播客</h4>
|
||||
<p>关于 AI 原生开发的对话。2026 年 3 月 1 日上线！</p>
|
||||
<h4>BMad Method 播客</h4>
|
||||
<p>围绕 AI 原生研发方法开展持续讨论与案例分享。</p>
|
||||
</div>
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">🎓</span>
|
||||
<h4>BMad 方法大师课</h4>
|
||||
<p>从用户到专家。深入每个阶段、每个工作流、每个秘密。</p>
|
||||
<h4>BMad Method 大师课</h4>
|
||||
<p>面向进阶用户，系统拆解各阶段与核心 workflow。</p>
|
||||
</div>
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">🏗️</span>
|
||||
<h4>BMad 构建器大师课</h4>
|
||||
<p>构建你自己的智能体。当你准备好创造而不仅仅是使用时的高级技巧。</p>
|
||||
<h4>BMad Builder 大师课</h4>
|
||||
<p>聚焦自定义 agent/workflow 的高级设计与工程实践。</p>
|
||||
</div>
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">⚡</span>
|
||||
<h4>BMad 原型优先</h4>
|
||||
<p>一次会话从想法到可用原型。像创作艺术品一样打造你的梦想应用。</p>
|
||||
<h4>BMad Prototype First</h4>
|
||||
<p>探索“单会话从想法到原型”的端到端实践路径。</p>
|
||||
</div>
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">🌴</span>
|
||||
<h4>BMad BALM！</h4>
|
||||
<p>AI 原生的生活管理。任务、习惯、目标——你的 AI 副驾驶，无处不在。</p>
|
||||
<h4>BMad BALM</h4>
|
||||
<p>将 AI 原生协作模式扩展到个人任务、习惯与目标管理。</p>
|
||||
</div>
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">🖥️</span>
|
||||
<h4>官方 UI</h4>
|
||||
<p>整个 BMad 生态系统的精美界面。CLI 的强大，GUI 的精致。</p>
|
||||
<p>在保留 CLI 能力的基础上提供完整图形化操作体验。</p>
|
||||
</div>
|
||||
<div class="roadmap-future-card">
|
||||
<span class="roadmap-emoji">🔒</span>
|
||||
<h4>BMad 一体机</h4>
|
||||
<p>自托管、气隙隔离、企业级。你的 AI 助手、你的基础设施、你的控制。</p>
|
||||
<h4>BMad in a Box</h4>
|
||||
<p>面向自托管与气隙隔离场景的企业级部署方案。</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div style="text-align: center; margin-top: 3rem; padding: 2rem; background: var(--color-bg-card); border-radius: 12px; border: 1px solid var(--color-border);">
|
||||
<h3 style="margin: 0 0 1rem;">想要贡献？</h3>
|
||||
<h3 style="margin: 0 0 1rem;">欢迎参与贡献</h3>
|
||||
<p style="color: var(--slate-color-400); margin: 0;">
|
||||
这只是计划内容的一部分。BMad 开源团队欢迎贡献者！{" "}<br />
|
||||
<a href="https://github.com/bmad-code-org/BMAD-METHOD" style="color: var(--color-in-progress);">在 GitHub 上加入我们</a>，共同塑造 AI 驱动开发的未来。
|
||||
以上并非全部规划。BMad 开源团队欢迎贡献者加入。{" "}<br />
|
||||
前往 <a href="https://github.com/bmad-code-org/BMAD-METHOD" style="color: var(--color-in-progress);">GitHub 仓库</a> 参与共建。
|
||||
</p>
|
||||
<p style="color: var(--slate-color-400); margin: 1.5rem 0 0;">
|
||||
喜欢我们正在构建的东西？我们感谢一次性与月度{" "}<a href="https://buymeacoffee.com/bmad" style="color: var(--color-in-progress);">支持</a>。
|
||||
如果你认可项目方向，也欢迎通过{" "}<a href="https://buymeacoffee.com/bmad" style="color: var(--color-in-progress);">支持渠道</a> 帮助我们持续迭代。
|
||||
</p>
|
||||
<p style="color: var(--slate-color-400); margin: 1rem 0 0;">
|
||||
如需企业赞助、合作咨询、演讲邀请、培训或媒体咨询：{" "}
|
||||
企业赞助、合作咨询、培训与媒体联系：{" "}
|
||||
<a href="mailto:contact@bmadcode.com" style="color: var(--color-in-progress);">contact@bmadcode.com</a>
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **SSO**：单点登录。一种用户认证机制，允许用户使用一组凭据访问多个应用程序。
|
||||
- **air-gapped**：气隙隔离。指系统与外部网络完全物理隔离的安全措施。
|
||||
- **YOLO**：You Only Live Once 的缩写，此处指快速、大胆的执行模式。
|
||||
- **evals**：评估。对 AI 模型或智能体性能的测试与评价。
|
||||
- **graceful degradation**：优雅降级。系统在部分功能失效时仍能保持基本功能的特性。
|
||||
- **sub-agent**：子智能体。在主智能体协调下执行特定任务的辅助智能体。
|
||||
- **context**：上下文。AI 理解任务所需的相关信息与环境背景。
|
||||
- **workflow**：工作流。一系列有序的任务或操作流程。
|
||||
- **skills**：技能。AI 智能体可执行的具体能力或功能模块。
|
||||
- **CLI**：命令行界面。通过文本命令与计算机交互的方式。
|
||||
- **GUI**：图形用户界面。通过图形元素与计算机交互的方式。
|
||||
|
|
|
|||
|
|
@ -37,13 +37,13 @@ description: 安装 BMad 并构建你的第一个项目
|
|||
|
||||
### 如何使用 BMad-Help
|
||||
|
||||
只需在 AI IDE 中使用斜杠命令运行它：
|
||||
在你的 AI IDE 中直接调用技能名：
|
||||
|
||||
```
|
||||
bmad-help
|
||||
```
|
||||
|
||||
或者结合问题以获得上下文感知的指导：
|
||||
也可以带着问题一起调用，获得更贴合上下文的建议：
|
||||
|
||||
```
|
||||
bmad-help 我有一个 SaaS 产品的想法，我已经知道我想要的所有功能。我应该从哪里开始？
|
||||
|
|
@ -70,7 +70,7 @@ BMad 通过带有专门 AI 智能体的引导工作流帮助你构建软件。
|
|||
| ---- | -------------- | -------------------------------------------------- |
|
||||
| 1 | 分析 | 头脑风暴、研究、产品简报 *（可选）* |
|
||||
| 2 | 规划 | 创建需求（PRD 或技术规范） |
|
||||
| 3 | 解决方案设计 | 设计架构 *（仅限 BMad Method/Enterprise only）* |
|
||||
| 3 | 解决方案设计 | 设计架构 *（仅适用于 BMad Method/Enterprise）* |
|
||||
| 4 | 实现 | 逐个史诗、逐个故事地构建 |
|
||||
|
||||
**[打开工作流地图](../reference/workflow-map.md)** 以探索阶段、工作流和上下文管理。
|
||||
|
|
@ -95,6 +95,8 @@ BMad 通过带有专门 AI 智能体的引导工作流帮助你构建软件。
|
|||
npx bmad-method install
|
||||
```
|
||||
|
||||
如果你想使用最新预发布版本（而不是默认发布通道），可以改用 `npx bmad-method@next install`。
|
||||
|
||||
当提示选择模块时，选择 **BMad Method**。
|
||||
|
||||
安装程序会创建两个文件夹：
|
||||
|
|
@ -112,7 +114,7 @@ BMad-Help 将检测你已完成的内容，并准确推荐下一步该做什么
|
|||
:::
|
||||
|
||||
:::note[如何加载智能体和运行工作流]
|
||||
每个工作流都有一个你在 IDE 中运行的**斜杠命令**（例如 `bmad-bmm-create-prd`）。运行工作流命令会自动加载相应的智能体 —— 你不需要单独加载智能体。你也可以直接加载智能体进行一般对话（例如，加载 PM 智能体使用 `bmad-agent-bmm-pm`）。
|
||||
每个工作流都可以通过技能名直接调用（例如 `bmad-create-prd`）。你的 AI IDE 会识别 `bmad-*` 技能并执行，无需额外单独加载智能体。你也可以直接调用智能体技能进行通用对话（例如 PM 智能体用 `bmad-agent-pm`）。
|
||||
:::
|
||||
|
||||
:::caution[新对话]
|
||||
|
|
@ -126,35 +128,35 @@ BMad-Help 将检测你已完成的内容，并准确推荐下一步该做什么
|
|||
:::tip[项目上下文（可选）]
|
||||
在开始之前，考虑创建 `project-context.md` 来记录你的技术偏好和实现规则。这确保所有 AI 智能体在整个项目中遵循你的约定。
|
||||
|
||||
在 `_bmad-output/project-context.md` 手动创建它，或在架构之后使用 `bmad-bmm-generate-project-context` 生成它。[了解更多](../explanation/project-context.md)。
|
||||
在 `_bmad-output/project-context.md` 手动创建它，或在架构之后使用 `bmad-generate-project-context` 生成它。[了解更多](../explanation/project-context.md)。
|
||||
:::
|
||||
|
||||
### 阶段 1：分析（可选）
|
||||
|
||||
此阶段中的所有工作流都是可选的：
|
||||
- **头脑风暴**（`bmad-brainstorming`） — 引导式构思
|
||||
- **研究**（`bmad-bmm-research`） — 市场和技术研究
|
||||
- **创建产品简报**（`bmad-bmm-create-product-brief`） — 推荐的基础文档
|
||||
- **研究**（`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`） — 市场、领域和技术研究
|
||||
- **创建产品简报**（`bmad-create-product-brief`） — 推荐的基础文档
|
||||
|
||||
### 阶段 2：规划（必需）
|
||||
|
||||
**对于 BMad Method 和 Enterprise 路径：**
|
||||
1. 在新对话中加载 **PM 智能体**（`bmad-agent-bmm-pm`）
|
||||
2. 运行 `prd` 工作流（`bmad-bmm-create-prd`）
|
||||
1. 在新对话中调用 **PM 智能体**（`bmad-agent-pm`）
|
||||
2. 运行 `bmad-create-prd` 工作流（`bmad-create-prd`）
|
||||
3. 输出：`PRD.md`
|
||||
|
||||
**对于 Quick Flow 路径：**
|
||||
- 运行 `bmad-bmm-quick-dev` — 它在单个工作流中处理规划和实现，跳转到实现
|
||||
- 运行 `bmad-quick-dev` —— 它会在一个工作流里同时处理规划与实现，可直接进入实现阶段
|
||||
|
||||
:::note[UX 设计（可选）]
|
||||
如果你的项目有用户界面，在创建 PRD 后加载 **UX-Designer 智能体**（`bmad-agent-bmm-ux-designer`）并运行 UX 设计工作流（`bmad-bmm-create-ux-design`）。
|
||||
如果你的项目有用户界面，在创建 PRD 后调用 **UX-Designer 智能体**（`bmad-agent-ux-designer`），然后运行 UX 设计工作流（`bmad-create-ux-design`）。
|
||||
:::
|
||||
|
||||
### 阶段 3：解决方案设计（BMad Method/Enterprise）
|
||||
|
||||
**创建架构**
|
||||
1. 在新对话中加载 **Architect 智能体**（`bmad-agent-bmm-architect`）
|
||||
2. 运行 `create-architecture`（`bmad-bmm-create-architecture`）
|
||||
1. 在新对话中调用 **Architect 智能体**（`bmad-agent-architect`）
|
||||
2. 运行 `bmad-create-architecture`（`bmad-create-architecture`）
|
||||
3. 输出：包含技术决策的架构文档
|
||||
|
||||
**创建史诗和故事**
|
||||
|
|
@ -163,13 +165,13 @@ BMad-Help 将检测你已完成的内容，并准确推荐下一步该做什么
|
|||
史诗和故事现在在架构*之后*创建。这会产生更高质量的故事，因为架构决策（数据库、API 模式、技术栈）直接影响工作应该如何分解。
|
||||
:::
|
||||
|
||||
1. 在新对话中加载 **PM 智能体**（`bmad-agent-bmm-pm`）
|
||||
2. 运行 `create-epics-and-stories`（`bmad-bmm-create-epics-and-stories`）
|
||||
1. 在新对话中调用 **PM 智能体**（`bmad-agent-pm`）
|
||||
2. 运行 `bmad-create-epics-and-stories`（`bmad-create-epics-and-stories`）
|
||||
3. 工作流使用 PRD 和架构来创建技术信息丰富的故事
|
||||
|
||||
**实现就绪检查** *（强烈推荐）*
|
||||
1. 在新对话中加载 **Architect 智能体**（`bmad-agent-bmm-architect`）
|
||||
2. 运行 `check-implementation-readiness`（`bmad-bmm-check-implementation-readiness`）
|
||||
1. 在新对话中调用 **Architect 智能体**（`bmad-agent-architect`）
|
||||
2. 运行 `bmad-check-implementation-readiness`（`bmad-check-implementation-readiness`）
|
||||
3. 验证所有规划文档之间的一致性
|
||||
|
||||
## 步骤 2：构建你的项目
|
||||
|
|
@ -178,7 +180,7 @@ BMad-Help 将检测你已完成的内容，并准确推荐下一步该做什么
|
|||
|
||||
### 初始化冲刺规划
|
||||
|
||||
加载 **SM 智能体**（`bmad-agent-bmm-sm`）并运行 `sprint-planning`（`bmad-bmm-sprint-planning`）。这将创建 `sprint-status.yaml` 来跟踪所有史诗和故事。
|
||||
调用 **SM 智能体**（`bmad-agent-sm`）并运行 `bmad-sprint-planning`（`bmad-sprint-planning`）。这会创建 `sprint-status.yaml` 来跟踪所有史诗和故事。
|
||||
|
||||
### 构建周期
|
||||
|
||||
|
|
@ -186,11 +188,11 @@ BMad-Help 将检测你已完成的内容，并准确推荐下一步该做什么
|
|||
|
||||
| 步骤 | 智能体 | 工作流 | 命令 | 目的 |
|
||||
| ---- | ------ | ------------ | ----------------------- | ------------------------------- |
|
||||
| 1 | SM | `create-story` | `bmad-bmm-create-story` | 从史诗创建故事文件 |
|
||||
| 2 | DEV | `dev-story` | `bmad-bmm-dev-story` | 实现故事 |
|
||||
| 3 | DEV | `code-review` | `bmad-bmm-code-review` | 质量验证 *（推荐）* |
|
||||
| 1 | SM | `bmad-create-story` | `bmad-create-story` | 从史诗创建故事文件 |
|
||||
| 2 | DEV | `bmad-dev-story` | `bmad-dev-story` | 实现故事 |
|
||||
| 3 | DEV | `bmad-code-review` | `bmad-code-review` | 质量验证 *（推荐）* |
|
||||
|
||||
完成史诗中的所有故事后，加载 **SM 智能体**（`bmad-agent-bmm-sm`）并运行 `retrospective`（`bmad-bmm-retrospective`）。
|
||||
完成史诗中的所有故事后，调用 **SM 智能体**（`bmad-agent-sm`）并运行 `bmad-retrospective`（`bmad-retrospective`）。
|
||||
|
||||
## 你已完成的工作
|
||||
|
||||
|
|
@ -221,16 +223,16 @@ your-project/
|
|||
|
||||
| 工作流 | 命令 | 智能体 | 目的 |
|
||||
| ----------------------------------- | --------------------------------------- | -------- | -------------------------------------------- |
|
||||
| **`help`** ⭐ | `bmad-help` | 任意 | **你的智能向导 —— 随时询问任何问题！** |
|
||||
| `prd` | `bmad-bmm-create-prd` | PM | 创建产品需求文档 |
|
||||
| `create-architecture` | `bmad-bmm-create-architecture` | Architect | 创建架构文档 |
|
||||
| `generate-project-context` | `bmad-bmm-generate-project-context` | Analyst | 创建项目上下文文件 |
|
||||
| `create-epics-and-stories` | `bmad-bmm-create-epics-and-stories` | PM | 将 PRD 分解为史诗 |
|
||||
| `check-implementation-readiness` | `bmad-bmm-check-implementation-readiness` | Architect | 验证规划一致性 |
|
||||
| `sprint-planning` | `bmad-bmm-sprint-planning` | SM | 初始化冲刺跟踪 |
|
||||
| `create-story` | `bmad-bmm-create-story` | SM | 创建故事文件 |
|
||||
| `dev-story` | `bmad-bmm-dev-story` | DEV | 实现故事 |
|
||||
| `code-review` | `bmad-bmm-code-review` | DEV | 审查已实现的代码 |
|
||||
| **`bmad-help`** ⭐ | `bmad-help` | 任意 | **你的智能向导 —— 随时询问任何问题！** |
|
||||
| `bmad-create-prd` | `bmad-create-prd` | PM | 创建产品需求文档 |
|
||||
| `bmad-create-architecture` | `bmad-create-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 | 验证规划一致性 |
|
||||
| `bmad-sprint-planning` | `bmad-sprint-planning` | SM | 初始化冲刺跟踪 |
|
||||
| `bmad-create-story` | `bmad-create-story` | SM | 创建故事文件 |
|
||||
| `bmad-dev-story` | `bmad-dev-story` | DEV | 实现故事 |
|
||||
| `bmad-code-review` | `bmad-code-review` | DEV | 审查已实现的代码 |
|
||||
|
||||
## 常见问题
|
||||
|
||||
|
|
@ -238,10 +240,10 @@ your-project/
|
|||
仅对于 BMad Method 和 Enterprise 路径。Quick Flow 从技术规范跳转到实现。
|
||||
|
||||
**我可以稍后更改我的计划吗？**
|
||||
可以。SM 智能体有一个 `correct-course` 工作流（`bmad-bmm-correct-course`）用于处理范围变更。
|
||||
可以。SM 智能体提供 `bmad-correct-course` 工作流（`bmad-correct-course`）来处理范围变化。
|
||||
|
||||
**如果我想先进行头脑风暴怎么办？**
|
||||
在开始 PRD 之前，加载 Analyst 智能体（`bmad-agent-bmm-analyst`）并运行 `brainstorming`（`bmad-brainstorming`）。
|
||||
在开始 PRD 之前，调用 Analyst 智能体（`bmad-agent-analyst`）并运行 `bmad-brainstorming`（`bmad-brainstorming`）。
|
||||
|
||||
**我需要遵循严格的顺序吗？**
|
||||
不一定。一旦你了解了流程，你可以使用上面的快速参考直接运行工作流。
|
||||
|
|
@ -271,30 +273,3 @@ BMad-Help 检查你的项目，检测你已完成的内容，并确切地告诉
|
|||
:::
|
||||
|
||||
准备好开始了吗？安装 BMad，运行 `bmad-help`，让你的智能向导为你引路。
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **epic**：史诗。软件开发中用于组织和管理大型功能或用户需求的高级工作项。
|
||||
- **story**：故事。敏捷开发中的用户故事，描述用户需求的小型工作项。
|
||||
- **PRD**：产品需求文档（Product Requirements Document）。详细描述产品功能、需求和目标的文档。
|
||||
- **workflow**：工作流。一系列有序的任务或步骤，用于完成特定目标。
|
||||
- **sprint**：冲刺。敏捷开发中的固定时间周期，用于完成预定的工作。
|
||||
- **IDE**：集成开发环境（Integrated Development Environment）。提供代码编辑、调试等功能的软件工具。
|
||||
- **artifact**：工件。软件开发过程中产生的文档、代码或其他可交付成果。
|
||||
- **retrospective**：回顾。敏捷开发中的会议，用于反思和改进团队工作流程。
|
||||
- **tech-spec**：技术规范（Technical Specification）。描述系统技术实现细节的文档。
|
||||
- **UX**：用户体验（User Experience）。用户在使用产品过程中的整体感受和交互体验。
|
||||
- **PM**：产品经理（Product Manager）。负责产品规划、需求管理和团队协调的角色。
|
||||
- **SM**：Scrum Master。敏捷开发中的角色，负责促进 Scrum 流程和团队协作。
|
||||
- **DEV**：开发者（Developer）。负责编写代码和实现功能的角色。
|
||||
- **Architect**：架构师。负责系统架构设计和技术决策的角色。
|
||||
- **Analyst**：分析师。负责需求分析、市场研究等工作的角色。
|
||||
- **npx**：Node Package eXecute。Node.js 包执行器，用于运行 npm 包而无需安装。
|
||||
- **Node.js**：基于 Chrome V8 引擎的 JavaScript 运行时环境。
|
||||
- **Git**：分布式版本控制系统。
|
||||
- **SaaS**：软件即服务（Software as a Service）。通过互联网提供软件服务的模式。
|
||||
- **DevOps**：开发运维（Development and Operations）。强调开发和运维协作的实践和方法。
|
||||
- **multi-tenant**：多租户。一种软件架构，允许单个实例为多个客户（租户）提供服务。
|
||||
- **compliance**：合规性。遵守法律、法规和行业标准的要求。
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
{
|
||||
"name": "bmad-method",
|
||||
"version": "6.2.0",
|
||||
"version": "6.2.1",
|
||||
"lockfileVersion": 3,
|
||||
"requires": true,
|
||||
"packages": {
|
||||
"": {
|
||||
"name": "bmad-method",
|
||||
"version": "6.2.0",
|
||||
"version": "6.2.1",
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"@clack/core": "^1.0.0",
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
{
|
||||
"$schema": "https://json.schemastore.org/package.json",
|
||||
"name": "bmad-method",
|
||||
"version": "6.2.0",
|
||||
"version": "6.2.1",
|
||||
"description": "Breakthrough Method of Agile AI-driven Development",
|
||||
"keywords": [
|
||||
"agile",
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
type: skill
|
||||
type: agent
|
||||
name: bmad-agent-analyst
|
||||
displayName: Mary
|
||||
title: Business Analyst
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
type: skill
|
||||
type: agent
|
||||
name: bmad-agent-tech-writer
|
||||
displayName: Paige
|
||||
title: Technical Writer
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
type: skill
|
||||
type: agent
|
||||
name: bmad-agent-pm
|
||||
displayName: John
|
||||
title: Product Manager
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
type: skill
|
||||
type: agent
|
||||
name: bmad-agent-ux-designer
|
||||
displayName: Sally
|
||||
title: UX Designer
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
type: skill
|
||||
type: agent
|
||||
name: bmad-agent-architect
|
||||
displayName: Winston
|
||||
title: Architect
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
type: skill
|
||||
type: agent
|
||||
name: bmad-agent-dev
|
||||
displayName: Amelia
|
||||
title: Developer Agent
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
type: skill
|
||||
type: agent
|
||||
name: bmad-agent-qa
|
||||
displayName: Quinn
|
||||
title: QA Engineer
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
type: skill
|
||||
type: agent
|
||||
name: bmad-agent-quick-flow-solo-dev
|
||||
displayName: Barry
|
||||
title: Quick Flow Solo Dev
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
type: skill
|
||||
type: agent
|
||||
name: bmad-agent-sm
|
||||
displayName: Bob
|
||||
title: Scrum Master
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -36,7 +36,7 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
|||
| Epics | `{planning_artifacts}/*epic*.md` (whole) or `{planning_artifacts}/*epic*/*.md` (sharded) | FULL_LOAD |
|
||||
| Architecture | `{planning_artifacts}/*architecture*.md` (whole) or `{planning_artifacts}/*architecture*/*.md` (sharded) | FULL_LOAD |
|
||||
| UX Design | `{planning_artifacts}/*ux*.md` (whole) or `{planning_artifacts}/*ux*/*.md` (sharded) | FULL_LOAD |
|
||||
| Tech Spec | `{planning_artifacts}/*tech-spec*.md` (whole) | FULL_LOAD |
|
||||
| Spec | `{planning_artifacts}/*spec-*.md` (whole) | FULL_LOAD |
|
||||
| Document Project | `{project_knowledge}/index.md` (sharded) | INDEX_GUIDED |
|
||||
|
||||
### Context
|
||||
|
|
@ -51,9 +51,9 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
|||
|
||||
**Strategy**: Course correction needs broad project context to assess change impact accurately. Load all available planning artifacts.
|
||||
|
||||
**Discovery Process for FULL_LOAD documents (PRD, Epics, Architecture, UX Design, Tech Spec):**
|
||||
**Discovery Process for FULL_LOAD documents (PRD, Epics, Architecture, UX Design, Spec):**
|
||||
|
||||
1. **Search for whole document first** - Look for files matching the whole-document pattern (e.g., `*prd*.md`, `*epic*.md`, `*architecture*.md`, `*ux*.md`, `*tech-spec*.md`)
|
||||
1. **Search for whole document first** - Look for files matching the whole-document pattern (e.g., `*prd*.md`, `*epic*.md`, `*architecture*.md`, `*ux*.md`, `*spec-*.md`)
|
||||
2. **Check for sharded version** - If whole document not found, look for a directory with `index.md` (e.g., `prd/index.md`, `epics/index.md`)
|
||||
3. **If sharded version found**:
|
||||
- Read `index.md` to understand the document structure
|
||||
|
|
@ -70,7 +70,7 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
|||
|
||||
**Fuzzy matching**: Be flexible with document names — users may use variations like `prd.md`, `bmm-prd.md`, `product-requirements.md`, etc.
|
||||
|
||||
**Missing documents**: Not all documents may exist. PRD and Epics are essential; Architecture, UX Design, Tech Spec, and Document Project are loaded if available. HALT if PRD or Epics cannot be found.
|
||||
**Missing documents**: Not all documents may exist. PRD and Epics are essential; Architecture, UX Design, Spec, and Document Project are loaded if available. HALT if PRD or Epics cannot be found.
|
||||
|
||||
<workflow>
|
||||
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -11,8 +11,6 @@ context: [] # optional: max 3 project-wide standards/docs. NO source code files.
|
|||
Cohesive cross-layer stories (DB+BE+UI) stay in ONE file.
|
||||
IMPORTANT: Remove all HTML comments when filling this template. -->
|
||||
|
||||
# {title}
|
||||
|
||||
<frozen-after-approval reason="human-owned intent — do not modify unless human renegotiates">
|
||||
|
||||
## Intent
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
wipFile: '{implementation_artifacts}/tech-spec-wip.md'
|
||||
wipFile: '{implementation_artifacts}/spec-wip.md'
|
||||
deferred_work_file: '{implementation_artifacts}/deferred-work.md'
|
||||
spec_file: '' # set at runtime for plan-code-review before leaving this step
|
||||
---
|
||||
|
|
@ -15,13 +15,27 @@ spec_file: '' # set at runtime for plan-code-review before leaving this step
|
|||
- The user chose this workflow on purpose. Later steps (e.g. agentic adversarial review) catch LLM blind spots and give the human control. Do not skip them.
|
||||
- **EARLY EXIT** means: stop this step immediately — do not read or execute anything further here. Read and fully follow the target file instead. Return here ONLY if a later step explicitly says to loop back.
|
||||
|
||||
## ARTIFACT SCAN
|
||||
## Intent check (do this first)
|
||||
|
||||
- `{wipFile}` exists? → Offer resume or archive.
|
||||
- Active specs (`ready-for-dev`, `in-progress`, `in-review`) in `{implementation_artifacts}`? → List them and HALT. Ask user which to resume (or `[N]` for new).
|
||||
- If `ready-for-dev` or `in-progress` selected: Set `spec_file`. **EARLY EXIT** → `./step-03-implement.md`
|
||||
- If `in-review` selected: Set `spec_file`. **EARLY EXIT** → `./step-04-review.md`
|
||||
- Unformatted spec or intent file lacking `status` frontmatter in `{implementation_artifacts}`? → Suggest to the user to treat its contents as the starting intent for this workflow. DO NOT attempt to infer a state and resume it.
|
||||
Before listing artifacts or prompting the user, check whether you already know the intent. Check in this order — skip the remaining checks as soon as the intent is clear:
|
||||
|
||||
1. Explicit argument
|
||||
Did the user pass a specific file path, spec name, or clear instruction this message?
|
||||
- If it points to a file that matches the spec template (has `status` frontmatter with a recognized value: ready-for-dev, in-progress, or in-review) → set `spec_file` and **EARLY EXIT** to the appropriate step (step-03 for ready/in-progress, step-04 for review).
|
||||
- Anything else (intent files, external docs, plans, descriptions) → ingest it as starting intent and proceed to INSTRUCTIONS. Do not attempt to infer a workflow state from it.
|
||||
|
||||
2. Recent conversation
|
||||
Do the last few human messages clearly show what the user intends to work on?
|
||||
Use the same routing as above.
|
||||
|
||||
3. Otherwise — scan artifacts and ask
|
||||
- `{wipFile}` exists? → Offer resume or archive.
|
||||
- Active specs (`ready-for-dev`, `in-progress`, `in-review`) in `{implementation_artifacts}`? → List them and HALT. Ask user which to resume (or `[N]` for new).
|
||||
- If `ready-for-dev` or `in-progress` selected: Set `spec_file`. **EARLY EXIT** → `./step-03-implement.md`
|
||||
- If `in-review` selected: Set `spec_file`. **EARLY EXIT** → `./step-04-review.md`
|
||||
- Unformatted spec or intent file lacking `status` frontmatter? → Suggest treating its contents as the starting intent. Do NOT attempt to infer a state and resume it.
|
||||
|
||||
Never ask extra questions if you already understand what the user intends.
|
||||
|
||||
## INSTRUCTIONS
|
||||
|
||||
|
|
@ -42,7 +56,7 @@ spec_file: '' # set at runtime for plan-code-review before leaving this step
|
|||
**EARLY EXIT** → `./step-oneshot.md`
|
||||
|
||||
**b) Plan-code-review** — everything else. When uncertain whether blast radius is truly zero, choose this path.
|
||||
1. Derive a valid kebab-case slug from the clarified intent. If `{implementation_artifacts}/tech-spec-{slug}.md` already exists, append `-2`, `-3`, etc. Set `spec_file` = `{implementation_artifacts}/tech-spec-{slug}.md`.
|
||||
1. Derive a valid kebab-case slug from the clarified intent. If the intent references a tracking identifier (story number, issue number, ticket ID), lead the slug with it (e.g. `3-2-digest-delivery`, `gh-47-fix-auth`). If `{implementation_artifacts}/spec-{slug}.md` already exists, append `-2`, `-3`, etc. Set `spec_file` = `{implementation_artifacts}/spec-{slug}.md`.
|
||||
|
||||
|
||||
## NEXT
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
wipFile: '{implementation_artifacts}/tech-spec-wip.md'
|
||||
wipFile: '{implementation_artifacts}/spec-wip.md'
|
||||
deferred_work_file: '{implementation_artifacts}/deferred-work.md'
|
||||
---
|
||||
|
||||
|
|
@ -13,7 +13,7 @@ deferred_work_file: '{implementation_artifacts}/deferred-work.md'
|
|||
## INSTRUCTIONS
|
||||
|
||||
1. Investigate codebase. _Isolate deep exploration in sub-agents/tasks where available. To prevent context snowballing, instruct subagents to give you distilled summaries only._
|
||||
2. Read `./tech-spec-template.md` fully. Fill it out based on the intent and investigation, and write the result to `{wipFile}`.
|
||||
2. Read `./spec-template.md` fully. Fill it out based on the intent and investigation, and write the result to `{wipFile}`.
|
||||
3. Self-review against READY FOR DEVELOPMENT standard.
|
||||
4. If intent gaps exist, do not fantasize, do not leave open questions, HALT and ask the human.
|
||||
5. Token count check (see SCOPE STANDARD). If spec exceeds 1600 tokens:
|
||||
|
|
|
|||
|
|
@ -26,6 +26,12 @@ Change `{spec_file}` status to `in-progress` in the frontmatter before starting
|
|||
|
||||
Hand `{spec_file}` to a sub-agent/task and let it implement. If no sub-agents are available, implement directly.
|
||||
|
||||
**Path formatting rule:** Any markdown links written into `{spec_file}` must use paths relative to `{spec_file}`'s directory so they are clickable in VS Code. Any file paths displayed in terminal/conversation output must use CWD-relative format with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability. No leading `/` in either case.
|
||||
|
||||
### Self-Check
|
||||
|
||||
Before leaving this step, verify every task in the `## Tasks & Acceptance` section of `{spec_file}` is complete. Mark each finished task `[x]`. If any task is not done, finish it before proceeding.
|
||||
|
||||
## NEXT
|
||||
|
||||
Read fully and follow `./step-04-review.md`
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Build the trail as an ordered sequence of **stops** — clickable `path:line` re
|
|||
2. **Lead with the entry point** — the single highest-leverage file:line a reviewer should look at first to grasp the design intent.
|
||||
3. **Inside each concern**, order stops from most important / architecturally interesting to supporting. Lightly bias toward higher-risk or boundary-crossing stops.
|
||||
4. **End with peripherals** — tests, config, types, and other supporting changes come last.
|
||||
5. **Every code reference is a clickable workspace-relative link** (project-root-relative for clickability in the editor). Format each stop as a markdown link: `[short-name:line](/project-root-relative/path/to/file.ts#L42)`. The link target uses a leading `/` (workspace root) with a `#L` line anchor. Use the file's basename (or shortest unambiguous suffix) plus line number as the link text.
|
||||
5. **Every code reference is a clickable spec-file-relative link.** Compute each link target as a relative path from `{spec_file}`'s directory to the changed file. Format each stop as a markdown link: `[short-name:line](../../path/to/file.ts#L42)`. Use a `#L` line anchor. Use the file's basename (or shortest unambiguous suffix) plus line number as the link text. The relative path must be dynamically derived — never hardcode the depth.
|
||||
6. **Each stop gets one ultra-concise line of framing** (≤15 words) — why this approach was chosen here and what it achieves in the context of the change. No paragraphs.
|
||||
|
||||
Format each stop as framing first, link on the next indented line:
|
||||
|
|
@ -33,17 +33,19 @@ Format each stop as framing first, link on the next indented line:
|
|||
**{Concern name}**
|
||||
|
||||
- {one-line framing}
|
||||
[`file.ts:42`](/src/path/to/file.ts#L42)
|
||||
[`file.ts:42`](../../src/path/to/file.ts#L42)
|
||||
|
||||
- {one-line framing}
|
||||
[`other.ts:17`](/src/path/to/other.ts#L17)
|
||||
[`other.ts:17`](../../src/path/to/other.ts#L17)
|
||||
|
||||
**{Next concern}**
|
||||
|
||||
- {one-line framing}
|
||||
[`file.ts:88`](/src/path/to/file.ts#L88)
|
||||
[`file.ts:88`](../../src/path/to/file.ts#L88)
|
||||
```
|
||||
|
||||
> The `../../` prefix above is illustrative — compute the actual relative path from `{spec_file}`'s directory to each target file.
|
||||
|
||||
When there is only one concern, omit the bold label — just list the stops directly.
|
||||
|
||||
### Commit and Present
|
||||
|
|
@ -51,9 +53,9 @@ When there is only one concern, omit the bold label — just list the stops dire
|
|||
1. Change `{spec_file}` status to `done` in the frontmatter.
|
||||
2. If version control is available and the tree is dirty, create a local commit with a conventional message derived from the spec title.
|
||||
3. Open the spec in the user's editor so they can click through the Suggested Review Order:
|
||||
- Run `code -r "{spec_file}"` to open the spec in the current VS Code window (reuses the window where the project or worktree is open). Always double-quote the path to handle spaces and special characters.
|
||||
- Resolve two absolute paths: (1) the repository root (`git rev-parse --show-toplevel` — returns the worktree root when in a worktree, project root otherwise; if this fails, fall back to the current working directory), (2) `{spec_file}`. Run `code -r "{absolute-root}" "{absolute-spec-file}"` — the root first so VS Code opens in the right context, then the spec file. Always double-quote paths to handle spaces and special characters.
|
||||
- If `code` is not available (command fails), skip gracefully and tell the user the spec file path instead.
|
||||
4. Display summary of your work to the user, including the commit hash if one was created. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) for terminal clickability — this differs from spec-file links which use project-root-relative paths. Include:
|
||||
4. Display summary of your work to the user, including the commit hash if one was created. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability — the goal is to make paths clickable in terminal emulators. Include:
|
||||
- A note that the spec is open in their editor (or the file path if it couldn't be opened). Mention that `{spec_file}` now contains a Suggested Review Order.
|
||||
- **Navigation tip:** "Ctrl+click (Cmd+click on macOS) the links in the Suggested Review Order to jump to each stop."
|
||||
- Offer to push and/or create a pull request.
|
||||
|
|
|
|||
|
|
@ -36,11 +36,11 @@ If version control is available and the tree is dirty, create a local commit wit
|
|||
### Present
|
||||
|
||||
1. Open all changed files in the user's editor so they can review the code directly:
|
||||
- Run `code -r "{project-root}" <changed-file-paths>` — the project root as the first argument, then each changed file path. Always double-quote paths with spaces.
|
||||
- Resolve two sets of absolute paths: (1) the repository root (`git rev-parse --show-toplevel` — returns the worktree root when in a worktree, project root otherwise; if this fails, fall back to the current working directory), (2) each changed file. Run `code -r "{absolute-root}" <absolute-changed-file-paths>` — the root first so VS Code opens in the right context, then each changed file. Always double-quote paths to handle spaces and special characters.
|
||||
- If `code` is not available (command fails), skip gracefully and list the file paths instead.
|
||||
2. Display a summary in conversation output, including:
|
||||
- The commit hash (if one was created).
|
||||
- List of files changed with one-line descriptions.
|
||||
- List of files changed with one-line descriptions. Use CWD-relative paths with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability. No leading `/`.
|
||||
- Review findings breakdown: patches applied, items deferred, items rejected. If all findings were rejected, say so.
|
||||
3. Offer to push and/or create a pull request.
|
||||
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `
|
|||
|
||||
### 2. Paths
|
||||
|
||||
- `wipFile` = `{implementation_artifacts}/tech-spec-wip.md`
|
||||
- `wipFile` = `{implementation_artifacts}/spec-wip.md`
|
||||
|
||||
### 3. First Step Execution
|
||||
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,
|
||||
bmm,anytime,Document Project,DP,,skill:bmad-document-project,bmad-bmm-document-project,false,analyst,Create Mode,"Analyze an existing project to produce useful documentation",project-knowledge,*,
|
||||
bmm,anytime,Generate Project Context,GPC,,skill:bmad-generate-project-context,bmad-bmm-generate-project-context,false,analyst,Create Mode,"Scan existing codebase to generate a lean LLM-optimized project-context.md containing critical implementation rules patterns and conventions for AI agents. Essential for brownfield projects and quick-flow.",output_folder,"project context",
|
||||
bmm,anytime,Quick Dev,QQ,,skill:bmad-quick-dev,bmad-bmm-quick-dev,false,quick-flow-solo-dev,Create Mode,"Unified quick flow: clarify intent plan implement review and present in a single workflow",implementation_artifacts,"tech spec and project implementation",
|
||||
bmm,anytime,Generate Project Context,GPC,,skill:bmad-generate-project-context,bmad-bmm-generate-project-context,false,analyst,Create Mode,"Scan existing codebase to generate a lean LLM-optimized project-context.md containing critical implementation rules patterns and conventions for AI agents. Essential for brownfield projects.",output_folder,"project context",
|
||||
bmm,anytime,Quick Dev,QQ,,skill:bmad-quick-dev,bmad-bmm-quick-dev,false,quick-flow-solo-dev,Create Mode,"Unified intent-in code-out workflow: clarify plan implement review and present",implementation_artifacts,"spec and project implementation",
|
||||
bmm,anytime,Correct Course,CC,,skill:bmad-correct-course,bmad-bmm-correct-course,false,sm,Create Mode,"Anytime: Navigate significant changes. May recommend start over update PRD redo architecture sprint planning or correct epics and stories",planning_artifacts,"change proposal",
|
||||
bmm,anytime,Write Document,WD,,skill:bmad-agent-tech-writer,,false,tech-writer,,"Describe in detail what you want, and the agent will follow the documentation best practices defined in agent memory. Multi-turn conversation with subprocess for research/review.",project-knowledge,"document",
|
||||
bmm,anytime,Update Standards,US,,skill:bmad-agent-tech-writer,,false,tech-writer,,"Update agent memory documentation-standards.md with your specific preferences if you discover missing document conventions.",_bmad/_memory/tech-writer-sidecar,"standards",
|
||||
|
|
|
|||
|
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
type: skill
|
||||
module: core
|
||||
capabilities:
|
||||
- name: bmad-distillator
|
||||
menu-code: DSTL
|
||||
description: "Produces lossless LLM-optimized distillate from source documents. Use after producing large human presentable documents that will be consumed later by LLMs"
|
||||
supports-headless: true
|
||||
input: source documents
|
||||
args: output, validate
|
||||
output: single distillate or folder of distillates next to source input
|
||||
config-vars-used: null
|
||||
phase: anytime
|
||||
before: []
|
||||
after: []
|
||||
is-required: false
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -1 +0,0 @@
|
|||
type: skill
|
||||
|
|
@ -14,7 +14,7 @@
|
|||
const path = require('node:path');
|
||||
const os = require('node:os');
|
||||
const fs = require('fs-extra');
|
||||
const { YamlXmlBuilder } = require('../tools/cli/lib/yaml-xml-builder');
|
||||
const { ConfigCollector } = require('../tools/cli/installers/lib/core/config-collector');
|
||||
const { ManifestGenerator } = require('../tools/cli/installers/lib/core/manifest-generator');
|
||||
const { IdeManager } = require('../tools/cli/installers/lib/ide/manager');
|
||||
const { clearCache, loadPlatformCodes } = require('../tools/cli/installers/lib/ide/platform-codes');
|
||||
|
|
@ -79,7 +79,6 @@ async function createTestBmadFixture() {
|
|||
'You are a test agent.',
|
||||
].join('\n'),
|
||||
);
|
||||
await fs.writeFile(path.join(skillDir, 'bmad-skill-manifest.yaml'), 'SKILL.md:\n type: skill\n');
|
||||
await fs.writeFile(path.join(skillDir, 'workflow.md'), '# Test Workflow\nStep 1: Do the thing.\n');
|
||||
|
||||
return fixtureDir;
|
||||
|
|
@ -100,17 +99,6 @@ async function createSkillCollisionFixture() {
|
|||
].join('\n'),
|
||||
);
|
||||
|
||||
await fs.writeFile(
|
||||
path.join(configDir, 'workflow-manifest.csv'),
|
||||
[
|
||||
'name,description,module,path,canonicalId',
|
||||
'"help","Workflow help","core","_bmad/core/workflows/help/workflow.md","bmad-help"',
|
||||
'',
|
||||
].join('\n'),
|
||||
);
|
||||
|
||||
await fs.writeFile(path.join(configDir, 'task-manifest.csv'), 'name,displayName,description,module,path,standalone,canonicalId\n');
|
||||
await fs.writeFile(path.join(configDir, 'tool-manifest.csv'), 'name,displayName,description,module,path,standalone,canonicalId\n');
|
||||
await fs.writeFile(
|
||||
path.join(configDir, 'skill-manifest.csv'),
|
||||
[
|
||||
|
|
@ -149,77 +137,10 @@ async function runTests() {
|
|||
|
||||
const projectRoot = path.join(__dirname, '..');
|
||||
|
||||
// Test 1: Removed — old YAML→XML agent compilation no longer applies (agents now use SKILL.md format)
|
||||
|
||||
console.log('');
|
||||
|
||||
// ============================================================
|
||||
// Test 2: Customization Merging
|
||||
// Test 1: Windsurf Native Skills Install
|
||||
// ============================================================
|
||||
console.log(`${colors.yellow}Test Suite 2: Customization Merging${colors.reset}\n`);
|
||||
|
||||
try {
|
||||
const builder = new YamlXmlBuilder();
|
||||
|
||||
// Test deepMerge function
|
||||
const base = {
|
||||
agent: {
|
||||
metadata: { name: 'John', title: 'PM' },
|
||||
persona: { role: 'Product Manager', style: 'Analytical' },
|
||||
},
|
||||
};
|
||||
|
||||
const customize = {
|
||||
agent: {
|
||||
metadata: { name: 'Sarah' }, // Override name only
|
||||
persona: { style: 'Concise' }, // Override style only
|
||||
},
|
||||
};
|
||||
|
||||
const merged = builder.deepMerge(base, customize);
|
||||
|
||||
assert(merged.agent.metadata.name === 'Sarah', 'Deep merge overrides customized name');
|
||||
|
||||
assert(merged.agent.metadata.title === 'PM', 'Deep merge preserves non-overridden title');
|
||||
|
||||
assert(merged.agent.persona.role === 'Product Manager', 'Deep merge preserves non-overridden role');
|
||||
|
||||
assert(merged.agent.persona.style === 'Concise', 'Deep merge overrides customized style');
|
||||
} catch (error) {
|
||||
assert(false, 'Customization merging works', error.message);
|
||||
}
|
||||
|
||||
console.log('');
|
||||
|
||||
// ============================================================
|
||||
// Test 3: Path Resolution
|
||||
// ============================================================
|
||||
console.log(`${colors.yellow}Test Suite 3: Path Variable Resolution${colors.reset}\n`);
|
||||
|
||||
try {
|
||||
const builder = new YamlXmlBuilder();
|
||||
|
||||
// Test path resolution logic (if exposed)
|
||||
// This would test {project-root}, {installed_path}, {config_source} resolution
|
||||
|
||||
const testPath = '{project-root}/bmad/bmm/config.yaml';
|
||||
const expectedPattern = /\/bmad\/bmm\/config\.yaml$/;
|
||||
|
||||
assert(
|
||||
true, // Placeholder - would test actual resolution
|
||||
'Path variable resolution pattern matches expected format',
|
||||
'Note: This test validates path resolution logic exists',
|
||||
);
|
||||
} catch (error) {
|
||||
assert(false, 'Path resolution works', error.message);
|
||||
}
|
||||
|
||||
console.log('');
|
||||
|
||||
// ============================================================
|
||||
// Test 4: Windsurf Native Skills Install
|
||||
// ============================================================
|
||||
console.log(`${colors.yellow}Test Suite 4: Windsurf Native Skills${colors.reset}\n`);
|
||||
console.log(`${colors.yellow}Test Suite 1: Windsurf Native Skills${colors.reset}\n`);
|
||||
|
||||
try {
|
||||
clearCache();
|
||||
|
|
@ -1603,7 +1524,6 @@ async function runTests() {
|
|||
// --- Skill at unusual path: core/custom-area/my-skill/ ---
|
||||
const skillDir29 = path.join(tempFixture29, 'core', 'custom-area', 'my-skill');
|
||||
await fs.ensureDir(skillDir29);
|
||||
await fs.writeFile(path.join(skillDir29, 'bmad-skill-manifest.yaml'), 'type: skill\n');
|
||||
await fs.writeFile(
|
||||
path.join(skillDir29, 'SKILL.md'),
|
||||
'---\nname: my-skill\ndescription: A skill at an unusual path\n---\n\nFollow the instructions in [workflow.md](workflow.md).\n',
|
||||
|
|
@ -1619,10 +1539,9 @@ async function runTests() {
|
|||
'---\nname: Regular Workflow\ndescription: A regular workflow not a skill\n---\n\nWorkflow body\n',
|
||||
);
|
||||
|
||||
// --- Skill inside workflows/ dir: core/workflows/wf-skill/ (exercises findWorkflows skip logic) ---
|
||||
// --- Skill inside workflows/ dir: core/workflows/wf-skill/ ---
|
||||
const wfSkillDir29 = path.join(tempFixture29, 'core', 'workflows', 'wf-skill');
|
||||
await fs.ensureDir(wfSkillDir29);
|
||||
await fs.writeFile(path.join(wfSkillDir29, 'bmad-skill-manifest.yaml'), 'type: skill\n');
|
||||
await fs.writeFile(
|
||||
path.join(wfSkillDir29, 'SKILL.md'),
|
||||
'---\nname: wf-skill\ndescription: A skill inside workflows dir\n---\n\nFollow the instructions in [workflow.md](workflow.md).\n',
|
||||
|
|
@ -1632,7 +1551,6 @@ async function runTests() {
|
|||
// --- Skill inside tasks/ dir: core/tasks/task-skill/ ---
|
||||
const taskSkillDir29 = path.join(tempFixture29, 'core', 'tasks', 'task-skill');
|
||||
await fs.ensureDir(taskSkillDir29);
|
||||
await fs.writeFile(path.join(taskSkillDir29, 'bmad-skill-manifest.yaml'), 'type: skill\n');
|
||||
await fs.writeFile(
|
||||
path.join(taskSkillDir29, 'SKILL.md'),
|
||||
'---\nname: task-skill\ndescription: A skill inside tasks dir\n---\n\nFollow the instructions in [workflow.md](workflow.md).\n',
|
||||
|
|
@ -1665,18 +1583,10 @@ async function runTests() {
|
|||
'Skill path includes relative path from module root',
|
||||
);
|
||||
|
||||
// Skill should NOT be in workflows
|
||||
const inWorkflows29 = generator29.workflows.find((w) => w.name === 'my-skill');
|
||||
assert(inWorkflows29 === undefined, 'Skill at unusual path does NOT appear in workflows[]');
|
||||
|
||||
// Skill in tasks/ dir should be in skills
|
||||
const taskSkillEntry29 = generator29.skills.find((s) => s.canonicalId === 'task-skill');
|
||||
assert(taskSkillEntry29 !== undefined, 'Skill in tasks/ dir appears in skills[]');
|
||||
|
||||
// Skill in tasks/ should NOT appear in tasks[]
|
||||
const inTasks29 = generator29.tasks.find((t) => t.name === 'task-skill');
|
||||
assert(inTasks29 === undefined, 'Skill in tasks/ dir does NOT appear in tasks[]');
|
||||
|
||||
// Native agent entrypoint should be installed as a verbatim skill and also
|
||||
// remain visible to the agent manifest pipeline.
|
||||
const nativeAgentEntry29 = generator29.skills.find((s) => s.canonicalId === 'bmad-tea');
|
||||
|
|
@ -1688,23 +1598,17 @@ async function runTests() {
|
|||
const nativeAgentManifest29 = generator29.agents.find((a) => a.name === 'bmad-tea');
|
||||
assert(nativeAgentManifest29 !== undefined, 'Native type:agent SKILL.md dir appears in agents[] for agent metadata');
|
||||
|
||||
// Regular workflow should be in workflows, NOT in skills
|
||||
const regularWf29 = generator29.workflows.find((w) => w.name === 'Regular Workflow');
|
||||
assert(regularWf29 !== undefined, 'Regular type:workflow appears in workflows[]');
|
||||
|
||||
// Regular type:workflow should NOT appear in skills[]
|
||||
const regularInSkills29 = generator29.skills.find((s) => s.canonicalId === 'regular-wf');
|
||||
assert(regularInSkills29 === undefined, 'Regular type:workflow does NOT appear in skills[]');
|
||||
|
||||
// Skill inside workflows/ should be in skills[], NOT in workflows[] (exercises findWorkflows skip at lines 311/322)
|
||||
// Skill inside workflows/ should be in skills[]
|
||||
const wfSkill29 = generator29.skills.find((s) => s.canonicalId === 'wf-skill');
|
||||
assert(wfSkill29 !== undefined, 'Skill in workflows/ dir appears in skills[]');
|
||||
const wfSkillInWorkflows29 = generator29.workflows.find((w) => w.name === 'wf-skill');
|
||||
assert(wfSkillInWorkflows29 === undefined, 'Skill in workflows/ dir does NOT appear in workflows[]');
|
||||
|
||||
// Test scanInstalledModules recognizes skill-only modules
|
||||
const skillOnlyModDir29 = path.join(tempFixture29, 'skill-only-mod');
|
||||
await fs.ensureDir(path.join(skillOnlyModDir29, 'deep', 'nested', 'my-skill'));
|
||||
await fs.writeFile(path.join(skillOnlyModDir29, 'deep', 'nested', 'my-skill', 'bmad-skill-manifest.yaml'), 'type: skill\n');
|
||||
await fs.writeFile(
|
||||
path.join(skillOnlyModDir29, 'deep', 'nested', 'my-skill', 'SKILL.md'),
|
||||
'---\nname: my-skill\ndescription: desc\n---\n\nFollow the instructions in [workflow.md](workflow.md).\n',
|
||||
|
|
@ -1744,6 +1648,93 @@ async function runTests() {
|
|||
// skill-manifest.csv should include the native agent entrypoint
|
||||
const skillManifestCsv29 = await fs.readFile(path.join(tempFixture29, '_config', 'skill-manifest.csv'), 'utf8');
|
||||
assert(skillManifestCsv29.includes('bmad-tea'), 'skill-manifest.csv includes native type:agent SKILL.md entrypoint');
|
||||
|
||||
// --- Agents at non-agents/ paths (regression test for BMM/CIS layouts) ---
|
||||
// Create a second fixture with agents at paths like bmm/1-analysis/bmad-agent-analyst/
|
||||
const tempFixture29b = await fs.mkdtemp(path.join(os.tmpdir(), 'bmad-agent-paths-'));
|
||||
await fs.ensureDir(path.join(tempFixture29b, '_config'));
|
||||
|
||||
// Agent at bmm-style path: bmm/1-analysis/bmad-agent-analyst/
|
||||
const bmmAgentDir = path.join(tempFixture29b, 'bmm', '1-analysis', 'bmad-agent-analyst');
|
||||
await fs.ensureDir(bmmAgentDir);
|
||||
await fs.writeFile(
|
||||
path.join(bmmAgentDir, 'bmad-skill-manifest.yaml'),
|
||||
[
|
||||
'type: agent',
|
||||
'name: bmad-agent-analyst',
|
||||
'displayName: Mary',
|
||||
'title: Business Analyst',
|
||||
'role: Strategic Business Analyst',
|
||||
'module: bmm',
|
||||
].join('\n') + '\n',
|
||||
);
|
||||
await fs.writeFile(
|
||||
path.join(bmmAgentDir, 'SKILL.md'),
|
||||
'---\nname: bmad-agent-analyst\ndescription: Business Analyst agent\n---\n\nAnalyst agent.\n',
|
||||
);
|
||||
|
||||
// Agent at cis-style path: cis/skills/bmad-cis-agent-brainstorming-coach/
|
||||
const cisAgentDir = path.join(tempFixture29b, 'cis', 'skills', 'bmad-cis-agent-brainstorming-coach');
|
||||
await fs.ensureDir(cisAgentDir);
|
||||
await fs.writeFile(
|
||||
path.join(cisAgentDir, 'bmad-skill-manifest.yaml'),
|
||||
[
|
||||
'type: agent',
|
||||
'name: bmad-cis-agent-brainstorming-coach',
|
||||
'displayName: Carson',
|
||||
'title: Brainstorming Specialist',
|
||||
'role: Master Facilitator',
|
||||
'module: cis',
|
||||
].join('\n') + '\n',
|
||||
);
|
||||
await fs.writeFile(
|
||||
path.join(cisAgentDir, 'SKILL.md'),
|
||||
'---\nname: bmad-cis-agent-brainstorming-coach\ndescription: Brainstorming coach\n---\n\nCoach.\n',
|
||||
);
|
||||
|
||||
// Agent at standard agents/ path (GDS-style): gds/agents/gds-agent-game-dev/
|
||||
const gdsAgentDir = path.join(tempFixture29b, 'gds', 'agents', 'gds-agent-game-dev');
|
||||
await fs.ensureDir(gdsAgentDir);
|
||||
await fs.writeFile(
|
||||
path.join(gdsAgentDir, 'bmad-skill-manifest.yaml'),
|
||||
[
|
||||
'type: agent',
|
||||
'name: gds-agent-game-dev',
|
||||
'displayName: Link',
|
||||
'title: Game Developer',
|
||||
'role: Senior Game Dev',
|
||||
'module: gds',
|
||||
].join('\n') + '\n',
|
||||
);
|
||||
await fs.writeFile(
|
||||
path.join(gdsAgentDir, 'SKILL.md'),
|
||||
'---\nname: gds-agent-game-dev\ndescription: Game developer agent\n---\n\nGame dev.\n',
|
||||
);
|
||||
|
||||
const generator29b = new ManifestGenerator();
|
||||
await generator29b.generateManifests(tempFixture29b, ['bmm', 'cis', 'gds'], [], { ides: [] });
|
||||
|
||||
// All three agents should appear in agents[] regardless of directory layout
|
||||
const bmmAgent = generator29b.agents.find((a) => a.name === 'bmad-agent-analyst');
|
||||
assert(bmmAgent !== undefined, 'Agent at bmm/1-analysis/ path appears in agents[]');
|
||||
assert(bmmAgent && bmmAgent.module === 'bmm', 'BMM agent module field comes from manifest file');
|
||||
assert(bmmAgent && bmmAgent.path.includes('bmm/1-analysis/bmad-agent-analyst'), 'BMM agent path reflects actual directory layout');
|
||||
|
||||
const cisAgent = generator29b.agents.find((a) => a.name === 'bmad-cis-agent-brainstorming-coach');
|
||||
assert(cisAgent !== undefined, 'Agent at cis/skills/ path appears in agents[]');
|
||||
assert(cisAgent && cisAgent.module === 'cis', 'CIS agent module field comes from manifest file');
|
||||
|
||||
const gdsAgent = generator29b.agents.find((a) => a.name === 'gds-agent-game-dev');
|
||||
assert(gdsAgent !== undefined, 'Agent at gds/agents/ path appears in agents[]');
|
||||
assert(gdsAgent && gdsAgent.module === 'gds', 'GDS agent module field comes from manifest file');
|
||||
|
||||
// agent-manifest.csv should contain all three
|
||||
const agentCsv29b = await fs.readFile(path.join(tempFixture29b, '_config', 'agent-manifest.csv'), 'utf8');
|
||||
assert(agentCsv29b.includes('bmad-agent-analyst'), 'agent-manifest.csv includes BMM-layout agent');
|
||||
assert(agentCsv29b.includes('bmad-cis-agent-brainstorming-coach'), 'agent-manifest.csv includes CIS-layout agent');
|
||||
assert(agentCsv29b.includes('gds-agent-game-dev'), 'agent-manifest.csv includes GDS-layout agent');
|
||||
|
||||
await fs.remove(tempFixture29b).catch(() => {});
|
||||
} catch (error) {
|
||||
assert(false, 'Unified skill scanner test succeeds', error.message);
|
||||
} finally {
|
||||
|
|
@ -1950,6 +1941,93 @@ async function runTests() {
|
|||
|
||||
console.log('');
|
||||
|
||||
// ============================================================
|
||||
// Test Suite 33: ConfigCollector Prompt Normalization
|
||||
// ============================================================
|
||||
console.log(`${colors.yellow}Test Suite 33: ConfigCollector Prompt Normalization${colors.reset}\n`);
|
||||
|
||||
try {
|
||||
const teaModuleConfig33 = {
|
||||
test_artifacts: {
|
||||
default: '_bmad-output/test-artifacts',
|
||||
},
|
||||
test_design_output: {
|
||||
prompt: 'Where should test design documents be stored?',
|
||||
default: 'test-design',
|
||||
result: '{test_artifacts}/{value}',
|
||||
},
|
||||
test_review_output: {
|
||||
prompt: 'Where should test review reports be stored?',
|
||||
default: 'test-reviews',
|
||||
result: '{test_artifacts}/{value}',
|
||||
},
|
||||
trace_output: {
|
||||
prompt: 'Where should traceability reports be stored?',
|
||||
default: 'traceability',
|
||||
result: '{test_artifacts}/{value}',
|
||||
},
|
||||
};
|
||||
|
||||
const collector33 = new ConfigCollector();
|
||||
collector33.currentProjectDir = path.join(os.tmpdir(), 'bmad-config-normalization');
|
||||
collector33.allAnswers = {};
|
||||
collector33.collectedConfig = {
|
||||
tea: {
|
||||
test_artifacts: '_bmad-output/test-artifacts',
|
||||
},
|
||||
};
|
||||
collector33.existingConfig = {
|
||||
tea: {
|
||||
test_artifacts: '_bmad-output/test-artifacts',
|
||||
test_design_output: '_bmad-output/test-artifacts/test-design',
|
||||
test_review_output: '_bmad-output/test-artifacts/test-reviews',
|
||||
trace_output: '_bmad-output/test-artifacts/traceability',
|
||||
},
|
||||
};
|
||||
|
||||
const testDesignQuestion33 = await collector33.buildQuestion(
|
||||
'tea',
|
||||
'test_design_output',
|
||||
teaModuleConfig33.test_design_output,
|
||||
teaModuleConfig33,
|
||||
);
|
||||
const testReviewQuestion33 = await collector33.buildQuestion(
|
||||
'tea',
|
||||
'test_review_output',
|
||||
teaModuleConfig33.test_review_output,
|
||||
teaModuleConfig33,
|
||||
);
|
||||
const traceQuestion33 = await collector33.buildQuestion('tea', 'trace_output', teaModuleConfig33.trace_output, teaModuleConfig33);
|
||||
|
||||
assert(testDesignQuestion33.default === 'test-design', 'ConfigCollector normalizes existing test_design_output prompt default');
|
||||
assert(testReviewQuestion33.default === 'test-reviews', 'ConfigCollector normalizes existing test_review_output prompt default');
|
||||
assert(traceQuestion33.default === 'traceability', 'ConfigCollector normalizes existing trace_output prompt default');
|
||||
|
||||
collector33.allAnswers = {
|
||||
tea_test_artifacts: '_bmad-output/test-artifacts',
|
||||
};
|
||||
|
||||
assert(
|
||||
collector33.processResultTemplate(teaModuleConfig33.test_design_output.result, testDesignQuestion33.default) ===
|
||||
'_bmad-output/test-artifacts/test-design',
|
||||
'ConfigCollector re-applies test_design_output template without duplicating prefix',
|
||||
);
|
||||
assert(
|
||||
collector33.processResultTemplate(teaModuleConfig33.test_review_output.result, testReviewQuestion33.default) ===
|
||||
'_bmad-output/test-artifacts/test-reviews',
|
||||
'ConfigCollector re-applies test_review_output template without duplicating prefix',
|
||||
);
|
||||
assert(
|
||||
collector33.processResultTemplate(teaModuleConfig33.trace_output.result, traceQuestion33.default) ===
|
||||
'_bmad-output/test-artifacts/traceability',
|
||||
'ConfigCollector re-applies trace_output template without duplicating prefix',
|
||||
);
|
||||
} catch (error) {
|
||||
assert(false, 'ConfigCollector prompt normalization test succeeds', error.message);
|
||||
}
|
||||
|
||||
console.log('');
|
||||
|
||||
// ============================================================
|
||||
// Summary
|
||||
// ============================================================
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
* This file ensures proper execution when run via npx from GitHub or npm registry
|
||||
*/
|
||||
|
||||
const { execSync } = require('node:child_process');
|
||||
const { execFileSync } = require('node:child_process');
|
||||
const path = require('node:path');
|
||||
const fs = require('node:fs');
|
||||
|
||||
|
|
@ -25,7 +25,7 @@ if (isNpxExecution) {
|
|||
|
||||
try {
|
||||
// Execute CLI from user's working directory (process.cwd()), not npm cache
|
||||
execSync(`node "${bmadCliPath}" ${args.join(' ')}`, {
|
||||
execFileSync('node', [bmadCliPath, ...args], {
|
||||
stdio: 'inherit',
|
||||
cwd: process.cwd(), // This preserves the user's working directory
|
||||
});
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@ import fs from 'node:fs';
|
|||
import path from 'node:path';
|
||||
import { fileURLToPath } from 'node:url';
|
||||
import { getSiteUrl } from '../website/src/lib/site-url.mjs';
|
||||
import { translatedLocales } from '../website/src/lib/locales.mjs';
|
||||
|
||||
// =============================================================================
|
||||
// Configuration
|
||||
|
|
@ -288,6 +289,9 @@ function shouldExcludeFromLlm(filePath) {
|
|||
const pathParts = filePath.split(path.sep);
|
||||
if (pathParts.some((part) => part.startsWith('_'))) return true;
|
||||
|
||||
// Exclude non-root locale directories (translations duplicate English content)
|
||||
if (translatedLocales.some((locale) => filePath.startsWith(`${locale}/`) || filePath.startsWith(`${locale}${path.sep}`))) return true;
|
||||
|
||||
// Check configured patterns
|
||||
return LLM_EXCLUDE_PATTERNS.some((pattern) => filePath.includes(pattern));
|
||||
}
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ module.exports = {
|
|||
'Comma-separated list of tool/IDE IDs to configure (e.g., "claude-code,cursor"). Use "none" to skip tool configuration.',
|
||||
],
|
||||
['--custom-content <paths>', 'Comma-separated list of paths to custom modules/agents/workflows'],
|
||||
['--action <type>', 'Action type for existing installations: install, update, quick-update, or compile-agents'],
|
||||
['--action <type>', 'Action type for existing installations: install, update, or quick-update'],
|
||||
['--user-name <name>', 'Name for agents to use (default: system username)'],
|
||||
['--communication-language <lang>', 'Language for agent communication (default: English)'],
|
||||
['--document-output-language <lang>', 'Language for document output (default: English)'],
|
||||
|
|
@ -49,13 +49,6 @@ module.exports = {
|
|||
process.exit(0);
|
||||
}
|
||||
|
||||
// Handle compile agents separately
|
||||
if (config.actionType === 'compile-agents') {
|
||||
const result = await installer.compileAgents(config);
|
||||
await prompts.log.info(`Recompiled ${result.agentCount} agents with customizations applied`);
|
||||
process.exit(0);
|
||||
}
|
||||
|
||||
// Regular install/update flow
|
||||
const result = await installer.install(config);
|
||||
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue