Compare commits
15 Commits
61e0ab1460
...
a390966585
| Author | SHA1 | Date |
|---|---|---|
Mathieu Santostefano
|
a390966585 | |
梁山河
|
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 | |
Copilot
|
2b6c79d731 |
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
|
||||
|
|
|
|||
|
|
@ -89,7 +89,10 @@ your-project/
|
|||
│ ├── bmad-help/
|
||||
│ ├── bmad-persona/
|
||||
│ └── ...
|
||||
└── .cursor/ # Cursor skills (if using Cursor)
|
||||
├── .cursor/ # Cursor skills (if using Cursor)
|
||||
│ └── skills/
|
||||
│ └── ...
|
||||
└── .vibe/ # Mistral Vibe skills (if using Mistral Vibe)
|
||||
└── skills/
|
||||
└── ...
|
||||
```
|
||||
|
|
|
|||
|
|
@ -61,6 +61,8 @@ Available tool IDs for the `--tools` flag:
|
|||
|
||||
**Preferred:** `claude-code`, `cursor`
|
||||
|
||||
**Other CLIs:** `mistral`, `gemini`, `codex`, `auggie`, `pi`
|
||||
|
||||
Run `npx bmad-method install` interactively once to see the full current list of supported tools, or check the [platform codes configuration](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/tools/cli/installers/lib/ide/platform-codes.yaml).
|
||||
|
||||
## Installation Modes
|
||||
|
|
|
|||
|
|
@ -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,18 +39,18 @@ 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 |
|
||||
|
|
@ -59,18 +59,18 @@ Critical warnings only — data loss, security issues
|
|||
| 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 方法中的一种工作流程，用于快速处理既有项目。
|
||||
- **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,11 +76,11 @@ persona:
|
|||
- 'Favor composition over inheritance'
|
||||
```
|
||||
|
||||
`persona` 部分会替换整个默认角色，因此如果您设置它，请包含所有四个字段。
|
||||
`persona` 会覆盖默认整段配置，所以启用时请把四个字段都填全。
|
||||
|
||||
**记忆**
|
||||
**记忆（`memories`）**
|
||||
|
||||
添加智能体将始终记住的持久上下文：
|
||||
添加智能体会长期记住的上下文：
|
||||
|
||||
```yaml
|
||||
memories:
|
||||
|
|
@ -89,9 +89,9 @@ memories:
|
|||
- '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,56 +126,51 @@ prompts:
|
|||
3. Execute deployment script
|
||||
```
|
||||
|
||||
### 3. 应用您的更改
|
||||
### 3. 应用更改
|
||||
|
||||
编辑后，重新安装以应用更改：
|
||||
编辑完成后，重新安装以应用配置：
|
||||
|
||||
```bash
|
||||
npx bmad-method install
|
||||
```
|
||||
|
||||
安装程序会检测现有安装并提供以下选项：
|
||||
安装程序会识别现有安装，并给出以下选项：
|
||||
|
||||
| Option | What It Does |
|
||||
| 选项 | 作用 |
|
||||
| ---------------------------- | ------------------------------------------------------------------- |
|
||||
| **Quick Update** | 将所有模块更新到最新版本并应用自定义配置 |
|
||||
| **Modify BMad Installation** | 用于添加或删除模块的完整安装流程 |
|
||||
| **Quick Update** | 更新所有模块到最新版本，并应用你的自定义配置 |
|
||||
| **Modify BMad Installation** | 进入完整安装流程，用于增删模块 |
|
||||
|
||||
对于仅自定义配置的更改，**Quick Update** 是最快的选项。
|
||||
如果只是调整 `.customize.yaml`，优先选 **Quick Update**。
|
||||
|
||||
## 故障排除
|
||||
## 故障排查
|
||||
|
||||
**更改未生效？**
|
||||
**改动没有生效？**
|
||||
|
||||
- 运行 `npx bmad-method install` 并选择 **Quick Update** 以应用更改
|
||||
- 检查您的 YAML 语法是否有效（缩进很重要）
|
||||
- 验证您编辑的是该智能体正确的 `.customize.yaml` 文件
|
||||
- 检查 YAML 语法是否正确（尤其是缩进）
|
||||
- 确认你编辑的是目标智能体对应的 `.customize.yaml`
|
||||
|
||||
**智能体无法加载？**
|
||||
|
||||
- 使用在线 YAML 验证器检查 YAML 语法错误
|
||||
- 确保在取消注释后没有留下空字段
|
||||
- 尝试恢复到原始模板并重新构建
|
||||
- 确保取消注释后没有遗留空字段
|
||||
- 可先回退到模板，再逐项恢复自定义配置
|
||||
|
||||
**需要重置智能体？**
|
||||
**需要重置某个智能体？**
|
||||
|
||||
- 清空或删除智能体的 `.customize.yaml` 文件
|
||||
- 运行 `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,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,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` | 统一快速流程 — 澄清意图、规划、实现、审查和呈现 | `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**：图形用户界面。通过图形元素与计算机交互的方式。
|
||||
|
|
|
|||
|
|
@ -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,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,4 +1,4 @@
|
|||
type: skill
|
||||
type: agent
|
||||
name: bmad-agent-architect
|
||||
displayName: Winston
|
||||
title: Architect
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@
|
|||
const path = require('node:path');
|
||||
const os = require('node:os');
|
||||
const fs = require('fs-extra');
|
||||
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');
|
||||
|
|
@ -1511,7 +1512,7 @@ async function runTests() {
|
|||
// ============================================================
|
||||
// Suite 29: Unified Skill Scanner — collectSkills
|
||||
// ============================================================
|
||||
console.log(`${colors.yellow}Test Suite 29: Unified Skill Scanner${colors.reset}\n`);
|
||||
console.log(`${colors.yellow}Test Suite 30: Unified Skill Scanner${colors.reset}\n`);
|
||||
|
||||
let tempFixture29;
|
||||
try {
|
||||
|
|
@ -1647,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 {
|
||||
|
|
@ -1658,7 +1746,7 @@ async function runTests() {
|
|||
// ============================================================
|
||||
// Suite 30: parseSkillMd validation (negative cases)
|
||||
// ============================================================
|
||||
console.log(`${colors.yellow}Test Suite 30: parseSkillMd Validation${colors.reset}\n`);
|
||||
console.log(`${colors.yellow}Test Suite 31: parseSkillMd Validation${colors.reset}\n`);
|
||||
|
||||
let tempFixture30;
|
||||
try {
|
||||
|
|
@ -1760,6 +1848,99 @@ async function runTests() {
|
|||
|
||||
console.log('');
|
||||
|
||||
// ============================================================
|
||||
// Suite 31: Mistral Vibe CLI Native Skills
|
||||
// ============================================================
|
||||
console.log(`${colors.yellow}Test Suite 31: Mistral Vibe CLI Native Skills${colors.reset}\n`);
|
||||
|
||||
let tempProjectDirMistral;
|
||||
let installedBmadDirMistral;
|
||||
try {
|
||||
clearCache();
|
||||
const platformCodesMistral = await loadPlatformCodes();
|
||||
const mistralInstaller = platformCodesMistral.platforms.mistral?.installer;
|
||||
|
||||
assert(mistralInstaller?.target_dir === '.vibe/skills', 'Mistral Vibe target_dir uses native skills path');
|
||||
assert(mistralInstaller?.skill_format === true, 'Mistral Vibe installer enables native skill output');
|
||||
assert(mistralInstaller?.template_type === 'default', 'Mistral Vibe installer uses default skill template');
|
||||
assert(mistralInstaller?.legacy_targets === undefined, 'Mistral Vibe installer has no legacy_targets');
|
||||
|
||||
tempProjectDirMistral = await fs.mkdtemp(path.join(os.tmpdir(), 'bmad-mistral-test-'));
|
||||
installedBmadDirMistral = await createTestBmadFixture();
|
||||
|
||||
const ideManagerMistral = new IdeManager();
|
||||
await ideManagerMistral.ensureInitialized();
|
||||
|
||||
// Verify Mistral Vibe is selectable in an available IDEs list
|
||||
const availableIdesMistral = ideManagerMistral.getAvailableIdes();
|
||||
assert(
|
||||
availableIdesMistral.some((ide) => ide.value === 'mistral'),
|
||||
'Mistral Vibe appears in available IDEs list',
|
||||
);
|
||||
|
||||
// Verify Mistral Vibe is NOT detected before install
|
||||
const detectedBeforeMistral = await ideManagerMistral.detectInstalledIdes(tempProjectDirMistral);
|
||||
assert(!detectedBeforeMistral.includes('mistral'), 'Mistral Vibe is not detected before install');
|
||||
|
||||
const resultMistral = await ideManagerMistral.setup('mistral', tempProjectDirMistral, installedBmadDirMistral, {
|
||||
silent: true,
|
||||
selectedModules: ['bmm'],
|
||||
});
|
||||
|
||||
assert(resultMistral.success === true, 'Mistral Vibe setup succeeds against temp project');
|
||||
|
||||
// Verify Mistral Vibe IS detected after install
|
||||
const detectedAfterMistral = await ideManagerMistral.detectInstalledIdes(tempProjectDirMistral);
|
||||
assert(detectedAfterMistral.includes('mistral'), 'Mistral Vibe is detected after install');
|
||||
|
||||
const skillFileMistral = path.join(tempProjectDirMistral, '.vibe', 'skills', 'bmad-master', 'SKILL.md');
|
||||
assert(await fs.pathExists(skillFileMistral), 'Mistral Vibe install writes SKILL.md directory output');
|
||||
|
||||
// Parse YAML frontmatter between --- markers
|
||||
const skillContentMistral = await fs.readFile(skillFileMistral, 'utf8');
|
||||
const fmMatchMistral = skillContentMistral.match(/^---\n([\s\S]*?)\n---\n?([\s\S]*)$/);
|
||||
assert(fmMatchMistral, 'Mistral Vibe SKILL.md contains valid frontmatter delimiters');
|
||||
|
||||
const frontmatterMistral = fmMatchMistral[1];
|
||||
const bodyMistral = fmMatchMistral[2];
|
||||
|
||||
// Verify the name in the frontmatter matches the directory name
|
||||
const fmNameMistral = frontmatterMistral.match(/^name:\s*(.+)$/m);
|
||||
assert(
|
||||
fmNameMistral && fmNameMistral[1].trim() === 'bmad-master',
|
||||
'Mistral Vibe skill name frontmatter matches directory name exactly',
|
||||
);
|
||||
|
||||
// Verify description exists and is non-empty
|
||||
const fmDescMistral = frontmatterMistral.match(/^description:\s*(.+)$/m);
|
||||
assert(fmDescMistral && fmDescMistral[1].trim().length > 0, 'Mistral Vibe skill description frontmatter is present and non-empty');
|
||||
|
||||
// Verify frontmatter contains only name and description keys
|
||||
const fmKeysMistral = [...frontmatterMistral.matchAll(/^([a-zA-Z0-9_-]+):/gm)].map((m) => m[1]);
|
||||
assert(
|
||||
fmKeysMistral.length === 2 && fmKeysMistral.includes('name') && fmKeysMistral.includes('description'),
|
||||
'Mistral Vibe skill frontmatter contains only name and description keys',
|
||||
);
|
||||
|
||||
// Verify body content is non-empty
|
||||
assert(bodyMistral.trim().length > 0, 'Mistral Vibe skill body content is non-empty');
|
||||
|
||||
// Reinstall/upgrade: run setup again over existing output
|
||||
const resultMistralb = await ideManagerMistral.setup('mistral', tempProjectDirMistral, installedBmadDirMistral, {
|
||||
silent: true,
|
||||
selectedModules: ['bmm'],
|
||||
});
|
||||
assert(resultMistralb.success === true, 'Mistral Vibe reinstall/upgrade succeeds over existing skills');
|
||||
assert(await fs.pathExists(skillFileMistral), 'Mistral Vibe reinstall preserves SKILL.md output');
|
||||
} catch (error) {
|
||||
assert(false, 'Mistral Vibe native skills test succeeds', error.message);
|
||||
} finally {
|
||||
if (tempProjectDirMistral) await fs.remove(tempProjectDirMistral).catch(() => {});
|
||||
if (installedBmadDirMistral) await fs.remove(installedBmadDirMistral).catch(() => {});
|
||||
}
|
||||
|
||||
console.log('');
|
||||
|
||||
// ============================================================
|
||||
// Suite 32: Ona Native Skills
|
||||
// ============================================================
|
||||
|
|
@ -1853,6 +2034,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
|
||||
});
|
||||
|
|
|
|||
|
|
@ -954,31 +954,123 @@ class ConfigCollector {
|
|||
return match;
|
||||
}
|
||||
|
||||
// Look for the config value in allAnswers (already answered questions)
|
||||
let configValue = this.allAnswers[configKey] || this.allAnswers[`core_${configKey}`];
|
||||
|
||||
// Check in already collected config
|
||||
if (!configValue) {
|
||||
for (const mod of Object.keys(this.collectedConfig)) {
|
||||
if (mod !== '_meta' && this.collectedConfig[mod] && this.collectedConfig[mod][configKey]) {
|
||||
configValue = this.collectedConfig[mod][configKey];
|
||||
break;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// If still not found and we're in the same module, use the default from the config schema
|
||||
if (!configValue && currentModule && moduleConfig && moduleConfig[configKey]) {
|
||||
const referencedItem = moduleConfig[configKey];
|
||||
if (referencedItem && referencedItem.default !== undefined) {
|
||||
configValue = referencedItem.default;
|
||||
}
|
||||
}
|
||||
const configValue = this.resolveConfigValue(configKey, currentModule, moduleConfig);
|
||||
|
||||
return configValue || match;
|
||||
});
|
||||
}
|
||||
|
||||
/**
|
||||
* Clean a stored path-like value for prompt display/input reuse.
|
||||
* @param {*} value - Stored value
|
||||
* @returns {*} Cleaned value
|
||||
*/
|
||||
cleanPromptValue(value) {
|
||||
if (typeof value === 'string' && value.startsWith('{project-root}/')) {
|
||||
return value.replace('{project-root}/', '');
|
||||
}
|
||||
|
||||
return value;
|
||||
}
|
||||
|
||||
/**
|
||||
* Resolve a config key from answers, collected config, existing config, or schema defaults.
|
||||
* @param {string} configKey - Config key to resolve
|
||||
* @param {string} currentModule - Current module name
|
||||
* @param {Object} moduleConfig - Current module config schema
|
||||
* @returns {*} Resolved value
|
||||
*/
|
||||
resolveConfigValue(configKey, currentModule = null, moduleConfig = null) {
|
||||
// Look for the config value in allAnswers (already answered questions)
|
||||
let configValue = this.allAnswers?.[configKey] || this.allAnswers?.[`core_${configKey}`];
|
||||
|
||||
if (!configValue && this.allAnswers) {
|
||||
for (const [answerKey, answerValue] of Object.entries(this.allAnswers)) {
|
||||
if (answerKey.endsWith(`_${configKey}`)) {
|
||||
configValue = answerValue;
|
||||
break;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Prefer the current module's persisted value when re-prompting an existing install
|
||||
if (!configValue && currentModule && this.existingConfig?.[currentModule]?.[configKey] !== undefined) {
|
||||
configValue = this.existingConfig[currentModule][configKey];
|
||||
}
|
||||
|
||||
// Check in already collected config
|
||||
if (!configValue) {
|
||||
for (const mod of Object.keys(this.collectedConfig)) {
|
||||
if (mod !== '_meta' && this.collectedConfig[mod] && this.collectedConfig[mod][configKey]) {
|
||||
configValue = this.collectedConfig[mod][configKey];
|
||||
break;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Fall back to other existing module config values
|
||||
if (!configValue && this.existingConfig) {
|
||||
for (const mod of Object.keys(this.existingConfig)) {
|
||||
if (mod !== '_meta' && this.existingConfig[mod] && this.existingConfig[mod][configKey]) {
|
||||
configValue = this.existingConfig[mod][configKey];
|
||||
break;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// If still not found and we're in the same module, use the default from the config schema
|
||||
if (!configValue && currentModule && moduleConfig && moduleConfig[configKey]) {
|
||||
const referencedItem = moduleConfig[configKey];
|
||||
if (referencedItem && referencedItem.default !== undefined) {
|
||||
configValue = referencedItem.default;
|
||||
}
|
||||
}
|
||||
|
||||
return this.cleanPromptValue(configValue);
|
||||
}
|
||||
|
||||
/**
|
||||
* Convert an existing stored value back into the prompt-facing value for templated fields.
|
||||
* For example, "{test_artifacts}/{value}" + "_bmad-output/test-artifacts/test-design"
|
||||
* becomes "test-design" so the template is not applied twice on modify.
|
||||
* @param {*} existingValue - Stored config value
|
||||
* @param {string} moduleName - Module name
|
||||
* @param {Object} item - Config item definition
|
||||
* @param {Object} moduleConfig - Current module config schema
|
||||
* @returns {*} Prompt-facing default value
|
||||
*/
|
||||
normalizeExistingValueForPrompt(existingValue, moduleName, item, moduleConfig = null) {
|
||||
const cleanedValue = this.cleanPromptValue(existingValue);
|
||||
|
||||
if (typeof cleanedValue !== 'string' || typeof item?.result !== 'string' || !item.result.includes('{value}')) {
|
||||
return cleanedValue;
|
||||
}
|
||||
|
||||
const [prefixTemplate = '', suffixTemplate = ''] = item.result.split('{value}');
|
||||
const prefix = this.cleanPromptValue(this.replacePlaceholders(prefixTemplate, moduleName, moduleConfig));
|
||||
const suffix = this.cleanPromptValue(this.replacePlaceholders(suffixTemplate, moduleName, moduleConfig));
|
||||
|
||||
if ((prefix && !cleanedValue.startsWith(prefix)) || (suffix && !cleanedValue.endsWith(suffix))) {
|
||||
return cleanedValue;
|
||||
}
|
||||
|
||||
const startIndex = prefix.length;
|
||||
const endIndex = suffix ? cleanedValue.length - suffix.length : cleanedValue.length;
|
||||
if (endIndex < startIndex) {
|
||||
return cleanedValue;
|
||||
}
|
||||
|
||||
let promptValue = cleanedValue.slice(startIndex, endIndex);
|
||||
if (promptValue.startsWith('/')) {
|
||||
promptValue = promptValue.slice(1);
|
||||
}
|
||||
if (promptValue.endsWith('/')) {
|
||||
promptValue = promptValue.slice(0, -1);
|
||||
}
|
||||
|
||||
return promptValue || cleanedValue;
|
||||
}
|
||||
|
||||
/**
|
||||
* Build a prompt question from a config item
|
||||
* @param {string} moduleName - Module name
|
||||
|
|
@ -993,12 +1085,7 @@ class ConfigCollector {
|
|||
let existingValue = null;
|
||||
if (this.existingConfig && this.existingConfig[moduleName]) {
|
||||
existingValue = this.existingConfig[moduleName][key];
|
||||
|
||||
// Clean up existing value - remove {project-root}/ prefix if present
|
||||
// This prevents duplication when the result template adds it back
|
||||
if (typeof existingValue === 'string' && existingValue.startsWith('{project-root}/')) {
|
||||
existingValue = existingValue.replace('{project-root}/', '');
|
||||
}
|
||||
existingValue = this.normalizeExistingValueForPrompt(existingValue, moduleName, item, moduleConfig);
|
||||
}
|
||||
|
||||
// Special handling for user_name: default to system user
|
||||
|
|
|
|||
|
|
@ -268,153 +268,103 @@ class ManifestGenerator {
|
|||
}
|
||||
|
||||
/**
|
||||
* Collect all agents from core and selected modules
|
||||
* Scans the INSTALLED bmad directory, not the source
|
||||
* Collect all agents from selected modules by walking their directory trees.
|
||||
*/
|
||||
async collectAgents(selectedModules) {
|
||||
this.agents = [];
|
||||
const debug = process.env.BMAD_DEBUG_MANIFEST === 'true';
|
||||
|
||||
// Use updatedModules which already includes deduplicated 'core' + selectedModules
|
||||
// Walk each module's full directory tree looking for type:agent manifests
|
||||
for (const moduleName of this.updatedModules) {
|
||||
const agentsPath = path.join(this.bmadDir, moduleName, 'agents');
|
||||
const modulePath = path.join(this.bmadDir, moduleName);
|
||||
if (!(await fs.pathExists(modulePath))) continue;
|
||||
|
||||
if (await fs.pathExists(agentsPath)) {
|
||||
const moduleAgents = await this.getAgentsFromDir(agentsPath, moduleName);
|
||||
this.agents.push(...moduleAgents);
|
||||
}
|
||||
const moduleAgents = await this.getAgentsFromDirRecursive(modulePath, moduleName, '', debug);
|
||||
this.agents.push(...moduleAgents);
|
||||
}
|
||||
|
||||
// Get standalone agents from bmad/agents/ directory
|
||||
const standaloneAgentsDir = path.join(this.bmadDir, 'agents');
|
||||
if (await fs.pathExists(standaloneAgentsDir)) {
|
||||
const agentDirs = await fs.readdir(standaloneAgentsDir, { withFileTypes: true });
|
||||
const standaloneAgents = await this.getAgentsFromDirRecursive(standaloneAgentsDir, 'standalone', '', debug);
|
||||
this.agents.push(...standaloneAgents);
|
||||
}
|
||||
|
||||
for (const agentDir of agentDirs) {
|
||||
if (!agentDir.isDirectory()) continue;
|
||||
|
||||
const agentDirPath = path.join(standaloneAgentsDir, agentDir.name);
|
||||
const standaloneAgents = await this.getAgentsFromDir(agentDirPath, 'standalone');
|
||||
this.agents.push(...standaloneAgents);
|
||||
}
|
||||
if (debug) {
|
||||
console.log(`[DEBUG] collectAgents: total agents found: ${this.agents.length}`);
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Get agents from a directory recursively
|
||||
* Only includes .md files with agent content
|
||||
* Recursively walk a directory tree collecting agents.
|
||||
* Discovers agents via directory with bmad-skill-manifest.yaml containing type: agent
|
||||
*
|
||||
* @param {string} dirPath - Current directory being scanned
|
||||
* @param {string} moduleName - Module this directory belongs to
|
||||
* @param {string} relativePath - Path relative to the module root (for install path construction)
|
||||
* @param {boolean} debug - Emit debug messages
|
||||
*/
|
||||
async getAgentsFromDir(dirPath, moduleName, relativePath = '') {
|
||||
// Skip directories claimed by collectSkills
|
||||
if (this.skillClaimedDirs && this.skillClaimedDirs.has(dirPath)) return [];
|
||||
async getAgentsFromDirRecursive(dirPath, moduleName, relativePath = '', debug = false) {
|
||||
const agents = [];
|
||||
const entries = await fs.readdir(dirPath, { withFileTypes: true });
|
||||
// Load skill manifest for this directory (if present)
|
||||
const skillManifest = await this.loadSkillManifest(dirPath);
|
||||
let entries;
|
||||
try {
|
||||
entries = await fs.readdir(dirPath, { withFileTypes: true });
|
||||
} catch {
|
||||
return agents;
|
||||
}
|
||||
|
||||
for (const entry of entries) {
|
||||
if (!entry.isDirectory()) continue;
|
||||
if (entry.name.startsWith('.') || entry.name.startsWith('_')) continue;
|
||||
|
||||
const fullPath = path.join(dirPath, entry.name);
|
||||
|
||||
if (entry.isDirectory()) {
|
||||
// Check for new-format agent: bmad-skill-manifest.yaml with type: agent
|
||||
// Note: type:agent dirs may also be claimed by collectSkills for IDE installation,
|
||||
// but we still need to process them here for agent-manifest.csv
|
||||
const dirManifest = await this.loadSkillManifest(fullPath);
|
||||
if (dirManifest && dirManifest.__single && dirManifest.__single.type === 'agent') {
|
||||
const m = dirManifest.__single;
|
||||
const dirRelativePath = relativePath ? `${relativePath}/${entry.name}` : entry.name;
|
||||
const installPath =
|
||||
moduleName === 'core'
|
||||
? `${this.bmadFolderName}/core/agents/${dirRelativePath}`
|
||||
: `${this.bmadFolderName}/${moduleName}/agents/${dirRelativePath}`;
|
||||
|
||||
agents.push({
|
||||
name: m.name || entry.name,
|
||||
displayName: m.displayName || m.name || entry.name,
|
||||
title: m.title || '',
|
||||
icon: m.icon || '',
|
||||
capabilities: m.capabilities ? this.cleanForCSV(m.capabilities) : '',
|
||||
role: m.role ? this.cleanForCSV(m.role) : '',
|
||||
identity: m.identity ? this.cleanForCSV(m.identity) : '',
|
||||
communicationStyle: m.communicationStyle ? this.cleanForCSV(m.communicationStyle) : '',
|
||||
principles: m.principles ? this.cleanForCSV(m.principles) : '',
|
||||
module: m.module || moduleName,
|
||||
path: installPath,
|
||||
canonicalId: m.canonicalId || '',
|
||||
});
|
||||
|
||||
this.files.push({
|
||||
type: 'agent',
|
||||
name: m.name || entry.name,
|
||||
module: moduleName,
|
||||
path: installPath,
|
||||
});
|
||||
continue;
|
||||
}
|
||||
|
||||
// Skip directories claimed by collectSkills (non-agent type skills)
|
||||
if (this.skillClaimedDirs && this.skillClaimedDirs.has(fullPath)) continue;
|
||||
|
||||
// Recurse into subdirectories
|
||||
const newRelativePath = relativePath ? `${relativePath}/${entry.name}` : entry.name;
|
||||
const subDirAgents = await this.getAgentsFromDir(fullPath, moduleName, newRelativePath);
|
||||
agents.push(...subDirAgents);
|
||||
} else if (entry.name.endsWith('.md') && entry.name.toLowerCase() !== 'readme.md') {
|
||||
const content = await fs.readFile(fullPath, 'utf8');
|
||||
|
||||
// Skip files that don't contain <agent> tag (e.g., README files)
|
||||
if (!content.includes('<agent')) {
|
||||
continue;
|
||||
}
|
||||
|
||||
// Skip web-only agents
|
||||
if (content.includes('localskip="true"')) {
|
||||
continue;
|
||||
}
|
||||
|
||||
// Extract agent metadata from the XML structure
|
||||
const nameMatch = content.match(/name="([^"]+)"/);
|
||||
const titleMatch = content.match(/title="([^"]+)"/);
|
||||
const iconMatch = content.match(/icon="([^"]+)"/);
|
||||
const capabilitiesMatch = content.match(/capabilities="([^"]+)"/);
|
||||
|
||||
// Extract persona fields
|
||||
const roleMatch = content.match(/<role>([^<]+)<\/role>/);
|
||||
const identityMatch = content.match(/<identity>([\s\S]*?)<\/identity>/);
|
||||
const styleMatch = content.match(/<communication_style>([\s\S]*?)<\/communication_style>/);
|
||||
const principlesMatch = content.match(/<principles>([\s\S]*?)<\/principles>/);
|
||||
|
||||
// Build relative path for installation
|
||||
const fileRelativePath = relativePath ? `${relativePath}/${entry.name}` : entry.name;
|
||||
const installPath =
|
||||
moduleName === 'core'
|
||||
? `${this.bmadFolderName}/core/agents/${fileRelativePath}`
|
||||
: `${this.bmadFolderName}/${moduleName}/agents/${fileRelativePath}`;
|
||||
|
||||
const agentName = entry.name.replace('.md', '');
|
||||
// Check for type:agent manifest BEFORE checking skillClaimedDirs —
|
||||
// agent dirs may be claimed by collectSkills for IDE installation,
|
||||
// but we still need them in agent-manifest.csv.
|
||||
const dirManifest = await this.loadSkillManifest(fullPath);
|
||||
if (dirManifest && dirManifest.__single && dirManifest.__single.type === 'agent') {
|
||||
const m = dirManifest.__single;
|
||||
const dirRelativePath = relativePath ? `${relativePath}/${entry.name}` : entry.name;
|
||||
const agentModule = m.module || moduleName;
|
||||
const installPath = `${this.bmadFolderName}/${agentModule}/${dirRelativePath}`;
|
||||
|
||||
agents.push({
|
||||
name: agentName,
|
||||
displayName: nameMatch ? nameMatch[1] : agentName,
|
||||
title: titleMatch ? titleMatch[1] : '',
|
||||
icon: iconMatch ? iconMatch[1] : '',
|
||||
capabilities: capabilitiesMatch ? this.cleanForCSV(capabilitiesMatch[1]) : '',
|
||||
role: roleMatch ? this.cleanForCSV(roleMatch[1]) : '',
|
||||
identity: identityMatch ? this.cleanForCSV(identityMatch[1]) : '',
|
||||
communicationStyle: styleMatch ? this.cleanForCSV(styleMatch[1]) : '',
|
||||
principles: principlesMatch ? this.cleanForCSV(principlesMatch[1]) : '',
|
||||
module: moduleName,
|
||||
name: m.name || entry.name,
|
||||
displayName: m.displayName || m.name || entry.name,
|
||||
title: m.title || '',
|
||||
icon: m.icon || '',
|
||||
capabilities: m.capabilities ? this.cleanForCSV(m.capabilities) : '',
|
||||
role: m.role ? this.cleanForCSV(m.role) : '',
|
||||
identity: m.identity ? this.cleanForCSV(m.identity) : '',
|
||||
communicationStyle: m.communicationStyle ? this.cleanForCSV(m.communicationStyle) : '',
|
||||
principles: m.principles ? this.cleanForCSV(m.principles) : '',
|
||||
module: agentModule,
|
||||
path: installPath,
|
||||
canonicalId: this.getCanonicalId(skillManifest, entry.name),
|
||||
canonicalId: m.canonicalId || '',
|
||||
});
|
||||
|
||||
// Add to files list
|
||||
this.files.push({
|
||||
type: 'agent',
|
||||
name: agentName,
|
||||
module: moduleName,
|
||||
name: m.name || entry.name,
|
||||
module: agentModule,
|
||||
path: installPath,
|
||||
});
|
||||
|
||||
if (debug) {
|
||||
console.log(`[DEBUG] collectAgents: found type:agent "${m.name || entry.name}" at ${fullPath}`);
|
||||
}
|
||||
continue;
|
||||
}
|
||||
|
||||
// Skip directories claimed by collectSkills (non-agent type skills) —
|
||||
// avoids recursing into skill trees that can't contain agents.
|
||||
if (this.skillClaimedDirs && this.skillClaimedDirs.has(fullPath)) continue;
|
||||
|
||||
// Recurse into subdirectories
|
||||
const newRelativePath = relativePath ? `${relativePath}/${entry.name}` : entry.name;
|
||||
const subDirAgents = await this.getAgentsFromDirRecursive(fullPath, moduleName, newRelativePath, debug);
|
||||
agents.push(...subDirAgents);
|
||||
}
|
||||
|
||||
return agents;
|
||||
|
|
|
|||
|
|
@ -176,6 +176,16 @@ platforms:
|
|||
template_type: kiro
|
||||
skill_format: true
|
||||
|
||||
mistral:
|
||||
name: "Mistral Vibe"
|
||||
preferred: false
|
||||
category: cli
|
||||
description: "Mistral's AI coding CLI"
|
||||
installer:
|
||||
target_dir: .vibe/skills
|
||||
template_type: default
|
||||
skill_format: true
|
||||
|
||||
ona:
|
||||
name: "Ona"
|
||||
preferred: false
|
||||
|
|
|
|||
|
|
@ -5,6 +5,33 @@ const { loadSkillManifest, getCanonicalId } = require('./skill-manifest');
|
|||
/**
|
||||
* Helpers for gathering BMAD agents/tasks from the installed tree.
|
||||
* Shared by installers that need Claude-style exports.
|
||||
*
|
||||
* TODO: Dead code cleanup — compiled XML agents are retired.
|
||||
*
|
||||
* All agents now use the SKILL.md directory format with bmad-skill-manifest.yaml
|
||||
* (type: agent). The legacy pipeline below only discovers compiled .md files
|
||||
* containing <agent> XML tags, which no longer exist. The following are dead:
|
||||
*
|
||||
* - getAgentsFromBmad() — scans {module}/agents/ for .md files with <agent> tags
|
||||
* - getAgentsFromDir() — recursive helper for the above
|
||||
* - AgentCommandGenerator — (agent-command-generator.js) generates launcher .md files
|
||||
* that tell the LLM to load a compiled agent .md file
|
||||
* - agent-command-template.md — (templates/) the launcher template with hardcoded
|
||||
* {module}/agents/{{path}} reference
|
||||
*
|
||||
* Agent metadata for agent-manifest.csv is now handled entirely by
|
||||
* ManifestGenerator.getAgentsFromDirRecursive() in manifest-generator.js,
|
||||
* which walks the full module tree and finds type:agent directories.
|
||||
*
|
||||
* IDE installation of agents is handled by the native skill pipeline —
|
||||
* each agent's SKILL.md directory is installed directly to the IDE's
|
||||
* skills path, so no launcher intermediary is needed.
|
||||
*
|
||||
* Cleanup: remove getAgentsFromBmad, getAgentsFromDir, their exports,
|
||||
* AgentCommandGenerator, agent-command-template.md, and all call sites
|
||||
* in IDE installers that invoke collectAgentArtifacts / writeAgentLaunchers /
|
||||
* writeColonArtifacts / writeDashArtifacts.
|
||||
* getTasksFromBmad and getTasksFromDir may still be live — verify before removing.
|
||||
*/
|
||||
async function getAgentsFromBmad(bmadDir, selectedModules = []) {
|
||||
const agents = [];
|
||||
|
|
|
|||
Loading…
Reference in New Issue