Merge branch 'main' into main
This commit is contained in:
miendinh
GitHub
commit
e172c2c00c
20
CHANGELOG.md
20
CHANGELOG.md
|
|
@ -1,5 +1,25 @@
|
||||||
# Changelog
|
# 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
|
## v6.2.0 - 2026-03-15
|
||||||
|
|
||||||
### 🎁 Highlights
|
### 🎁 Highlights
|
||||||
|
|
|
||||||
|
|
@ -1,25 +1,25 @@
|
||||||
---
|
---
|
||||||
title: "Documentation Style Guide"
|
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 |
|
| 禁用 `####` 标题 | 用加粗短句或 admonition 替代 |
|
||||||
| No "Related" or "Next:" sections | Sidebar handles navigation |
|
| 避免 “Related/Next” 章节 | 交给侧边栏导航 |
|
||||||
| No deeply nested lists | Break into sections instead |
|
| 避免深层嵌套列表 | 拆成新段落或新小节 |
|
||||||
| No code blocks for non-code | Use admonitions for dialogue examples |
|
| 非代码内容不要放代码块 | 对话/提示用 admonition |
|
||||||
| No bold paragraphs for callouts | Use admonitions instead |
|
| 不用整段粗体做提醒 | 统一用 admonition |
|
||||||
| 1-2 admonitions per section max | Tutorials allow 3-4 per major section |
|
| 每节 1-2 个 admonition | 教程大节可放宽到 3-4 个 |
|
||||||
| Table cells / list items | 1-2 sentences max |
|
| 表格单元格/列表项 | 控制在 1-2 句 |
|
||||||
| Header budget | 8-12 `##` per doc; 2-3 `###` per section |
|
| 标题预算 | 每篇约 8-12 个 `##`，每节 2-3 个 `###` |
|
||||||
|
|
||||||
## Admonitions (Starlight Syntax)
|
## 提示块（Starlight 语法）
|
||||||
|
|
||||||
```md
|
```md
|
||||||
:::tip[Title]
|
:::tip[Title]
|
||||||
|
|
@ -39,18 +39,18 @@ Critical warnings only — data loss, security issues
|
||||||
:::
|
:::
|
||||||
```
|
```
|
||||||
|
|
||||||
### Standard Uses
|
### 标准用途
|
||||||
|
|
||||||
| Admonition | Use For |
|
| 提示块 | 适用场景 |
|
||||||
| ------------------------ | ----------------------------- |
|
| --- | --- |
|
||||||
| `:::note[Prerequisites]` | Dependencies before starting |
|
| `:::note[Prerequisites]` | 开始前依赖与前置条件 |
|
||||||
| `:::tip[Quick Path]` | TL;DR summary at document top |
|
| `:::tip[Quick Path]` | 文档顶部 TL;DR |
|
||||||
| `:::caution[Important]` | Critical caveats |
|
| `:::caution[Important]` | 关键风险提醒 |
|
||||||
| `:::note[Example]` | Command/response examples |
|
| `:::note[Example]` | 命令/响应示例说明 |
|
||||||
|
|
||||||
## Standard Table Formats
|
## 标准表格模板
|
||||||
|
|
||||||
**Phases:**
|
**阶段（Phases）：**
|
||||||
|
|
||||||
```md
|
```md
|
||||||
| Phase | Name | What Happens |
|
| Phase | Name | What Happens |
|
||||||
|
|
@ -59,18 +59,18 @@ Critical warnings only — data loss, security issues
|
||||||
| 2 | Planning | Requirements — PRD or spec *(required)* |
|
| 2 | Planning | Requirements — PRD or spec *(required)* |
|
||||||
```
|
```
|
||||||
|
|
||||||
**Commands:**
|
**技能（Skills）：**
|
||||||
|
|
||||||
```md
|
```md
|
||||||
| Command | Agent | Purpose |
|
| Skill | Agent | Purpose |
|
||||||
| ------------ | ------- | ------------------------------------ |
|
| -------------------- | ------- | ------------------------------------ |
|
||||||
| `brainstorm` | Analyst | Brainstorm a new project |
|
| `bmad-brainstorming` | Analyst | Brainstorm a new project |
|
||||||
| `prd` | PM | Create Product Requirements Document |
|
| `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
|
````md
|
||||||
```
|
```
|
||||||
|
|
@ -85,223 +85,223 @@ your-project/
|
||||||
```
|
```
|
||||||
````
|
````
|
||||||
|
|
||||||
## Tutorial Structure
|
## 教程（Tutorial）结构
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (1-2 sentences describing outcome)
|
1. Title + Hook（1-2 句结果导向开场）
|
||||||
2. Version/Module Notice (info or warning admonition) (optional)
|
2. Version/Module Notice（可选，信息或警告提示块）
|
||||||
3. What You'll Learn (bullet list of outcomes)
|
3. What You'll Learn（结果清单）
|
||||||
4. Prerequisites (info admonition)
|
4. Prerequisites（前置条件提示块）
|
||||||
5. Quick Path (tip admonition - TL;DR summary)
|
5. Quick Path（TL;DR 提示块）
|
||||||
6. Understanding [Topic] (context before steps - tables for phases/agents)
|
6. Understanding [Topic]（步骤前的背景说明，可配表格）
|
||||||
7. Installation (optional)
|
7. Installation（可选）
|
||||||
8. Step 1: [First Major Task]
|
8. Step 1: [First Major Task]
|
||||||
9. Step 2: [Second Major Task]
|
9. Step 2: [Second Major Task]
|
||||||
10. Step 3: [Third Major Task]
|
10. Step 3: [Third Major Task]
|
||||||
11. What You've Accomplished (summary + folder structure)
|
11. What You've Accomplished（总结 + 文件结构）
|
||||||
12. Quick Reference (commands table)
|
12. Quick Reference（skills 表）
|
||||||
13. Common Questions (FAQ format)
|
13. Common Questions（FAQ）
|
||||||
14. Getting Help (community links)
|
14. Getting Help（社区入口）
|
||||||
15. Key Takeaways (tip admonition)
|
15. Key Takeaways（末尾 tip 提示块）
|
||||||
```
|
```
|
||||||
|
|
||||||
### Tutorial Checklist
|
### 教程检查清单
|
||||||
|
|
||||||
- [ ] Hook describes outcome in 1-2 sentences
|
- [ ] Hook 用 1-2 句明确结果
|
||||||
- [ ] "What You'll Learn" section present
|
- [ ] 包含 “What You'll Learn”
|
||||||
- [ ] Prerequisites in admonition
|
- [ ] 前置条件放在 admonition
|
||||||
- [ ] Quick Path TL;DR admonition at top
|
- [ ] 顶部有 Quick Path TL;DR
|
||||||
- [ ] Tables for phases, commands, agents
|
- [ ] 关键信息用 phases/skills/agents 表格
|
||||||
- [ ] "What You've Accomplished" section present
|
- [ ] 包含 “What You've Accomplished”
|
||||||
- [ ] Quick Reference table present
|
- [ ] 包含 Quick Reference 表
|
||||||
- [ ] Common Questions section present
|
- [ ] 包含 Common Questions
|
||||||
- [ ] Getting Help section present
|
- [ ] 包含 Getting Help
|
||||||
- [ ] Key Takeaways admonition at end
|
- [ ] 末尾包含 Key Takeaways 提示块
|
||||||
|
|
||||||
## How-To Structure
|
## How-to 结构
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (one sentence: "Use the `X` workflow to...")
|
1. Title + Hook（单句，形如 "Use the `X` workflow to..."）
|
||||||
2. When to Use This (bullet list of scenarios)
|
2. When to Use This（3-5 条场景）
|
||||||
3. When to Skip This (optional)
|
3. When to Skip This（可选）
|
||||||
4. Prerequisites (note admonition)
|
4. Prerequisites（note 提示块）
|
||||||
5. Steps (numbered ### subsections)
|
5. Steps（编号 `###` 动词开头）
|
||||||
6. What You Get (output/artifacts produced)
|
6. What You Get（产出物说明）
|
||||||
7. Example (optional)
|
7. Example（可选）
|
||||||
8. Tips (optional)
|
8. Tips（可选）
|
||||||
9. Next Steps (optional)
|
9. Next Steps（可选）
|
||||||
```
|
```
|
||||||
|
|
||||||
### How-To Checklist
|
### How-to 检查清单
|
||||||
|
|
||||||
- [ ] Hook starts with "Use the `X` workflow to..."
|
- [ ] Hook 以 “Use the `X` workflow to...” 开头
|
||||||
- [ ] "When to Use This" has 3-5 bullet points
|
- [ ] “When to Use This” 有 3-5 条场景
|
||||||
- [ ] Prerequisites listed
|
- [ ] 明确前置条件
|
||||||
- [ ] Steps are numbered `###` subsections with action verbs
|
- [ ] 步骤为编号 `###` 子标题且动词开头
|
||||||
- [ ] "What You Get" describes output artifacts
|
- [ ] “What You Get” 明确产出物
|
||||||
|
|
||||||
## Explanation Structure
|
## Explanation 结构
|
||||||
|
|
||||||
### Types
|
### 类型
|
||||||
|
|
||||||
| Type | Example |
|
| 类型 | 示例 |
|
||||||
| ----------------- | ----------------------------- |
|
| --- | --- |
|
||||||
| **Index/Landing** | `core-concepts/index.md` |
|
| **Index/Landing** | `core-concepts/index.md` |
|
||||||
| **Concept** | `what-are-agents.md` |
|
| **Concept** | `what-are-agents.md` |
|
||||||
| **Feature** | `quick-dev.md` |
|
| **Feature** | `quick-dev.md` |
|
||||||
| **Philosophy** | `why-solutioning-matters.md` |
|
| **Philosophy** | `why-solutioning-matters.md` |
|
||||||
| **FAQ** | `established-projects-faq.md` |
|
| **FAQ** | `established-projects-faq.md` |
|
||||||
|
|
||||||
### General Template
|
### 通用模板
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (1-2 sentences)
|
1. Title + Hook（1-2 句）
|
||||||
2. Overview/Definition (what it is, why it matters)
|
2. Overview/Definition（是什么，为什么重要）
|
||||||
3. Key Concepts (### subsections)
|
3. Key Concepts（`###` 小节）
|
||||||
4. Comparison Table (optional)
|
4. Comparison Table（可选）
|
||||||
5. When to Use / When Not to Use (optional)
|
5. When to Use / When Not to Use（可选）
|
||||||
6. Diagram (optional - mermaid, 1 per doc max)
|
6. Diagram（可选，单文档最多 1 个 mermaid）
|
||||||
7. Next Steps (optional)
|
7. Next Steps（可选）
|
||||||
```
|
```
|
||||||
|
|
||||||
### Index/Landing Pages
|
### Index/Landing 页面
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (one sentence)
|
1. Title + Hook（单句）
|
||||||
2. Content Table (links with descriptions)
|
2. Content Table（链接 + 描述）
|
||||||
3. Getting Started (numbered list)
|
3. Getting Started（编号步骤）
|
||||||
4. Choose Your Path (optional - decision tree)
|
4. Choose Your Path（可选，决策树）
|
||||||
```
|
```
|
||||||
|
|
||||||
### Concept Explainers
|
### 概念解释页（Concept）
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (what it is)
|
1. Title + Hook（定义性开场）
|
||||||
2. Types/Categories (### subsections) (optional)
|
2. Types/Categories（可选，`###`）
|
||||||
3. Key Differences Table
|
3. Key Differences Table
|
||||||
4. Components/Parts
|
4. Components/Parts
|
||||||
5. Which Should You Use?
|
5. Which Should You Use?
|
||||||
6. Creating/Customizing (pointer to how-to guides)
|
6. Creating/Customizing（指向 how-to）
|
||||||
```
|
```
|
||||||
|
|
||||||
### Feature Explainers
|
### 功能解释页（Feature）
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (what it does)
|
1. Title + Hook（功能作用）
|
||||||
2. Quick Facts (optional - "Perfect for:", "Time to:")
|
2. Quick Facts（可选）
|
||||||
3. When to Use / When Not to Use
|
3. When to Use / When Not to Use
|
||||||
4. How It Works (mermaid diagram optional)
|
4. How It Works（可选 mermaid）
|
||||||
5. Key Benefits
|
5. Key Benefits
|
||||||
6. Comparison Table (optional)
|
6. Comparison Table（可选）
|
||||||
7. When to Graduate/Upgrade (optional)
|
7. When to Graduate/Upgrade（可选）
|
||||||
```
|
```
|
||||||
|
|
||||||
### Philosophy/Rationale Documents
|
### 原理/哲学页（Philosophy）
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (the principle)
|
1. Title + Hook（核心原则）
|
||||||
2. The Problem
|
2. The Problem
|
||||||
3. The Solution
|
3. The Solution
|
||||||
4. Key Principles (### subsections)
|
4. Key Principles（`###`）
|
||||||
5. Benefits
|
5. Benefits
|
||||||
6. When This Applies
|
6. When This Applies
|
||||||
```
|
```
|
||||||
|
|
||||||
### Explanation Checklist
|
### Explanation 检查清单
|
||||||
|
|
||||||
- [ ] Hook states what document explains
|
- [ ] Hook 清楚说明“本文解释什么”
|
||||||
- [ ] Content in scannable `##` sections
|
- [ ] 内容分布在可扫读的 `##` 区块
|
||||||
- [ ] Comparison tables for 3+ options
|
- [ ] 3 个以上选项时使用对比表
|
||||||
- [ ] Diagrams have clear labels
|
- [ ] 图示有清晰标签
|
||||||
- [ ] Links to how-to guides for procedural questions
|
- [ ] 程序性问题链接到 how-to
|
||||||
- [ ] 2-3 admonitions max per document
|
- [ ] 每篇控制在 2-3 个 admonition
|
||||||
|
|
||||||
## Reference Structure
|
## Reference 结构
|
||||||
|
|
||||||
### Types
|
### 类型
|
||||||
|
|
||||||
| Type | Example |
|
| 类型 | 示例 |
|
||||||
| ----------------- | --------------------- |
|
| --- | --- |
|
||||||
| **Index/Landing** | `workflows/index.md` |
|
| **Index/Landing** | `workflows/index.md` |
|
||||||
| **Catalog** | `agents/index.md` |
|
| **Catalog** | `agents/index.md` |
|
||||||
| **Deep-Dive** | `document-project.md` |
|
| **Deep-Dive** | `document-project.md` |
|
||||||
| **Configuration** | `core-tasks.md` |
|
| **Configuration** | `core-tasks.md` |
|
||||||
| **Glossary** | `glossary/index.md` |
|
| **Glossary** | `glossary/index.md` |
|
||||||
| **Comprehensive** | `bmgd-workflows.md` |
|
| **Comprehensive** | `bmgd-workflows.md` |
|
||||||
|
|
||||||
### Reference Index Pages
|
### Reference 索引页
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (one sentence)
|
1. Title + Hook（单句）
|
||||||
2. Content Sections (## for each category)
|
2. Content Sections（每类一个 `##`）
|
||||||
- Bullet list with links and descriptions
|
- 链接 + 简短描述
|
||||||
```
|
```
|
||||||
|
|
||||||
### Catalog Reference
|
### Catalog 参考页
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook
|
1. Title + Hook
|
||||||
2. Items (## for each item)
|
2. Items（每项一个 `##`）
|
||||||
- Brief description (one sentence)
|
- 单句说明
|
||||||
- **Commands:** or **Key Info:** as flat list
|
- **Skills:** 或 **Key Info:** 平铺列表
|
||||||
3. Universal/Shared (## section) (optional)
|
3. Universal/Shared（可选）
|
||||||
```
|
```
|
||||||
|
|
||||||
### Item Deep-Dive Reference
|
### Deep-Dive 参考页
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (one sentence purpose)
|
1. Title + Hook（单句说明用途）
|
||||||
2. Quick Facts (optional note admonition)
|
2. Quick Facts（可选 note 提示块）
|
||||||
- Module, Command, Input, Output as list
|
- Module, Skill, Input, Output
|
||||||
3. Purpose/Overview (## section)
|
3. Purpose/Overview（`##`）
|
||||||
4. How to Invoke (code block)
|
4. How to Invoke（代码块）
|
||||||
5. Key Sections (## for each aspect)
|
5. Key Sections（每个方面一个 `##`）
|
||||||
- Use ### for sub-options
|
- 子选项使用 `###`
|
||||||
6. Notes/Caveats (tip or caution admonition)
|
6. Notes/Caveats（tip/caution）
|
||||||
```
|
```
|
||||||
|
|
||||||
### Configuration Reference
|
### Configuration 参考页
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook
|
1. Title + Hook
|
||||||
2. Table of Contents (jump links if 4+ items)
|
2. Table of Contents（可选，4 项以上建议）
|
||||||
3. Items (## for each config/task)
|
3. Items（每项一个 `##`）
|
||||||
- **Bold summary** — one sentence
|
- **Bold summary**（单句）
|
||||||
- **Use it when:** bullet list
|
- **Use it when:** 场景列表
|
||||||
- **How it works:** numbered steps (3-5 max)
|
- **How it works:** 3-5 步
|
||||||
- **Output:** expected result (optional)
|
- **Output:**（可选）
|
||||||
```
|
```
|
||||||
|
|
||||||
### Comprehensive Reference Guide
|
### 综合参考页（Comprehensive）
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook
|
1. Title + Hook
|
||||||
2. Overview (## section)
|
2. Overview（`##`）
|
||||||
- Diagram or table showing organization
|
- 用图或表解释组织方式
|
||||||
3. Major Sections (## for each phase/category)
|
3. Major Sections（每个阶段/类别一个 `##`）
|
||||||
- Items (### for each item)
|
- Items（每项 `###`）
|
||||||
- Standardized fields: Command, Agent, Input, Output, Description
|
- 统一字段：Skill, Agent, Input, Output, Description
|
||||||
4. Next Steps (optional)
|
4. Next Steps（可选）
|
||||||
```
|
```
|
||||||
|
|
||||||
### Reference Checklist
|
### Reference 检查清单
|
||||||
|
|
||||||
- [ ] Hook states what document references
|
- [ ] Hook 说明“本文引用什么”
|
||||||
- [ ] Structure matches reference type
|
- [ ] 结构匹配参考页类型
|
||||||
- [ ] Items use consistent structure throughout
|
- [ ] 条目结构前后一致
|
||||||
- [ ] Tables for structured/comparative data
|
- [ ] 结构化信息优先表格表达
|
||||||
- [ ] Links to explanation docs for conceptual depth
|
- [ ] 概念深度指向 explanation 页面
|
||||||
- [ ] 1-2 admonitions max
|
- [ ] 每篇 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
|
```md
|
||||||
## Category Name
|
## 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. |
|
| **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..." |
|
| 直接写“它是什么/做什么” | 以 “This is...” 或 “A [term] is...” 开头 |
|
||||||
| Keep to 1-2 sentences | Write multi-paragraph explanations |
|
| 控制在 1-2 句 | 多段长解释 |
|
||||||
| Bold term name in cell | Use plain text for terms |
|
| 术语名称加粗 | 术语用普通文本 |
|
||||||
|
|
||||||
### Context Markers
|
### 语境标记（Context Markers）
|
||||||
|
|
||||||
Add italic context at definition start for limited-scope terms:
|
在定义开头用斜体标记适用范围：
|
||||||
|
|
||||||
- `*Quick Flow only.*`
|
- `*Quick Flow only.*`
|
||||||
- `*BMad Method/Enterprise.*`
|
- `*BMad Method/Enterprise.*`
|
||||||
|
|
@ -330,16 +330,16 @@ Add italic context at definition start for limited-scope terms:
|
||||||
- `*BMGD.*`
|
- `*BMGD.*`
|
||||||
- `*Established projects.*`
|
- `*Established projects.*`
|
||||||
|
|
||||||
### Glossary Checklist
|
### Glossary 检查清单
|
||||||
|
|
||||||
- [ ] Terms in tables, not individual headers
|
- [ ] 术语以表格维护，不用独立标题
|
||||||
- [ ] Terms alphabetized within categories
|
- [ ] 同分类内按字母序排序
|
||||||
- [ ] Definitions 1-2 sentences
|
- [ ] 定义控制在 1-2 句
|
||||||
- [ ] Context markers italicized
|
- [ ] 语境标记使用斜体
|
||||||
- [ ] Term names bolded in cells
|
- [ ] 术语名称在单元格中加粗
|
||||||
- [ ] No "A [term] is..." definitions
|
- [ ] 避免 “A [term] is...” 句式
|
||||||
|
|
||||||
## FAQ Sections
|
## FAQ 章节模板
|
||||||
|
|
||||||
```md
|
```md
|
||||||
## Questions
|
## Questions
|
||||||
|
|
@ -353,18 +353,18 @@ Only for BMad Method and Enterprise tracks. Quick Flow skips to implementation.
|
||||||
|
|
||||||
### Can I change my plan later?
|
### 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](...).
|
**Have a question not answered here?** [Open an issue](...) or ask in [Discord](...).
|
||||||
```
|
```
|
||||||
|
|
||||||
## Validation Commands
|
## 校验命令
|
||||||
|
|
||||||
Before submitting documentation changes:
|
提交文档改动前，建议执行：
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
npm run docs:fix-links # Preview link format fixes
|
npm run docs:fix-links # 预览链接修复结果
|
||||||
npm run docs:fix-links -- --write # Apply fixes
|
npm run docs:fix-links -- --write # 写回链接修复
|
||||||
npm run docs:validate-links # Check links exist
|
npm run docs:validate-links # 校验链接是否存在
|
||||||
npm run docs:build # Verify no build errors
|
npm run docs:build # 校验站点构建
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -5,58 +5,53 @@ sidebar:
|
||||||
order: 6
|
order: 6
|
||||||
---
|
---
|
||||||
|
|
||||||
让 LLM 重新审视它刚刚生成的内容。你选择一种推理方法，它将该方法应用于自己的输出，然后你决定是否保留改进。
|
高级启发（advanced elicitation）是“第二轮思考”机制：不是笼统地让模型“再来一次”，而是让它按指定推理方法重审自己的输出。
|
||||||
|
|
||||||
## 什么是高级启发？
|
## 它是什么
|
||||||
|
|
||||||
结构化的第二轮处理。与其要求 AI "再试一次" 或 "做得更好"，不如选择一种特定的推理方法，让 AI 通过该视角重新审视自己的输出。
|
你先有一版输出（方案、文案、分析或规范），再通过某种推理框架做二次审视，例如：
|
||||||
|
- 事前复盘（Pre-mortem）
|
||||||
|
- 第一性原理
|
||||||
|
- 逆向思维（Inversion）
|
||||||
|
- 红队/蓝队
|
||||||
|
- 苏格拉底式追问
|
||||||
|
|
||||||
这种区别很重要。模糊的请求会产生模糊的修订。命名的方法会强制采用特定的攻击角度，揭示出通用重试会遗漏的见解。
|
这种“带方法名的重审”通常比“再优化一下”更有效，因为它会强制模型从特定角度进攻已有答案。
|
||||||
|
|
||||||
## 何时使用
|
## 什么时候使用
|
||||||
|
|
||||||
- 在工作流生成内容后，你想要替代方案
|
- 你已有可用初稿，但怀疑还不够扎实
|
||||||
- 当输出看起来还可以，但你怀疑还有更深层次的内容
|
- 你想压力测试关键假设或找潜在漏洞
|
||||||
- 对假设进行压力测试或发现弱点
|
- 你面对高风险内容，需要更高置信度
|
||||||
- 对于重新思考有帮助的高风险内容
|
- 你想要替代解法，而不是同义改写
|
||||||
|
|
||||||
工作流在决策点提供高级启发——在 LLM 生成某些内容后，系统会询问你是否要运行它。
|
## 它如何运行
|
||||||
|
|
||||||
## 工作原理
|
1. 模型先给出若干与你内容相关的方法候选
|
||||||
|
2. 你选择一种（或重抽）
|
||||||
|
3. 模型按该方法重审并展示改进
|
||||||
|
4. 你决定采纳、丢弃、继续下一轮或结束
|
||||||
|
|
||||||
1. LLM 为你的内容建议 5 种相关方法
|
:::tip[实战建议]
|
||||||
2. 你选择一种（或重新洗牌以获取不同选项）
|
做规格、方案或计划时，先跑一次“事前复盘”通常收益最高，容易提前暴露隐藏风险。
|
||||||
3. 应用方法，显示改进
|
|
||||||
4. 接受或丢弃，重复或继续
|
|
||||||
|
|
||||||
## 内置方法
|
|
||||||
|
|
||||||
有数十种推理方法可用。几个示例：
|
|
||||||
|
|
||||||
- **事前复盘** - 假设项目已经失败，反向推导找出原因
|
|
||||||
- **第一性原理思维** - 剥离假设，从基本事实重建
|
|
||||||
- **逆向思维** - 询问如何保证失败，然后避免这些事情
|
|
||||||
- **红队对蓝队** - 攻击你自己的工作，然后为它辩护
|
|
||||||
- **苏格拉底式提问** - 用"为什么？"和"你怎么知道？"挑战每个主张
|
|
||||||
- **约束移除** - 放下所有约束，看看有什么变化，然后有选择地加回
|
|
||||||
- **利益相关者映射** - 从每个利益相关者的角度重新评估
|
|
||||||
- **类比推理** - 在其他领域找到平行案例并应用其教训
|
|
||||||
|
|
||||||
还有更多。AI 会为你的内容选择最相关的选项——你选择运行哪一个。
|
|
||||||
|
|
||||||
:::tip[从这里开始]
|
|
||||||
对于任何规范或计划，事前复盘都是一个很好的首选。它始终能找到标准审查会遗漏的空白。
|
|
||||||
:::
|
:::
|
||||||
|
|
||||||
---
|
## 与相近模式的区别
|
||||||
## 术语说明
|
|
||||||
|
|
||||||
- **LLM**：大语言模型。一种基于深度学习的自然语言处理模型，能够理解和生成人类语言。
|
| 模式 | 核心目标 | 典型输入 | 典型输出 |
|
||||||
- **elicitation**：启发。在人工智能与提示工程中，指通过特定方法引导模型生成更高质量或更符合预期的输出。
|
| ----- | ----- | ----- | ----- |
|
||||||
- **pre-mortem analysis**：事前复盘。一种风险管理技术，假设项目已经失败，然后反向推导可能的原因，以提前识别和预防潜在问题。
|
| `advanced elicitation` | 二次推理与补强 | 已有初稿/方案 | 风险更清晰、论证更完整的改进版 |
|
||||||
- **first principles thinking**：第一性原理思维。一种将复杂问题分解为最基本事实或假设，然后从这些基本要素重新构建解决方案的思维方式。
|
| `bmad-brainstorming` | 发散创意并收敛 | 目标模糊或方向开放 | 想法池与行动方向 |
|
||||||
- **inversion**：逆向思维。通过思考如何导致失败来避免失败，从而找到成功路径的思维方式。
|
| `bmad-party-mode` | 多角色讨论权衡 | 需要跨角色协同判断 | 多视角共识或争议点 |
|
||||||
- **red team vs blue team**：红队对蓝队。一种模拟对抗的方法，红队负责攻击和发现问题，蓝队负责防御和解决问题。
|
|
||||||
- **socratic questioning**：苏格拉底式提问。一种通过连续提问来揭示假设、澄清概念和深入思考的对话方法。
|
## 使用边界
|
||||||
- **stakeholder mapping**：利益相关者映射。识别并分析项目中所有利益相关者及其利益、影响和关系的系统性方法。
|
|
||||||
- **analogical reasoning**：类比推理。通过将当前问题与已知相似领域的问题进行比较，从而借鉴解决方案或见解的推理方式。
|
- 它不能替代原始输入质量：初稿太空，二次推理也会受限
|
||||||
|
- 它会产出更多“可疑问题”，需要你做人工判别
|
||||||
|
- 连续多轮会出现收益递减，建议在关键决策点使用
|
||||||
|
|
||||||
|
## 继续阅读
|
||||||
|
|
||||||
|
- [头脑风暴](./brainstorming.md)
|
||||||
|
- [派对模式](./party-mode.md)
|
||||||
|
- [对抗性评审](./adversarial-review.md)
|
||||||
|
|
|
||||||
|
|
@ -1,71 +1,71 @@
|
||||||
---
|
---
|
||||||
title: "对抗性评审"
|
title: "对抗性评审"
|
||||||
description: 防止懒惰"看起来不错"评审的强制推理技术
|
description: 防止懒惰“看起来不错”评审的强制推理技术
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 5
|
order: 5
|
||||||
---
|
---
|
||||||
|
|
||||||
通过要求发现问题来强制进行更深入的分析。
|
对抗性评审（adversarial review）是一种“强制找问题”的评审方法：不允许直接“Looks good”，必须给出可验证发现，或者明确解释为什么没有发现。
|
||||||
|
|
||||||
## 什么是对抗性评审？
|
## 它是什么
|
||||||
|
|
||||||
一种评审技术，评审者*必须*发现问题。不允许"看起来不错"。评审者采取怀疑态度——假设问题存在并找到它们。
|
常规评审容易落入确认偏差：快速扫一遍，没有明显报错，就批准。
|
||||||
|
对抗性评审反过来要求评审者先假设“问题存在”，再去定位证据。
|
||||||
|
|
||||||
这不是为了消极。而是为了强制进行真正的分析，而不是对提交的内容进行草率浏览并盖章批准。
|
核心规则：
|
||||||
|
- 必须产出问题发现或明确的无发现理由
|
||||||
**核心规则：**你必须发现问题。零发现会触发停止——重新分析或解释原因。
|
- 发现要具体、可追溯、可操作
|
||||||
|
- 评审对象是工件本身，而不是作者意图
|
||||||
|
|
||||||
## 为什么有效
|
## 为什么有效
|
||||||
|
|
||||||
普通评审容易受到确认偏差的影响。你浏览工作，没有发现突出的问题，就批准了它。"发现问题"的指令打破了这种模式：
|
- 强制深入阅读，减少“浏览式批准”
|
||||||
|
- 更容易发现“缺了什么”，不只看“写错了什么”
|
||||||
- **强制彻底性**——在你足够努力地查看以发现问题之前，不能批准
|
- 发现通常更结构化，便于后续分诊与修复
|
||||||
- **捕捉遗漏**——"这里缺少什么？"成为一个自然的问题
|
- 在新上下文评审时，能降低“先入为主”偏差
|
||||||
- **提高信号质量**——发现是具体且可操作的，而不是模糊的担忧
|
|
||||||
- **信息不对称**——在新的上下文中运行评审（无法访问原始推理），以便你评估的是工件，而不是意图
|
|
||||||
|
|
||||||
## 在哪里使用
|
## 在哪里使用
|
||||||
|
|
||||||
对抗性评审出现在 BMad 工作流程的各个地方——代码评审、实施就绪检查、规范验证等。有时它是必需步骤，有时是可选的（如高级启发或派对模式）。该模式适应任何需要审查的工件。
|
它不是某个单一 workflow 独占，而是一种可复用评审模式，常见于：
|
||||||
|
- 代码评审
|
||||||
|
- 规范/方案评审
|
||||||
|
- 实施就绪检查
|
||||||
|
- 高风险改动复核
|
||||||
|
|
||||||
## 需要人工过滤
|
## 你需要知道的限制
|
||||||
|
|
||||||
因为 AI 被*指示*要发现问题，它就会发现问题——即使问题不存在。预期会有误报：伪装成问题的吹毛求疵、对意图的误解，或完全幻觉化的担忧。
|
因为系统被要求“必须找问题”，它会提高召回率，也会提高误报率。
|
||||||
|
你会看到：
|
||||||
|
- 吹毛求疵型发现
|
||||||
|
- 语义误解型发现
|
||||||
|
- 偶发幻觉型发现
|
||||||
|
|
||||||
**你决定什么是真实的。**审查每个发现，忽略噪音，修复重要的内容。
|
所以它本质上是**高召回、需人工分诊**的策略，而不是“自动真理机”。
|
||||||
|
|
||||||
## 示例
|
:::caution[关键心法]
|
||||||
|
把发现分成三类：必须修、可延后、可忽略。评审质量的关键不在“发现数量”，而在分诊质量。
|
||||||
而不是：
|
|
||||||
|
|
||||||
> "身份验证实现看起来合理。已批准。"
|
|
||||||
|
|
||||||
对抗性评审产生：
|
|
||||||
|
|
||||||
> 1. **高** - `login.ts:47` - 失败尝试没有速率限制
|
|
||||||
> 2. **高** - 会话令牌存储在 localStorage 中（易受 XSS 攻击）
|
|
||||||
> 3. **中** - 密码验证仅在客户端进行
|
|
||||||
> 4. **中** - 失败登录尝试没有审计日志
|
|
||||||
> 5. **低** - 魔法数字 `3600` 应该是 `SESSION_TIMEOUT_SECONDS`
|
|
||||||
|
|
||||||
第一个评审可能会遗漏安全漏洞。第二个发现了四个。
|
|
||||||
|
|
||||||
## 迭代和收益递减
|
|
||||||
|
|
||||||
在处理发现后，考虑再次运行。第二轮通常会捕获更多。第三轮也不总是无用的。但每一轮都需要时间，最终你会遇到收益递减——只是吹毛求疵和虚假发现。
|
|
||||||
|
|
||||||
:::tip[更好的评审]
|
|
||||||
假设问题存在。寻找缺失的内容，而不仅仅是错误的内容。
|
|
||||||
:::
|
:::
|
||||||
|
|
||||||
---
|
## 与 Quick Dev 的关系
|
||||||
## 术语说明
|
|
||||||
|
|
||||||
- **adversarial review**：对抗性评审。一种强制评审者必须发现问题的评审技术，旨在防止草率批准。
|
`bmad-quick-dev` 关注执行效率与边界控制；对抗性评审关注问题发现质量。
|
||||||
- **confirmation bias**：确认偏差。倾向于寻找、解释和记忆符合自己已有信念的信息的心理倾向。
|
一个解决“跑得稳不稳”，一个解决“看得深不深”，两者互补而非替代。
|
||||||
- **information asymmetry**：信息不对称。交易或评审中一方拥有比另一方更多或更好信息的情况。
|
|
||||||
- **false positives**：误报。错误地将不存在的问题识别为存在的问题。
|
## 示例（对比）
|
||||||
- **diminishing returns**：收益递减。在投入持续增加的情况下，产出增长逐渐减少的现象。
|
|
||||||
- **XSS**：跨站脚本攻击（Cross-Site Scripting）。一种安全漏洞，攻击者可在网页中注入恶意脚本。
|
普通评审可能是：
|
||||||
- **localStorage**：本地存储。浏览器提供的 Web Storage API，用于在客户端存储键值对数据。
|
> “实现基本没问题，先过。”
|
||||||
- **magic number**：魔法数字。代码中直接出现的未命名数值常量，缺乏语义含义。
|
|
||||||
|
对抗性评审更像：
|
||||||
|
> 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,57 @@ sidebar:
|
||||||
order: 2
|
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 负责构建“更容易产生好想法”的过程。
|
||||||
:::
|
:::
|
||||||
|
|
||||||
---
|
## 与相近模式的区别
|
||||||
## 术语说明
|
|
||||||
|
|
||||||
- **brainstorming**：头脑风暴。一种集体或个人的创意生成方法，通过自由联想和发散思维产生大量想法。
|
| 模式 | 核心目标 | 输入状态 | 典型输出 |
|
||||||
- **ideation**：构思。产生想法、概念或解决方案的过程。
|
| ----- | ----- | ----- | ----- |
|
||||||
- **facilitator**：引导者。在会议或工作坊中引导讨论、促进参与并帮助达成目标的人。
|
| `bmad-brainstorming` | 发散并收敛想法 | 方向模糊、问题开放 | 想法清单、优先级、下一步 |
|
||||||
- **creative blocks**：创意瓶颈。在创意过程中遇到的思维停滞或灵感枯竭状态。
|
| `advanced elicitation` | 对已有内容做二次推理 | 已有初稿或方案 | 改进版内容与推理补强 |
|
||||||
- **probing questions**：探索性问题。旨在深入挖掘信息、激发思考或揭示潜在见解的问题。
|
| `bmad-party-mode` | 多角色协同讨论与对齐 | 涉及多方权衡的议题 | 角色视角下的共识或分歧 |
|
||||||
- **stakeholders**：利益相关者。对项目或决策有利益关系或受其影响的个人或群体。
|
|
||||||
|
## 继续阅读
|
||||||
|
|
||||||
|
- [高级启发](./advanced-elicitation.md)
|
||||||
|
- [派对模式](./party-mode.md)
|
||||||
|
- [工作流地图](../reference/workflow-map.md)
|
||||||
|
|
|
||||||
|
|
@ -5,75 +5,54 @@ sidebar:
|
||||||
order: 7
|
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 中验证会话管理需求。这是我的错，没有发现这一点。"
|
:::caution[使用建议]
|
||||||
|
先给清晰议题，再给决策约束（时间、风险、成本、成功标准），讨论质量会明显更高。
|
||||||
**TEA:** "我也应该在集成测试中发现这一点。测试场景没有覆盖并发失效。"
|
|
||||||
|
|
||||||
### 创意头脑风暴
|
|
||||||
|
|
||||||
**You:** "我们如何让入职体验变得神奇，而不是无聊？"
|
|
||||||
|
|
||||||
**UX Designer:** "从渐进式披露开始——在用户需要时揭示功能，而不是在教程中一次性展示所有内容。"
|
|
||||||
|
|
||||||
**Storyteller:** "如果入职是一个故事会怎样？每一步都揭示一个角色的旅程——用户就是英雄。"
|
|
||||||
|
|
||||||
**Game Designer:** "在此基础上——如果第一个'任务'实际上是解决一个真实的用户问题会怎样？他们通过做有价值的事情来学习。"
|
|
||||||
|
|
||||||
### 技术决策
|
|
||||||
|
|
||||||
**You:** "MVP 用单体还是微服务？"
|
|
||||||
|
|
||||||
**Architect:** "从单体开始。微服务会增加你在 1000 用户时不需要的复杂性。"
|
|
||||||
|
|
||||||
**PM:** "同意。上市时间比理论上的可扩展性更重要。"
|
|
||||||
|
|
||||||
**Dev:** "单体，但要有清晰的模块边界。如果需要，我们以后可以提取服务。"
|
|
||||||
|
|
||||||
:::tip[Better Decisions]
|
|
||||||
通过多元视角做出更好的决策。欢迎来到 party mode。
|
|
||||||
:::
|
:::
|
||||||
|
|
||||||
---
|
## 与相近模式的区别
|
||||||
## 术语说明
|
|
||||||
|
|
||||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
| 模式 | 核心目标 | 最佳场景 | 输出形态 |
|
||||||
- **PM**：产品经理（Product Manager）。
|
| ----- | ----- | ----- | ----- |
|
||||||
- **Architect**：架构师。
|
| `bmad-party-mode` | 多角色对齐与权衡 | 跨职能决策、复盘、规划 | 共识点、争议点、决策建议 |
|
||||||
- **Dev**：开发者（Developer）。
|
| `bmad-brainstorming` | 发散创意并收敛 | 方向探索、创意卡点 | 想法池与优先级 |
|
||||||
- **UX Designer**：用户体验设计师。
|
| `advanced elicitation` | 对现有输出做二次推理 | 规格/方案补强 | 改进版内容与风险补充 |
|
||||||
- **TEA**：测试工程师（Test Engineer/Automation）。
|
|
||||||
- **PRD**：产品需求文档（Product Requirements Document）。
|
## 继续阅读
|
||||||
- **MVP**：最小可行产品（Minimum Viable Product）。
|
|
||||||
- **monolith**：单体架构。一种将应用程序构建为单一、统一单元的架构风格。
|
- [头脑风暴](./brainstorming.md)
|
||||||
- **microservices**：微服务。一种将应用程序构建为一组小型、独立服务的架构风格。
|
- [高级启发](./advanced-elicitation.md)
|
||||||
- **progressive disclosure**：渐进式披露。一种交互设计模式，仅在用户需要时显示信息或功能。
|
- [工作流地图](../reference/workflow-map.md)
|
||||||
- **post-mortem**：复盘。对事件或项目进行事后分析，以了解发生了什么以及如何改进。
|
|
||||||
- **sprint**：冲刺。敏捷开发中的固定时间周期，通常为 1-4 周。
|
|
||||||
- **race condition**：竞态条件。当多个进程或线程同时访问和操作共享数据时，系统行为取决于执行顺序的一种情况。
|
|
||||||
- **fallback**：回退机制。当主要方法失败时使用的备用方案。
|
|
||||||
- **time to market**：上市时间。产品从概念到推向市场所需的时间。
|
|
||||||
|
|
|
||||||
|
|
@ -5,69 +5,82 @@ sidebar:
|
||||||
order: 2
|
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)
|
||||||
快速开发通过将审查视为分诊来解决这两个问题。
|
|
||||||
|
|
||||||
一些发现属于当前变更。一些不属于。如果一个发现是附带的而不是与当前工作有因果关系，工作流可以推迟它，而不是强迫人类立即处理它。这使运行保持专注，并防止随机的分支话题消耗注意力的预算。
|
|
||||||
|
|
||||||
那个分诊有时会不完美。这是可以接受的。通常，误判一些发现比用成千上万个低价值的审查评论淹没人类要好。系统正在优化信号质量，而不是详尽的召回率。
|
|
||||||
|
|
|
||||||
|
|
@ -1,41 +1,62 @@
|
||||||
---
|
---
|
||||||
title: "智能体"
|
title: "智能体"
|
||||||
description: 默认 BMM 智能体及其菜单触发器和主要工作流
|
description: 默认 BMM 智能体的 skill ID、触发器与主要 workflow 速查。
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 2
|
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）位于其独立模块中。
|
|
||||||
|
|
||||||
| 智能体 | 触发 | 主要工作流 |
|
- `Skill ID` 是直接调用该智能体的名称（例如 `bmad-dev`）
|
||||||
| --------------------------- | --------------------------------- | --------------------------------------------------------------------------------------------------- |
|
- 触发器是进入智能体会话后可使用的菜单短码
|
||||||
| Analyst (Mary) | `BP`, `RS`, `CB`, `DP` | 头脑风暴项目、研究、创建简报、文档化项目 |
|
- QA（Quinn）是 BMM 内置轻量测试角色；完整 TEA 能力位于独立模块
|
||||||
| 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 生成、验证文档、解释概念 |
|
|
||||||
|
|
||||||
---
|
## 触发器类型
|
||||||
## 术语说明
|
|
||||||
|
|
||||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
### 工作流触发器（通常不需要额外参数）
|
||||||
- **BMM**：BMad Method 中的默认智能体套件，涵盖敏捷开发流程中的各类角色。
|
|
||||||
- **PRD**：产品需求文档（Product Requirements Document）。
|
多数触发器会直接启动结构化 workflow。你只需输入触发码，然后按流程提示提供信息。
|
||||||
- **Epic**：史诗。大型功能或需求集合，可拆分为多个用户故事。
|
|
||||||
- **Story**：用户故事。描述用户需求的简短陈述。
|
示例：`CP`（Create PRD）、`DS`（Dev Story）、`CA`（Create Architecture）、`QD`（Quick Dev）
|
||||||
- **Sprint**：冲刺。敏捷开发中的固定时间周期迭代。
|
|
||||||
- **QA**：质量保证（Quality Assurance）。
|
### 会话触发器（需要附带说明）
|
||||||
- **TEA**：测试架构师（Test Architect）。
|
|
||||||
- **Mermaid**：一种用于生成图表和流程图的文本语法。
|
部分触发器进入自由对话模式，需要你在触发码后描述需求。
|
||||||
|
|
||||||
|
| 智能体 | 触发器 | 你需要提供的内容 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 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: "命令"
|
title: "技能（Skills）"
|
||||||
description: BMad 斜杠命令参考——它们是什么、如何工作以及在哪里找到它们。
|
description: BMad 技能参考：它们是什么、如何生成以及如何调用。
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 3
|
order: 3
|
||||||
---
|
---
|
||||||
|
|
||||||
斜杠命令是预构建的提示词，用于在 IDE 中加载智能体、运行工作流或执行任务。BMad 安装程序在安装时根据已安装的模块生成这些命令。如果您后续添加、删除或更改模块，请重新运行安装程序以保持命令同步（参见[故障排除](#troubleshooting)）。
|
每次运行 `npx bmad-method install`，BMad 会基于你选择的模块生成一组 **skills**。你可以直接输入 skill 名称调用 workflow、任务、工具或智能体角色。
|
||||||
|
|
||||||
## 命令与智能体菜单触发器
|
## Skills 与菜单触发器的区别
|
||||||
|
|
||||||
BMad 提供两种开始工作的方式，它们服务于不同的目的。
|
| 机制 | 调用方式 | 适用场景 |
|
||||||
|
|
||||||
| 机制 | 调用方式 | 发生什么 |
|
|
||||||
| --- | --- | --- |
|
| --- | --- | --- |
|
||||||
| **斜杠命令** | 在 IDE 中输入 `bmad-...` | 直接加载智能体、运行工作流或执行任务 |
|
| **Skill** | 直接输入 skill 名（如 `bmad-help`） | 你已明确要运行哪个功能 |
|
||||||
| **智能体菜单触发器** | 先加载智能体，然后输入简短代码（例如 `DS`） | 智能体解释代码并启动匹配的工作流，同时保持角色设定 |
|
| **智能体菜单触发器** | 先加载智能体，再输入短触发码（如 `DS`） | 你在智能体会话内连续切换任务 |
|
||||||
|
|
||||||
智能体菜单触发器需要活动的智能体会话。当您知道要使用哪个工作流时，使用斜杠命令。当您已经与智能体一起工作并希望在不离开对话的情况下切换任务时，使用触发器。
|
菜单触发器依赖“已激活的智能体会话”；skill 可独立运行。
|
||||||
|
|
||||||
## 命令如何生成
|
## Skills 如何生成
|
||||||
|
|
||||||
当您运行 `npx bmad-method install` 时，安装程序会读取每个选定模块的清单，并为每个智能体、工作流、任务和工具编写一个命令文件。每个文件都是一个简短的 Markdown 提示词，指示 AI 加载相应的源文件并遵循其指令。
|
安装程序会读取已选模块，为每个 agent / workflow / task / tool 生成一个 skill 目录，目录中包含 `SKILL.md` 入口文件。
|
||||||
|
|
||||||
安装程序为每种命令类型使用模板：
|
| Skill 类型 | 生成行为 |
|
||||||
|
|
||||||
| 命令类型 | 生成的文件的作用 |
|
|
||||||
| --- | --- |
|
| --- | --- |
|
||||||
| **智能体启动器** | 加载智能体角色文件，激活其菜单，并保持角色设定 |
|
| Agent launcher | 加载角色设定并激活菜单 |
|
||||||
| **工作流命令** | 加载工作流引擎（`workflow.xml`）并传递工作流配置 |
|
| Workflow skill | 加载 workflow 配置并执行步骤 |
|
||||||
| **任务命令** | 加载独立任务文件并遵循其指令 |
|
| Task skill | 执行独立任务 |
|
||||||
| **工具命令** | 加载独立工具文件并遵循其指令 |
|
| Tool skill | 执行独立工具 |
|
||||||
|
|
||||||
:::note[重新运行安装程序]
|
:::note[模块变更后要重装]
|
||||||
如果您添加或删除模块，请再次运行安装程序。它会重新生成所有命令文件以匹配您当前的模块选择。
|
当你新增、删除或切换模块后，请重新运行安装程序，避免 skill 列表与模块状态不一致。
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## 命令文件的位置
|
## Skill 文件位置
|
||||||
|
|
||||||
安装程序将命令文件写入项目内 IDE 特定的目录中。确切路径取决于您在安装期间选择的 IDE。
|
| IDE / CLI | Skills 目录 |
|
||||||
|
|
||||||
| IDE / CLI | 命令目录 |
|
|
||||||
| --- | --- |
|
| --- | --- |
|
||||||
| Claude Code | `.claude/commands/` |
|
| Claude Code | `.claude/skills/` |
|
||||||
| Cursor | `.cursor/commands/` |
|
| Cursor | `.cursor/skills/` |
|
||||||
| Windsurf | `.windsurf/workflows/` |
|
| Windsurf | `.windsurf/skills/` |
|
||||||
| 其他 IDE | 请参阅安装程序输出中的目标路径 |
|
| 其他 IDE | 以安装器输出路径为准 |
|
||||||
|
|
||||||
所有 IDE 都在其命令目录中接收一组扁平的命令文件。例如，Claude Code 安装看起来像：
|
示例（Claude Code）：
|
||||||
|
|
||||||
```text
|
```text
|
||||||
.claude/commands/
|
.claude/skills/
|
||||||
├── bmad-agent-bmm-dev.md
|
├── bmad-help/
|
||||||
├── bmad-agent-bmm-pm.md
|
│ └── SKILL.md
|
||||||
├── bmad-bmm-create-prd.md
|
├── bmad-create-prd/
|
||||||
├── bmad-editorial-review-prose.md
|
│ └── SKILL.md
|
||||||
├── bmad-help.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[快速定位]
|
||||||
|
不确定该跑哪个 workflow 时，先执行 `bmad-help`，通常比人工翻文档更快。
|
||||||
:::tip[快速发现]
|
|
||||||
项目中生成的命令文件夹是权威列表。在文件资源管理器中打开它们以查看每个命令及其描述。
|
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## 命令类别
|
## Skill 分类与示例
|
||||||
|
|
||||||
### 智能体命令
|
### 智能体技能（Agent Skills）
|
||||||
|
|
||||||
智能体命令加载具有定义角色、沟通风格和工作流菜单的专业化 AI 角色。加载后，智能体保持角色设定并响应菜单触发器。
|
加载一个角色化智能体，并保持其 persona 与菜单上下文。
|
||||||
|
|
||||||
| 示例命令 | 智能体 | 角色 |
|
| 示例 skill | 角色 | 用途 |
|
||||||
| --- | --- | --- |
|
| --- | --- | --- |
|
||||||
| `bmad-agent-bmm-dev` | Amelia（开发者） | 严格按照规范实现故事 |
|
| `bmad-dev` | Developer（Amelia） | 按规范实现 story |
|
||||||
| `bmad-agent-bmm-pm` | John（产品经理） | 创建和验证 PRD |
|
| `bmad-pm` | Product Manager（John） | 创建与校验 PRD |
|
||||||
| `bmad-agent-bmm-architect` | Winston（架构师） | 设计系统架构 |
|
| `bmad-architect` | Architect（Winston） | 架构设计与约束定义 |
|
||||||
| `bmad-agent-bmm-sm` | Bob（Scrum Master） | 管理冲刺和故事 |
|
| `bmad-sm` | Scrum Master（Bob） | 冲刺与 story 流程管理 |
|
||||||
|
|
||||||
参见[智能体](./agents.md)获取默认智能体及其触发器的完整列表。
|
完整列表见 [智能体参考](./agents.md)。
|
||||||
|
|
||||||
### 工作流命令
|
### Workflow Skills
|
||||||
|
|
||||||
工作流命令运行结构化的多步骤过程，而无需先加载智能体角色。它们加载工作流引擎并传递特定的工作流配置。
|
无需先加载 agent，直接运行结构化流程。
|
||||||
|
|
||||||
| 示例命令 | 目的 |
|
| 示例 skill | 用途 |
|
||||||
| --- | --- |
|
| --- | --- |
|
||||||
| `bmad-bmm-create-prd` | 创建产品需求文档 |
|
| `bmad-create-prd` | 创建 PRD |
|
||||||
| `bmad-bmm-create-architecture` | 设计系统架构 |
|
| `bmad-create-architecture` | 创建架构方案 |
|
||||||
| `bmad-bmm-dev-story` | 实现故事 |
|
| `bmad-create-epics-and-stories` | 拆分 epics/stories |
|
||||||
| `bmad-bmm-code-review` | 运行代码审查 |
|
| `bmad-dev-story` | 实现指定 story |
|
||||||
| `bmad-bmm-quick-dev` | 统一快速流程 — 澄清意图、规划、实现、审查、呈现 |
|
| `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 才会刷新。
|
||||||
|
|
||||||
| 示例命令 | 目的 |
|
**缺少预期 skill：** 可能模块未安装或安装时未勾选。重新运行安装程序并确认模块选择。
|
||||||
| --- | --- |
|
|
||||||
| `bmad-shard-doc` | 将大型 Markdown 文件拆分为较小的部分 |
|
|
||||||
| `bmad-index-docs` | 索引项目文档 |
|
|
||||||
| `bmad-editorial-review-prose` | 审查文档散文质量 |
|
|
||||||
|
|
||||||
## 命名约定
|
**已移除模块的 skills 仍存在：** 安装器不会自动清理历史目录。手动删除旧 skill 目录后再重装可获得干净结果。
|
||||||
|
|
||||||
命令名称遵循可预测的模式。
|
## 相关参考
|
||||||
|
|
||||||
| 模式 | 含义 | 示例 |
|
- [智能体参考](./agents.md)
|
||||||
| --- | --- | --- |
|
- [核心工具参考](./core-tools.md)
|
||||||
| `bmad-agent-<module>-<name>` | 智能体启动器 | `bmad-agent-bmm-dev` |
|
- [模块参考](./modules.md)
|
||||||
| `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**：用户体验。用户在使用产品或服务过程中的整体感受和交互体验。
|
|
||||||
|
|
|
||||||
|
|
@ -1,293 +1,233 @@
|
||||||
---
|
---
|
||||||
title: "核心工具"
|
title: "核心工具"
|
||||||
description: 每个 BMad 安装都自带的内置任务和工作流参考。
|
description: 每个 BMad 安装默认可用的任务与 workflow 参考。
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 2
|
order: 2
|
||||||
---
|
---
|
||||||
|
|
||||||
每个 BMad 安装都包含一组核心技能，可以配合你正在做的任何事情使用——跨项目、跨模块、跨阶段的独立任务和工作流。无论安装了哪些可选模块，这些工具始终可用。
|
核心工具是跨模块可复用的一组通用能力：不依赖特定业务项目，也不要求先进入某个智能体角色。只要安装了 BMad，你就可以直接调用它们。
|
||||||
|
|
||||||
:::tip[快速上手]
|
:::tip[快速入口]
|
||||||
在 IDE 中输入技能名称（如 `bmad-help`）即可运行任意核心工具，无需启动智能体会话。
|
在 IDE 中直接输入工具 skill 名（例如 `bmad-help`）即可调用，无需先加载智能体。
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## 概览
|
## 概览
|
||||||
|
|
||||||
| 工具 | 类型 | 用途 |
|
| 工具 | 类型 | 主要用途 |
|
||||||
| --- | --- | --- |
|
| --- | --- | --- |
|
||||||
| [`bmad-help`](#bmad-help) | 任务 | 根据上下文给出下一步建议 |
|
| [`bmad-help`](#bmad-help) | Task | 基于项目上下文推荐下一步 |
|
||||||
| [`bmad-brainstorming`](#bmad-brainstorming) | 工作流 | 引导交互式头脑风暴 |
|
| [`bmad-brainstorming`](#bmad-brainstorming) | Workflow | 引导式头脑风暴与想法扩展 |
|
||||||
| [`bmad-party-mode`](#bmad-party-mode) | 工作流 | 编排多智能体群组讨论 |
|
| [`bmad-party-mode`](#bmad-party-mode) | Workflow | 多智能体协作讨论 |
|
||||||
| [`bmad-distillator`](#bmad-distillator) | 任务 | 无损的 LLM 优化文档压缩 |
|
| [`bmad-distillator`](#bmad-distillator) | Task | 无损压缩文档，提升 LLM 消费效率 |
|
||||||
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | 任务 | 通过迭代精炼方法提升 LLM 输出质量 |
|
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | Task | 通过多轮技法增强 LLM 输出 |
|
||||||
| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | 任务 | 挑刺式审查——找出遗漏和问题 |
|
| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | Task | 对抗式问题发现审查 |
|
||||||
| [`bmad-review-edge-case-hunter`](#bmad-review-edge-case-hunter) | 任务 | 穷举分支路径分析，找出未处理的边界情况 |
|
| [`bmad-review-edge-case-hunter`](#bmad-review-edge-case-hunter) | Task | 边界与分支路径穷举审查 |
|
||||||
| [`bmad-editorial-review-prose`](#bmad-editorial-review-prose) | 任务 | 临床式文案编辑，聚焦表达清晰度 |
|
| [`bmad-editorial-review-prose`](#bmad-editorial-review-prose) | Task | 文案可读性与表达清晰度审查 |
|
||||||
| [`bmad-editorial-review-structure`](#bmad-editorial-review-structure) | 任务 | 结构编辑——裁剪、合并与重组 |
|
| [`bmad-editorial-review-structure`](#bmad-editorial-review-structure) | Task | 文档结构裁剪、合并与重组建议 |
|
||||||
| [`bmad-shard-doc`](#bmad-shard-doc) | 任务 | 将大型 Markdown 文件拆分为有序章节 |
|
| [`bmad-shard-doc`](#bmad-shard-doc) | Task | 将大文档拆分为章节文件 |
|
||||||
| [`bmad-index-docs`](#bmad-index-docs) | 任务 | 生成或更新文件夹的文档索引 |
|
| [`bmad-index-docs`](#bmad-index-docs) | Task | 为目录生成/更新文档索引 |
|
||||||
|
|
||||||
## bmad-help
|
## bmad-help
|
||||||
|
|
||||||
**你的智能向导，告诉你下一步该做什么。** — 检查项目状态，识别已完成的内容，推荐下一个必需或可选步骤。
|
**定位：** 你的默认导航入口，告诉你“下一步该做什么”。
|
||||||
|
|
||||||
**适用场景：**
|
**适用场景：**
|
||||||
|
- 刚完成一个 workflow，不确定如何衔接
|
||||||
|
- 新接触项目，需要先看当前进度
|
||||||
|
- 变更模块后，想知道可用能力和推荐顺序
|
||||||
|
|
||||||
- 完成了一个工作流，想知道接下来做什么
|
**工作机制：**
|
||||||
- 刚接触 BMad，需要快速了解全貌
|
1. 扫描已存在产物（PRD、architecture、stories 等）
|
||||||
- 卡住了，想要根据当前上下文获取建议
|
2. 检测已安装模块及其可用 workflow
|
||||||
- 安装了新模块，想看看有哪些可用功能
|
3. 按优先级输出“必需步骤 + 可选步骤”
|
||||||
|
|
||||||
**工作原理：**
|
**输入：** 可选自然语言问题（如 `bmad-help 我该先做 PRD 还是 architecture？`）
|
||||||
|
**输出：** 带 skill 名称的下一步建议列表
|
||||||
1. 扫描项目中已有的产出物（PRD、架构文档、用户故事等）
|
|
||||||
2. 检测已安装的模块及其可用工作流
|
|
||||||
3. 按优先级推荐下一步——必需步骤优先，可选步骤其次
|
|
||||||
4. 每条推荐都附带技能命令和简要说明
|
|
||||||
|
|
||||||
**输入：** 可选的自然语言查询（如 `bmad-help I have a SaaS idea, where do I start?`）
|
|
||||||
|
|
||||||
**输出：** 按优先级排列的下一步推荐列表，附带技能命令
|
|
||||||
|
|
||||||
## bmad-brainstorming
|
## bmad-brainstorming
|
||||||
|
|
||||||
**通过交互式创意技法激发多样想法。** — 引导式头脑风暴会话，从技法库中加载经过验证的创意方法，引导你在整理之前先产出 100+ 个想法。
|
**定位：** 用结构化创意技法快速扩展想法池。
|
||||||
|
|
||||||
**适用场景：**
|
**适用场景：**
|
||||||
|
- 启动新主题，想先打开问题空间
|
||||||
|
- 团队卡在同一思路，需要外部技法打破惯性
|
||||||
|
- 需要把“模糊方向”变成可讨论候选方案
|
||||||
|
|
||||||
- 启动新项目，需要探索问题空间
|
**工作机制：**
|
||||||
- 想法枯竭，需要结构化的创意引导
|
1. 建立主题会话
|
||||||
- 想使用成熟的创意框架（SCAMPER、反向头脑风暴等）
|
2. 从方法库选择创意技法
|
||||||
|
3. 逐轮引导产出并记录想法
|
||||||
|
4. 生成可追溯的会话文档
|
||||||
|
|
||||||
**工作原理：**
|
**输入：** 主题或问题陈述（可附上下文文件）
|
||||||
|
**输出：** `brainstorming-session-{date}.md`
|
||||||
1. 围绕你的主题建立头脑风暴会话
|
|
||||||
2. 从方法库中加载创意技法
|
|
||||||
3. 逐个技法引导你产出想法
|
|
||||||
4. 应用反偏差协议——每产出 10 个想法切换一次创意领域，防止想法扎堆
|
|
||||||
5. 生成一份只追加的会话文档，所有想法按技法分类整理
|
|
||||||
|
|
||||||
**输入：** 头脑风暴主题或问题陈述，可选上下文文件
|
|
||||||
|
|
||||||
**输出：** `brainstorming-session-{date}.md`，包含所有产出的想法
|
|
||||||
|
|
||||||
:::note[数量目标]
|
|
||||||
真正的好点子往往出现在第 50-100 个想法之间。工作流鼓励在整理之前先产出 100+ 个想法。
|
|
||||||
:::
|
|
||||||
|
|
||||||
## bmad-party-mode
|
## 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
|
## bmad-distillator
|
||||||
|
|
||||||
**无损的 LLM 优化文档压缩。** — 生成信息密度高、token 高效的精馏文档，保留全部信息供下游 LLM 消费。可通过往返重构验证无损性。
|
**定位：** 在不丢失信息前提下压缩文档，降低 token 成本。
|
||||||
|
|
||||||
**适用场景：**
|
**适用场景：**
|
||||||
|
- 源文档超过上下文窗口
|
||||||
|
- 需要把研究/规格材料转成高密度引用版本
|
||||||
|
- 想验证压缩结果是否可逆
|
||||||
|
|
||||||
- 文档太大，超出 LLM 的上下文窗口
|
**工作机制：**
|
||||||
- 需要研究资料、规格或规划产出物的 token 高效版本
|
1. 分析源文档结构与信息密度
|
||||||
- 想验证压缩过程中没有丢失信息
|
2. 压缩为高密度结构化表达
|
||||||
- 智能体需要频繁引用和检索其中的信息
|
3. 校验信息完整性
|
||||||
|
4. 可选执行往返重构验证（round-trip）
|
||||||
**工作原理：**
|
|
||||||
|
|
||||||
1. **分析** — 读取源文档，识别信息密度和结构
|
|
||||||
2. **压缩** — 将散文转为密集的要点格式，剥离装饰性排版
|
|
||||||
3. **校验** — 检查完整性，确保原始信息全部保留
|
|
||||||
4. **验证**（可选）— 往返重构测试，证明压缩无损
|
|
||||||
|
|
||||||
**输入：**
|
**输入：**
|
||||||
|
- `source_documents`（必填）
|
||||||
|
- `downstream_consumer`（可选）
|
||||||
|
- `token_budget`（可选）
|
||||||
|
- `--validate`（可选标志）
|
||||||
|
|
||||||
- `source_documents`（必填）— 文件路径、文件夹路径或 glob 模式
|
**输出：** 精馏文档 + 压缩比报告
|
||||||
- `downstream_consumer`（可选）— 消费方是什么（如 "PRD creation"）
|
|
||||||
- `token_budget`（可选）— 大致目标大小
|
|
||||||
- `--validate`（标志）— 运行往返重构测试
|
|
||||||
|
|
||||||
**输出：** 精馏 Markdown 文件，附带压缩比报告（如 "3.2:1"）
|
|
||||||
|
|
||||||
## bmad-advanced-elicitation
|
## bmad-advanced-elicitation
|
||||||
|
|
||||||
**通过迭代精炼方法提升 LLM 输出质量。** — 从启发技法库中选取合适的方法，通过多轮迭代系统性地改进内容。
|
**定位：** 对已有 LLM 输出做第二轮深挖与改写强化。
|
||||||
|
|
||||||
**适用场景：**
|
**适用场景：**
|
||||||
|
- 结果“看起来对”，但深度不够
|
||||||
|
- 想从多个思维框架交叉审视同一内容
|
||||||
|
- 在交付前提升论证质量与完整性
|
||||||
|
|
||||||
- LLM 输出感觉浅薄或千篇一律
|
**工作机制：**
|
||||||
- 想从多个分析角度深挖一个话题
|
1. 加载启发技法库
|
||||||
- 正在打磨关键文档，需要更深层的思考
|
2. 选择匹配内容的候选技法
|
||||||
|
3. 交互式选择并应用技法
|
||||||
|
4. 多轮迭代直到你确认收敛
|
||||||
|
|
||||||
**工作原理：**
|
**输入：** 待增强内容片段
|
||||||
|
**输出：** 增强后的内容版本
|
||||||
1. 加载包含 5+ 种启发技法的方法注册表
|
|
||||||
2. 根据内容类型和复杂度选出 5 个最匹配的方法
|
|
||||||
3. 呈现交互菜单——选一个方法、重新洗牌或列出全部
|
|
||||||
4. 将选中的方法应用到内容上进行增强
|
|
||||||
5. 重新呈现选项，反复迭代改进，直到你选择"继续"
|
|
||||||
|
|
||||||
**输入：** 待增强的内容段落
|
|
||||||
|
|
||||||
**输出：** 应用改进后的增强版内容
|
|
||||||
|
|
||||||
## bmad-review-adversarial-general
|
## bmad-review-adversarial-general
|
||||||
|
|
||||||
**预设问题存在，然后去找出来的挑刺式审查。** — 以怀疑、挑剔的审查者视角，对粗糙工作零容忍。重点找遗漏，而不只是找错误。
|
**定位：** 假设问题存在，主动寻找遗漏与风险。
|
||||||
|
|
||||||
**适用场景：**
|
**适用场景：**
|
||||||
|
- 文档/规格/实现即将交付前
|
||||||
|
- 想补足“乐观审查”容易漏掉的问题
|
||||||
|
- 需要对关键变更做压力测试
|
||||||
|
|
||||||
- 在交付物定稿前需要质量保证
|
**工作机制：**
|
||||||
- 想对规格、用户故事或文档进行压力测试
|
1. 以怀疑视角检查内容
|
||||||
- 想找到乐观审查容易忽略的覆盖盲区
|
2. 从完整性、正确性、质量三个维度找问题
|
||||||
|
3. 强制关注“缺失内容”，而非仅纠错
|
||||||
|
|
||||||
**工作原理：**
|
**输入：** `content`（必填），`also_consider`（可选）
|
||||||
|
**输出：** 结构化问题清单
|
||||||
1. 以挑剔、批判的视角阅读内容
|
|
||||||
2. 从完整性、正确性和质量三个维度识别问题
|
|
||||||
3. 专门寻找遗漏的内容——不只是已有内容中的错误
|
|
||||||
4. 至少找出 10 个问题，否则进行更深层分析
|
|
||||||
|
|
||||||
**输入：**
|
|
||||||
|
|
||||||
- `content`（必填）— diff、规格、用户故事、文档或任意产出物
|
|
||||||
- `also_consider`（可选）— 需要额外关注的领域
|
|
||||||
|
|
||||||
**输出：** 包含 10+ 条发现及描述的 Markdown 列表
|
|
||||||
|
|
||||||
## bmad-review-edge-case-hunter
|
## bmad-review-edge-case-hunter
|
||||||
|
|
||||||
**遍历每条分支路径和边界条件，只报告未处理的情况。** — 纯路径追踪方法论，机械地推导边界类别。与对抗式审查正交——靠方法驱动，而非靠态度驱动。
|
**定位：** 穷举分支路径与边界条件，只报告未覆盖情况。
|
||||||
|
|
||||||
**适用场景：**
|
**适用场景：**
|
||||||
|
- 审查核心逻辑的边界健壮性
|
||||||
|
- 对 diff 做路径级覆盖检查
|
||||||
|
- 与 adversarial review 形成互补
|
||||||
|
|
||||||
- 想对代码或逻辑做穷举式边界覆盖
|
**工作机制：**
|
||||||
- 需要与对抗式审查互补（不同方法论，不同发现）
|
1. 枚举所有分支路径
|
||||||
- 正在审查 diff 或函数的边界条件
|
2. 推导边界类别（missing default、off-by-one、竞态等）
|
||||||
|
3. 检查每条路径是否已有防护
|
||||||
|
4. 仅输出未处理路径
|
||||||
|
|
||||||
**工作原理：**
|
**输入：** `content`（必填），`also_consider`（可选）
|
||||||
|
**输出：** JSON 发现列表（含触发条件与潜在后果）
|
||||||
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` 可获得正交覆盖。对抗式审查捕捉质量和完整性问题；边界猎手捕捉未处理的路径。
|
|
||||||
:::
|
|
||||||
|
|
||||||
## bmad-editorial-review-prose
|
## bmad-editorial-review-prose
|
||||||
|
|
||||||
**聚焦表达清晰度的临床式文案编辑。** — 审查文本中阻碍理解的问题，以 Microsoft 写作风格指南为基准，保留作者个人风格。
|
**定位：** 聚焦表达清晰度的文案审查，不替你改写个人风格。
|
||||||
|
|
||||||
**适用场景：**
|
**适用场景：**
|
||||||
|
- 内容可用，但读起来费劲
|
||||||
|
- 需要针对特定读者提升可理解性
|
||||||
|
- 想做“表达修复”而非“立场重写”
|
||||||
|
|
||||||
- 写完初稿想打磨文字
|
**工作机制：**
|
||||||
- 需要确保内容对特定受众足够清晰
|
1. 跳过 frontmatter 与代码块读取正文
|
||||||
- 只想修表达问题，不想改写风格偏好
|
2. 标记影响理解的表达问题
|
||||||
|
3. 去重同类问题并输出修订建议
|
||||||
|
|
||||||
**工作原理：**
|
**输入：** `content`（必填），`style_guide`（可选），`reader_type`（可选）
|
||||||
|
**输出：** 三列表（原文 / 修改后 / 说明）
|
||||||
1. 阅读内容，跳过代码块和 frontmatter
|
|
||||||
2. 识别表达问题（不是风格偏好）
|
|
||||||
3. 对多处出现的相同问题去重
|
|
||||||
4. 生成三列修改表
|
|
||||||
|
|
||||||
**输入：**
|
|
||||||
|
|
||||||
- `content`（必填）— Markdown、纯文本或 XML
|
|
||||||
- `style_guide`（可选）— 项目特定的写作风格指南
|
|
||||||
- `reader_type`（可选）— `humans`（默认）注重清晰流畅，`llm` 注重精确一致
|
|
||||||
|
|
||||||
**输出：** 三列 Markdown 表格：原文 | 修改后 | 变更说明
|
|
||||||
|
|
||||||
## bmad-editorial-review-structure
|
## bmad-editorial-review-structure
|
||||||
|
|
||||||
**结构编辑——提出裁剪、合并、移动和精简建议。** — 审查文档组织结构，在文案编辑之前提出实质性调整建议，以改善清晰度和阅读流畅性。
|
**定位：** 处理文档结构问题：裁剪、合并、重排、精简。
|
||||||
|
|
||||||
**适用场景：**
|
**适用场景：**
|
||||||
|
- 文档是多来源拼接，结构不连贯
|
||||||
|
- 想在不丢信息前提下降低篇幅
|
||||||
|
- 重要信息被埋在低优先级段落
|
||||||
|
|
||||||
- 文档由多个子流程产出，需要结构上的连贯性
|
**工作机制：**
|
||||||
- 想在保持可读性的前提下缩减文档篇幅
|
1. 按结构模型分析文档组织
|
||||||
- 需要识别范围越界或关键信息被埋没的情况
|
2. 识别冗余、越界与信息埋没
|
||||||
|
3. 输出优先级建议与压缩预估
|
||||||
|
|
||||||
**工作原理：**
|
**输入：** `content`（必填），`purpose`/`target_audience`/`reader_type`/`length_target`（可选）
|
||||||
|
**输出：** 结构建议清单 + 预计缩减量
|
||||||
1. 将文档与 5 种结构模型对照分析（教程、参考、解释、提示词、战略）
|
|
||||||
2. 识别冗余、范围越界和被埋没的信息
|
|
||||||
3. 生成优先级排序的建议：裁剪、合并、移动、精简、质疑、保留
|
|
||||||
4. 估算总缩减字数和百分比
|
|
||||||
|
|
||||||
**输入：**
|
|
||||||
|
|
||||||
- `content`（必填）— 待审查的文档
|
|
||||||
- `purpose`（可选）— 预期用途（如 "quickstart tutorial"）
|
|
||||||
- `target_audience`（可选）— 目标读者
|
|
||||||
- `reader_type`（可选）— `humans` 或 `llm`
|
|
||||||
- `length_target`（可选）— 目标缩减量（如 "30% shorter"）
|
|
||||||
|
|
||||||
**输出：** 文档摘要、优先级排序的建议列表，以及预估缩减量
|
|
||||||
|
|
||||||
## bmad-shard-doc
|
## bmad-shard-doc
|
||||||
|
|
||||||
**将大型 Markdown 文件拆分为有序的章节文件。** — 以二级标题为分割点，创建一个包含独立章节文件和索引的文件夹。
|
**定位：** 把超大 Markdown 文档拆成可维护章节。
|
||||||
|
|
||||||
**适用场景：**
|
**适用场景：**
|
||||||
|
- 单文件过大（常见 500+ 行）
|
||||||
|
- 需要并行编辑或分段维护
|
||||||
|
- 希望降低 LLM 读取成本
|
||||||
|
|
||||||
- Markdown 文档过大，难以有效管理（500+ 行）
|
**工作机制：**
|
||||||
- 想把单体文档拆分成可导航的章节
|
1. 校验源文件
|
||||||
- 需要独立文件以支持并行编辑或 LLM 上下文管理
|
2. 按 `##` 二级标题分片
|
||||||
|
3. 生成 `index.md` 与编号章节
|
||||||
|
4. 提示保留/归档/删除原文件
|
||||||
|
|
||||||
**工作原理：**
|
**输入：** 源文件路径（可选目标目录）
|
||||||
|
**输出：** 分片目录（含 `index.md`）
|
||||||
1. 验证源文件存在且是 Markdown 格式
|
|
||||||
2. 按二级（`##`）标题分割为编号章节文件
|
|
||||||
3. 创建 `index.md`，包含章节清单和链接
|
|
||||||
4. 提示你选择删除、归档还是保留原文件
|
|
||||||
|
|
||||||
**输入：** 源 Markdown 文件路径，可选目标文件夹
|
|
||||||
|
|
||||||
**输出：** 包含 `index.md` 和 `01-{section}.md`、`02-{section}.md` 等文件的文件夹
|
|
||||||
|
|
||||||
## bmad-index-docs
|
## bmad-index-docs
|
||||||
|
|
||||||
**生成或更新文件夹中所有文档的索引。** — 扫描目录，读取每个文件以理解其用途，生成一份带链接和描述的有序 `index.md`。
|
**定位：** 为目录自动生成可导航文档索引。
|
||||||
|
|
||||||
**适用场景：**
|
**适用场景：**
|
||||||
|
- 文档目录持续增长，需要统一入口
|
||||||
|
- 想给 LLM 或新人快速提供全局视图
|
||||||
|
- 需要保持索引与目录同步
|
||||||
|
|
||||||
- 需要一个轻量索引供 LLM 快速扫描可用文档
|
**工作机制：**
|
||||||
- 文档文件夹不断增长，需要一个有序的目录
|
1. 扫描目录内非隐藏文件
|
||||||
- 想要一份自动生成、能持续保持最新的概览
|
2. 读取文件并提炼用途
|
||||||
|
3. 按类型/主题组织条目
|
||||||
|
4. 生成描述简洁的 `index.md`
|
||||||
|
|
||||||
**工作原理：**
|
**输入：** 目标目录路径
|
||||||
|
**输出：** 更新后的 `index.md`
|
||||||
|
|
||||||
1. 扫描目标目录中所有非隐藏文件
|
## 相关参考
|
||||||
2. 读取每个文件以理解其实际用途
|
|
||||||
3. 按类型、用途或子目录分组
|
|
||||||
4. 生成简洁描述（每条 3-10 个词）
|
|
||||||
|
|
||||||
**输入：** 目标文件夹路径
|
- [技能（Skills）参考](./commands.md)
|
||||||
|
- [智能体参考](./agents.md)
|
||||||
**输出：** `index.md`，包含有序的文件列表、相对链接和简要描述
|
- [工作流地图](./workflow-map.md)
|
||||||
|
|
|
||||||
|
|
@ -1,94 +1,94 @@
|
||||||
---
|
---
|
||||||
title: "官方模块"
|
title: "官方模块"
|
||||||
description: 用于构建自定义智能体、创意智能、游戏开发和测试的附加模块
|
description: BMad 可选模块参考：能力边界、适用场景与外部资源
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 4
|
order: 4
|
||||||
---
|
---
|
||||||
|
|
||||||
BMad 通过您在安装期间选择的官方模块进行扩展。这些附加模块为内置核心和 BMM（敏捷套件）之外的特定领域提供专门的智能体、工作流和任务。
|
BMad 通过可选模块扩展能力。你可以在安装时按需选择模块，为当前项目增加特定领域的 `agent`、`workflow` 与 `skill`。
|
||||||
|
|
||||||
:::tip[安装模块]
|
:::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`
|
## BMad Builder（`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”的元模块，重点是把你的方法沉淀成可复用能力。
|
||||||
|
|
||||||
- 智能体构建器 —— 创建具有自定义专业知识和工具访问权限的专用 AI 智能体
|
**你会得到：**
|
||||||
- 工作流构建器 —— 设计包含步骤和决策点的结构化流程
|
- Agent Builder：创建具备特定专业能力的 agent
|
||||||
- 模块构建器 —— 将智能体和工作流打包为可共享、可发布的模块
|
- Workflow Builder：设计有步骤与决策点的 workflow
|
||||||
- 交互式设置，支持 YAML 配置和 npm 发布
|
- 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、逆向头脑风暴等）
|
||||||
|
|
||||||
- 创新策略师、设计思维教练和头脑风暴教练智能体
|
**外部资源（英文）：**
|
||||||
- 问题解决者和创意问题解决者，用于系统性和横向思维
|
- 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)
|
||||||
- 构思框架，包括 SCAMPER、逆向头脑风暴和问题重构
|
|
||||||
|
|
||||||
## 游戏开发工作室
|
## 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)
|
- 游戏设计文档（GDD）生成流程
|
||||||
- **GitHub：** [bmad-code-org/bmad-module-game-dev-studio](https://github.com/bmad-code-org/bmad-module-game-dev-studio)
|
- 面向快速迭代的 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）生成工作流
|
## Test Architect（TEA，`tea`）
|
||||||
- 用于快速原型制作的 Quick Dev 模式
|
|
||||||
- 针对角色、对话和世界构建的叙事设计支持
|
|
||||||
- 覆盖 21+ 种游戏类型，并提供特定引擎的架构指导
|
|
||||||
|
|
||||||
## 测试架构师（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)
|
- 文档: [TEA Module Docs](https://bmad-code-org.github.io/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)
|
- 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 智能体（主测试架构师和质量顾问）
|
- 你要“扩展框架能力”而不是只用框架：优先 `bmb`
|
||||||
- 用于测试设计、ATDD、自动化、测试审查和可追溯性的工作流
|
- 你还在探索方向、需要结构化创意过程：优先 `cis`
|
||||||
- NFR 评估、CI 设置和框架脚手架
|
- 你是游戏项目：优先 `gds`
|
||||||
- P0-P3 优先级排序，可选 Playwright Utils 和 MCP 集成
|
- 你需要测试治理、质量门控或审计追溯：优先 `tea`
|
||||||
|
|
||||||
## 社区模块
|
:::note[模块可以组合安装]
|
||||||
|
模块之间不是互斥关系。你可以按项目阶段增量安装，并在后续重新运行安装器同步 skills。
|
||||||
|
:::
|
||||||
|
|
||||||
社区模块和模块市场即将推出。请查看 [BMad GitHub 组织](https://github.com/bmad-code-org) 获取最新更新。
|
## 相关参考
|
||||||
|
|
||||||
---
|
- [测试选项](./testing.md)
|
||||||
## 术语说明
|
- [技能（Skills）参考](./commands.md)
|
||||||
|
- [工作流地图](./workflow-map.md)
|
||||||
- **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**：快速流程。一种用于快速原型开发的工作流模式。
|
|
||||||
|
|
|
||||||
|
|
@ -1,122 +1,105 @@
|
||||||
---
|
---
|
||||||
title: "测试选项"
|
title: "测试选项"
|
||||||
description: 比较内置 QA 智能体（Quinn）与测试架构师（TEA）模块的测试自动化。
|
description: 内置 QA（Quinn）与 TEA 模块对比：何时用哪个、各自边界是什么
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 5
|
order: 5
|
||||||
---
|
---
|
||||||
|
|
||||||
BMad 提供两条测试路径：用于快速生成测试的内置 QA 智能体，以及用于企业级测试策略的可安装测试架构师模块。
|
BMad 有两条测试路径：
|
||||||
|
- **Quinn（内置 QA）**：快速生成可运行测试
|
||||||
|
- **TEA（可选模块）**：企业级测试策略与治理能力
|
||||||
|
|
||||||
## 应该使用哪一个？
|
## 该选 Quinn 还是 TEA？
|
||||||
|
|
||||||
| 因素 | Quinn（内置 QA） | TEA 模块 |
|
| 维度 | Quinn（内置 QA） | TEA 模块 |
|
||||||
| --- | --- | --- |
|
| --- | --- | --- |
|
||||||
| **最适合** | 中小型项目、快速覆盖 | 大型项目、受监管或复杂领域 |
|
| 最适合 | 中小项目、快速补覆盖 | 大型项目、受监管或复杂业务 |
|
||||||
| **设置** | 无需安装——包含在 BMM 中 | 通过 `npx bmad-method install` 单独安装 |
|
| 安装成本 | 无需额外安装（BMM 内置） | 需通过安装器单独选择 |
|
||||||
| **方法** | 快速生成测试，稍后迭代 | 先规划，再生成并保持可追溯性 |
|
| 方法 | 先生成测试，再迭代 | 先定义策略，再执行并追溯 |
|
||||||
| **测试类型** | API 和 E2E 测试 | API、E2E、ATDD、NFR 等 |
|
| 测试类型 | API + E2E | API、E2E、ATDD、NFR 等 |
|
||||||
| **策略** | 快乐路径 + 关键边界情况 | 基于风险的优先级排序（P0-P3） |
|
| 风险策略 | 快乐路径 + 关键边界 | P0-P3 风险优先级 |
|
||||||
| **工作流数量** | 1（Automate） | 9（设计、ATDD、自动化、审查、可追溯性等） |
|
| workflow 数量 | 1（Automate） | 9（设计/自动化/审查/追溯等） |
|
||||||
|
|
||||||
:::tip[从 Quinn 开始]
|
:::tip[默认建议]
|
||||||
大多数项目应从 Quinn 开始。如果后续需要测试策略、质量门控或需求可追溯性，可并行安装 TEA。
|
大多数项目先用 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. **识别功能**——询问要测试的内容或自动发现代码库中的功能。
|
- 仅使用标准框架 API
|
||||||
3. **生成 API 测试**——覆盖状态码、响应结构、快乐路径和 1-2 个错误情况。
|
- UI 测试优先语义定位器（角色、标签、文本）
|
||||||
4. **生成 E2E 测试**——使用语义定位器和可见结果断言覆盖用户工作流。
|
- 测试互相独立，不依赖顺序
|
||||||
5. **运行并验证**——执行生成的测试并立即修复失败。
|
- 避免硬编码等待/休眠
|
||||||
|
|
||||||
Quinn 会生成测试摘要，保存到项目的实现产物文件夹中。
|
:::note[范围边界]
|
||||||
|
Quinn 只负责“生成测试”。如需实现质量评审与故事验收，请配合代码审查 workflow（`CR` / `bmad-code-review`）。
|
||||||
### 测试模式
|
|
||||||
|
|
||||||
生成的测试遵循"简单且可维护"的理念：
|
|
||||||
|
|
||||||
- **仅使用标准框架 API**——不使用外部工具或自定义抽象
|
|
||||||
- UI 测试使用**语义定位器**（角色、标签、文本而非 CSS 选择器）
|
|
||||||
- **独立测试**，无顺序依赖
|
|
||||||
- **无硬编码等待或休眠**
|
|
||||||
- **清晰的描述**，可作为功能文档阅读
|
|
||||||
|
|
||||||
:::note[范围]
|
|
||||||
Quinn 仅生成测试。如需代码审查和故事验证，请改用代码审查工作流（`CR`）。
|
|
||||||
:::
|
:::
|
||||||
|
|
||||||
### 何时使用 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 模块
|
- 文档: [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)
|
- 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 | 创建与需求关联的全面测试策略 |
|
| Test Design | 按需求建立测试策略 |
|
||||||
| ATDD | 基于干系人标准的验收测试驱动开发 |
|
| ATDD | 基于验收标准驱动测试设计 |
|
||||||
| Automate | 使用高级模式和工具生成测试 |
|
| Automate | 使用高级模式生成自动化测试 |
|
||||||
| Test Review | 根据策略验证测试质量和覆盖范围 |
|
| Test Review | 评估测试质量与覆盖完整性 |
|
||||||
| Traceability | 将测试映射回需求，用于审计和合规 |
|
| Traceability | 建立“需求—测试”追溯链路 |
|
||||||
| NFR Assessment | 评估非功能性需求（性能、安全性） |
|
| NFR Assessment | 评估性能/安全等非功能需求 |
|
||||||
| CI Setup | 在持续集成管道中配置测试执行 |
|
| CI Setup | 配置 CI 中的测试执行 |
|
||||||
| Framework Scaffolding | 设置测试基础设施和项目结构 |
|
| Framework Scaffolding | 搭建测试工程基础结构 |
|
||||||
| Release Gate | 基于数据做出发布/不发布决策 |
|
| 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`）实现一个故事
|
Quinn 主要依据代码直接生成测试；TEA 可结合上游规划产物（如 PRD、architecture）实现更强追溯。
|
||||||
2. 使用 Quinn（`QA`）或 TEA 的 Automate 工作流生成测试
|
|
||||||
3. 使用代码审查（`CR`）验证实现
|
|
||||||
|
|
||||||
Quinn 直接从源代码工作，无需加载规划文档（PRD、架构）。TEA 工作流可以与上游规划产物集成以实现可追溯性。
|
## 相关参考
|
||||||
|
|
||||||
有关测试在整体流程中的位置，请参阅[工作流图](./workflow-map.md)。
|
- [官方模块](./modules.md)
|
||||||
|
- [工作流地图](./workflow-map.md)
|
||||||
---
|
- [智能体参考](./agents.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 模型与外部工具之间通信的协议。
|
|
||||||
|
|
|
||||||
|
|
@ -1,103 +1,86 @@
|
||||||
---
|
---
|
||||||
title: "工作流程图"
|
title: "工作流地图"
|
||||||
description: BMad Method 工作流程阶段与输出的可视化参考
|
description: BMad Method 各阶段 workflow 与产出速查
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 1
|
order: 1
|
||||||
---
|
---
|
||||||
|
|
||||||
BMad Method（BMM）是 BMad 生态系统中的一个模块，旨在遵循上下文工程与规划的最佳实践。AI 智能体在清晰、结构化的上下文中表现最佳。BMM 系统在 4 个不同阶段中逐步构建该上下文——每个阶段以及每个阶段内的多个可选工作流程都会生成文档，这些文档为下一阶段提供信息，因此智能体始终知道要构建什么以及为什么。
|
BMad Method（BMM）通过分阶段 workflow 逐步构建上下文，让智能体始终知道“做什么、为什么做、如何做”。这张地图用于快速查阅阶段目标、关键 workflow 和对应产出。
|
||||||
|
|
||||||
其基本原理和概念来自敏捷方法论，这些方法论在整个行业中被广泛用作思维框架，并取得了巨大成功。
|
如果你不确定下一步，优先运行 `bmad-help`。它会基于你当前项目状态和已安装模块给出实时建议。
|
||||||
|
|
||||||
如果您在任何时候不确定该做什么，`bmad-help` 命令将帮助您保持正轨或了解下一步该做什么。您也可以随时参考此文档以获取参考信息——但如果您已经安装了 BMad Method，`bmad-help` 是完全交互式的，速度要快得多。此外，如果您正在使用扩展了 BMad Method 或添加了其他互补非扩展模块的不同模块——`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>
|
<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;">
|
<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>
|
</p>
|
||||||
|
|
||||||
## 阶段 1：分析（可选）
|
## 阶段 1：分析（可选）
|
||||||
|
|
||||||
在投入规划之前探索问题空间并验证想法。
|
在正式规划前，先验证问题空间与关键假设。
|
||||||
|
|
||||||
| 工作流程 | 目的 | 产出 |
|
| Workflow | 目的 | 产出 |
|
||||||
| ------------------------------- | -------------------------------------------------------------------------- | ------------------------- |
|
| --- | --- | --- |
|
||||||
| `bmad-brainstorming` | 在头脑风暴教练的引导协助下进行项目想法头脑风暴 | `brainstorming-report.md` |
|
| `bmad-brainstorming` | 通过引导式创意方法扩展方案空间 | `brainstorming-report.md` |
|
||||||
| `bmad-bmm-research` | 验证市场、技术或领域假设 | 研究发现 |
|
| `bmad-domain-research`、`bmad-market-research`、`bmad-technical-research` | 验证领域、市场与技术假设 | 研究发现 |
|
||||||
| `bmad-bmm-create-product-brief` | 捕捉战略愿景 | `product-brief.md` |
|
| `bmad-create-product-brief` | 沉淀产品方向与战略愿景 | `product-brief.md` |
|
||||||
|
|
||||||
## 阶段 2：规划
|
## 阶段 2：规划
|
||||||
|
|
||||||
定义要构建什么以及为谁构建。
|
定义“为谁做、做什么”。
|
||||||
|
|
||||||
| 工作流程 | 目的 | 产出 |
|
| Workflow | 目的 | 产出 |
|
||||||
| --------------------------- | ---------------------------------------- | ------------ |
|
| --- | --- | --- |
|
||||||
| `bmad-bmm-create-prd` | 定义需求（FRs/NFRs） | `PRD.md` |
|
| `bmad-create-prd` | 明确 FR/NFR 与范围边界 | `PRD.md` |
|
||||||
| `bmad-bmm-create-ux-design` | 设计用户体验（当 UX 重要时） | `ux-spec.md` |
|
| `bmad-create-ux-design` | 在 UX 复杂场景下补齐交互与体验方案 | `ux-spec.md` |
|
||||||
|
|
||||||
## 阶段 3：解决方案设计
|
## 阶段 3：解决方案设计（Solutioning）
|
||||||
|
|
||||||
决定如何构建它并将工作分解为故事。
|
定义“如何实现”并拆分可交付工作单元。
|
||||||
|
|
||||||
| 工作流程 | 目的 | 产出 |
|
| Workflow | 目的 | 产出 |
|
||||||
| ----------------------------------------- | ------------------------------------------ | --------------------------- |
|
| --- | --- | --- |
|
||||||
| `bmad-bmm-create-architecture` | 明确技术决策 | 包含 ADR 的 `architecture.md` |
|
| `bmad-create-architecture` | 显式记录技术决策与架构边界 | `architecture.md`（含 ADR） |
|
||||||
| `bmad-bmm-create-epics-and-stories` | 将需求分解为可实施的工作 | 包含故事的 Epic 文件 |
|
| `bmad-create-epics-and-stories` | 将需求拆分为可实施的 epics/stories | epics 文件与 story 条目 |
|
||||||
| `bmad-bmm-check-implementation-readiness` | 实施前的关卡检查 | PASS/CONCERNS/FAIL 决策 |
|
| `bmad-check-implementation-readiness` | 实施前 gate 检查 | PASS / CONCERNS / FAIL 结论 |
|
||||||
|
|
||||||
## 阶段 4：实施
|
## 阶段 4：实施
|
||||||
|
|
||||||
逐个故事地构建它。即将推出完整的阶段 4 自动化！
|
按 story 节奏持续交付与校验。
|
||||||
|
|
||||||
| 工作流程 | 目的 | 产出 |
|
| Workflow | 目的 | 产出 |
|
||||||
| -------------------------- | ------------------------------------------------------------------------ | -------------------------------- |
|
| --- | --- | --- |
|
||||||
| `bmad-bmm-sprint-planning` | 初始化跟踪（每个项目一次，以排序开发周期） | `sprint-status.yaml` |
|
| `bmad-sprint-planning` | 初始化迭代追踪（通常每项目一次） | `sprint-status.yaml` |
|
||||||
| `bmad-bmm-create-story` | 准备下一个故事以供实施 | `story-[slug].md` |
|
| `bmad-create-story` | 准备下一个可实施 story | `story-[slug].md` |
|
||||||
| `bmad-bmm-dev-story` | 实施该故事 | 工作代码 + 测试 |
|
| `bmad-dev-story` | 按规范实现 story | 可运行代码与测试 |
|
||||||
| `bmad-bmm-code-review` | 验证实施质量 | 批准或请求更改 |
|
| `bmad-code-review` | 验证实现质量 | 通过或变更请求 |
|
||||||
| `bmad-bmm-correct-course` | 处理冲刺中的重大变更 | 更新的计划或重新路由 |
|
| `bmad-correct-course` | 处理中途重大方向调整 | 更新后的计划或重路由 |
|
||||||
| `bmad-bmm-automate` | 为现有功能生成测试 - 在完整的 epic 完成后使用 | 端到端 UI 专注测试套件 |
|
| `bmad-sprint-status` | 跟踪冲刺与 story 状态 | 状态更新 |
|
||||||
| `bmad-bmm-retrospective` | 在 epic 完成后回顾 | 经验教训 |
|
| `bmad-retrospective` | epic 完成后复盘 | 经验与改进项 |
|
||||||
|
|
||||||
## 快速流程（并行轨道）
|
## Quick Flow（并行快线）
|
||||||
|
|
||||||
对于小型、易于理解的工作，跳过阶段 1-3。
|
当任务范围小且目标清晰时，可跳过阶段 1-3 直接推进：
|
||||||
|
|
||||||
| 工作流程 | 目的 | 产出 |
|
| Workflow | 目的 | 产出 |
|
||||||
| --------------------- | --------------------------------------------------------------------------- | --------------------------- |
|
| --- | --- | --- |
|
||||||
| `bmad-bmm-quick-dev` | 统一快速流程 — 澄清意图、规划、实现、审查和呈现 | `spec-*.md` + 代码 |
|
| `bmad-quick-dev` | 统一快流：意图澄清、规划、实现、审查、呈现 | `spec-*.md` + 代码变更 |
|
||||||
|
|
||||||
## 上下文管理
|
## 上下文管理
|
||||||
|
|
||||||
每个文档都成为下一阶段的上下文。PRD 告诉架构师哪些约束很重要。架构告诉开发智能体要遵循哪些模式。故事文件为实施提供专注、完整的上下文。没有这种结构，智能体会做出不一致的决策。
|
每个阶段产出都会成为下一阶段输入：PRD 约束架构，架构约束开发，story 约束实现。没有这条链路，智能体更容易在跨 story 时出现不一致决策。
|
||||||
|
|
||||||
### 项目上下文
|
:::tip[Project Context 建议]
|
||||||
|
创建 `project-context.md`，把项目特有约定（技术栈、命名、组织、测试策略）写成共享规则，能显著降低实现偏差。
|
||||||
:::tip[推荐]
|
|
||||||
创建 `project-context.md` 以确保 AI 智能体遵循您项目的规则和偏好。该文件就像您项目的宪法——它指导所有工作流程中的实施决策。这个可选文件可以在架构创建结束时生成，或者在现有项目中也可以生成它，以捕捉与当前约定保持一致的重要内容。
|
|
||||||
:::
|
:::
|
||||||
|
|
||||||
**如何创建它：**
|
**创建方式：**
|
||||||
|
- **手动创建**：在 `_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)
|
- [命令与技能参考](./commands.md)
|
||||||
|
- [智能体参考](./agents.md)
|
||||||
---
|
- [核心工具参考](./core-tools.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 智能体提供的环境信息和背景资料。
|
|
||||||
|
|
|
||||||
|
|
@ -1,11 +1,11 @@
|
||||||
---
|
---
|
||||||
title: 路线图
|
title: 路线图
|
||||||
description: BMad 的下一步计划——功能、改进与社区贡献
|
description: BMad 后续方向：功能演进、体验优化与社区生态
|
||||||
---
|
---
|
||||||
|
|
||||||
# BMad 方法：公开路线图
|
# BMad Method 公开路线图
|
||||||
|
|
||||||
BMad 方法、BMad 方法模块（BMM）和 BMad 构建器（BMB）正在持续演进。以下是我们正在开展的工作以及即将推出的内容。
|
BMad Method、BMM（Agile 套件）与 BMad Builder 正在持续迭代。以下内容用于说明当前重点与下一阶段规划。
|
||||||
|
|
||||||
<div class="roadmap-container">
|
<div class="roadmap-container">
|
||||||
|
|
||||||
|
|
@ -14,139 +14,123 @@ BMad 方法、BMad 方法模块（BMM）和 BMad 构建器（BMB）正在持续
|
||||||
<div class="roadmap-future">
|
<div class="roadmap-future">
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🧩</span>
|
<span class="roadmap-emoji">🧩</span>
|
||||||
<h4>通用技能架构</h4>
|
<h4>通用 Skills 架构</h4>
|
||||||
<p>一个技能，任意平台。一次编写，随处运行。</p>
|
<p>同一 skill 在不同平台复用，降低跨工具维护成本。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🏗️</span>
|
<span class="roadmap-emoji">🏗️</span>
|
||||||
<h4>BMad 构建器 v1</h4>
|
<h4>BMad Builder v1</h4>
|
||||||
<p>打造生产级 AI 智能体与工作流，内置评估、团队协作与优雅降级。</p>
|
<p>面向生产场景的 agent/workflow 构建能力，覆盖评估、协作与优雅降级。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🧠</span>
|
<span class="roadmap-emoji">🧠</span>
|
||||||
<h4>项目上下文系统</h4>
|
<h4>Project Context 系统</h4>
|
||||||
<p>AI 真正理解你的项目。框架感知的上下文，随代码库共同演进。</p>
|
<p>让 AI 在项目约束内工作：上下文随代码库变化持续更新。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">📦</span>
|
<span class="roadmap-emoji">📦</span>
|
||||||
<h4>集中式技能</h4>
|
<h4>集中式 Skills</h4>
|
||||||
<p>一次安装，随处使用。跨项目共享技能，告别文件杂乱。</p>
|
<p>减少项目内重复拷贝，支持跨项目共享与统一管理。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🔄</span>
|
<span class="roadmap-emoji">🔄</span>
|
||||||
<h4>自适应技能</h4>
|
<h4>自适应 Skills</h4>
|
||||||
<p>技能懂你的工具。为 Claude、Codex、Kimi、OpenCode 等提供优化变体，以及更多。</p>
|
<p>针对 Claude、Codex、Kimi、OpenCode 等平台提供优化变体。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">📝</span>
|
<span class="roadmap-emoji">📝</span>
|
||||||
<h4>BMad 团队专业博客</h4>
|
<h4>BMad 团队博客</h4>
|
||||||
<p>来自团队的指南、文章与见解。即将上线。</p>
|
<p>持续发布实践文章、方法拆解与落地经验。</p>
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<h2 class="roadmap-section-title">入门阶段</h2>
|
<h2 class="roadmap-section-title">近期规划</h2>
|
||||||
|
|
||||||
<div class="roadmap-future">
|
<div class="roadmap-future">
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🏪</span>
|
<span class="roadmap-emoji">🏪</span>
|
||||||
<h4>技能市场</h4>
|
<h4>Skill 市场</h4>
|
||||||
<p>发现、安装与更新社区构建的技能。一条 curl 命令即可获得超能力。</p>
|
<p>发现、安装、更新社区技能，缩短能力接入路径。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🎨</span>
|
<span class="roadmap-emoji">🎨</span>
|
||||||
<h4>工作流定制</h4>
|
<h4>Workflow 定制</h4>
|
||||||
<p>打造属于你的工作流。集成 Jira、Linear、自定义输出——你的工作流，你的规则。</p>
|
<p>支持 Jira、Linear 与自定义产出对接，构建团队专属流程。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🚀</span>
|
<span class="roadmap-emoji">🚀</span>
|
||||||
<h4>阶段 1-3 优化</h4>
|
<h4>阶段 1-3 优化</h4>
|
||||||
<p>通过子智能体上下文收集实现闪电般快速的规划。YOLO 模式遇上引导式卓越。</p>
|
<p>通过子智能体上下文采集提升前期分析与规划效率。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🌐</span>
|
<span class="roadmap-emoji">🌐</span>
|
||||||
<h4>企业级就绪</h4>
|
<h4>企业级能力完善</h4>
|
||||||
<p>SSO、审计日志、团队工作空间。那些让企业点头同意的无聊但必要的东西。</p>
|
<p>补齐 SSO、审计日志、团队工作区等企业落地基础能力。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">💎</span>
|
<span class="roadmap-emoji">💎</span>
|
||||||
<h4>社区模块爆发</h4>
|
<h4>社区模块扩展</h4>
|
||||||
<p>娱乐、安全、治疗、角色扮演以及更多内容。扩展 BMad 方法平台。</p>
|
<p>覆盖更多垂直场景，持续扩展 BMad 模块生态。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">⚡</span>
|
<span class="roadmap-emoji">⚡</span>
|
||||||
<h4>开发循环自动化</h4>
|
<h4>开发循环自动化</h4>
|
||||||
<p>可选的开发自动驾驶。让 AI 处理流程，同时保持质量高企。</p>
|
<p>在可控质量边界内提升自动化程度，减少重复人工操作。</p>
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<h2 class="roadmap-section-title">社区与团队</h2>
|
<h2 class="roadmap-section-title">社区与团队计划</h2>
|
||||||
|
|
||||||
<div class="roadmap-future">
|
<div class="roadmap-future">
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🎙️</span>
|
<span class="roadmap-emoji">🎙️</span>
|
||||||
<h4>BMad 方法播客</h4>
|
<h4>BMad Method 播客</h4>
|
||||||
<p>关于 AI 原生开发的对话。2026 年 3 月 1 日上线！</p>
|
<p>围绕 AI 原生研发方法开展持续讨论与案例分享。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🎓</span>
|
<span class="roadmap-emoji">🎓</span>
|
||||||
<h4>BMad 方法大师课</h4>
|
<h4>BMad Method 大师课</h4>
|
||||||
<p>从用户到专家。深入每个阶段、每个工作流、每个秘密。</p>
|
<p>面向进阶用户，系统拆解各阶段与核心 workflow。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🏗️</span>
|
<span class="roadmap-emoji">🏗️</span>
|
||||||
<h4>BMad 构建器大师课</h4>
|
<h4>BMad Builder 大师课</h4>
|
||||||
<p>构建你自己的智能体。当你准备好创造而不仅仅是使用时的高级技巧。</p>
|
<p>聚焦自定义 agent/workflow 的高级设计与工程实践。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">⚡</span>
|
<span class="roadmap-emoji">⚡</span>
|
||||||
<h4>BMad 原型优先</h4>
|
<h4>BMad Prototype First</h4>
|
||||||
<p>一次会话从想法到可用原型。像创作艺术品一样打造你的梦想应用。</p>
|
<p>探索“单会话从想法到原型”的端到端实践路径。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🌴</span>
|
<span class="roadmap-emoji">🌴</span>
|
||||||
<h4>BMad BALM！</h4>
|
<h4>BMad BALM</h4>
|
||||||
<p>AI 原生的生活管理。任务、习惯、目标——你的 AI 副驾驶，无处不在。</p>
|
<p>将 AI 原生协作模式扩展到个人任务、习惯与目标管理。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🖥️</span>
|
<span class="roadmap-emoji">🖥️</span>
|
||||||
<h4>官方 UI</h4>
|
<h4>官方 UI</h4>
|
||||||
<p>整个 BMad 生态系统的精美界面。CLI 的强大，GUI 的精致。</p>
|
<p>在保留 CLI 能力的基础上提供完整图形化操作体验。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🔒</span>
|
<span class="roadmap-emoji">🔒</span>
|
||||||
<h4>BMad 一体机</h4>
|
<h4>BMad in a Box</h4>
|
||||||
<p>自托管、气隙隔离、企业级。你的 AI 助手、你的基础设施、你的控制。</p>
|
<p>面向自托管与气隙隔离场景的企业级部署方案。</p>
|
||||||
</div>
|
</div>
|
||||||
</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);">
|
<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;">
|
<p style="color: var(--slate-color-400); margin: 0;">
|
||||||
这只是计划内容的一部分。BMad 开源团队欢迎贡献者！{" "}<br />
|
以上并非全部规划。BMad 开源团队欢迎贡献者加入。{" "}<br />
|
||||||
<a href="https://github.com/bmad-code-org/BMAD-METHOD" style="color: var(--color-in-progress);">在 GitHub 上加入我们</a>，共同塑造 AI 驱动开发的未来。
|
前往 <a href="https://github.com/bmad-code-org/BMAD-METHOD" style="color: var(--color-in-progress);">GitHub 仓库</a> 参与共建。
|
||||||
</p>
|
</p>
|
||||||
<p style="color: var(--slate-color-400); margin: 1.5rem 0 0;">
|
<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>
|
||||||
<p style="color: var(--slate-color-400); margin: 1rem 0 0;">
|
<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>
|
<a href="mailto:contact@bmadcode.com" style="color: var(--color-in-progress);">contact@bmadcode.com</a>
|
||||||
</p>
|
</p>
|
||||||
</div>
|
</div>
|
||||||
</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",
|
"name": "bmad-method",
|
||||||
"version": "6.2.0",
|
"version": "6.2.1",
|
||||||
"lockfileVersion": 3,
|
"lockfileVersion": 3,
|
||||||
"requires": true,
|
"requires": true,
|
||||||
"packages": {
|
"packages": {
|
||||||
"": {
|
"": {
|
||||||
"name": "bmad-method",
|
"name": "bmad-method",
|
||||||
"version": "6.2.0",
|
"version": "6.2.1",
|
||||||
"license": "MIT",
|
"license": "MIT",
|
||||||
"dependencies": {
|
"dependencies": {
|
||||||
"@clack/core": "^1.0.0",
|
"@clack/core": "^1.0.0",
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,7 @@
|
||||||
{
|
{
|
||||||
"$schema": "https://json.schemastore.org/package.json",
|
"$schema": "https://json.schemastore.org/package.json",
|
||||||
"name": "bmad-method",
|
"name": "bmad-method",
|
||||||
"version": "6.2.0",
|
"version": "6.2.1",
|
||||||
"description": "Breakthrough Method of Agile AI-driven Development",
|
"description": "Breakthrough Method of Agile AI-driven Development",
|
||||||
"keywords": [
|
"keywords": [
|
||||||
"agile",
|
"agile",
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
type: skill
|
type: agent
|
||||||
name: bmad-agent-analyst
|
name: bmad-agent-analyst
|
||||||
displayName: Mary
|
displayName: Mary
|
||||||
title: Business Analyst
|
title: Business Analyst
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
type: skill
|
type: agent
|
||||||
name: bmad-agent-tech-writer
|
name: bmad-agent-tech-writer
|
||||||
displayName: Paige
|
displayName: Paige
|
||||||
title: Technical Writer
|
title: Technical Writer
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
type: skill
|
type: agent
|
||||||
name: bmad-agent-pm
|
name: bmad-agent-pm
|
||||||
displayName: John
|
displayName: John
|
||||||
title: Product Manager
|
title: Product Manager
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
type: skill
|
type: agent
|
||||||
name: bmad-agent-ux-designer
|
name: bmad-agent-ux-designer
|
||||||
displayName: Sally
|
displayName: Sally
|
||||||
title: UX Designer
|
title: UX Designer
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
type: skill
|
type: agent
|
||||||
name: bmad-agent-architect
|
name: bmad-agent-architect
|
||||||
displayName: Winston
|
displayName: Winston
|
||||||
title: Architect
|
title: Architect
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
type: skill
|
type: agent
|
||||||
name: bmad-agent-dev
|
name: bmad-agent-dev
|
||||||
displayName: Amelia
|
displayName: Amelia
|
||||||
title: Developer Agent
|
title: Developer Agent
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
type: skill
|
type: agent
|
||||||
name: bmad-agent-qa
|
name: bmad-agent-qa
|
||||||
displayName: Quinn
|
displayName: Quinn
|
||||||
title: QA Engineer
|
title: QA Engineer
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
type: skill
|
type: agent
|
||||||
name: bmad-agent-quick-flow-solo-dev
|
name: bmad-agent-quick-flow-solo-dev
|
||||||
displayName: Barry
|
displayName: Barry
|
||||||
title: Quick Flow Solo Dev
|
title: Quick Flow Solo Dev
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
type: skill
|
type: agent
|
||||||
name: bmad-agent-sm
|
name: bmad-agent-sm
|
||||||
displayName: Bob
|
displayName: Bob
|
||||||
title: Scrum Master
|
title: Scrum Master
|
||||||
|
|
|
||||||
|
|
@ -1648,6 +1648,93 @@ async function runTests() {
|
||||||
// skill-manifest.csv should include the native agent entrypoint
|
// skill-manifest.csv should include the native agent entrypoint
|
||||||
const skillManifestCsv29 = await fs.readFile(path.join(tempFixture29, '_config', 'skill-manifest.csv'), 'utf8');
|
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');
|
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) {
|
} catch (error) {
|
||||||
assert(false, 'Unified skill scanner test succeeds', error.message);
|
assert(false, 'Unified skill scanner test succeeds', error.message);
|
||||||
} finally {
|
} finally {
|
||||||
|
|
|
||||||
|
|
@ -268,153 +268,103 @@ class ManifestGenerator {
|
||||||
}
|
}
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* Collect all agents from core and selected modules
|
* Collect all agents from selected modules by walking their directory trees.
|
||||||
* Scans the INSTALLED bmad directory, not the source
|
|
||||||
*/
|
*/
|
||||||
async collectAgents(selectedModules) {
|
async collectAgents(selectedModules) {
|
||||||
this.agents = [];
|
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) {
|
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.getAgentsFromDirRecursive(modulePath, moduleName, '', debug);
|
||||||
const moduleAgents = await this.getAgentsFromDir(agentsPath, moduleName);
|
this.agents.push(...moduleAgents);
|
||||||
this.agents.push(...moduleAgents);
|
|
||||||
}
|
|
||||||
}
|
}
|
||||||
|
|
||||||
// Get standalone agents from bmad/agents/ directory
|
// Get standalone agents from bmad/agents/ directory
|
||||||
const standaloneAgentsDir = path.join(this.bmadDir, 'agents');
|
const standaloneAgentsDir = path.join(this.bmadDir, 'agents');
|
||||||
if (await fs.pathExists(standaloneAgentsDir)) {
|
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 (debug) {
|
||||||
if (!agentDir.isDirectory()) continue;
|
console.log(`[DEBUG] collectAgents: total agents found: ${this.agents.length}`);
|
||||||
|
|
||||||
const agentDirPath = path.join(standaloneAgentsDir, agentDir.name);
|
|
||||||
const standaloneAgents = await this.getAgentsFromDir(agentDirPath, 'standalone');
|
|
||||||
this.agents.push(...standaloneAgents);
|
|
||||||
}
|
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* Get agents from a directory recursively
|
* Recursively walk a directory tree collecting agents.
|
||||||
* Only includes .md files with agent content
|
* 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 = '') {
|
async getAgentsFromDirRecursive(dirPath, moduleName, relativePath = '', debug = false) {
|
||||||
// Skip directories claimed by collectSkills
|
|
||||||
if (this.skillClaimedDirs && this.skillClaimedDirs.has(dirPath)) return [];
|
|
||||||
const agents = [];
|
const agents = [];
|
||||||
const entries = await fs.readdir(dirPath, { withFileTypes: true });
|
let entries;
|
||||||
// Load skill manifest for this directory (if present)
|
try {
|
||||||
const skillManifest = await this.loadSkillManifest(dirPath);
|
entries = await fs.readdir(dirPath, { withFileTypes: true });
|
||||||
|
} catch {
|
||||||
|
return agents;
|
||||||
|
}
|
||||||
|
|
||||||
for (const entry of entries) {
|
for (const entry of entries) {
|
||||||
|
if (!entry.isDirectory()) continue;
|
||||||
|
if (entry.name.startsWith('.') || entry.name.startsWith('_')) continue;
|
||||||
|
|
||||||
const fullPath = path.join(dirPath, entry.name);
|
const fullPath = path.join(dirPath, entry.name);
|
||||||
|
|
||||||
if (entry.isDirectory()) {
|
// Check for type:agent manifest BEFORE checking skillClaimedDirs —
|
||||||
// Check for new-format agent: bmad-skill-manifest.yaml with type: agent
|
// agent dirs may be claimed by collectSkills for IDE installation,
|
||||||
// Note: type:agent dirs may also be claimed by collectSkills for IDE installation,
|
// but we still need them in agent-manifest.csv.
|
||||||
// but we still need to process them here for agent-manifest.csv
|
const dirManifest = await this.loadSkillManifest(fullPath);
|
||||||
const dirManifest = await this.loadSkillManifest(fullPath);
|
if (dirManifest && dirManifest.__single && dirManifest.__single.type === 'agent') {
|
||||||
if (dirManifest && dirManifest.__single && dirManifest.__single.type === 'agent') {
|
const m = dirManifest.__single;
|
||||||
const m = dirManifest.__single;
|
const dirRelativePath = relativePath ? `${relativePath}/${entry.name}` : entry.name;
|
||||||
const dirRelativePath = relativePath ? `${relativePath}/${entry.name}` : entry.name;
|
const agentModule = m.module || moduleName;
|
||||||
const installPath =
|
const installPath = `${this.bmadFolderName}/${agentModule}/${dirRelativePath}`;
|
||||||
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', '');
|
|
||||||
|
|
||||||
agents.push({
|
agents.push({
|
||||||
name: agentName,
|
name: m.name || entry.name,
|
||||||
displayName: nameMatch ? nameMatch[1] : agentName,
|
displayName: m.displayName || m.name || entry.name,
|
||||||
title: titleMatch ? titleMatch[1] : '',
|
title: m.title || '',
|
||||||
icon: iconMatch ? iconMatch[1] : '',
|
icon: m.icon || '',
|
||||||
capabilities: capabilitiesMatch ? this.cleanForCSV(capabilitiesMatch[1]) : '',
|
capabilities: m.capabilities ? this.cleanForCSV(m.capabilities) : '',
|
||||||
role: roleMatch ? this.cleanForCSV(roleMatch[1]) : '',
|
role: m.role ? this.cleanForCSV(m.role) : '',
|
||||||
identity: identityMatch ? this.cleanForCSV(identityMatch[1]) : '',
|
identity: m.identity ? this.cleanForCSV(m.identity) : '',
|
||||||
communicationStyle: styleMatch ? this.cleanForCSV(styleMatch[1]) : '',
|
communicationStyle: m.communicationStyle ? this.cleanForCSV(m.communicationStyle) : '',
|
||||||
principles: principlesMatch ? this.cleanForCSV(principlesMatch[1]) : '',
|
principles: m.principles ? this.cleanForCSV(m.principles) : '',
|
||||||
module: moduleName,
|
module: agentModule,
|
||||||
path: installPath,
|
path: installPath,
|
||||||
canonicalId: this.getCanonicalId(skillManifest, entry.name),
|
canonicalId: m.canonicalId || '',
|
||||||
});
|
});
|
||||||
|
|
||||||
// Add to files list
|
|
||||||
this.files.push({
|
this.files.push({
|
||||||
type: 'agent',
|
type: 'agent',
|
||||||
name: agentName,
|
name: m.name || entry.name,
|
||||||
module: moduleName,
|
module: agentModule,
|
||||||
path: installPath,
|
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;
|
return agents;
|
||||||
|
|
|
||||||
|
|
@ -5,6 +5,33 @@ const { loadSkillManifest, getCanonicalId } = require('./skill-manifest');
|
||||||
/**
|
/**
|
||||||
* Helpers for gathering BMAD agents/tasks from the installed tree.
|
* Helpers for gathering BMAD agents/tasks from the installed tree.
|
||||||
* Shared by installers that need Claude-style exports.
|
* 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 = []) {
|
async function getAgentsFromBmad(bmadDir, selectedModules = []) {
|
||||||
const agents = [];
|
const agents = [];
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue