mirror of
https://github.com/bmad-code-org/BMAD-METHOD.git
synced 2026-01-30 04:32:02 +00:00
docs: comprehensive style guide update with reference and glossary standards
Style Guide Additions: - Add Reference Structure section with 6 document types (Index, Catalog, Deep-Dive, Configuration, Glossary, Comprehensive) - Add Glossary Structure section with table-based format leveraging Starlight's right-nav for navigation - Include checklists for both new document types Reference Docs Updated: - agents/index.md: Catalog format, universal commands tip admonition - configuration/core-tasks.md: Configuration format with admonitions - configuration/global-config.md: Table-based config reference - workflows/index.md: Minimal index format - workflows/core-workflows.md: Catalog format - workflows/document-project.md: Deep-dive with Quick Facts admonition - workflows/bmgd-workflows.md: Comprehensive format, removed ~30 hr rules Glossary Rewritten: - Converted from 373 lines with ### headers to 123 lines with tables - Right nav now shows 9 categories instead of 50+ terms - Added italic context markers (*BMGD.*, *Brownfield.*, etc.) - Alphabetized terms within categories - Removed redundant inline TOC All Docs: - Remove horizontal rules (---) per style guide - Remove "Related" sections (sidebar handles navigation) - Standardize admonition usage - Archive deleted workflow customization docs Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
forcetrainer
@@ -3,10 +3,7 @@ title: "How to Add a Feature to an Existing Project"
|
||||
description: How to add new features to an existing brownfield project
|
||||
---
|
||||
|
||||
|
||||
Add new functionality to your brownfield codebase while respecting existing patterns and architecture.
|
||||
|
||||
---
|
||||
Use the `workflow-init` workflow to add new functionality to your brownfield codebase while respecting existing patterns and architecture.
|
||||
|
||||
## When to Use This
|
||||
|
||||
@@ -14,15 +11,11 @@ Add new functionality to your brownfield codebase while respecting existing patt
|
||||
- Major enhancements that need proper planning
|
||||
- Features that touch multiple parts of the system
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed
|
||||
- Existing project documentation (run `document-project` first if needed)
|
||||
- Clear understanding of what you want to build
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -73,19 +66,9 @@ Follow the standard Phase 4 implementation workflows:
|
||||
3. `dev-story` - Implement with tests
|
||||
4. `code-review` - Quality assurance
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
- Always ensure agents read your existing documentation
|
||||
- Pay attention to integration points with existing code
|
||||
- Follow existing conventions unless deliberately changing them
|
||||
- Document why you're adding new patterns (if any)
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [Brownfield Development Guide](/docs/how-to/brownfield/index.md)
|
||||
- [Document Existing Project](/docs/how-to/brownfield/document-existing-project.md)
|
||||
- [Quick Fix in Brownfield](/docs/how-to/brownfield/quick-fix-in-brownfield.md)
|
||||
|
||||
@@ -3,11 +3,8 @@ title: "How to Document an Existing Project"
|
||||
description: How to document an existing brownfield codebase using BMad Method
|
||||
---
|
||||
|
||||
|
||||
Use the `document-project` workflow to scan your entire codebase and generate comprehensive documentation about its current state.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This
|
||||
|
||||
- Starting work on an undocumented legacy project
|
||||
@@ -15,14 +12,10 @@ Use the `document-project` workflow to scan your entire codebase and generate co
|
||||
- AI agents need context about existing code patterns
|
||||
- Onboarding new team members
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed in your project
|
||||
- Access to the codebase you want to document
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -58,8 +51,6 @@ Review the documentation for:
|
||||
- Completeness of architecture description
|
||||
- Any missing business rules or intent
|
||||
|
||||
---
|
||||
|
||||
## What You Get
|
||||
|
||||
- **Project overview** - High-level description of what the project does
|
||||
@@ -68,17 +59,8 @@ Review the documentation for:
|
||||
- **Business rules** - Logic extracted from the codebase
|
||||
- **Integration points** - External APIs and services
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
- Run this before any major brownfield work
|
||||
- Keep the documentation updated as the project evolves
|
||||
- Use it as input for future PRD creation
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [Brownfield Development Guide](/docs/how-to/brownfield/index.md)
|
||||
- [Add Feature to Existing Project](/docs/how-to/brownfield/add-feature-to-existing.md)
|
||||
|
||||
@@ -3,24 +3,19 @@ title: "Brownfield Development"
|
||||
description: How to use BMad Method on existing codebases
|
||||
---
|
||||
|
||||
|
||||
How to effectively use BMad Method when working on existing projects and legacy codebases.
|
||||
Use BMad Method effectively when working on existing projects and legacy codebases.
|
||||
|
||||
## What is Brownfield Development?
|
||||
|
||||
**Brownfield** refers to working on existing projects with established codebases and patterns, as opposed to **greenfield** which means starting from scratch with a clean slate.
|
||||
|
||||
This tutorial covers the essential workflow for onboarding to brownfield projects with BMad Method.
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
This guide covers the essential workflow for onboarding to brownfield projects with BMad Method.
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed (`npx bmad-method install`)
|
||||
- An existing codebase you want to work on
|
||||
- Access to an AI-powered IDE (Claude Code, Cursor, or Windsurf)
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Step 1: Clean Up Completed Planning Artifacts
|
||||
|
||||
@@ -30,8 +25,6 @@ If you have completed all PRD epics and stories through the BMad process, clean
|
||||
- `_bmad-output/planning-artifacts/`
|
||||
- `_bmad-output/implementation-artifacts/`
|
||||
|
||||
---
|
||||
|
||||
## Step 2: Maintain Quality Project Documentation
|
||||
|
||||
Your `docs/` folder should contain succinct, well-organized documentation that accurately represents your project:
|
||||
@@ -43,8 +36,6 @@ Your `docs/` folder should contain succinct, well-organized documentation that a
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## Step 3: Initialize for Brownfield Work
|
||||
|
||||
Run `workflow-init`. It should recognize you are in an existing project. If not, explicitly clarify that this is brownfield development for a new feature.
|
||||
@@ -85,18 +76,9 @@ When doing architecture, ensure the architect:
|
||||
|
||||
Pay close attention here to prevent reinventing the wheel or making decisions that misalign with your existing architecture.
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
- **[Document Existing Project](/docs/how-to/brownfield/document-existing-project.md)** - How to document your brownfield codebase
|
||||
- **[Add Feature to Existing Project](/docs/how-to/brownfield/add-feature-to-existing.md)** - Adding new functionality
|
||||
- **[Quick Fix in Brownfield](/docs/how-to/brownfield/quick-fix-in-brownfield.md)** - Bug fixes and ad-hoc changes
|
||||
- **[Brownfield FAQ](/docs/explanation/faq/brownfield-faq.md)** - Common questions about brownfield development
|
||||
|
||||
---
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- [Quick Start Guide](/docs/tutorials/getting-started/getting-started-bmadv6.md) - Getting started with BMM
|
||||
- [Quick Spec Flow](/docs/explanation/features/quick-flow.md) - Fast path for small changes
|
||||
|
||||
@@ -3,10 +3,7 @@ title: "How to Make Quick Fixes in Brownfield Projects"
|
||||
description: How to make quick fixes and ad-hoc changes in brownfield projects
|
||||
---
|
||||
|
||||
|
||||
Not everything requires the full BMad method or even Quick Flow. For bug fixes, refactorings, or small targeted changes, you can work directly with the agent.
|
||||
|
||||
---
|
||||
Use the **DEV agent** directly for bug fixes, refactorings, or small targeted changes that don't require the full BMad method or Quick Flow.
|
||||
|
||||
## When to Use This
|
||||
|
||||
@@ -16,8 +13,6 @@ Not everything requires the full BMad method or even Quick Flow. For bug fixes,
|
||||
- Learning about your codebase
|
||||
- One-off changes that don't need planning
|
||||
|
||||
---
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Load an Agent
|
||||
@@ -54,8 +49,6 @@ The agent will:
|
||||
|
||||
Review the changes made and commit when satisfied.
|
||||
|
||||
---
|
||||
|
||||
## Learning Your Codebase
|
||||
|
||||
This approach is also excellent for exploring unfamiliar code:
|
||||
@@ -74,8 +67,6 @@ LLMs are excellent at interpreting and analyzing code—whether it was AI-genera
|
||||
- Understand how things are built
|
||||
- Explore unfamiliar parts of the codebase
|
||||
|
||||
---
|
||||
|
||||
## When to Upgrade to Formal Planning
|
||||
|
||||
Consider using Quick Flow or full BMad Method when:
|
||||
@@ -84,11 +75,3 @@ Consider using Quick Flow or full BMad Method when:
|
||||
- You're unsure about the scope
|
||||
- The fix keeps growing in complexity
|
||||
- You need documentation for the change
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [Brownfield Development Guide](/docs/how-to/brownfield/index.md)
|
||||
- [Add Feature to Existing Project](/docs/how-to/brownfield/add-feature-to-existing.md)
|
||||
- [Quick Spec Flow](/docs/explanation/features/quick-flow.md)
|
||||
|
||||
@@ -2,8 +2,14 @@
|
||||
title: "Agent Customization Guide"
|
||||
---
|
||||
|
||||
Use `.customize.yaml` files to customize BMad agents without modifying core files. All customizations persist through updates.
|
||||
|
||||
Customize BMad agents without modifying core files. All customizations persist through updates.
|
||||
## When to Use This
|
||||
|
||||
- Change agent names or personas
|
||||
- Add project-specific memories or context
|
||||
- Add custom menu items and workflows
|
||||
- Define critical actions for consistent behavior
|
||||
|
||||
## Quick Start
|
||||
|
||||
@@ -204,5 +210,3 @@ memories:
|
||||
- **[Learn about Agents](/docs/explanation/core-concepts/what-are-agents.md)** - Understand Simple vs Expert agents
|
||||
- **[Agent Creation Guide](/docs/tutorials/advanced/create-custom-agent.md)** - Build completely custom agents
|
||||
- **[BMM Complete Documentation](/docs/explanation/bmm/index.md)** - Full BMad Method reference
|
||||
|
||||
[← Back to Customization](/docs/how-to/customization/index.md)
|
||||
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
title: "Workflow Customization Guide"
|
||||
---
|
||||
|
||||
|
||||
Customize and optimize workflows with step replacement and hooks.
|
||||
|
||||
## Status
|
||||
|
||||
> **Coming Soon:** Workflow customization is an upcoming capability. This guide will be updated when the feature is available.
|
||||
|
||||
## What to Expect
|
||||
|
||||
Workflow customization will allow you to:
|
||||
|
||||
- **Replace Steps** - Swap out specific workflow steps with custom implementations
|
||||
- **Add Hooks** - Inject custom behavior before/after workflow steps
|
||||
- **Extend Workflows** - Create new workflows based on existing ones
|
||||
- **Override Behavior** - Customize workflow logic for your project's needs
|
||||
|
||||
## For Now
|
||||
|
||||
While workflow customization is in development, you can:
|
||||
|
||||
- **Create Custom Workflows** - Use the BMad Builder to create entirely new workflows
|
||||
- **Customize Agents** - Modify agent behavior using [Agent Customization](/docs/how-to/customization/customize-agents.md)
|
||||
- **Provide Feedback** - Share your workflow customization needs with the community
|
||||
|
||||
---
|
||||
|
||||
**In the meantime:** Learn how to [create custom workflows](/docs/explanation/bmad-builder/index.md) from scratch.
|
||||
|
||||
[← Back to Customization](/docs/how-to/customization/index.md)
|
||||
@@ -2,7 +2,6 @@
|
||||
title: "BMad Customization"
|
||||
---
|
||||
|
||||
|
||||
Personalize agents and workflows to match your needs.
|
||||
|
||||
## Guides
|
||||
@@ -17,11 +16,9 @@ Personalize agents and workflows to match your needs.
|
||||
BMad provides two main customization approaches:
|
||||
|
||||
### Agent Customization
|
||||
|
||||
Modify any agent's persona, name, capabilities, or menu items using `.customize.yaml` files in `_bmad/_config/agents/`. Your customizations persist through updates.
|
||||
|
||||
### Workflow Customization
|
||||
|
||||
Replace or extend workflow steps to create tailored processes. (Coming soon)
|
||||
|
||||
---
|
||||
|
||||
**Next:** Read the [Agent Customization Guide](/docs/how-to/customization/customize-agents.md) to start personalizing your agents.
|
||||
|
||||
@@ -2,16 +2,14 @@
|
||||
title: "Document Sharding Guide"
|
||||
---
|
||||
|
||||
Use the `shard-doc` tool to split large markdown files into smaller, organized files for better context management.
|
||||
|
||||
Comprehensive guide to BMad Method's document sharding system for managing large planning and architecture documents.
|
||||
## When to Use This
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [What is Document Sharding?](#what-is-document-sharding)
|
||||
- [When to Use Sharding](#when-to-use-sharding)
|
||||
- [How Sharding Works](#how-sharding-works)
|
||||
- [Using the Shard-Doc Tool](#using-the-shard-doc-tool)
|
||||
- [Workflow Support](#workflow-support)
|
||||
- Very large complex PRDs
|
||||
- Architecture documents with multiple system layers
|
||||
- Epic files with 4+ epics (especially for Phase 4)
|
||||
- UX design specs covering multiple subsystems
|
||||
|
||||
## What is Document Sharding?
|
||||
|
||||
@@ -39,43 +37,15 @@ docs/
|
||||
└── ... # Additional sections
|
||||
```
|
||||
|
||||
## When to Use Sharding
|
||||
## Steps
|
||||
|
||||
### Ideal Candidates
|
||||
|
||||
**Large Multi-Epic Projects:**
|
||||
|
||||
- Very large complex PRDs
|
||||
- Architecture documents with multiple system layers
|
||||
- Epic files with 4+ epics (especially for Phase 4)
|
||||
- UX design specs covering multiple subsystems
|
||||
|
||||
## How Sharding Works
|
||||
|
||||
### Sharding Process
|
||||
|
||||
1. **Tool Execution**: Run `npx @kayvan/markdown-tree-parser source.md destination/` - this is abstracted with the core shard-doc task which is installed as a slash command or manual task rule depending on your tools.
|
||||
2. **Section Extraction**: Tool splits by level 2 headings
|
||||
3. **File Creation**: Each section becomes a separate file
|
||||
4. **Index Generation**: `index.md` created with structure and descriptions
|
||||
|
||||
### Workflow Discovery
|
||||
|
||||
BMad workflows use a **dual discovery system**:
|
||||
|
||||
1. **Try whole document first** - Look for `document-name.md`
|
||||
2. **Check for sharded version** - Look for `document-name/index.md`
|
||||
3. **Priority rule** - Whole document takes precedence if both exist - remove the whole document if you want the sharded to be used instead.
|
||||
|
||||
## Using the Shard-Doc Tool
|
||||
|
||||
### CLI Command
|
||||
### 1. Run the Shard-Doc Tool
|
||||
|
||||
```bash
|
||||
/bmad:core:tools:shard-doc
|
||||
/bmad:core:tools:shard-doc
|
||||
```
|
||||
|
||||
### Interactive Process
|
||||
### 2. Follow the Interactive Process
|
||||
|
||||
```
|
||||
Agent: Which document would you like to shard?
|
||||
@@ -91,7 +61,7 @@ Agent: Sharding PRD.md...
|
||||
✓ Complete!
|
||||
```
|
||||
|
||||
### What Gets Created
|
||||
## What You Get
|
||||
|
||||
**index.md structure:**
|
||||
|
||||
@@ -113,13 +83,19 @@ Agent: Sharding PRD.md...
|
||||
- Preserves all markdown formatting
|
||||
- Can be read independently
|
||||
|
||||
## How Workflow Discovery Works
|
||||
|
||||
BMad workflows use a **dual discovery system**:
|
||||
|
||||
1. **Try whole document first** - Look for `document-name.md`
|
||||
2. **Check for sharded version** - Look for `document-name/index.md`
|
||||
3. **Priority rule** - Whole document takes precedence if both exist - remove the whole document if you want the sharded to be used instead
|
||||
|
||||
## Workflow Support
|
||||
|
||||
### Universal Support
|
||||
All BMM workflows support both formats:
|
||||
|
||||
**All BMM workflows support both formats:**
|
||||
|
||||
- ✅ Whole documents
|
||||
- ✅ Sharded documents
|
||||
- ✅ Automatic detection
|
||||
- ✅ Transparent to user
|
||||
- Whole documents
|
||||
- Sharded documents
|
||||
- Automatic detection
|
||||
- Transparent to user
|
||||
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: "Workflow Vendoring, Customization, and Inheritance (Official Support Coming Soon)"
|
||||
---
|
||||
|
||||
|
||||
Vendoring and Inheritance of workflows are 2 ways of sharing or reutilizing workflows - but with some key distinctions and use cases.
|
||||
|
||||
## Workflow Vendoring
|
||||
|
||||
Workflow Vendoring allows an agent to have access to a workflow from another module, without having to install said module. At install time, the module workflow being vendored will be cloned and installed into the module that is receiving the vendored workflow the agent needs.
|
||||
|
||||
### How to Vendor
|
||||
|
||||
Lets assume you are building a module, and you do not want to recreate a workflow from the BMad Method, such as workflows/4-implementation/dev-story/workflow.md. Instead of copying all the context to your module, and having to maintain it over time as updates are made, you can instead use the exec-vendor menu item in your agent.
|
||||
|
||||
From your modules agent definition, you would implement the menu item as follows in the agent:
|
||||
|
||||
```yaml
|
||||
- trigger: develop-story
|
||||
exec-vendor: "{project-root}/_bmad/<source-module>/workflows/4-production/dev-story/workflow.md"
|
||||
exec: "{project-root}/_bmad/<my-module>/workflows/dev-story/workflow.md"
|
||||
description: "Execute Dev Story workflow, implementing tasks and tests, or performing updates to the story"
|
||||
```
|
||||
|
||||
At install time, it will clone the workflow and all of its required assets, and the agent that gets built will have an exec to a path installed in its own module. The content gets added to the folder you specify in exec. While it does not have to exactly match the source path, you will want to ensure you are specifying the workflow.md to be in a new location (in other words in this example, dev-story would not already be the path of another custom module workflow that already exists.)
|
||||
|
||||
## Workflow Inheritance (Official Support Coming Post Beta)
|
||||
|
||||
Workflow Inheritance is a different concept, that allows you to modify or extend existing workflow.
|
||||
|
||||
Party Mode from the core is an example of a workflow that is designed with inheritance in mind - customization for specific party needs. While party mode itself is generic - there might be specific agent collaborations you want to create. Without having to reinvent the whole party mode concept, or copy and paste all of its content - you could inherit from party mode to extend it to be specific.
|
||||
|
||||
Some possible examples could be:
|
||||
|
||||
- Retrospective
|
||||
- Sprint Planning
|
||||
- Collaborative Brainstorming Sessions
|
||||
|
||||
## Workflow Customization (Official Support Coming Post Beta)
|
||||
|
||||
Similar to Workflow Inheritance, Workflow Customization will soon be allowed for certain workflows that are meant to be user customized - similar in process to how agents are customized now.
|
||||
|
||||
This will take the shape of workflows with optional hooks, configurable inputs, and the ability to replace whole at install time.
|
||||
|
||||
For example, assume you are using the Create PRD workflow, which is comprised of 11 steps, and you want to always include specifics about your companies domain, technical landscape or something else. While project-context can be helpful with that, you can also through hooks and step overrides, have full replace steps, the key requirement being to ensure your step replace file is an exact file name match of an existing step, follows all conventions, and ends in a similar fashion to either hook back in to call the next existing step, or more custom steps that eventually hook back into the flow.
|
||||
@@ -3,41 +3,38 @@ title: "How to Get Answers About BMad"
|
||||
description: Use an LLM to quickly answer your own BMad questions
|
||||
---
|
||||
|
||||
Point an LLM at BMad's source files and ask your question. That's the technique—the rest of this guide shows you how.
|
||||
Use your AI tool to get answers about BMad by pointing it at the source files.
|
||||
|
||||
## See It Work
|
||||
## When to Use This
|
||||
|
||||
:::note[Example]
|
||||
**Q:** "Tell me the fastest way to build something with BMad"
|
||||
- You have a question about how BMad works
|
||||
- You want to understand a specific agent or workflow
|
||||
- You need quick answers without waiting for Discord
|
||||
|
||||
**A:** Use Quick Flow: Run `quick-spec` to write a technical specification, then `quick-dev` to implement it—skipping the full planning phases. This gets small features shipped in a single focused session instead of going through the full 4-phase BMM workflow.
|
||||
:::note[Prerequisites]
|
||||
An AI tool (Claude Code, Cursor, ChatGPT, Claude.ai, etc.) and either BMad installed in your project or access to the GitHub repo.
|
||||
:::
|
||||
|
||||
## Why This Works
|
||||
## Steps
|
||||
|
||||
BMad's prompts are written in plain English, not code. The `_bmad` folder contains readable instructions, workflows, and agent definitions—exactly what LLMs are good at processing. You're not asking the LLM to guess; you're giving it the actual source material.
|
||||
|
||||
## How to Do It
|
||||
|
||||
### What Each Source Gives You
|
||||
### 1. Choose Your Source
|
||||
|
||||
| Source | Best For | Examples |
|
||||
|--------|----------|----------|
|
||||
| **`_bmad` folder** (installed) | How BMad works in detail—agents, workflows, prompts | "What does the PM agent do?" "How does the PRD workflow work?" |
|
||||
| **Full GitHub repo** (cloned) | Why things are the way they are—history, installer, architecture | "Why is the installer structured this way?" "What changed in v6?" |
|
||||
| **`llms-full.txt`** | Quick overview from documentation perspective | "Explain BMad's four phases" "What's the difference between levels?" |
|
||||
| **`_bmad` folder** | How BMad works—agents, workflows, prompts | "What does the PM agent do?" |
|
||||
| **Full GitHub repo** | History, installer, architecture | "What changed in v6?" |
|
||||
| **`llms-full.txt`** | Quick overview from docs | "Explain BMad's four phases" |
|
||||
|
||||
:::note[What's `_bmad`?]
|
||||
The `_bmad` folder is created when you install BMad. It contains all the agent definitions, workflows, and prompts. If you don't have this folder yet, you haven't installed BMad—see the "clone the repo" option below.
|
||||
:::
|
||||
The `_bmad` folder is created when you install BMad. If you don't have it yet, clone the repo instead.
|
||||
|
||||
### If Your AI Can Read Files (Claude Code, Cursor, etc.)
|
||||
### 2. Point Your AI at the Source
|
||||
|
||||
**BMad installed:** Point your LLM at the `_bmad` folder and ask directly.
|
||||
**If your AI can read files (Claude Code, Cursor, etc.):**
|
||||
|
||||
**Want deeper context:** Clone the [full repo](https://github.com/bmad-code-org/BMAD-METHOD) for git history and installer details.
|
||||
- **BMad installed:** Point at the `_bmad` folder and ask directly
|
||||
- **Want deeper context:** Clone the [full repo](https://github.com/bmad-code-org/BMAD-METHOD)
|
||||
|
||||
### If You Use ChatGPT or Claude.ai
|
||||
**If you use ChatGPT or Claude.ai:**
|
||||
|
||||
Fetch `llms-full.txt` into your session:
|
||||
|
||||
@@ -45,12 +42,25 @@ Fetch `llms-full.txt` into your session:
|
||||
https://bmad-code-org.github.io/BMAD-METHOD/llms-full.txt
|
||||
```
|
||||
|
||||
You can also find this and other downloadable resources on the [Downloads page](/docs/downloads.md).
|
||||
See the [Downloads page](/docs/downloads.md) for other downloadable resources.
|
||||
|
||||
:::tip[Verify Surprising Answers]
|
||||
LLMs occasionally get things wrong. If an answer seems off, check the source file it referenced or ask on Discord.
|
||||
### 3. Ask Your Question
|
||||
|
||||
:::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.
|
||||
:::
|
||||
|
||||
## What You Get
|
||||
|
||||
Direct answers about BMad—how agents work, what workflows do, why things are structured the way they are—without waiting for someone else to respond.
|
||||
|
||||
## Tips
|
||||
|
||||
- **Verify surprising answers** — LLMs occasionally get things wrong. Check the source file or ask on Discord.
|
||||
- **Be specific** — "What does step 3 of the PRD workflow do?" beats "How does PRD work?"
|
||||
|
||||
## Still Stuck?
|
||||
|
||||
Tried the LLM approach and still need help? You now have a much better question to ask.
|
||||
@@ -64,13 +74,7 @@ Tried the LLM approach and still need help? You now have a much better question
|
||||
|
||||
**Discord:** [discord.gg/gk8jAdXWmj](https://discord.gg/gk8jAdXWmj)
|
||||
|
||||
## Found a Bug?
|
||||
|
||||
If it's clearly a bug in BMad itself, skip Discord and go straight to GitHub Issues:
|
||||
|
||||
**GitHub Issues:** [github.com/bmad-code-org/BMAD-METHOD/issues](https://github.com/bmad-code-org/BMAD-METHOD/issues)
|
||||
|
||||
---
|
||||
**GitHub Issues:** [github.com/bmad-code-org/BMAD-METHOD/issues](https://github.com/bmad-code-org/BMAD-METHOD/issues) (for clear bugs)
|
||||
|
||||
*You!*
|
||||
*Stuck*
|
||||
|
||||
@@ -3,13 +3,10 @@ title: "Installation Guides"
|
||||
description: How to install and upgrade BMad Method
|
||||
---
|
||||
|
||||
|
||||
How-to guides for installing and configuring the BMad Method.
|
||||
|
||||
## Available Guides
|
||||
|
||||
| Guide | Description |
|
||||
|-------|-------------|
|
||||
| **[Install BMad](/docs/how-to/installation/install-bmad.md)** | Step-by-step installation instructions |
|
||||
| **[Install Custom Modules](/docs/how-to/installation/install-custom-modules.md)** | Add custom agents, workflows, and modules |
|
||||
| **[Upgrade to v6](/docs/how-to/installation/upgrade-to-v6.md)** | Migrate from BMad v4 to v6 |
|
||||
| [Install BMad](/docs/how-to/installation/install-bmad.md) | Step-by-step installation instructions |
|
||||
| [Install Custom Modules](/docs/how-to/installation/install-custom-modules.md) | Add custom agents, workflows, and modules |
|
||||
| [Upgrade to v6](/docs/how-to/installation/upgrade-to-v6.md) | Migrate from BMad v4 to v6 |
|
||||
|
||||
@@ -3,18 +3,19 @@ title: "How to Install BMad"
|
||||
description: Step-by-step guide to installing BMad in your project
|
||||
---
|
||||
|
||||
Use the `npx bmad-method install` command to set up BMad in your project with your choice of modules and AI tools.
|
||||
|
||||
Complete guide to installing BMad in your project.
|
||||
## When to Use This
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
- Starting a new project with BMad
|
||||
- Adding BMad to an existing codebase
|
||||
- Setting up BMad on a new machine
|
||||
|
||||
:::note[Prerequisites]
|
||||
- **Node.js** 20+ (required for the installer)
|
||||
- **Git** (recommended)
|
||||
- **AI-powered IDE** (Claude Code, Cursor, Windsurf, or similar)
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -26,7 +27,8 @@ npx bmad-method install
|
||||
|
||||
### 2. Choose Installation Location
|
||||
|
||||
The installer will ask where to install BMad files. Options:
|
||||
The installer will ask where to install BMad files:
|
||||
|
||||
- Current directory (recommended for new projects)
|
||||
- Subdirectory
|
||||
- Custom path
|
||||
@@ -34,6 +36,7 @@ The installer will ask where to install BMad files. Options:
|
||||
### 3. Select Your AI Tools
|
||||
|
||||
Choose which AI tools you'll be using:
|
||||
|
||||
- Claude Code
|
||||
- Cursor
|
||||
- Windsurf
|
||||
@@ -54,29 +57,13 @@ Select which modules to install:
|
||||
|
||||
### 5. Add Custom Content (Optional)
|
||||
|
||||
If you have custom agents, workflows, or modules:
|
||||
- Point to their location
|
||||
- The installer will integrate them
|
||||
If you have custom agents, workflows, or modules, point to their location and the installer will integrate them.
|
||||
|
||||
### 6. Configure Settings
|
||||
|
||||
For each module, either:
|
||||
- Accept recommended defaults (faster)
|
||||
- Customize settings (more control)
|
||||
For each module, either accept recommended defaults (faster) or customize settings (more control).
|
||||
|
||||
---
|
||||
|
||||
## Verify Installation
|
||||
|
||||
After installation, verify by:
|
||||
|
||||
1. Checking the `_bmad/` directory exists
|
||||
2. Loading an agent in your AI tool
|
||||
3. Running `*menu` to see available commands
|
||||
|
||||
---
|
||||
|
||||
## Directory Structure
|
||||
## What You Get
|
||||
|
||||
```
|
||||
your-project/
|
||||
@@ -91,7 +78,11 @@ your-project/
|
||||
└── .claude/ # IDE configuration
|
||||
```
|
||||
|
||||
---
|
||||
## Verify Installation
|
||||
|
||||
1. Check the `_bmad/` directory exists
|
||||
2. Load an agent in your AI tool
|
||||
3. Run `*menu` to see available commands
|
||||
|
||||
## Configuration
|
||||
|
||||
@@ -103,36 +94,19 @@ user_name: Your Name
|
||||
communication_language: english
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### "Command not found: npx"
|
||||
|
||||
Install Node.js 20+:
|
||||
**"Command not found: npx"** — Install Node.js 20+:
|
||||
```bash
|
||||
brew install node
|
||||
|
||||
```
|
||||
|
||||
### "Permission denied"
|
||||
|
||||
Check npm permissions:
|
||||
**"Permission denied"** — Check npm permissions:
|
||||
```bash
|
||||
npm config set prefix ~/.npm-global
|
||||
```
|
||||
|
||||
### Installer hangs
|
||||
|
||||
Try running with verbose output:
|
||||
**Installer hangs** — Try running with verbose output:
|
||||
```bash
|
||||
npx bmad-method install --verbose
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [Quick Start Guide](/docs/tutorials/getting-started/getting-started-bmadv6.md) - Getting started with BMM
|
||||
- [Upgrade to V6](/docs/how-to/installation/upgrade-to-v6.md) - Upgrading from previous versions
|
||||
- [Install Custom Modules](/docs/how-to/installation/install-custom-modules.md) - Adding custom content
|
||||
|
||||
@@ -1,152 +1,118 @@
|
||||
---
|
||||
title: "Custom Content Installation"
|
||||
title: "How to Install Custom Modules"
|
||||
description: Add custom agents, workflows, and modules to BMad
|
||||
---
|
||||
|
||||
Use the BMad installer to add custom agents, workflows, and modules that extend BMad's functionality.
|
||||
|
||||
This guide explains how to create and install custom BMad content including agents, workflows, and modules. Custom content extends BMad's functionality with specialized tools and workflows that can be shared across projects or teams.
|
||||
## When to Use This
|
||||
|
||||
For detailed information about the different types of custom content available, see [Custom Content Types](/docs/explanation/bmad-builder/custom-content-types.md).
|
||||
- Adding third-party BMad modules to your project
|
||||
- Installing your own custom agents or workflows
|
||||
- Sharing custom content across projects or teams
|
||||
|
||||
You can find example custom modules in the `samples/sample-custom-modules/` folder of the repository. Download either of the sample folders to try them out.
|
||||
:::note[Prerequisites]
|
||||
- BMad installed in your project
|
||||
- Custom content with a valid `module.yaml` file
|
||||
:::
|
||||
|
||||
## Content Types Overview
|
||||
## Steps
|
||||
|
||||
BMad Core supports several categories of custom content:
|
||||
### 1. Prepare Your Custom Content
|
||||
|
||||
- Custom Stand Alone Modules
|
||||
- Custom Add On Modules
|
||||
- Custom Global Modules
|
||||
- Custom Agents
|
||||
- Custom Workflows
|
||||
Your custom content needs a `module.yaml` file. Choose the appropriate structure:
|
||||
|
||||
## Making Custom Content Installable
|
||||
**For a cohesive module** (agents and workflows that work together):
|
||||
|
||||
### Custom Modules
|
||||
```
|
||||
module-code/
|
||||
module.yaml
|
||||
agents/
|
||||
workflows/
|
||||
tools/
|
||||
templates/
|
||||
```
|
||||
|
||||
To create an installable custom module:
|
||||
**For standalone items** (unrelated agents/workflows):
|
||||
|
||||
1. **Folder Structure**
|
||||
- Create a folder with a short, abbreviated name (e.g., `cis` for Creative Intelligence Suite)
|
||||
- The folder name serves as the module code
|
||||
```
|
||||
module-name/
|
||||
module.yaml # Contains unitary: true
|
||||
agents/
|
||||
larry/larry.agent.md
|
||||
curly/curly.agent.md
|
||||
workflows/
|
||||
```
|
||||
|
||||
2. **Required File**
|
||||
- Include a `module.yaml` file in the root folder (this drives questions for the final generated config.yaml at install target)
|
||||
Add `unitary: true` in your `module.yaml` to indicate items don't depend on each other.
|
||||
|
||||
3. **Folder Organization**
|
||||
Follow these conventions for optimal compatibility:
|
||||
### 2. Run the Installer
|
||||
|
||||
```
|
||||
module-code/
|
||||
module.yaml
|
||||
agents/
|
||||
workflows/
|
||||
tools/
|
||||
templates/
|
||||
...
|
||||
```
|
||||
**New project:**
|
||||
|
||||
- `agents/` - Agent definitions
|
||||
- `workflows/` - Workflow definitions
|
||||
- Additional custom folders are supported but following conventions is recommended for agent and workflow discovery
|
||||
```bash
|
||||
npx bmad-method install
|
||||
```
|
||||
|
||||
**Note:** Full documentation for global modules and add-on modules will be available as support is finalized.
|
||||
When prompted "Would you like to install a local custom module?", select 'y' and provide the path to your module folder.
|
||||
|
||||
### Standalone Content (Agents, Workflows, Tasks, Tools, Templates, Prompts)
|
||||
**Existing project:**
|
||||
|
||||
For standalone content that isn't part of a cohesive module collection, follow this structure:
|
||||
```bash
|
||||
npx bmad-method install
|
||||
```
|
||||
|
||||
1. **Module Configuration**
|
||||
- Create a folder with a `module.yaml` file (similar to custom modules)
|
||||
- Add the property `unitary: true` in the module.yaml
|
||||
- The `unitary: true` property indicates this is a collection of potentially unrelated items that don't depend on each other
|
||||
- Any content you add to this folder should still be nested under workflows and agents - but the key with stand alone content is they do not rely on each other.
|
||||
- Agents do not reference other workflows even if stored in a unitary:true module. But unitary Agents can have their own workflows in their sidecar, or reference workflows as requirements from other modules - with a process known as workflow vendoring. Keep in mind, this will require that the workflow referenced from the other module would need to be available for the end user to install, so its recommended to only vendor workflows from the core module, or official bmm modules.
|
||||
1. Select `Modify BMad Installation`
|
||||
2. Choose the option to add, modify, or update custom modules
|
||||
3. Provide the path to your module folder
|
||||
|
||||
2. **Folder Structure**
|
||||
Organize content in specific named folders:
|
||||
### 3. Verify Installation
|
||||
|
||||
```
|
||||
module-name/
|
||||
module.yaml # Contains unitary: true
|
||||
agents/
|
||||
workflows/
|
||||
templates/
|
||||
tools/
|
||||
tasks/
|
||||
prompts/
|
||||
```
|
||||
Check that your custom content appears in the `_bmad/` directory and is accessible from your AI tool.
|
||||
|
||||
3. **Individual Item Organization**
|
||||
Each item should have its own subfolder:
|
||||
```text
|
||||
my-custom-stuff/
|
||||
module.yaml
|
||||
agents/
|
||||
larry/larry.agent.md
|
||||
curly/curly.agent.md
|
||||
moe/moe.agent.md
|
||||
moe/moe-sidecar/memories.csv
|
||||
```
|
||||
## What You Get
|
||||
|
||||
**Future Feature:** Unitary modules will support selective installation, allowing users to pick and choose which specific items to install.
|
||||
- Custom agents available in your AI tool
|
||||
- Custom workflows accessible via `*workflow-name`
|
||||
- Content integrated with BMad's update system
|
||||
|
||||
**Note:** Documentation explaining the distinctions between these content types and their specific use cases will be available soon.
|
||||
## Content Types
|
||||
|
||||
## Installation Process
|
||||
BMad supports several categories of custom content:
|
||||
|
||||
### Prerequisites
|
||||
| Type | Description |
|
||||
|------|-------------|
|
||||
| **Stand Alone Modules** | Complete modules with their own agents and workflows |
|
||||
| **Add On Modules** | Extensions that add to existing modules |
|
||||
| **Global Modules** | Content available across all modules |
|
||||
| **Custom Agents** | Individual agent definitions |
|
||||
| **Custom Workflows** | Individual workflow definitions |
|
||||
|
||||
Ensure your content follows the proper conventions and includes a `module.yaml` file (only one per top-level folder).
|
||||
For detailed information about content types, see [Custom Content Types](/docs/explanation/bmad-builder/custom-content-types.md).
|
||||
|
||||
### New Project Installation
|
||||
## Updating Custom Content
|
||||
|
||||
When setting up a new BMad project:
|
||||
When BMad Core or module updates are available, the quick update process:
|
||||
|
||||
1. The installer will prompt: `Would you like to install a local custom module (this includes custom agents and workflows also)? (y/N)`
|
||||
2. Select 'y' to specify the path to your module folder containing `module.yaml`
|
||||
1. Applies updates to core modules
|
||||
2. Recompiles all agents with your customizations
|
||||
3. Retains your custom content from cache
|
||||
4. Preserves your configurations
|
||||
|
||||
### Existing Project Modification
|
||||
You don't need to keep source module files locally—just point to the updated location during updates.
|
||||
|
||||
To add custom content to an existing BMad project:
|
||||
## Tips
|
||||
|
||||
1. Run the installer against your project location
|
||||
2. Select `Modify BMad Installation`
|
||||
3. Choose the option to add, modify, or update custom modules
|
||||
- **Use unique module codes** — Don't use `bmm` or other existing module codes
|
||||
- **Avoid naming conflicts** — Each module needs a distinct code
|
||||
- **Document dependencies** — Note any modules your custom content requires
|
||||
- **Test in isolation** — Verify custom modules work before sharing
|
||||
- **Version your content** — Track updates with version numbers
|
||||
|
||||
### Upcoming Features
|
||||
:::caution[Naming Conflicts]
|
||||
Don't create custom modules with codes like `bmm` (already used by BMad Method). Each custom module needs a unique code.
|
||||
:::
|
||||
|
||||
- **Unitary Module Selection:** For modules with `type: unitary` (instead of `type: module`), you'll be able to select specific items to install
|
||||
- **Add-on Module Dependencies:** The installer will verify and install dependencies for add-on modules automatically
|
||||
## Example Modules
|
||||
|
||||
## Quick Updates
|
||||
|
||||
When updates to BMad Core or core modules (BMM, CIS, etc.) become available, the quick update process will:
|
||||
|
||||
1. Apply available updates to core modules
|
||||
2. Recompile all agents with customizations from the `_config/agents` folder
|
||||
3. Retain your custom content from a cached location
|
||||
4. Preserve your existing configurations and customizations
|
||||
|
||||
This means you don't need to keep the source module files locally. When updates are available, simply point to the updated module location during the update process.
|
||||
|
||||
## Important Considerations
|
||||
|
||||
### Module Naming Conflicts
|
||||
|
||||
When installing unofficial modules, ensure unique identification to avoid conflicts:
|
||||
|
||||
1. **Module Codes:** Each module must have a unique code (e.g., don't use `bmm` for custom modules)
|
||||
2. **Module Names:** Avoid using names that conflict with existing modules
|
||||
3. **Multiple Custom Modules:** If creating multiple custom modules, use distinct codes for each
|
||||
|
||||
**Examples of conflicts to avoid:**
|
||||
|
||||
- Don't create a custom module with code `bmm` (already used by BMad Method)
|
||||
- Don't name multiple custom modules with the same code like `mca`
|
||||
|
||||
### Best Practices
|
||||
|
||||
- Use descriptive, unique codes for your modules
|
||||
- Document any dependencies your custom modules have
|
||||
- Test custom modules in isolation before sharing
|
||||
- Consider version numbering for your custom content to track updates
|
||||
Find example custom modules in the `samples/sample-custom-modules/` folder of the [BMad repository](https://github.com/bmad-code-org/BMAD-METHOD). Download either sample folder to try them out.
|
||||
|
||||
@@ -1,147 +1,131 @@
|
||||
---
|
||||
title: "Upgrading from Previous Versions"
|
||||
title: "How to Upgrade to v6"
|
||||
description: Migrate from BMad v4 to v6
|
||||
---
|
||||
|
||||
Use the BMad installer to upgrade from v4 to v6, which includes automatic detection of legacy installations and migration assistance.
|
||||
|
||||
## Overview
|
||||
## When to Use This
|
||||
|
||||
The latest version of BMad represents a complete ground-up rewrite with significant architectural changes. This guide will help you migrate from version 4.
|
||||
- You have BMad v4 installed (`.bmad-method` folder)
|
||||
- You want to migrate to the new v6 architecture
|
||||
- You have existing planning artifacts to preserve
|
||||
|
||||
---
|
||||
:::note[Prerequisites]
|
||||
- Node.js 20+
|
||||
- Existing BMad v4 installation
|
||||
:::
|
||||
|
||||
## Automatic V4 Detection
|
||||
## Steps
|
||||
|
||||
When you run `npm run install:bmad` on a project, the installer automatically detects:
|
||||
### 1. Run the Installer
|
||||
|
||||
- **Legacy v4 installation folder**: `.bmad-method`
|
||||
- **IDE command artifacts**: Legacy bmad folders in IDE configuration directories (`.claude/commands/`, `.cursor/commands/`, etc.)
|
||||
|
||||
### What Happens During Detection
|
||||
|
||||
1. **Automatic Detection of v4 Modules**
|
||||
1. Installer will suggest removal or backup of your .bmad-method folder. You can choose to exit the installer and handle this cleanup, or allow the install to continue. Technically you can have both v4 and v6 installed, but it is not recommended. All BMad content and modules will be installed under a .bmad folder, fully segregated.
|
||||
|
||||
2. **IDE Command Cleanup Recommended**: Legacy v4 IDE commands should be manually removed
|
||||
- Located in IDE config folders, for example claude: `.claude/commands/BMad/agents`, `.claude/commands/BMad/tasks`, etc.
|
||||
- NOTE: if the upgrade and install of v6 finished, the new commands will be under `.claude/commands/bmad/<module>/agents|workflows`
|
||||
- Note 2: If you accidentally delete the wrong/new bmad commands - you can easily restore them by rerunning the installer, and choose quick update option, and all will be reapplied properly.
|
||||
|
||||
## Module Migration
|
||||
|
||||
### Deprecated Modules from v4
|
||||
|
||||
| v4 Module | v6 Status |
|
||||
| ----------------------------- | ---------------------------------------------- |
|
||||
| `_bmad-2d-phaser-game-dev` | Integrated into new BMGD Module |
|
||||
| `_bmad-2d-unity-game-dev` | Integrated into new BMGD Module |
|
||||
| `_bmad-godot-game-dev` | Integrated into new BMGD Module |
|
||||
| `_bmad-*-game-dev` (any) | Integrated into new BMGD Module |
|
||||
| `_bmad-infrastructure-devops` | Deprecated - New core devops agent coming soon |
|
||||
| `_bmad-creative-writing` | Not adapted - New v6 module coming soon |
|
||||
|
||||
Aside from .bmad-method - if you have any of these others installed also, again its recommended to remove them and use the V6 equivalents, but its also fine if you decide to keep both. But it is not recommended to use both on the same project long term.
|
||||
|
||||
## Architecture Changes
|
||||
|
||||
### Folder Structure
|
||||
|
||||
**v4 "Expansion Packs" Structure:**
|
||||
|
||||
```
|
||||
your-project/
|
||||
├── .bmad-method/
|
||||
├── .bmad-game-dev/
|
||||
├── .bmad-creative-writing/
|
||||
└── .bmad-infrastructure-devops/
|
||||
```bash
|
||||
npx bmad-method install
|
||||
```
|
||||
|
||||
**v6 Unified Structure:**
|
||||
The installer automatically detects:
|
||||
|
||||
```
|
||||
your-project/
|
||||
└── _bmad/ # Single installation folder is _bmad
|
||||
└── _config/ # Your customizations
|
||||
| └── agents/ # Agent customization files
|
||||
├── core/ # Real core framework (applies to all modules)
|
||||
├── bmm/ # BMad Method (software/game dev)
|
||||
├── bmb/ # BMad Builder (create agents/workflows)
|
||||
├── cis/ # Creative Intelligence Suite
|
||||
├── _bmad_output # Default bmad output folder (was doc folder in v4)
|
||||
- **Legacy v4 folder**: `.bmad-method`
|
||||
- **IDE command artifacts**: Legacy bmad folders in `.claude/commands/`, `.cursor/commands/`, etc.
|
||||
|
||||
```
|
||||
### 2. Handle Legacy Installation
|
||||
|
||||
### Key Concept Changes
|
||||
When v4 is detected, you can:
|
||||
|
||||
- **v4 `_bmad-core and _bmad-method`**: Was actually the BMad Method
|
||||
- **v6 `_bmad/core/`**: Is the real universal core framework
|
||||
- **v6 `_bmad/bmm/`**: Is the BMad Method module
|
||||
- **Module identification**: All modules now have a `config.yaml` file once installed at the root of the modules installed folder
|
||||
- Allow the installer to back up and remove `.bmad-method`
|
||||
- Exit and handle cleanup manually
|
||||
- Keep both (not recommended for same project)
|
||||
|
||||
## Project Progress Migration
|
||||
### 3. Clean Up IDE Commands
|
||||
|
||||
### If You've Completed Some or all Planning Phases (Brief/PRD/UX/Architecture) with the BMad Method:
|
||||
Manually remove legacy v4 IDE commands:
|
||||
|
||||
After running the v6 installer, if you kept the paths the same as the installation suggested, you will need to move a few files, or run the installer again. It is recommended to stick with these defaults as it will be easier to adapt if things change in the future.
|
||||
- `.claude/commands/BMad/agents`
|
||||
- `.claude/commands/BMad/tasks`
|
||||
|
||||
If you have any planning artifacts, put them in a folder called _bmad-output/planning-artifacts at the root of your project, ensuring that:
|
||||
PRD has PRD in the file name or folder name if sharded.
|
||||
Similar for 'brief', 'architecture', 'ux-design'.
|
||||
New v6 commands will be at `.claude/commands/bmad/<module>/agents|workflows`.
|
||||
|
||||
If you have other long term docs that will not be as ephemeral as these project docs, you can put them in the /docs folder, ideally with a index.md file.
|
||||
:::tip[Accidentally Deleted Commands?]
|
||||
If you delete the wrong commands, rerun the installer and choose "quick update" to restore them.
|
||||
:::
|
||||
|
||||
HIGHLY RECOMMENDED NOTE: If you are only partway through planning, its highly recommended to restart and do the PRD, UX and ARCHITECTURE steps. You could even use your existing documents as inputs letting the agent know you want to redo them with the new workflows. These optimized v6 progressive discovery workflows that also will utilize web search at key moments, while offering better advanced elicitation and part mode in the IDE will produce superior results. And then once all are complete, an epics with stories is generated after the architecture step now - ensuring it uses input from all planing documents.
|
||||
### 4. Migrate Planning Artifacts
|
||||
|
||||
### If You're Mid-Development (Stories Created/Implemented)
|
||||
**If you have planning documents (Brief/PRD/UX/Architecture):**
|
||||
|
||||
1. Complete the v6 installation as above
|
||||
2. Ensure you have a file called epics.md or epics/epic*.md - these need to be located under the _bmad-output/planning-artifacts folder.
|
||||
3. Run the scrum masters `sprint-planning` workflow to generate the implementation tracking plan in _bmad-output/implementation-artifacts.
|
||||
4. Inform the SM after the output is complete which epics and stories were completed already and should be parked properly in the file.
|
||||
Move them to `_bmad-output/planning-artifacts/` with descriptive names:
|
||||
|
||||
## Agent Customization Migration
|
||||
- Include `PRD` in filename for PRD documents
|
||||
- Include `brief`, `architecture`, or `ux-design` accordingly
|
||||
- Sharded documents can be in named subfolders
|
||||
|
||||
### v4 Agent Customization
|
||||
**If you're mid-planning:** Consider restarting with v6 workflows. Use your existing documents as inputs—the new progressive discovery workflows with web search and IDE plan mode produce better results.
|
||||
|
||||
In v4, you may have modified agent files directly in `_bmad-*` folders.
|
||||
### 5. Migrate In-Progress Development
|
||||
|
||||
### v6 Agent Customization
|
||||
If you have stories created or implemented:
|
||||
|
||||
**All customizations** now go in `_bmad/_config/agents/` using customize files:
|
||||
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
|
||||
4. Tell the SM which epics/stories are already complete
|
||||
|
||||
**Example: Renaming an agent and changing communication style**
|
||||
### 6. Migrate Agent Customizations
|
||||
|
||||
File: `_bmad/_config/agents/bmm-pm.customize.yaml`
|
||||
**v4:** Modified agent files directly in `_bmad-*` folders
|
||||
|
||||
**v6:** All customizations go in `_bmad/_config/agents/` using customize files:
|
||||
|
||||
```yaml
|
||||
# Customize the PM agent
|
||||
# _bmad/_config/agents/bmm-pm.customize.yaml
|
||||
persona:
|
||||
name: 'Captain Jack' # Override agent name
|
||||
name: 'Captain Jack'
|
||||
role: 'Swashbuckling Product Owner'
|
||||
communication_style: |
|
||||
- Talk like a pirate
|
||||
- Use nautical metaphors for software concepts
|
||||
- Always upbeat and adventurous
|
||||
- Use nautical metaphors
|
||||
```
|
||||
|
||||
There is a lot more that is possible with agent customization, which is covered in detail in the [Agent Customization Guide](/docs/how-to/customization/customize-agents.md)
|
||||
After modifying customization files, rerun the installer and choose "rebuild all agents" or "quick update".
|
||||
|
||||
CRITICAL NOTE: After you modify the customization file, you need to run the npx installer against your installed location, and choose the option to rebuild all agents, or just do a quick update again. This always builds agents fresh and applies customizations.
|
||||
## What You Get
|
||||
|
||||
**How it works:**
|
||||
**v6 unified structure:**
|
||||
|
||||
- Base agent: `_bmad/bmm/agents/pm.md`
|
||||
- Customization: `_bmad/_config/agents/bmm-pm.customize.yaml`
|
||||
- Rebuild all agents -> Result: Agent uses your custom name and style
|
||||
```
|
||||
your-project/
|
||||
└── _bmad/ # Single installation folder
|
||||
├── _config/ # Your customizations
|
||||
│ └── agents/ # Agent customization files
|
||||
├── core/ # Universal core framework
|
||||
├── bmm/ # BMad Method module
|
||||
├── bmb/ # BMad Builder
|
||||
└── cis/ # Creative Intelligence Suite
|
||||
├── _bmad-output/ # Output folder (was doc folder in v4)
|
||||
```
|
||||
|
||||
## Document Compatibility
|
||||
## Module Migration
|
||||
|
||||
### Sharded vs Unsharded Documents
|
||||
| v4 Module | v6 Status |
|
||||
|-----------|-----------|
|
||||
| `_bmad-2d-phaser-game-dev` | Integrated into BMGD Module |
|
||||
| `_bmad-2d-unity-game-dev` | Integrated into BMGD Module |
|
||||
| `_bmad-godot-game-dev` | Integrated into BMGD Module |
|
||||
| `_bmad-infrastructure-devops` | Deprecated — new DevOps agent coming soon |
|
||||
| `_bmad-creative-writing` | Not adapted — new v6 module coming soon |
|
||||
|
||||
**Good news**: Unlike v4, v6 workflows are **fully flexible** with document structure:
|
||||
## Key Changes
|
||||
|
||||
- ✅ Sharded documents (split into multiple files)
|
||||
- ✅ Unsharded documents (single file per section)
|
||||
- ✅ Custom sections for your project type
|
||||
- ✅ Mixed approaches
|
||||
| Concept | v4 | v6 |
|
||||
|---------|----|----|
|
||||
| **Core** | `_bmad-core` was actually BMad Method | `_bmad/core/` is universal framework |
|
||||
| **Method** | `_bmad-method` | `_bmad/bmm/` |
|
||||
| **Config** | Modified files directly | `config.yaml` per module |
|
||||
| **Documents** | Sharded or unsharded required setup | Fully flexible, auto-scanned |
|
||||
|
||||
All workflow files are scanned automatically. No manual configuration needed.
|
||||
## Tips
|
||||
|
||||
- **Back up first** — Keep your v4 installation until you verify v6 works
|
||||
- **Use v6 workflows** — Even partial planning docs benefit from v6's improved discovery
|
||||
- **Rebuild after customizing** — Always run the installer after changing customize files
|
||||
|
||||
@@ -2,10 +2,7 @@
|
||||
title: "BMGD Troubleshooting"
|
||||
---
|
||||
|
||||
|
||||
Common issues and solutions when using BMGD workflows.
|
||||
|
||||
---
|
||||
Use this guide to resolve common issues when using BMGD workflows.
|
||||
|
||||
## Installation Issues
|
||||
|
||||
@@ -19,8 +16,6 @@ Common issues and solutions when using BMGD workflows.
|
||||
2. Check `_bmad/bmgd/` folder exists in your project
|
||||
3. Re-run installer with `--add-module bmgd`
|
||||
|
||||
---
|
||||
|
||||
### Config file missing
|
||||
|
||||
**Symptom:** Workflows fail with "config not found" errors.
|
||||
@@ -36,8 +31,6 @@ document_output_language: 'English'
|
||||
game_dev_experience: 'intermediate'
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Workflow Issues
|
||||
|
||||
### "GDD not found" in Narrative workflow
|
||||
@@ -50,8 +43,6 @@ game_dev_experience: 'intermediate'
|
||||
2. Check GDD filename contains "gdd" (e.g., `game-gdd.md`, `my-gdd.md`)
|
||||
3. If using sharded GDD, verify `{output_folder}/gdd/index.md` exists
|
||||
|
||||
---
|
||||
|
||||
### Workflow state not persisting
|
||||
|
||||
**Symptom:** Returning to a workflow starts from the beginning.
|
||||
@@ -62,8 +53,6 @@ game_dev_experience: 'intermediate'
|
||||
2. Ensure document was saved before ending session
|
||||
3. Use "Continue existing" option when re-entering workflow
|
||||
|
||||
---
|
||||
|
||||
### Wrong game type sections in GDD
|
||||
|
||||
**Symptom:** GDD includes irrelevant sections for your game type.
|
||||
@@ -74,8 +63,6 @@ game_dev_experience: 'intermediate'
|
||||
2. You can select multiple types for hybrid games
|
||||
3. Irrelevant sections can be marked N/A or removed
|
||||
|
||||
---
|
||||
|
||||
## Agent Issues
|
||||
|
||||
### Agent not recognizing commands
|
||||
@@ -88,8 +75,6 @@ game_dev_experience: 'intermediate'
|
||||
2. Check exact command spelling (case-sensitive)
|
||||
3. Try `workflow-status` to verify agent is loaded correctly
|
||||
|
||||
---
|
||||
|
||||
### Agent using wrong persona
|
||||
|
||||
**Symptom:** Agent responses don't match expected personality.
|
||||
@@ -100,8 +85,6 @@ game_dev_experience: 'intermediate'
|
||||
2. Check `_bmad/bmgd/agents/` for agent definitions
|
||||
3. Start a fresh chat session with the correct agent
|
||||
|
||||
---
|
||||
|
||||
## Document Issues
|
||||
|
||||
### Document too large for context
|
||||
@@ -114,8 +97,6 @@ game_dev_experience: 'intermediate'
|
||||
2. Request specific sections rather than full document
|
||||
3. GDD workflow supports automatic sharding for large documents
|
||||
|
||||
---
|
||||
|
||||
### Template placeholders not replaced
|
||||
|
||||
**Symptom:** Output contains `{{placeholder}}` text.
|
||||
@@ -126,8 +107,6 @@ game_dev_experience: 'intermediate'
|
||||
2. Re-run the specific step that generates that section
|
||||
3. Manually edit the document to fill in missing values
|
||||
|
||||
---
|
||||
|
||||
### Frontmatter parsing errors
|
||||
|
||||
**Symptom:** YAML errors when loading documents.
|
||||
@@ -138,8 +117,6 @@ game_dev_experience: 'intermediate'
|
||||
2. Check for tabs vs spaces (YAML requires spaces)
|
||||
3. Ensure frontmatter is bounded by `---` markers
|
||||
|
||||
---
|
||||
|
||||
## Phase 4 (Production) Issues
|
||||
|
||||
### Sprint status not updating
|
||||
@@ -152,8 +129,6 @@ game_dev_experience: 'intermediate'
|
||||
2. Check file permissions on sprint-status.yaml
|
||||
3. Verify workflow-install files exist in `_bmad/bmgd/workflows/4-production/`
|
||||
|
||||
---
|
||||
|
||||
### Story context missing code references
|
||||
|
||||
**Symptom:** Generated story context doesn't include relevant code.
|
||||
@@ -164,8 +139,6 @@ game_dev_experience: 'intermediate'
|
||||
2. Check that architecture document references correct file paths
|
||||
3. Story may need more specific file references in acceptance criteria
|
||||
|
||||
---
|
||||
|
||||
### Code review not finding issues
|
||||
|
||||
**Symptom:** Code review passes but bugs exist.
|
||||
@@ -176,8 +149,6 @@ game_dev_experience: 'intermediate'
|
||||
2. Always run actual tests before marking story done
|
||||
3. Consider manual review for critical code paths
|
||||
|
||||
---
|
||||
|
||||
## Performance Issues
|
||||
|
||||
### Workflows running slowly
|
||||
@@ -190,8 +161,6 @@ game_dev_experience: 'intermediate'
|
||||
2. Keep documents concise (avoid unnecessary detail)
|
||||
3. Use sharded documents for large projects
|
||||
|
||||
---
|
||||
|
||||
### Context limit reached mid-workflow
|
||||
|
||||
**Symptom:** Workflow stops or loses context partway through.
|
||||
@@ -202,8 +171,6 @@ game_dev_experience: 'intermediate'
|
||||
2. Break complex sections into multiple sessions
|
||||
3. Use step-file architecture (workflows resume from last step)
|
||||
|
||||
---
|
||||
|
||||
## Common Error Messages
|
||||
|
||||
### "Input file not found"
|
||||
@@ -212,24 +179,18 @@ game_dev_experience: 'intermediate'
|
||||
|
||||
**Fix:** Complete prerequisite workflow first (e.g., Game Brief before GDD).
|
||||
|
||||
---
|
||||
|
||||
### "Invalid game type"
|
||||
|
||||
**Cause:** Selected game type not in supported list.
|
||||
|
||||
**Fix:** Check `game-types.csv` for valid type IDs.
|
||||
|
||||
---
|
||||
|
||||
### "Validation failed"
|
||||
|
||||
**Cause:** Document doesn't meet checklist requirements.
|
||||
|
||||
**Fix:** Review the validation output and address flagged items.
|
||||
|
||||
---
|
||||
|
||||
## Getting Help
|
||||
|
||||
### Community Support
|
||||
@@ -252,8 +213,6 @@ When reporting issues, include:
|
||||
3. Relevant document frontmatter
|
||||
4. Steps to reproduce
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
- **[Quick Start Guide](/docs/tutorials/getting-started/quick-start-bmgd.md)** - Getting started
|
||||
|
||||
@@ -1,52 +1,41 @@
|
||||
---
|
||||
title: "BMGD Quick-Flow Guide"
|
||||
description: Fast-track workflows for rapid game prototyping and flexible development
|
||||
---
|
||||
|
||||
Use BMGD Quick-Flow workflows for rapid game prototyping and flexible development when you need to move fast.
|
||||
|
||||
Fast-track workflows for rapid game prototyping and flexible development.
|
||||
|
||||
---
|
||||
|
||||
## Game Solo Dev Agent
|
||||
|
||||
For dedicated quick-flow development, use the **Game Solo Dev** agent (Indie). This agent is optimized for solo developers and small teams who want to skip the full planning phases and ship fast.
|
||||
|
||||
**Switch to Game Solo Dev:** Type `@game-solo-dev` or select the agent from your IDE.
|
||||
|
||||
The Game Solo Dev agent includes:
|
||||
|
||||
- `quick-prototype` - Rapid mechanic testing
|
||||
- `quick-dev` - Flexible feature implementation
|
||||
- `quick-spec` - Create implementation-ready specs
|
||||
- `code-review` - Quality checks
|
||||
- `test-framework` - Automated testing setup
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Quick-flow workflows skip the full BMGD planning phases when you need to move fast. Use them for:
|
||||
## When to Use This
|
||||
|
||||
- Testing a game mechanic idea
|
||||
- Implementing a small feature
|
||||
- Rapid prototyping before committing to design
|
||||
- Bug fixes and tweaks
|
||||
|
||||
```
|
||||
Full BMGD Flow:
|
||||
Brief → GDD → Architecture → Sprint Planning → Stories → Implementation
|
||||
## When to Use Full BMGD Instead
|
||||
|
||||
Quick-Flow:
|
||||
Idea → Quick-Prototype → Quick-Dev → Done
|
||||
```
|
||||
- Building a major feature or system
|
||||
- The scope is unclear or large
|
||||
- Multiple team members need alignment
|
||||
- The work affects game pillars or core loop
|
||||
- You need documentation for future reference
|
||||
|
||||
---
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed with BMGD module
|
||||
- Game Solo Dev agent (Indie) or other BMGD agent available
|
||||
:::
|
||||
|
||||
## Game Solo Dev Agent
|
||||
|
||||
For dedicated quick-flow development, use the **Game Solo Dev** agent. This agent is optimized for solo developers and small teams who want to skip the full planning phases.
|
||||
|
||||
**Switch to Game Solo Dev:** Type `@game-solo-dev` or select from your IDE.
|
||||
|
||||
Includes: `quick-prototype`, `quick-dev`, `quick-spec`, `code-review`, `test-framework`
|
||||
|
||||
## Quick-Prototype
|
||||
|
||||
**Command:** `quick-prototype`
|
||||
**Agent:** Game Designer, Game Developer
|
||||
**Purpose:** Rapidly test gameplay ideas with minimal setup
|
||||
Use `quick-prototype` to rapidly test gameplay ideas with minimal setup.
|
||||
|
||||
### When to Use
|
||||
|
||||
@@ -55,60 +44,31 @@ Idea → Quick-Prototype → Quick-Dev → Done
|
||||
- You want to experiment before committing to design
|
||||
- You need a proof of concept
|
||||
|
||||
### Workflow Steps
|
||||
### Steps
|
||||
|
||||
1. **Define Scope** - What are you prototyping? (mechanic, feature, system)
|
||||
2. **Set Success Criteria** - How will you know if it works?
|
||||
3. **Rapid Implementation** - Build the minimum to test the idea
|
||||
4. **Playtest and Evaluate** - Does it feel right?
|
||||
1. Run `quick-prototype`
|
||||
2. Define what you're prototyping (mechanic, feature, system)
|
||||
3. Set success criteria (2-3 items)
|
||||
4. Build the minimum to test the idea
|
||||
5. Playtest and evaluate
|
||||
|
||||
### Prototype Principles
|
||||
|
||||
- **Minimum Viable Prototype** - Only what's needed to test the idea
|
||||
- **Hardcode First** - Magic numbers are fine, extract later
|
||||
- **Skip Edge Cases** - Happy path only for now
|
||||
- **Placeholder Everything** - Cubes, debug text, temp sounds
|
||||
- **Comment Intent** - Mark what's temporary vs keeper code
|
||||
|
||||
### Example Session
|
||||
|
||||
```
|
||||
You: quick-prototype
|
||||
|
||||
Agent: What are you prototyping?
|
||||
|
||||
You: I want to test a grappling hook mechanic. Player should be
|
||||
able to aim at surfaces and pull themselves toward the hook point.
|
||||
|
||||
Agent: What makes this prototype successful?
|
||||
|
||||
You: 1. Aiming feels responsive and intuitive
|
||||
2. The pull movement feels satisfying, not floaty
|
||||
3. Player can chain hooks without awkward pauses
|
||||
|
||||
Agent: [Implements minimal grappling hook]
|
||||
|
||||
Agent: Prototype complete! Playtest results:
|
||||
- Aiming: Works, consider adding aim assist
|
||||
- Movement: Pull is smooth, might need speed curve
|
||||
- Chaining: Currently has 0.2s delay, feels sluggish
|
||||
|
||||
Next: [d] Develop further | [i] Iterate | [a] Archive
|
||||
```
|
||||
- **Minimum Viable Prototype** — Only what's needed to test the idea
|
||||
- **Hardcode First** — Magic numbers are fine, extract later
|
||||
- **Skip Edge Cases** — Happy path only for now
|
||||
- **Placeholder Everything** — Cubes, debug text, temp sounds
|
||||
- **Comment Intent** — Mark what's temporary vs keeper code
|
||||
|
||||
### After Prototyping
|
||||
|
||||
- **Develop** (`d`) - Use `quick-dev` to build production code
|
||||
- **Iterate** (`i`) - Adjust and re-test the prototype
|
||||
- **Archive** (`a`) - Keep as reference, move on to other ideas
|
||||
|
||||
---
|
||||
- **Develop** (`d`) — Use `quick-dev` to build production code
|
||||
- **Iterate** (`i`) — Adjust and re-test the prototype
|
||||
- **Archive** (`a`) — Keep as reference, move on to other ideas
|
||||
|
||||
## Quick-Dev
|
||||
|
||||
**Command:** `quick-dev`
|
||||
**Agent:** Game Developer
|
||||
**Purpose:** Flexible development with game-specific considerations
|
||||
Use `quick-dev` for flexible development with game-specific considerations.
|
||||
|
||||
### When to Use
|
||||
|
||||
@@ -120,172 +80,77 @@ Agent: Prototype complete! Playtest results:
|
||||
### Workflow Modes
|
||||
|
||||
**Mode A: Tech-Spec Driven**
|
||||
|
||||
```
|
||||
You: quick-dev tech-spec-combat.md
|
||||
Agent: [Loads spec, extracts tasks, implements]
|
||||
quick-dev tech-spec-combat.md
|
||||
```
|
||||
|
||||
**Mode B: Direct Instructions**
|
||||
|
||||
```
|
||||
You: quick-dev implement double-jump for the player
|
||||
Agent: [Evaluates complexity, offers planning options]
|
||||
quick-dev implement double-jump for the player
|
||||
```
|
||||
|
||||
**Mode C: From Prototype**
|
||||
|
||||
```
|
||||
You: quick-dev from the grappling hook prototype
|
||||
Agent: [Loads prototype, productionizes code]
|
||||
quick-dev from the grappling hook prototype
|
||||
```
|
||||
|
||||
### Game-Specific Checks
|
||||
|
||||
Quick-dev includes automatic consideration of:
|
||||
|
||||
- **Performance** - No allocations in hot paths, object pooling
|
||||
- **Feel** - Input responsiveness, visual/audio feedback
|
||||
- **Integration** - Save/load, multiplayer sync, platform testing
|
||||
|
||||
### Example Session
|
||||
|
||||
```
|
||||
You: quick-dev implement enemy patrol behavior
|
||||
|
||||
Agent: This looks like a focused feature. Options:
|
||||
[t] Plan first - Create tech-spec (recommended)
|
||||
[r] Prototype first - Test the idea
|
||||
[e] Execute directly
|
||||
|
||||
You: e
|
||||
|
||||
Agent: Any additional guidance? (patterns, files, constraints)
|
||||
|
||||
You: Use the existing AIController base class. Enemies should
|
||||
patrol between waypoints and return if player leaves range.
|
||||
|
||||
Agent: [Implements patrol behavior]
|
||||
|
||||
Agent: Implementation Complete!
|
||||
Files Modified: EnemyAI.cs, PatrolBehavior.cs
|
||||
Tests: Unit tests added for patrol state machine
|
||||
Performance: No per-frame allocations
|
||||
|
||||
Recommended: Playtest the changes
|
||||
```
|
||||
- **Performance** — No allocations in hot paths, object pooling
|
||||
- **Feel** — Input responsiveness, visual/audio feedback
|
||||
- **Integration** — Save/load, multiplayer sync, platform testing
|
||||
|
||||
### Complexity Routing
|
||||
|
||||
Quick-dev automatically detects complex requests and offers alternatives:
|
||||
|
||||
| Signals | Recommendation |
|
||||
| -------------------------------------- | ---------------------- |
|
||||
| Single mechanic, bug fix, tweak | Execute directly |
|
||||
| Signals | Recommendation |
|
||||
|---------|----------------|
|
||||
| Single mechanic, bug fix, tweak | Execute directly |
|
||||
| Multiple systems, performance-critical | Plan first (tech-spec) |
|
||||
| Platform/system level work | Use full BMGD workflow |
|
||||
|
||||
---
|
||||
| Platform/system level work | Use full BMGD workflow |
|
||||
|
||||
## Choosing Between Quick-Flows
|
||||
|
||||
| Scenario | Use |
|
||||
| ----------------------- | ------------------------------- |
|
||||
| "Will this be fun?" | `quick-prototype` |
|
||||
| "How should this feel?" | `quick-prototype` |
|
||||
| "Build this feature" | `quick-dev` |
|
||||
| "Fix this bug" | `quick-dev` |
|
||||
| "Test then build" | `quick-prototype` → `quick-dev` |
|
||||
| Scenario | Use |
|
||||
|----------|-----|
|
||||
| "Will this be fun?" | `quick-prototype` |
|
||||
| "How should this feel?" | `quick-prototype` |
|
||||
| "Build this feature" | `quick-dev` |
|
||||
| "Fix this bug" | `quick-dev` |
|
||||
| "Test then build" | `quick-prototype` → `quick-dev` |
|
||||
|
||||
---
|
||||
## Flow Comparison
|
||||
|
||||
## Quick-Flow vs Full BMGD
|
||||
```
|
||||
Full BMGD Flow:
|
||||
Brief → GDD → Architecture → Sprint Planning → Stories → Implementation
|
||||
|
||||
### Use Quick-Flow When
|
||||
|
||||
- The scope is small and well-understood
|
||||
- You're experimenting or prototyping
|
||||
- You have a clear tech-spec already
|
||||
- The work doesn't affect core game systems significantly
|
||||
|
||||
### Use Full BMGD When
|
||||
|
||||
- Building a major feature or system
|
||||
- The scope is unclear or large
|
||||
- Multiple team members need alignment
|
||||
- The work affects game pillars or core loop
|
||||
- You need documentation for future reference
|
||||
|
||||
---
|
||||
Quick-Flow:
|
||||
Idea → Quick-Prototype → Quick-Dev → Done
|
||||
```
|
||||
|
||||
## Checklists
|
||||
|
||||
### Quick-Prototype Checklist
|
||||
|
||||
**Before:**
|
||||
|
||||
**Quick-Prototype:**
|
||||
- [ ] Prototype scope defined
|
||||
- [ ] Success criteria established (2-3 items)
|
||||
|
||||
**During:**
|
||||
|
||||
- [ ] Minimum viable code written
|
||||
- [ ] Placeholder assets used
|
||||
- [ ] Core functionality testable
|
||||
|
||||
**After:**
|
||||
|
||||
- [ ] Each criterion evaluated
|
||||
- [ ] Decision made (develop/iterate/archive)
|
||||
|
||||
### Quick-Dev Checklist
|
||||
|
||||
**Before:**
|
||||
|
||||
**Quick-Dev:**
|
||||
- [ ] Context loaded (spec, prototype, or guidance)
|
||||
- [ ] Files to modify identified
|
||||
- [ ] Patterns understood
|
||||
|
||||
**During:**
|
||||
|
||||
- [ ] All tasks completed
|
||||
- [ ] No allocations in hot paths
|
||||
- [ ] Frame rate maintained
|
||||
|
||||
**After:**
|
||||
|
||||
- [ ] Game runs without errors
|
||||
- [ ] Feature works as specified
|
||||
- [ ] Manual playtest completed
|
||||
|
||||
---
|
||||
## Tips
|
||||
|
||||
## Tips for Success
|
||||
|
||||
### 1. Timebox Prototypes
|
||||
|
||||
Set a limit (e.g., 2 hours) for prototyping. If it's not working by then, step back and reconsider.
|
||||
|
||||
### 2. Embrace Programmer Art
|
||||
|
||||
Prototypes don't need to look good. Focus on feel, not visuals.
|
||||
|
||||
### 3. Test on Target Hardware
|
||||
|
||||
What feels right on your dev machine might not feel right on target platform.
|
||||
|
||||
### 4. Document Learnings
|
||||
|
||||
Even failed prototypes teach something. Note what you learned.
|
||||
|
||||
### 5. Know When to Graduate
|
||||
|
||||
If quick-dev keeps expanding scope, stop and create proper stories.
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
- **[Workflows Guide](/docs/reference/workflows/bmgd-workflows.md)** - Full workflow reference
|
||||
- **[Agents Guide](/docs/explanation/game-dev/agents.md)** - Agent capabilities
|
||||
- **[Quick Start Guide](/docs/tutorials/getting-started/quick-start-bmgd.md)** - Getting started with BMGD
|
||||
- **Timebox prototypes** — Set a limit (e.g., 2 hours). If it's not working, step back
|
||||
- **Embrace programmer art** — Focus on feel, not visuals
|
||||
- **Test on target hardware** — What feels right on dev machine might not on target
|
||||
- **Document learnings** — Even failed prototypes teach something
|
||||
- **Know when to graduate** — If quick-dev keeps expanding scope, create proper stories
|
||||
|
||||
@@ -3,11 +3,8 @@ title: "How to Conduct Research"
|
||||
description: How to conduct market, technical, and competitive research using BMad Method
|
||||
---
|
||||
|
||||
|
||||
Use the `research` workflow to perform comprehensive multi-type research for validating ideas, understanding markets, and making informed decisions.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This
|
||||
|
||||
- Need market viability validation
|
||||
@@ -17,14 +14,10 @@ Use the `research` workflow to perform comprehensive multi-type research for val
|
||||
- Understanding domain or industry
|
||||
- Need deeper AI-assisted research
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed
|
||||
- Analyst agent available
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -42,14 +35,14 @@ Start a fresh chat and load the Analyst agent.
|
||||
|
||||
Select the type of research you need:
|
||||
|
||||
| Type | Purpose | Use When |
|
||||
| --------------- | ------------------------------------------------------ | ----------------------------------- |
|
||||
| **market** | TAM/SAM/SOM, competitive analysis | Need market viability validation |
|
||||
| **technical** | Technology evaluation, ADRs | Choosing frameworks/platforms |
|
||||
| **competitive** | Deep competitor analysis | Understanding competitive landscape |
|
||||
| **user** | Customer insights, personas, JTBD | Need user understanding |
|
||||
| **domain** | Industry deep dives, trends | Understanding domain/industry |
|
||||
| **deep_prompt** | Generate AI research prompts (ChatGPT, Claude, Gemini) | Need deeper AI-assisted research |
|
||||
| Type | Purpose | Use When |
|
||||
|------|---------|----------|
|
||||
| **market** | TAM/SAM/SOM, competitive analysis | Need market viability validation |
|
||||
| **technical** | Technology evaluation, ADRs | Choosing frameworks/platforms |
|
||||
| **competitive** | Deep competitor analysis | Understanding competitive landscape |
|
||||
| **user** | Customer insights, personas, JTBD | Need user understanding |
|
||||
| **domain** | Industry deep dives, trends | Understanding domain/industry |
|
||||
| **deep_prompt** | Generate AI research prompts | Need deeper AI-assisted research |
|
||||
|
||||
### 4. Provide Context
|
||||
|
||||
@@ -63,38 +56,24 @@ Give the agent details about what you're researching:
|
||||
|
||||
Choose your depth level:
|
||||
|
||||
- **Quick** - Fast overview
|
||||
- **Standard** - Balanced depth
|
||||
- **Comprehensive** - Deep analysis
|
||||
|
||||
---
|
||||
- **Quick** — Fast overview
|
||||
- **Standard** — Balanced depth
|
||||
- **Comprehensive** — Deep analysis
|
||||
|
||||
## What You Get
|
||||
|
||||
### Market Research Example
|
||||
Research output varies by type:
|
||||
|
||||
```
|
||||
TAM: $50B
|
||||
SAM: $5B
|
||||
SOM: $50M
|
||||
**Market Research:**
|
||||
- TAM/SAM/SOM analysis
|
||||
- Top competitors
|
||||
- Positioning recommendation
|
||||
|
||||
Top Competitors:
|
||||
- Asana
|
||||
- Monday
|
||||
- etc.
|
||||
|
||||
Positioning Recommendation: ...
|
||||
```
|
||||
|
||||
### Technical Research Example
|
||||
|
||||
Technology evaluation with:
|
||||
**Technical Research:**
|
||||
- Comparison matrix
|
||||
- Trade-off analysis
|
||||
- Recommendations with rationale
|
||||
|
||||
---
|
||||
|
||||
## Key Features
|
||||
|
||||
- Real-time web research
|
||||
@@ -102,29 +81,17 @@ Technology evaluation with:
|
||||
- Platform-specific optimization for deep_prompt type
|
||||
- Configurable research depth
|
||||
|
||||
---
|
||||
## Tips
|
||||
|
||||
- **Use market research early** — Validates new product ideas
|
||||
- **Technical research helps architecture** — Inform ADRs with data
|
||||
- **Competitive research informs positioning** — Differentiate your product
|
||||
- **Domain research for specialized industries** — Fintech, healthcare, etc.
|
||||
|
||||
## Next Steps
|
||||
|
||||
After research:
|
||||
|
||||
1. **Product Brief** - Capture strategic vision informed by research
|
||||
2. **PRD** - Use findings as context for requirements
|
||||
3. **Architecture** - Use technical research in ADRs
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
- Use market research early for new products
|
||||
- Technical research helps with architecture decisions
|
||||
- Competitive research informs positioning
|
||||
- Domain research is valuable for specialized industries
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [Run Brainstorming Session](/docs/how-to/workflows/run-brainstorming-session.md) - Explore ideas before research
|
||||
- [Create Product Brief](/docs/how-to/workflows/create-product-brief.md) - Capture strategic vision
|
||||
- [Create PRD](/docs/how-to/workflows/create-prd.md) - Move to formal planning
|
||||
1. **Product Brief** — Capture strategic vision informed by research
|
||||
2. **PRD** — Use findings as context for requirements
|
||||
3. **Architecture** — Use technical research in ADRs
|
||||
|
||||
@@ -3,11 +3,8 @@ title: "How to Create Architecture"
|
||||
description: How to create system architecture using the BMad Method
|
||||
---
|
||||
|
||||
|
||||
Use the `architecture` workflow to make technical decisions explicit and prevent agent conflicts during implementation.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This
|
||||
|
||||
- Multi-epic projects (BMad Method, Enterprise)
|
||||
@@ -16,23 +13,17 @@ Use the `architecture` workflow to make technical decisions explicit and prevent
|
||||
- Integration complexity exists
|
||||
- Technology choices need alignment
|
||||
|
||||
---
|
||||
|
||||
## When to Skip This
|
||||
|
||||
- Quick Flow (simple changes)
|
||||
- BMad Method Simple with straightforward tech stack
|
||||
- Single epic with clear technical approach
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed
|
||||
- Architect agent available
|
||||
- PRD completed
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -63,25 +54,21 @@ Work with the agent to create Architecture Decision Records (ADRs) for significa
|
||||
|
||||
The agent produces a decision-focused architecture document.
|
||||
|
||||
---
|
||||
|
||||
## What You Get
|
||||
|
||||
An `architecture.md` document containing:
|
||||
|
||||
1. **Architecture Overview** - System context, principles, style
|
||||
2. **System Architecture** - High-level diagram, component interactions
|
||||
3. **Data Architecture** - Database design, state management, caching
|
||||
4. **API Architecture** - API style (REST/GraphQL/gRPC), auth, versioning
|
||||
5. **Frontend Architecture** - Framework, state management, components
|
||||
6. **Integration Architecture** - Third-party integrations, messaging
|
||||
7. **Security Architecture** - Auth/authorization, data protection
|
||||
8. **Deployment Architecture** - CI/CD, environments, monitoring
|
||||
9. **ADRs** - Key decisions with context, options, rationale
|
||||
10. **FR/NFR-Specific Guidance** - Technical approach per requirement
|
||||
11. **Standards and Conventions** - Directory structure, naming, testing
|
||||
|
||||
---
|
||||
1. **Architecture Overview** — System context, principles, style
|
||||
2. **System Architecture** — High-level diagram, component interactions
|
||||
3. **Data Architecture** — Database design, state management, caching
|
||||
4. **API Architecture** — API style (REST/GraphQL/gRPC), auth, versioning
|
||||
5. **Frontend Architecture** — Framework, state management, components
|
||||
6. **Integration Architecture** — Third-party integrations, messaging
|
||||
7. **Security Architecture** — Auth/authorization, data protection
|
||||
8. **Deployment Architecture** — CI/CD, environments, monitoring
|
||||
9. **ADRs** — Key decisions with context, options, rationale
|
||||
10. **FR/NFR-Specific Guidance** — Technical approach per requirement
|
||||
11. **Standards and Conventions** — Directory structure, naming, testing
|
||||
|
||||
## ADR Format
|
||||
|
||||
@@ -110,8 +97,6 @@ An `architecture.md` document containing:
|
||||
- Mitigation: Use DataLoader for batching
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
E-commerce platform produces:
|
||||
@@ -119,29 +104,16 @@ E-commerce platform produces:
|
||||
- ADRs explaining each choice
|
||||
- FR/NFR-specific implementation guidance
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
- Focus on decisions that prevent agent conflicts
|
||||
- Use ADRs for every significant technology choice
|
||||
- Keep it practical - don't over-architect
|
||||
- Architecture is living - update as you learn
|
||||
|
||||
---
|
||||
- **Focus on decisions that prevent conflicts** — Multiple agents need alignment
|
||||
- **Use ADRs for every significant choice** — Document the "why"
|
||||
- **Keep it practical** — Don't over-architect
|
||||
- **Architecture is living** — Update as you learn
|
||||
|
||||
## Next Steps
|
||||
|
||||
After architecture:
|
||||
|
||||
1. **Create Epics and Stories** - Work breakdown informed by architecture
|
||||
2. **Implementation Readiness** - Gate check before Phase 4
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [Create PRD](/docs/how-to/workflows/create-prd.md) - Requirements before architecture
|
||||
- [Create Epics and Stories](/docs/how-to/workflows/create-epics-and-stories.md) - Next step
|
||||
- [Run Implementation Readiness](/docs/how-to/workflows/run-implementation-readiness.md) - Gate check
|
||||
- [Why Solutioning Matters](/docs/explanation/architecture/why-solutioning-matters.md)
|
||||
1. **Create Epics and Stories** — Work breakdown informed by architecture
|
||||
2. **Implementation Readiness** — Gate check before Phase 4
|
||||
|
||||
@@ -3,38 +3,29 @@ title: "How to Create Epics and Stories"
|
||||
description: How to break PRD requirements into epics and stories using BMad Method
|
||||
---
|
||||
|
||||
|
||||
Use the `create-epics-and-stories` workflow to transform PRD requirements into bite-sized stories organized into deliverable epics.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This
|
||||
|
||||
- After architecture workflow completes
|
||||
- When PRD contains FRs/NFRs ready for implementation breakdown
|
||||
- Before implementation-readiness gate check
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed
|
||||
- PM agent available
|
||||
- PRD completed
|
||||
- Architecture completed
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Why After Architecture?
|
||||
|
||||
This workflow runs AFTER architecture because:
|
||||
|
||||
1. **Informed Story Sizing** - Architecture decisions affect story complexity
|
||||
2. **Dependency Awareness** - Architecture reveals technical dependencies
|
||||
3. **Technical Feasibility** - Stories can be properly scoped knowing the tech stack
|
||||
4. **Consistency** - All stories align with documented architectural patterns
|
||||
|
||||
---
|
||||
1. **Informed Story Sizing** — Architecture decisions affect story complexity
|
||||
2. **Dependency Awareness** — Architecture reveals technical dependencies
|
||||
3. **Technical Feasibility** — Stories can be properly scoped knowing the tech stack
|
||||
4. **Consistency** — All stories align with documented architectural patterns
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -67,8 +58,6 @@ Ensure each story has:
|
||||
- Identified dependencies
|
||||
- Technical notes from architecture
|
||||
|
||||
---
|
||||
|
||||
## What You Get
|
||||
|
||||
Epic files (one per epic) containing:
|
||||
@@ -79,8 +68,6 @@ Epic files (one per epic) containing:
|
||||
4. **Dependencies between stories**
|
||||
5. **Technical notes** referencing architecture decisions
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
E-commerce PRD with FR-001 (User Registration), FR-002 (Product Catalog) produces:
|
||||
@@ -98,39 +85,25 @@ E-commerce PRD with FR-001 (User Registration), FR-002 (Product Catalog) produce
|
||||
|
||||
Each story references relevant ADRs from architecture.
|
||||
|
||||
---
|
||||
|
||||
## Story Priority Levels
|
||||
|
||||
| Priority | Meaning |
|
||||
|----------|---------|
|
||||
| **P0** | Critical - Must have for MVP |
|
||||
| **P1** | High - Important for release |
|
||||
| **P2** | Medium - Nice to have |
|
||||
| **P3** | Low - Future consideration |
|
||||
|
||||
---
|
||||
| **P0** | Critical — Must have for MVP |
|
||||
| **P1** | High — Important for release |
|
||||
| **P2** | Medium — Nice to have |
|
||||
| **P3** | Low — Future consideration |
|
||||
|
||||
## Tips
|
||||
|
||||
- Keep stories small enough to complete in a session
|
||||
- Ensure acceptance criteria are testable
|
||||
- Document dependencies clearly
|
||||
- Reference architecture decisions in technical notes
|
||||
|
||||
---
|
||||
- **Keep stories small** — Complete in a single session
|
||||
- **Make criteria testable** — Acceptance criteria should be verifiable
|
||||
- **Document dependencies clearly** — Know what blocks what
|
||||
- **Reference architecture** — Include ADR references in technical notes
|
||||
|
||||
## Next Steps
|
||||
|
||||
After creating epics and stories:
|
||||
|
||||
1. **Implementation Readiness** - Validate alignment before Phase 4
|
||||
2. **Sprint Planning** - Organize work for implementation
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [Create Architecture](/docs/how-to/workflows/create-architecture.md) - Do this first
|
||||
- [Run Implementation Readiness](/docs/how-to/workflows/run-implementation-readiness.md) - Gate check
|
||||
- [Run Sprint Planning](/docs/how-to/workflows/run-sprint-planning.md) - Start implementation
|
||||
1. **Implementation Readiness** — Validate alignment before Phase 4
|
||||
2. **Sprint Planning** — Organize work for implementation
|
||||
|
||||
@@ -3,11 +3,8 @@ title: "How to Create a PRD"
|
||||
description: How to create a Product Requirements Document using the BMad Method
|
||||
---
|
||||
|
||||
|
||||
Use the `prd` workflow to create a strategic Product Requirements Document with Functional Requirements (FRs) and Non-Functional Requirements (NFRs).
|
||||
|
||||
---
|
||||
|
||||
## When to Use This
|
||||
|
||||
- Medium to large feature sets
|
||||
@@ -16,15 +13,11 @@ Use the `prd` workflow to create a strategic Product Requirements Document with
|
||||
- Multiple system integrations
|
||||
- Phased delivery required
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed
|
||||
- PM agent available
|
||||
- Optional: Product brief from Phase 1
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -48,15 +41,13 @@ The workflow will:
|
||||
### 4. Define Requirements
|
||||
|
||||
Work with the agent to define:
|
||||
- Functional Requirements (FRs) - What the system should do
|
||||
- Non-Functional Requirements (NFRs) - How well it should do it
|
||||
- Functional Requirements (FRs) — What the system should do
|
||||
- Non-Functional Requirements (NFRs) — How well it should do it
|
||||
|
||||
### 5. Review the PRD
|
||||
|
||||
The agent produces a comprehensive PRD scaled to your project.
|
||||
|
||||
---
|
||||
|
||||
## What You Get
|
||||
|
||||
A `PRD.md` document containing:
|
||||
@@ -69,8 +60,6 @@ A `PRD.md` document containing:
|
||||
- Success metrics
|
||||
- Risks and assumptions
|
||||
|
||||
---
|
||||
|
||||
## Scale-Adaptive Structure
|
||||
|
||||
The PRD adapts to your project complexity:
|
||||
@@ -81,50 +70,22 @@ The PRD adapts to your project complexity:
|
||||
| **Standard** | 20-30 | Comprehensive FRs/NFRs, thorough analysis |
|
||||
| **Comprehensive** | 30-50+ | Extensive FRs/NFRs, multi-phase, stakeholder analysis |
|
||||
|
||||
---
|
||||
|
||||
## V6 Improvement
|
||||
|
||||
In V6, the PRD focuses on **WHAT** to build (requirements). Epic and Stories are created **AFTER** architecture via the `create-epics-and-stories` workflow for better quality.
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
E-commerce checkout → PRD with:
|
||||
- 15 FRs (user account, cart management, payment flow)
|
||||
- 8 NFRs (performance, security, scalability)
|
||||
|
||||
---
|
||||
## Tips
|
||||
|
||||
## Best Practices
|
||||
|
||||
### 1. Do Product Brief First
|
||||
|
||||
Run product-brief from Phase 1 to kickstart the PRD for better results.
|
||||
|
||||
### 2. Focus on "What" Not "How"
|
||||
|
||||
Planning defines **what** to build and **why**. Leave **how** (technical design) to Phase 3 (Solutioning).
|
||||
|
||||
### 3. Document-Project First for Brownfield
|
||||
|
||||
Always run `document-project` before planning brownfield projects. AI agents need existing codebase context.
|
||||
|
||||
---
|
||||
- **Do Product Brief first** — Run product-brief from Phase 1 for better results
|
||||
- **Focus on "What" not "How"** — Planning defines what to build and why. Leave how (technical design) to Phase 3
|
||||
- **Document-Project first for Brownfield** — Always run `document-project` before planning brownfield projects. AI agents need existing codebase context
|
||||
|
||||
## Next Steps
|
||||
|
||||
After PRD:
|
||||
|
||||
1. **Create UX Design** (optional) - If UX is critical
|
||||
2. **Create Architecture** - Technical design
|
||||
3. **Create Epics and Stories** - After architecture
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [Create Product Brief](/docs/how-to/workflows/create-product-brief.md) - Input for PRD
|
||||
- [Create UX Design](/docs/how-to/workflows/create-ux-design.md) - Optional UX workflow
|
||||
- [Create Architecture](/docs/how-to/workflows/create-architecture.md) - Next step after PRD
|
||||
1. **Create UX Design** (optional) — If UX is critical
|
||||
2. **Create Architecture** — Technical design
|
||||
3. **Create Epics and Stories** — After architecture
|
||||
|
||||
@@ -3,11 +3,8 @@ title: "How to Create a Product Brief"
|
||||
description: How to create a product brief using the BMad Method
|
||||
---
|
||||
|
||||
|
||||
Use the `product-brief` workflow to define product vision and strategy through an interactive process.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This
|
||||
|
||||
- Starting new product or major feature initiative
|
||||
@@ -15,15 +12,11 @@ Use the `product-brief` workflow to define product vision and strategy through a
|
||||
- Transitioning from exploration to strategy
|
||||
- Need executive-level product documentation
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed
|
||||
- Analyst agent available
|
||||
- Optional: Research documents from previous workflows
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -50,22 +43,18 @@ The workflow guides you through strategic product vision definition:
|
||||
|
||||
The agent will draft sections and let you refine them interactively.
|
||||
|
||||
---
|
||||
|
||||
## What You Get
|
||||
|
||||
The `product-brief.md` document includes:
|
||||
|
||||
- **Executive summary** - High-level overview
|
||||
- **Problem statement** - With evidence
|
||||
- **Proposed solution** - And differentiators
|
||||
- **Target users** - Segmented
|
||||
- **MVP scope** - Ruthlessly defined
|
||||
- **Financial impact** - And ROI
|
||||
- **Strategic alignment** - With business goals
|
||||
- **Risks and open questions** - Documented upfront
|
||||
|
||||
---
|
||||
- **Executive summary** — High-level overview
|
||||
- **Problem statement** — With evidence
|
||||
- **Proposed solution** — And differentiators
|
||||
- **Target users** — Segmented
|
||||
- **MVP scope** — Ruthlessly defined
|
||||
- **Financial impact** — And ROI
|
||||
- **Strategic alignment** — With business goals
|
||||
- **Risks and open questions** — Documented upfront
|
||||
|
||||
## Integration with Other Workflows
|
||||
|
||||
@@ -79,11 +68,9 @@ The product brief feeds directly into the PRD workflow:
|
||||
|
||||
Planning workflows automatically load the product brief if it exists.
|
||||
|
||||
---
|
||||
|
||||
## Common Patterns
|
||||
|
||||
### Greenfield Software (Full Analysis)
|
||||
**Greenfield Software (Full Analysis):**
|
||||
|
||||
```
|
||||
1. brainstorm-project - explore approaches
|
||||
@@ -92,26 +79,16 @@ Planning workflows automatically load the product brief if it exists.
|
||||
4. → Phase 2: prd
|
||||
```
|
||||
|
||||
### Skip Analysis (Clear Requirements)
|
||||
**Skip Analysis (Clear Requirements):**
|
||||
|
||||
```
|
||||
→ Phase 2: prd or tech-spec directly
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
- Be specific about the problem you're solving
|
||||
- Ruthlessly prioritize MVP scope
|
||||
- Document assumptions and risks
|
||||
- Use research findings as evidence
|
||||
- This is recommended for greenfield projects
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [Run Brainstorming Session](/docs/how-to/workflows/run-brainstorming-session.md) - Explore ideas first
|
||||
- [Conduct Research](/docs/how-to/workflows/conduct-research.md) - Validate ideas
|
||||
- [Create PRD](/docs/how-to/workflows/create-prd.md) - Next step after product brief
|
||||
- **Be specific about the problem** — Vague problems lead to vague solutions
|
||||
- **Ruthlessly prioritize MVP scope** — Less is more
|
||||
- **Document assumptions and risks** — Surface unknowns early
|
||||
- **Use research findings as evidence** — Back up claims with data
|
||||
- **Recommended for greenfield projects** — Sets strategic foundation
|
||||
|
||||
@@ -3,27 +3,20 @@ title: "How to Create a Story"
|
||||
description: How to create implementation-ready stories from epic backlog
|
||||
---
|
||||
|
||||
|
||||
Use the `create-story` workflow to prepare the next story from the epic backlog for implementation.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This
|
||||
|
||||
- Before implementing each story
|
||||
- When moving to the next story in an epic
|
||||
- After sprint-planning has been run
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed
|
||||
- SM (Scrum Master) agent available
|
||||
- Sprint-status.yaml created by sprint-planning
|
||||
- Architecture and PRD available for context
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -48,8 +41,6 @@ The agent will:
|
||||
|
||||
The agent creates a comprehensive story file ready for development.
|
||||
|
||||
---
|
||||
|
||||
## What You Get
|
||||
|
||||
A `story-[slug].md` file containing:
|
||||
@@ -61,23 +52,18 @@ A `story-[slug].md` file containing:
|
||||
- Dependencies on other stories
|
||||
- Definition of Done
|
||||
|
||||
---
|
||||
|
||||
## Story Content Sources
|
||||
|
||||
The create-story workflow pulls from:
|
||||
|
||||
- **PRD** - Requirements and acceptance criteria
|
||||
- **Architecture** - Technical approach and ADRs
|
||||
- **Epic file** - Story context and dependencies
|
||||
- **Existing code** - Patterns to follow (brownfield)
|
||||
|
||||
---
|
||||
- **PRD** — Requirements and acceptance criteria
|
||||
- **Architecture** — Technical approach and ADRs
|
||||
- **Epic file** — Story context and dependencies
|
||||
- **Existing code** — Patterns to follow (brownfield)
|
||||
|
||||
## Example Output
|
||||
|
||||
```markdown
|
||||
|
||||
## Objective
|
||||
Implement email verification flow for new user registrations.
|
||||
|
||||
@@ -93,7 +79,7 @@ Implement email verification flow for new user registrations.
|
||||
- Follow existing email template patterns in /templates
|
||||
|
||||
## Dependencies
|
||||
- Story 1.1 (User Registration) - DONE ✅
|
||||
- Story 1.1 (User Registration) - DONE
|
||||
|
||||
## Definition of Done
|
||||
- All acceptance criteria pass
|
||||
@@ -101,19 +87,16 @@ Implement email verification flow for new user registrations.
|
||||
- Code review approved
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
- Complete one story before creating the next
|
||||
- Ensure dependencies are marked DONE before starting
|
||||
- Review technical notes for architecture alignment
|
||||
- Use the story file as context for dev-story
|
||||
- **Complete one story before creating the next** — Focus on finishing
|
||||
- **Ensure dependencies are DONE** — Don't start blocked stories
|
||||
- **Review technical notes** — Align with architecture
|
||||
- **Use the story file as context** — Pass to dev-story workflow
|
||||
|
||||
---
|
||||
## Next Steps
|
||||
|
||||
## Related
|
||||
After creating a story:
|
||||
|
||||
- [Run Sprint Planning](/docs/how-to/workflows/run-sprint-planning.md) - Initialize tracking
|
||||
- [Implement Story](/docs/how-to/workflows/implement-story.md) - Next step
|
||||
- [Run Code Review](/docs/how-to/workflows/run-code-review.md) - After implementation
|
||||
1. **Implement Story** — Run dev-story with the DEV agent
|
||||
2. **Code Review** — Run code-review after implementation
|
||||
|
||||
@@ -3,11 +3,8 @@ title: "How to Create a UX Design"
|
||||
description: How to create UX specifications using the BMad Method
|
||||
---
|
||||
|
||||
|
||||
Use the `create-ux-design` workflow to create UX specifications for projects where user experience is a primary differentiator.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This
|
||||
|
||||
- UX is primary competitive advantage
|
||||
@@ -16,8 +13,6 @@ Use the `create-ux-design` workflow to create UX specifications for projects whe
|
||||
- Design system creation
|
||||
- Accessibility-critical experiences
|
||||
|
||||
---
|
||||
|
||||
## When to Skip This
|
||||
|
||||
- Simple CRUD interfaces
|
||||
@@ -25,15 +20,11 @@ Use the `create-ux-design` workflow to create UX specifications for projects whe
|
||||
- Changes to existing screens you're happy with
|
||||
- Quick Flow projects
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed
|
||||
- UX Designer agent available
|
||||
- PRD completed
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -58,17 +49,15 @@ Point the agent to your PRD and describe:
|
||||
|
||||
The workflow uses a collaborative approach:
|
||||
|
||||
1. **Visual exploration** - Generate multiple options
|
||||
2. **Informed decisions** - Evaluate with user needs
|
||||
3. **Collaborative design** - Refine iteratively
|
||||
4. **Living documentation** - Evolves with project
|
||||
1. **Visual exploration** — Generate multiple options
|
||||
2. **Informed decisions** — Evaluate with user needs
|
||||
3. **Collaborative design** — Refine iteratively
|
||||
4. **Living documentation** — Evolves with project
|
||||
|
||||
### 5. Review the UX Spec
|
||||
|
||||
The agent produces comprehensive UX documentation.
|
||||
|
||||
---
|
||||
|
||||
## What You Get
|
||||
|
||||
The `ux-spec.md` document includes:
|
||||
@@ -79,8 +68,6 @@ The `ux-spec.md` document includes:
|
||||
- Design system (components, patterns, tokens)
|
||||
- Epic breakdown (UX stories)
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
Dashboard redesign produces:
|
||||
@@ -90,8 +77,6 @@ Dashboard redesign produces:
|
||||
- Responsive grid
|
||||
- 3 epics (Layout, Visualization, Accessibility)
|
||||
|
||||
---
|
||||
|
||||
## Integration
|
||||
|
||||
The UX spec feeds into:
|
||||
@@ -99,19 +84,17 @@ The UX spec feeds into:
|
||||
- Epic and story creation
|
||||
- Architecture decisions (Phase 3)
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
- Focus on user problems, not solutions first
|
||||
- Generate multiple options before deciding
|
||||
- Consider accessibility from the start
|
||||
- Document component reusability
|
||||
- **Focus on user problems first** — Solutions come second
|
||||
- **Generate multiple options** — Don't settle on the first idea
|
||||
- **Consider accessibility from the start** — Not an afterthought
|
||||
- **Document component reusability** — Build a system, not just screens
|
||||
|
||||
---
|
||||
## Next Steps
|
||||
|
||||
## Related
|
||||
After UX design:
|
||||
|
||||
- [Create PRD](/docs/how-to/workflows/create-prd.md) - Create requirements first
|
||||
- [Create Architecture](/docs/how-to/workflows/create-architecture.md) - Technical design
|
||||
- [Create Epics and Stories](/docs/how-to/workflows/create-epics-and-stories.md) - Work breakdown
|
||||
1. **Update PRD** — Incorporate UX findings
|
||||
2. **Create Architecture** — Technical design informed by UX
|
||||
3. **Create Epics and Stories** — Include UX-specific stories
|
||||
|
||||
@@ -3,27 +3,20 @@ title: "How to Implement a Story"
|
||||
description: How to implement a story using the dev-story workflow
|
||||
---
|
||||
|
||||
|
||||
Use the `dev-story` workflow to implement a story with tests following the architecture and conventions.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This
|
||||
|
||||
- After create-story has prepared the story file
|
||||
- When ready to write code for a story
|
||||
- Story dependencies are marked DONE
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed
|
||||
- DEV agent available
|
||||
- Story file created by create-story
|
||||
- Architecture and tech-spec available for context
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -53,75 +46,52 @@ The DEV agent:
|
||||
|
||||
Work with the agent until all acceptance criteria are met.
|
||||
|
||||
---
|
||||
|
||||
## What Happens
|
||||
|
||||
The dev-story workflow:
|
||||
|
||||
1. **Reads context** - Story file, architecture, existing patterns
|
||||
2. **Plans implementation** - Identifies files to create/modify
|
||||
3. **Writes code** - Following conventions and patterns
|
||||
4. **Writes tests** - Unit, integration, or E2E as appropriate
|
||||
5. **Validates** - Runs tests and checks acceptance criteria
|
||||
|
||||
---
|
||||
1. **Reads context** — Story file, architecture, existing patterns
|
||||
2. **Plans implementation** — Identifies files to create/modify
|
||||
3. **Writes code** — Following conventions and patterns
|
||||
4. **Writes tests** — Unit, integration, or E2E as appropriate
|
||||
5. **Validates** — Runs tests and checks acceptance criteria
|
||||
|
||||
## Key Principles
|
||||
|
||||
### One Story at a Time
|
||||
**One Story at a Time** — Complete each story's full lifecycle before starting the next. This prevents context switching and ensures quality.
|
||||
|
||||
Complete each story's full lifecycle before starting the next. This prevents context switching and ensures quality.
|
||||
**Follow Architecture** — The DEV agent references ADRs for technology decisions, standards for naming and structure, and existing patterns in the codebase.
|
||||
|
||||
### Follow Architecture
|
||||
|
||||
The DEV agent references:
|
||||
- ADRs for technology decisions
|
||||
- Standards for naming and structure
|
||||
- Existing patterns in the codebase
|
||||
|
||||
### Write Tests
|
||||
|
||||
Every story includes appropriate tests:
|
||||
- Unit tests for business logic
|
||||
- Integration tests for API endpoints
|
||||
- E2E tests for critical flows
|
||||
|
||||
---
|
||||
**Write Tests** — Every story includes appropriate tests: unit tests for business logic, integration tests for API endpoints, E2E tests for critical flows.
|
||||
|
||||
## After Implementation
|
||||
|
||||
1. **Update sprint-status.yaml** - Mark story as READY FOR REVIEW
|
||||
2. **Run code-review** - Quality assurance
|
||||
3. **Address feedback** - If code review finds issues
|
||||
4. **Mark DONE** - After code review passes
|
||||
|
||||
---
|
||||
1. **Update sprint-status.yaml** — Mark story as READY FOR REVIEW
|
||||
2. **Run code-review** — Quality assurance
|
||||
3. **Address feedback** — If code review finds issues
|
||||
4. **Mark DONE** — After code review passes
|
||||
|
||||
## Tips
|
||||
|
||||
- Keep the story file open for reference
|
||||
- Ask the agent to explain decisions
|
||||
- Run tests frequently during implementation
|
||||
- Don't skip tests for "simple" changes
|
||||
|
||||
---
|
||||
- **Keep the story file open** — Reference it during implementation
|
||||
- **Ask the agent to explain decisions** — Understand the approach
|
||||
- **Run tests frequently** — Catch issues early
|
||||
- **Don't skip tests** — Even for "simple" changes
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Q: Story needs significant changes mid-implementation?**
|
||||
A: Run `correct-course` to analyze impact and route appropriately.
|
||||
**Story needs significant changes mid-implementation?**
|
||||
Run `correct-course` to analyze impact and route appropriately.
|
||||
|
||||
**Q: Can I work on multiple stories in parallel?**
|
||||
A: Not recommended. Complete one story's full lifecycle first.
|
||||
**Can I work on multiple stories in parallel?**
|
||||
Not recommended. Complete one story's full lifecycle first.
|
||||
|
||||
**Q: What if implementation reveals the story is too large?**
|
||||
A: Split the story and document the change.
|
||||
**What if implementation reveals the story is too large?**
|
||||
Split the story and document the change.
|
||||
|
||||
---
|
||||
## Next Steps
|
||||
|
||||
## Related
|
||||
After implementing a story:
|
||||
|
||||
- [Create Story](/docs/how-to/workflows/create-story.md) - Prepare the story first
|
||||
- [Run Code Review](/docs/how-to/workflows/run-code-review.md) - After implementation
|
||||
- [Run Sprint Planning](/docs/how-to/workflows/run-sprint-planning.md) - Sprint organization
|
||||
1. **Code Review** — Run code-review with the DEV agent
|
||||
2. **Create Next Story** — Run create-story with the SM agent
|
||||
|
||||
@@ -3,10 +3,7 @@ title: "How to Use Quick Spec"
|
||||
description: How to create a technical specification using Quick Spec workflow
|
||||
---
|
||||
|
||||
|
||||
Use the `tech-spec` workflow for Quick Flow projects to go directly from idea to implementation-ready specification.
|
||||
|
||||
---
|
||||
Use the `quick-spec` workflow for Quick Flow projects to go directly from idea to implementation-ready specification.
|
||||
|
||||
## When to Use This
|
||||
|
||||
@@ -16,15 +13,11 @@ Use the `tech-spec` workflow for Quick Flow projects to go directly from idea to
|
||||
- Adding to existing brownfield codebase
|
||||
- Quick Flow track projects
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed
|
||||
- PM agent or Quick Flow Solo Dev agent available
|
||||
- Project directory (can be empty for greenfield)
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -63,12 +56,9 @@ For brownfield projects, the agent will:
|
||||
|
||||
The agent generates a comprehensive tech-spec with ready-to-implement stories.
|
||||
|
||||
---
|
||||
|
||||
## What You Get
|
||||
|
||||
### tech-spec.md
|
||||
|
||||
**tech-spec.md:**
|
||||
- Problem statement and solution
|
||||
- Detected framework versions and dependencies
|
||||
- Brownfield code patterns (if applicable)
|
||||
@@ -76,18 +66,11 @@ The agent generates a comprehensive tech-spec with ready-to-implement stories.
|
||||
- Specific file paths to modify
|
||||
- Complete implementation guidance
|
||||
|
||||
### Story Files
|
||||
**Story Files:**
|
||||
- Single changes: `story-[slug].md`
|
||||
- Small features: `epics.md` + `story-[epic-slug]-1.md`, etc.
|
||||
|
||||
For single changes:
|
||||
- `story-[slug].md` - Single user story ready for development
|
||||
|
||||
For small features:
|
||||
- `epics.md` - Epic organization
|
||||
- `story-[epic-slug]-1.md`, `story-[epic-slug]-2.md`, etc.
|
||||
|
||||
---
|
||||
|
||||
## Example: Bug Fix (Single Change)
|
||||
## Example: Bug Fix
|
||||
|
||||
**You:** "I want to fix the login validation bug that allows empty passwords"
|
||||
|
||||
@@ -99,11 +82,7 @@ For small features:
|
||||
5. Generates tech-spec.md with specific file paths
|
||||
6. Creates story-login-fix.md
|
||||
|
||||
**Total time:** 15-30 minutes (mostly implementation)
|
||||
|
||||
---
|
||||
|
||||
## Example: Small Feature (Multi-Story)
|
||||
## Example: Small Feature
|
||||
|
||||
**You:** "I want to add OAuth social login (Google, GitHub)"
|
||||
|
||||
@@ -118,10 +97,6 @@ For small features:
|
||||
- story-oauth-1.md (Backend OAuth setup)
|
||||
- story-oauth-2.md (Frontend login buttons)
|
||||
|
||||
**Total time:** 1-3 hours (mostly implementation)
|
||||
|
||||
---
|
||||
|
||||
## Implementing After Tech Spec
|
||||
|
||||
```bash
|
||||
@@ -133,27 +108,15 @@ For small features:
|
||||
# Then: Load DEV agent and run dev-story for each story
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
### Be Specific in Discovery
|
||||
- **Be specific in discovery** — "Fix email validation in UserService to allow plus-addressing" beats "Fix validation bug"
|
||||
- **Trust convention detection** — If it detects your patterns correctly, say yes! It's faster than establishing new conventions
|
||||
- **Keep single changes atomic** — If your "single change" needs 3+ files, it might be a multi-story feature. Let the workflow guide you
|
||||
|
||||
- ✅ "Fix email validation in UserService to allow plus-addressing"
|
||||
- ❌ "Fix validation bug"
|
||||
## Next Steps
|
||||
|
||||
### Trust Convention Detection
|
||||
After tech spec:
|
||||
|
||||
If it detects your patterns correctly, say yes! It's faster than establishing new conventions.
|
||||
|
||||
### Keep Single Changes Atomic
|
||||
|
||||
If your "single change" needs 3+ files, it might be a multi-story feature. Let the workflow guide you.
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [Quick Flow](/docs/explanation/features/quick-flow.md) - Understanding Quick Spec Flow
|
||||
- [Implement Story](/docs/how-to/workflows/implement-story.md) - After tech spec
|
||||
- [Create PRD](/docs/how-to/workflows/create-prd.md) - For larger projects needing full BMad Method
|
||||
1. **Implement Story** — Run dev-story with the DEV agent
|
||||
2. **Sprint Planning** — Optional for multi-story features
|
||||
|
||||
@@ -3,11 +3,8 @@ title: "How to Run a Brainstorming Session"
|
||||
description: How to run a brainstorming session using the BMad Method
|
||||
---
|
||||
|
||||
|
||||
Use the `brainstorm-project` workflow to explore solution approaches through parallel ideation tracks.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This
|
||||
|
||||
- Very vague or seed kernel of an idea that needs exploration
|
||||
@@ -15,14 +12,10 @@ Use the `brainstorm-project` workflow to explore solution approaches through par
|
||||
- See your idea from different angles and viewpoints
|
||||
- No idea what you want to build, but want to find some inspiration
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed
|
||||
- Analyst agent available
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -48,17 +41,15 @@ Tell the agent about your project idea, even if it's vague:
|
||||
|
||||
The workflow generates solution approaches through parallel ideation tracks:
|
||||
|
||||
- **Architecture track** - Technical approaches and patterns
|
||||
- **UX track** - User experience possibilities
|
||||
- **Integration track** - How it connects with other systems
|
||||
- **Value track** - Business value and differentiation
|
||||
- **Architecture track** — Technical approaches and patterns
|
||||
- **UX track** — User experience possibilities
|
||||
- **Integration track** — How it connects with other systems
|
||||
- **Value track** — Business value and differentiation
|
||||
|
||||
### 5. Evaluate Options
|
||||
|
||||
Review the generated options with rationale for each approach.
|
||||
|
||||
---
|
||||
|
||||
## What You Get
|
||||
|
||||
- Multiple solution approaches with trade-offs
|
||||
@@ -66,29 +57,17 @@ Review the generated options with rationale for each approach.
|
||||
- UX and integration considerations
|
||||
- Clear rationale for each direction
|
||||
|
||||
---
|
||||
## Tips
|
||||
|
||||
- **Don't worry about having a fully formed idea** — Vague is fine
|
||||
- **Let the agent guide exploration** — Follow the prompts
|
||||
- **Consider multiple tracks** — Don't settle on the first option
|
||||
- **Use outputs as input for product-brief** — Build on brainstorming results
|
||||
|
||||
## Next Steps
|
||||
|
||||
After brainstorming:
|
||||
|
||||
1. **Research** - Validate ideas with market/technical research
|
||||
2. **Product Brief** - Capture strategic vision
|
||||
3. **PRD** - Move to formal planning
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
- Don't worry about having a fully formed idea
|
||||
- Let the agent guide the exploration
|
||||
- Consider multiple tracks before deciding
|
||||
- Use outputs as input for product-brief workflow
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [Conduct Research](/docs/how-to/workflows/conduct-research.md) - Validate your ideas
|
||||
- [Create Product Brief](/docs/how-to/workflows/create-product-brief.md) - Capture strategic vision
|
||||
- [Create PRD](/docs/how-to/workflows/create-prd.md) - Move to formal planning
|
||||
1. **Research** — Validate ideas with market/technical research
|
||||
2. **Product Brief** — Capture strategic vision
|
||||
3. **PRD** — Move to formal planning
|
||||
|
||||
@@ -3,27 +3,20 @@ title: "How to Run Code Review"
|
||||
description: How to run code review for quality assurance
|
||||
---
|
||||
|
||||
|
||||
Use the `code-review` workflow to perform a thorough quality review of implemented code.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This
|
||||
|
||||
- After dev-story completes implementation
|
||||
- Before marking a story as DONE
|
||||
- Every story goes through code review - no exceptions
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
- Every story goes through code review — no exceptions
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed
|
||||
- DEV agent available
|
||||
- Story implementation complete
|
||||
- Tests written and passing
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -55,56 +48,21 @@ If issues are found:
|
||||
2. Re-run tests
|
||||
3. Run code-review again
|
||||
|
||||
---
|
||||
|
||||
## What Gets Reviewed
|
||||
|
||||
The code review checks:
|
||||
|
||||
### Code Quality
|
||||
- Clean, readable code
|
||||
- Appropriate abstractions
|
||||
- No code smells
|
||||
- Proper error handling
|
||||
|
||||
### Architecture Alignment
|
||||
- Follows ADRs and architecture decisions
|
||||
- Consistent with existing patterns
|
||||
- Proper separation of concerns
|
||||
|
||||
### Testing
|
||||
- Adequate test coverage
|
||||
- Tests are meaningful (not just for coverage)
|
||||
- Edge cases handled
|
||||
- Tests follow project patterns
|
||||
|
||||
### Security
|
||||
- No hardcoded secrets
|
||||
- Input validation
|
||||
- Authentication/authorization proper
|
||||
- No common vulnerabilities
|
||||
|
||||
### Performance
|
||||
- No obvious performance issues
|
||||
- Appropriate data structures
|
||||
- Efficient queries
|
||||
|
||||
---
|
||||
| Category | Checks |
|
||||
|----------|--------|
|
||||
| **Code Quality** | Clean code, appropriate abstractions, no code smells, proper error handling |
|
||||
| **Architecture Alignment** | Follows ADRs, consistent with patterns, proper separation of concerns |
|
||||
| **Testing** | Adequate coverage, meaningful tests, edge cases, follows project patterns |
|
||||
| **Security** | No hardcoded secrets, input validation, proper auth, no common vulnerabilities |
|
||||
| **Performance** | No obvious issues, appropriate data structures, efficient queries |
|
||||
|
||||
## Review Outcomes
|
||||
|
||||
### ✅ Approved
|
||||
**Approved** — Code meets quality standards, tests pass. Mark story as DONE in sprint-status.yaml.
|
||||
|
||||
- Code meets quality standards
|
||||
- Tests pass
|
||||
- **Action:** Mark story as DONE in sprint-status.yaml
|
||||
|
||||
### 🔧 Changes Requested
|
||||
|
||||
- Issues identified that need fixing
|
||||
- **Action:** Fix issues in dev-story, then re-run code-review
|
||||
|
||||
---
|
||||
**Changes Requested** — Issues identified that need fixing. Fix issues in dev-story, then re-run code-review.
|
||||
|
||||
## Quality Gates
|
||||
|
||||
@@ -115,27 +73,17 @@ Every story goes through code-review before being marked done. This ensures:
|
||||
- Test coverage
|
||||
- Security review
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
- Don't skip code review for "simple" changes
|
||||
- Address all findings, not just critical ones
|
||||
- Use findings as learning opportunities
|
||||
- Re-run review after fixes
|
||||
- **Don't skip for "simple" changes** — Simple changes can have subtle bugs
|
||||
- **Address all findings** — Not just critical ones
|
||||
- **Use findings as learning opportunities** — Improve over time
|
||||
- **Re-run review after fixes** — Verify issues are resolved
|
||||
|
||||
---
|
||||
## Next Steps
|
||||
|
||||
## After Code Review
|
||||
After code review:
|
||||
|
||||
1. **If approved:** Update sprint-status.yaml to mark story DONE
|
||||
2. **If changes requested:** Fix issues and re-run review
|
||||
3. **Move to next story:** Run create-story for the next item
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [Implement Story](/docs/how-to/workflows/implement-story.md) - Before code review
|
||||
- [Create Story](/docs/how-to/workflows/create-story.md) - Move to next story
|
||||
- [Run Sprint Planning](/docs/how-to/workflows/run-sprint-planning.md) - Sprint organization
|
||||
1. **If approved** — Update sprint-status.yaml to mark story DONE
|
||||
2. **If changes requested** — Fix issues and re-run review
|
||||
3. **Move to next story** — Run create-story for the next item
|
||||
|
||||
@@ -3,11 +3,8 @@ title: "How to Run Implementation Readiness"
|
||||
description: How to validate planning and solutioning before implementation
|
||||
---
|
||||
|
||||
|
||||
Use the `implementation-readiness` workflow to validate that planning and solutioning are complete and aligned before Phase 4 implementation.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This
|
||||
|
||||
- **Always** before Phase 4 for BMad Method and Enterprise projects
|
||||
@@ -15,22 +12,16 @@ Use the `implementation-readiness` workflow to validate that planning and soluti
|
||||
- Before sprint-planning workflow
|
||||
- When stakeholders request readiness check
|
||||
|
||||
---
|
||||
|
||||
## When to Skip This
|
||||
|
||||
- Quick Flow (no solutioning phase)
|
||||
- BMad Method Simple (no gate check required)
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed
|
||||
- Architect agent available
|
||||
- PRD, Architecture, and Epics completed
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -56,66 +47,42 @@ The workflow systematically checks:
|
||||
|
||||
The agent produces a gate decision with rationale.
|
||||
|
||||
---
|
||||
|
||||
## Gate Decision Outcomes
|
||||
|
||||
### ✅ PASS
|
||||
|
||||
- All critical criteria met
|
||||
- Minor gaps acceptable with documented plan
|
||||
- **Action:** Proceed to Phase 4
|
||||
|
||||
### ⚠️ CONCERNS
|
||||
|
||||
- Some criteria not met but not blockers
|
||||
- Gaps identified with clear resolution path
|
||||
- **Action:** Proceed with caution, address gaps in parallel
|
||||
|
||||
### ❌ FAIL
|
||||
|
||||
- Critical gaps or contradictions
|
||||
- Architecture missing key decisions
|
||||
- Epics conflict with PRD/architecture
|
||||
- **Action:** BLOCK Phase 4, resolve issues first
|
||||
|
||||
---
|
||||
| Decision | Meaning | Action |
|
||||
|----------|---------|--------|
|
||||
| **PASS** | All critical criteria met, minor gaps acceptable | Proceed to Phase 4 |
|
||||
| **CONCERNS** | Some criteria not met but not blockers | Proceed with caution, address gaps in parallel |
|
||||
| **FAIL** | Critical gaps or contradictions | BLOCK Phase 4, resolve issues first |
|
||||
|
||||
## What Gets Checked
|
||||
|
||||
### PRD/GDD Completeness
|
||||
**PRD/GDD Completeness:**
|
||||
- Problem statement clear and evidence-based
|
||||
- Success metrics defined
|
||||
- User personas identified
|
||||
- Functional requirements (FRs) complete
|
||||
- Non-functional requirements (NFRs) specified
|
||||
- FRs and NFRs complete
|
||||
- Risks and assumptions documented
|
||||
|
||||
### Architecture Completeness
|
||||
- System architecture defined
|
||||
- Data architecture specified
|
||||
- API architecture decided
|
||||
**Architecture Completeness:**
|
||||
- System, data, API architecture defined
|
||||
- Key ADRs documented
|
||||
- Security architecture addressed
|
||||
- FR/NFR-specific guidance provided
|
||||
- Standards and conventions defined
|
||||
|
||||
### Epic/Story Completeness
|
||||
**Epic/Story Completeness:**
|
||||
- All PRD features mapped to stories
|
||||
- Stories have acceptance criteria
|
||||
- Stories prioritized (P0/P1/P2/P3)
|
||||
- Dependencies identified
|
||||
- Story sequencing logical
|
||||
|
||||
### Alignment Checks
|
||||
**Alignment Checks:**
|
||||
- Architecture addresses all PRD FRs/NFRs
|
||||
- Epics align with architecture decisions
|
||||
- No contradictions between epics
|
||||
- NFRs have technical approach
|
||||
- Integration points clear
|
||||
|
||||
---
|
||||
|
||||
## What You Get
|
||||
|
||||
An `implementation-readiness.md` document containing:
|
||||
@@ -128,11 +95,9 @@ An `implementation-readiness.md` document containing:
|
||||
6. **Gate Decision** with rationale
|
||||
7. **Next Steps**
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
E-commerce platform → CONCERNS ⚠️
|
||||
E-commerce platform → CONCERNS
|
||||
|
||||
**Gaps identified:**
|
||||
- Missing security architecture section
|
||||
@@ -144,19 +109,17 @@ E-commerce platform → CONCERNS ⚠️
|
||||
|
||||
**Action:** Proceed with caution, address before payment epic.
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
- Run this before every Phase 4 start
|
||||
- Take FAIL decisions seriously - fix issues first
|
||||
- Use CONCERNS as a checklist for parallel work
|
||||
- Document why you proceed despite concerns
|
||||
- **Run before every Phase 4 start** — It's a valuable checkpoint
|
||||
- **Take FAIL decisions seriously** — Fix issues first
|
||||
- **Use CONCERNS as a checklist** — Track parallel work
|
||||
- **Document why you proceed despite concerns** — Transparency matters
|
||||
|
||||
---
|
||||
## Next Steps
|
||||
|
||||
## Related
|
||||
After implementation readiness:
|
||||
|
||||
- [Create Architecture](/docs/how-to/workflows/create-architecture.md) - Architecture workflow
|
||||
- [Create Epics and Stories](/docs/how-to/workflows/create-epics-and-stories.md) - Work breakdown
|
||||
- [Run Sprint Planning](/docs/how-to/workflows/run-sprint-planning.md) - Start implementation
|
||||
1. **If PASS** — Run sprint-planning to start Phase 4
|
||||
2. **If CONCERNS** — Proceed with documented gaps to address
|
||||
3. **If FAIL** — Return to relevant workflow to fix issues
|
||||
|
||||
@@ -3,27 +3,20 @@ title: "How to Run Sprint Planning"
|
||||
description: How to initialize sprint tracking for implementation
|
||||
---
|
||||
|
||||
|
||||
Use the `sprint-planning` workflow to initialize the sprint tracking file and organize work for implementation.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This
|
||||
|
||||
- Once at the start of Phase 4 (Implementation)
|
||||
- After implementation-readiness gate passes
|
||||
- When starting a new sprint cycle
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed
|
||||
- SM (Scrum Master) agent available
|
||||
- Epic files created from `create-epics-and-stories`
|
||||
- Implementation-readiness passed (for BMad Method/Enterprise)
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -45,8 +38,6 @@ Point the agent to your epic files created during Phase 3.
|
||||
|
||||
The agent organizes stories into the sprint tracking file.
|
||||
|
||||
---
|
||||
|
||||
## What You Get
|
||||
|
||||
A `sprint-status.yaml` file containing:
|
||||
@@ -56,12 +47,8 @@ A `sprint-status.yaml` file containing:
|
||||
- Dependencies between stories
|
||||
- Priority ordering
|
||||
|
||||
---
|
||||
|
||||
## Story Lifecycle States
|
||||
|
||||
Stories move through these states in the sprint status file:
|
||||
|
||||
| State | Description |
|
||||
|-------|-------------|
|
||||
| **TODO** | Story identified but not started |
|
||||
@@ -69,43 +56,39 @@ Stories move through these states in the sprint status file:
|
||||
| **READY FOR REVIEW** | Implementation complete, awaiting code review |
|
||||
| **DONE** | Accepted and complete |
|
||||
|
||||
---
|
||||
|
||||
## Typical Sprint Flow
|
||||
|
||||
### Sprint 0 (Planning Phase)
|
||||
**Sprint 0 (Planning Phase):**
|
||||
- Complete Phases 1-3
|
||||
- PRD/GDD + Architecture complete
|
||||
- Epics+Stories created via create-epics-and-stories
|
||||
|
||||
### Sprint 1+ (Implementation Phase)
|
||||
**Sprint 1+ (Implementation Phase):**
|
||||
|
||||
**Start of Phase 4:**
|
||||
Start of Phase 4:
|
||||
1. SM runs `sprint-planning` (once)
|
||||
|
||||
**Per Story (repeat until epic complete):**
|
||||
Per Story (repeat until epic complete):
|
||||
1. SM runs `create-story`
|
||||
2. DEV runs `dev-story`
|
||||
3. DEV runs `code-review`
|
||||
4. Update sprint-status.yaml
|
||||
|
||||
**After Epic Complete:**
|
||||
After Epic Complete:
|
||||
- SM runs `retrospective`
|
||||
- Move to next epic
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
- Run sprint-planning only once at Phase 4 start
|
||||
- Use `sprint-status` during Phase 4 to check current state
|
||||
- Keep the sprint-status.yaml file as single source of truth
|
||||
- Update story status after each stage
|
||||
- **Run sprint-planning only once** — At Phase 4 start
|
||||
- **Use sprint-status during Phase 4** — Check current state anytime
|
||||
- **Keep sprint-status.yaml as single source of truth** — All status updates go here
|
||||
- **Update story status after each stage** — Keep it current
|
||||
|
||||
---
|
||||
## Next Steps
|
||||
|
||||
## Related
|
||||
After sprint planning:
|
||||
|
||||
- [Create Story](/docs/how-to/workflows/create-story.md) - Prepare stories for implementation
|
||||
- [Implement Story](/docs/how-to/workflows/implement-story.md) - Dev workflow
|
||||
- [Run Code Review](/docs/how-to/workflows/run-code-review.md) - Quality assurance
|
||||
1. **Create Story** — Prepare the first story for implementation
|
||||
2. **Implement Story** — Run dev-story with the DEV agent
|
||||
3. **Code Review** — Quality assurance after implementation
|
||||
|
||||
@@ -3,11 +3,8 @@ title: "How to Run Test Design"
|
||||
description: How to create comprehensive test plans using TEA's test-design workflow
|
||||
---
|
||||
|
||||
|
||||
Use TEA's `*test-design` workflow to create comprehensive test plans with risk assessment and coverage strategies.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This
|
||||
|
||||
**System-level (Phase 3):**
|
||||
@@ -20,16 +17,12 @@ Use TEA's `*test-design` workflow to create comprehensive test plans with risk a
|
||||
- Before implementing stories in the epic
|
||||
- To identify epic-specific testing needs
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed
|
||||
- TEA agent available
|
||||
- For system-level: Architecture document complete
|
||||
- For epic-level: Epic defined with stories
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -47,8 +40,8 @@ Start a fresh chat and load the TEA (Test Architect) agent.
|
||||
|
||||
TEA will ask if you want:
|
||||
|
||||
- **System-level** - For architecture testability review (Phase 3)
|
||||
- **Epic-level** - For epic-specific test planning (Phase 4)
|
||||
- **System-level** — For architecture testability review (Phase 3)
|
||||
- **Epic-level** — For epic-specific test planning (Phase 4)
|
||||
|
||||
### 4. Provide Context
|
||||
|
||||
@@ -64,20 +57,16 @@ For epic-level:
|
||||
|
||||
TEA generates a comprehensive test design document.
|
||||
|
||||
---
|
||||
|
||||
## What You Get
|
||||
|
||||
### System-Level Output (`test-design-system.md`)
|
||||
|
||||
**System-Level Output (`test-design-system.md`):**
|
||||
- Testability review of architecture
|
||||
- ADR → test mapping
|
||||
- Architecturally Significant Requirements (ASRs)
|
||||
- Environment needs
|
||||
- Test infrastructure recommendations
|
||||
|
||||
### Epic-Level Output (`test-design-epic-N.md`)
|
||||
|
||||
**Epic-Level Output (`test-design-epic-N.md`):**
|
||||
- Risk assessment for the epic
|
||||
- Test priorities
|
||||
- Coverage plan
|
||||
@@ -85,44 +74,25 @@ TEA generates a comprehensive test design document.
|
||||
- Integration risks
|
||||
- Mitigation strategies
|
||||
|
||||
---
|
||||
|
||||
## Test Design for Different Tracks
|
||||
|
||||
### Greenfield - BMad Method
|
||||
|
||||
| Stage | Test Design Focus |
|
||||
|-------|-------------------|
|
||||
| Phase 3 | System-level testability review |
|
||||
| Phase 4 | Per-epic risk assessment and test plan |
|
||||
|
||||
### Brownfield - BMad Method/Enterprise
|
||||
|
||||
| Stage | Test Design Focus |
|
||||
|-------|-------------------|
|
||||
| Phase 3 | System-level + existing test baseline |
|
||||
| Phase 4 | Regression hotspots, integration risks |
|
||||
|
||||
### Enterprise
|
||||
|
||||
| Stage | Test Design Focus |
|
||||
|-------|-------------------|
|
||||
| Phase 3 | Compliance-aware testability |
|
||||
| Phase 4 | Security/performance/compliance focus |
|
||||
|
||||
---
|
||||
| Track | Phase 3 Focus | Phase 4 Focus |
|
||||
|-------|---------------|---------------|
|
||||
| **Greenfield** | System-level testability review | Per-epic risk assessment and test plan |
|
||||
| **Brownfield** | System-level + existing test baseline | Regression hotspots, integration risks |
|
||||
| **Enterprise** | Compliance-aware testability | Security/performance/compliance focus |
|
||||
|
||||
## Tips
|
||||
|
||||
- Run system-level test-design right after architecture
|
||||
- Run epic-level test-design at the start of each epic
|
||||
- Update test design if ADRs change
|
||||
- Use the output to guide `*atdd` and `*automate` workflows
|
||||
- **Run system-level right after architecture** — Early testability review
|
||||
- **Run epic-level at the start of each epic** — Targeted test planning
|
||||
- **Update if ADRs change** — Keep test design aligned
|
||||
- **Use output to guide other workflows** — Feeds into `*atdd` and `*automate`
|
||||
|
||||
---
|
||||
## Next Steps
|
||||
|
||||
## Related
|
||||
After test design:
|
||||
|
||||
- [TEA Overview](/docs/explanation/features/tea-overview.md) - Understanding the Test Architect
|
||||
- [Setup Test Framework](/docs/how-to/workflows/setup-test-framework.md) - Setting up testing infrastructure
|
||||
- [Create Architecture](/docs/how-to/workflows/create-architecture.md) - Architecture workflow
|
||||
1. **Setup Test Framework** — If not already configured
|
||||
2. **Implementation Readiness** — System-level feeds into gate check
|
||||
3. **Story Implementation** — Epic-level guides testing during dev
|
||||
|
||||
@@ -3,11 +3,8 @@ title: "How to Set Up Party Mode"
|
||||
description: How to set up and use Party Mode for multi-agent collaboration
|
||||
---
|
||||
|
||||
|
||||
Use Party Mode to orchestrate dynamic multi-agent conversations with your entire BMad team.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This
|
||||
|
||||
- Exploring complex topics that benefit from diverse expert perspectives
|
||||
@@ -15,14 +12,10 @@ Use Party Mode to orchestrate dynamic multi-agent conversations with your entire
|
||||
- Getting comprehensive views across multiple domains
|
||||
- Strategic decisions with trade-offs
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed with multiple agents
|
||||
- Any agent loaded that supports party mode
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -62,56 +55,36 @@ The facilitator will:
|
||||
|
||||
Type "exit" or "done" to conclude the session. Participating agents will say personalized farewells.
|
||||
|
||||
---
|
||||
|
||||
## What Happens
|
||||
|
||||
1. **Agent Roster** - Party Mode loads your complete agent roster
|
||||
2. **Introduction** - Available team members are introduced
|
||||
3. **Topic Analysis** - The facilitator analyzes your topic
|
||||
4. **Agent Selection** - 2-3 most relevant agents are selected
|
||||
5. **Discussion** - Agents respond, reference each other, engage in cross-talk
|
||||
6. **Exit** - Session concludes with farewells
|
||||
|
||||
---
|
||||
1. **Agent Roster** — Party Mode loads your complete agent roster
|
||||
2. **Introduction** — Available team members are introduced
|
||||
3. **Topic Analysis** — The facilitator analyzes your topic
|
||||
4. **Agent Selection** — 2-3 most relevant agents are selected
|
||||
5. **Discussion** — Agents respond, reference each other, engage in cross-talk
|
||||
6. **Exit** — Session concludes with farewells
|
||||
|
||||
## Example Party Compositions
|
||||
|
||||
### Product Strategy
|
||||
- PM + Innovation Strategist (CIS) + Analyst
|
||||
|
||||
### Technical Design
|
||||
- Architect + Creative Problem Solver (CIS) + Game Architect
|
||||
|
||||
### User Experience
|
||||
- UX Designer + Design Thinking Coach (CIS) + Storyteller (CIS)
|
||||
|
||||
### Quality Assessment
|
||||
- TEA + DEV + Architect
|
||||
|
||||
---
|
||||
| Topic | Typical Agents |
|
||||
|-------|---------------|
|
||||
| **Product Strategy** | PM + Innovation Strategist (CIS) + Analyst |
|
||||
| **Technical Design** | Architect + Creative Problem Solver (CIS) + Game Architect |
|
||||
| **User Experience** | UX Designer + Design Thinking Coach (CIS) + Storyteller (CIS) |
|
||||
| **Quality Assessment** | TEA + DEV + Architect |
|
||||
|
||||
## Key Features
|
||||
|
||||
- **Intelligent agent selection** - Selects based on expertise needed
|
||||
- **Authentic personalities** - Each agent maintains their unique voice
|
||||
- **Natural cross-talk** - Agents reference and build on each other
|
||||
- **Optional TTS** - Voice configurations for each agent
|
||||
- **Graceful exit** - Personalized farewells
|
||||
|
||||
---
|
||||
- **Intelligent agent selection** — Selects based on expertise needed
|
||||
- **Authentic personalities** — Each agent maintains their unique voice
|
||||
- **Natural cross-talk** — Agents reference and build on each other
|
||||
- **Optional TTS** — Voice configurations for each agent
|
||||
- **Graceful exit** — Personalized farewells
|
||||
|
||||
## Tips
|
||||
|
||||
- Be specific about your topic for better agent selection
|
||||
- Let the conversation flow naturally
|
||||
- Ask follow-up questions to go deeper
|
||||
- Take notes on key insights
|
||||
- Use for strategic decisions, not routine tasks
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [Party Mode](/docs/explanation/features/party-mode.md) - Understanding Party Mode
|
||||
- [Agent Roles](/docs/explanation/core-concepts/agent-roles.md) - Available agents
|
||||
- **Be specific about your topic** — Better agent selection
|
||||
- **Let the conversation flow** — Don't over-direct
|
||||
- **Ask follow-up questions** — Go deeper on interesting points
|
||||
- **Take notes on key insights** — Capture valuable perspectives
|
||||
- **Use for strategic decisions** — Not routine tasks
|
||||
|
||||
@@ -3,11 +3,8 @@ title: "How to Set Up a Test Framework"
|
||||
description: How to set up a production-ready test framework using TEA
|
||||
---
|
||||
|
||||
|
||||
Use TEA's `*framework` workflow to scaffold a production-ready test framework for your project.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This
|
||||
|
||||
- No existing test framework in your project
|
||||
@@ -15,15 +12,11 @@ Use TEA's `*framework` workflow to scaffold a production-ready test framework fo
|
||||
- Starting a new project that needs testing infrastructure
|
||||
- Phase 3 (Solutioning) after architecture is complete
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::note[Prerequisites]
|
||||
- BMad Method installed
|
||||
- Architecture completed (or at least tech stack decided)
|
||||
- TEA agent available
|
||||
|
||||
---
|
||||
:::
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -50,13 +43,11 @@ TEA will ask about:
|
||||
|
||||
TEA generates:
|
||||
|
||||
- **Test scaffold** - Directory structure and config files
|
||||
- **Sample specs** - Example tests following best practices
|
||||
- **`.env.example`** - Environment variable template
|
||||
- **`.nvmrc`** - Node version specification
|
||||
- **README updates** - Testing documentation
|
||||
|
||||
---
|
||||
- **Test scaffold** — Directory structure and config files
|
||||
- **Sample specs** — Example tests following best practices
|
||||
- **`.env.example`** — Environment variable template
|
||||
- **`.nvmrc`** — Node version specification
|
||||
- **README updates** — Testing documentation
|
||||
|
||||
## What You Get
|
||||
|
||||
@@ -71,8 +62,6 @@ tests/
|
||||
└── README.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Optional: Playwright Utils Integration
|
||||
|
||||
TEA can integrate with `@seontechnologies/playwright-utils` for advanced fixtures:
|
||||
@@ -85,29 +74,25 @@ Enable during BMad installation or set `tea_use_playwright_utils: true` in confi
|
||||
|
||||
**Utilities available:** api-request, network-recorder, auth-session, intercept-network-call, recurse, log, file-utils, burn-in, network-error-monitor
|
||||
|
||||
---
|
||||
|
||||
## Optional: MCP Enhancements
|
||||
|
||||
TEA can use Playwright MCP servers for enhanced capabilities:
|
||||
|
||||
- `playwright` - Browser automation
|
||||
- `playwright-test` - Test runner with failure analysis
|
||||
- `playwright` — Browser automation
|
||||
- `playwright-test` — Test runner with failure analysis
|
||||
|
||||
Configure in your IDE's MCP settings.
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
- Run `*framework` only once per repository
|
||||
- Run after architecture is complete so framework aligns with tech stack
|
||||
- Follow up with `*ci` to set up CI/CD pipeline
|
||||
- **Run only once per repository** — Framework setup is a one-time operation
|
||||
- **Run after architecture is complete** — Framework aligns with tech stack
|
||||
- **Follow up with CI setup** — Run `*ci` to configure CI/CD pipeline
|
||||
|
||||
---
|
||||
## Next Steps
|
||||
|
||||
## Related
|
||||
After test framework setup:
|
||||
|
||||
- [TEA Overview](/docs/explanation/features/tea-overview.md) - Understanding the Test Architect
|
||||
- [Run Test Design](/docs/how-to/workflows/run-test-design.md) - Creating test plans
|
||||
- [Create Architecture](/docs/how-to/workflows/create-architecture.md) - Architecture workflow
|
||||
1. **Test Design** — Create test plans for system or epics
|
||||
2. **CI Configuration** — Set up automated test runs
|
||||
3. **Story Implementation** — Tests are ready for development
|
||||
|
||||
Reference in New Issue
Block a user