Compare commits
55 Commits
e0555d847f
...
2c40c9ea7a
| Author | SHA1 | Date |
|---|---|---|
|
|
2c40c9ea7a | |
|
|
00d4f20ec1 | |
|
|
527395e0af | |
|
|
28ff5b21e5 | |
|
|
d9c4e7b4d6 | |
|
|
32693f1a6b | |
|
|
874ae40bb2 | |
|
|
6292b0323f | |
|
|
3339f24890 | |
|
|
c0877e795f | |
|
|
ffd7d53be5 | |
|
|
031a9093a1 | |
|
|
2a12c6b2f0 | |
|
|
bb046f5062 | |
|
|
2b809e56a4 | |
|
|
5988fe0506 | |
|
|
61d89c82ef | |
|
|
30a98633cd | |
|
|
b7315c6e32 | |
|
|
6a0046917a | |
|
|
c8f5b60598 | |
|
|
7bc2b5e0e0 | |
|
|
1ed5c9d94b | |
|
|
fb76895145 | |
|
|
ebf1513069 | |
|
|
10f02a8f15 | |
|
|
7857b17626 | |
|
|
063aa58b8d | |
|
|
9421f20b69 | |
|
|
956c43ff62 | |
|
|
1b3c3c5013 | |
|
|
066bfe32e9 | |
|
|
ee25fcca6f | |
|
|
4c470d9948 | |
|
|
0782e291fd | |
|
|
5c9227340e | |
|
|
350a1eaa47 | |
|
|
140ae57f2a | |
|
|
c9ebe1b417 | |
|
|
835d6d85a5 | |
|
|
dc8293e5df | |
|
|
7f1a55ca8c | |
|
|
8e5898e862 | |
|
|
44ba15f9a1 | |
|
|
db8f856fce | |
|
|
ec973ebcf3 | |
|
|
4974cd847f | |
|
|
5aab72caba | |
|
|
434e7efab6 | |
|
|
0d3b317598 | |
|
|
09ce8559f2 | |
|
|
e3ffdf9c90 | |
|
|
d812205470 | |
|
|
ed76f57a19 | |
|
|
f7846fd5eb |
|
|
@ -56,17 +56,13 @@ areas:
|
|||
- "src/**/workflows/**"
|
||||
rules:
|
||||
- id: "workflow_entry_point_required"
|
||||
description: "Every workflow folder must have workflow.yaml, workflow.md, or workflow.xml as entry point"
|
||||
description: "Every workflow folder must have workflow.md as entry point"
|
||||
severity: "high"
|
||||
|
||||
- id: "sharded_workflow_steps_folder"
|
||||
description: "Sharded workflows (using workflow.md) must have steps/ folder with numbered files (step-01-*.md, step-02-*.md)"
|
||||
severity: "high"
|
||||
|
||||
- id: "standard_workflow_instructions"
|
||||
description: "Standard workflows using workflow.yaml must include instructions.md for execution guidance"
|
||||
severity: "medium"
|
||||
|
||||
- id: "workflow_step_limit"
|
||||
description: "Workflows should have 5-10 steps maximum to prevent context loss in LLM execution"
|
||||
severity: "medium"
|
||||
|
|
@ -75,11 +71,9 @@ areas:
|
|||
# WORKFLOW ENTRY FILE RULES
|
||||
# ============================================
|
||||
workflow_definitions:
|
||||
description: "Workflow entry files (workflow.yaml, workflow.md, workflow.xml)"
|
||||
description: "Workflow entry files (workflow.md)"
|
||||
globs:
|
||||
- "src/**/workflows/**/workflow.yaml"
|
||||
- "src/**/workflows/**/workflow.md"
|
||||
- "src/**/workflows/**/workflow.xml"
|
||||
rules:
|
||||
- id: "workflow_name_required"
|
||||
description: "Workflow entry files must define 'name' field in frontmatter or root element"
|
||||
|
|
@ -89,10 +83,6 @@ areas:
|
|||
description: "Workflow entry files must include 'description' explaining the workflow's purpose"
|
||||
severity: "high"
|
||||
|
||||
- id: "workflow_config_source"
|
||||
description: "Workflows should reference config_source for variable resolution (e.g., {project-root}/_bmad/module/config.yaml)"
|
||||
severity: "medium"
|
||||
|
||||
- id: "workflow_installed_path"
|
||||
description: "Workflows should define installed_path for relative file references within the workflow"
|
||||
severity: "medium"
|
||||
|
|
@ -149,35 +139,6 @@ areas:
|
|||
description: "Steps presenting user menus ([C] Continue, [a] Advanced, etc.) must HALT and wait for response"
|
||||
severity: "high"
|
||||
|
||||
# ============================================
|
||||
# XML WORKFLOW/TASK RULES
|
||||
# ============================================
|
||||
xml_workflows:
|
||||
description: "XML-based workflows and tasks"
|
||||
globs:
|
||||
- "src/**/workflows/**/*.xml"
|
||||
- "src/**/tasks/**/*.xml"
|
||||
rules:
|
||||
- id: "xml_task_id_required"
|
||||
description: "XML tasks must have unique 'id' attribute on root task element"
|
||||
severity: "high"
|
||||
|
||||
- id: "xml_llm_instructions"
|
||||
description: "XML workflows should include <llm> section with critical execution instructions for the agent"
|
||||
severity: "medium"
|
||||
|
||||
- id: "xml_step_numbering"
|
||||
description: "XML steps should use n='X' attribute for sequential numbering"
|
||||
severity: "medium"
|
||||
|
||||
- id: "xml_action_tags"
|
||||
description: "Use <action> for required actions, <ask> for user input (must HALT), <goto> for jumps, <check if='...'> for conditionals"
|
||||
severity: "medium"
|
||||
|
||||
- id: "xml_ask_must_halt"
|
||||
description: "<ask> tags require agent to HALT and wait for user response before continuing"
|
||||
severity: "high"
|
||||
|
||||
# ============================================
|
||||
# WORKFLOW CONTENT QUALITY
|
||||
# ============================================
|
||||
|
|
@ -185,7 +146,6 @@ areas:
|
|||
description: "Content quality and consistency rules for all workflow files"
|
||||
globs:
|
||||
- "src/**/workflows/**/*.md"
|
||||
- "src/**/workflows/**/*.yaml"
|
||||
rules:
|
||||
- id: "communication_language_variable"
|
||||
description: "Workflows should use {communication_language} variable for agent output language consistency"
|
||||
|
|
|
|||
|
|
@ -1,6 +0,0 @@
|
|||
---
|
||||
name: bmad-os-audit-file-refs
|
||||
description: Audit BMAD source files for file-reference convention violations using parallel Haiku subagents. Use when users requests an "audit file references" for a skill, workflow or task.
|
||||
---
|
||||
|
||||
Read `prompts/instructions.md` and execute.
|
||||
|
|
@ -1,59 +0,0 @@
|
|||
# audit-file-refs
|
||||
|
||||
Audit new-format BMAD source files for file-reference convention violations using parallel Haiku subagents.
|
||||
|
||||
## Convention
|
||||
|
||||
In new-format BMAD workflow and task files (`src/bmm/`, `src/core/`, `src/utility/`), every file path reference must use one of these **valid** forms:
|
||||
|
||||
- `{project-root}/_bmad/path/to/file.ext` — canonical form, always correct
|
||||
- `{installed_path}/relative/path` — valid in new-format step files (always defined by workflow.md before any step is reached)
|
||||
- Template/runtime variables: `{nextStepFile}`, `{workflowFile}`, `{{mustache}}`, `{output_folder}`, `{communication_language}`, etc. — skip these, they are substituted at runtime
|
||||
|
||||
**Flag any reference that uses:**
|
||||
|
||||
- `./step-NN.md` or `../something.md` — relative paths
|
||||
- `step-NN.md` — bare filename with no path prefix
|
||||
- `steps/step-NN.md` — bare steps-relative path (missing `{project-root}/_bmad/...` prefix)
|
||||
- `` `_bmad/core/tasks/help.md` `` — bare `_bmad/` path (missing `{project-root}/`)
|
||||
- `/Users/...`, `/home/...`, `C:\...` — absolute system paths
|
||||
|
||||
References inside fenced code blocks (``` ``` ```) are examples — skip them.
|
||||
|
||||
Old-format files in `src/bmm/workflows/4-implementation/` use `{installed_path}` by design within the XML calling chain — exclude that directory entirely.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Run this command to get the file list:
|
||||
```
|
||||
find src/bmm src/core src/utility -type f \( -name "*.md" -o -name "*.yaml" \) | grep -v "4-implementation" | sort
|
||||
```
|
||||
|
||||
2. Divide the resulting file paths into batches of roughly 20 files each.
|
||||
|
||||
3. For each batch, spawn a subagent (`subagent_type: "Explore"`, `model: "haiku"`) with this prompt (fill in the actual file paths):
|
||||
|
||||
> Read each of these files (use the Read tool on each):
|
||||
> [list the file paths from this batch]
|
||||
>
|
||||
> For each file, identify every line that contains a file path reference that violates the convention described below. Skip references inside fenced code blocks. Skip template variables (anything containing `{` that isn't `{project-root}` or `{installed_path}`).
|
||||
>
|
||||
> **Valid references:** `{project-root}/_bmad/...`, `{installed_path}/...`, template variables.
|
||||
> **Flag:** bare filenames (`step-NN.md`), `./` or `../` relative paths, bare `steps/` paths, bare `_bmad/` paths (without `{project-root}/`), absolute system paths.
|
||||
>
|
||||
> Return findings as a list:
|
||||
> `path/to/file.md:LINE_NUMBER | VIOLATION_TYPE | offending text`
|
||||
>
|
||||
> If a file has no violations, include it as: `path/to/file.md | clean`
|
||||
>
|
||||
> End your response with a single line: `FILES CHECKED: N` where N is the exact number of files you read.
|
||||
|
||||
4. Collect all findings from all subagents.
|
||||
|
||||
5. **Self-check before reporting:** Count the total number of files returned by the `find` command. Sum the `FILES CHECKED: N` values across all subagent responses. If the totals do not match, identify which files are missing and re-run subagents for those files before proceeding. Do not produce the final report until all files are accounted for.
|
||||
|
||||
6. Output a final report:
|
||||
- Group findings by violation type
|
||||
- List each finding as `file:line — offending text`
|
||||
- Show total count of violations and number of affected files
|
||||
- If nothing found, say "All files conform to the convention."
|
||||
|
|
@ -1,177 +0,0 @@
|
|||
---
|
||||
name: bmad-os-changelog-social
|
||||
description: Generate social media announcements for Discord, Twitter, and LinkedIn from the latest changelog entry. Use when user asks to 'create release announcement' or 'create social posts' or share changelog updates.
|
||||
---
|
||||
|
||||
# Changelog Social
|
||||
|
||||
Generate engaging social media announcements from changelog entries.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Extract Changelog Entry
|
||||
|
||||
Read `./CHANGELOG.md` and extract the latest version entry. The changelog follows this format:
|
||||
|
||||
```markdown
|
||||
## [VERSION]
|
||||
|
||||
### 🎁 Features
|
||||
* **Title** — Description
|
||||
|
||||
### 🐛 Bug Fixes
|
||||
* **Title** — Description
|
||||
|
||||
### 📚 Documentation
|
||||
* **Title** — Description
|
||||
|
||||
### 🔧 Maintenance
|
||||
* **Title** — Description
|
||||
```
|
||||
|
||||
Parse:
|
||||
- **Version number** (e.g., `6.0.0-Beta.5`)
|
||||
- **Features** - New functionality, enhancements
|
||||
- **Bug Fixes** - Fixes users will care about
|
||||
- **Documentation** - New or improved docs
|
||||
- **Maintenance** - Dependency updates, tooling improvements
|
||||
|
||||
### Step 2: Get Git Contributors
|
||||
|
||||
Use git log to find contributors since the previous version. Get commits between the current version tag and the previous one:
|
||||
|
||||
```bash
|
||||
# Find the previous version tag first
|
||||
git tag --sort=-version:refname | head -5
|
||||
|
||||
# Get commits between versions with PR numbers and authors
|
||||
git log <previous-tag>..<current-tag> --pretty=format:"%h|%s|%an" --grep="#"
|
||||
```
|
||||
|
||||
Extract PR numbers from commit messages that contain `#` followed by digits. Compile unique contributors.
|
||||
|
||||
### Step 3: Generate Discord Announcement
|
||||
|
||||
**Limit: 2,000 characters per message.** Split into multiple messages if needed.
|
||||
|
||||
Use this template style:
|
||||
|
||||
```markdown
|
||||
🚀 **BMad vVERSION RELEASED!**
|
||||
|
||||
🎉 [Brief hype sentence]
|
||||
|
||||
🪥 **KEY HIGHLIGHT** - [One-line summary]
|
||||
|
||||
🎯 **CATEGORY NAME**
|
||||
• Feature one - brief description
|
||||
• Feature two - brief description
|
||||
• Coming soon: Future teaser
|
||||
|
||||
🔧 **ANOTHER CATEGORY**
|
||||
• Fix or feature
|
||||
• Another item
|
||||
|
||||
📚 **DOCS OR OTHER**
|
||||
• Item
|
||||
• Item with link
|
||||
|
||||
🌟 **COMMUNITY PHILOSOPHY** (optional - include for major releases)
|
||||
• Everything is FREE - No paywalls
|
||||
• Knowledge shared, not sold
|
||||
|
||||
📊 **STATS**
|
||||
X commits | Y PRs merged | Z files changed
|
||||
|
||||
🙏 **CONTRIBUTORS**
|
||||
@username1 (X PRs!), @username2 (Y PRs!)
|
||||
@username3, @username4, username5 + dependabot 🛡️
|
||||
Community-driven FTW! 🌟
|
||||
|
||||
📦 **INSTALL:**
|
||||
`npx bmad-method@VERSION install`
|
||||
|
||||
⭐ **SUPPORT US:**
|
||||
🌟 GitHub: github.com/bmad-code-org/BMAD-METHOD/
|
||||
📺 YouTube: youtube.com/@BMadCode
|
||||
☕ Donate: buymeacoffee.com/bmad
|
||||
|
||||
🔥 **Next version tease!**
|
||||
```
|
||||
|
||||
**Content Strategy:**
|
||||
- Focus on **user impact** - what's better for them?
|
||||
- Highlight **annoying bugs fixed** that frustrated users
|
||||
- Show **new capabilities** that enable workflows
|
||||
- Keep it **punchy** - use emojis and short bullets
|
||||
- Add **personality** - excitement, humor, gratitude
|
||||
|
||||
### Step 4: Generate Twitter Post
|
||||
|
||||
**Limit: 25,000 characters per tweet (Premium).** With Premium, use a single comprehensive post matching the Discord style (minus Discord-specific formatting). Aim for 1,500-3,000 characters for better engagement.
|
||||
|
||||
**Threads are optional** — only use for truly massive releases where you want multiple engagement points.
|
||||
|
||||
See `examples/twitter-example.md` for the single-post Premium format.
|
||||
|
||||
## Content Selection Guidelines
|
||||
|
||||
**Include:**
|
||||
- New features that change workflows
|
||||
- Bug fixes for annoying/blocking issues
|
||||
- Documentation that helps users
|
||||
- Performance improvements
|
||||
- New agents or workflows
|
||||
- Breaking changes (call out clearly)
|
||||
|
||||
**Skip/Minimize:**
|
||||
- Internal refactoring
|
||||
- Dependency updates (unless user-facing)
|
||||
- Test improvements
|
||||
- Minor style fixes
|
||||
|
||||
**Emphasize:**
|
||||
- "Finally fixed" issues
|
||||
- "Faster" operations
|
||||
- "Easier" workflows
|
||||
- "Now supports" capabilities
|
||||
|
||||
## Examples
|
||||
|
||||
Reference example posts in `examples/` for tone and formatting guidance:
|
||||
|
||||
- **discord-example.md** — Full Discord announcement with emojis, sections, contributor shout-outs
|
||||
- **twitter-example.md** — Twitter thread format (5 tweets max for major releases)
|
||||
- **linkedin-example.md** — Professional post for major/minor releases with significant features
|
||||
|
||||
**When to use LinkedIn:**
|
||||
- Major version releases (e.g., v6.0.0 Beta, v7.0.0)
|
||||
- Minor releases with exceptional new features
|
||||
- Community milestone announcements
|
||||
|
||||
Read the appropriate example file before generating to match the established style and voice.
|
||||
|
||||
## Output Format
|
||||
|
||||
**CRITICAL: ALWAYS write to files** - Create files in `_bmad-output/social/` directory:
|
||||
|
||||
1. `{repo-name}-discord-{version}.md` - Discord announcement
|
||||
2. `{repo-name}-twitter-{version}.md` - Twitter post
|
||||
3. `{repo-name}-linkedin-{version}.md` - LinkedIn post (if applicable)
|
||||
|
||||
Also present a preview in the chat:
|
||||
|
||||
```markdown
|
||||
## Discord Announcement
|
||||
|
||||
[paste Discord content here]
|
||||
|
||||
## Twitter Post
|
||||
|
||||
[paste Twitter content here]
|
||||
```
|
||||
|
||||
Files created:
|
||||
- `_bmad-output/social/{filename}`
|
||||
|
||||
Offer to make adjustments if the user wants different emphasis, tone, or content.
|
||||
|
|
@ -1,53 +0,0 @@
|
|||
🚀 **BMad v6.0.0-alpha.23 RELEASED!**
|
||||
|
||||
🎉 Huge update - almost beta!
|
||||
|
||||
🪟 **WINDOWS INSTALLER FIXED** - Menu arrows issue should be fixed! CRLF & ESM problems resolved.
|
||||
|
||||
🎯 **PRD WORKFLOWS IMPROVED**
|
||||
• Validation & Edit workflows added!
|
||||
• PRD Cohesion check ensures document flows beautifully
|
||||
• Coming soon: Use of subprocess optimization (context saved!)
|
||||
• Coming soon: Final format polish step in all workflows - Human consumption OR hyper-optimized LLM condensed initially!
|
||||
|
||||
🔧 **WORKFLOW CREATOR & VALIDATOR**
|
||||
• Subprocess support for advanced optimization
|
||||
• Path violation checks ensure integrity
|
||||
• Beyond error checking - offers optimization & flow suggestions!
|
||||
|
||||
📚 **NEW DOCS SITE** - docs.bmad-method.org
|
||||
• Diataxis framework: Tutorials, How-To, Explanations, References
|
||||
• Current docs still being revised
|
||||
• Tutorials, blogs & explainers coming soon!
|
||||
|
||||
💡 **BRAINSTORMING REVOLUTION**
|
||||
• 100+ idea goal (quantity-first!)
|
||||
• Anti-bias protocol (pivot every 10 ideas)
|
||||
• Chain-of-thought + simulated temperature prompts
|
||||
• Coming soon: SubProcessing (on-the-fly sub agents)
|
||||
|
||||
🌟 **COMMUNITY PHILOSOPHY**
|
||||
• Everything is FREE - No paywalls, no gated content
|
||||
• Knowledge shared, not sold
|
||||
• No premium tiers - full access to our ideas
|
||||
|
||||
📊 **27 commits | 217 links converted | 42+ docs created**
|
||||
|
||||
🙏 **17 Community PR Authors in this release!**
|
||||
@lum (6 PRs!), @q00 (3 PRs!), @phil (2 PRs!)
|
||||
@mike, @alex, @ramiz, @sjennings + dependabot 🛡️
|
||||
Community-driven FTW! 🌟
|
||||
|
||||
📦 **INSTALL ALPHA:**
|
||||
`npx bmad-method install`
|
||||
|
||||
⭐ **SUPPORT US:**
|
||||
🌟 GitHub: github.com/bmad-code-org/BMAD-METHOD/
|
||||
📺 YouTube: youtube.com/@BMadCode
|
||||
|
||||
🎤 **SPEAKING & MEDIA**
|
||||
Available for conferences, podcasts, media appearances!
|
||||
Topics: AI-Native Organizations (Any Industry), BMad Method
|
||||
DM on Discord for inquiries!
|
||||
|
||||
🔥 **V6 Beta is DAYS away!** January 22nd ETA - new features such as xyz and abc bug fixes!
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
🚀 **Announcing BMad Method v6.0.0 Beta - AI-Native Agile Development Framework**
|
||||
|
||||
I'm excited to share that BMad Method, the open-source AI-driven agile development framework, is entering Beta! After 27 alpha releases and countless community contributions, we're approaching a major milestone.
|
||||
|
||||
**What's New in v6.0.0-alpha.23**
|
||||
|
||||
🪟 **Windows Compatibility Fixed**
|
||||
We've resolved the installer issues that affected Windows users. The menu arrows problem, CRLF handling, and ESM compatibility are all resolved.
|
||||
|
||||
🎯 **Enhanced PRD Workflows**
|
||||
Our Product Requirements Document workflows now include validation and editing capabilities, with a new cohesion check that ensures your documents flow beautifully. Subprocess optimization is coming soon to save even more context.
|
||||
|
||||
🔧 **Workflow Creator & Validator**
|
||||
New tools for creating and validating workflows with subprocess support, path violation checks, and optimization suggestions that go beyond simple error checking.
|
||||
|
||||
📚 **New Documentation Platform**
|
||||
We've launched docs.bmad-method.org using the Diataxis framework - providing clear separation between tutorials, how-to guides, explanations, and references. Our documentation is being continuously revised and expanded.
|
||||
|
||||
💡 **Brainstorming Revolution**
|
||||
Our brainstorming workflows now use research-backed techniques: 100+ idea goals, anti-bias protocols, chain-of-thought reasoning, and simulated temperature prompts for higher divergence.
|
||||
|
||||
**Our Philosophy**
|
||||
|
||||
Everything in BMad Method is FREE. No paywalls, no gated content, no premium tiers. We believe knowledge should be shared, not sold. This is community-driven development at its finest.
|
||||
|
||||
**The Stats**
|
||||
- 27 commits in this release
|
||||
- 217 documentation links converted
|
||||
- 42+ new documents created
|
||||
- 17 community PR authors contributed
|
||||
|
||||
**Get Started**
|
||||
|
||||
```
|
||||
npx bmad-method@alpha install
|
||||
```
|
||||
|
||||
**Learn More**
|
||||
- GitHub: github.com/bmad-code-org/BMAD-METHOD
|
||||
- YouTube: youtube.com/@BMadCode
|
||||
- Docs: docs.bmad-method.org
|
||||
|
||||
**What's Next?**
|
||||
|
||||
Beta is just days away with an ETA of January 22nd. We're also available for conferences, podcasts, and media appearances to discuss AI-Native Organizations and the BMad Method.
|
||||
|
||||
Have you tried BMad Method yet? I'd love to hear about your experience in the comments!
|
||||
|
||||
#AI #SoftwareDevelopment #Agile #OpenSource #DevTools #LLM #AgentEngineering
|
||||
|
|
@ -1,55 +0,0 @@
|
|||
🚀 **BMad v6.0.0-alpha.23 RELEASED!**
|
||||
|
||||
Huge update - we're almost at Beta! 🎉
|
||||
|
||||
🪟 **WINDOWS INSTALLER FIXED** - Menu arrows issue should be fixed! CRLF & ESM problems resolved.
|
||||
|
||||
🎯 **PRD WORKFLOWS IMPROVED**
|
||||
• Validation & Edit workflows added!
|
||||
• PRD Cohesion check ensures document flows beautifully
|
||||
• Coming soon: Subprocess optimization (context saved!)
|
||||
• Coming soon: Final format polish step in all workflows
|
||||
|
||||
🔧 **WORKFLOW CREATOR & VALIDATOR**
|
||||
• Subprocess support for advanced optimization
|
||||
• Path violation checks ensure integrity
|
||||
• Beyond error checking - offers optimization & flow suggestions!
|
||||
|
||||
📚 **NEW DOCS SITE** - docs.bmad-method.org
|
||||
• Diataxis framework: Tutorials, How-To, Explanations, References
|
||||
• Current docs still being revised
|
||||
• Tutorials, blogs & explainers coming soon!
|
||||
|
||||
💡 **BRAINSTORMING REVOLUTION**
|
||||
• 100+ idea goal (quantity-first!)
|
||||
• Anti-bias protocol (pivot every 10 ideas)
|
||||
• Chain-of-thought + simulated temperature prompts
|
||||
• Coming soon: SubProcessing (on-the-fly sub agents)
|
||||
|
||||
🌟 **COMMUNITY PHILOSOPHY**
|
||||
• Everything is FREE - No paywalls, no gated content
|
||||
• Knowledge shared, not sold
|
||||
• No premium tiers - full access to our ideas
|
||||
|
||||
📊 **27 commits | 217 links converted | 42+ docs created**
|
||||
|
||||
🙏 **17 Community PR Authors in this release!**
|
||||
@lum (6 PRs!), @q00 (3 PRs!), @phil (2 PRs!)
|
||||
@mike, @alex, @ramiz, @sjennings + dependabot 🛡️
|
||||
Community-driven FTW! 🌟
|
||||
|
||||
📦 **INSTALL ALPHA:**
|
||||
`npx bmad-method install`
|
||||
|
||||
⭐ **SUPPORT US:**
|
||||
🌟 GitHub: github.com/bmad-code-org/BMAD-METHOD/
|
||||
📺 YouTube: youtube.com/@BMadCode
|
||||
|
||||
🎤 **SPEAKING & MEDIA**
|
||||
Available for conferences, podcasts, media appearances!
|
||||
Topics: AI-Native Organizations (Any Industry), BMad Method
|
||||
DM on Discord for inquiries!
|
||||
|
||||
🔥 **V6 Beta is DAYS away!** January 22nd ETA!
|
||||
|
||||
#AI #DevTools #Agile #OpenSource #LLM #AgentEngineering
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
---
|
||||
name: bmad-os-diataxis-style-fix
|
||||
description: Fixes documentation to comply with Diataxis framework and BMad Method style guide rules. Use when user asks to check or fix style of files under the docs folder.
|
||||
---
|
||||
|
||||
Read `prompts/instructions.md` and execute.
|
||||
|
|
@ -1,229 +0,0 @@
|
|||
# Diataxis Style Fixer
|
||||
|
||||
Automatically fixes documentation to comply with the Diataxis framework and BMad Method style guide.
|
||||
|
||||
## CRITICAL RULES
|
||||
|
||||
- **NEVER commit or push changes** — let the user review first
|
||||
- **NEVER make destructive edits** — preserve all content, only fix formatting
|
||||
- **Use Edit tool** — make targeted fixes, not full file rewrites
|
||||
- **Show summary** — after fixing, list all changes made
|
||||
|
||||
## Input
|
||||
|
||||
Documentation file path or directory to fix. Defaults to `docs/` if not specified.
|
||||
|
||||
## Step 1: Understand Diataxis Framework
|
||||
|
||||
**Diataxis** is a documentation framework that categorizes content into four types based on two axes:
|
||||
|
||||
| | **Learning** (oriented toward future) | **Doing** (oriented toward present) |
|
||||
| -------------- | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
|
||||
| **Practical** | **Tutorials** — lessons that guide learners through achieving a specific goal | **How-to guides** — step-by-step instructions for solving a specific problem |
|
||||
| **Conceptual** | **Explanation** — content that clarifies and describes underlying concepts | **Reference** — technical descriptions, organized for lookup |
|
||||
|
||||
**Key principles:**
|
||||
- Each document type serves a distinct user need
|
||||
- Don't mix types — a tutorial shouldn't explain concepts deeply
|
||||
- Focus on the user's goal, not exhaustive coverage
|
||||
- Structure follows purpose (tutorials are linear, reference is scannable)
|
||||
|
||||
## Step 2: Read the Style Guide
|
||||
|
||||
Read the project's style guide at `docs/_STYLE_GUIDE.md` to understand all project-specific conventions.
|
||||
|
||||
## Step 3: Detect Document Type
|
||||
|
||||
Based on file location, determine the document type:
|
||||
|
||||
| Location | Diataxis Type |
|
||||
| -------------------- | -------------------- |
|
||||
| `/docs/tutorials/` | Tutorial |
|
||||
| `/docs/how-to/` | How-to guide |
|
||||
| `/docs/explanation/` | Explanation |
|
||||
| `/docs/reference/` | Reference |
|
||||
| `/docs/glossary/` | Reference (glossary) |
|
||||
|
||||
## Step 4: Find and Fix Issues
|
||||
|
||||
For each markdown file, scan for issues and fix them:
|
||||
|
||||
### Universal Fixes (All Doc Types)
|
||||
|
||||
**Horizontal Rules (`---`)**
|
||||
- Remove any `---` outside of YAML frontmatter
|
||||
- Replace with `##` section headers or admonitions as appropriate
|
||||
|
||||
**`####` Headers**
|
||||
- Replace with bold text: `#### Header` → `**Header**`
|
||||
- Or convert to admonition if it's a warning/notice
|
||||
|
||||
**"Related" or "Next:" Sections**
|
||||
- Remove entire section including links
|
||||
- The sidebar handles navigation
|
||||
|
||||
**Deeply Nested Lists**
|
||||
- Break into sections with `##` headers
|
||||
- Flatten to max 3 levels
|
||||
|
||||
**Code Blocks for Dialogue/Examples**
|
||||
- Convert to admonitions:
|
||||
```
|
||||
:::note[Example]
|
||||
[content]
|
||||
:::
|
||||
```
|
||||
|
||||
**Bold Paragraph Callouts**
|
||||
- Convert to admonitions with appropriate type
|
||||
|
||||
**Too Many Admonitions**
|
||||
- Limit to 1-2 per section (tutorials allow 3-4 per major section)
|
||||
- Consolidate related admonitions
|
||||
- Remove less critical ones if over limit
|
||||
|
||||
**Table Cells / List Items > 2 Sentences**
|
||||
- Break into multiple rows/cells
|
||||
- Or shorten to 1-2 sentences
|
||||
|
||||
**Header Budget Exceeded**
|
||||
- Merge related sections
|
||||
- Convert some `##` to `###` subsections
|
||||
- Goal: 8-12 `##` per doc; 2-3 `###` per section
|
||||
|
||||
### Type-Specific Fixes
|
||||
|
||||
**Tutorials** (`/docs/tutorials/`)
|
||||
- Ensure hook describes outcome in 1-2 sentences
|
||||
- Add "What You'll Learn" bullet section if missing
|
||||
- Add `:::note[Prerequisites]` if missing
|
||||
- Add `:::tip[Quick Path]` TL;DR at top if missing
|
||||
- Use tables for phases, commands, agents
|
||||
- Add "What You've Accomplished" section if missing
|
||||
- Add Quick Reference table if missing
|
||||
- Add Common Questions section if missing
|
||||
- Add Getting Help section if missing
|
||||
- Add `:::tip[Key Takeaways]` at end if missing
|
||||
|
||||
**How-To** (`/docs/how-to/`)
|
||||
- Ensure hook starts with "Use the `X` workflow to..."
|
||||
- Add "When to Use This" with 3-5 bullets if missing
|
||||
- Add `:::note[Prerequisites]` if missing
|
||||
- Ensure steps are numbered `###` with action verbs
|
||||
- Add "What You Get" describing outputs if missing
|
||||
|
||||
**Explanation** (`/docs/explanation/`)
|
||||
- Ensure hook states what document explains
|
||||
- Organize content into scannable `##` sections
|
||||
- Add comparison tables for 3+ options
|
||||
- Link to how-to guides for procedural questions
|
||||
- Limit to 2-3 admonitions per document
|
||||
|
||||
**Reference** (`/docs/reference/`)
|
||||
- Ensure hook states what document references
|
||||
- Ensure structure matches reference type
|
||||
- Use consistent item structure throughout
|
||||
- Use tables for structured/comparative data
|
||||
- Link to explanation docs for conceptual depth
|
||||
- Limit to 1-2 admonitions per document
|
||||
|
||||
**Glossary** (`/docs/glossary/` or glossary files)
|
||||
- Ensure categories as `##` headers
|
||||
- Ensure terms in tables (not individual headers)
|
||||
- Definitions 1-2 sentences max
|
||||
- Bold term names in cells
|
||||
|
||||
## Step 5: Apply Fixes
|
||||
|
||||
For each file with issues:
|
||||
1. Read the file
|
||||
2. Use Edit tool for each fix
|
||||
3. Track what was changed
|
||||
|
||||
## Step 6: Summary
|
||||
|
||||
After processing all files, output a summary:
|
||||
|
||||
```markdown
|
||||
# Style Fixes Applied
|
||||
|
||||
**Files processed:** N
|
||||
**Files modified:** N
|
||||
|
||||
## Changes Made
|
||||
|
||||
### `path/to/file.md`
|
||||
- Removed horizontal rule at line 45
|
||||
- Converted `####` headers to bold text
|
||||
- Added `:::tip[Quick Path]` admonition
|
||||
- Consolidated 3 admonitions into 2
|
||||
|
||||
### `path/to/other.md`
|
||||
- Removed "Related:" section
|
||||
- Fixed table cell length (broke into 2 rows)
|
||||
|
||||
## Review Required
|
||||
|
||||
Please review the changes. When satisfied, commit and push as needed.
|
||||
```
|
||||
|
||||
## Common Patterns
|
||||
|
||||
**Converting `####` to bold:**
|
||||
```markdown
|
||||
#### Important Note
|
||||
Some text here.
|
||||
```
|
||||
→
|
||||
```markdown
|
||||
**Important Note**
|
||||
|
||||
Some text here.
|
||||
```
|
||||
|
||||
**Removing horizontal rule:**
|
||||
```markdown
|
||||
Some content above.
|
||||
|
||||
---
|
||||
|
||||
Some content below.
|
||||
```
|
||||
→
|
||||
```markdown
|
||||
Some content above.
|
||||
|
||||
## [Descriptive Section Header]
|
||||
|
||||
Some content below.
|
||||
```
|
||||
|
||||
**Converting code block to admonition:**
|
||||
```markdown
|
||||
```
|
||||
User: What should I do?
|
||||
|
||||
Agent: Run the workflow.
|
||||
```
|
||||
```
|
||||
→
|
||||
```markdown
|
||||
:::note[Example]
|
||||
|
||||
**User:** What should I do?
|
||||
|
||||
**Agent:** Run the workflow.
|
||||
|
||||
:::
|
||||
```
|
||||
|
||||
**Converting bold paragraph to admonition:**
|
||||
```markdown
|
||||
**IMPORTANT:** This is critical that you read this before proceeding.
|
||||
```
|
||||
→
|
||||
```markdown
|
||||
:::caution[Important]
|
||||
This is critical that you read this before proceeding.
|
||||
:::
|
||||
```
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
---
|
||||
name: bmad-os-draft-changelog
|
||||
description: "Analyzes changes since last release and updates CHANGELOG.md ONLY. Use when users requests 'update the changelog' or 'prepare changelog release notes'"
|
||||
---
|
||||
|
||||
Read `prompts/instructions.md` and execute.
|
||||
|
|
@ -1,82 +0,0 @@
|
|||
# Draft Changelog Execution
|
||||
|
||||
## ⚠️ IMPORTANT - READ FIRST
|
||||
|
||||
**This skill ONLY updates CHANGELOG.md. That is its entire purpose.**
|
||||
|
||||
- **DO** update CHANGELOG.md with the new version entry
|
||||
- **DO** present the draft for user review before editing
|
||||
- **DO NOT** trigger any GitHub release workflows
|
||||
- **DO NOT** run any other skills or workflows automatically
|
||||
- **DO NOT** make any commits
|
||||
|
||||
After the changelog is complete, you may suggest the user can run `/release-module` if they want to proceed with the actual release — but NEVER trigger it yourself.
|
||||
|
||||
## Input
|
||||
Project path (or run from project root)
|
||||
|
||||
## Step 1: Identify Current State
|
||||
- Get the latest released tag
|
||||
- Get current version
|
||||
- Verify there are commits since the last release
|
||||
|
||||
## Step 2: Launch Explore Agent
|
||||
|
||||
Use `thoroughness: "very thorough"` to analyze all changes since the last release tag.
|
||||
|
||||
**Key: For each merge commit, look up the merged PR/issue that was closed.**
|
||||
- Use `gh pr view` or git commit body to find the PR number
|
||||
- Read the PR description and comments to understand full context
|
||||
- Don't rely solely on commit merge messages - they lack context
|
||||
|
||||
**Analyze:**
|
||||
|
||||
1. **All merges/commits** since the last tag
|
||||
2. **For each merge, read the original PR/issue** that was closed
|
||||
3. **Files changed** with statistics
|
||||
4. **Categorize changes:**
|
||||
- 🎁 **Features** - New functionality, new agents, new workflows
|
||||
- 🐛 **Bug Fixes** - Fixed bugs, corrected issues
|
||||
- ♻️ **Refactoring** - Code improvements, reorganization
|
||||
- 📚 **Documentation** - Docs updates, README changes
|
||||
- 🔧 **Maintenance** - Dependency updates, tooling, infrastructure
|
||||
- 💥 **Breaking Changes** - Changes that may affect users
|
||||
|
||||
**Provide:**
|
||||
- Comprehensive summary of ALL changes with PR context
|
||||
- Categorization of each change
|
||||
- Identification of breaking changes
|
||||
- Significance assessment (major/minor/trivial)
|
||||
|
||||
## Step 3: Generate Draft Changelog
|
||||
|
||||
Format:
|
||||
```markdown
|
||||
## v0.X.X - [Date]
|
||||
|
||||
* [Change 1 - categorized by type]
|
||||
* [Change 2]
|
||||
```
|
||||
|
||||
Guidelines:
|
||||
- Present tense ("Fix bug" not "Fixed bug")
|
||||
- Most significant changes first
|
||||
- Group related changes
|
||||
- Clear, concise language
|
||||
- For breaking changes, clearly indicate impact
|
||||
|
||||
## Step 4: Present Draft & Update CHANGELOG.md
|
||||
|
||||
Show the draft with current version, last tag, commit count, and options to edit/retry.
|
||||
|
||||
When user accepts:
|
||||
1. Update CHANGELOG.md with the new entry (insert at top, after `# Changelog` header)
|
||||
2. STOP. That's it. You're done.
|
||||
|
||||
You may optionally suggest: *"When ready, you can run `/release-module` to create the actual release."*
|
||||
|
||||
**DO NOT:**
|
||||
- Trigger any GitHub workflows
|
||||
- Run any other skills
|
||||
- Make any commits
|
||||
- Do anything beyond updating CHANGELOG.md
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
---
|
||||
name: bmad-os-findings-triage
|
||||
description: Orchestrate HITL triage of review findings using parallel agents. Use when the user says 'triage these findings' or 'run findings triage' or has a batch of review findings to process.
|
||||
---
|
||||
|
||||
Read `prompts/instructions.md` and execute.
|
||||
|
|
@ -1,104 +0,0 @@
|
|||
# Finding Agent: {{TASK_ID}} — {{TASK_SUBJECT}}
|
||||
|
||||
You are a finding agent in the `{{TEAM_NAME}}` triage team. You own exactly one finding and will shepherd it through research, planning, human conversation, and a final decision.
|
||||
|
||||
## Your Assignment
|
||||
|
||||
- **Task:** `{{TASK_ID}}`
|
||||
- **Finding:** `{{FINDING_ID}}` — {{FINDING_TITLE}}
|
||||
- **Severity:** {{SEVERITY}}
|
||||
- **Team:** `{{TEAM_NAME}}`
|
||||
- **Team Lead:** `{{TEAM_LEAD_NAME}}`
|
||||
|
||||
## Phase 1 — Research (autonomous)
|
||||
|
||||
1. Read your task details with `TaskGet("{{TASK_ID}}")`.
|
||||
2. Read the relevant source files to understand the finding in context:
|
||||
{{FILE_LIST}}
|
||||
If no specific files are listed above, use codebase search to locate code relevant to the finding.
|
||||
|
||||
If a context document was provided:
|
||||
- Also read this context document for background: {{CONTEXT_DOC}}
|
||||
|
||||
If an initial triage was provided:
|
||||
- **Note:** The team lead triaged this as **{{INITIAL_TRIAGE}}** — {{TRIAGE_RATIONALE}}. Evaluate whether this triage is correct and incorporate your assessment into your plan.
|
||||
|
||||
**Rules for research:**
|
||||
- Work autonomously. Do not ask the team lead or the human for help during research.
|
||||
- Use `Read`, `Grep`, `Glob`, and codebase search tools to understand the codebase.
|
||||
- Trace call chains, check tests, read related code — be thorough.
|
||||
- Form your own opinion on whether this finding is real, a false positive, or somewhere in between.
|
||||
|
||||
## Phase 2 — Plan (display only)
|
||||
|
||||
Prepare a plan for dealing with this finding. The plan MUST cover:
|
||||
|
||||
1. **Assessment** — Is this finding real? What is the actual risk or impact?
|
||||
2. **Recommendation** — One of: fix it, accept the risk (wontfix), dismiss as not a real issue, or reject as a false positive.
|
||||
3. **If recommending a fix:** Describe the specific changes — which files, what modifications, why this approach.
|
||||
4. **If recommending against fixing:** Explain the reasoning — existing mitigations, acceptable risk, false positive rationale.
|
||||
|
||||
**Display the plan in your output.** Write it clearly so the human can read it directly. Follow the plan with a 2-5 line summary of the finding itself.
|
||||
|
||||
**CRITICAL: Do NOT send your plan or analysis to the team lead.** The team lead does not need your plan — the human reads it from your output stream. Sending full plans to the team lead wastes its context window.
|
||||
|
||||
## Phase 3 — Signal Ready
|
||||
|
||||
After displaying your plan, send exactly this to the team lead:
|
||||
|
||||
```
|
||||
SendMessage({
|
||||
type: "message",
|
||||
recipient: "{{TEAM_LEAD_NAME}}",
|
||||
content: "{{FINDING_ID}} ready for HITL",
|
||||
summary: "{{FINDING_ID}} ready for review"
|
||||
})
|
||||
```
|
||||
|
||||
Then **stop and wait**. Do not proceed until the human engages with you.
|
||||
|
||||
## Phase 4 — HITL Conversation
|
||||
|
||||
The human will review your plan and talk to you directly. This is a real conversation, not a rubber stamp:
|
||||
|
||||
- The human may agree immediately, push back, ask questions, or propose alternatives.
|
||||
- Answer questions thoroughly. Refer back to specific code you read.
|
||||
- If the human wants a fix, **apply it** — edit the source files, verify the change makes sense.
|
||||
- If the human disagrees with your assessment, update your recommendation.
|
||||
- Stay focused on THIS finding only. Do not discuss other findings.
|
||||
- **Do not send a decision until the human explicitly states a verdict.** Acknowledging your plan is NOT a decision. Wait for clear direction like "fix it", "dismiss", "reject", "skip", etc.
|
||||
|
||||
## Phase 5 — Report Decision
|
||||
|
||||
When the human reaches a decision, send exactly ONE message to the team lead:
|
||||
|
||||
```
|
||||
SendMessage({
|
||||
type: "message",
|
||||
recipient: "{{TEAM_LEAD_NAME}}",
|
||||
content: "DECISION {{FINDING_ID}} {{TASK_ID}} [CATEGORY] | [one-sentence summary]",
|
||||
summary: "{{FINDING_ID}} [CATEGORY]"
|
||||
})
|
||||
```
|
||||
|
||||
Where `[CATEGORY]` is one of:
|
||||
|
||||
| Category | Meaning |
|
||||
|----------|---------|
|
||||
| **SKIP** | Human chose to skip without full review. |
|
||||
| **DEFER** | Human chose to defer to a later session. |
|
||||
| **FIX** | Change applied. List the file paths changed and what each change was (use a parseable format: `files: path1, path2`). |
|
||||
| **WONTFIX** | Real finding, not worth fixing now. State why. |
|
||||
| **DISMISS** | Not a real finding or mitigated by existing design. State the mitigation. |
|
||||
| **REJECT** | False positive from the reviewer. State why it is wrong. |
|
||||
|
||||
After sending the decision, **go idle and wait for shutdown**. Do not take any further action. The team lead will send you a shutdown request — approve it.
|
||||
|
||||
## Rules
|
||||
|
||||
- You own ONE finding. Do not touch files unrelated to your finding unless required for the fix.
|
||||
- Your plan is for the human's eyes — display it in your output, never send it to the team lead.
|
||||
- Your only messages to the team lead are: (1) ready for HITL, (2) final decision. Nothing else.
|
||||
- If you cannot form a confident plan (ambiguous finding, missing context), still signal ready for HITL and explain what you are unsure about. The HITL conversation will resolve it.
|
||||
- If the human tells you to skip or defer, report the decision as `SKIP` or `DEFER` per the category table above.
|
||||
- When you receive a shutdown request, approve it immediately.
|
||||
|
|
@ -1,286 +0,0 @@
|
|||
# Findings Triage — Team Lead Orchestration
|
||||
|
||||
You are the team lead for a findings triage session. Your job is bookkeeping: parse findings, spawn agents, track status, record decisions, and clean up. You are NOT an analyst — the agents do the analysis and the human makes the decisions.
|
||||
|
||||
**Be minimal.** Short confirmations. No editorializing. No repeating what agents already said.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1 — Setup
|
||||
|
||||
### 1.1 Determine Input Source
|
||||
|
||||
The human will provide findings in one of three ways:
|
||||
|
||||
1. **A findings report file** — a markdown file with structured findings. Read the file.
|
||||
2. **A pre-populated task list** — tasks already exist. Call `TaskList` to discover them.
|
||||
- If tasks are pre-populated: skip section 1.2 (parsing) and section 1.4 (task creation). Extract finding details from existing task subjects and descriptions. Number findings based on task order. Proceed from section 1.3 (pre-spawn checks).
|
||||
3. **Inline findings** — pasted directly in conversation. Parse them.
|
||||
|
||||
Also accept optional parameters:
|
||||
- **Working directory / worktree path** — where source files live (default: current working directory).
|
||||
- **Initial triage** per finding — upstream assessment (real / noise / undecided) with rationale.
|
||||
- **Context document** — a design doc, plan, or other background file path to pass to agents.
|
||||
|
||||
### 1.2 Parse Findings
|
||||
|
||||
Extract from each finding:
|
||||
- **Title / description**
|
||||
- **Severity** (Critical / High / Medium / Low)
|
||||
- **Relevant file paths**
|
||||
- **Initial triage** (if provided)
|
||||
|
||||
Number findings sequentially: F1, F2, ... Fn. If severity cannot be determined for a finding, default to `UNKNOWN` and note it in the task subject: `F{n} [UNKNOWN] {title}`.
|
||||
|
||||
**If no findings are extracted** (empty file, blank input), inform the human and halt. Do not proceed to task creation or team setup.
|
||||
|
||||
**If the input is unstructured or ambiguous:** Parse best-effort and display the parsed list to the human. Ask for confirmation before proceeding. Do NOT spawn agents until confirmed.
|
||||
|
||||
### 1.3 Pre-Spawn Checks
|
||||
|
||||
**Large batch (>25 findings):**
|
||||
HALT. Tell the human:
|
||||
> "There are {N} findings. Spawning {N} agents at once may overwhelm the system. I recommend processing in waves of ~20. Proceed with all at once, or batch into waves?"
|
||||
|
||||
Wait for the human to decide. If batching, record wave assignments (Wave 1: F1-F20, Wave 2: F21-Fn).
|
||||
|
||||
**Same-file conflicts:**
|
||||
Scan all findings for overlapping file paths. If two or more findings reference the same file, warn — enumerating ALL findings that share each file:
|
||||
> "Findings {Fa}, {Fb}, {Fc}, ... all reference `{file}`. Concurrent edits may conflict. Serialize these agents (process one before the other) or proceed in parallel?"
|
||||
|
||||
Wait for the human to decide. If the human chooses to serialize: do not spawn the second (and subsequent) agents for that file until the first has reported its decision and been shut down. Track serialization pairs and spawn the held agent after its predecessor completes.
|
||||
|
||||
### 1.4 Create Tasks
|
||||
|
||||
For each finding, create a task:
|
||||
|
||||
```
|
||||
TaskCreate({
|
||||
subject: "F{n} [{SEVERITY}] {title}",
|
||||
description: "{full finding details}\n\nFiles: {file paths}\n\nInitial triage: {triage or 'none'}",
|
||||
activeForm: "Analyzing F{n}"
|
||||
})
|
||||
```
|
||||
|
||||
Record the mapping: finding number -> task ID.
|
||||
|
||||
### 1.5 Create Team
|
||||
|
||||
```
|
||||
TeamCreate({
|
||||
team_name: "{review-type}-triage",
|
||||
description: "HITL triage of {N} findings from {source}"
|
||||
})
|
||||
```
|
||||
|
||||
Use a contextual name based on the review type (e.g., `pr-review-triage`, `prompt-audit-triage`, `code-review-triage`). If unsure, use `findings-triage`.
|
||||
|
||||
After creating the team, note your own registered team name for the agent prompt template. Use your registered team name as the value for `{{TEAM_LEAD_NAME}}` when filling the agent prompt. If unsure of your name, read the team config at `~/.claude/teams/{team-name}/config.json` to find your own entry in the members list.
|
||||
|
||||
### 1.6 Spawn Agents
|
||||
|
||||
Read the agent prompt template from `prompts/agent-prompt.md`.
|
||||
|
||||
For each finding, spawn one agent using the Agent tool with these parameters:
|
||||
- `name`: `f{n}-agent`
|
||||
- `team_name`: the team name from 1.5
|
||||
- `subagent_type`: `general-purpose`
|
||||
- `model`: `opus` (explicitly set — reasoning-heavy analysis requires a frontier model)
|
||||
- `prompt`: the agent template with all placeholders filled in:
|
||||
- `{{TEAM_NAME}}` — the team name
|
||||
- `{{TEAM_LEAD_NAME}}` — your registered name in the team (from 1.5)
|
||||
- `{{TASK_ID}}` — the task ID from 1.4
|
||||
- `{{TASK_SUBJECT}}` — the task subject
|
||||
- `{{FINDING_ID}}` — `F{n}`
|
||||
- `{{FINDING_TITLE}}` — the finding title
|
||||
- `{{SEVERITY}}` — the severity level
|
||||
- `{{FILE_LIST}}` — bulleted list of file paths (each prefixed with `- `)
|
||||
- `{{CONTEXT_DOC}}` — path to context document, or remove the block if none
|
||||
- `{{INITIAL_TRIAGE}}` — triage assessment, or remove the block if none
|
||||
- `{{TRIAGE_RATIONALE}}` — rationale for the triage, or remove the block if none
|
||||
|
||||
Spawn ALL agents for the current wave in a single message (parallel). If batching, spawn only the current wave.
|
||||
|
||||
After spawning, print:
|
||||
|
||||
```
|
||||
All {N} agents spawned. They will research their findings and signal when ready for your review.
|
||||
```
|
||||
|
||||
Initialize the scorecard (internal state):
|
||||
|
||||
```
|
||||
Scorecard:
|
||||
- Total: {N}
|
||||
- Pending: {N}
|
||||
- Ready for review: 0
|
||||
- Completed: 0
|
||||
- Decisions: FIX=0 WONTFIX=0 DISMISS=0 REJECT=0 SKIP=0 DEFER=0
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 — HITL Review Loop
|
||||
|
||||
### 2.1 Track Agent Readiness
|
||||
|
||||
Agents will send messages matching: `F{n} ready for HITL`
|
||||
|
||||
When received:
|
||||
- Note which finding is ready.
|
||||
- Update the internal status tracker.
|
||||
- Print a short status line: `F{n} ready. ({ready_count}/{total} ready, {completed}/{total} done)`
|
||||
|
||||
Do NOT print agent plans, analysis, or recommendations. The human reads those directly from the agent output.
|
||||
|
||||
### 2.2 Status Dashboard
|
||||
|
||||
When the human asks for status (or periodically when useful), print:
|
||||
|
||||
```
|
||||
=== Triage Status ===
|
||||
Ready for review: F3, F7, F11
|
||||
Still analyzing: F1, F5, F9
|
||||
Completed: F2 (FIX), F4 (DISMISS), F6 (REJECT)
|
||||
{completed}/{total} done
|
||||
===
|
||||
```
|
||||
|
||||
Keep it compact. No decoration beyond what is needed.
|
||||
|
||||
### 2.3 Process Decisions
|
||||
|
||||
Agents will send messages matching: `DECISION F{n} {task_id} [CATEGORY] | [summary]`
|
||||
|
||||
When received:
|
||||
1. **Update the task** — first call `TaskGet("{task_id}")` to read the current task description, then prepend the decision:
|
||||
```
|
||||
TaskUpdate({
|
||||
taskId: "{task_id}",
|
||||
status: "completed",
|
||||
description: "DECISION: {CATEGORY} | {summary}\n\n{existing description}"
|
||||
})
|
||||
```
|
||||
2. **Update the scorecard** — increment the decision category counter. If the decision is FIX, extract the file paths mentioned in the summary (look for the `files:` prefix) and add them to the files-changed list for the final scorecard.
|
||||
3. **Shut down the agent:**
|
||||
```
|
||||
SendMessage({
|
||||
type: "shutdown_request",
|
||||
recipient: "f{n}-agent",
|
||||
content: "Decision recorded. Shutting down."
|
||||
})
|
||||
```
|
||||
4. **Print confirmation:** `F{n} closed: {CATEGORY}. {remaining} remaining.`
|
||||
|
||||
### 2.4 Human-Initiated Skip/Defer
|
||||
|
||||
If the human wants to skip or defer a finding without full engagement:
|
||||
|
||||
1. Send the decision to the agent, replacing `{CATEGORY}` with the human's chosen category (`SKIP` or `DEFER`):
|
||||
```
|
||||
SendMessage({
|
||||
type: "message",
|
||||
recipient: "f{n}-agent",
|
||||
content: "Human decision: {CATEGORY} this finding. Report {CATEGORY} as your decision and go idle.",
|
||||
summary: "F{n} {CATEGORY} directive"
|
||||
})
|
||||
```
|
||||
2. Wait for the agent to report the decision back (it will send `DECISION F{n} ... {CATEGORY}`).
|
||||
3. Process as a normal decision (2.3).
|
||||
|
||||
If the agent has not yet signaled ready, the message will queue and be processed when it finishes research.
|
||||
|
||||
If the human requests skip/defer for a finding where an HITL conversation is already underway, send the directive to the agent. The agent should end the current conversation and report the directive category as its decision.
|
||||
|
||||
### 2.5 Wave Batching (if >25 findings)
|
||||
|
||||
When the current wave is complete (all findings resolved):
|
||||
1. Print wave summary.
|
||||
2. Ask: `"Wave {W} complete. Spawn wave {W+1} ({count} findings)? (y/n)"`
|
||||
3. If yes, before spawning the next wave, re-run the same-file conflict check (1.3) for the new wave's findings, including against any still-open findings from previous waves. Then repeat Phase 1.4 (task creation) and 1.6 (agent spawning) only. Do NOT call TeamCreate again — the team already exists.
|
||||
4. If the human declines, treat unspawned findings as not processed. Proceed to Phase 3 wrap-up. Note the count of unprocessed findings in the final scorecard.
|
||||
5. Carry the scorecard forward across waves.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3 — Wrap-up
|
||||
|
||||
When all findings across all waves are resolved:
|
||||
|
||||
### 3.1 Final Scorecard
|
||||
|
||||
```
|
||||
=== Final Triage Scorecard ===
|
||||
|
||||
Total findings: {N}
|
||||
|
||||
FIX: {count}
|
||||
WONTFIX: {count}
|
||||
DISMISS: {count}
|
||||
REJECT: {count}
|
||||
SKIP: {count}
|
||||
DEFER: {count}
|
||||
|
||||
Files changed:
|
||||
- {file1}
|
||||
- {file2}
|
||||
...
|
||||
|
||||
Findings:
|
||||
F1 [{SEVERITY}] {title} — {DECISION}
|
||||
F2 [{SEVERITY}] {title} — {DECISION}
|
||||
...
|
||||
|
||||
=== End Triage ===
|
||||
```
|
||||
|
||||
### 3.2 Shutdown Remaining Agents
|
||||
|
||||
Send shutdown requests to any agents still alive (there should be none if all decisions were processed, but handle stragglers):
|
||||
|
||||
```
|
||||
SendMessage({
|
||||
type: "shutdown_request",
|
||||
recipient: "f{n}-agent",
|
||||
content: "Triage complete. Shutting down."
|
||||
})
|
||||
```
|
||||
|
||||
### 3.3 Offer to Save
|
||||
|
||||
Ask the human:
|
||||
> "Save the scorecard to a file? (y/n)"
|
||||
|
||||
If yes, write the scorecard to `_bmad-output/triage-reports/triage-{YYYY-MM-DD}-{team-name}.md`.
|
||||
|
||||
### 3.4 Delete Team
|
||||
|
||||
```
|
||||
TeamDelete()
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Edge Cases Reference
|
||||
|
||||
| Situation | Response |
|
||||
|-----------|----------|
|
||||
| >25 findings | HALT, suggest wave batching, wait for human decision |
|
||||
| Same-file conflict | Warn, suggest serializing, wait for human decision |
|
||||
| Unstructured input | Parse best-effort, display list, confirm before spawning |
|
||||
| Agent signals uncertainty | Normal — the HITL conversation resolves it |
|
||||
| Human skips/defers | Send directive to agent, process decision when reported |
|
||||
| Agent goes idle unexpectedly | Send a message to check status; agents stay alive until explicit shutdown |
|
||||
| Human asks to re-open a completed finding | Not supported in this session; suggest re-running triage on that finding |
|
||||
| All agents spawned but none ready yet | Tell the human agents are still analyzing; no action needed |
|
||||
|
||||
---
|
||||
|
||||
## Behavioral Rules
|
||||
|
||||
1. **Be minimal.** Short confirmations, compact dashboards. Do not repeat agent analysis.
|
||||
2. **Never auto-close.** Every finding requires a human decision. No exceptions.
|
||||
3. **One agent per finding.** Never batch multiple findings into one agent.
|
||||
4. **Protect your context window.** Agents display plans in their output, not in messages to you. If an agent sends you a long message, acknowledge it briefly and move on.
|
||||
5. **Track everything.** Finding number, task ID, agent name, decision, files changed. You are the single source of truth for the session.
|
||||
6. **Respect the human's pace.** They review in whatever order they want. Do not rush them. Do not suggest which finding to review next unless asked.
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
---
|
||||
name: bmad-os-gh-triage
|
||||
description: Analyze all github issues. Use when the user says 'triage the github issues' or 'analyze open github issues'.
|
||||
---
|
||||
|
||||
Read `prompts/instructions.md` and execute.
|
||||
|
|
@ -1,60 +0,0 @@
|
|||
You are analyzing a batch of GitHub issues for deep understanding and triage.
|
||||
|
||||
**YOUR TASK:**
|
||||
Read the issues in your batch and provide DEEP analysis:
|
||||
|
||||
1. **For EACH issue, analyze:**
|
||||
- What is this ACTUALLY about? (beyond keywords)
|
||||
- What component/system does it affect?
|
||||
- What's the impact and severity?
|
||||
- Is it a bug, feature request, or something else?
|
||||
- What specific theme does it belong to?
|
||||
|
||||
2. **PRIORITY ASSESSMENT:**
|
||||
- CRITICAL: Blocks users, security issues, data loss, broken installers
|
||||
- HIGH: Major functionality broken, important features missing
|
||||
- MEDIUM: Workarounds available, minor bugs, nice-to-have features
|
||||
- LOW: Edge cases, cosmetic issues, questions
|
||||
|
||||
3. **RELATIONSHIPS:**
|
||||
- Duplicates: Near-identical issues about the same problem
|
||||
- Related: Issues connected by theme or root cause
|
||||
- Dependencies: One issue blocks or requires another
|
||||
|
||||
**YOUR BATCH:**
|
||||
[Paste the batch of issues here - each with number, title, body, labels]
|
||||
|
||||
**OUTPUT FORMAT (JSON only, no markdown):**
|
||||
{
|
||||
"issues": [
|
||||
{
|
||||
"number": 123,
|
||||
"title": "issue title",
|
||||
"deep_understanding": "2-3 sentences explaining what this is really about",
|
||||
"affected_components": ["installer", "workflows", "docs"],
|
||||
"issue_type": "bug/feature/question/tech-debt",
|
||||
"priority": "CRITICAL/HIGH/MEDIUM/LOW",
|
||||
"priority_rationale": "Why this priority level",
|
||||
"theme": "installation/workflow/integration/docs/ide-support/etc",
|
||||
"relationships": {
|
||||
"duplicates_of": [456],
|
||||
"related_to": [789, 101],
|
||||
"blocks": [111]
|
||||
}
|
||||
}
|
||||
],
|
||||
"cross_repo_issues": [
|
||||
{"number": 123, "target_repo": "bmad-builder", "reason": "about agent builder"}
|
||||
],
|
||||
"cleanup_candidates": [
|
||||
{"number": 456, "reason": "v4-related/outdated/duplicate"}
|
||||
],
|
||||
"themes_found": {
|
||||
"Installation Blockers": {
|
||||
"count": 5,
|
||||
"root_cause": "Common pattern if identifiable"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
Return ONLY valid JSON. No explanations outside the JSON structure.
|
||||
|
|
@ -1,74 +0,0 @@
|
|||
# GitHub Issue Triage with AI Analysis
|
||||
|
||||
**CRITICAL RULES:**
|
||||
- NEVER include time or effort estimates in output or recommendations
|
||||
- Focus on WHAT needs to be done, not HOW LONG it takes
|
||||
- Use Bash tool with gh CLI for all GitHub operations
|
||||
|
||||
## Execution
|
||||
|
||||
### Step 1: Fetch Issues
|
||||
Use `gh issue list --json number,title,body,labels` to fetch all open issues.
|
||||
|
||||
### Step 2: Batch Creation
|
||||
Split issues into batches of ~10 issues each for parallel analysis.
|
||||
|
||||
### Step 3: Parallel Agent Analysis
|
||||
For EACH batch, use the Task tool with `subagent_type=general-purpose` to launch an agent with prompt from `prompts/agent-prompt.md`
|
||||
|
||||
### Step 4: Consolidate & Generate Report
|
||||
After all agents complete, create a comprehensive markdown report saved to `_bmad-output/triage-reports/triage-YYYY-MM-DD.md`
|
||||
|
||||
## Report Format
|
||||
|
||||
### Executive Summary
|
||||
- Total issues analyzed
|
||||
- Issue count by priority (CRITICAL, HIGH, MEDIUM, LOW)
|
||||
- Major themes discovered
|
||||
- Top 5 critical issues requiring immediate attention
|
||||
|
||||
### Critical Issues (CRITICAL Priority)
|
||||
For each CRITICAL issue:
|
||||
- **#123 - [Issue Title](url)**
|
||||
- **What it's about:** [Deep understanding]
|
||||
- **Affected:** [Components]
|
||||
- **Why Critical:** [Rationale]
|
||||
- **Suggested Action:** [Specific action]
|
||||
|
||||
### High Priority Issues (HIGH Priority)
|
||||
Same format as Critical, grouped by theme.
|
||||
|
||||
### Theme Clusters
|
||||
For each major theme:
|
||||
- **Theme Name** (N issues)
|
||||
- **What connects these:** [Pattern]
|
||||
- **Root cause:** [If identifiable]
|
||||
- **Consolidated actions:** [Bulk actions if applicable]
|
||||
- **Issues:** #123, #456, #789
|
||||
|
||||
### Relationships & Dependencies
|
||||
- **Duplicates:** List pairs with `gh issue close` commands
|
||||
- **Related Issues:** Groups of related issues
|
||||
- **Dependencies:** Blocking relationships
|
||||
|
||||
### Cross-Repo Issues
|
||||
Issues that should be migrated to other repositories.
|
||||
|
||||
For each, provide:
|
||||
```
|
||||
gh issue close XXX --repo CURRENT_REPO --comment "This issue belongs in REPO. Please report at https://github.com/TARGET_REPO/issues/new"
|
||||
```
|
||||
|
||||
### Cleanup Candidates
|
||||
- **v4-related:** Deprecated version issues with close commands
|
||||
- **Stale:** No activity >30 days
|
||||
- **Low priority + old:** Low priority issues >60 days old
|
||||
|
||||
### Actionable Next Steps
|
||||
Specific, prioritized actions:
|
||||
1. [CRITICAL] Fix broken installer - affects all new users
|
||||
2. [HIGH] Resolve Windows path escaping issues
|
||||
3. [HIGH] Address workflow integration bugs
|
||||
etc.
|
||||
|
||||
Include `gh` commands where applicable for bulk actions.
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
---
|
||||
name: bmad-os-release-module
|
||||
description: Perform requested version bump, git tag, npm publish, GitHub release. Use when user requests 'perform a release' only.
|
||||
---
|
||||
|
||||
Read `prompts/instructions.md` and execute.
|
||||
|
|
@ -1,53 +0,0 @@
|
|||
# Release BMad Module Execution
|
||||
|
||||
## Input
|
||||
Project path (or run from project root)
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### Step 1: Get Current State
|
||||
- Verify git working tree is clean
|
||||
- Get latest tag and current version
|
||||
- Check for unpushed commits
|
||||
|
||||
### Step 2: Get Changelog Entry
|
||||
|
||||
Ask the user for the changelog entry (from draft-changelog skill or manual).
|
||||
|
||||
### Step 3: Confirm Changelog
|
||||
|
||||
Show project name, current version, proposed next version, and changelog. Get confirmation.
|
||||
|
||||
### Step 4: Confirm Version Bump Type
|
||||
|
||||
Ask what type of bump: patch, minor, major, prerelease, or custom.
|
||||
|
||||
### Step 5: Update CHANGELOG.md
|
||||
|
||||
Insert new entry at top, commit, and push.
|
||||
|
||||
### Step 6: Bump Version
|
||||
|
||||
Run `npm version` to update package.json, create commit, and create tag.
|
||||
|
||||
### Step 7: Push Tag
|
||||
|
||||
Push the new version tag to GitHub.
|
||||
|
||||
### Step 8: Publish to npm
|
||||
|
||||
Publish the package.
|
||||
|
||||
### Step 9: Create GitHub Release
|
||||
|
||||
Create release with changelog notes using `gh release create`.
|
||||
|
||||
## Error Handling
|
||||
|
||||
Stop immediately on any step failure. Inform user and suggest fix.
|
||||
|
||||
## Important Notes
|
||||
|
||||
- Wait for user confirmation before destructive operations
|
||||
- Push changelog commit before version bump
|
||||
- Use explicit directory paths in commands
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
---
|
||||
name: bmad-os-review-pr
|
||||
description: Adversarial PR review tool (Raven's Verdict). Cynical deep review transformed into professional engineering findings. Use when user asks to 'review a PR' and provides a PR url or id.
|
||||
---
|
||||
|
||||
Read `prompts/instructions.md` and execute.
|
||||
|
|
@ -1,231 +0,0 @@
|
|||
# Raven's Verdict - Deep PR Review Tool
|
||||
|
||||
A cynical adversarial review, transformed into cold engineering professionalism.
|
||||
|
||||
## CRITICAL: Sandboxed Execution Rules
|
||||
|
||||
Before proceeding, you MUST verify:
|
||||
|
||||
- [ ] PR number or URL was EXPLICITLY provided in the user's message
|
||||
- [ ] You are NOT inferring the PR from conversation history
|
||||
- [ ] You are NOT looking at git branches, recent commits, or local state
|
||||
- [ ] You are NOT guessing or assuming any PR numbers
|
||||
|
||||
**If no explicit PR number/URL was provided, STOP immediately and ask:**
|
||||
"What PR number or URL should I review?"
|
||||
|
||||
## Preflight Checks
|
||||
|
||||
### 0.1 Parse PR Input
|
||||
|
||||
Extract PR number from user input. Examples of valid formats:
|
||||
|
||||
- `123` (just the number)
|
||||
- `#123` (with hash)
|
||||
- `https://github.com/owner/repo/pull/123` (full URL)
|
||||
|
||||
If a URL specifies a different repository than the current one:
|
||||
|
||||
```bash
|
||||
# Check current repo
|
||||
gh repo view --json nameWithOwner -q '.nameWithOwner'
|
||||
```
|
||||
|
||||
If mismatch detected, ask user:
|
||||
|
||||
> "This PR is from `{detected_repo}` but we're in `{current_repo}`. Proceed with reviewing `{detected_repo}#123`? (y/n)"
|
||||
|
||||
If user confirms, store `{REPO}` for use in all subsequent `gh` commands.
|
||||
|
||||
### 0.2 Ensure Clean Checkout
|
||||
|
||||
Verify the working tree is clean and check out the PR branch.
|
||||
|
||||
```bash
|
||||
# Check for uncommitted changes
|
||||
git status --porcelain
|
||||
```
|
||||
|
||||
If output is non-empty, STOP and tell user:
|
||||
|
||||
> "You have uncommitted changes. Please commit or stash them before running a PR review."
|
||||
|
||||
If clean, fetch and checkout the PR branch:
|
||||
|
||||
```bash
|
||||
# Fetch and checkout PR branch
|
||||
# For cross-repo PRs, include --repo {REPO}
|
||||
gh pr checkout {PR_NUMBER} [--repo {REPO}]
|
||||
```
|
||||
|
||||
If checkout fails, STOP and report the error.
|
||||
|
||||
Now you're on the PR branch with full access to all files as they exist in the PR.
|
||||
|
||||
### 0.3 Check PR Size
|
||||
|
||||
```bash
|
||||
# For cross-repo PRs, include --repo {REPO}
|
||||
gh pr view {PR_NUMBER} [--repo {REPO}] --json additions,deletions,changedFiles -q '{"additions": .additions, "deletions": .deletions, "files": .changedFiles}'
|
||||
```
|
||||
|
||||
**Size thresholds:**
|
||||
|
||||
| Metric | Warning Threshold |
|
||||
| ------------- | ----------------- |
|
||||
| Files changed | > 50 |
|
||||
| Lines changed | > 5000 |
|
||||
|
||||
If thresholds exceeded, ask user:
|
||||
|
||||
> "This PR has {X} files and {Y} line changes. That's large.
|
||||
>
|
||||
> **[f] Focus** - Pick specific files or directories to review
|
||||
> **[p] Proceed** - Review everything (may be slow/expensive)
|
||||
> **[a] Abort** - Stop here"
|
||||
|
||||
### 0.4 Note Binary Files
|
||||
|
||||
```bash
|
||||
# For cross-repo PRs, include --repo {REPO}
|
||||
gh pr diff {PR_NUMBER} [--repo {REPO}] --name-only | grep -E '\.(png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot|pdf|zip|tar|gz|bin|exe|dll|so|dylib)$' || echo "No binary files detected"
|
||||
```
|
||||
|
||||
Store list of binary files to skip. Note them in final output.
|
||||
|
||||
## Adversarial Review
|
||||
|
||||
### 1.1 Run Cynical Review
|
||||
|
||||
**INTERNAL PERSONA - Never post this directly:**
|
||||
|
||||
Task: You are a cynical, jaded code reviewer with zero patience for sloppy work. This PR was submitted by a clueless weasel and you expect to find problems. Find at least five issues to fix or improve in it. Number them. Be skeptical of everything. Ultrathink.
|
||||
|
||||
Output format:
|
||||
|
||||
```markdown
|
||||
### [NUMBER]. [FINDING TITLE] [likely]
|
||||
|
||||
**Severity:** [EMOJI] [LEVEL]
|
||||
|
||||
[DESCRIPTION - be specific, include file:line references]
|
||||
```
|
||||
|
||||
Severity scale:
|
||||
|
||||
| Level | Emoji | Meaning |
|
||||
| -------- | ----- | ------------------------------------------------------- |
|
||||
| Critical | 🔴 | Security issue, data loss risk, or broken functionality |
|
||||
| Moderate | 🟡 | Bug, performance issue, or significant code smell |
|
||||
| Minor | 🟢 | Style, naming, minor improvement opportunity |
|
||||
|
||||
Likely tag:
|
||||
|
||||
- Add `[likely]` to findings with high confidence, e.g. with direct evidence
|
||||
- Sort findings by severity (Critical → Moderate → Minor), not by confidence
|
||||
|
||||
## Tone Transformation
|
||||
|
||||
**Transform the cynical output into cold engineering professionalism.**
|
||||
|
||||
**Transformation rules:**
|
||||
|
||||
1. Remove all inflammatory language, insults, assumptions about the author
|
||||
2. Keep all technical substance, file references, severity ratings and likely tag
|
||||
3. Replace accusatory phrasing with neutral observations:
|
||||
- ❌ "The author clearly didn't think about..."
|
||||
- ✅ "This implementation may not account for..."
|
||||
4. Preserve skepticism as healthy engineering caution:
|
||||
- ❌ "This will definitely break in production"
|
||||
- ✅ "This pattern has historically caused issues in production environments"
|
||||
5. Add the suggested fixes.
|
||||
6. Keep suggestions actionable and specific
|
||||
|
||||
Output format after transformation:
|
||||
|
||||
```markdown
|
||||
## PR Review: #{PR_NUMBER}
|
||||
|
||||
**Title:** {PR_TITLE}
|
||||
**Author:** @{AUTHOR}
|
||||
**Branch:** {HEAD} → {BASE}
|
||||
|
||||
---
|
||||
|
||||
### Findings
|
||||
|
||||
[TRANSFORMED FINDINGS HERE]
|
||||
|
||||
---
|
||||
|
||||
### Summary
|
||||
|
||||
**Critical:** {COUNT} | **Moderate:** {COUNT} | **Minor:** {COUNT}
|
||||
|
||||
[BINARY_FILES_NOTE if any]
|
||||
|
||||
---
|
||||
|
||||
_Review generated by Raven's Verdict. LLM-produced analysis - findings may be incorrect or lack context. Verify before acting._
|
||||
```
|
||||
|
||||
## Post Review
|
||||
|
||||
### 3.1 Preview
|
||||
|
||||
Display the complete transformed review to the user.
|
||||
|
||||
```
|
||||
══════════════════════════════════════════════════════
|
||||
PREVIEW - This will be posted to PR #{PR_NUMBER}
|
||||
══════════════════════════════════════════════════════
|
||||
|
||||
[FULL REVIEW CONTENT]
|
||||
|
||||
══════════════════════════════════════════════════════
|
||||
```
|
||||
|
||||
### 3.2 Confirm
|
||||
|
||||
Ask user for explicit confirmation:
|
||||
|
||||
> **Ready to post this review to PR #{PR_NUMBER}?**
|
||||
>
|
||||
> **[y] Yes** - Post as comment
|
||||
> **[n] No** - Abort, do not post
|
||||
> **[e] Edit** - Let me modify before posting
|
||||
> **[s] Save only** - Save locally, don't post
|
||||
|
||||
### 3.3 Post or Save
|
||||
|
||||
**Write review to a temp file, then post:**
|
||||
|
||||
1. Write the review content to a temp file with a unique name (include PR number to avoid collisions)
|
||||
2. Post using `gh pr comment {PR_NUMBER} [--repo {REPO}] --body-file {path}`
|
||||
3. Delete the temp file after successful post
|
||||
|
||||
Do NOT use heredocs or `echo` - Markdown code blocks will break shell parsing. Use your file writing tool instead.
|
||||
|
||||
**If auth fails or post fails:**
|
||||
|
||||
1. Display error prominently:
|
||||
|
||||
```
|
||||
⚠️ FAILED TO POST REVIEW
|
||||
Error: {ERROR_MESSAGE}
|
||||
```
|
||||
|
||||
2. Keep the temp file and tell the user where it is, so they can post manually with:
|
||||
`gh pr comment {PR_NUMBER} [--repo {REPO}] --body-file {path}`
|
||||
|
||||
**If save only (s):**
|
||||
|
||||
Keep the temp file and inform user of location.
|
||||
|
||||
## Notes
|
||||
|
||||
- The "cynical asshole" phase is internal only - never posted
|
||||
- Tone transform MUST happen before any external output
|
||||
- When in doubt, ask the user - never assume
|
||||
- If you're unsure about severity, err toward higher severity
|
||||
- If you're unsure about confidence, be honest and use Medium or Low
|
||||
|
|
@ -1,177 +0,0 @@
|
|||
---
|
||||
name: bmad-os-review-prompt
|
||||
description: Review LLM workflow step prompts for known failure modes (silent ignoring, negation fragility, scope creep, etc). Use when user asks to "review a prompt" or "audit a workflow step".
|
||||
---
|
||||
|
||||
# Prompt Review Skill: PromptSentinel v1.2
|
||||
|
||||
**Version:** v1.2
|
||||
**Date:** March 2026
|
||||
**Target Models:** Frontier LLMs (Claude 4.6, GPT-5.3, Gemini 3.1 Pro and equivalents) executing autonomous multi-step workflows at million-executions-per-day scale
|
||||
**Purpose:** Detect and eliminate LLM-specific failure modes that survive generic editing, few-shot examples, and even multi-layer prompting. Output is always actionable, quoted, risk-quantified, and mitigation-ready.
|
||||
|
||||
---
|
||||
|
||||
### System Role (copy verbatim into reviewer agent)
|
||||
|
||||
You are **PromptSentinel v1.2**, a Prompt Auditor for production-grade LLM agent systems.
|
||||
|
||||
Your sole objective is to prevent silent, non-deterministic, or cascading failures in prompts that will be executed millions of times daily across heterogeneous models, tool stacks, and sub-agent contexts.
|
||||
|
||||
**Core Principles (required for every finding)**
|
||||
- Every finding must populate all columns of the output table defined in the Strict Output Format section.
|
||||
- Every finding must include: exact quote/location, failure mode ID or "ADV" (adversarial) / "PATH" (path-trace), production-calibrated risk, and a concrete mitigation with positive, deterministic rewritten example.
|
||||
- Assume independent sub-agent contexts, variable context-window pressure, and model variance.
|
||||
|
||||
---
|
||||
|
||||
### Mandatory Review Procedure
|
||||
|
||||
Execute steps in order. Steps 0-1 run sequentially. Steps 2A/2B/2C run in parallel. Steps 3-4 run sequentially after all parallel tracks complete.
|
||||
|
||||
---
|
||||
|
||||
**Step 0: Input Validation**
|
||||
If the input is not a clear LLM instruction prompt (raw code, data table, empty, or fewer than 50 tokens), output exactly:
|
||||
`INPUT_NOT_A_PROMPT: [one-sentence reason]. Review aborted.`
|
||||
and stop.
|
||||
|
||||
**Step 1: Context & Dependency Inventory**
|
||||
Parse the entire prompt. Derive the **Prompt Title** as follows:
|
||||
- First # or ## heading if present, OR
|
||||
- Filename if provided, OR
|
||||
- First complete sentence (truncated to 80 characters).
|
||||
|
||||
Build an explicit inventory table listing:
|
||||
- All numbered/bulleted steps
|
||||
- All variables, placeholders, file references, prior-step outputs
|
||||
- All conditionals, loops, halts, tool calls
|
||||
- All assumptions about persistent memory or ordering
|
||||
|
||||
Flag any unresolved dependencies.
|
||||
Step 1 is complete when the full inventory table is populated.
|
||||
|
||||
This inventory is shared context for all three parallel tracks below.
|
||||
|
||||
---
|
||||
|
||||
### Step 2: Three Parallel Review Tracks
|
||||
|
||||
Launch all three tracks concurrently. Each track produces findings in the same table format. Tracks are independent — no track reads another track's output.
|
||||
|
||||
---
|
||||
|
||||
**Track A: Adversarial Review (sub-agent)**
|
||||
|
||||
Spawn a sub-agent with the following brief and the full prompt text. Give it the Step 1 inventory for reference. Give it NO catalog, NO checklist, and NO further instructions beyond this brief:
|
||||
|
||||
> You are reviewing an LLM prompt that will execute millions of times daily across different models. Find every way this prompt could fail, produce wrong results, or behave inconsistently. For each issue found, provide: exact quote or location, what goes wrong at scale, and a concrete fix. Use only training knowledge — rely on your own judgment, not any external checklist.
|
||||
|
||||
Track A is complete when the sub-agent returns its findings.
|
||||
|
||||
---
|
||||
|
||||
**Track B: Catalog Scan + Execution Simulation (main agent)**
|
||||
|
||||
**B.1 — Failure Mode Audit**
|
||||
Scan the prompt against all 17 failure modes in the catalog below. Quote every relevant instance. For modes with zero findings, list them in a single summary line (e.g., "Modes 3, 7, 10, 12: no instances found").
|
||||
B.1 is complete when every mode has been explicitly checked.
|
||||
|
||||
**B.2 — Execution Simulation**
|
||||
Simulate the prompt under 3 scenarios:
|
||||
- Scenario A: Small-context model (32k window) under load
|
||||
- Scenario B: Large-context model (200k window), fresh session
|
||||
- Scenario C: Different model vendor with weaker instruction-following
|
||||
|
||||
For each scenario, produce one row in this table:
|
||||
|
||||
| Scenario | Likely Failure Location | Failure Mode | Expected Symptom |
|
||||
|----------|-------------------------|--------------|------------------|
|
||||
|
||||
B.2 is complete when the table contains 3 fully populated rows.
|
||||
|
||||
Track B is complete when both B.1 and B.2 are finished.
|
||||
|
||||
---
|
||||
|
||||
**Track C: Prompt Path Tracer (sub-agent)**
|
||||
|
||||
Spawn a sub-agent with the following brief, the full prompt text, and the Step 1 inventory:
|
||||
|
||||
> You are a mechanical path tracer for LLM prompts. Walk every execution path through this prompt — every conditional, branch, loop, halt, optional step, tool call, and error path. For each path, determine: is the entry condition unambiguous? Is there a defined done-state? Are all required inputs guaranteed to be available? Report only paths with gaps — discard clean paths silently.
|
||||
>
|
||||
> For each finding, provide:
|
||||
> - **Location**: step/section reference
|
||||
> - **Path**: the specific conditional or branch
|
||||
> - **Gap**: what is missing (unclear entry, no done-state, unresolved input)
|
||||
> - **Fix**: concrete rewrite that closes the gap
|
||||
|
||||
Track C is complete when the sub-agent returns its findings.
|
||||
|
||||
---
|
||||
|
||||
**Step 3: Merge & Deduplicate**
|
||||
|
||||
Collect all findings from Tracks A, B, and C. Tag each finding with its source (ADV, catalog mode number, or PATH). Deduplicate by exact quote — when multiple tracks flag the same issue, keep the finding with the most specific mitigation and note all sources.
|
||||
|
||||
Assign severity to each finding: Critical / High / Medium / Low.
|
||||
|
||||
Step 3 is complete when the merged, deduplicated, severity-scored findings table is populated.
|
||||
|
||||
**Step 4: Final Synthesis**
|
||||
|
||||
Format the entire review using the Strict Output Format below. Emit the complete review only after Step 3 is finished.
|
||||
|
||||
---
|
||||
|
||||
### Complete Failure Mode Catalog (Track B — scan all 17)
|
||||
|
||||
1. **Silent Ignoring** — Instructions buried mid-paragraph, nested >2-deep conditionals, parentheticals, or "also remember to..." after long text.
|
||||
2. **Ambiguous Completion** — Steps with no observable done-state or verification criterion ("think about it", "finalize").
|
||||
3. **Context Window Assumptions** — References to "previous step output", "the file we created earlier", or variables not re-passed.
|
||||
4. **Over-specification vs Under-specification** — Wall-of-text detail causing selective attention OR vague verbs inviting hallucination.
|
||||
5. **Non-deterministic Phrasing** — "Consider", "you may", "if appropriate", "best way", "optionally", "try to".
|
||||
6. **Negation Fragility** — "Do NOT", "avoid", "never" (especially multiple or under load).
|
||||
7. **Implicit Ordering** — Step B assumes Step A completed without explicit sequencing or guardrails.
|
||||
8. **Variable Resolution Gaps** — `{{VAR}}` or "the result from tool X" never initialized upstream.
|
||||
9. **Scope Creep Invitation** — "Explore", "improve", "make it better", open-ended goals without hard boundaries.
|
||||
10. **Halt / Checkpoint Gaps** — Human-in-loop required but no explicit `STOP_AND_WAIT_FOR_HUMAN` or output format that forces pause.
|
||||
11. **Teaching Known Knowledge** — Re-explaining basic facts, tool usage, or reasoning patterns frontier models already know (2026 cutoff).
|
||||
12. **Obsolete Prompting Techniques** — Outdated patterns (vanilla "think step by step" without modern scaffolding, deprecated few-shot styles).
|
||||
13. **Missing Strict Output Schema** — No enforced JSON mode or structured output format.
|
||||
14. **Missing Error Handling** — No recovery instructions for tool failures, timeouts, or malformed inputs.
|
||||
15. **Missing Success Criteria** — No quality gates or measurable completion standards.
|
||||
16. **Monolithic Prompt Anti-pattern** — Single large prompt that should be split into specialized sub-agents.
|
||||
17. **Missing Grounding Instructions** — Factual claims required without explicit requirement to base them on retrieved evidence.
|
||||
|
||||
---
|
||||
|
||||
### Strict Output Format (use this template exactly as shown)
|
||||
|
||||
```markdown
|
||||
# PromptSentinel Review: [Derived Prompt Title]
|
||||
|
||||
**Overall Risk Level:** Critical / High / Medium / Low
|
||||
**Critical Issues:** X | **High:** Y | **Medium:** Z | **Low:** W
|
||||
**Estimated Production Failure Rate if Unfixed:** ~XX% of runs
|
||||
|
||||
## Critical & High Findings
|
||||
| # | Source | Failure Mode | Exact Quote / Location | Risk (High-Volume) | Mitigation & Rewritten Example |
|
||||
|---|--------|--------------|------------------------|--------------------|-------------------------------|
|
||||
| | | | | | |
|
||||
|
||||
## Medium & Low Findings
|
||||
(same table format)
|
||||
|
||||
## Positive Observations
|
||||
(only practices that actively mitigate known failure modes)
|
||||
|
||||
## Recommended Refactor Summary
|
||||
- Highest-leverage changes (bullets)
|
||||
|
||||
## Revised Prompt Sections (Critical/High items only)
|
||||
Provide full rewritten paragraphs/sections with changes clearly marked.
|
||||
|
||||
**Reviewer Confidence:** XX/100
|
||||
**Review Complete** – ready for re-submission or automated patching.
|
||||
```
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
---
|
||||
name: bmad-os-root-cause-analysis
|
||||
description: Analyzes a bug-fix commit or PR and produces a structured Root Cause Analysis report covering what went wrong, why, and what guardrails failed.
|
||||
license: MIT
|
||||
disable-model-invocation: true
|
||||
metadata:
|
||||
author: bmad-code-org
|
||||
version: "1.0.0"
|
||||
compatibility: Requires gh CLI and git repository
|
||||
---
|
||||
|
||||
Read `prompts/instructions.md` and execute.
|
||||
|
|
@ -1,74 +0,0 @@
|
|||
# Bug-Fix Root Cause Analysis
|
||||
|
||||
Analyze a bug-fix commit or PR and produce a structured Root Cause Analysis report.
|
||||
|
||||
## Principles
|
||||
|
||||
- **Direct attribution.** This report names the individual who introduced the defect. Industry convention advocates blameless postmortems. This skill deliberately deviates: naming the individual and trusting them to own it is more respectful than diffusing accountability into systemic abstraction. Direct, factual, not accusatory. If authorship can't be determined confidently, say so.
|
||||
- **Pyramid communication.** The executive summary must convey the full picture. A reader who stops after the first paragraph gets the gist. Everything else is supporting evidence.
|
||||
|
||||
## Preflight
|
||||
|
||||
Verify `gh auth status` and that you're in a git repository. Stop with a clear message if either fails.
|
||||
|
||||
## Execution
|
||||
|
||||
1. **Identify the fix.** Accept whatever the user provides — commit SHA, PR, issue, description. Resolve to the specific fix commit/PR using `gh` and `git`. If ambiguous, ask. Confirm the change is actually a bug fix before proceeding.
|
||||
2. **Gather evidence.** Read the fix diff, PR/issue discussion, and use blame/log to identify the commit that introduced the bug. Collect timeline data.
|
||||
3. **Analyze.** Apply 5 Whys. Classify the root cause. Identify contributing factors.
|
||||
4. **Evaluate guardrails.** Inspect the actual repo configuration (CI workflows, linter configs, test setup) — don't assume. For each applicable guardrail, explain specifically why it missed this bug.
|
||||
5. **Write the report** to `_bmad-output/rca-reports/rca-{YYYY-MM-DD}-{slug}.md`. Present the executive summary in chat.
|
||||
|
||||
## Report Structure
|
||||
|
||||
```markdown
|
||||
# Root Cause Analysis: {Bug Title}
|
||||
|
||||
**Date:** {today}
|
||||
**Fix:** {PR link or commit SHA}
|
||||
**Severity:** {Critical | High | Medium | Low}
|
||||
**Root Cause Category:** {Requirements | Design | Code Logic | Test Gap | Process | Environment/Config}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{One paragraph. What the bug was, root cause, who introduced it and when, detection
|
||||
latency (introduced → detected), severity, and the key preventive recommendation.}
|
||||
|
||||
## What Was the Problem?
|
||||
|
||||
## When Did It Happen?
|
||||
|
||||
| Event | Date | Reference |
|
||||
|-------|------|-----------|
|
||||
| Introduced | | |
|
||||
| Detected | | |
|
||||
| Fixed | | |
|
||||
| **Detection Latency** | **{introduced → detected}** | |
|
||||
|
||||
## Who Caused It?
|
||||
|
||||
{Author, commit/PR that introduced the defect, and the context — what were they
|
||||
trying to do?}
|
||||
|
||||
## How Did It Happen?
|
||||
|
||||
## Why Did It Happen?
|
||||
|
||||
{5 Whys analysis. Root cause category. Contributing factors.}
|
||||
|
||||
## Failed Guardrails Analysis
|
||||
|
||||
| Guardrail | In Place? | Why It Failed |
|
||||
|-----------|-----------|---------------|
|
||||
| | | |
|
||||
|
||||
**Most Critical Failure:** {Which one mattered most and why.}
|
||||
|
||||
## Resolution
|
||||
|
||||
## Corrective & Preventive Actions
|
||||
|
||||
| # | Action | Type | Priority |
|
||||
|---|--------|------|----------|
|
||||
| | | {Prevent/Detect/Mitigate} | |
|
||||
```
|
||||
|
|
@ -0,0 +1,133 @@
|
|||
name: Publish
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [main]
|
||||
paths:
|
||||
- "src/**"
|
||||
- "tools/cli/**"
|
||||
- "package.json"
|
||||
workflow_dispatch:
|
||||
inputs:
|
||||
channel:
|
||||
description: "Publish channel"
|
||||
required: true
|
||||
default: "latest"
|
||||
type: choice
|
||||
options:
|
||||
- latest
|
||||
- next
|
||||
bump:
|
||||
description: "Version bump type (latest channel only)"
|
||||
required: false
|
||||
default: "patch"
|
||||
type: choice
|
||||
options:
|
||||
- patch
|
||||
- minor
|
||||
- major
|
||||
|
||||
concurrency:
|
||||
group: publish
|
||||
cancel-in-progress: ${{ github.event_name == 'push' }}
|
||||
|
||||
permissions:
|
||||
id-token: write
|
||||
contents: write
|
||||
|
||||
jobs:
|
||||
publish:
|
||||
if: github.event_name != 'workflow_dispatch' || github.ref == 'refs/heads/main'
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0
|
||||
token: ${{ secrets.GITHUB_TOKEN }}
|
||||
|
||||
- name: Setup Node
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version-file: ".nvmrc"
|
||||
cache: "npm"
|
||||
|
||||
- name: Ensure trusted publishing toolchain
|
||||
run: |
|
||||
# npm trusted publishing requires Node >= 22.14.0 and npm >= 11.5.1.
|
||||
npm install --global npm@11.6.2
|
||||
|
||||
- name: Configure git user
|
||||
if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
|
||||
run: |
|
||||
git config user.name "github-actions[bot]"
|
||||
git config user.email "github-actions[bot]@users.noreply.github.com"
|
||||
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Run tests
|
||||
run: npm test
|
||||
|
||||
- name: Derive next prerelease version
|
||||
if: github.event_name == 'push' || (github.event_name == 'workflow_dispatch' && inputs.channel == 'next')
|
||||
run: |
|
||||
NEXT_VER=$(npm view bmad-method@next version 2>/dev/null || echo "")
|
||||
LATEST_VER=$(npm view bmad-method@latest version 2>/dev/null || echo "")
|
||||
|
||||
# Determine the best base version for the next prerelease.
|
||||
BASE=$(node -e "
|
||||
const semver = require('semver');
|
||||
const next = process.argv[1] || null;
|
||||
const latest = process.argv[2] || null;
|
||||
if (!next && !latest) process.exit(0);
|
||||
if (!next) { console.log(latest); process.exit(0); }
|
||||
if (!latest) { console.log(next); process.exit(0); }
|
||||
const nextBase = next.replace(/-next\.\d+$/, '');
|
||||
console.log(semver.gt(latest, nextBase) ? latest : next);
|
||||
" "$NEXT_VER" "$LATEST_VER")
|
||||
|
||||
if [ -n "$BASE" ]; then
|
||||
npm version "$BASE" --no-git-tag-version --allow-same-version
|
||||
fi
|
||||
npm version prerelease --preid=next --no-git-tag-version
|
||||
|
||||
- name: Bump stable version
|
||||
if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
|
||||
run: 'npm version ${{ inputs.bump }} -m "chore(release): v%s [skip ci]"'
|
||||
|
||||
- name: Publish prerelease to npm
|
||||
if: github.event_name == 'push' || (github.event_name == 'workflow_dispatch' && inputs.channel == 'next')
|
||||
run: npm publish --tag next --provenance
|
||||
|
||||
- name: Publish stable release to npm
|
||||
if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
|
||||
run: npm publish --tag latest --provenance
|
||||
|
||||
- name: Push version commit and tag
|
||||
if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
|
||||
run: git push origin main --follow-tags
|
||||
|
||||
- name: Create GitHub Release
|
||||
if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
|
||||
run: |
|
||||
TAG="v$(node -p 'require("./package.json").version')"
|
||||
gh release create "$TAG" --generate-notes
|
||||
env:
|
||||
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
|
||||
- name: Notify Discord
|
||||
if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
|
||||
continue-on-error: true
|
||||
run: |
|
||||
set -o pipefail
|
||||
source .github/scripts/discord-helpers.sh
|
||||
[ -z "$WEBHOOK" ] && exit 0
|
||||
|
||||
VERSION=$(node -p 'require("./package.json").version')
|
||||
RELEASE_URL="${{ github.server_url }}/${{ github.repository }}/releases/tag/v${VERSION}"
|
||||
MSG=$(printf '📦 **[bmad-method v%s released](<%s>)**' "$VERSION" "$RELEASE_URL" | esc)
|
||||
|
||||
jq -n --arg content "$MSG" '{content: $content}' | curl -sf --retry 2 -X POST "$WEBHOOK" -H "Content-Type: application/json" -d @-
|
||||
env:
|
||||
WEBHOOK: ${{ secrets.DISCORD_WEBHOOK }}
|
||||
|
|
@ -7,6 +7,7 @@ name: Quality & Validation
|
|||
# - Schema validation (YAML structure)
|
||||
# - Agent schema tests (fixture-based validation)
|
||||
# - Installation component tests (compilation)
|
||||
# - fs wrapper tests (native fs replacement)
|
||||
# - Bundle validation (web bundle integrity)
|
||||
|
||||
"on":
|
||||
|
|
@ -112,5 +113,8 @@ jobs:
|
|||
- name: Test agent compilation components
|
||||
run: npm run test:install
|
||||
|
||||
- name: Test fs wrapper
|
||||
run: npm run test:fs
|
||||
|
||||
- name: Validate file references
|
||||
run: npm run validate:refs
|
||||
|
|
|
|||
|
|
@ -40,6 +40,7 @@ CLAUDE.local.md
|
|||
.agents/
|
||||
|
||||
z*/
|
||||
!docs/zh-cn/
|
||||
|
||||
_bmad
|
||||
_bmad-output
|
||||
|
|
@ -55,7 +56,7 @@ _bmad-output
|
|||
.qwen
|
||||
.rovodev
|
||||
.kilocodemodes
|
||||
.claude/commands
|
||||
.claude
|
||||
.codex
|
||||
.github/chatmodes
|
||||
.github/agents
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@
|
|||
* Add CodeBuddy platform support with installer configuration (#1483)
|
||||
* Add LLM audit prompt for file reference conventions - new audit tool using parallel subagents (#1720)
|
||||
* Migrate Codex installer from `.codex/prompts` to `.agents/skills` format to align with Codex CLI changes (#1729)
|
||||
* Convert review-pr and audit-file-refs tools to proper bmad-os skills with slash commands `/bmad-os-review-pr` and `/bmad-os-audit-file-refs` (#1732)
|
||||
* Convert review-pr and audit-file-refs tools to proper bmad-os skills with slash commands `bmad-os-review-pr` and `bmad-os-audit-file-refs` (#1732)
|
||||
|
||||
### 🐛 Bug Fixes
|
||||
|
||||
|
|
@ -365,7 +365,7 @@ V6 Stable Release! The End of Beta!
|
|||
- TEA documentation restructured using Diátaxis framework (25 docs)
|
||||
- Style guide optimized for LLM readers (367 lines, down from 767)
|
||||
- Glossary rewritten using table format (123 lines, down from 373)
|
||||
- README overhaul with numbered command flows and prominent `/bmad-help` callout
|
||||
- README overhaul with numbered command flows and prominent `bmad-help` callout
|
||||
- New workflow map diagram with interactive HTML
|
||||
- New editorial review tasks for document quality
|
||||
- E2E testing methodology for Game Dev Studio
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ After searching, use the [feature request template](https://github.com/bmad-code
|
|||
|
||||
### Target Branch
|
||||
|
||||
Submit PRs to the `main` branch. We use [trunk-based development](https://trunkbaseddevelopment.com/branch-for-release/): `main` is the trunk where all work lands, and stable release branches receive only cherry-picked fixes.
|
||||
Submit PRs to the `main` branch. We use trunk-based development. Every push to `main` auto-publishes to `npm` under the `next` tag. Stable releases are cut ~weekly to the `latest` tag.
|
||||
|
||||
### PR Size
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@
|
|||
|
||||
Traditional AI tools do the thinking for you, producing average results. BMad agents and facilitated workflows act as expert collaborators who guide you through a structured process to bring out your best thinking in partnership with the AI.
|
||||
|
||||
- **AI Intelligent Help** — Ask `/bmad-help` anytime for guidance on what's next
|
||||
- **AI Intelligent Help** — Invoke the `bmad-help` skill anytime for guidance on what's next
|
||||
- **Scale-Domain-Adaptive** — Automatically adjusts planning depth based on project complexity
|
||||
- **Structured Workflows** — Grounded in agile best practices across analysis, planning, architecture, and implementation
|
||||
- **Specialized Agents** — 12+ domain experts (PM, Architect, Developer, UX, Scrum Master, and more)
|
||||
|
|
@ -40,7 +40,7 @@ Traditional AI tools do the thinking for you, producing average results. BMad ag
|
|||
npx bmad-method install
|
||||
```
|
||||
|
||||
> If you are getting a stale beta version, use: `npx bmad-method@6.0.1 install`
|
||||
> Want the newest prerelease build? Use `npx bmad-method@next install`. Expect higher churn than the default install.
|
||||
|
||||
Follow the installer prompts, then open your AI IDE (Claude Code, Cursor, etc.) in your project folder.
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ npx bmad-method install --directory /path/to/project --modules bmm --tools claud
|
|||
|
||||
[See all installation options](https://docs.bmad-method.org/how-to/non-interactive-installation/)
|
||||
|
||||
> **Not sure what to do?** Run `/bmad-help` — it tells you exactly what's next and what's optional. You can also ask questions like `/bmad-help I just finished the architecture, what do I do next?`
|
||||
> **Not sure what to do?** Ask `bmad-help` — it tells you exactly what's next and what's optional. You can also ask questions like `bmad-help I just finished the architecture, what do I do next?`
|
||||
|
||||
## Modules
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@
|
|||
|
||||
传统 AI 工具替你思考,产生平庸的结果。BMad 智能体和辅助工作流充当专家协作者,引导你通过结构化流程,与 AI 的合作发挥最佳思维,产出最有效优秀的结果。
|
||||
|
||||
- **AI 智能帮助** — 随时使用 `/bmad-help` 获取下一步指导
|
||||
- **AI 智能帮助** — 随时使用 `bmad-help` 获取下一步指导
|
||||
- **规模-领域自适应** — 根据项目复杂度自动调整规划深度
|
||||
- **结构化工作流** — 基于分析、规划、架构和实施的敏捷最佳实践
|
||||
- **专业智能体** — 12+ 领域专家(PM、架构师、开发者、UX、Scrum Master 等)
|
||||
|
|
@ -52,7 +52,7 @@ npx bmad-method install --directory /path/to/project --modules bmm --tools claud
|
|||
|
||||
[查看所有安装选项](http://docs.bmad-method.org/how-to/non-interactive-installation/)
|
||||
|
||||
> **不确定该做什么?** 运行 `/bmad-help` — 它会准确告诉你下一步做什么以及什么是可选的。你也可以问诸如 `/bmad-help 我刚刚完成了架构设计,接下来该做什么?` 之类的问题。
|
||||
> **不确定该做什么?** 运行 `bmad-help` — 它会准确告诉你下一步做什么以及什么是可选的。你也可以问诸如 `bmad-help 我刚刚完成了架构设计,接下来该做什么?` 之类的问题。
|
||||
|
||||
## 模块
|
||||
|
||||
|
|
|
|||
|
|
@ -59,13 +59,13 @@ Critical warnings only — data loss, security issues
|
|||
| 2 | Planning | Requirements — PRD or tech-spec *(required)* |
|
||||
```
|
||||
|
||||
**Commands:**
|
||||
**Skills:**
|
||||
|
||||
```md
|
||||
| Command | Agent | Purpose |
|
||||
| Skill | Agent | Purpose |
|
||||
| ------------ | ------- | ------------------------------------ |
|
||||
| `brainstorm` | Analyst | Brainstorm a new project |
|
||||
| `prd` | PM | Create Product Requirements Document |
|
||||
| `bmad-brainstorming` | Analyst | Brainstorm a new project |
|
||||
| `bmad-create-prd` | PM | Create Product Requirements Document |
|
||||
```
|
||||
|
||||
## Folder Structure Blocks
|
||||
|
|
@ -99,7 +99,7 @@ your-project/
|
|||
9. Step 2: [Second Major Task]
|
||||
10. Step 3: [Third Major Task]
|
||||
11. What You've Accomplished (summary + folder structure)
|
||||
12. Quick Reference (commands table)
|
||||
12. Quick Reference (skills table)
|
||||
13. Common Questions (FAQ format)
|
||||
14. Getting Help (community links)
|
||||
15. Key Takeaways (tip admonition)
|
||||
|
|
@ -111,7 +111,7 @@ your-project/
|
|||
- [ ] "What You'll Learn" section present
|
||||
- [ ] Prerequisites in admonition
|
||||
- [ ] Quick Path TL;DR admonition at top
|
||||
- [ ] Tables for phases, commands, agents
|
||||
- [ ] Tables for phases, skills, agents
|
||||
- [ ] "What You've Accomplished" section present
|
||||
- [ ] Quick Reference table present
|
||||
- [ ] Common Questions section present
|
||||
|
|
@ -243,7 +243,7 @@ your-project/
|
|||
1. Title + Hook
|
||||
2. Items (## for each item)
|
||||
- Brief description (one sentence)
|
||||
- **Commands:** or **Key Info:** as flat list
|
||||
- **Skills:** or **Key Info:** as flat list
|
||||
3. Universal/Shared (## section) (optional)
|
||||
```
|
||||
|
||||
|
|
@ -252,7 +252,7 @@ your-project/
|
|||
```text
|
||||
1. Title + Hook (one sentence purpose)
|
||||
2. Quick Facts (optional note admonition)
|
||||
- Module, Command, Input, Output as list
|
||||
- Module, Skill, Input, Output as list
|
||||
3. Purpose/Overview (## section)
|
||||
4. How to Invoke (code block)
|
||||
5. Key Sections (## for each aspect)
|
||||
|
|
@ -280,7 +280,7 @@ your-project/
|
|||
- Diagram or table showing organization
|
||||
3. Major Sections (## for each phase/category)
|
||||
- Items (### for each item)
|
||||
- Standardized fields: Command, Agent, Input, Output, Description
|
||||
- Standardized fields: Skill, Agent, Input, Output, Description
|
||||
4. Next Steps (optional)
|
||||
```
|
||||
|
||||
|
|
@ -353,7 +353,7 @@ Only for BMad Method and Enterprise tracks. Quick Flow skips to implementation.
|
|||
|
||||
### Can I change my plan later?
|
||||
|
||||
Yes. The SM agent has a `correct-course` workflow for handling scope changes.
|
||||
Yes. The SM agent has a `bmad-correct-course` workflow for handling scope changes.
|
||||
|
||||
**Have a question not answered here?** [Open an issue](...) or ask in [Discord](...).
|
||||
```
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Unlock your creativity through guided exploration.
|
|||
|
||||
## What is Brainstorming?
|
||||
|
||||
Run `brainstorming` and you've got a creative facilitator pulling ideas out of you - not generating them for you. The AI acts as coach and guide, using proven techniques to create conditions where your best thinking emerges.
|
||||
Run `bmad-brainstorming` and you've got a creative facilitator pulling ideas out of you - not generating them for you. The AI acts as coach and guide, using proven techniques to create conditions where your best thinking emerges.
|
||||
|
||||
**Good for:**
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Get all your AI agents in one conversation.
|
|||
|
||||
## What is Party Mode?
|
||||
|
||||
Run `party-mode` and you've got your whole AI team in one room - PM, Architect, Dev, UX Designer, whoever you need. BMad Master orchestrates, picking relevant agents per message. Agents respond in character, agree, disagree, and build on each other's ideas.
|
||||
Run `bmad-party-mode` and you've got your whole AI team in one room - PM, Architect, Dev, UX Designer, whoever you need. BMad Master orchestrates, picking relevant agents per message. Agents respond in character, agree, disagree, and build on each other's ideas.
|
||||
|
||||
The conversation continues as long as you want. Ask follow-ups, push back on answers, redirect the discussion - it's a real back-and-forth with your agents until you're done.
|
||||
|
||||
|
|
|
|||
|
|
@ -108,5 +108,5 @@ Common decisions that prevent conflicts:
|
|||
- Document decisions that cross epic boundaries
|
||||
- Focus on conflict-prone areas
|
||||
- Update architecture as you learn
|
||||
- Use `correct-course` for significant changes
|
||||
- Use `bmad-correct-course` for significant changes
|
||||
:::
|
||||
|
|
|
|||
|
|
@ -21,12 +21,12 @@ The `project-context.md` file solves this by documenting what agents need to kno
|
|||
Every implementation workflow automatically loads `project-context.md` if it exists. The architect workflow also loads it to respect your technical preferences when designing the architecture.
|
||||
|
||||
**Loaded by these workflows:**
|
||||
- `create-architecture` — respects technical preferences during solutioning
|
||||
- `create-story` — informs story creation with project patterns
|
||||
- `dev-story` — guides implementation decisions
|
||||
- `code-review` — validates against project standards
|
||||
- `quick-dev` — applies patterns when implementing tech-specs
|
||||
- `sprint-planning`, `retrospective`, `correct-course` — provides project-wide context
|
||||
- `bmad-create-architecture` — respects technical preferences during solutioning
|
||||
- `bmad-create-story` — informs story creation with project patterns
|
||||
- `bmad-dev-story` — guides implementation decisions
|
||||
- `bmad-code-review` — validates against project standards
|
||||
- `bmad-quick-dev` — applies patterns when implementing tech-specs
|
||||
- `bmad-sprint-planning`, `bmad-retrospective`, `bmad-correct-course` — provides project-wide context
|
||||
|
||||
## When to Create It
|
||||
|
||||
|
|
@ -34,10 +34,10 @@ The `project-context.md` file is useful at any stage of a project:
|
|||
|
||||
| Scenario | When to Create | Purpose |
|
||||
|----------|----------------|---------|
|
||||
| **New project, before architecture** | Manually, before `create-architecture` | Document your technical preferences so the architect respects them |
|
||||
| **New project, after architecture** | Via `generate-project-context` or manually | Capture architecture decisions for implementation agents |
|
||||
| **Existing project** | Via `generate-project-context` | Discover existing patterns so agents follow established conventions |
|
||||
| **Quick Flow project** | Before or during `quick-dev` | Ensure quick implementation respects your patterns |
|
||||
| **New project, before architecture** | Manually, before `bmad-create-architecture` | Document your technical preferences so the architect respects them |
|
||||
| **New project, after architecture** | Via `bmad-generate-project-context` or manually | Capture architecture decisions for implementation agents |
|
||||
| **Existing project** | Via `bmad-generate-project-context` | Discover existing patterns so agents follow established conventions |
|
||||
| **Quick Flow project** | Before or during `bmad-quick-dev` | Ensure quick implementation respects your patterns |
|
||||
|
||||
:::tip[Recommended]
|
||||
For new projects, create it manually before architecture if you have strong technical preferences. Otherwise, generate it after architecture to capture those decisions.
|
||||
|
|
@ -107,20 +107,20 @@ Edit it with your technology stack and implementation rules. The architect and i
|
|||
|
||||
### Generate After Architecture
|
||||
|
||||
Run the `generate-project-context` workflow after completing your architecture:
|
||||
Run the `bmad-generate-project-context` workflow after completing your architecture:
|
||||
|
||||
```bash
|
||||
/bmad-bmm-generate-project-context
|
||||
bmad-generate-project-context
|
||||
```
|
||||
|
||||
This scans your architecture document and project files to generate a context file capturing the decisions made.
|
||||
|
||||
### Generate for Existing Projects
|
||||
|
||||
For existing projects, run `generate-project-context` to discover existing patterns:
|
||||
For existing projects, run `bmad-generate-project-context` to discover existing patterns:
|
||||
|
||||
```bash
|
||||
/bmad-bmm-generate-project-context
|
||||
bmad-generate-project-context
|
||||
```
|
||||
|
||||
The workflow analyzes your codebase to identify conventions, then generates a context file you can review and refine.
|
||||
|
|
@ -150,7 +150,7 @@ The `project-context.md` file is a living document. Update it when:
|
|||
- Patterns evolve during implementation
|
||||
- You identify gaps from agent behavior
|
||||
|
||||
You can edit it manually at any time, or re-run `generate-project-context` to update it after significant changes.
|
||||
You can edit it manually at any time, or re-run `bmad-generate-project-context` to update it after significant changes.
|
||||
|
||||
:::note[File Location]
|
||||
The default location is `_bmad-output/project-context.md`. Workflows search for it there, and also check `**/project-context.md` anywhere in your project.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,73 @@
|
|||
---
|
||||
title: "Quick Dev New Preview"
|
||||
description: Reduce human-in-the-loop friction without giving up the checkpoints that protect output quality
|
||||
sidebar:
|
||||
order: 2
|
||||
---
|
||||
|
||||
`bmad-quick-dev-new-preview` is an experimental attempt to radically improve Quick Flow: intent in, code changes out, with lower ceremony and fewer human-in-the-loop turns without sacrificing quality.
|
||||
|
||||
It lets the model run longer between checkpoints, then brings the human back only when the task cannot safely continue without human judgment or when it is time to review the end result.
|
||||
|
||||

|
||||
|
||||
## Why This Exists
|
||||
|
||||
Human-in-the-loop turns are necessary and expensive.
|
||||
|
||||
Current LLMs still fail in predictable ways: they misread intent, fill gaps with confident guesses, drift into unrelated work, and generate noisy review output. At the same time, constant human intervention limits development velocity. Human attention is the bottleneck.
|
||||
|
||||
This experimental version of Quick Flow is an attempt to rebalance that tradeoff. It trusts the model to run unsupervised for longer stretches, but only after the workflow has created a strong enough boundary to make that safe.
|
||||
|
||||
## The Core Design
|
||||
|
||||
### 1. Compress intent first
|
||||
|
||||
The workflow starts by having the human and the model compress the request into one coherent goal. The input can begin as a rough expression of intent, but before the workflow runs autonomously it has to become small enough, clear enough, and contradiction-free enough to execute.
|
||||
|
||||
Intent can come in many forms: a couple of phrases, a bug tracker link, output from plan mode, text copied from a chat session, or even a story number from BMAD's own `epics.md`. In that last case, the workflow will not understand BMAD story-tracking semantics, but it can still take the story itself and run with it.
|
||||
|
||||
This workflow does not eliminate human control. It relocates it to a small number of high-value moments:
|
||||
|
||||
- **Intent clarification** - turning a messy request into one coherent goal without hidden contradictions
|
||||
- **Spec approval** - confirming that the frozen understanding is the right thing to build
|
||||
- **Review of the final product** - the primary checkpoint, where the human decides whether the result is acceptable at the end
|
||||
|
||||
### 2. Route to the smallest safe path
|
||||
|
||||
Once the goal is clear, the workflow decides whether this is a true one-shot change or whether it needs the fuller path. Small, zero-blast-radius changes can go straight to implementation. Everything else goes through planning so the model has a stronger boundary before it runs longer on its own.
|
||||
|
||||
### 3. Run longer with less supervision
|
||||
|
||||
After that routing decision, the model can carry more of the work on its own. On the fuller path, the approved spec becomes the boundary the model executes against with less supervision, which is the whole point of the experiment.
|
||||
|
||||
### 4. Diagnose failure at the right layer
|
||||
|
||||
If the implementation is wrong because the intent was wrong, patching the code is the wrong fix. If the code is wrong because the spec was weak, patching the diff is also the wrong fix. The workflow is designed to diagnose where the failure entered the system, go back to that layer, and regenerate from there.
|
||||
|
||||
Review findings are used to decide whether the problem came from intent, spec generation, or local implementation. Only truly local problems get patched locally.
|
||||
|
||||
### 5. Bring the human back only when needed
|
||||
|
||||
The intent interview is human-in-the-loop, but it is not the same kind of interruption as a recurring checkpoint. The workflow tries to keep those recurring checkpoints to a minimum. After the initial shaping of intent, the human mainly comes back when the workflow cannot safely continue without judgment and at the end, when it is time to review the result.
|
||||
|
||||
- **Intent-gap resolution** - stepping back in when review proves the workflow could not safely infer what was meant
|
||||
|
||||
Everything else is a candidate for longer autonomous execution. That tradeoff is deliberate. Older patterns spend more human attention on continuous supervision. Quick Dev New Preview spends more trust on the model, but saves human attention for the moments where human reasoning has the highest leverage.
|
||||
|
||||
## Why the Review System Matters
|
||||
|
||||
The review phase is not just there to find bugs. It is there to route correction without destroying momentum.
|
||||
|
||||
This workflow works best on a platform that can spawn subagents, or at least invoke another LLM through the command line and wait for a result. If your platform does not support that natively, you can add a skill to do it. Context-free subagents are a cornerstone of the review design.
|
||||
|
||||
Agentic reviews often go wrong in two ways:
|
||||
|
||||
- They generate too many findings, forcing the human to sift through noise.
|
||||
- They derail the current change by surfacing unrelated issues and turning every run into an ad hoc cleanup project.
|
||||
|
||||
Quick Dev New Preview addresses both by treating review as triage.
|
||||
|
||||
Some findings belong to the current change. Some do not. If a finding is incidental rather than causally tied to the current work, the workflow can defer it instead of forcing the human to handle it immediately. That keeps the run focused and prevents random tangents from consuming the budget of attention.
|
||||
|
||||
That triage will sometimes be imperfect. That is acceptable. It is usually better to misjudge some findings than to flood the human with thousands of low-value review comments. The system is optimizing for signal quality, not exhaustive recall.
|
||||
|
|
@ -5,7 +5,11 @@ sidebar:
|
|||
order: 1
|
||||
---
|
||||
|
||||
Skip the ceremony. Quick Flow takes you from idea to working code in two commands - no Product Brief, no PRD, no Architecture doc.
|
||||
Skip the ceremony. Quick Flow takes you from idea to working code in two skills - no Product Brief, no PRD, no Architecture doc.
|
||||
|
||||
:::tip[Want a Unified Variant?]
|
||||
If you want one workflow to clarify, plan, implement, review, and present in a single run, see [Quick Dev New Preview](./quick-dev-new-preview.md).
|
||||
:::
|
||||
|
||||
## When to Use It
|
||||
|
||||
|
|
@ -23,16 +27,16 @@ Skip the ceremony. Quick Flow takes you from idea to working code in two command
|
|||
- Anything where requirements are unclear or contested
|
||||
|
||||
:::caution[Scope Creep]
|
||||
If you start a Quick Flow and realize the scope is bigger than expected, `quick-dev` will detect this and offer to escalate. You can switch to a full PRD workflow at any point without losing your work.
|
||||
If you start a Quick Flow and realize the scope is bigger than expected, `bmad-quick-dev` will detect this and offer to escalate. You can switch to a full PRD workflow at any point without losing your work.
|
||||
:::
|
||||
|
||||
## How It Works
|
||||
|
||||
Quick Flow has two commands, each backed by a structured workflow. You can run them together or independently.
|
||||
Quick Flow has two skills, each backed by a structured workflow. You can run them together or independently.
|
||||
|
||||
### quick-spec: Plan
|
||||
|
||||
Run `quick-spec` and Barry (the Quick Flow agent) walks you through a conversational discovery process:
|
||||
Run `bmad-quick-spec` and Barry (the Quick Flow agent) walks you through a conversational discovery process:
|
||||
|
||||
1. **Understand** - You describe what you want to build. Barry scans the codebase to ask informed questions, then captures a problem statement, solution approach, and scope boundaries.
|
||||
2. **Investigate** - Barry reads relevant files, maps code patterns, identifies files to modify, and documents the technical context.
|
||||
|
|
@ -43,15 +47,15 @@ The output is a `tech-spec-{slug}.md` file saved to your project's implementatio
|
|||
|
||||
### quick-dev: Build
|
||||
|
||||
Run `quick-dev` and Barry implements the work. It operates in two modes:
|
||||
Run `bmad-quick-dev` and Barry implements the work. It operates in two modes:
|
||||
|
||||
- **Tech-spec mode** - Point it at a spec file (`quick-dev tech-spec-auth.md`) and it executes every task in order, writes tests, and verifies acceptance criteria.
|
||||
- **Direct mode** - Give it instructions directly (`quick-dev "refactor the auth middleware"`) and it gathers context, builds a mental plan, and executes.
|
||||
|
||||
After implementation, `quick-dev` runs a self-check audit against all tasks and acceptance criteria, then triggers an adversarial code review of the diff. Findings are presented for you to resolve before wrapping up.
|
||||
After implementation, `bmad-quick-dev` runs a self-check audit against all tasks and acceptance criteria, then triggers an adversarial code review of the diff. Findings are presented for you to resolve before wrapping up.
|
||||
|
||||
:::tip[Fresh Context]
|
||||
For best results, run `quick-dev` in a new conversation after finishing `quick-spec`. This gives the implementation agent clean context focused solely on building.
|
||||
For best results, run `bmad-quick-dev` in a new conversation after finishing `bmad-quick-spec`. This gives the implementation agent clean context focused solely on building.
|
||||
:::
|
||||
|
||||
## What Quick Flow Skips
|
||||
|
|
@ -65,9 +69,9 @@ The full BMad Method produces a Product Brief, PRD, Architecture doc, and Epic/S
|
|||
|
||||
## Escalating to Full BMad Method
|
||||
|
||||
Quick Flow includes built-in guardrails for scope detection. When you run `quick-dev` with a direct request, it evaluates signals like multi-component mentions, system-level language, and uncertainty about approach. If it detects the work is bigger than a quick flow:
|
||||
Quick Flow includes built-in guardrails for scope detection. When you run `bmad-quick-dev` with a direct request, it evaluates signals like multi-component mentions, system-level language, and uncertainty about approach. If it detects the work is bigger than a quick flow:
|
||||
|
||||
- **Light escalation** - Recommends running `quick-spec` first to create a plan
|
||||
- **Light escalation** - Recommends running `bmad-quick-spec` first to create a plan
|
||||
- **Heavy escalation** - Recommends switching to the full BMad Method PRD process
|
||||
|
||||
You can also escalate manually at any time. Your tech-spec work carries forward - it becomes input for the broader planning process rather than being discarded.
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Generate `project-context.md` to capture your existing codebase patterns and con
|
|||
Run the generate project context workflow:
|
||||
|
||||
```bash
|
||||
/bmad-bmm-generate-project-context
|
||||
bmad-generate-project-context
|
||||
```
|
||||
|
||||
This scans your codebase to identify:
|
||||
|
|
@ -55,22 +55,22 @@ Your `docs/` folder should contain succinct, well-organized documentation that a
|
|||
- Architecture
|
||||
- Any other relevant project information
|
||||
|
||||
For complex projects, consider using the `document-project` workflow. It offers runtime variants that will scan your entire project and document its actual current state.
|
||||
For complex projects, consider using the `bmad-document-project` workflow. It offers runtime variants that will scan your entire project and document its actual current state.
|
||||
|
||||
## Step 3: Get Help
|
||||
|
||||
### BMad-Help: Your Starting Point
|
||||
|
||||
**Run `/bmad-help` anytime you're unsure what to do next.** This intelligent guide:
|
||||
**Run `bmad-help` anytime you're unsure what to do next.** This intelligent guide:
|
||||
|
||||
- Inspects your project to see what's already been done
|
||||
- Shows options based on your installed modules
|
||||
- Understands natural language queries
|
||||
|
||||
```
|
||||
/bmad-help I have an existing Rails app, where should I start?
|
||||
/bmad-help What's the difference between quick-flow and full method?
|
||||
/bmad-help Show me what workflows are available
|
||||
bmad-help I have an existing Rails app, where should I start?
|
||||
bmad-help What's the difference between quick-flow and full method?
|
||||
bmad-help Show me what workflows are available
|
||||
```
|
||||
|
||||
BMad-Help also **automatically runs at the end of every workflow**, providing clear guidance on exactly what to do next.
|
||||
|
|
@ -81,7 +81,7 @@ You have two primary options depending on the scope of changes:
|
|||
|
||||
| Scope | Recommended Approach |
|
||||
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **Small updates or additions** | Use `quick-flow-solo-dev` to create a tech-spec and implement the change. The full four-phase BMad Method is likely overkill. |
|
||||
| **Small updates or additions** | Use `bmad-quick-flow-solo-dev` to create a tech-spec and implement the change. The full four-phase BMad Method is likely overkill. |
|
||||
| **Major changes or additions** | Start with the BMad Method, applying as much or as little rigor as needed. |
|
||||
|
||||
### During PRD Creation
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ sidebar:
|
|||
|
||||
## Start Here: BMad-Help
|
||||
|
||||
**The fastest way to get answers about BMad is `/bmad-help`.** This intelligent guide will answer upwards of 80% of all questions and is available to you directly in your IDE as you work.
|
||||
**The fastest way to get answers about BMad is the `bmad-help` skill.** This intelligent guide will answer upwards of 80% of all questions and is available to you directly in your IDE as you work.
|
||||
|
||||
BMad-Help is more than a lookup tool — it:
|
||||
- **Inspects your project** to see what's already been completed
|
||||
|
|
@ -18,19 +18,23 @@ BMad-Help is more than a lookup tool — it:
|
|||
|
||||
### How to Use BMad-Help
|
||||
|
||||
Run it with just the slash command:
|
||||
Call it by name in your AI session:
|
||||
|
||||
```
|
||||
/bmad-help
|
||||
bmad-help
|
||||
```
|
||||
|
||||
Or combine it with a natural language query:
|
||||
:::tip
|
||||
You can also use `/bmad-help` or `$bmad-help` depending on your platform, but just `bmad-help` should work everywhere.
|
||||
:::
|
||||
|
||||
Combine it with a natural language query:
|
||||
|
||||
```
|
||||
/bmad-help I have a SaaS idea and know all the features. Where do I start?
|
||||
/bmad-help What are my options for UX design?
|
||||
/bmad-help I'm stuck on the PRD workflow
|
||||
/bmad-help Show me what's been done so far
|
||||
bmad-help I have a SaaS idea and know all the features. Where do I start?
|
||||
bmad-help What are my options for UX design?
|
||||
bmad-help I'm stuck on the PRD workflow
|
||||
bmad-help Show me what's been done so far
|
||||
```
|
||||
|
||||
BMad-Help responds with:
|
||||
|
|
@ -81,7 +85,7 @@ https://bmad-code-org.github.io/BMAD-METHOD/llms-full.txt
|
|||
:::note[Example]
|
||||
**Q:** "Tell me the fastest way to build something with BMad"
|
||||
|
||||
**A:** Use Quick Flow: Run `quick-spec` to write a technical specification, then `quick-dev` to implement it—skipping the full planning phases.
|
||||
**A:** Use Quick Flow: Run `bmad-quick-spec` to write a technical specification, then `bmad-quick-dev` to implement it—skipping the full planning phases.
|
||||
:::
|
||||
|
||||
## What You Get
|
||||
|
|
|
|||
|
|
@ -29,6 +29,15 @@ If you want to use a non interactive installer and provide all install options o
|
|||
npx bmad-method install
|
||||
```
|
||||
|
||||
:::tip[Want the newest prerelease build?]
|
||||
Use the `next` dist-tag:
|
||||
```bash
|
||||
npx bmad-method@next install
|
||||
```
|
||||
|
||||
This gets you newer changes earlier, with a higher chance of churn than the default install.
|
||||
:::
|
||||
|
||||
:::tip[Bleeding edge]
|
||||
To install the latest from the main branch (may be unstable):
|
||||
```bash
|
||||
|
|
@ -51,7 +60,11 @@ Pick which AI tools you use:
|
|||
- Cursor
|
||||
- Others
|
||||
|
||||
Each tool has its own way of integrating commands. The installer creates tiny prompt files to activate workflows and agents — it just puts them where your tool expects to find them.
|
||||
Each tool has its own way of integrating skills. The installer creates tiny prompt files to activate workflows and agents — it just puts them where your tool expects to find them.
|
||||
|
||||
:::note[Enabling Skills]
|
||||
Some platforms require skills to be explicitly enabled in settings before they appear. If you install BMad and don't see the skills, check your platform's settings or ask your AI assistant how to enable skills.
|
||||
:::
|
||||
|
||||
### 4. Choose Modules
|
||||
|
||||
|
|
@ -71,13 +84,19 @@ your-project/
|
|||
│ ├── core/ # Required core module
|
||||
│ └── ...
|
||||
├── _bmad-output/ # Generated artifacts
|
||||
├── .claude/ # Claude Code commands (if using Claude Code)
|
||||
└── .kiro/ # Kiro steering files (if using Kiro)
|
||||
├── .claude/ # Claude Code skills (if using Claude Code)
|
||||
│ └── skills/
|
||||
│ ├── bmad-help/
|
||||
│ ├── bmad-persona/
|
||||
│ └── ...
|
||||
└── .cursor/ # Cursor skills (if using Cursor)
|
||||
└── skills/
|
||||
└── ...
|
||||
```
|
||||
|
||||
## Verify Installation
|
||||
|
||||
Run `/bmad-help` to verify everything works and see what to do next.
|
||||
Run `bmad-help` to verify everything works and see what to do next.
|
||||
|
||||
**BMad-Help is your intelligent guide** that will:
|
||||
- Confirm your installation is working
|
||||
|
|
@ -86,8 +105,8 @@ Run `/bmad-help` to verify everything works and see what to do next.
|
|||
|
||||
You can also ask it questions:
|
||||
```
|
||||
/bmad-help I just installed, what should I do first?
|
||||
/bmad-help What are my options for a SaaS project?
|
||||
bmad-help I just installed, what should I do first?
|
||||
bmad-help What are my options for a SaaS project?
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ sections_completed: ['technology_stack', 'critical_rules']
|
|||
Run the workflow in a fresh chat:
|
||||
|
||||
```bash
|
||||
/bmad-bmm-generate-project-context
|
||||
bmad-generate-project-context
|
||||
```
|
||||
|
||||
The workflow scans your architecture document and project files to generate a context file capturing the decisions made.
|
||||
|
|
@ -87,7 +87,7 @@ The workflow scans your architecture document and project files to generate a co
|
|||
For existing projects, run:
|
||||
|
||||
```bash
|
||||
/bmad-bmm-generate-project-context
|
||||
bmad-generate-project-context
|
||||
```
|
||||
|
||||
The workflow analyzes your codebase to identify conventions, then generates a context file you can review and refine.
|
||||
|
|
|
|||
|
|
@ -30,18 +30,18 @@ If you are unsure, start with the DEV agent. You can always escalate to Quick Fl
|
|||
|
||||
## Steps
|
||||
|
||||
### 1. Load the DEV Agent
|
||||
### 1. Invoke the DEV Agent
|
||||
|
||||
Start a **fresh chat** in your AI IDE and load the DEV agent with its slash command:
|
||||
Start a **fresh chat** in your AI IDE and invoke the DEV agent skill:
|
||||
|
||||
```text
|
||||
/bmad-agent-bmm-dev
|
||||
bmad-dev
|
||||
```
|
||||
|
||||
This loads the agent's persona and capabilities into the session. If you decide you need Quick Flow instead, load the **Quick Flow Solo Dev** agent in a fresh chat:
|
||||
This loads the agent's persona and capabilities into the session. If you decide you need Quick Flow instead, invoke the **Quick Flow Solo Dev** agent skill in a fresh chat:
|
||||
|
||||
```text
|
||||
/bmad-agent-bmm-quick-flow-solo-dev
|
||||
bmad-quick-flow-solo-dev
|
||||
```
|
||||
|
||||
Once the Solo Dev agent is loaded, describe your change and ask it to create a **quick-spec**. The agent drafts a lightweight spec capturing what you want to change and how. After you approve the quick-spec, tell the agent to start the **Quick Flow dev cycle** -- it will implement the change, run tests, and perform a self-review, all guided by the spec you just approved.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ sidebar:
|
|||
order: 8
|
||||
---
|
||||
|
||||
Use the `shard-doc` tool if you need to split large markdown files into smaller, organized files for better context management.
|
||||
Use the `bmad-shard-doc` tool if you need to split large markdown files into smaller, organized files for better context management.
|
||||
|
||||
:::caution[Deprecated]
|
||||
This is no longer recommended, and soon with updated workflows and most major LLMs and tools supporting subprocesses this will be unnecessary.
|
||||
|
|
|
|||
|
|
@ -33,12 +33,15 @@ When v4 is detected, you can:
|
|||
|
||||
If you named your bmad method folder something else - you will need to manually remove the folder yourself.
|
||||
|
||||
### 3. Clean Up IDE Commands
|
||||
### 3. Clean Up IDE Skills
|
||||
|
||||
Manually remove legacy v4 IDE commands - for example if you have claude, look for any nested folders that start with bmad and remove them:
|
||||
Manually remove legacy v4 IDE commands/skills - for example if you have Claude Code, look for any nested folders that start with bmad and remove them:
|
||||
|
||||
- `.claude/commands/BMad/agents`
|
||||
- `.claude/commands/BMad/tasks`
|
||||
- `.claude/commands/`
|
||||
|
||||
The new v6 skills are installed to:
|
||||
|
||||
- `.claude/skills/`
|
||||
|
||||
### 4. Migrate Planning Artifacts
|
||||
|
||||
|
|
@ -58,7 +61,7 @@ If you have stories created or implemented:
|
|||
|
||||
1. Complete the v6 installation
|
||||
2. Place `epics.md` or `epics/epic*.md` in `_bmad-output/planning-artifacts/`
|
||||
3. Run the Scrum Master's `sprint-planning` workflow
|
||||
3. Run the Scrum Master's `bmad-sprint-planning` workflow
|
||||
4. Tell the SM which epics/stories are already complete
|
||||
|
||||
## What You Get
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ The fastest way to understand BMad is to try it.
|
|||
- **[Workflow Map](./reference/workflow-map.md)** — Visual overview of BMM phases, workflows, and context management
|
||||
|
||||
:::tip[Just Want to Dive In?]
|
||||
Install BMad and run `/bmad-help` — it will guide you through everything based on your project and installed modules.
|
||||
Install BMad and use the `bmad-help` skill — it will guide you through everything based on your project and installed modules.
|
||||
:::
|
||||
|
||||
## How to Use These Docs
|
||||
|
|
|
|||
|
|
@ -1,28 +1,28 @@
|
|||
---
|
||||
title: Agents
|
||||
description: Default BMM agents with their menu triggers and primary workflows
|
||||
description: Default BMM agents with their skill IDs, menu triggers, and primary workflows
|
||||
sidebar:
|
||||
order: 2
|
||||
---
|
||||
|
||||
## Default Agents
|
||||
|
||||
This page lists the default BMM (Agile suite) agents that install with BMad Method, along with their menu triggers and primary workflows.
|
||||
This page lists the default BMM (Agile suite) agents that install with BMad Method, along with their skill IDs, menu triggers, and primary workflows. Each agent is invoked as a skill.
|
||||
|
||||
## Notes
|
||||
|
||||
- Each agent is available as a skill, generated by the installer. The skill ID (e.g., `bmad-dev`) is used to invoke the agent.
|
||||
- Triggers are the short menu codes (e.g., `CP`) and fuzzy matches shown in each agent menu.
|
||||
- Slash commands are generated separately. See [Commands](./commands.md) for the slash command list and where they are defined.
|
||||
- QA (Quinn) is the lightweight test automation agent in BMM. The full Test Architect (TEA) lives in its own module.
|
||||
|
||||
| Agent | Triggers | Primary workflows |
|
||||
| --------------------------- | ---------------------------------- | --------------------------------------------------------------------------------------------------- |
|
||||
| Analyst (Mary) | `BP`, `RS`, `CB`, `DP` | Brainstorm Project, Research, Create Brief, Document Project |
|
||||
| Product Manager (John) | `CP`, `VP`, `EP`, `CE`, `IR`, `CC` | Create/Validate/Edit PRD, Create Epics and Stories, Implementation Readiness, Correct Course |
|
||||
| Architect (Winston) | `CA`, `IR` | Create Architecture, Implementation Readiness |
|
||||
| Scrum Master (Bob) | `SP`, `CS`, `ER`, `CC` | Sprint Planning, Create Story, Epic Retrospective, Correct Course |
|
||||
| Developer (Amelia) | `DS`, `CR` | Dev Story, Code Review |
|
||||
| QA Engineer (Quinn) | `QA` | Automate (generate tests for existing features) |
|
||||
| Quick Flow Solo Dev (Barry) | `QS`, `QD`, `CR` | Quick Spec, Quick Dev, Code Review |
|
||||
| UX Designer (Sally) | `CU` | Create UX Design |
|
||||
| Technical Writer (Paige) | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | Document Project, Write Document, Update Standards, Mermaid Generate, Validate Doc, Explain Concept |
|
||||
| Agent | Skill ID | Triggers | Primary workflows |
|
||||
| --------------------------- | -------------------- | ---------------------------------- | --------------------------------------------------------------------------------------------------- |
|
||||
| Analyst (Mary) | `bmad-analyst` | `BP`, `RS`, `CB`, `DP` | Brainstorm Project, 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 (generate tests for existing features) |
|
||||
| Quick Flow Solo Dev (Barry) | `bmad-master` | `QS`, `QD`, `CR` | Quick Spec, 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 |
|
||||
|
|
|
|||
|
|
@ -1,111 +1,113 @@
|
|||
---
|
||||
title: Commands
|
||||
description: Reference for BMad slash commands — what they are, how they work, and where to find them.
|
||||
title: Skills
|
||||
description: Reference for BMad skills — what they are, how they work, and where to find them.
|
||||
sidebar:
|
||||
order: 3
|
||||
---
|
||||
|
||||
Slash commands are pre-built prompts that load agents, run workflows, or execute tasks inside your IDE. The BMad installer generates them from your installed modules at install time. If you later add, remove, or change modules, re-run the installer to keep commands in sync (see [Troubleshooting](#troubleshooting)).
|
||||
Skills are pre-built prompts that load agents, run workflows, or execute tasks inside your IDE. The BMad installer generates them from your installed modules at install time. If you later add, remove, or change modules, re-run the installer to keep skills in sync (see [Troubleshooting](#troubleshooting)).
|
||||
|
||||
## Commands vs. Agent Menu Triggers
|
||||
## Skills vs. Agent Menu Triggers
|
||||
|
||||
BMad offers two ways to start work, and they serve different purposes.
|
||||
|
||||
| Mechanism | How you invoke it | What happens |
|
||||
| --- | --- | --- |
|
||||
| **Slash command** | Type `/bmad-...` in your IDE | Directly loads an agent, runs a workflow, or executes a task |
|
||||
| **Skill** | Type the skill name (e.g. `bmad-help`) in your IDE | Directly loads an agent, runs a workflow, or executes a task |
|
||||
| **Agent menu trigger** | Load an agent first, then type a short code (e.g. `DS`) | The agent interprets the code and starts the matching workflow while staying in character |
|
||||
|
||||
Agent menu triggers require an active agent session. Use slash commands when you know which workflow you want. Use triggers when you are already working with an agent and want to switch tasks without leaving the conversation.
|
||||
Agent menu triggers require an active agent session. Use skills when you know which workflow you want. Use triggers when you are already working with an agent and want to switch tasks without leaving the conversation.
|
||||
|
||||
## How Commands Are Generated
|
||||
## How Skills Are Generated
|
||||
|
||||
When you run `npx bmad-method install`, the installer reads the manifests for every selected module and writes one command file per agent, workflow, task, and tool. Each file is a short markdown prompt that instructs the AI to load the corresponding source file and follow its instructions.
|
||||
When you run `npx bmad-method install`, the installer reads the manifests for every selected module and writes one skill per agent, workflow, task, and tool. Each skill is a directory containing a `SKILL.md` file that instructs the AI to load the corresponding source file and follow its instructions.
|
||||
|
||||
The installer uses templates for each command type:
|
||||
The installer uses templates for each skill type:
|
||||
|
||||
| Command type | What the generated file does |
|
||||
| Skill type | What the generated file does |
|
||||
| --- | --- |
|
||||
| **Agent launcher** | Loads the agent persona file, activates its menu, and stays in character |
|
||||
| **Workflow command** | Loads the workflow engine (`workflow.xml`) and passes the workflow config |
|
||||
| **Task command** | Loads a standalone task file and follows its instructions |
|
||||
| **Tool command** | Loads a standalone tool file and follows its instructions |
|
||||
| **Workflow skill** | Loads the workflow config and follows its steps |
|
||||
| **Task skill** | Loads a standalone task file and follows its instructions |
|
||||
| **Tool skill** | Loads a standalone tool file and follows its instructions |
|
||||
|
||||
:::note[Re-running the installer]
|
||||
If you add or remove modules, run the installer again. It regenerates all command files to match your current module selection.
|
||||
If you add or remove modules, run the installer again. It regenerates all skill files to match your current module selection.
|
||||
:::
|
||||
|
||||
## Where Command Files Live
|
||||
## Where Skill Files Live
|
||||
|
||||
The installer writes command files into an IDE-specific directory inside your project. The exact path depends on which IDE you selected during installation.
|
||||
The installer writes skill files into an IDE-specific directory inside your project. The exact path depends on which IDE you selected during installation.
|
||||
|
||||
| IDE / CLI | Command directory |
|
||||
| IDE / CLI | Skills directory |
|
||||
| --- | --- |
|
||||
| Claude Code | `.claude/commands/` |
|
||||
| Cursor | `.cursor/commands/` |
|
||||
| Windsurf | `.windsurf/workflows/` |
|
||||
| Claude Code | `.claude/skills/` |
|
||||
| Cursor | `.cursor/skills/` |
|
||||
| Windsurf | `.windsurf/skills/` |
|
||||
| Other IDEs | See the installer output for the target path |
|
||||
|
||||
All IDEs receive a flat set of command files in their command directory. For example, a Claude Code installation looks like:
|
||||
Each skill is a directory containing a `SKILL.md` file. For example, a Claude Code installation looks like:
|
||||
|
||||
```text
|
||||
.claude/commands/
|
||||
├── bmad-agent-bmm-dev.md
|
||||
├── bmad-agent-bmm-pm.md
|
||||
├── bmad-bmm-create-prd.md
|
||||
├── bmad-editorial-review-prose.md
|
||||
├── bmad-help.md
|
||||
.claude/skills/
|
||||
├── bmad-help/
|
||||
│ └── SKILL.md
|
||||
├── bmad-create-prd/
|
||||
│ └── SKILL.md
|
||||
├── bmad-dev/
|
||||
│ └── SKILL.md
|
||||
└── ...
|
||||
```
|
||||
|
||||
The filename determines the slash command name in your IDE. For example, the file `bmad-agent-bmm-dev.md` registers the command `/bmad-agent-bmm-dev`.
|
||||
The directory name determines the skill name in your IDE. For example, the directory `bmad-dev/` registers the skill `bmad-dev`.
|
||||
|
||||
## How to Discover Your Commands
|
||||
## How to Discover Your Skills
|
||||
|
||||
Type `/bmad` in your IDE and use autocomplete to browse available commands.
|
||||
Type the skill name in your IDE to invoke it. Some platforms require you to enable skills in settings before they appear.
|
||||
|
||||
Run `/bmad-help` for context-aware guidance on your next step.
|
||||
Run `bmad-help` for context-aware guidance on your next step.
|
||||
|
||||
:::tip[Quick discovery]
|
||||
The generated command folders in your project are the canonical list. Open them in your file explorer to see every command with its description.
|
||||
The generated skill directories in your project are the canonical list. Open them in your file explorer to see every skill with its description.
|
||||
:::
|
||||
|
||||
## Command Categories
|
||||
## Skill Categories
|
||||
|
||||
### Agent Commands
|
||||
### Agent Skills
|
||||
|
||||
Agent commands load a specialized AI persona with a defined role, communication style, and menu of workflows. Once loaded, the agent stays in character and responds to menu triggers.
|
||||
Agent skills load a specialized AI persona with a defined role, communication style, and menu of workflows. Once loaded, the agent stays in character and responds to menu triggers.
|
||||
|
||||
| Example command | Agent | Role |
|
||||
| Example skill | Agent | Role |
|
||||
| --- | --- | --- |
|
||||
| `/bmad-agent-bmm-dev` | Amelia (Developer) | Implements stories with strict adherence to specs |
|
||||
| `/bmad-agent-bmm-pm` | John (Product Manager) | Creates and validates PRDs |
|
||||
| `/bmad-agent-bmm-architect` | Winston (Architect) | Designs system architecture |
|
||||
| `/bmad-agent-bmm-sm` | Bob (Scrum Master) | Manages sprints and stories |
|
||||
| `bmad-dev` | Amelia (Developer) | Implements stories with strict adherence to specs |
|
||||
| `bmad-pm` | John (Product Manager) | Creates and validates PRDs |
|
||||
| `bmad-architect` | Winston (Architect) | Designs system architecture |
|
||||
| `bmad-sm` | Bob (Scrum Master) | Manages sprints and stories |
|
||||
|
||||
See [Agents](./agents.md) for the full list of default agents and their triggers.
|
||||
|
||||
### Workflow Commands
|
||||
### Workflow Skills
|
||||
|
||||
Workflow commands run a structured, multi-step process without loading an agent persona first. They load the workflow engine and pass a specific workflow configuration.
|
||||
Workflow skills run a structured, multi-step process without loading an agent persona first. They load a workflow configuration and follow its steps.
|
||||
|
||||
| Example command | Purpose |
|
||||
| Example skill | Purpose |
|
||||
| --- | --- |
|
||||
| `/bmad-bmm-create-prd` | Create a Product Requirements Document |
|
||||
| `/bmad-bmm-create-architecture` | Design system architecture |
|
||||
| `/bmad-bmm-dev-story` | Implement a story |
|
||||
| `/bmad-bmm-code-review` | Run a code review |
|
||||
| `/bmad-bmm-quick-spec` | Define an ad-hoc change (Quick Flow) |
|
||||
| `bmad-create-prd` | Create a Product Requirements Document |
|
||||
| `bmad-create-architecture` | Design system architecture |
|
||||
| `bmad-create-epics-and-stories` | Create epics and stories |
|
||||
| `bmad-dev-story` | Implement a story |
|
||||
| `bmad-code-review` | Run a code review |
|
||||
| `bmad-quick-spec` | Define an ad-hoc change (Quick Flow) |
|
||||
|
||||
See [Workflow Map](./workflow-map.md) for the complete workflow reference organized by phase.
|
||||
|
||||
### Task and Tool Commands
|
||||
### Task and Tool Skills
|
||||
|
||||
Tasks and tools are standalone operations that do not require an agent or workflow context.
|
||||
|
||||
#### BMad-Help: Your Intelligent Guide
|
||||
|
||||
**`/bmad-help`** is your primary interface for discovering what to do next. It's not just a lookup tool — it's an intelligent assistant that:
|
||||
**`bmad-help`** is your primary interface for discovering what to do next. It's not just a lookup tool — it's an intelligent assistant that:
|
||||
|
||||
- **Inspects your project** to see what's already been done
|
||||
- **Understands natural language queries** — ask questions in plain English
|
||||
|
|
@ -116,36 +118,28 @@ Tasks and tools are standalone operations that do not require an agent or workfl
|
|||
**Examples:**
|
||||
|
||||
```
|
||||
/bmad-help
|
||||
/bmad-help I have a SaaS idea and know all the features. Where do I start?
|
||||
/bmad-help What are my options for UX design?
|
||||
/bmad-help I'm stuck on the PRD workflow
|
||||
bmad-help
|
||||
bmad-help I have a SaaS idea and know all the features. Where do I start?
|
||||
bmad-help What are my options for UX design?
|
||||
bmad-help I'm stuck on the PRD workflow
|
||||
```
|
||||
|
||||
#### Other Tasks and Tools
|
||||
|
||||
| Example command | Purpose |
|
||||
| Example skill | Purpose |
|
||||
| --- | --- |
|
||||
| `/bmad-shard-doc` | Split a large markdown file into smaller sections |
|
||||
| `/bmad-index-docs` | Index project documentation |
|
||||
| `/bmad-editorial-review-prose` | Review document prose quality |
|
||||
| `bmad-shard-doc` | Split a large markdown file into smaller sections |
|
||||
| `bmad-index-docs` | Index project documentation |
|
||||
| `bmad-editorial-review-prose` | Review document prose quality |
|
||||
|
||||
## Naming Convention
|
||||
|
||||
Command names follow a predictable pattern.
|
||||
|
||||
| Pattern | Meaning | Example |
|
||||
| --- | --- | --- |
|
||||
| `bmad-agent-<module>-<name>` | Agent launcher | `bmad-agent-bmm-dev` |
|
||||
| `bmad-<module>-<workflow>` | Workflow command | `bmad-bmm-create-prd` |
|
||||
| `bmad-<name>` | Core task or tool | `bmad-help` |
|
||||
|
||||
Module codes: `bmm` (Agile suite), `bmb` (Builder), `tea` (Test Architect), `cis` (Creative Intelligence), `gds` (Game Dev Studio). See [Modules](./modules.md) for descriptions.
|
||||
All skills use the `bmad-` prefix followed by a descriptive name (e.g., `bmad-dev`, `bmad-create-prd`, `bmad-help`). See [Modules](./modules.md) for available modules.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Commands not appearing after install.** Restart your IDE or reload the window. Some IDEs cache the command list and require a refresh to pick up new files.
|
||||
**Skills not appearing after install.** Some platforms require skills to be explicitly enabled in settings. Check your IDE's documentation or ask your AI assistant how to enable skills. You may also need to restart your IDE or reload the window.
|
||||
|
||||
**Expected commands are missing.** The installer only generates commands for modules you selected. Run `npx bmad-method install` again and verify your module selection. Check that the command files exist in the expected directory.
|
||||
**Expected skills are missing.** The installer only generates skills for modules you selected. Run `npx bmad-method install` again and verify your module selection. Check that the skill files exist in the expected directory.
|
||||
|
||||
**Commands from a removed module still appear.** The installer does not delete old command files automatically. Remove the stale files from your IDE's command directory, or delete the entire command directory and re-run the installer for a clean set.
|
||||
**Skills from a removed module still appear.** The installer does not delete old skill files automatically. Remove the stale directories from your IDE's skills directory, or delete the entire skills directory and re-run the installer for a clean set.
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Most projects should start with Quinn. If you later need test strategy, quality
|
|||
|
||||
Quinn is the built-in QA agent in the BMM (Agile suite) module. It generates working tests quickly using your project's existing test framework -- no configuration or additional installation required.
|
||||
|
||||
**Trigger:** `QA` or `bmad-bmm-qa-automate`
|
||||
**Trigger:** `QA` or `bmad-qa-generate-e2e-tests`
|
||||
|
||||
### What Quinn Does
|
||||
|
||||
|
|
|
|||
|
|
@ -9,9 +9,9 @@ The BMad Method (BMM) is a module in the BMad Ecosystem, targeted at following t
|
|||
|
||||
The rationale and concepts come from agile methodologies that have been used across the industry with great success as a mental framework.
|
||||
|
||||
If at any time you are unsure what to do, the `/bmad-help` command will help you stay on track or know what to do next. You can always refer to this for reference also - but /bmad-help is fully interactive and much quicker if you have already installed the BMad Method. Additionally, if you are using different modules that have extended the BMad Method or added other complementary non-extension modules - the /bmad-help evolves to know all that is available to give you the best in-the-moment advice.
|
||||
If at any time you are unsure what to do, the `bmad-help` skill will help you stay on track or know what to do next. You can always refer to this for reference also - but `bmad-help` is fully interactive and much quicker if you have already installed the BMad Method. Additionally, if you are using different modules that have extended the BMad Method or added other complementary non-extension modules - `bmad-help` evolves to know all that is available to give you the best in-the-moment advice.
|
||||
|
||||
Final important note: Every workflow below can be run directly with your tool of choice via slash command or by loading an agent first and using the entry from the agents menu.
|
||||
Final important note: Every workflow below can be run directly with your tool of choice via skill or by loading an agent first and using the entry from the agents menu.
|
||||
|
||||
<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>
|
||||
|
||||
|
|
@ -26,8 +26,8 @@ Explore the problem space and validate ideas before committing to planning.
|
|||
| Workflow | Purpose | Produces |
|
||||
| ------------------------------- | -------------------------------------------------------------------------- | ------------------------- |
|
||||
| `bmad-brainstorming` | Brainstorm Project Ideas with guided facilitation of a brainstorming coach | `brainstorming-report.md` |
|
||||
| `bmad-bmm-research` | Validate market, technical, or domain assumptions | Research findings |
|
||||
| `bmad-bmm-create-product-brief` | Capture strategic vision | `product-brief.md` |
|
||||
| `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | Validate market, technical, or domain assumptions | Research findings |
|
||||
| `bmad-create-product-brief` | Capture strategic vision | `product-brief.md` |
|
||||
|
||||
## Phase 2: Planning
|
||||
|
||||
|
|
@ -35,8 +35,8 @@ Define what to build and for whom.
|
|||
|
||||
| Workflow | Purpose | Produces |
|
||||
| --------------------------- | ---------------------------------------- | ------------ |
|
||||
| `bmad-bmm-create-prd` | Define requirements (FRs/NFRs) | `PRD.md` |
|
||||
| `bmad-bmm-create-ux-design` | Design user experience (when UX matters) | `ux-spec.md` |
|
||||
| `bmad-create-prd` | Define requirements (FRs/NFRs) | `PRD.md` |
|
||||
| `bmad-create-ux-design` | Design user experience (when UX matters) | `ux-spec.md` |
|
||||
|
||||
## Phase 3: Solutioning
|
||||
|
||||
|
|
@ -44,9 +44,9 @@ Decide how to build it and break work into stories.
|
|||
|
||||
| Workflow | Purpose | Produces |
|
||||
| ----------------------------------------- | ------------------------------------------ | --------------------------- |
|
||||
| `bmad-bmm-create-architecture` | Make technical decisions explicit | `architecture.md` with ADRs |
|
||||
| `bmad-bmm-create-epics-and-stories` | Break requirements into implementable work | Epic files with stories |
|
||||
| `bmad-bmm-check-implementation-readiness` | Gate check before implementation | PASS/CONCERNS/FAIL decision |
|
||||
| `bmad-create-architecture` | Make technical decisions explicit | `architecture.md` with ADRs |
|
||||
| `bmad-create-epics-and-stories` | Break requirements into implementable work | Epic files with stories |
|
||||
| `bmad-check-implementation-readiness` | Gate check before implementation | PASS/CONCERNS/FAIL decision |
|
||||
|
||||
## Phase 4: Implementation
|
||||
|
||||
|
|
@ -54,13 +54,13 @@ Build it, one story at a time. Coming soon, full phase 4 automation!
|
|||
|
||||
| Workflow | Purpose | Produces |
|
||||
| -------------------------- | ------------------------------------------------------------------------ | -------------------------------- |
|
||||
| `bmad-bmm-sprint-planning` | Initialize tracking (once per project to sequence the dev cycle) | `sprint-status.yaml` |
|
||||
| `bmad-bmm-create-story` | Prepare next story for implementation | `story-[slug].md` |
|
||||
| `bmad-bmm-dev-story` | Implement the story | Working code + tests |
|
||||
| `bmad-bmm-code-review` | Validate implementation quality | Approved or changes requested |
|
||||
| `bmad-bmm-correct-course` | Handle significant mid-sprint changes | Updated plan or re-routing |
|
||||
| `bmad-bmm-automate` | Generate tests for existing features - Use after a full epic is complete | End to End UI Focused Test suite |
|
||||
| `bmad-bmm-retrospective` | Review after epic completion | Lessons learned |
|
||||
| `bmad-sprint-planning` | Initialize tracking (once per project to sequence the dev cycle) | `sprint-status.yaml` |
|
||||
| `bmad-create-story` | Prepare next story for implementation | `story-[slug].md` |
|
||||
| `bmad-dev-story` | Implement the story | Working code + tests |
|
||||
| `bmad-code-review` | Validate implementation quality | Approved or changes requested |
|
||||
| `bmad-correct-course` | Handle significant mid-sprint changes | Updated plan or re-routing |
|
||||
| `bmad-sprint-status` | Track sprint progress and story status | Sprint status update |
|
||||
| `bmad-retrospective` | Review after epic completion | Lessons learned |
|
||||
|
||||
## Quick Flow (Parallel Track)
|
||||
|
||||
|
|
@ -68,8 +68,8 @@ Skip phases 1-3 for small, well-understood work.
|
|||
|
||||
| Workflow | Purpose | Produces |
|
||||
| --------------------- | ------------------------------------------ | --------------------------------------------- |
|
||||
| `bmad-bmm-quick-spec` | Define an ad-hoc change | `tech-spec.md` (story file for small changes) |
|
||||
| `bmad-bmm-quick-dev` | Implement from spec or direct instructions | Working code + tests |
|
||||
| `bmad-quick-spec` | Define an ad-hoc change | `tech-spec.md` (story file for small changes) |
|
||||
| `bmad-quick-dev` | Implement from spec or direct instructions | Working code + tests |
|
||||
|
||||
## Context Management
|
||||
|
||||
|
|
@ -84,6 +84,6 @@ Create `project-context.md` to ensure AI agents follow your project's rules and
|
|||
**How to create it:**
|
||||
|
||||
- **Manually** — Create `_bmad-output/project-context.md` with your technology stack and implementation rules
|
||||
- **Generate it** — Run `/bmad-bmm-generate-project-context` to auto-generate from your architecture or codebase
|
||||
- **Generate it** — Run `bmad-generate-project-context` to auto-generate from your architecture or codebase
|
||||
|
||||
[**Learn more about project-context.md**](../explanation/project-context.md)
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Build software faster using AI-powered workflows with specialized agents that gu
|
|||
|
||||
:::tip[The Easiest Path]
|
||||
**Install** → `npx bmad-method install`
|
||||
**Ask** → `/bmad-help what should I do first?`
|
||||
**Ask** → `bmad-help what should I do first?`
|
||||
**Build** → Let BMad-Help guide you workflow by workflow
|
||||
:::
|
||||
|
||||
|
|
@ -37,16 +37,16 @@ Build software faster using AI-powered workflows with specialized agents that gu
|
|||
|
||||
### How to Use BMad-Help
|
||||
|
||||
Run it in your AI IDE with just the slash command:
|
||||
Run it in your AI IDE by invoking the skill:
|
||||
|
||||
```
|
||||
/bmad-help
|
||||
bmad-help
|
||||
```
|
||||
|
||||
Or combine it with a question for context-aware guidance:
|
||||
|
||||
```
|
||||
/bmad-help I have an idea for a SaaS product, I already know all the features I want. where do I get started?
|
||||
bmad-help I have an idea for a SaaS product, I already know all the features I want. where do I get started?
|
||||
```
|
||||
|
||||
BMad-Help will respond with:
|
||||
|
|
@ -59,7 +59,7 @@ BMad-Help will respond with:
|
|||
BMad-Help doesn't just answer questions — **it automatically runs at the end of every workflow** to tell you exactly what to do next. No guessing, no searching docs — just clear guidance on the next required workflow.
|
||||
|
||||
:::tip[Start Here]
|
||||
After installing BMad, run `/bmad-help` immediately. It will detect what modules you have installed and guide you to the right starting point for your project.
|
||||
After installing BMad, invoke the `bmad-help` skill immediately. It will detect what modules you have installed and guide you to the right starting point for your project.
|
||||
:::
|
||||
|
||||
## Understanding BMad
|
||||
|
|
@ -95,6 +95,8 @@ Open a terminal in your project directory and run:
|
|||
npx bmad-method install
|
||||
```
|
||||
|
||||
If you want the newest prerelease build instead of the default release channel, use `npx bmad-method@next install`.
|
||||
|
||||
When prompted to select modules, choose **BMad Method**.
|
||||
|
||||
The installer creates two folders:
|
||||
|
|
@ -105,14 +107,14 @@ The installer creates two folders:
|
|||
Open your AI IDE in the project folder and run:
|
||||
|
||||
```
|
||||
/bmad-help
|
||||
bmad-help
|
||||
```
|
||||
|
||||
BMad-Help will detect what you've completed and recommend exactly what to do next. You can also ask it questions like "What are my options?" or "I have a SaaS idea, where should I start?"
|
||||
:::
|
||||
|
||||
:::note[How to Load Agents and Run Workflows]
|
||||
Each workflow has a **slash command** you run in your IDE (e.g., `/bmad-bmm-create-prd`). Running a workflow command automatically loads the appropriate agent — you don't need to load agents separately. You can also load an agent directly for general conversation (e.g., `/bmad-agent-bmm-pm` for the PM agent).
|
||||
Each workflow has a **skill** you invoke by name in your IDE (e.g., `bmad-create-prd`). Your AI tool will recognize the `bmad-*` name and run it — you don't need to load agents separately. You can also invoke an agent skill directly for general conversation (e.g., `bmad-pm` for the PM agent).
|
||||
:::
|
||||
|
||||
:::caution[Fresh Chats]
|
||||
|
|
@ -126,35 +128,35 @@ Work through phases 1-3. **Use fresh chats for each workflow.**
|
|||
:::tip[Project Context (Optional)]
|
||||
Before starting, consider creating `project-context.md` to document your technical preferences and implementation rules. This ensures all AI agents follow your conventions throughout the project.
|
||||
|
||||
Create it manually at `_bmad-output/project-context.md` or generate it after architecture using `/bmad-bmm-generate-project-context`. [Learn more](../explanation/project-context.md).
|
||||
Create it manually at `_bmad-output/project-context.md` or generate it after architecture using `bmad-generate-project-context`. [Learn more](../explanation/project-context.md).
|
||||
:::
|
||||
|
||||
### Phase 1: Analysis (Optional)
|
||||
|
||||
All workflows in this phase are optional:
|
||||
- **brainstorming** (`/bmad-brainstorming`) — Guided ideation
|
||||
- **research** (`/bmad-bmm-research`) — Market and technical research
|
||||
- **create-product-brief** (`/bmad-bmm-create-product-brief`) — Recommended foundation document
|
||||
- **brainstorming** (`bmad-brainstorming`) — Guided ideation
|
||||
- **research** (`bmad-research`) — Market and technical research
|
||||
- **create-product-brief** (`bmad-create-product-brief`) — Recommended foundation document
|
||||
|
||||
### Phase 2: Planning (Required)
|
||||
|
||||
**For BMad Method and Enterprise tracks:**
|
||||
1. Load the **PM agent** (`/bmad-agent-bmm-pm`) in a new chat
|
||||
2. Run the `prd` workflow (`/bmad-bmm-create-prd`)
|
||||
1. Invoke the **PM agent** (`bmad-pm`) in a new chat
|
||||
2. Run the `bmad-create-prd` workflow (`bmad-create-prd`)
|
||||
3. Output: `PRD.md`
|
||||
|
||||
**For Quick Flow track:**
|
||||
- Use the `quick-spec` workflow (`/bmad-bmm-quick-spec`) instead of PRD, then skip to implementation
|
||||
- Use the `bmad-quick-spec` workflow (`bmad-quick-spec`) instead of PRD, then skip to implementation
|
||||
|
||||
:::note[UX Design (Optional)]
|
||||
If your project has a user interface, load the **UX-Designer agent** (`/bmad-agent-bmm-ux-designer`) and run the UX design workflow (`/bmad-bmm-create-ux-design`) after creating your PRD.
|
||||
If your project has a user interface, invoke the **UX-Designer agent** (`bmad-ux-designer`) and run the UX design workflow (`bmad-create-ux-design`) after creating your PRD.
|
||||
:::
|
||||
|
||||
### Phase 3: Solutioning (BMad Method/Enterprise)
|
||||
|
||||
**Create Architecture**
|
||||
1. Load the **Architect agent** (`/bmad-agent-bmm-architect`) in a new chat
|
||||
2. Run `create-architecture` (`/bmad-bmm-create-architecture`)
|
||||
1. Invoke the **Architect agent** (`bmad-architect`) in a new chat
|
||||
2. Run `bmad-create-architecture` (`bmad-create-architecture`)
|
||||
3. Output: Architecture document with technical decisions
|
||||
|
||||
**Create Epics and Stories**
|
||||
|
|
@ -163,13 +165,13 @@ If your project has a user interface, load the **UX-Designer agent** (`/bmad-age
|
|||
Epics and stories are now created *after* architecture. This produces better quality stories because architecture decisions (database, API patterns, tech stack) directly affect how work should be broken down.
|
||||
:::
|
||||
|
||||
1. Load the **PM agent** (`/bmad-agent-bmm-pm`) in a new chat
|
||||
2. Run `create-epics-and-stories` (`/bmad-bmm-create-epics-and-stories`)
|
||||
1. Invoke the **PM agent** (`bmad-pm`) in a new chat
|
||||
2. Run `bmad-create-epics-and-stories` (`bmad-create-epics-and-stories`)
|
||||
3. The workflow uses both PRD and Architecture to create technically-informed stories
|
||||
|
||||
**Implementation Readiness Check** *(Highly Recommended)*
|
||||
1. Load the **Architect agent** (`/bmad-agent-bmm-architect`) in a new chat
|
||||
2. Run `check-implementation-readiness` (`/bmad-bmm-check-implementation-readiness`)
|
||||
1. Invoke the **Architect agent** (`bmad-architect`) in a new chat
|
||||
2. Run `bmad-check-implementation-readiness` (`bmad-check-implementation-readiness`)
|
||||
3. Validates cohesion across all planning documents
|
||||
|
||||
## Step 2: Build Your Project
|
||||
|
|
@ -178,7 +180,7 @@ Once planning is complete, move to implementation. **Each workflow should run in
|
|||
|
||||
### Initialize Sprint Planning
|
||||
|
||||
Load the **SM agent** (`/bmad-agent-bmm-sm`) and run `sprint-planning` (`/bmad-bmm-sprint-planning`). This creates `sprint-status.yaml` to track all epics and stories.
|
||||
Invoke the **SM agent** (`bmad-sm`) and run `bmad-sprint-planning` (`bmad-sprint-planning`). This creates `sprint-status.yaml` to track all epics and stories.
|
||||
|
||||
### The Build Cycle
|
||||
|
||||
|
|
@ -186,11 +188,11 @@ For each story, repeat this cycle with fresh chats:
|
|||
|
||||
| Step | Agent | Workflow | Command | Purpose |
|
||||
| ---- | ----- | -------------- | -------------------------- | ---------------------------------- |
|
||||
| 1 | SM | `create-story` | `/bmad-bmm-create-story` | Create story file from epic |
|
||||
| 2 | DEV | `dev-story` | `/bmad-bmm-dev-story` | Implement the story |
|
||||
| 3 | DEV | `code-review` | `/bmad-bmm-code-review` | Quality validation *(recommended)* |
|
||||
| 1 | SM | `bmad-create-story` | `bmad-create-story` | Create story file from epic |
|
||||
| 2 | DEV | `bmad-dev-story` | `bmad-dev-story` | Implement the story |
|
||||
| 3 | DEV | `bmad-code-review` | `bmad-code-review` | Quality validation *(recommended)* |
|
||||
|
||||
After completing all stories in an epic, load the **SM agent** (`/bmad-agent-bmm-sm`) and run `retrospective` (`/bmad-bmm-retrospective`).
|
||||
After completing all stories in an epic, invoke the **SM agent** (`bmad-sm`) and run `bmad-retrospective` (`bmad-retrospective`).
|
||||
|
||||
## What You've Accomplished
|
||||
|
||||
|
|
@ -221,16 +223,16 @@ your-project/
|
|||
|
||||
| Workflow | Command | Agent | Purpose |
|
||||
| ------------------------------------- | ------------------------------------------ | --------- | ----------------------------------------------- |
|
||||
| **`help`** ⭐ | `/bmad-help` | Any | **Your intelligent guide — ask anything!** |
|
||||
| `prd` | `/bmad-bmm-create-prd` | PM | Create Product Requirements Document |
|
||||
| `create-architecture` | `/bmad-bmm-create-architecture` | Architect | Create architecture document |
|
||||
| `generate-project-context` | `/bmad-bmm-generate-project-context` | Analyst | Create project context file |
|
||||
| `create-epics-and-stories` | `/bmad-bmm-create-epics-and-stories` | PM | Break down PRD into epics |
|
||||
| `check-implementation-readiness` | `/bmad-bmm-check-implementation-readiness` | Architect | Validate planning cohesion |
|
||||
| `sprint-planning` | `/bmad-bmm-sprint-planning` | SM | Initialize sprint tracking |
|
||||
| `create-story` | `/bmad-bmm-create-story` | SM | Create a story file |
|
||||
| `dev-story` | `/bmad-bmm-dev-story` | DEV | Implement a story |
|
||||
| `code-review` | `/bmad-bmm-code-review` | DEV | Review implemented code |
|
||||
| **`bmad-help`** ⭐ | `bmad-help` | Any | **Your intelligent guide — ask anything!** |
|
||||
| `bmad-create-prd` | `bmad-create-prd` | PM | Create Product Requirements Document |
|
||||
| `bmad-create-architecture` | `bmad-create-architecture` | Architect | Create architecture document |
|
||||
| `bmad-generate-project-context` | `bmad-generate-project-context` | Analyst | Create project context file |
|
||||
| `bmad-create-epics-and-stories` | `bmad-create-epics-and-stories` | PM | Break down PRD into epics |
|
||||
| `bmad-check-implementation-readiness` | `bmad-check-implementation-readiness` | Architect | Validate planning cohesion |
|
||||
| `bmad-sprint-planning` | `bmad-sprint-planning` | SM | Initialize sprint tracking |
|
||||
| `bmad-create-story` | `bmad-create-story` | SM | Create a story file |
|
||||
| `bmad-dev-story` | `bmad-dev-story` | DEV | Implement a story |
|
||||
| `bmad-code-review` | `bmad-code-review` | DEV | Review implemented code |
|
||||
|
||||
## Common Questions
|
||||
|
||||
|
|
@ -238,10 +240,10 @@ your-project/
|
|||
Only for BMad Method and Enterprise tracks. Quick Flow skips from tech-spec to implementation.
|
||||
|
||||
**Can I change my plan later?**
|
||||
Yes. The SM agent has a `correct-course` workflow (`/bmad-bmm-correct-course`) for handling scope changes.
|
||||
Yes. The SM agent has a `bmad-correct-course` workflow (`bmad-correct-course`) for handling scope changes.
|
||||
|
||||
**What if I want to brainstorm first?**
|
||||
Load the Analyst agent (`/bmad-agent-bmm-analyst`) and run `brainstorming` (`/bmad-brainstorming`) before starting your PRD.
|
||||
Invoke the Analyst agent (`bmad-analyst`) and run `bmad-brainstorming` (`bmad-brainstorming`) before starting your PRD.
|
||||
|
||||
**Do I need to follow a strict order?**
|
||||
Not strictly. Once you learn the flow, you can run workflows directly using the Quick Reference above.
|
||||
|
|
@ -249,7 +251,7 @@ Not strictly. Once you learn the flow, you can run workflows directly using the
|
|||
## Getting Help
|
||||
|
||||
:::tip[First Stop: BMad-Help]
|
||||
**Run `/bmad-help` anytime** — it's the fastest way to get unstuck. Ask it anything:
|
||||
**Invoke `bmad-help` anytime** — it's the fastest way to get unstuck. Ask it anything:
|
||||
- "What should I do after installing?"
|
||||
- "I'm stuck on workflow X"
|
||||
- "What are my options for Y?"
|
||||
|
|
@ -264,10 +266,10 @@ BMad-Help inspects your project, detects what you've completed, and tells you ex
|
|||
## Key Takeaways
|
||||
|
||||
:::tip[Remember These]
|
||||
- **Start with `/bmad-help`** — Your intelligent guide that knows your project and options
|
||||
- **Start with `bmad-help`** — Your intelligent guide that knows your project and options
|
||||
- **Always use fresh chats** — Start a new chat for each workflow
|
||||
- **Track matters** — Quick Flow uses quick-spec; Method/Enterprise need PRD and architecture
|
||||
- **BMad-Help runs automatically** — Every workflow ends with guidance on what's next
|
||||
:::
|
||||
|
||||
Ready to start? Install BMad, run `/bmad-help`, and let your intelligent guide lead the way.
|
||||
Ready to start? Install BMad, invoke `bmad-help`, and let your intelligent guide lead the way.
|
||||
|
|
|
|||
|
|
@ -6,4 +6,4 @@ template: splash
|
|||
|
||||
您查找的页面不存在或已被移动。
|
||||
|
||||
[返回首页](./index_cn.md)
|
||||
[返回首页](./index.md)
|
||||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
title: "Quick Flow"
|
||||
title: "快速流程"
|
||||
description: 小型变更的快速通道 - 跳过完整方法论
|
||||
sidebar:
|
||||
order: 1
|
||||
---
|
||||
|
||||
跳过繁琐流程。Quick Flow 通过两条命令将你从想法带到可运行的代码 - 无需产品简报、无需 PRD、无需架构文档。
|
||||
跳过繁琐流程。快速流程通过两条命令将你从想法带到可运行的代码 - 无需产品简报、无需 PRD、无需架构文档。
|
||||
|
||||
## 何时使用
|
||||
|
||||
|
|
@ -23,12 +23,12 @@ sidebar:
|
|||
- 需求不明确或有争议的任何工作
|
||||
|
||||
:::caution[Scope Creep]
|
||||
如果你启动 Quick Flow 后发现范围超出预期,`quick-dev` 会检测到并提供升级选项。你可以在任何时间切换到完整的 PRD 工作流程,而不会丢失你的工作。
|
||||
如果你启动快速流程后发现范围超出预期,`quick-dev` 会检测到并提供升级选项。你可以在任何时间切换到完整的 PRD 工作流程,而不会丢失你的工作。
|
||||
:::
|
||||
|
||||
## 工作原理
|
||||
|
||||
Quick Flow 有两条命令,每条都由结构化的工作流程支持。你可以一起运行它们,也可以独立运行。
|
||||
快速流程有两条命令,每条都由结构化的工作流程支持。你可以一起运行它们,也可以独立运行。
|
||||
|
||||
### quick-spec:规划
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ Quick Flow 有两条命令,每条都由结构化的工作流程支持。你可
|
|||
为获得最佳效果,在完成 `quick-spec` 后,在新对话中运行 `quick-dev`。这为实现智能体提供了专注于构建的干净上下文。
|
||||
:::
|
||||
|
||||
## Quick Flow 跳过的内容
|
||||
## 快速流程跳过的内容
|
||||
|
||||
完整的 BMad 方法在编写任何代码之前会生成产品简报、PRD、架构文档和 Epic/Story 分解。Quick Flow 用单个技术规范替代所有这些。这之所以有效,是因为 Quick Flow 针对以下变更:
|
||||
|
||||
|
|
@ -65,7 +65,7 @@ Quick Flow 有两条命令,每条都由结构化的工作流程支持。你可
|
|||
|
||||
## 升级到完整 BMad 方法
|
||||
|
||||
Quick Flow 包含内置的范围检测护栏。当你使用直接请求运行 `quick-dev` 时,它会评估多组件提及、系统级语言和方法不确定性等信号。如果检测到工作超出快速流程范围:
|
||||
快速流程包含内置的范围检测护栏。当你使用直接请求运行 `quick-dev` 时,它会评估多组件提及、系统级语言和方法不确定性等信号。如果检测到工作超出快速流程范围:
|
||||
|
||||
- **轻度升级** - 建议先运行 `quick-spec` 创建计划
|
||||
- **重度升级** - 建议切换到完整的 BMad 方法 PRD 流程
|
||||
|
|
@ -15,7 +15,7 @@ sidebar:
|
|||
- 您希望智能体在每次启动时执行特定操作
|
||||
|
||||
:::note[前置条件]
|
||||
- 在项目中安装了 BMad(参见[如何安装 BMad](./install-bmad_cn.md))
|
||||
- 在项目中安装了 BMad(参见[如何安装 BMad](./install-bmad.md))
|
||||
- 用于编辑 YAML 文件的文本编辑器
|
||||
:::
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ sidebar:
|
|||
|
||||
你可以查看和完善生成的文件,或者如果你更喜欢,可以在 `_bmad-output/project-context.md` 手动创建它。
|
||||
|
||||
[了解更多关于项目上下文](../explanation/project-context_cn.md)
|
||||
[了解更多关于项目上下文](../explanation/project-context.md)
|
||||
|
||||
## 步骤 3:维护高质量项目文档
|
||||
|
||||
|
|
@ -61,16 +61,16 @@ sidebar:
|
|||
|
||||
### BMad-Help:你的起点
|
||||
|
||||
**随时运行 `/bmad-help`,当你不确定下一步该做什么时。** 这个智能指南:
|
||||
**随时运行 `bmad-help`,当你不确定下一步该做什么时。** 这个智能指南:
|
||||
|
||||
- 检查你的项目以查看已经完成了什么
|
||||
- 根据你安装的模块显示选项
|
||||
- 理解自然语言查询
|
||||
|
||||
```
|
||||
/bmad-help 我有一个现有的 Rails 应用,我应该从哪里开始?
|
||||
/bmad-help quick-flow 和完整方法有什么区别?
|
||||
/bmad-help 显示我有哪些可用的工作流程
|
||||
bmad-help 我有一个现有的 Rails 应用,我应该从哪里开始?
|
||||
bmad-help quick-flow 和完整方法有什么区别?
|
||||
bmad-help 显示我有哪些可用的工作流程
|
||||
```
|
||||
|
||||
BMad-Help 还会在**每个工作流程结束时自动运行**,提供关于下一步该做什么的清晰指导。
|
||||
|
|
@ -113,8 +113,8 @@ UX 工作是可选的。决定不取决于你的项目是否有 UX,而取决
|
|||
|
||||
## 更多信息
|
||||
|
||||
- **[快速修复](./quick-fixes_cn.md)** - 错误修复和临时变更
|
||||
- **[既有项目 FAQ](../explanation/established-projects-faq_cn.md)** - 关于在既有项目上工作的常见问题
|
||||
- **[快速修复](./quick-fixes.md)** - 错误修复和临时变更
|
||||
- **[既有项目 FAQ](../explanation/established-projects-faq.md)** - 关于在既有项目上工作的常见问题
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
|
@ -7,7 +7,7 @@ sidebar:
|
|||
|
||||
## 从这里开始:BMad-Help
|
||||
|
||||
**获取关于 BMad 答案的最快方式是 `/bmad-help`。** 这个智能指南可以回答超过 80% 的问题,并且直接在您的 IDE 中可用,方便您工作时使用。
|
||||
**获取关于 BMad 答案的最快方式是 `bmad-help`。** 这个智能指南可以回答超过 80% 的问题,并且直接在您的 IDE 中可用,方便您工作时使用。
|
||||
|
||||
BMad-Help 不仅仅是一个查询工具——它:
|
||||
- **检查您的项目**以查看已完成的内容
|
||||
|
|
@ -21,16 +21,16 @@ BMad-Help 不仅仅是一个查询工具——它:
|
|||
只需使用斜杠命令运行它:
|
||||
|
||||
```
|
||||
/bmad-help
|
||||
bmad-help
|
||||
```
|
||||
|
||||
或者结合自然语言查询:
|
||||
|
||||
```
|
||||
/bmad-help 我有一个 SaaS 想法并且知道所有功能。我应该从哪里开始?
|
||||
/bmad-help 我在 UX 设计方面有哪些选择?
|
||||
/bmad-help 我在 PRD 工作流上卡住了
|
||||
/bmad-help 向我展示到目前为止已完成的内容
|
||||
bmad-help 我有一个 SaaS 想法并且知道所有功能。我应该从哪里开始?
|
||||
bmad-help 我在 UX 设计方面有哪些选择?
|
||||
bmad-help 我在 PRD 工作流上卡住了
|
||||
bmad-help 向我展示到目前为止已完成的内容
|
||||
```
|
||||
|
||||
BMad-Help 会回应:
|
||||
|
|
@ -7,7 +7,7 @@ sidebar:
|
|||
|
||||
使用 `npx bmad-method install` 命令在项目中设置 BMad,并选择你需要的模块和 AI 工具。
|
||||
|
||||
如果你想使用非交互式安装程序并在命令行中提供所有安装选项,请参阅[本指南](./non-interactive-installation_cn.md)。
|
||||
如果你想使用非交互式安装程序并在命令行中提供所有安装选项,请参阅[本指南](./non-interactive-installation.md)。
|
||||
|
||||
## 何时使用
|
||||
|
||||
|
|
@ -77,7 +77,7 @@ your-project/
|
|||
|
||||
## 验证安装
|
||||
|
||||
运行 `/bmad-help` 来验证一切正常并查看下一步操作。
|
||||
运行 `bmad-help` 来验证一切正常并查看下一步操作。
|
||||
|
||||
**BMad-Help 是你的智能向导**,它会:
|
||||
- 确认你的安装正常工作
|
||||
|
|
@ -86,15 +86,15 @@ your-project/
|
|||
|
||||
你也可以向它提问:
|
||||
```
|
||||
/bmad-help 我刚安装完成,应该先做什么?
|
||||
/bmad-help 对于 SaaS 项目我有哪些选项?
|
||||
bmad-help 我刚安装完成,应该先做什么?
|
||||
bmad-help 对于 SaaS 项目我有哪些选项?
|
||||
```
|
||||
|
||||
## 故障排除
|
||||
|
||||
**安装程序抛出错误**——将输出复制粘贴到你的 AI 助手中,让它来解决问题。
|
||||
|
||||
**安装程序工作正常但后续出现问题**——你的 AI 需要 BMad 上下文才能提供帮助。请参阅[如何获取关于 BMad 的答案](./get-answers-about-bmad_cn.md)了解如何将你的 AI 指向正确的来源。
|
||||
**安装程序工作正常但后续出现问题**——你的 AI 需要 BMad 上下文才能提供帮助。请参阅[如何获取关于 BMad 的答案](./get-answers-about-bmad.md)了解如何将你的 AI 指向正确的来源。
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 非交互式安装
|
||||
title: "非交互式安装"
|
||||
description: 使用命令行标志安装 BMad,适用于 CI/CD 流水线和自动化部署
|
||||
sidebar:
|
||||
order: 2
|
||||
|
|
@ -132,8 +132,8 @@ sections_completed: ['technology_stack', 'critical_rules']
|
|||
|
||||
## 后续步骤
|
||||
|
||||
- [**项目上下文说明**](../explanation/project-context_cn.md) — 了解其工作原理
|
||||
- [**工作流程图**](../reference/workflow-map_cn.md) — 查看哪些工作流程加载项目上下文
|
||||
- [**项目上下文说明**](../explanation/project-context.md) — 了解其工作原理
|
||||
- [**工作流程图**](../reference/workflow-map.md) — 查看哪些工作流程加载项目上下文
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
|
@ -115,7 +115,7 @@ DEV 智能体也适用于探索不熟悉的代码。在新的聊天中加载它
|
|||
|
||||
## 何时升级到正式规划
|
||||
|
||||
在以下情况下考虑使用 [Quick Flow](../explanation/quick-flow_cn.md) 或完整的 BMad Method:
|
||||
在以下情况下考虑使用 [Quick Flow](../explanation/quick-flow.md) 或完整的 BMad Method:
|
||||
|
||||
- 更改影响多个系统或需要在许多文件中进行协调更新
|
||||
- 你不确定范围,需要规范来理清思路
|
||||
|
|
@ -22,7 +22,7 @@ sidebar:
|
|||
|
||||
### 1. 运行安装程序
|
||||
|
||||
按照[安装程序说明](./install-bmad_cn.md)操作。
|
||||
按照[安装程序说明](./install-bmad.md)操作。
|
||||
|
||||
### 2. 处理旧版安装
|
||||
|
||||
|
|
@ -15,11 +15,11 @@ BMad 方法(**B**reakthrough **M**ethod of **A**gile AI **D**riven Development
|
|||
|
||||
理解 BMad 的最快方式是亲自尝试。
|
||||
|
||||
- **[BMad 入门指南](./tutorials/getting-started_cn.md)** — 安装并了解 BMad 的工作原理
|
||||
- **[工作流地图](./reference/workflow-map_cn.md)** — BMM 阶段、工作流和上下文管理的可视化概览
|
||||
- **[BMad 入门指南](./tutorials/getting-started.md)** — 安装并了解 BMad 的工作原理
|
||||
- **[工作流地图](./reference/workflow-map.md)** — BMM 阶段、工作流和上下文管理的可视化概览
|
||||
|
||||
:::tip[只想直接上手?]
|
||||
安装 BMad 并运行 `/bmad-help` — 它会根据您的项目和已安装的模块引导您完成所有操作。
|
||||
安装 BMad 并运行 `bmad-help` — 它会根据您的项目和已安装的模块引导您完成所有操作。
|
||||
:::
|
||||
|
||||
## 如何使用本文档
|
||||
|
|
@ -57,7 +57,7 @@ BMad 可与任何支持自定义系统提示词或项目上下文的 AI 编码
|
|||
|
||||
## 下一步
|
||||
|
||||
准备开始了吗?**[BMad 入门指南](./tutorials/getting-started_cn.md)** 并构建您的第一个项目。
|
||||
准备开始了吗?**[BMad 入门指南](./tutorials/getting-started.md)** 并构建您的第一个项目。
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 智能体
|
||||
title: "智能体"
|
||||
description: 默认 BMM 智能体及其菜单触发器和主要工作流
|
||||
sidebar:
|
||||
order: 2
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 命令
|
||||
title: "命令"
|
||||
description: BMad 斜杠命令参考——它们是什么、如何工作以及在哪里找到它们。
|
||||
sidebar:
|
||||
order: 3
|
||||
|
|
@ -13,7 +13,7 @@ BMad 提供两种开始工作的方式,它们服务于不同的目的。
|
|||
|
||||
| 机制 | 调用方式 | 发生什么 |
|
||||
| --- | --- | --- |
|
||||
| **斜杠命令** | 在 IDE 中输入 `/bmad-...` | 直接加载智能体、运行工作流或执行任务 |
|
||||
| **斜杠命令** | 在 IDE 中输入 `bmad-...` | 直接加载智能体、运行工作流或执行任务 |
|
||||
| **智能体菜单触发器** | 先加载智能体,然后输入简短代码(例如 `DS`) | 智能体解释代码并启动匹配的工作流,同时保持角色设定 |
|
||||
|
||||
智能体菜单触发器需要活动的智能体会话。当您知道要使用哪个工作流时,使用斜杠命令。当您已经与智能体一起工作并希望在不离开对话的情况下切换任务时,使用触发器。
|
||||
|
|
@ -58,13 +58,13 @@ BMad 提供两种开始工作的方式,它们服务于不同的目的。
|
|||
└── ...
|
||||
```
|
||||
|
||||
文件名决定了 IDE 中的斜杠命令名称。例如,文件 `bmad-agent-bmm-dev.md` 注册命令 `/bmad-agent-bmm-dev`。
|
||||
文件名决定了 IDE 中的技能名称。例如,文件 `bmad-agent-bmm-dev.md` 注册技能 `bmad-agent-bmm-dev`。
|
||||
|
||||
## 如何发现您的命令
|
||||
|
||||
在 IDE 中输入 `/bmad` 并使用自动完成功能浏览可用命令。
|
||||
|
||||
运行 `/bmad-help` 获取关于下一步的上下文感知指导。
|
||||
运行 `bmad-help` 获取关于下一步的上下文感知指导。
|
||||
|
||||
:::tip[快速发现]
|
||||
项目中生成的命令文件夹是权威列表。在文件资源管理器中打开它们以查看每个命令及其描述。
|
||||
|
|
@ -78,12 +78,12 @@ BMad 提供两种开始工作的方式,它们服务于不同的目的。
|
|||
|
||||
| 示例命令 | 智能体 | 角色 |
|
||||
| --- | --- | --- |
|
||||
| `/bmad-agent-bmm-dev` | Amelia(开发者) | 严格按照规范实现故事 |
|
||||
| `/bmad-agent-bmm-pm` | John(产品经理) | 创建和验证 PRD |
|
||||
| `/bmad-agent-bmm-architect` | Winston(架构师) | 设计系统架构 |
|
||||
| `/bmad-agent-bmm-sm` | Bob(Scrum Master) | 管理冲刺和故事 |
|
||||
| `bmad-agent-bmm-dev` | Amelia(开发者) | 严格按照规范实现故事 |
|
||||
| `bmad-agent-bmm-pm` | John(产品经理) | 创建和验证 PRD |
|
||||
| `bmad-agent-bmm-architect` | Winston(架构师) | 设计系统架构 |
|
||||
| `bmad-agent-bmm-sm` | Bob(Scrum Master) | 管理冲刺和故事 |
|
||||
|
||||
参见[智能体](./agents_cn.md)获取默认智能体及其触发器的完整列表。
|
||||
参见[智能体](./agents.md)获取默认智能体及其触发器的完整列表。
|
||||
|
||||
### 工作流命令
|
||||
|
||||
|
|
@ -91,13 +91,13 @@ BMad 提供两种开始工作的方式,它们服务于不同的目的。
|
|||
|
||||
| 示例命令 | 目的 |
|
||||
| --- | --- |
|
||||
| `/bmad-bmm-create-prd` | 创建产品需求文档 |
|
||||
| `/bmad-bmm-create-architecture` | 设计系统架构 |
|
||||
| `/bmad-bmm-dev-story` | 实现故事 |
|
||||
| `/bmad-bmm-code-review` | 运行代码审查 |
|
||||
| `/bmad-bmm-quick-spec` | 定义临时更改(快速流程) |
|
||||
| `bmad-bmm-create-prd` | 创建产品需求文档 |
|
||||
| `bmad-bmm-create-architecture` | 设计系统架构 |
|
||||
| `bmad-bmm-dev-story` | 实现故事 |
|
||||
| `bmad-bmm-code-review` | 运行代码审查 |
|
||||
| `bmad-bmm-quick-spec` | 定义临时更改(快速流程) |
|
||||
|
||||
参见[工作流地图](./workflow-map_cn.md)获取按阶段组织的完整工作流参考。
|
||||
参见[工作流地图](./workflow-map.md)获取按阶段组织的完整工作流参考。
|
||||
|
||||
### 任务和工具命令
|
||||
|
||||
|
|
@ -105,7 +105,7 @@ BMad 提供两种开始工作的方式,它们服务于不同的目的。
|
|||
|
||||
#### BMad-Help:您的智能向导
|
||||
|
||||
**`/bmad-help`** 是您发现下一步操作的主要界面。它不仅仅是一个查找工具——它是一个智能助手,可以:
|
||||
**`bmad-help`** 是您发现下一步操作的主要界面。它不仅仅是一个查找工具——它是一个智能助手,可以:
|
||||
|
||||
- **检查您的项目**以查看已经完成的工作
|
||||
- **理解自然语言查询**——用简单的英语提问
|
||||
|
|
@ -116,19 +116,19 @@ BMad 提供两种开始工作的方式,它们服务于不同的目的。
|
|||
**示例:**
|
||||
|
||||
```
|
||||
/bmad-help
|
||||
/bmad-help 我有一个 SaaS 想法并且知道所有功能。我应该从哪里开始?
|
||||
/bmad-help 我在 UX 设计方面有哪些选择?
|
||||
/bmad-help 我在 PRD 工作流上卡住了
|
||||
bmad-help
|
||||
bmad-help 我有一个 SaaS 想法并且知道所有功能。我应该从哪里开始?
|
||||
bmad-help 我在 UX 设计方面有哪些选择?
|
||||
bmad-help 我在 PRD 工作流上卡住了
|
||||
```
|
||||
|
||||
#### 其他任务和工具
|
||||
|
||||
| 示例命令 | 目的 |
|
||||
| --- | --- |
|
||||
| `/bmad-shard-doc` | 将大型 Markdown 文件拆分为较小的部分 |
|
||||
| `/bmad-index-docs` | 索引项目文档 |
|
||||
| `/bmad-editorial-review-prose` | 审查文档散文质量 |
|
||||
| `bmad-shard-doc` | 将大型 Markdown 文件拆分为较小的部分 |
|
||||
| `bmad-index-docs` | 索引项目文档 |
|
||||
| `bmad-editorial-review-prose` | 审查文档散文质量 |
|
||||
|
||||
## 命名约定
|
||||
|
||||
|
|
@ -140,7 +140,7 @@ BMad 提供两种开始工作的方式,它们服务于不同的目的。
|
|||
| `bmad-<module>-<workflow>` | 工作流命令 | `bmad-bmm-create-prd` |
|
||||
| `bmad-<name>` | 核心任务或工具 | `bmad-help` |
|
||||
|
||||
模块代码:`bmm`(敏捷套件)、`bmb`(构建器)、`tea`(测试架构师)、`cis`(创意智能)、`gds`(游戏开发工作室)。参见[模块](./modules_cn.md)获取描述。
|
||||
模块代码:`bmm`(敏捷套件)、`bmb`(构建器)、`tea`(测试架构师)、`cis`(创意智能)、`gds`(游戏开发工作室)。参见[模块](./modules.md)获取描述。
|
||||
|
||||
## 故障排除
|
||||
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 官方模块
|
||||
title: "官方模块"
|
||||
description: 用于构建自定义智能体、创意智能、游戏开发和测试的附加模块
|
||||
sidebar:
|
||||
order: 4
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 测试选项
|
||||
title: "测试选项"
|
||||
description: 比较内置 QA 智能体(Quinn)与测试架构师(TEA)模块的测试自动化。
|
||||
sidebar:
|
||||
order: 5
|
||||
|
|
@ -103,7 +103,7 @@ Quinn 的 Automate 工作流出现在 BMad 方法工作流图的第 4 阶段(
|
|||
|
||||
Quinn 直接从源代码工作,无需加载规划文档(PRD、架构)。TEA 工作流可以与上游规划产物集成以实现可追溯性。
|
||||
|
||||
有关测试在整体流程中的位置,请参阅[工作流图](./workflow-map_cn.md)。
|
||||
有关测试在整体流程中的位置,请参阅[工作流图](./workflow-map.md)。
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
|
@ -9,7 +9,7 @@ BMad Method(BMM)是 BMad 生态系统中的一个模块,旨在遵循上下
|
|||
|
||||
其基本原理和概念来自敏捷方法论,这些方法论在整个行业中被广泛用作思维框架,并取得了巨大成功。
|
||||
|
||||
如果您在任何时候不确定该做什么,`/bmad-help` 命令将帮助您保持正轨或了解下一步该做什么。您也可以随时参考此文档以获取参考信息——但如果您已经安装了 BMad Method,`/bmad-help` 是完全交互式的,速度要快得多。此外,如果您正在使用扩展了 BMad Method 或添加了其他互补非扩展模块的不同模块——`/bmad-help` 会不断演进以了解所有可用内容,从而为您提供最佳即时建议。
|
||||
如果您在任何时候不确定该做什么,`bmad-help` 命令将帮助您保持正轨或了解下一步该做什么。您也可以随时参考此文档以获取参考信息——但如果您已经安装了 BMad Method,`bmad-help` 是完全交互式的,速度要快得多。此外,如果您正在使用扩展了 BMad Method 或添加了其他互补非扩展模块的不同模块——`bmad-help` 会不断演进以了解所有可用内容,从而为您提供最佳即时建议。
|
||||
|
||||
最后的重要说明:以下每个工作流程都可以通过斜杠命令直接使用您选择的工具运行,或者先加载智能体,然后使用智能体菜单中的条目来运行。
|
||||
|
||||
|
|
@ -84,9 +84,9 @@ BMad Method(BMM)是 BMad 生态系统中的一个模块,旨在遵循上下
|
|||
**如何创建它:**
|
||||
|
||||
- **手动** — 使用您的技术栈和实施规则创建 `_bmad-output/project-context.md`
|
||||
- **生成它** — 运行 `/bmad-bmm-generate-project-context` 以从您的架构或代码库自动生成
|
||||
- **生成它** — 运行 `bmad-bmm-generate-project-context` 以从您的架构或代码库自动生成
|
||||
|
||||
[**了解更多关于 project-context.md**](../explanation/project-context_cn.md)
|
||||
[**了解更多关于 project-context.md**](../explanation/project-context.md)
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
|
@ -22,7 +22,7 @@ description: 安装 BMad 并构建你的第一个项目
|
|||
|
||||
:::tip[最简单的路径]
|
||||
**安装** → `npx bmad-method install`
|
||||
**询问** → `/bmad-help 我应该先做什么?`
|
||||
**询问** → `bmad-help 我应该先做什么?`
|
||||
**构建** → 让 BMad-Help 逐个工作流地引导你
|
||||
:::
|
||||
|
||||
|
|
@ -40,13 +40,13 @@ description: 安装 BMad 并构建你的第一个项目
|
|||
只需在 AI IDE 中使用斜杠命令运行它:
|
||||
|
||||
```
|
||||
/bmad-help
|
||||
bmad-help
|
||||
```
|
||||
|
||||
或者结合问题以获得上下文感知的指导:
|
||||
|
||||
```
|
||||
/bmad-help 我有一个 SaaS 产品的想法,我已经知道我想要的所有功能。我应该从哪里开始?
|
||||
bmad-help 我有一个 SaaS 产品的想法,我已经知道我想要的所有功能。我应该从哪里开始?
|
||||
```
|
||||
|
||||
BMad-Help 将回应:
|
||||
|
|
@ -59,7 +59,7 @@ BMad-Help 将回应:
|
|||
BMad-Help 不仅回答问题 —— **它会在每个工作流结束时自动运行**,告诉你确切地下一步该做什么。无需猜测,无需搜索文档 —— 只需对下一个必需工作流的清晰指导。
|
||||
|
||||
:::tip[从这里开始]
|
||||
安装 BMad 后,立即运行 `/bmad-help`。它将检测你安装了哪些模块,并引导你找到项目的正确起点。
|
||||
安装 BMad 后,立即运行 `bmad-help`。它将检测你安装了哪些模块,并引导你找到项目的正确起点。
|
||||
:::
|
||||
|
||||
## 了解 BMad
|
||||
|
|
@ -73,7 +73,7 @@ BMad 通过带有专门 AI 智能体的引导工作流帮助你构建软件。
|
|||
| 3 | 解决方案设计 | 设计架构 *(仅限 BMad Method/Enterprise only)* |
|
||||
| 4 | 实现 | 逐个史诗、逐个故事地构建 |
|
||||
|
||||
**[打开工作流地图](../reference/workflow-map_cn.md)** 以探索阶段、工作流和上下文管理。
|
||||
**[打开工作流地图](../reference/workflow-map.md)** 以探索阶段、工作流和上下文管理。
|
||||
|
||||
根据项目的复杂性,BMad 提供三种规划路径:
|
||||
|
||||
|
|
@ -105,14 +105,14 @@ npx bmad-method install
|
|||
在项目文件夹中打开你的 AI IDE 并运行:
|
||||
|
||||
```
|
||||
/bmad-help
|
||||
bmad-help
|
||||
```
|
||||
|
||||
BMad-Help 将检测你已完成的内容,并准确推荐下一步该做什么。你也可以问它诸如"我的选项是什么?"或"我有一个 SaaS 想法,我应该从哪里开始?"之类的问题。
|
||||
:::
|
||||
|
||||
:::note[如何加载智能体和运行工作流]
|
||||
每个工作流都有一个你在 IDE 中运行的**斜杠命令**(例如 `/bmad-bmm-create-prd`)。运行工作流命令会自动加载相应的智能体 —— 你不需要单独加载智能体。你也可以直接加载智能体进行一般对话(例如,加载 PM 智能体使用 `/bmad-agent-bmm-pm`)。
|
||||
每个工作流都有一个你在 IDE 中运行的**斜杠命令**(例如 `bmad-bmm-create-prd`)。运行工作流命令会自动加载相应的智能体 —— 你不需要单独加载智能体。你也可以直接加载智能体进行一般对话(例如,加载 PM 智能体使用 `bmad-agent-bmm-pm`)。
|
||||
:::
|
||||
|
||||
:::caution[新对话]
|
||||
|
|
@ -126,35 +126,35 @@ BMad-Help 将检测你已完成的内容,并准确推荐下一步该做什么
|
|||
:::tip[项目上下文(可选)]
|
||||
在开始之前,考虑创建 `project-context.md` 来记录你的技术偏好和实现规则。这确保所有 AI 智能体在整个项目中遵循你的约定。
|
||||
|
||||
在 `_bmad-output/project-context.md` 手动创建它,或在架构之后使用 `/bmad-bmm-generate-project-context` 生成它。[了解更多](../explanation/project-context_cn.md)。
|
||||
在 `_bmad-output/project-context.md` 手动创建它,或在架构之后使用 `bmad-bmm-generate-project-context` 生成它。[了解更多](../explanation/project-context.md)。
|
||||
:::
|
||||
|
||||
### 阶段 1:分析(可选)
|
||||
|
||||
此阶段中的所有工作流都是可选的:
|
||||
- **头脑风暴**(`/bmad-brainstorming`) — 引导式构思
|
||||
- **研究**(`/bmad-bmm-research`) — 市场和技术研究
|
||||
- **创建产品简报**(`/bmad-bmm-create-product-brief`) — 推荐的基础文档
|
||||
- **头脑风暴**(`bmad-brainstorming`) — 引导式构思
|
||||
- **研究**(`bmad-bmm-research`) — 市场和技术研究
|
||||
- **创建产品简报**(`bmad-bmm-create-product-brief`) — 推荐的基础文档
|
||||
|
||||
### 阶段 2:规划(必需)
|
||||
|
||||
**对于 BMad Method 和 Enterprise 路径:**
|
||||
1. 在新对话中加载 **PM 智能体**(`/bmad-agent-bmm-pm`)
|
||||
2. 运行 `prd` 工作流(`/bmad-bmm-create-prd`)
|
||||
1. 在新对话中加载 **PM 智能体**(`bmad-agent-bmm-pm`)
|
||||
2. 运行 `prd` 工作流(`bmad-bmm-create-prd`)
|
||||
3. 输出:`PRD.md`
|
||||
|
||||
**对于 Quick Flow 路径:**
|
||||
- 使用 `quick-spec` 工作流(`/bmad-bmm-quick-spec`)代替 PRD,然后跳转到实现
|
||||
- 使用 `quick-spec` 工作流(`bmad-bmm-quick-spec`)代替 PRD,然后跳转到实现
|
||||
|
||||
:::note[UX 设计(可选)]
|
||||
如果你的项目有用户界面,在创建 PRD 后加载 **UX-Designer 智能体**(`/bmad-agent-bmm-ux-designer`)并运行 UX 设计工作流(`/bmad-bmm-create-ux-design`)。
|
||||
如果你的项目有用户界面,在创建 PRD 后加载 **UX-Designer 智能体**(`bmad-agent-bmm-ux-designer`)并运行 UX 设计工作流(`bmad-bmm-create-ux-design`)。
|
||||
:::
|
||||
|
||||
### 阶段 3:解决方案设计(BMad Method/Enterprise)
|
||||
|
||||
**创建架构**
|
||||
1. 在新对话中加载 **Architect 智能体**(`/bmad-agent-bmm-architect`)
|
||||
2. 运行 `create-architecture`(`/bmad-bmm-create-architecture`)
|
||||
1. 在新对话中加载 **Architect 智能体**(`bmad-agent-bmm-architect`)
|
||||
2. 运行 `create-architecture`(`bmad-bmm-create-architecture`)
|
||||
3. 输出:包含技术决策的架构文档
|
||||
|
||||
**创建史诗和故事**
|
||||
|
|
@ -163,13 +163,13 @@ BMad-Help 将检测你已完成的内容,并准确推荐下一步该做什么
|
|||
史诗和故事现在在架构*之后*创建。这会产生更高质量的故事,因为架构决策(数据库、API 模式、技术栈)直接影响工作应该如何分解。
|
||||
:::
|
||||
|
||||
1. 在新对话中加载 **PM 智能体**(`/bmad-agent-bmm-pm`)
|
||||
2. 运行 `create-epics-and-stories`(`/bmad-bmm-create-epics-and-stories`)
|
||||
1. 在新对话中加载 **PM 智能体**(`bmad-agent-bmm-pm`)
|
||||
2. 运行 `create-epics-and-stories`(`bmad-bmm-create-epics-and-stories`)
|
||||
3. 工作流使用 PRD 和架构来创建技术信息丰富的故事
|
||||
|
||||
**实现就绪检查** *(强烈推荐)*
|
||||
1. 在新对话中加载 **Architect 智能体**(`/bmad-agent-bmm-architect`)
|
||||
2. 运行 `check-implementation-readiness`(`/bmad-bmm-check-implementation-readiness`)
|
||||
1. 在新对话中加载 **Architect 智能体**(`bmad-agent-bmm-architect`)
|
||||
2. 运行 `check-implementation-readiness`(`bmad-bmm-check-implementation-readiness`)
|
||||
3. 验证所有规划文档之间的一致性
|
||||
|
||||
## 步骤 2:构建你的项目
|
||||
|
|
@ -178,7 +178,7 @@ BMad-Help 将检测你已完成的内容,并准确推荐下一步该做什么
|
|||
|
||||
### 初始化冲刺规划
|
||||
|
||||
加载 **SM 智能体**(`/bmad-agent-bmm-sm`)并运行 `sprint-planning`(`/bmad-bmm-sprint-planning`)。这将创建 `sprint-status.yaml` 来跟踪所有史诗和故事。
|
||||
加载 **SM 智能体**(`bmad-agent-bmm-sm`)并运行 `sprint-planning`(`bmad-bmm-sprint-planning`)。这将创建 `sprint-status.yaml` 来跟踪所有史诗和故事。
|
||||
|
||||
### 构建周期
|
||||
|
||||
|
|
@ -186,11 +186,11 @@ BMad-Help 将检测你已完成的内容,并准确推荐下一步该做什么
|
|||
|
||||
| 步骤 | 智能体 | 工作流 | 命令 | 目的 |
|
||||
| ---- | ------ | ------------ | ----------------------- | ------------------------------- |
|
||||
| 1 | SM | `create-story` | `/bmad-bmm-create-story` | 从史诗创建故事文件 |
|
||||
| 2 | DEV | `dev-story` | `/bmad-bmm-dev-story` | 实现故事 |
|
||||
| 3 | DEV | `code-review` | `/bmad-bmm-code-review` | 质量验证 *(推荐)* |
|
||||
| 1 | SM | `create-story` | `bmad-bmm-create-story` | 从史诗创建故事文件 |
|
||||
| 2 | DEV | `dev-story` | `bmad-bmm-dev-story` | 实现故事 |
|
||||
| 3 | DEV | `code-review` | `bmad-bmm-code-review` | 质量验证 *(推荐)* |
|
||||
|
||||
完成史诗中的所有故事后,加载 **SM 智能体**(`/bmad-agent-bmm-sm`)并运行 `retrospective`(`/bmad-bmm-retrospective`)。
|
||||
完成史诗中的所有故事后,加载 **SM 智能体**(`bmad-agent-bmm-sm`)并运行 `retrospective`(`bmad-bmm-retrospective`)。
|
||||
|
||||
## 你已完成的工作
|
||||
|
||||
|
|
@ -221,16 +221,16 @@ your-project/
|
|||
|
||||
| 工作流 | 命令 | 智能体 | 目的 |
|
||||
| ----------------------------------- | --------------------------------------- | -------- | -------------------------------------------- |
|
||||
| **`help`** ⭐ | `/bmad-help` | 任意 | **你的智能向导 —— 随时询问任何问题!** |
|
||||
| `prd` | `/bmad-bmm-create-prd` | PM | 创建产品需求文档 |
|
||||
| `create-architecture` | `/bmad-bmm-create-architecture` | Architect | 创建架构文档 |
|
||||
| `generate-project-context` | `/bmad-bmm-generate-project-context` | Analyst | 创建项目上下文文件 |
|
||||
| `create-epics-and-stories` | `/bmad-bmm-create-epics-and-stories` | PM | 将 PRD 分解为史诗 |
|
||||
| `check-implementation-readiness` | `/bmad-bmm-check-implementation-readiness` | Architect | 验证规划一致性 |
|
||||
| `sprint-planning` | `/bmad-bmm-sprint-planning` | SM | 初始化冲刺跟踪 |
|
||||
| `create-story` | `/bmad-bmm-create-story` | SM | 创建故事文件 |
|
||||
| `dev-story` | `/bmad-bmm-dev-story` | DEV | 实现故事 |
|
||||
| `code-review` | `/bmad-bmm-code-review` | DEV | 审查已实现的代码 |
|
||||
| **`help`** ⭐ | `bmad-help` | 任意 | **你的智能向导 —— 随时询问任何问题!** |
|
||||
| `prd` | `bmad-bmm-create-prd` | PM | 创建产品需求文档 |
|
||||
| `create-architecture` | `bmad-bmm-create-architecture` | Architect | 创建架构文档 |
|
||||
| `generate-project-context` | `bmad-bmm-generate-project-context` | Analyst | 创建项目上下文文件 |
|
||||
| `create-epics-and-stories` | `bmad-bmm-create-epics-and-stories` | PM | 将 PRD 分解为史诗 |
|
||||
| `check-implementation-readiness` | `bmad-bmm-check-implementation-readiness` | Architect | 验证规划一致性 |
|
||||
| `sprint-planning` | `bmad-bmm-sprint-planning` | SM | 初始化冲刺跟踪 |
|
||||
| `create-story` | `bmad-bmm-create-story` | SM | 创建故事文件 |
|
||||
| `dev-story` | `bmad-bmm-dev-story` | DEV | 实现故事 |
|
||||
| `code-review` | `bmad-bmm-code-review` | DEV | 审查已实现的代码 |
|
||||
|
||||
## 常见问题
|
||||
|
||||
|
|
@ -238,10 +238,10 @@ your-project/
|
|||
仅对于 BMad Method 和 Enterprise 路径。Quick Flow 从技术规范跳转到实现。
|
||||
|
||||
**我可以稍后更改我的计划吗?**
|
||||
可以。SM 智能体有一个 `correct-course` 工作流(`/bmad-bmm-correct-course`)用于处理范围变更。
|
||||
可以。SM 智能体有一个 `correct-course` 工作流(`bmad-bmm-correct-course`)用于处理范围变更。
|
||||
|
||||
**如果我想先进行头脑风暴怎么办?**
|
||||
在开始 PRD 之前,加载 Analyst 智能体(`/bmad-agent-bmm-analyst`)并运行 `brainstorming`(`/bmad-brainstorming`)。
|
||||
在开始 PRD 之前,加载 Analyst 智能体(`bmad-agent-bmm-analyst`)并运行 `brainstorming`(`bmad-brainstorming`)。
|
||||
|
||||
**我需要遵循严格的顺序吗?**
|
||||
不一定。一旦你了解了流程,你可以使用上面的快速参考直接运行工作流。
|
||||
|
|
@ -249,7 +249,7 @@ your-project/
|
|||
## 获取帮助
|
||||
|
||||
:::tip[第一站:BMad-Help]
|
||||
**随时运行 `/bmad-help`** —— 这是摆脱困境的最快方式。问它任何问题:
|
||||
**随时运行 `bmad-help`** —— 这是摆脱困境的最快方式。问它任何问题:
|
||||
- "安装后我应该做什么?"
|
||||
- "我在工作流 X 上卡住了"
|
||||
- "我在 Y 方面有什么选项?"
|
||||
|
|
@ -264,13 +264,13 @@ BMad-Help 检查你的项目,检测你已完成的内容,并确切地告诉
|
|||
## 关键要点
|
||||
|
||||
:::tip[记住这些]
|
||||
- **从 `/bmad-help` 开始** — 你的智能向导,了解你的项目和选项
|
||||
- **从 `bmad-help` 开始** — 你的智能向导,了解你的项目和选项
|
||||
- **始终使用新对话** — 为每个工作流开始新对话
|
||||
- **路径很重要** — Quick Flow 使用 quick-spec;Method/Enterprise 需要 PRD 和架构
|
||||
- **BMad-Help 自动运行** — 每个工作流结束时都会提供下一步的指导
|
||||
:::
|
||||
|
||||
准备好开始了吗?安装 BMad,运行 `/bmad-help`,让你的智能向导为你引路。
|
||||
准备好开始了吗?安装 BMad,运行 `bmad-help`,让你的智能向导为你引路。
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
|
@ -15,7 +15,6 @@
|
|||
"chalk": "^4.1.2",
|
||||
"commander": "^14.0.0",
|
||||
"csv-parse": "^6.1.0",
|
||||
"fs-extra": "^11.3.0",
|
||||
"glob": "^11.0.3",
|
||||
"ignore": "^7.0.5",
|
||||
"js-yaml": "^4.1.0",
|
||||
|
|
@ -6996,20 +6995,6 @@
|
|||
"url": "https://github.com/sponsors/isaacs"
|
||||
}
|
||||
},
|
||||
"node_modules/fs-extra": {
|
||||
"version": "11.3.3",
|
||||
"resolved": "https://registry.npmjs.org/fs-extra/-/fs-extra-11.3.3.tgz",
|
||||
"integrity": "sha512-VWSRii4t0AFm6ixFFmLLx1t7wS1gh+ckoa84aOeapGum0h+EZd1EhEumSB+ZdDLnEPuucsVB9oB7cxJHap6Afg==",
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"graceful-fs": "^4.2.0",
|
||||
"jsonfile": "^6.0.1",
|
||||
"universalify": "^2.0.0"
|
||||
},
|
||||
"engines": {
|
||||
"node": ">=14.14"
|
||||
}
|
||||
},
|
||||
"node_modules/fs.realpath": {
|
||||
"version": "1.0.0",
|
||||
"resolved": "https://registry.npmjs.org/fs.realpath/-/fs.realpath-1.0.0.tgz",
|
||||
|
|
@ -7227,6 +7212,7 @@
|
|||
"version": "4.2.11",
|
||||
"resolved": "https://registry.npmjs.org/graceful-fs/-/graceful-fs-4.2.11.tgz",
|
||||
"integrity": "sha512-RbJ5/jmFcNNCcDV5o9eTnBLJ/HszWV0P73bc+Ff4nS/rJj+YaS6IGyiOL0VoBYX+l1Wrl3k63h/KrH+nhJ0XvQ==",
|
||||
"dev": true,
|
||||
"license": "ISC"
|
||||
},
|
||||
"node_modules/h3": {
|
||||
|
|
@ -9066,18 +9052,6 @@
|
|||
"dev": true,
|
||||
"license": "MIT"
|
||||
},
|
||||
"node_modules/jsonfile": {
|
||||
"version": "6.2.0",
|
||||
"resolved": "https://registry.npmjs.org/jsonfile/-/jsonfile-6.2.0.tgz",
|
||||
"integrity": "sha512-FGuPw30AdOIUTRMC2OMRtQV+jkVj2cfPqSeWXv1NEAJ1qZ5zb1X6z1mFhbfOB/iy3ssJCD+3KuZ8r8C3uVFlAg==",
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"universalify": "^2.0.0"
|
||||
},
|
||||
"optionalDependencies": {
|
||||
"graceful-fs": "^4.1.6"
|
||||
}
|
||||
},
|
||||
"node_modules/katex": {
|
||||
"version": "0.16.28",
|
||||
"resolved": "https://registry.npmjs.org/katex/-/katex-0.16.28.tgz",
|
||||
|
|
@ -13607,15 +13581,6 @@
|
|||
"url": "https://opencollective.com/unified"
|
||||
}
|
||||
},
|
||||
"node_modules/universalify": {
|
||||
"version": "2.0.1",
|
||||
"resolved": "https://registry.npmjs.org/universalify/-/universalify-2.0.1.tgz",
|
||||
"integrity": "sha512-gptHNQghINnc/vTGIk0SOFGFNXw7JVrlRUtConJRlvaw6DuX0wO5Jeko9sWrMBhh+PsYAZ7oXAiOnf/UKogyiw==",
|
||||
"license": "MIT",
|
||||
"engines": {
|
||||
"node": ">= 10.0.0"
|
||||
}
|
||||
},
|
||||
"node_modules/unrs-resolver": {
|
||||
"version": "1.11.1",
|
||||
"resolved": "https://registry.npmjs.org/unrs-resolver/-/unrs-resolver-1.11.1.tgz",
|
||||
|
|
|
|||
|
|
@ -40,8 +40,9 @@
|
|||
"lint:md": "markdownlint-cli2 \"**/*.md\"",
|
||||
"prepare": "command -v husky >/dev/null 2>&1 && husky || exit 0",
|
||||
"rebundle": "node tools/cli/bundlers/bundle-web.js rebundle",
|
||||
"test": "npm run test:schemas && npm run test:refs && npm run test:install && npm run validate:schemas && npm run lint && npm run lint:md && npm run format:check",
|
||||
"test": "npm run test:schemas && npm run test:refs && npm run test:install && npm run test:fs && npm run validate:schemas && npm run lint && npm run lint:md && npm run format:check",
|
||||
"test:coverage": "c8 --reporter=text --reporter=html npm run test:schemas",
|
||||
"test:fs": "node test/test-fs-wrapper.js",
|
||||
"test:install": "node test/test-installation-components.js",
|
||||
"test:refs": "node test/test-file-refs-csv.js",
|
||||
"test:schemas": "node test/test-agent-schema.js",
|
||||
|
|
@ -71,7 +72,6 @@
|
|||
"chalk": "^4.1.2",
|
||||
"commander": "^14.0.0",
|
||||
"csv-parse": "^6.1.0",
|
||||
"fs-extra": "^11.3.0",
|
||||
"glob": "^11.0.3",
|
||||
"ignore": "^7.0.5",
|
||||
"js-yaml": "^4.1.0",
|
||||
|
|
|
|||
|
|
@ -39,5 +39,5 @@ agent:
|
|||
description: "[CB] Create Brief: A guided experience to nail down your product idea into an executive brief"
|
||||
|
||||
- trigger: DP or fuzzy match on document-project
|
||||
workflow: "{project-root}/_bmad/bmm/workflows/document-project/workflow.yaml"
|
||||
exec: "{project-root}/_bmad/bmm/workflows/document-project/workflow.md"
|
||||
description: "[DP] Document Project: Analyze an existing project to produce useful documentation for both human and LLM"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,39 @@
|
|||
analyst.agent.yaml:
|
||||
canonicalId: bmad-analyst
|
||||
type: agent
|
||||
description: "Business Analyst for market research, competitive analysis, and requirements elicitation"
|
||||
|
||||
architect.agent.yaml:
|
||||
canonicalId: bmad-architect
|
||||
type: agent
|
||||
description: "Architect for distributed systems, cloud infrastructure, and API design"
|
||||
|
||||
dev.agent.yaml:
|
||||
canonicalId: bmad-dev
|
||||
type: agent
|
||||
description: "Developer Agent for story execution, test-driven development, and code implementation"
|
||||
|
||||
pm.agent.yaml:
|
||||
canonicalId: bmad-pm
|
||||
type: agent
|
||||
description: "Product Manager for PRD creation, requirements discovery, and stakeholder alignment"
|
||||
|
||||
qa.agent.yaml:
|
||||
canonicalId: bmad-qa
|
||||
type: agent
|
||||
description: "QA Engineer for test automation, API testing, and E2E testing"
|
||||
|
||||
quick-flow-solo-dev.agent.yaml:
|
||||
canonicalId: bmad-quick-flow-solo-dev
|
||||
type: agent
|
||||
description: "Quick Flow Solo Dev for rapid spec creation and lean implementation"
|
||||
|
||||
sm.agent.yaml:
|
||||
canonicalId: bmad-sm
|
||||
type: agent
|
||||
description: "Scrum Master for sprint planning, story preparation, and agile ceremonies"
|
||||
|
||||
ux-designer.agent.yaml:
|
||||
canonicalId: bmad-ux-designer
|
||||
type: agent
|
||||
description: "UX Designer for user research, interaction design, and UI patterns"
|
||||
|
|
@ -30,9 +30,9 @@ agent:
|
|||
|
||||
menu:
|
||||
- trigger: DS or fuzzy match on dev-story
|
||||
workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/dev-story/workflow.yaml"
|
||||
exec: "{project-root}/_bmad/bmm/workflows/4-implementation/dev-story/workflow.md"
|
||||
description: "[DS] Dev Story: Write the next or specified stories tests and code."
|
||||
|
||||
- trigger: CR or fuzzy match on code-review
|
||||
workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/code-review/workflow.yaml"
|
||||
exec: "{project-root}/_bmad/bmm/workflows/4-implementation/code-review/workflow.md"
|
||||
description: "[CR] Code Review: Initiate a comprehensive code review across multiple quality facets. For best results, use a fresh context and a different quality LLM if available"
|
||||
|
|
|
|||
|
|
@ -40,5 +40,5 @@ agent:
|
|||
description: "[IR] Implementation Readiness: Ensure the PRD, UX, and Architecture and Epics and Stories List are all aligned"
|
||||
|
||||
- trigger: CC or fuzzy match on correct-course
|
||||
workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml"
|
||||
exec: "{project-root}/_bmad/bmm/workflows/4-implementation/correct-course/workflow.md"
|
||||
description: "[CC] Course Correction: Use this so we can determine how to proceed if major need for change is discovered mid implementation"
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ agent:
|
|||
|
||||
menu:
|
||||
- trigger: QA or fuzzy match on qa-automate
|
||||
workflow: "{project-root}/_bmad/bmm/workflows/qa-generate-e2e-tests/workflow.yaml"
|
||||
exec: "{project-root}/_bmad/bmm/workflows/qa-generate-e2e-tests/workflow.md"
|
||||
description: "[QA] Automate - Generate tests for existing features (simplified)"
|
||||
|
||||
prompts:
|
||||
|
|
|
|||
|
|
@ -27,10 +27,10 @@ agent:
|
|||
exec: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md"
|
||||
description: "[QD] Quick-flow Develop: Implement a story tech spec end-to-end (Core of Quick Flow)"
|
||||
|
||||
- trigger: QQ or fuzzy match on quick-dev-new-preview
|
||||
exec: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/workflow.md"
|
||||
- trigger: QQ or fuzzy match on bmad-quick-dev-new-preview
|
||||
exec: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/workflow.md"
|
||||
description: "[QQ] Quick Dev New (Preview): Unified quick flow — clarify intent, plan, implement, review, present (experimental)"
|
||||
|
||||
- trigger: CR or fuzzy match on code-review
|
||||
workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/code-review/workflow.yaml"
|
||||
exec: "{project-root}/_bmad/bmm/workflows/4-implementation/code-review/workflow.md"
|
||||
description: "[CR] Code Review: Initiate a comprehensive code review across multiple quality facets. For best results, use a fresh context and a different quality LLM if available"
|
||||
|
|
|
|||
|
|
@ -20,18 +20,18 @@ agent:
|
|||
|
||||
menu:
|
||||
- trigger: SP or fuzzy match on sprint-planning
|
||||
workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/sprint-planning/workflow.yaml"
|
||||
exec: "{project-root}/_bmad/bmm/workflows/4-implementation/sprint-planning/workflow.md"
|
||||
description: "[SP] Sprint Planning: Generate or update the record that will sequence the tasks to complete the full project that the dev agent will follow"
|
||||
|
||||
- trigger: CS or fuzzy match on create-story
|
||||
workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/create-story/workflow.yaml"
|
||||
exec: "{project-root}/_bmad/bmm/workflows/4-implementation/create-story/workflow.md"
|
||||
description: "[CS] Context Story: Prepare a story with all required context for implementation for the developer agent"
|
||||
|
||||
- trigger: ER or fuzzy match on epic-retrospective
|
||||
workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/retrospective/workflow.yaml"
|
||||
exec: "{project-root}/_bmad/bmm/workflows/4-implementation/retrospective/workflow.md"
|
||||
data: "{project-root}/_bmad/_config/agent-manifest.csv"
|
||||
description: "[ER] Epic Retrospective: Party Mode review of all work completed across an epic."
|
||||
|
||||
- trigger: CC or fuzzy match on correct-course
|
||||
workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml"
|
||||
exec: "{project-root}/_bmad/bmm/workflows/4-implementation/correct-course/workflow.md"
|
||||
description: "[CC] Course Correction: Use this so we can determine how to proceed if major need for change is discovered mid implementation"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,3 @@
|
|||
canonicalId: bmad-tech-writer
|
||||
type: agent
|
||||
description: "Technical Writer for documentation, Mermaid diagrams, and standards compliance"
|
||||
|
|
@ -22,7 +22,7 @@ agent:
|
|||
|
||||
menu:
|
||||
- trigger: DP or fuzzy match on document-project
|
||||
workflow: "{project-root}/_bmad/bmm/workflows/document-project/workflow.yaml"
|
||||
exec: "{project-root}/_bmad/bmm/workflows/document-project/workflow.md"
|
||||
description: "[DP] Document Project: Generate comprehensive project documentation (brownfield analysis, architecture scanning)"
|
||||
|
||||
- trigger: WD or fuzzy match on write-document
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,
|
||||
bmm,anytime,Document Project,DP,,_bmad/bmm/workflows/document-project/workflow.yaml,bmad-bmm-document-project,false,analyst,Create Mode,"Analyze an existing project to produce useful documentation",project-knowledge,*,
|
||||
bmm,anytime,Document Project,DP,,_bmad/bmm/workflows/document-project/workflow.md,bmad-bmm-document-project,false,analyst,Create Mode,"Analyze an existing project to produce useful documentation",project-knowledge,*,
|
||||
bmm,anytime,Generate Project Context,GPC,,_bmad/bmm/workflows/generate-project-context/workflow.md,bmad-bmm-generate-project-context,false,analyst,Create Mode,"Scan existing codebase to generate a lean LLM-optimized project-context.md containing critical implementation rules patterns and conventions for AI agents. Essential for brownfield projects and quick-flow.",output_folder,"project context",
|
||||
bmm,anytime,Quick Spec,QS,,_bmad/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md,bmad-bmm-quick-spec,false,quick-flow-solo-dev,Create Mode,"Do not suggest for potentially very complex things unless requested or if the user complains that they do not want to follow the extensive planning of the bmad method. Quick one-off tasks small changes simple apps brownfield additions to well established patterns utilities without extensive planning",planning_artifacts,"tech spec",
|
||||
bmm,anytime,Quick Dev,QD,,_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md,bmad-bmm-quick-dev,false,quick-flow-solo-dev,Create Mode,"Quick one-off tasks small changes simple apps utilities without extensive planning - Do not suggest for potentially very complex things unless requested or if the user complains that they do not want to follow the extensive planning of the bmad method, unless the user is already working through the implementation phase and just requests a 1 off things not already in the plan",,,
|
||||
bmm,anytime,Quick Dev New Preview,QQ,,_bmad/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/workflow.md,bmad-bmm-quick-dev-new-preview,false,quick-flow-solo-dev,Create Mode,"Unified quick flow (experimental): clarify intent plan implement review and present in a single workflow",implementation_artifacts,"tech spec implementation",
|
||||
bmm,anytime,Correct Course,CC,,_bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml,bmad-bmm-correct-course,false,sm,Create Mode,"Anytime: Navigate significant changes. May recommend start over update PRD redo architecture sprint planning or correct epics and stories",planning_artifacts,"change proposal",
|
||||
bmm,anytime,Quick Dev New Preview,QQ,,skill:bmad-quick-dev-new-preview,bmad-bmm-quick-dev-new-preview,false,quick-flow-solo-dev,Create Mode,"Unified quick flow (experimental): clarify intent plan implement review and present in a single workflow",implementation_artifacts,"tech spec implementation",
|
||||
bmm,anytime,Correct Course,CC,,_bmad/bmm/workflows/4-implementation/correct-course/workflow.md,bmad-bmm-correct-course,false,sm,Create Mode,"Anytime: Navigate significant changes. May recommend start over update PRD redo architecture sprint planning or correct epics and stories",planning_artifacts,"change proposal",
|
||||
bmm,anytime,Write Document,WD,,_bmad/bmm/agents/tech-writer/tech-writer.agent.yaml,,false,tech-writer,,"Describe in detail what you want, and the agent will follow the documentation best practices defined in agent memory. Multi-turn conversation with subprocess for research/review.",project-knowledge,"document",
|
||||
bmm,anytime,Update Standards,US,,_bmad/bmm/agents/tech-writer/tech-writer.agent.yaml,,false,tech-writer,,"Update agent memory documentation-standards.md with your specific preferences if you discover missing document conventions.",_bmad/_memory/tech-writer-sidecar,"standards",
|
||||
bmm,anytime,Mermaid Generate,MG,,_bmad/bmm/agents/tech-writer/tech-writer.agent.yaml,,false,tech-writer,,"Create a Mermaid diagram based on user description. Will suggest diagram types if not specified.",planning_artifacts,"mermaid diagram",
|
||||
|
|
@ -22,11 +22,11 @@ bmm,2-planning,Create UX,CU,30,_bmad/bmm/workflows/2-plan-workflows/create-ux-de
|
|||
bmm,3-solutioning,Create Architecture,CA,10,_bmad/bmm/workflows/3-solutioning/create-architecture/workflow.md,bmad-bmm-create-architecture,true,architect,Create Mode,"Guided Workflow to document technical decisions",planning_artifacts,architecture,
|
||||
bmm,3-solutioning,Create Epics and Stories,CE,30,_bmad/bmm/workflows/3-solutioning/create-epics-and-stories/workflow.md,bmad-bmm-create-epics-and-stories,true,pm,Create Mode,"Create the Epics and Stories Listing",planning_artifacts,"epics and stories",
|
||||
bmm,3-solutioning,Check Implementation Readiness,IR,70,_bmad/bmm/workflows/3-solutioning/check-implementation-readiness/workflow.md,bmad-bmm-check-implementation-readiness,true,architect,Validate Mode,"Ensure PRD UX Architecture and Epics Stories are aligned",planning_artifacts,"readiness report",
|
||||
bmm,4-implementation,Sprint Planning,SP,10,_bmad/bmm/workflows/4-implementation/sprint-planning/workflow.yaml,bmad-bmm-sprint-planning,true,sm,Create Mode,"Generate sprint plan for development tasks - this kicks off the implementation phase by producing a plan the implementation agents will follow in sequence for every story in the plan.",implementation_artifacts,"sprint status",
|
||||
bmm,4-implementation,Sprint Status,SS,20,_bmad/bmm/workflows/4-implementation/sprint-status/workflow.yaml,bmad-bmm-sprint-status,false,sm,Create Mode,"Anytime: Summarize sprint status and route to next workflow",,,
|
||||
bmm,4-implementation,Validate Story,VS,35,_bmad/bmm/workflows/4-implementation/create-story/workflow.yaml,bmad-bmm-create-story,false,sm,Validate Mode,"Validates story readiness and completeness before development work begins",implementation_artifacts,"story validation report",
|
||||
bmm,4-implementation,Create Story,CS,30,_bmad/bmm/workflows/4-implementation/create-story/workflow.yaml,bmad-bmm-create-story,true,sm,Create Mode,"Story cycle start: Prepare first found story in the sprint plan that is next, or if the command is run with a specific epic and story designation with context. Once complete, then VS then DS then CR then back to DS if needed or next CS or ER",implementation_artifacts,story,
|
||||
bmm,4-implementation,Dev Story,DS,40,_bmad/bmm/workflows/4-implementation/dev-story/workflow.yaml,bmad-bmm-dev-story,true,dev,Create Mode,"Story cycle: Execute story implementation tasks and tests then CR then back to DS if fixes needed",,,
|
||||
bmm,4-implementation,Code Review,CR,50,_bmad/bmm/workflows/4-implementation/code-review/workflow.yaml,bmad-bmm-code-review,false,dev,Create Mode,"Story cycle: If issues back to DS if approved then next CS or ER if epic complete",,,
|
||||
bmm,4-implementation,QA Automation Test,QA,45,_bmad/bmm/workflows/qa-generate-e2e-tests/workflow.yaml,bmad-bmm-qa-automate,false,qa,Create Mode,"Generate automated API and E2E tests for implemented code using the project's existing test framework (detects existing well known in use test frameworks). Use after implementation to add test coverage. NOT for code review or story validation - use CR for that.",implementation_artifacts,"test suite",
|
||||
bmm,4-implementation,Retrospective,ER,60,_bmad/bmm/workflows/4-implementation/retrospective/workflow.yaml,bmad-bmm-retrospective,false,sm,Create Mode,"Optional at epic end: Review completed work lessons learned and next epic or if major issues consider CC",implementation_artifacts,retrospective,
|
||||
bmm,4-implementation,Sprint Planning,SP,10,_bmad/bmm/workflows/4-implementation/sprint-planning/workflow.md,bmad-bmm-sprint-planning,true,sm,Create Mode,"Generate sprint plan for development tasks - this kicks off the implementation phase by producing a plan the implementation agents will follow in sequence for every story in the plan.",implementation_artifacts,"sprint status",
|
||||
bmm,4-implementation,Sprint Status,SS,20,_bmad/bmm/workflows/4-implementation/sprint-status/workflow.md,bmad-bmm-sprint-status,false,sm,Create Mode,"Anytime: Summarize sprint status and route to next workflow",,,
|
||||
bmm,4-implementation,Validate Story,VS,35,_bmad/bmm/workflows/4-implementation/create-story/workflow.md,bmad-bmm-create-story,false,sm,Validate Mode,"Validates story readiness and completeness before development work begins",implementation_artifacts,"story validation report",
|
||||
bmm,4-implementation,Create Story,CS,30,_bmad/bmm/workflows/4-implementation/create-story/workflow.md,bmad-bmm-create-story,true,sm,Create Mode,"Story cycle start: Prepare first found story in the sprint plan that is next, or if the command is run with a specific epic and story designation with context. Once complete, then VS then DS then CR then back to DS if needed or next CS or ER",implementation_artifacts,story,
|
||||
bmm,4-implementation,Dev Story,DS,40,_bmad/bmm/workflows/4-implementation/dev-story/workflow.md,bmad-bmm-dev-story,true,dev,Create Mode,"Story cycle: Execute story implementation tasks and tests then CR then back to DS if fixes needed",,,
|
||||
bmm,4-implementation,Code Review,CR,50,_bmad/bmm/workflows/4-implementation/code-review/workflow.md,bmad-bmm-code-review,false,dev,Create Mode,"Story cycle: If issues back to DS if approved then next CS or ER if epic complete",,,
|
||||
bmm,4-implementation,QA Automation Test,QA,45,_bmad/bmm/workflows/qa-generate-e2e-tests/workflow.md,bmad-bmm-qa-automate,false,qa,Create Mode,"Generate automated API and E2E tests for implemented code using the project's existing test framework (detects existing well known in use test frameworks). Use after implementation to add test coverage. NOT for code review or story validation - use CR for that.",implementation_artifacts,"test suite",
|
||||
bmm,4-implementation,Retrospective,ER,60,_bmad/bmm/workflows/4-implementation/retrospective/workflow.md,bmad-bmm-retrospective,false,sm,Create Mode,"Optional at epic end: Review completed work lessons learned and next epic or if major issues consider CC",implementation_artifacts,retrospective,
|
||||
|
|
|
|||
|
|
|
@ -0,0 +1,3 @@
|
|||
canonicalId: bmad-create-product-brief
|
||||
type: workflow
|
||||
description: "Create product brief through collaborative discovery"
|
||||
|
|
@ -7,7 +7,7 @@ nextStepFile: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brie
|
|||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ nextStepFile: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brie
|
|||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ nextStepFile: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brie
|
|||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ nextStepFile: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brie
|
|||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -128,7 +128,7 @@ Recap that the brief captures everything needed to guide subsequent product deve
|
|||
|
||||
### 5. Suggest next steps
|
||||
|
||||
Product Brief complete. Read fully and follow: `{project-root}/_bmad/core/tasks/help.md`
|
||||
Product Brief complete. Invoke the `bmad-help` skill.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,14 @@
|
|||
workflow-domain-research.md:
|
||||
canonicalId: bmad-domain-research
|
||||
type: workflow
|
||||
description: "Conduct domain and industry research. Use when the user says 'lets create a research report on [domain or industry]'"
|
||||
|
||||
workflow-market-research.md:
|
||||
canonicalId: bmad-market-research
|
||||
type: workflow
|
||||
description: "Conduct market research on competition and customers. Use when the user says 'create a market research report about [business idea]'"
|
||||
|
||||
workflow-technical-research.md:
|
||||
canonicalId: bmad-technical-research
|
||||
type: workflow
|
||||
description: "Conduct technical research on technologies and architecture. Use when the user says 'create a technical research report on [topic]'"
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
workflow-create-prd.md:
|
||||
canonicalId: bmad-create-prd
|
||||
type: workflow
|
||||
description: "Create a PRD from scratch. Use when the user says 'lets create a product requirements document' or 'I want to create a new PRD'"
|
||||
|
||||
workflow-edit-prd.md:
|
||||
canonicalId: bmad-edit-prd
|
||||
type: workflow
|
||||
description: "Edit an existing PRD. Use when the user says 'edit this PRD'"
|
||||
|
||||
workflow-validate-prd.md:
|
||||
canonicalId: bmad-validate-prd
|
||||
type: workflow
|
||||
description: "Validate a PRD against standards. Use when the user says 'validate this PRD' or 'run PRD validation'"
|
||||
|
|
@ -11,7 +11,7 @@ projectTypesCSV: '../data/project-types.csv'
|
|||
domainComplexityCSV: '../data/domain-complexity.csv'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue