@zeyue0329/xiaoma-cli 1.0.0 → 1.0.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +2 -2
- package/{QUICK-START.md → docs/quick-start.md} +67 -61
- package/package.json +1 -1
- package/tools/installer/package-lock.json +23 -23
- package/tools/installer/package.json +6 -6
- package/CONTRIBUTING.md +0 -209
- package/docs/GUIDING-PRINCIPLES.md +0 -91
- package/docs/core-architecture.md +0 -219
- package/docs/expansion-packs.md +0 -280
- package/docs/versioning-and-releases.md +0 -77
- package/docs/versions.md +0 -48
package/README.md
CHANGED
|
@@ -1,68 +1,57 @@
|
|
|
1
|
-
# 🚀 XIAOMA-
|
|
1
|
+
# 🚀 XIAOMA-CLI 快速启动指南
|
|
2
2
|
|
|
3
|
-
##
|
|
3
|
+
## 项目已成功发布!✅
|
|
4
4
|
|
|
5
|
-
### 📦
|
|
6
|
-
-
|
|
7
|
-
-
|
|
8
|
-
-
|
|
9
|
-
- ✅
|
|
10
|
-
- ✅ dist文件已生成
|
|
5
|
+
### 📦 NPM包信息
|
|
6
|
+
- 📦 **包名**: `@zeyue0329/xiaoma-cli`
|
|
7
|
+
- 🔖 **版本**: `1.0.0`
|
|
8
|
+
- 🌐 **仓库**: https://www.npmjs.com/package/@zeyue0329/xiaoma-cli
|
|
9
|
+
- ✅ 已发布到npm仓库,可全球下载使用
|
|
11
10
|
|
|
12
11
|
### 🎯 项目概述
|
|
13
|
-
XIAOMA-
|
|
12
|
+
XIAOMA-CLI是一个通用AI代理框架,支持敏捷AI驱动开发。提供专业的AI代理团队来处理项目的各个环节。
|
|
14
13
|
|
|
15
|
-
## 🔧
|
|
14
|
+
## 🔧 安装和使用
|
|
16
15
|
|
|
17
|
-
###
|
|
18
|
-
目前XIAOMA-WEB还没有发布到npm仓库,所以需要使用本地安装方式。
|
|
19
|
-
|
|
20
|
-
### 方法1: 使用本地路径(推荐)
|
|
16
|
+
### ⚡ 快速开始(推荐)
|
|
21
17
|
```bash
|
|
22
|
-
#
|
|
23
|
-
npx /
|
|
18
|
+
# 直接使用,无需安装(推荐方式)
|
|
19
|
+
npx @zeyue0329/xiaoma-cli install
|
|
24
20
|
|
|
25
21
|
# 查看帮助
|
|
26
|
-
npx /
|
|
22
|
+
npx @zeyue0329/xiaoma-cli --help
|
|
23
|
+
|
|
24
|
+
# 查看版本
|
|
25
|
+
npx @zeyue0329/xiaoma-cli --version
|
|
27
26
|
```
|
|
28
27
|
|
|
29
|
-
###
|
|
28
|
+
### 🏗️ 全局安装方式
|
|
30
29
|
```bash
|
|
31
|
-
#
|
|
32
|
-
|
|
33
|
-
npm link
|
|
34
|
-
|
|
35
|
-
# 2. 然后在任何目录中使用
|
|
36
|
-
xiaoma-web --version
|
|
37
|
-
xiaoma-web --help
|
|
38
|
-
xiaoma-web install
|
|
39
|
-
|
|
40
|
-
# 构建所有bundles
|
|
41
|
-
npm run build
|
|
42
|
-
|
|
43
|
-
# 验证配置
|
|
44
|
-
npm run validate
|
|
45
|
-
|
|
46
|
-
# 列出可用代理
|
|
47
|
-
npm run list:agents
|
|
30
|
+
# 全局安装
|
|
31
|
+
npm install -g @zeyue0329/xiaoma-cli
|
|
48
32
|
|
|
49
|
-
#
|
|
50
|
-
|
|
33
|
+
# 安装后可直接使用命令
|
|
34
|
+
xiaoma-cli install
|
|
35
|
+
xiaoma-cli --help
|
|
36
|
+
xiaoma-cli --version
|
|
51
37
|
```
|
|
52
38
|
|
|
53
|
-
###
|
|
39
|
+
### 📚 CLI命令详情
|
|
54
40
|
```bash
|
|
55
|
-
#
|
|
56
|
-
|
|
41
|
+
# 项目安装 - 在任意项目目录中运行
|
|
42
|
+
npx @zeyue0329/xiaoma-cli install
|
|
57
43
|
|
|
58
|
-
#
|
|
59
|
-
|
|
44
|
+
# 查看可用代理列表
|
|
45
|
+
npx @zeyue0329/xiaoma-cli list:agents
|
|
60
46
|
|
|
61
|
-
#
|
|
62
|
-
|
|
47
|
+
# 验证配置文件
|
|
48
|
+
npx @zeyue0329/xiaoma-cli validate
|
|
63
49
|
|
|
64
|
-
#
|
|
65
|
-
|
|
50
|
+
# 构建所有bundles
|
|
51
|
+
npx @zeyue0329/xiaoma-cli build
|
|
52
|
+
|
|
53
|
+
# 代码库扁平化(用于AI分析)
|
|
54
|
+
npx @zeyue0329/xiaoma-cli flatten
|
|
66
55
|
```
|
|
67
56
|
|
|
68
57
|
## 📁 项目结构
|
|
@@ -89,10 +78,13 @@ XIAOMA-WEB/
|
|
|
89
78
|
|
|
90
79
|
### 方式1: 在新项目中安装使用
|
|
91
80
|
```bash
|
|
92
|
-
#
|
|
81
|
+
# 进入你的项目目录
|
|
82
|
+
cd /path/to/your/project
|
|
93
83
|
|
|
84
|
+
# 运行安装命令
|
|
85
|
+
npx @zeyue0329/xiaoma-cli install
|
|
94
86
|
|
|
95
|
-
#
|
|
87
|
+
# 按提示选择:
|
|
96
88
|
# - Complete XiaoMa Core (完整安装)
|
|
97
89
|
# - Single Agent (单个代理)
|
|
98
90
|
|
|
@@ -100,14 +92,15 @@ XIAOMA-WEB/
|
|
|
100
92
|
# - Cursor, Claude Code, Windsurf, VS Code等
|
|
101
93
|
```
|
|
102
94
|
|
|
103
|
-
### 方式2:
|
|
95
|
+
### 方式2: 获取Web UI Bundles
|
|
104
96
|
```bash
|
|
105
|
-
#
|
|
106
|
-
|
|
97
|
+
# 首先在本地生成bundle文件
|
|
98
|
+
npx @zeyue0329/xiaoma-cli build
|
|
107
99
|
|
|
108
|
-
#
|
|
100
|
+
# bundle文件将生成在项目的dist目录中
|
|
101
|
+
# 然后可以上传到以下平台:
|
|
109
102
|
# - Gemini (推荐用于规划阶段)
|
|
110
|
-
# - ChatGPT
|
|
103
|
+
# - ChatGPT
|
|
111
104
|
# - Claude Web UI
|
|
112
105
|
```
|
|
113
106
|
|
|
@@ -134,16 +127,17 @@ cp dist/teams/team-fullstack.txt /path/to/upload/
|
|
|
134
127
|
## ⚡ 快速开始
|
|
135
128
|
|
|
136
129
|
### IDE开发流程
|
|
137
|
-
1. 在项目中安装:`npx xiaoma-
|
|
130
|
+
1. 在项目中安装:`npx @zeyue0329/xiaoma-cli install`
|
|
138
131
|
2. 选择IDE集成
|
|
139
132
|
3. 使用 `@代理名` 或 `/代理名` 调用代理
|
|
140
133
|
4. 按照SM → Dev循环进行开发
|
|
141
134
|
|
|
142
135
|
### Web UI规划流程
|
|
143
|
-
1.
|
|
144
|
-
2.
|
|
145
|
-
3.
|
|
146
|
-
4.
|
|
136
|
+
1. 运行:`npx @zeyue0329/xiaoma-cli build` 生成bundle文件
|
|
137
|
+
2. 使用 `dist/teams/team-fullstack.txt`
|
|
138
|
+
3. 上传到Gemini/ChatGPT
|
|
139
|
+
4. 创建PRD和架构文档
|
|
140
|
+
5. 切换到IDE进行开发
|
|
147
141
|
|
|
148
142
|
## 📚 文档资源
|
|
149
143
|
|
|
@@ -154,20 +148,32 @@ cp dist/teams/team-fullstack.txt /path/to/upload/
|
|
|
154
148
|
|
|
155
149
|
## 🔗 相关链接
|
|
156
150
|
|
|
151
|
+
- **NPM包**: https://www.npmjs.com/package/@zeyue0329/xiaoma-cli
|
|
157
152
|
- **GitHub**: https://github.com/zqyl-xiaoma/xiaoma-cli
|
|
158
153
|
- **Issues**: https://github.com/zqyl-xiaoma/xiaoma-cli/issues
|
|
159
154
|
- **Discord**: https://discord.gg/gk8jAdXWmj
|
|
160
155
|
|
|
161
156
|
## 🎉 开始使用
|
|
162
157
|
|
|
163
|
-
|
|
158
|
+
项目已成功发布到npm!现在全球用户都可以通过简单的命令使用XIAOMA-CLI框架。
|
|
164
159
|
|
|
165
160
|
**建议第一次使用:**
|
|
166
161
|
1. 阅读[用户指南](xiaoma-core/user-guide.md)了解工作流程
|
|
167
|
-
2. 在测试项目中运行 `npx xiaoma-
|
|
162
|
+
2. 在测试项目中运行 `npx @zeyue0329/xiaoma-cli install`
|
|
168
163
|
3. 选择您的IDE进行集成
|
|
169
164
|
4. 开始您的第一个AI辅助开发项目!
|
|
170
165
|
|
|
166
|
+
**🚀 一键开始:**
|
|
167
|
+
```bash
|
|
168
|
+
# 创建新项目目录
|
|
169
|
+
mkdir my-ai-project && cd my-ai-project
|
|
170
|
+
|
|
171
|
+
# 安装XIAOMA-CLI框架
|
|
172
|
+
npx @zeyue0329/xiaoma-cli install
|
|
173
|
+
|
|
174
|
+
# 开始您的AI驱动开发之旅!
|
|
175
|
+
```
|
|
176
|
+
|
|
171
177
|
---
|
|
172
178
|
|
|
173
|
-
**🎊 祝您使用愉快!XIAOMA-
|
|
179
|
+
**🎊 祝您使用愉快!XIAOMA-CLI团队为您的开发之旅保驾护航!**
|
package/package.json
CHANGED
|
@@ -1,12 +1,12 @@
|
|
|
1
1
|
{
|
|
2
|
-
"name": "
|
|
3
|
-
"version": "
|
|
2
|
+
"name": "@zeyue0329/xiaoma-cli-installer",
|
|
3
|
+
"version": "1.0.1",
|
|
4
4
|
"lockfileVersion": 3,
|
|
5
5
|
"requires": true,
|
|
6
6
|
"packages": {
|
|
7
7
|
"": {
|
|
8
|
-
"name": "
|
|
9
|
-
"version": "
|
|
8
|
+
"name": "@zeyue0329/xiaoma-cli-installer",
|
|
9
|
+
"version": "1.0.1",
|
|
10
10
|
"license": "MIT",
|
|
11
11
|
"dependencies": {
|
|
12
12
|
"chalk": "^5.4.1",
|
|
@@ -17,8 +17,8 @@
|
|
|
17
17
|
"ora": "^8.2.0"
|
|
18
18
|
},
|
|
19
19
|
"bin": {
|
|
20
|
-
"
|
|
21
|
-
"
|
|
20
|
+
"xiaoma-cli-installer": "bin/xiaoma.js",
|
|
21
|
+
"xiaoma-installer": "bin/xiaoma.js"
|
|
22
22
|
},
|
|
23
23
|
"engines": {
|
|
24
24
|
"node": ">=20.0.0"
|
|
@@ -214,9 +214,9 @@
|
|
|
214
214
|
}
|
|
215
215
|
},
|
|
216
216
|
"node_modules/@inquirer/prompts": {
|
|
217
|
-
"version": "7.
|
|
218
|
-
"resolved": "https://registry.npmjs.org/@inquirer/prompts/-/prompts-7.
|
|
219
|
-
"integrity": "sha512-
|
|
217
|
+
"version": "7.8.0",
|
|
218
|
+
"resolved": "https://registry.npmjs.org/@inquirer/prompts/-/prompts-7.8.0.tgz",
|
|
219
|
+
"integrity": "sha512-JHwGbQ6wjf1dxxnalDYpZwZxUEosT+6CPGD9Zh4sm9WXdtUp9XODCQD3NjSTmu+0OAyxWXNOqf0spjIymJa2Tw==",
|
|
220
220
|
"license": "MIT",
|
|
221
221
|
"dependencies": {
|
|
222
222
|
"@inquirer/checkbox": "^4.2.0",
|
|
@@ -227,7 +227,7 @@
|
|
|
227
227
|
"@inquirer/number": "^3.0.17",
|
|
228
228
|
"@inquirer/password": "^4.0.17",
|
|
229
229
|
"@inquirer/rawlist": "^4.1.5",
|
|
230
|
-
"@inquirer/search": "^3.0
|
|
230
|
+
"@inquirer/search": "^3.1.0",
|
|
231
231
|
"@inquirer/select": "^4.3.1"
|
|
232
232
|
},
|
|
233
233
|
"engines": {
|
|
@@ -265,9 +265,9 @@
|
|
|
265
265
|
}
|
|
266
266
|
},
|
|
267
267
|
"node_modules/@inquirer/search": {
|
|
268
|
-
"version": "3.0
|
|
269
|
-
"resolved": "https://registry.npmjs.org/@inquirer/search/-/search-3.0.
|
|
270
|
-
"integrity": "sha512-
|
|
268
|
+
"version": "3.1.0",
|
|
269
|
+
"resolved": "https://registry.npmjs.org/@inquirer/search/-/search-3.1.0.tgz",
|
|
270
|
+
"integrity": "sha512-PMk1+O/WBcYJDq2H7foV0aAZSmDdkzZB9Mw2v/DmONRJopwA/128cS9M/TXWLKKdEQKZnKwBzqu2G4x/2Nqx8Q==",
|
|
271
271
|
"license": "MIT",
|
|
272
272
|
"dependencies": {
|
|
273
273
|
"@inquirer/core": "^10.1.15",
|
|
@@ -377,9 +377,9 @@
|
|
|
377
377
|
"license": "Python-2.0"
|
|
378
378
|
},
|
|
379
379
|
"node_modules/chalk": {
|
|
380
|
-
"version": "5.
|
|
381
|
-
"resolved": "https://registry.npmjs.org/chalk/-/chalk-5.
|
|
382
|
-
"integrity": "sha512-
|
|
380
|
+
"version": "5.5.0",
|
|
381
|
+
"resolved": "https://registry.npmjs.org/chalk/-/chalk-5.5.0.tgz",
|
|
382
|
+
"integrity": "sha512-1tm8DTaJhPBG3bIkVeZt1iZM9GfSX2lzOeDVZH9R9ffRHpmHvxZ/QhgQH/aDTkswQVt+YHdXAdS/In/30OjCbg==",
|
|
383
383
|
"license": "MIT",
|
|
384
384
|
"engines": {
|
|
385
385
|
"node": "^12.17.0 || ^14.13 || >=16.0.0"
|
|
@@ -478,9 +478,9 @@
|
|
|
478
478
|
}
|
|
479
479
|
},
|
|
480
480
|
"node_modules/fs-extra": {
|
|
481
|
-
"version": "11.3.
|
|
482
|
-
"resolved": "https://registry.npmjs.org/fs-extra/-/fs-extra-11.3.
|
|
483
|
-
"integrity": "sha512-
|
|
481
|
+
"version": "11.3.1",
|
|
482
|
+
"resolved": "https://registry.npmjs.org/fs-extra/-/fs-extra-11.3.1.tgz",
|
|
483
|
+
"integrity": "sha512-eXvGGwZ5CL17ZSwHWd3bbgk7UUpF6IFHtP57NYYakPvHOs8GDgDe5KJI36jIJzDkJ6eJjuzRA8eBQb6SkKue0g==",
|
|
484
484
|
"license": "MIT",
|
|
485
485
|
"dependencies": {
|
|
486
486
|
"graceful-fs": "^4.2.0",
|
|
@@ -522,13 +522,13 @@
|
|
|
522
522
|
}
|
|
523
523
|
},
|
|
524
524
|
"node_modules/inquirer": {
|
|
525
|
-
"version": "12.
|
|
526
|
-
"resolved": "https://registry.npmjs.org/inquirer/-/inquirer-12.
|
|
527
|
-
"integrity": "sha512-
|
|
525
|
+
"version": "12.9.0",
|
|
526
|
+
"resolved": "https://registry.npmjs.org/inquirer/-/inquirer-12.9.0.tgz",
|
|
527
|
+
"integrity": "sha512-LlFVmvWVCun7uEgPB3vups9NzBrjJn48kRNtFGw3xU1H5UXExTEz/oF1JGLaB0fvlkUB+W6JfgLcSEaSdH7RPA==",
|
|
528
528
|
"license": "MIT",
|
|
529
529
|
"dependencies": {
|
|
530
530
|
"@inquirer/core": "^10.1.15",
|
|
531
|
-
"@inquirer/prompts": "^7.
|
|
531
|
+
"@inquirer/prompts": "^7.8.0",
|
|
532
532
|
"@inquirer/type": "^3.0.8",
|
|
533
533
|
"ansi-escapes": "^4.3.2",
|
|
534
534
|
"mute-stream": "^2.0.0",
|
|
@@ -1,17 +1,17 @@
|
|
|
1
1
|
{
|
|
2
|
-
"name": "
|
|
3
|
-
"version": "
|
|
4
|
-
"description": "XiaoMa
|
|
2
|
+
"name": "@zeyue0329/xiaoma-cli-installer",
|
|
3
|
+
"version": "1.0.1",
|
|
4
|
+
"description": "XiaoMa Cli installer - AI-powered Agile development framework",
|
|
5
5
|
"main": "lib/installer.js",
|
|
6
6
|
"bin": {
|
|
7
|
-
"
|
|
8
|
-
"
|
|
7
|
+
"xiaoma-installer": "./bin/xiaoma.js",
|
|
8
|
+
"xiaoma-cli-installer": "./bin/xiaoma.js"
|
|
9
9
|
},
|
|
10
10
|
"scripts": {
|
|
11
11
|
"test": "echo \"Error: no test specified\" && exit 1"
|
|
12
12
|
},
|
|
13
13
|
"keywords": [
|
|
14
|
-
"
|
|
14
|
+
"xiaoma",
|
|
15
15
|
"agile",
|
|
16
16
|
"ai",
|
|
17
17
|
"development",
|
package/CONTRIBUTING.md
DELETED
|
@@ -1,209 +0,0 @@
|
|
|
1
|
-
# Contributing to this project
|
|
2
|
-
|
|
3
|
-
Thank you for considering contributing to this project! This document outlines the process for contributing and some guidelines to follow.
|
|
4
|
-
|
|
5
|
-
🆕 **New to GitHub or pull requests?** Check out our [beginner-friendly Pull Request Guide](docs/how-to-contribute-with-pull-requests.md) first!
|
|
6
|
-
|
|
7
|
-
📋 **Before contributing**, please read our [Guiding Principles](docs/GUIDING-PRINCIPLES.md) to understand the XiaoMa Method's core philosophy and architectural decisions.
|
|
8
|
-
|
|
9
|
-
Also note, we use the discussions feature in GitHub to have a community to discuss potential ideas, uses, additions and enhancements.
|
|
10
|
-
|
|
11
|
-
💬 **Discord Community**: Join our [Discord server](https://discord.gg/gk8jAdXWmj) for real-time discussions:
|
|
12
|
-
|
|
13
|
-
- **#general-dev** - Technical discussions, feature ideas, and development questions
|
|
14
|
-
- **#bugs-issues** - Bug reports and issue discussions
|
|
15
|
-
|
|
16
|
-
## Code of Conduct
|
|
17
|
-
|
|
18
|
-
By participating in this project, you agree to abide by our Code of Conduct. Please read it before participating.
|
|
19
|
-
|
|
20
|
-
## How to Contribute
|
|
21
|
-
|
|
22
|
-
### Reporting Bugs
|
|
23
|
-
|
|
24
|
-
1. **Check existing issues** first to avoid duplicates
|
|
25
|
-
2. **Use the bug report template** when creating a new issue - it will guide you through providing:
|
|
26
|
-
- Clear bug description
|
|
27
|
-
- Steps to reproduce
|
|
28
|
-
- Expected vs actual behavior
|
|
29
|
-
- Model/IDE/XiaoMa version details
|
|
30
|
-
- Screenshots or links if applicable
|
|
31
|
-
3. **Consider discussing in Discord** (#bugs-issues channel) for quick help
|
|
32
|
-
4. **Indicate if you're working on a fix** to avoid duplicate efforts
|
|
33
|
-
|
|
34
|
-
### Suggesting Features
|
|
35
|
-
|
|
36
|
-
1. **Discuss first in Discord** (#general-dev channel) - the feature request template asks if you've done this
|
|
37
|
-
2. **Check existing issues and discussions** to avoid duplicates
|
|
38
|
-
3. **Use the feature request template** when creating an issue - it will guide you through:
|
|
39
|
-
- Confirming Discord discussion
|
|
40
|
-
- Describing the problem it solves
|
|
41
|
-
- Explaining your solution
|
|
42
|
-
- Listing alternatives considered
|
|
43
|
-
4. **Be specific** about why this feature would benefit the XiaoMa community
|
|
44
|
-
|
|
45
|
-
### Pull Request Process
|
|
46
|
-
|
|
47
|
-
⚠️ **Before starting work:**
|
|
48
|
-
|
|
49
|
-
1. **For bugs**: Check if an issue exists (create one using the bug template if not)
|
|
50
|
-
2. **For features**: Ensure you've discussed in Discord (#general-dev) AND created a feature request issue
|
|
51
|
-
3. **For large changes**: Always open an issue first to discuss alignment
|
|
52
|
-
|
|
53
|
-
Please only propose small granular commits! If its large or significant, please discuss in the discussions tab and open up an issue first. I do not want you to waste your time on a potentially very large PR to have it rejected because it is not aligned or deviates from other planned changes. Communicate and lets work together to build and improve this great community project!
|
|
54
|
-
|
|
55
|
-
**Important**: All contributions must align with our [Guiding Principles](docs/GUIDING-PRINCIPLES.md). Key points:
|
|
56
|
-
|
|
57
|
-
- Keep dev agents lean - they need context for coding, not documentation
|
|
58
|
-
- Web/planning agents can be larger with more complex tasks
|
|
59
|
-
- Everything is natural language (markdown) - no code in core framework
|
|
60
|
-
- Use expansion packs for domain-specific features
|
|
61
|
-
|
|
62
|
-
#### Which Branch for Your PR?
|
|
63
|
-
|
|
64
|
-
**Submit to `next` branch** (most contributions):
|
|
65
|
-
|
|
66
|
-
- ✨ New features or agents
|
|
67
|
-
- 🎨 Enhancements to existing features
|
|
68
|
-
- 📚 Documentation updates
|
|
69
|
-
- ♻️ Code refactoring
|
|
70
|
-
- ⚡ Performance improvements
|
|
71
|
-
- 🧪 New tests
|
|
72
|
-
- 🎁 New expansion packs
|
|
73
|
-
|
|
74
|
-
**Submit to `main` branch** (critical only):
|
|
75
|
-
|
|
76
|
-
- 🚨 Critical bug fixes that break basic functionality
|
|
77
|
-
- 🔒 Security patches
|
|
78
|
-
- 📚 Fixing dangerously incorrect documentation
|
|
79
|
-
- 🐛 Bugs preventing installation or basic usage
|
|
80
|
-
|
|
81
|
-
**When in doubt, submit to `next`**. We'd rather test changes thoroughly before they hit stable.
|
|
82
|
-
|
|
83
|
-
#### PR Size Guidelines
|
|
84
|
-
|
|
85
|
-
- **Ideal PR size**: 200-400 lines of code changes
|
|
86
|
-
- **Maximum PR size**: 800 lines (excluding generated files)
|
|
87
|
-
- **One feature/fix per PR**: Each PR should address a single issue or add one feature
|
|
88
|
-
- **If your change is larger**: Break it into multiple smaller PRs that can be reviewed independently
|
|
89
|
-
- **Related changes**: Even related changes should be separate PRs if they deliver independent value
|
|
90
|
-
|
|
91
|
-
#### Breaking Down Large PRs
|
|
92
|
-
|
|
93
|
-
If your change exceeds 800 lines, use this checklist to split it:
|
|
94
|
-
|
|
95
|
-
- [ ] Can I separate the refactoring from the feature implementation?
|
|
96
|
-
- [ ] Can I introduce the new API/interface in one PR and implementation in another?
|
|
97
|
-
- [ ] Can I split by file or module?
|
|
98
|
-
- [ ] Can I create a base PR with shared utilities first?
|
|
99
|
-
- [ ] Can I separate test additions from implementation?
|
|
100
|
-
- [ ] Even if changes are related, can they deliver value independently?
|
|
101
|
-
- [ ] Can these changes be merged in any order without breaking things?
|
|
102
|
-
|
|
103
|
-
Example breakdown:
|
|
104
|
-
|
|
105
|
-
1. PR #1: Add utility functions and types (100 lines)
|
|
106
|
-
2. PR #2: Refactor existing code to use utilities (200 lines)
|
|
107
|
-
3. PR #3: Implement new feature using refactored code (300 lines)
|
|
108
|
-
4. PR #4: Add comprehensive tests (200 lines)
|
|
109
|
-
|
|
110
|
-
**Note**: PRs #1 and #4 could be submitted simultaneously since they deliver independent value and don't depend on each other's merge order.
|
|
111
|
-
|
|
112
|
-
#### Pull Request Steps
|
|
113
|
-
|
|
114
|
-
1. Fork the repository
|
|
115
|
-
2. Create a new branch (`git checkout -b feature/your-feature-name`)
|
|
116
|
-
3. Make your changes
|
|
117
|
-
4. Run any tests or linting to ensure quality
|
|
118
|
-
5. Commit your changes with clear, descriptive messages following our commit message convention
|
|
119
|
-
6. Push to your branch (`git push origin feature/your-feature-name`)
|
|
120
|
-
7. Open a Pull Request against the main branch
|
|
121
|
-
|
|
122
|
-
## Issue Templates
|
|
123
|
-
|
|
124
|
-
We use GitHub issue templates to ensure all necessary information is provided:
|
|
125
|
-
|
|
126
|
-
- **Bug Reports**: Automatically guides you through providing reproduction steps, environment details, and expected behavior
|
|
127
|
-
- **Feature Requests**: Requires Discord discussion confirmation and asks for problem/solution descriptions
|
|
128
|
-
|
|
129
|
-
Using these templates helps maintainers understand and address your contribution faster.
|
|
130
|
-
|
|
131
|
-
## Pull Request Description Guidelines
|
|
132
|
-
|
|
133
|
-
Keep PR descriptions short and to the point following this template:
|
|
134
|
-
|
|
135
|
-
### PR Description Template
|
|
136
|
-
|
|
137
|
-
Keep your PR description concise and focused. Use this template:
|
|
138
|
-
|
|
139
|
-
```markdown
|
|
140
|
-
## What
|
|
141
|
-
|
|
142
|
-
[1-2 sentences describing WHAT changed]
|
|
143
|
-
|
|
144
|
-
## Why
|
|
145
|
-
|
|
146
|
-
[1-2 sentences explaining WHY this change is needed]
|
|
147
|
-
Fixes #[issue number] (if applicable)
|
|
148
|
-
|
|
149
|
-
## How
|
|
150
|
-
|
|
151
|
-
[2-3 bullets listing HOW you implemented it]
|
|
152
|
-
|
|
153
|
-
-
|
|
154
|
-
-
|
|
155
|
-
-
|
|
156
|
-
|
|
157
|
-
## Testing
|
|
158
|
-
|
|
159
|
-
[1-2 sentences on how you tested this]
|
|
160
|
-
```
|
|
161
|
-
|
|
162
|
-
**Maximum PR description length: 200 words** (excluding code examples if needed)
|
|
163
|
-
|
|
164
|
-
### Good vs Bad PR Descriptions
|
|
165
|
-
|
|
166
|
-
❌ **Bad Example:**
|
|
167
|
-
|
|
168
|
-
> This revolutionary PR introduces a paradigm-shifting enhancement to the system's architecture by implementing a state-of-the-art solution that leverages cutting-edge methodologies to optimize performance metrics and deliver unprecedented value to stakeholders through innovative approaches...
|
|
169
|
-
|
|
170
|
-
✅ **Good Example:**
|
|
171
|
-
|
|
172
|
-
> **What:** Added validation for agent dependency resolution
|
|
173
|
-
> **Why:** Build was failing silently when agents had circular dependencies
|
|
174
|
-
> **How:**
|
|
175
|
-
>
|
|
176
|
-
> - Added cycle detection in dependency-resolver.js
|
|
177
|
-
> - Throws clear error with dependency chain
|
|
178
|
-
> **Testing:** Tested with circular deps between 3 agents
|
|
179
|
-
|
|
180
|
-
## Commit Message Convention
|
|
181
|
-
|
|
182
|
-
Use conventional commits format:
|
|
183
|
-
|
|
184
|
-
- `feat:` New feature
|
|
185
|
-
- `fix:` Bug fix
|
|
186
|
-
- `docs:` Documentation only
|
|
187
|
-
- `refactor:` Code change that neither fixes a bug nor adds a feature
|
|
188
|
-
- `test:` Adding missing tests
|
|
189
|
-
- `chore:` Changes to build process or auxiliary tools
|
|
190
|
-
|
|
191
|
-
Keep commit messages under 72 characters.
|
|
192
|
-
|
|
193
|
-
### Atomic Commits
|
|
194
|
-
|
|
195
|
-
Each commit should represent one logical change:
|
|
196
|
-
|
|
197
|
-
- **Do:** One bug fix per commit
|
|
198
|
-
- **Do:** One feature addition per commit
|
|
199
|
-
- **Don't:** Mix refactoring with bug fixes
|
|
200
|
-
- **Don't:** Combine unrelated changes
|
|
201
|
-
|
|
202
|
-
## Code Style
|
|
203
|
-
|
|
204
|
-
- Follow the existing code style and conventions
|
|
205
|
-
- Write clear comments for complex logic
|
|
206
|
-
|
|
207
|
-
## License
|
|
208
|
-
|
|
209
|
-
By contributing to this project, you agree that your contributions will be licensed under the same license as the project.
|
|
@@ -1,91 +0,0 @@
|
|
|
1
|
-
# BMad Method Guiding Principles
|
|
2
|
-
|
|
3
|
-
The BMad Method is a natural language framework for AI-assisted software development. These principles ensure contributions maintain the method's effectiveness.
|
|
4
|
-
|
|
5
|
-
## Core Principles
|
|
6
|
-
|
|
7
|
-
### 1. Dev Agents Must Be Lean
|
|
8
|
-
|
|
9
|
-
- **Minimize dev agent dependencies**: Development agents that work in IDEs must have minimal context overhead
|
|
10
|
-
- **Save context for code**: Every line counts - dev agents should focus on coding, not documentation
|
|
11
|
-
- **Web agents can be larger**: Planning agents (PRD Writer, Architect) used in web UI can have more complex tasks and dependencies
|
|
12
|
-
- **Small files, loaded on demand**: Multiple small, focused files are better than large files with many branches
|
|
13
|
-
|
|
14
|
-
### 2. Natural Language First
|
|
15
|
-
|
|
16
|
-
- **Everything is markdown**: Agents, tasks, templates - all written in plain English
|
|
17
|
-
- **No code in core**: The framework itself contains no programming code, only natural language instructions
|
|
18
|
-
- **Self-contained templates**: Templates are defined as YAML files with structured sections that include metadata, workflow configuration, and detailed instructions for content generation
|
|
19
|
-
|
|
20
|
-
### 3. Agent and Task Design
|
|
21
|
-
|
|
22
|
-
- **Agents define roles**: Each agent is a persona with specific expertise (e.g., Frontend Developer, API Developer)
|
|
23
|
-
- **Tasks are procedures**: Step-by-step instructions an agent follows to complete work
|
|
24
|
-
- **Templates are outputs**: Structured documents with embedded instructions for generation
|
|
25
|
-
- **Dependencies matter**: Explicitly declare only what's needed
|
|
26
|
-
|
|
27
|
-
## Practical Guidelines
|
|
28
|
-
|
|
29
|
-
### When to Add to Core
|
|
30
|
-
|
|
31
|
-
- Universal software development needs only
|
|
32
|
-
- Doesn't bloat dev agent contexts
|
|
33
|
-
- Follows existing agent/task/template patterns
|
|
34
|
-
|
|
35
|
-
### When to Create Expansion Packs
|
|
36
|
-
|
|
37
|
-
- Domain-specific needs beyond software development
|
|
38
|
-
- Non-technical domains (business, wellness, education, creative)
|
|
39
|
-
- Specialized technical domains (games, infrastructure, mobile)
|
|
40
|
-
- Heavy documentation or knowledge bases
|
|
41
|
-
- Anything that would bloat core agents
|
|
42
|
-
|
|
43
|
-
See [Expansion Packs Guide](../docs/expansion-packs.md) for detailed examples and ideas.
|
|
44
|
-
|
|
45
|
-
### Agent Design Rules
|
|
46
|
-
|
|
47
|
-
1. **Web/Planning Agents**: Can have richer context, multiple tasks, extensive templates
|
|
48
|
-
2. **Dev Agents**: Minimal dependencies, focused on code generation, lean task sets
|
|
49
|
-
3. **All Agents**: Clear persona, specific expertise, well-defined capabilities
|
|
50
|
-
|
|
51
|
-
### Task Writing Rules
|
|
52
|
-
|
|
53
|
-
1. Write clear step-by-step procedures
|
|
54
|
-
2. Use markdown formatting for readability
|
|
55
|
-
3. Keep dev agent tasks focused and concise
|
|
56
|
-
4. Planning tasks can be more elaborate
|
|
57
|
-
5. **Prefer multiple small tasks over one large branching task**
|
|
58
|
-
- Instead of one task with many conditional paths
|
|
59
|
-
- Create multiple focused tasks the agent can choose from
|
|
60
|
-
- This keeps context overhead minimal
|
|
61
|
-
6. **Reuse common tasks** - Don't create new document creation tasks
|
|
62
|
-
- Use the existing `create-doc` task
|
|
63
|
-
- Pass the appropriate YAML template with structured sections
|
|
64
|
-
- This maintains consistency and reduces duplication
|
|
65
|
-
|
|
66
|
-
### Template Rules
|
|
67
|
-
|
|
68
|
-
Templates follow the [BMad Document Template](common/utils/bmad-doc-template.md) specification using YAML format:
|
|
69
|
-
|
|
70
|
-
1. **Structure**: Templates are defined in YAML with clear metadata, workflow configuration, and section hierarchy
|
|
71
|
-
2. **Separation of Concerns**: Instructions for LLMs are in `instruction` fields, separate from content
|
|
72
|
-
3. **Reusability**: Templates are agent-agnostic and can be used across different agents
|
|
73
|
-
4. **Key Components**:
|
|
74
|
-
- `template` block for metadata (id, name, version, output settings)
|
|
75
|
-
- `workflow` block for interaction mode configuration
|
|
76
|
-
- `sections` array defining document structure with nested subsections
|
|
77
|
-
- Each section has `id`, `title`, and `instruction` fields
|
|
78
|
-
5. **Advanced Features**:
|
|
79
|
-
- Variable substitution using `{{variable_name}}` syntax
|
|
80
|
-
- Conditional sections with `condition` field
|
|
81
|
-
- Repeatable sections with `repeatable: true`
|
|
82
|
-
- Agent permissions with `owner` and `editors` fields
|
|
83
|
-
- Examples arrays for guidance (never included in output)
|
|
84
|
-
6. **Clean Output**: YAML structure ensures all processing logic stays separate from generated content
|
|
85
|
-
|
|
86
|
-
## Remember
|
|
87
|
-
|
|
88
|
-
- The power is in natural language orchestration, not code
|
|
89
|
-
- Dev agents code, planning agents plan
|
|
90
|
-
- Keep dev agents lean for maximum coding efficiency
|
|
91
|
-
- Expansion packs handle specialized domains
|
|
@@ -1,219 +0,0 @@
|
|
|
1
|
-
# BMad Method: Core Architecture
|
|
2
|
-
|
|
3
|
-
## 1. Overview
|
|
4
|
-
|
|
5
|
-
The BMad Method is designed to provide agentic modes, tasks and templates to allow repeatable helpful workflows be it for agile agentic development, or expansion into vastly different domains. The core purpose of the project is to provide a structured yet flexible set of prompts, templates, and workflows that users can employ to guide AI agents (like Gemini, Claude, or ChatGPT) to perform complex tasks, guided discussions, or other meaningful domain specific flows in a predictable, high-quality manner.
|
|
6
|
-
|
|
7
|
-
The systems core module facilitates a full development lifecycle tailored to the challenges of current modern AI Agentic tooling:
|
|
8
|
-
|
|
9
|
-
1. **Ideation & Planning**: Brainstorming, market research, and creating project briefs.
|
|
10
|
-
2. **Architecture & Design**: Defining system architecture and UI/UX specifications.
|
|
11
|
-
3. **Development Execution**: A cyclical workflow where a Scrum Master (SM) agent drafts stories with extremely specific context and a Developer (Dev) agent implements them one at a time. This process works for both new (Greenfield) and existing (Brownfield) projects.
|
|
12
|
-
|
|
13
|
-
## 2. System Architecture Diagram
|
|
14
|
-
|
|
15
|
-
The entire BMad-Method ecosystem is designed around the installed `bmad-core` directory, which acts as the brain of the operation. The `tools` directory provides the means to process and package this brain for different environments.
|
|
16
|
-
|
|
17
|
-
```mermaid
|
|
18
|
-
graph TD
|
|
19
|
-
subgraph BMad Method Project
|
|
20
|
-
subgraph Core Framework
|
|
21
|
-
A["bmad-core"]
|
|
22
|
-
A --> B["agents"]
|
|
23
|
-
A --> C["agent-teams"]
|
|
24
|
-
A --> D["workflows"]
|
|
25
|
-
A --> E["templates"]
|
|
26
|
-
A --> F["tasks"]
|
|
27
|
-
A --> G["checklists"]
|
|
28
|
-
A --> H["data (KB)"]
|
|
29
|
-
end
|
|
30
|
-
|
|
31
|
-
subgraph Tooling
|
|
32
|
-
I["tools/builders/web-builder.js"]
|
|
33
|
-
end
|
|
34
|
-
|
|
35
|
-
subgraph Outputs
|
|
36
|
-
J["dist"]
|
|
37
|
-
end
|
|
38
|
-
|
|
39
|
-
B -- defines dependencies for --> E
|
|
40
|
-
B -- defines dependencies for --> F
|
|
41
|
-
B -- defines dependencies for --> G
|
|
42
|
-
B -- defines dependencies for --> H
|
|
43
|
-
|
|
44
|
-
C -- bundles --> B
|
|
45
|
-
I -- reads from --> A
|
|
46
|
-
I -- creates --> J
|
|
47
|
-
end
|
|
48
|
-
|
|
49
|
-
subgraph Target Environments
|
|
50
|
-
K["IDE (Cursor, VS Code, etc.)"]
|
|
51
|
-
L["Web UI (Gemini, ChatGPT)"]
|
|
52
|
-
end
|
|
53
|
-
|
|
54
|
-
B --> K
|
|
55
|
-
J --> L
|
|
56
|
-
|
|
57
|
-
style A fill:#1a73e8,color:#fff
|
|
58
|
-
style I fill:#f9ab00,color:#fff
|
|
59
|
-
style J fill:#34a853,color:#fff
|
|
60
|
-
```
|
|
61
|
-
|
|
62
|
-
## 3. Core Components
|
|
63
|
-
|
|
64
|
-
The `bmad-core` directory contains all the definitions and resources that give the agents their capabilities.
|
|
65
|
-
|
|
66
|
-
### 3.1. Agents (`bmad-core/agents/`)
|
|
67
|
-
|
|
68
|
-
- **Purpose**: These are the foundational building blocks of the system. Each markdown file (e.g., `bmad-master.md`, `pm.md`, `dev.md`) defines the persona, capabilities, and dependencies of a single AI agent.
|
|
69
|
-
- **Structure**: An agent file contains a YAML header that specifies its role, persona, dependencies, and startup instructions. These dependencies are lists of tasks, templates, checklists, and data files that the agent is allowed to use.
|
|
70
|
-
- **Startup Instructions**: Agents can include startup sequences that load project-specific documentation from the `docs/` folder, such as coding standards, API specifications, or project structure documents. This provides immediate project context upon activation.
|
|
71
|
-
- **Document Integration**: Agents can reference and load documents from the project's `docs/` folder as part of tasks, workflows, or startup sequences. Users can also drag documents directly into chat interfaces to provide additional context.
|
|
72
|
-
- **Example**: The `bmad-master` agent lists its dependencies, which tells the build tool which files to include in a web bundle and informs the agent of its own capabilities.
|
|
73
|
-
|
|
74
|
-
### 3.2. Agent Teams (`bmad-core/agent-teams/`)
|
|
75
|
-
|
|
76
|
-
- **Purpose**: Team files (e.g., `team-all.yaml`) define collections of agents and workflows that are bundled together for a specific purpose, like "full-stack development" or "backend-only". This creates a larger, pre-packaged context for web UI environments.
|
|
77
|
-
- **Structure**: A team file lists the agents to include. It can use wildcards, such as `"*"` to include all agents. This allows for the creation of comprehensive bundles like `team-all`.
|
|
78
|
-
|
|
79
|
-
### 3.3. Workflows (`bmad-core/workflows/`)
|
|
80
|
-
|
|
81
|
-
- **Purpose**: Workflows are YAML files (e.g., `greenfield-fullstack.yaml`) that define a prescribed sequence of steps and agent interactions for a specific project type. They act as a strategic guide for the user and the `bmad-orchestrator` agent.
|
|
82
|
-
- **Structure**: A workflow defines sequences for both complex and simple projects, lists the agents involved at each step, the artifacts they create, and the conditions for moving from one step to the next. It often includes a Mermaid diagram for visualization.
|
|
83
|
-
|
|
84
|
-
### 3.4. Reusable Resources (`templates`, `tasks`, `checklists`, `data`)
|
|
85
|
-
|
|
86
|
-
- **Purpose**: These folders house the modular components that are dynamically loaded by agents based on their dependencies.
|
|
87
|
-
- **`templates/`**: Contains markdown templates for common documents like PRDs, architecture specifications, and user stories.
|
|
88
|
-
- **`tasks/`**: Defines the instructions for carrying out specific, repeatable actions like "shard-doc" or "create-next-story".
|
|
89
|
-
- **`checklists/`**: Provides quality assurance checklists for agents like the Product Owner (`po`) or Architect.
|
|
90
|
-
- **`data/`**: Contains the core knowledge base (`bmad-kb.md`), technical preferences (`technical-preferences.md`), and other key data files.
|
|
91
|
-
|
|
92
|
-
#### 3.4.1. Template Processing System
|
|
93
|
-
|
|
94
|
-
A key architectural principle of BMad is that templates are self-contained and interactive - they embed both the desired document output and the LLM instructions needed to work with users. This means that in many cases, no separate task is needed for document creation, as the template itself contains all the processing logic.
|
|
95
|
-
|
|
96
|
-
The BMad framework employs a sophisticated template processing system orchestrated by three key components:
|
|
97
|
-
|
|
98
|
-
- **`template-format.md`** (`bmad-core/utils/`): Defines the foundational markup language used throughout all BMad templates. This specification establishes syntax rules for variable substitution (`{{placeholders}}`), AI-only processing directives (`[[LLM: instructions]]`), and conditional logic blocks. Templates follow this format to ensure consistent processing across the system.
|
|
99
|
-
|
|
100
|
-
- **`create-doc.md`** (`bmad-core/tasks/`): Acts as the orchestration engine that manages the entire document generation workflow. This task coordinates template selection, manages user interaction modes (incremental vs. rapid generation), enforces template-format processing rules, and handles validation. It serves as the primary interface between users and the template system.
|
|
101
|
-
|
|
102
|
-
- **`advanced-elicitation.md`** (`bmad-core/tasks/`): Provides an interactive refinement layer that can be embedded within templates through `[[LLM: instructions]]` blocks. This component offers 10 structured brainstorming actions, section-by-section review capabilities, and iterative improvement workflows to enhance content quality.
|
|
103
|
-
|
|
104
|
-
The system maintains a clean separation of concerns: template markup is processed internally by AI agents but never exposed to users, while providing sophisticated AI processing capabilities through embedded intelligence within the templates themselves.
|
|
105
|
-
|
|
106
|
-
#### 3.4.2. Technical Preferences System
|
|
107
|
-
|
|
108
|
-
BMad includes a personalization layer through the `technical-preferences.md` file in `bmad-core/data/`. This file serves as a persistent technical profile that influences agent behavior across all projects.
|
|
109
|
-
|
|
110
|
-
**Purpose and Benefits:**
|
|
111
|
-
|
|
112
|
-
- **Consistency**: Ensures all agents reference the same technical preferences
|
|
113
|
-
- **Efficiency**: Eliminates the need to repeatedly specify preferred technologies
|
|
114
|
-
- **Personalization**: Agents provide recommendations aligned with user preferences
|
|
115
|
-
- **Learning**: Captures lessons learned and preferences that evolve over time
|
|
116
|
-
|
|
117
|
-
**Content Structure:**
|
|
118
|
-
The file typically includes preferred technology stacks, design patterns, external services, coding standards, and anti-patterns to avoid. Agents automatically reference this file during planning and development to provide contextually appropriate suggestions.
|
|
119
|
-
|
|
120
|
-
**Integration Points:**
|
|
121
|
-
|
|
122
|
-
- Templates can reference technical preferences during document generation
|
|
123
|
-
- Agents suggest preferred technologies when appropriate for project requirements
|
|
124
|
-
- When preferences don't fit project needs, agents explain alternatives
|
|
125
|
-
- Web bundles can include preferences content for consistent behavior across platforms
|
|
126
|
-
|
|
127
|
-
**Evolution Over Time:**
|
|
128
|
-
Users are encouraged to continuously update this file with discoveries from projects, adding both positive preferences and technologies to avoid, creating a personalized knowledge base that improves agent recommendations over time.
|
|
129
|
-
|
|
130
|
-
## 4. The Build & Delivery Process
|
|
131
|
-
|
|
132
|
-
The framework is designed for two primary environments: local IDEs and web-based AI chat interfaces. The `web-builder.js` script is the key to supporting the latter.
|
|
133
|
-
|
|
134
|
-
### 4.1. Web Builder (`tools/builders/web-builder.js`)
|
|
135
|
-
|
|
136
|
-
- **Purpose**: This Node.js script is responsible for creating the `.txt` bundles found in `dist`.
|
|
137
|
-
- **Process**:
|
|
138
|
-
1. **Resolves Dependencies**: For a given agent or team, the script reads its definition file.
|
|
139
|
-
2. It recursively finds all dependent resources (tasks, templates, etc.) that the agent/team needs.
|
|
140
|
-
3. **Bundles Content**: It reads the content of all these files and concatenates them into a single, large text file, with clear separators indicating the original file path of each section.
|
|
141
|
-
4. **Outputs Bundle**: The final `.txt` file is saved in the `dist` directory, ready to be uploaded to a web UI.
|
|
142
|
-
|
|
143
|
-
### 4.2. Environment-Specific Usage
|
|
144
|
-
|
|
145
|
-
- **For IDEs**: Users interact with the agents directly via their markdown files in `bmad-core/agents/`. The IDE integration (for Cursor, Claude Code, etc.) knows how to call these agents.
|
|
146
|
-
- **For Web UIs**: Users upload a pre-built bundle from `dist`. This single file provides the AI with the context of the entire team and all their required tools and knowledge.
|
|
147
|
-
|
|
148
|
-
## 5. BMad Workflows
|
|
149
|
-
|
|
150
|
-
### 5.1. The Planning Workflow
|
|
151
|
-
|
|
152
|
-
Before development begins, BMad follows a structured planning workflow that establishes the foundation for successful project execution:
|
|
153
|
-
|
|
154
|
-
```mermaid
|
|
155
|
-
graph TD
|
|
156
|
-
A["Start: Project Idea"] --> B{"Optional: Analyst Brainstorming"}
|
|
157
|
-
B -->|Yes| C["Analyst: Market Research & Analysis"]
|
|
158
|
-
B -->|No| D["Create Project Brief"]
|
|
159
|
-
C --> D["Analyst: Create Project Brief"]
|
|
160
|
-
D --> E["PM: Create PRD from Brief"]
|
|
161
|
-
E --> F["Architect: Create Architecture from PRD"]
|
|
162
|
-
F --> G["PO: Run Master Checklist"]
|
|
163
|
-
G --> H{"Documents Aligned?"}
|
|
164
|
-
H -->|Yes| I["Planning Complete"]
|
|
165
|
-
H -->|No| J["PO: Update Epics & Stories"]
|
|
166
|
-
J --> K["Update PRD/Architecture as needed"]
|
|
167
|
-
K --> G
|
|
168
|
-
I --> L["📁 Switch to IDE"]
|
|
169
|
-
L --> M["PO: Shard Documents"]
|
|
170
|
-
M --> N["Ready for SM/Dev Cycle"]
|
|
171
|
-
|
|
172
|
-
style I fill:#34a853,color:#fff
|
|
173
|
-
style G fill:#f9ab00,color:#fff
|
|
174
|
-
style L fill:#1a73e8,color:#fff
|
|
175
|
-
style N fill:#34a853,color:#fff
|
|
176
|
-
```
|
|
177
|
-
|
|
178
|
-
**Key Planning Phases:**
|
|
179
|
-
|
|
180
|
-
1. **Optional Analysis**: Analyst conducts market research and competitive analysis
|
|
181
|
-
2. **Project Brief**: Foundation document created by Analyst or user
|
|
182
|
-
3. **PRD Creation**: PM transforms brief into comprehensive product requirements
|
|
183
|
-
4. **Architecture Design**: Architect creates technical foundation based on PRD
|
|
184
|
-
5. **Validation & Alignment**: PO ensures all documents are consistent and complete
|
|
185
|
-
6. **Refinement**: Updates to epics, stories, and documents as needed
|
|
186
|
-
7. **Environment Transition**: Critical switch from web UI to IDE for development workflow
|
|
187
|
-
8. **Document Preparation**: PO shards large documents for development consumption
|
|
188
|
-
|
|
189
|
-
**Workflow Orchestration**: The `bmad-orchestrator` agent uses these workflow definitions to guide users through the complete process, ensuring proper transitions between planning (web UI) and development (IDE) phases.
|
|
190
|
-
|
|
191
|
-
### 5.2. The Core Development Cycle
|
|
192
|
-
|
|
193
|
-
Once the initial planning and architecture phases are complete, the project moves into a cyclical development workflow, as detailed in the `bmad-kb.md`. This ensures a steady, sequential, and quality-controlled implementation process.
|
|
194
|
-
|
|
195
|
-
```mermaid
|
|
196
|
-
graph TD
|
|
197
|
-
A["Start: Planning Artifacts Complete"] --> B["PO: Shard Epics"]
|
|
198
|
-
B --> C["PO: Shard Arch"]
|
|
199
|
-
C --> D["Development Phase"]
|
|
200
|
-
D --> E["Scrum Master: Drafts next story from sharded epic"]
|
|
201
|
-
E --> F{"User Approval"}
|
|
202
|
-
F -->|Approved| G["Dev: Implement Story"]
|
|
203
|
-
F -->|Needs Changes| E
|
|
204
|
-
G --> H["Dev: Complete story Tasks"]
|
|
205
|
-
H --> I["Dev: Mark Ready for Review"]
|
|
206
|
-
I --> J{"User Verification"}
|
|
207
|
-
J -->|Request QA Review| K["QA: Run review-story task"]
|
|
208
|
-
J -->|Approve Without QA| M["Mark Story as Done"]
|
|
209
|
-
K --> L{"QA Review Results"}
|
|
210
|
-
L -->|Needs Work| G
|
|
211
|
-
L -->|Approved| M["Mark Story as Done"]
|
|
212
|
-
J -->|Needs Fixes| G
|
|
213
|
-
M --> E
|
|
214
|
-
|
|
215
|
-
style M fill:#34a853,color:#fff
|
|
216
|
-
style K fill:#f9ab00,color:#fff
|
|
217
|
-
```
|
|
218
|
-
|
|
219
|
-
This cycle continues, with the Scrum Master, Developer, and optionally QA agents working together. The QA agent provides senior developer review capabilities through the `review-story` task, offering code refactoring, quality improvements, and knowledge transfer. This ensures high code quality while maintaining development velocity.
|
package/docs/expansion-packs.md
DELETED
|
@@ -1,280 +0,0 @@
|
|
|
1
|
-
# The Power of BMad Expansion Packs
|
|
2
|
-
|
|
3
|
-
## Overview
|
|
4
|
-
|
|
5
|
-
BMad Method's expansion packs unlock the framework's true potential by extending its natural language AI orchestration to ANY domain. While the core framework focuses on software development, expansion packs transform BMad into a universal AI agent system.
|
|
6
|
-
|
|
7
|
-
## Why Expansion Packs?
|
|
8
|
-
|
|
9
|
-
### Keep Core Lean
|
|
10
|
-
|
|
11
|
-
The core BMad framework maintains its focus on software development, ensuring dev agents have maximum context for coding. Expansion packs handle everything else.
|
|
12
|
-
|
|
13
|
-
### Domain Expertise
|
|
14
|
-
|
|
15
|
-
Each expansion pack provides deep, specialized knowledge without bloating the core system. Install only what you need.
|
|
16
|
-
|
|
17
|
-
### Community Innovation
|
|
18
|
-
|
|
19
|
-
Anyone can create and share expansion packs, fostering a ecosystem of AI-powered solutions across all industries and interests.
|
|
20
|
-
|
|
21
|
-
## Technical Expansion Packs
|
|
22
|
-
|
|
23
|
-
### Game Development Pack
|
|
24
|
-
|
|
25
|
-
Transform your AI into a complete game development studio:
|
|
26
|
-
|
|
27
|
-
- **Game Designer**: Mechanics, balance, progression systems
|
|
28
|
-
- **Level Designer**: Map layouts, puzzle design, difficulty curves
|
|
29
|
-
- **Narrative Designer**: Story arcs, dialog trees, lore creation
|
|
30
|
-
- **Art Director**: Visual style guides, asset specifications
|
|
31
|
-
- **Sound Designer**: Audio direction, music themes, SFX planning
|
|
32
|
-
|
|
33
|
-
### Mobile Development Pack
|
|
34
|
-
|
|
35
|
-
Specialized agents for mobile app creation:
|
|
36
|
-
|
|
37
|
-
- **iOS Specialist**: Swift/SwiftUI patterns, Apple guidelines
|
|
38
|
-
- **Android Expert**: Kotlin best practices, Material Design
|
|
39
|
-
- **Mobile UX Designer**: Touch interfaces, gesture patterns
|
|
40
|
-
- **App Store Optimizer**: ASO strategies, listing optimization
|
|
41
|
-
- **Performance Tuner**: Battery optimization, network efficiency
|
|
42
|
-
|
|
43
|
-
### DevOps/Infrastructure Pack
|
|
44
|
-
|
|
45
|
-
Complete infrastructure automation team:
|
|
46
|
-
|
|
47
|
-
- **Cloud Architect**: AWS/Azure/GCP design patterns
|
|
48
|
-
- **Security Specialist**: Zero-trust implementation, compliance
|
|
49
|
-
- **SRE Expert**: Monitoring, alerting, incident response
|
|
50
|
-
- **Container Orchestrator**: Kubernetes, Docker optimization
|
|
51
|
-
- **Cost Optimizer**: Cloud spend analysis, resource right-sizing
|
|
52
|
-
|
|
53
|
-
### Data Science Pack
|
|
54
|
-
|
|
55
|
-
AI-powered data analysis team:
|
|
56
|
-
|
|
57
|
-
- **Data Scientist**: Statistical analysis, ML model selection
|
|
58
|
-
- **Data Engineer**: Pipeline design, ETL processes
|
|
59
|
-
- **ML Engineer**: Model deployment, A/B testing
|
|
60
|
-
- **Visualization Expert**: Dashboard design, insight communication
|
|
61
|
-
- **Ethics Advisor**: Bias detection, fairness assessment
|
|
62
|
-
|
|
63
|
-
## Non-Technical Expansion Packs
|
|
64
|
-
|
|
65
|
-
### Business Strategy Pack
|
|
66
|
-
|
|
67
|
-
Complete business advisory team:
|
|
68
|
-
|
|
69
|
-
- **Strategy Consultant**: Market positioning, competitive analysis
|
|
70
|
-
- **Financial Analyst**: Projections, unit economics, funding strategies
|
|
71
|
-
- **Operations Manager**: Process optimization, efficiency improvements
|
|
72
|
-
- **Marketing Strategist**: Go-to-market plans, growth hacking
|
|
73
|
-
- **HR Advisor**: Talent strategies, culture building
|
|
74
|
-
|
|
75
|
-
### Creative Writing Pack
|
|
76
|
-
|
|
77
|
-
Your personal writing team:
|
|
78
|
-
|
|
79
|
-
- **Plot Architect**: Three-act structure, story beats, pacing
|
|
80
|
-
- **Character Psychologist**: Deep motivations, authentic dialog
|
|
81
|
-
- **World Builder**: Consistent universes, cultural systems
|
|
82
|
-
- **Editor**: Style consistency, grammar, flow
|
|
83
|
-
- **Beta Reader**: Feedback simulation, plot hole detection
|
|
84
|
-
|
|
85
|
-
### Health & Wellness Pack
|
|
86
|
-
|
|
87
|
-
Personal wellness coaching system:
|
|
88
|
-
|
|
89
|
-
- **Fitness Trainer**: Progressive overload, form correction
|
|
90
|
-
- **Nutritionist**: Macro planning, supplement guidance
|
|
91
|
-
- **Sleep Coach**: Circadian optimization, sleep hygiene
|
|
92
|
-
- **Stress Manager**: Coping strategies, work-life balance
|
|
93
|
-
- **Habit Engineer**: Behavior change, accountability systems
|
|
94
|
-
|
|
95
|
-
### Education Pack
|
|
96
|
-
|
|
97
|
-
Complete learning design system:
|
|
98
|
-
|
|
99
|
-
- **Curriculum Architect**: Learning objectives, scope & sequence
|
|
100
|
-
- **Instructional Designer**: Engagement strategies, multimedia learning
|
|
101
|
-
- **Assessment Specialist**: Rubrics, formative/summative evaluation
|
|
102
|
-
- **Differentiation Expert**: Adaptive learning, special needs
|
|
103
|
-
- **EdTech Integrator**: Tool selection, digital pedagogy
|
|
104
|
-
|
|
105
|
-
### Mental Health Support Pack
|
|
106
|
-
|
|
107
|
-
Therapeutic support system:
|
|
108
|
-
|
|
109
|
-
- **CBT Guide**: Cognitive restructuring, thought challenging
|
|
110
|
-
- **Mindfulness Teacher**: Meditation scripts, awareness exercises
|
|
111
|
-
- **Journal Therapist**: Reflective prompts, emotional processing
|
|
112
|
-
- **Crisis Support**: Coping strategies, safety planning
|
|
113
|
-
- **Habit Tracker**: Mood monitoring, trigger identification
|
|
114
|
-
|
|
115
|
-
### Legal Assistant Pack
|
|
116
|
-
|
|
117
|
-
Legal document and research support:
|
|
118
|
-
|
|
119
|
-
- **Contract Analyst**: Term review, risk assessment
|
|
120
|
-
- **Legal Researcher**: Case law, precedent analysis
|
|
121
|
-
- **Document Drafter**: Template customization, clause libraries
|
|
122
|
-
- **Compliance Checker**: Regulatory alignment, audit prep
|
|
123
|
-
- **IP Advisor**: Patent strategies, trademark guidance
|
|
124
|
-
|
|
125
|
-
### Real Estate Pack
|
|
126
|
-
|
|
127
|
-
Property investment and management:
|
|
128
|
-
|
|
129
|
-
- **Market Analyst**: Comparable analysis, trend prediction
|
|
130
|
-
- **Investment Calculator**: ROI modeling, cash flow analysis
|
|
131
|
-
- **Property Manager**: Tenant screening, maintenance scheduling
|
|
132
|
-
- **Flip Strategist**: Renovation ROI, project planning
|
|
133
|
-
- **Agent Assistant**: Listing optimization, showing prep
|
|
134
|
-
|
|
135
|
-
### Personal Development Pack
|
|
136
|
-
|
|
137
|
-
Complete personal growth system:
|
|
138
|
-
|
|
139
|
-
- **Life Coach**: Guides personal growth and transformation
|
|
140
|
-
- **Goal Strategist**: Helps achieve objectives with SMART goals
|
|
141
|
-
- **Habit Builder**: Creates lasting habits with accountability
|
|
142
|
-
- **Mindset Mentor**: Develops positive thinking patterns
|
|
143
|
-
|
|
144
|
-
Key tasks include:
|
|
145
|
-
|
|
146
|
-
- `goal-setting`: Defines SMART goals with action plans
|
|
147
|
-
- `habit-tracking`: Monitors habit formation progress
|
|
148
|
-
- `reflection-exercise`: Facilitates deep self-reflection
|
|
149
|
-
|
|
150
|
-
## Unique & Innovative Packs
|
|
151
|
-
|
|
152
|
-
### Role-Playing Game Master Pack
|
|
153
|
-
|
|
154
|
-
AI-powered tabletop RPG assistance:
|
|
155
|
-
|
|
156
|
-
- **World Master**: Dynamic world generation, NPC creation
|
|
157
|
-
- **Combat Referee**: Initiative tracking, rule clarification
|
|
158
|
-
- **Story Weaver**: Plot hooks, side quests, consequences
|
|
159
|
-
- **Character Builder**: Backstory generation, stat optimization
|
|
160
|
-
- **Loot Master**: Treasure generation, magic item creation
|
|
161
|
-
|
|
162
|
-
### Life Event Planning Pack
|
|
163
|
-
|
|
164
|
-
Major life event coordination:
|
|
165
|
-
|
|
166
|
-
- **Wedding Planner**: Vendor coordination, timeline creation
|
|
167
|
-
- **Event Designer**: Theme development, decoration plans
|
|
168
|
-
- **Budget Manager**: Cost tracking, vendor negotiation
|
|
169
|
-
- **Guest Coordinator**: RSVP tracking, seating arrangements
|
|
170
|
-
- **Timeline Keeper**: Day-of scheduling, contingency planning
|
|
171
|
-
|
|
172
|
-
### Hobby Mastery Pack
|
|
173
|
-
|
|
174
|
-
Deep dive into specific hobbies:
|
|
175
|
-
|
|
176
|
-
- **Garden Designer**: Plant selection, seasonal planning
|
|
177
|
-
- **Brew Master**: Recipe formulation, process optimization
|
|
178
|
-
- **Maker Assistant**: 3D printing, woodworking, crafts
|
|
179
|
-
- **Collection Curator**: Organization, valuation, trading
|
|
180
|
-
- **Photography Coach**: Composition, lighting, post-processing
|
|
181
|
-
|
|
182
|
-
### Scientific Research Pack
|
|
183
|
-
|
|
184
|
-
Research acceleration tools:
|
|
185
|
-
|
|
186
|
-
- **Literature Reviewer**: Paper summarization, gap analysis
|
|
187
|
-
- **Hypothesis Generator**: Research question formulation
|
|
188
|
-
- **Methodology Designer**: Experiment planning, control design
|
|
189
|
-
- **Statistical Advisor**: Test selection, power analysis
|
|
190
|
-
- **Grant Writer**: Proposal structure, impact statements
|
|
191
|
-
|
|
192
|
-
## Creating Your Own Expansion Pack
|
|
193
|
-
|
|
194
|
-
### Step 1: Define Your Domain
|
|
195
|
-
|
|
196
|
-
What expertise are you capturing? What problems will it solve?
|
|
197
|
-
|
|
198
|
-
### Step 2: Design Your Agents
|
|
199
|
-
|
|
200
|
-
Each agent should have:
|
|
201
|
-
|
|
202
|
-
- Clear expertise area
|
|
203
|
-
- Specific personality traits
|
|
204
|
-
- Defined capabilities
|
|
205
|
-
- Knowledge boundaries
|
|
206
|
-
|
|
207
|
-
### Step 3: Create Tasks
|
|
208
|
-
|
|
209
|
-
Tasks should be:
|
|
210
|
-
|
|
211
|
-
- Step-by-step procedures
|
|
212
|
-
- Reusable across scenarios
|
|
213
|
-
- Clear and actionable
|
|
214
|
-
- Domain-specific
|
|
215
|
-
|
|
216
|
-
### Step 4: Build Templates
|
|
217
|
-
|
|
218
|
-
Templates need:
|
|
219
|
-
|
|
220
|
-
- Structured output format
|
|
221
|
-
- Embedded LLM instructions
|
|
222
|
-
- Placeholders for customization
|
|
223
|
-
- Professional formatting
|
|
224
|
-
|
|
225
|
-
### Step 5: Test & Iterate
|
|
226
|
-
|
|
227
|
-
- Use with real scenarios
|
|
228
|
-
- Gather user feedback
|
|
229
|
-
- Refine agent responses
|
|
230
|
-
- Improve task clarity
|
|
231
|
-
|
|
232
|
-
### Step 6: Package & Share
|
|
233
|
-
|
|
234
|
-
- Create clear documentation
|
|
235
|
-
- Include usage examples
|
|
236
|
-
- Add to expansion-packs directory
|
|
237
|
-
- Share with community
|
|
238
|
-
|
|
239
|
-
## The Future of Expansion Packs
|
|
240
|
-
|
|
241
|
-
### Marketplace Potential
|
|
242
|
-
|
|
243
|
-
Imagine a future where:
|
|
244
|
-
|
|
245
|
-
- Professional expansion packs are sold
|
|
246
|
-
- Certified packs for regulated industries
|
|
247
|
-
- Community ratings and reviews
|
|
248
|
-
- Automatic updates and improvements
|
|
249
|
-
|
|
250
|
-
### AI Agent Ecosystems
|
|
251
|
-
|
|
252
|
-
Expansion packs could enable:
|
|
253
|
-
|
|
254
|
-
- Cross-pack agent collaboration
|
|
255
|
-
- Industry-standard agent protocols
|
|
256
|
-
- Interoperable AI workflows
|
|
257
|
-
- Universal agent languages
|
|
258
|
-
|
|
259
|
-
### Democratizing Expertise
|
|
260
|
-
|
|
261
|
-
Every expansion pack:
|
|
262
|
-
|
|
263
|
-
- Makes expert knowledge accessible
|
|
264
|
-
- Reduces barriers to entry
|
|
265
|
-
- Enables solo entrepreneurs
|
|
266
|
-
- Empowers small teams
|
|
267
|
-
|
|
268
|
-
## Getting Started
|
|
269
|
-
|
|
270
|
-
1. **Browse existing packs**: Check `expansion-packs/` directory
|
|
271
|
-
2. **Install what you need**: Use the installer's expansion pack option
|
|
272
|
-
3. **Create your own**: Use the expansion-creator pack
|
|
273
|
-
4. **Share with others**: Submit PRs with new packs
|
|
274
|
-
5. **Build the future**: Help shape AI-assisted work
|
|
275
|
-
|
|
276
|
-
## Remember
|
|
277
|
-
|
|
278
|
-
The BMad Method is more than a development framework - it's a platform for structuring human expertise into AI-accessible formats. Every expansion pack you create makes specialized knowledge more accessible to everyone.
|
|
279
|
-
|
|
280
|
-
**What expertise will you share with the world?**
|
|
@@ -1,77 +0,0 @@
|
|
|
1
|
-
# How to Release a New Version
|
|
2
|
-
|
|
3
|
-
## Automated Releases (Recommended)
|
|
4
|
-
|
|
5
|
-
The easiest way to release new versions is through **automatic semantic releases**. Just commit with the right message format and push and everything else happens automatically.
|
|
6
|
-
|
|
7
|
-
### Commit Message Format
|
|
8
|
-
|
|
9
|
-
Use these prefixes to control what type of release happens:
|
|
10
|
-
|
|
11
|
-
```bash
|
|
12
|
-
fix: resolve CLI argument parsing bug # → patch release (4.1.0 → 4.1.1)
|
|
13
|
-
feat: add new agent orchestration mode # → minor release (4.1.0 → 4.2.0)
|
|
14
|
-
feat!: redesign CLI interface # → major release (4.1.0 → 5.0.0)
|
|
15
|
-
```
|
|
16
|
-
|
|
17
|
-
### What Happens Automatically
|
|
18
|
-
|
|
19
|
-
When you push commits with `fix:` or `feat:`, GitHub Actions will:
|
|
20
|
-
|
|
21
|
-
1. ✅ Analyze your commit messages
|
|
22
|
-
2. ✅ Bump version in `package.json`
|
|
23
|
-
3. ✅ Generate changelog
|
|
24
|
-
4. ✅ Create git tag
|
|
25
|
-
5. ✅ **Publish to NPM automatically**
|
|
26
|
-
6. ✅ Create GitHub release with notes
|
|
27
|
-
|
|
28
|
-
### Your Simple Workflow
|
|
29
|
-
|
|
30
|
-
```bash
|
|
31
|
-
# Make your changes
|
|
32
|
-
git add .
|
|
33
|
-
git commit -m "feat: add team collaboration mode"
|
|
34
|
-
git push
|
|
35
|
-
|
|
36
|
-
# That's it! Release happens automatically 🎉
|
|
37
|
-
# Users can now run: npx bmad-method (and get the new version)
|
|
38
|
-
```
|
|
39
|
-
|
|
40
|
-
### Commits That DON'T Trigger Releases
|
|
41
|
-
|
|
42
|
-
These commit types won't create releases (use them for maintenance):
|
|
43
|
-
|
|
44
|
-
```bash
|
|
45
|
-
chore: update dependencies # No release
|
|
46
|
-
docs: fix typo in readme # No release
|
|
47
|
-
style: format code # No release
|
|
48
|
-
test: add unit tests # No release
|
|
49
|
-
```
|
|
50
|
-
|
|
51
|
-
### Test Your Setup
|
|
52
|
-
|
|
53
|
-
```bash
|
|
54
|
-
npm run release:test # Safe to run locally - tests the config
|
|
55
|
-
```
|
|
56
|
-
|
|
57
|
-
---
|
|
58
|
-
|
|
59
|
-
## Manual Release Methods (Exceptions Only)
|
|
60
|
-
|
|
61
|
-
⚠️ Only use these methods if you need to bypass the automatic system
|
|
62
|
-
|
|
63
|
-
### Quick Manual Version Bump
|
|
64
|
-
|
|
65
|
-
```bash
|
|
66
|
-
npm run version:patch # 4.1.0 → 4.1.1 (bug fixes)
|
|
67
|
-
npm run version:minor # 4.1.0 → 4.2.0 (new features)
|
|
68
|
-
npm run version:major # 4.1.0 → 5.0.0 (breaking changes)
|
|
69
|
-
|
|
70
|
-
# Then manually publish:
|
|
71
|
-
npm publish
|
|
72
|
-
git push && git push --tags
|
|
73
|
-
```
|
|
74
|
-
|
|
75
|
-
### Manual GitHub Actions Trigger
|
|
76
|
-
|
|
77
|
-
You can also trigger releases manually through GitHub Actions workflow dispatch if needed.
|
package/docs/versions.md
DELETED
|
@@ -1,48 +0,0 @@
|
|
|
1
|
-
# Version History
|
|
2
|
-
|
|
3
|
-
## Previous Versions
|
|
4
|
-
|
|
5
|
-
- [Version 3](https://github.com/zqyl-xiaoma/xiaoma-cli/tree/V3)
|
|
6
|
-
- [Version 2](https://github.com/zqyl-xiaoma/xiaoma-cli/tree/V2)
|
|
7
|
-
- [Version 1](https://github.com/zqyl-xiaoma/xiaoma-cli/tree/V1)
|
|
8
|
-
|
|
9
|
-
## Current Version: V4 - Alpha
|
|
10
|
-
|
|
11
|
-
Guiding Principles of V4:
|
|
12
|
-
|
|
13
|
-
- Simple to understand, install and start using
|
|
14
|
-
- Support Greenfield and Brownfield Scenarios
|
|
15
|
-
- Greater configurability and more scenarios for usage - but kept out of the main package to maintain simplicity
|
|
16
|
-
- Helpers for installers and web builders that will work with any OS and IDE easily
|
|
17
|
-
- Align all agents to be the same for IDE and Web, without losing the power of the web versions, or the leanness of the files in the IDE to reduce context
|
|
18
|
-
- Further improvements to the two most important agents - the SM and DEV
|
|
19
|
-
|
|
20
|
-
## V3
|
|
21
|
-
|
|
22
|
-
With the customizability of V2, there were still some issues. A PM could only easily do one thing, create a PRD. And maintaining the consistency between Web and IDE agents was a pain.
|
|
23
|
-
|
|
24
|
-
V3 didn't fix the disconnect, but it did make it easier to maintain them all in a single folder, but there were only two official ide agents - all the rest were really made and optimized for the web.
|
|
25
|
-
|
|
26
|
-
V3's biggest impact was a full explosion of customizability. Tasks, Personas, Agent Configurations, Doc Templates, data payloads.
|
|
27
|
-
|
|
28
|
-
BUT - the BIGGEST change was the realization that we were barely scratching the surface of what could be loaded into Gemini Gems and still have very long chats. The BMad AGENT arose, and with a single V3 release - the future of the BMad Method was changed forever.
|
|
29
|
-
|
|
30
|
-
Now, instead of configuring 4+ web agents, all needing many files uploaded to create them, a single Agent called BMad, with a whole team, and the ability to switch and maintain personas evolved. Now you could in the same chat thread, talk to the whole team, or anyone on the team. No more exporting and reimporting docs to different chats - all of the sudden, you could finish the PRD, and ask Josh to pass it off to the Architect, and that was it, the architect just had it and we moved on! And all of that with just 7 total files to upload, delivering all power.
|
|
31
|
-
|
|
32
|
-
But V3 had a major flaw - with massive configuration comes massive complexity - and in some ways, V3 started to get away from core principles - power through simplicity. The core system needs to do one thing well and be solid, and not stretch too thing with every possible thing.
|
|
33
|
-
|
|
34
|
-
Also - while the dev is amazing and better in V3 than all the past, along with the SM - the dev started over documenting every step and really started to bloat stories with their own notes. And the SM was forgetting to add details to stories, or embellishing information. This was fixed somewhat in V3.1 - but the dev is still over explaining everything it does, instead of just capturing the changes to the story.
|
|
35
|
-
|
|
36
|
-
## V2
|
|
37
|
-
|
|
38
|
-
After V1 proved that the BMad method was solid and repeatable, 2 key ideas emerged. Separation of concerns, and building for the web made easier. By separating out templates - it was now much easier for the PRD fields to be customized, or the architecture.
|
|
39
|
-
|
|
40
|
-
And the introduction that really supercharged everything in my opinion, the web versions! There were 4 hard coded web variants hand crafted - and we saw that we could, dirt cheap, work with agents for hours in the massive context of Gemini - from a PRD generating PM, through to an architect and even an analyst that could help us do extensive market research and brain storming.
|
|
41
|
-
|
|
42
|
-
What I never expected is the names would stick, and people would keep the sample names I made that I thought people would configure. But now 4 version is, people refer to xiaofen, and xiaochan, and xiaomin! And when I randomly changed the names, I got A LOT of feedback! These have become trusted allies people are relying on, including for me!
|
|
43
|
-
|
|
44
|
-
## V1
|
|
45
|
-
|
|
46
|
-
Believe it or not (well you can view the link), V1 was a simple 7 file system! 7 Core agents working in harmony to help build a pretty specific type of application. But it showed its power and adaptability.
|
|
47
|
-
|
|
48
|
-
Meant to be a simple Tech Demo showing how custom agents with agile personas can help streamline your project, and create rails for your dev agents that to that point had gone unmatched - while also putting a focus on the planning phases - the project sparked the imagination of many, and a seed of a potential was realized.
|