ros/BMAD-METHOD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

massive update and guidance.

Browse Source
This commit is contained in:
Brian Madison
2025-04-16 22:13:31 -05:00
parent cb602a3fe5
commit 64f9a9c3f8
12 changed files with 329 additions and 61 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
README.md
View File

@@ -6,15 +6,15 @@ Join in on the [Community Discussion Forum](https://github.com/bmadcode/BMAD-MET
Also check out [Part 1 on the BMad Code YouTube channel](https://youtu.be/JbhiLUY_V2U) - feel free to comment, like, and subscribe also for future videos and updates.
**Super Quick TLDR:** These are [the prompts](./ai-pm/prompts/) you have been searching for!
**Bonus** - check the [Gemini Gems Demo Prompts](./ai-pm/prompts/Gemini%20Gems%20Agile%20Masters.md) for a set of Google Gemini Gems to use with this workflow! Optional and a totally different fun experience. These are still a WIP and I am working on improving them, and welcome feedback - but so far I find them fun to use and very promising!
Note: Depending on which tool you use - the [[prompts folder]](./ai-pm/prompts/) should be set to be ignored my your LLM codebase indexing (ie with cursor add them to .cursorindexingignore - cline and roo may differ).
## Overview
The BMad Method is a (not so) revolutionary approach to software development that leverages AI-driven processes to accelerate and enhance the entire product development lifecycle. This template provides a structured framework that guides you through generating all necessary artifacts to build a complete application with AI assistance.
The BMad Method is a (not so) revolutionary approach to software development that leverages AI-driven processes to accelerate and enhance the entire product development lifecycle from ideation and market fit, through agentic code implementation.
The method is meant to be tool agnostic including a workflow built into the role-prompts. It is a somewhat manual workflow that can be used in multiple ways.
It can easily be adapted to specifics of any agentic coding toolset, ide and platform.
## What is the BMad Method?
@@ -47,8 +47,8 @@ The BMad Method follows a structured workflow:
## Prompt Sequence
The `ai-pm/prompts` folder contains carefully crafted prompts for each phase of development.
This is for the most broadly ambitious project MVP - see the simplified prompts
The `prompts` folder contains carefully crafted prompts for each phase of development.
This is for the most broadly ambitious project MVP
1. **Research Assistant: Analysis** (`0-research-assistant.md`): Optional deep research on your product concept
2. **Business Analyst: Project Brief** (`1-business-analyst.md`): Define your product idea and MVP scope
@@ -57,9 +57,7 @@ This is for the most broadly ambitious project MVP - see the simplified prompts
5. **Architecture Deep Research: PRD Updates** (`4-Arch-Deep.md`): Optional deep research step for Up tp date best practice and rules generation
6. **Architect: Arch Doc** (`5-Arch.md`): Create a detailed architectural blueprint
7. **Technical Product Owner: Epic Story List** (`6-PO.md`): Break down requirements into implementable stories
8. **Technical Scrum Master: Agent Story Files** (`7-SM.md`): Transform stories into Dev Agent ready super detailed stories
There is a OPTIONAL final prompt (`8-SM-IDE.md`) - use this in your IDE with the selected agent to split up item 7 into the individual files for the ToDo folder (assuming you did not modify prompt 7 to generate the files individually within the IDE or external tool.)
8. **Technical Scrum Master: Agent Story Files** (`7-SM.md`): Transform stories into Dev Agent ready super detailed stories (it is not recommended to generate all stories with this up front - instead favor using the /role-prompts/dev.md agent with builtin workflow to craft story 1 by 1 as needed to implement.)
## Key Benefits
@@ -69,27 +67,32 @@ There is a OPTIONAL final prompt (`8-SM-IDE.md`) - use this in your IDE with the
- **Reduced Technical Debt**: Ensure architectural consistency from the start
- **Simplified Collaboration**: Clear artifacts for all stakeholders, Human and AI
## Quick How To
## How To
Recommend checking out this video series starting with [Part 1 on the BMad Code YouTube channel](https://youtu.be/JbhiLUY_V2U) and also checking the [Discussion Forum](https://github.com/bmadcode/BMAD-METHOD/discussions) in the coming days where BMad and the community hopefully will share and collaborate and give further tweaks tips and tricks!
But the **Quick and Dirt**y is:
1. Clone this project
2. Start with the first prompt in `ai-pm/prompts/0-research-assistant.md` (or skip to 1 if research isn't needed)
2. Start with the first prompt in `prompts/0-research-assistant.md` (or skip to 1 if research isn't needed) to do market research with an LLM's deep research capabilities
3. Follow each prompt in sequence, providing output from previous steps as context to the new prompt when indicated in the current prompt
4. Once all stories are drafted by the final prompts of the SM, move generated stories through the Kanban folders as they are implemented - meaning drag the first story to InProgress, start a Agent chat and direct it to that story. Optionally, use the sample workflow (coming soon) to automate (I prefer the manual nature of dragging each item).
5. Track progress until all stories are in the `3-Done` folder
4. One the PO generates the final story list, paste it back into the PRD.
5. Generate each detailed user story and implement it 1 by 1. The stories serve as the memory system and history of incremental agile development.
6. Track progress until all stories are completed to realize the MVP.
My recommendation is to take advantage of Google Gemini or ChatGPT apps, it is very economical and better in some regards.
My recommendation is to take advantage of Google Gemini or ChatGPT web apps for generation of deep research brain storming, PRD, and deep research for the architecture if needed. Beyond that, its easy enough to take the pieces of artifacts needed to put the markdown into the project ai folder, and then use prompts from within the IDE to generate the file architecture, story list updates to the PRD from the PO, and eventual story generation.
For example with Gemini its easy to group and also create google docs from the canvas feature. I like their web interface. And it gives access to its amazing Deep Research platform, expanded NotebookLM capabilities etc.. But you can also use OpenAI, Claude, Grok or do it all also within the IDE.
## Modifications
If you have a subscription to one of those or even free tier access to the best models like Gemini 2.5 or OpenAIs deep research web ui - might as well take advantage of it - it can save you lots of LLM credits, and produce IMO better results for the artifacts.
This is just an idea of what works for me to increamentally build up complex applications from idea to inception. But I use variants of this to work in existing code bases, where I will lay out a PRD with task lists and use the architecture document to put in place guardrails and further details the LLM needs to understand if it is not already in place.
Similar idea if you use the optional UX prompt, take advantage of free tier V0 or similar products to past in the produce prompt to quick start complex UI's.
The sharing of all these prompts are just suggestions - I HIGHLY recommend you use these ideas to tweak and refine what works for you! Experiment with different models, and over time they will improve.
Either way, ensure you are adding all of the artifacts to the ai-pm folder (or another folder of your choice) for your new project.
For small projects, just a PRD and the story files can be more than sufficient. And for more ambitious or unknowns, use the brainstorming step and deep research to help you out.
Valid produce artifacts for the application such as source trees, rules, architecture documentation can provide value beyond the initial implementation of the task at hand can can live with the project, usually moved into the docs folder, and also rules can be added to CONTRIBUTING.md. By putting rules in this file, it can be used by humans and ai tools.
For example in cursor, with a good contributing file, you can have an always rule to always reference the contributing.md file for its core rule set. And then if you use Cline or CoPilot, you can do similar with their rule systems or agent custom instructions.
## Future Enhancements

42
ai-pm/prompts/6-PO.md
View File

@@ -1,42 +0,0 @@
# Prompt 6: Product Owner Epic Stories List
persona: Expert Agile Product Owner specializing in decomposing complex requirements into logically sequenced Epics and User Stories based on value and technical/UI/setup dependencies.
model: Gemini 2.5 Pro (or similar advanced LLM)
mode: Standard Reasoning / Thinking Mode
**Find and fill in all Bracket Pairs before submitting!**
## Prompt Follows:
You are an Expert Agile Product Owner. Your task is to create a logically ordered backlog of Epics and User Stories for the MVP, based on the provided Product Requirements Document (PRD) and Architecture Document.
### Context: PRD
<Paste the complete Product Requirements Document (PRD) here, including UI/UX specifications, and the architecture documents>
### Context: Architecture Document
<Paste the complete Architecture Document here>
### Instructions:
1. **Analyze:** Carefully review the provided PRD and Architecture Document. Pay close attention to features, requirements, UI/UX flows, technical specifications, and any specified manual setup steps or dependencies mentioned in the Architecture Document.
2. **Create Epics:** Group related features or requirements from the PRD into logical Epics. Aim for roughly 3-6 User Stories per Epic. For each Epic, clearly state its primary goal.
3. **Decompose into User Stories:** Break down each Epic into small, valuable User Stories. Use the standard "As a `<type of user>`, I want `<some goal>` so that `<some reason>`" format where appropriate. Ensure stories align with the INVEST principles (Independent, Negotiable, Valuable, Estimable, Small, Testable), keeping in mind that foundational/setup stories might have slightly different characteristics but must still be clearly defined.
4. **Sequence Logically:** This is critical. Arrange the Epics and the User Stories within them in the **exact logical order required for execution**. You MUST consider:
- **Technical Dependencies:** Features that rely on other backend or foundational components must come later.
- **UI/UX Dependencies:** User flows often dictate the order in which UI elements need to be built.
- **Manual Setup Dependencies:** Any stories related to manual setup steps identified in the Architecture Document (e.g., project initialization via CLI) MUST be placed first in the sequence.
- There are manual tasks that might be called out in the architecture (such as set up remote account, configure api keys, etc...) - These need to also be called out as a user story and sequenced properly (Usually called Story 0 - but they can also be part of a story at the time they are needed as a subtask (just make sure its noted for the scrum master who will build the full stories with details later)).
5. **Output Format:** Present the output as a clearly structured list, first listing the Epics in sequence, and then listing the User Stories under each Epic, also in their required sequence.
Example Structure:
Epic 1: <Epic Goal>
_ Story 1.1: <User Story Title>
_ Story 1.2: <User Story Title>
_ ...
Epic 2: <Epic Goal>
_ Story 2.1: <User Story Title> \* ...
If any information regarding dependencies or feature breakdown seems unclear from the provided documents, please ask clarifying questions before generating the full list.

0
ai/stories/readme.md Normal file
View File

76
ai/templates/architecture-template.md Normal file
View File

@@ -0,0 +1,76 @@
# Architecture for {PRD Title}
Status: { Draft | Approved }
## Technical Summary
{ Short 1-2 paragraph }
## Technology Table
Table listing choices for languages, libraries, infra, etc...
<example>
| Technology | Description |
| ------------ | ------------------------------------------------------------- |
| Kubernetes | Container orchestration platform for microservices deployment |
| Apache Kafka | Event streaming platform for real-time data ingestion |
| TimescaleDB | Time-series database for sensor data storage |
| Go | Primary language for data processing services |
| GoRilla Mux | REST API Framework |
| Python | Used for data analysis and ML services |
</example>
## Architectural Diagrams
{ Mermaid Diagrams to describe key flows interactions or architecture to be followed during implementation, infra provisioning, and deployments }
## Data Models, API Specs, Schemas, etc...
{ As needed - may not be exhaustive - but key ideas that need to be retained and followed into the stories }
<example>
### Sensor Reading Schema
```json
{
"sensor_id": "string",
"timestamp": "datetime",
"readings": {
"temperature": "float",
"pressure": "float",
"humidity": "float"
},
"metadata": {
"location": "string",
"calibration_date": "datetime"
}
}
```
</example>
## Project Structure
{ Diagram the folder and file organization structure along with descriptions }
```
├ /src
├── /services
│ ├── /gateway # Sensor data ingestion
│ ├── /processor # Data processing and validation
│ ├── /analytics # Data analysis and ML
│ └── /notifier # Alert and notification system
├── /deploy
│ ├── /kubernetes # K8s manifests
│ └── /terraform # Infrastructure as Code
└── /docs
├── /api # API documentation
└── /schemas # Data schemas
```
## Infrastructure
## Deployment Plan
## Change Log

135
ai/templates/prd-template.md Normal file
View File

@@ -0,0 +1,135 @@
# 1. Title: {PRD for {project}}
## Status: { Draft | Approved }
## Intro
{ Short 1-2 paragraph describing the what and why of what the prd will achieve}
## Goals
{
- Clear project objectives
- Measurable outcomes
- Success criteria
- Key performance indicators (KPIs)
}
## Features and Requirements
- Functional requirements
- Non-functional requirements
- User experience requirements
- Integration requirements
- Compliance requirements
## Epic List
### Epic-1: Current PRD Epic (for example backend epic)
### Epic-2: Second Current PRD Epic (for example front end epic)
### Epic-N: Future Epic Enhancements (Beyond Scope of current PRD)
## Epic 1: Story List
<example>
- Story 1: Project and NestJS Configuration
Status: {''|'InProgress'|'Complete'}
Requirements:
- Install NestJS CLI Globally
- Create a new NestJS project with the nestJS cli generator
- Test Start App Boilerplate Functionality
- Init Git Repo and commit initial project set up
- Story 2: News Retrieval API Route
Status: {''|'InProgress'|'Complete'}
Requirements:
- Create API Route that returns a list of News and comments from the news source foo
- Route post body specifies the number of posts, articles, and comments to return
- Create a command in package.json that I can use to call the API Route (route configured in env.local)
</example>
## Technology Stack
{ Table listing choices for languages, libraries, infra, etc...}
<example>
| Technology | Version | Description |
| ---------- | ------- | ----------- |
| Kubernetes | x.y.z | Container orchestration platform for microservices deployment |
| Apache Kafka | x.y.z | Event streaming platform for real-time data ingestion |
| TimescaleDB | x.y.z | Time-series database for sensor data storage |
| Go | x.y.z | Primary language for data processing services |
| GoRilla Mux | x.y.z | REST API Framework |
| Python | x.y.z | Used for data analysis and ML services |
</example>
## Reference
{ Mermaid Diagrams for models tables, visual aids as needed, citations and external urls }
## Data Models, API Specs, Schemas, etc...
{ As needed - may not be exhaustive - but key ideas that need to be retained and followed into the architecture and stories }
<example>
### Sensor Reading Schema
```json
{
"sensor_id": "string",
"timestamp": "datetime",
"readings": {
"temperature": "float",
"pressure": "float",
"humidity": "float"
},
"metadata": {
"location": "string",
"calibration_date": "datetime"
}
}
```
</example>
## Project Structure
{ Diagram the folder and file organization structure along with descriptions }
<example>
````
// Start of Selection
```text
src/
├── services/
│ ├── gateway/ # Sensor data ingestion
│ ├── processor/ # Data processing and validation
│ ├── analytics/ # Data analysis and ML
│ └── notifier/ # Alert and notification system
├── deploy/
│ ├── kubernetes/ # K8s manifests
│ └── terraform/ # Infrastructure as Code
└── docs/
├── api/ # API documentation
└── schemas/ # Data schemas
````
</example>
## Change Log
{ Markdown table of key changes after document is no longer in draft and is updated, table includes the change title, the story id that the change happened during, and a description if the title is not clear enough }
<example>
| Change | Story ID | Description |
| -------------------- | -------- | ------------------------------------------------------------- |
| Initial draft | N/A | Initial draft prd |
| Add ML Pipeline | story-4 | Integration of machine learning prediction service story |
| Kafka Upgrade | story-6 | Upgraded from Kafka 2.0 to Kafka 3.0 for improved performance |
</example>

53
ai/templates/story-template.md Normal file
View File

@@ -0,0 +1,53 @@
# Story {N}: {Title}
## Story
**As a** {role}\
**I want** {action}\
**so that** {benefit}.
## Status
Draft OR In-Progress OR Complete
## Context
{A paragraph explaining the background, current state, and why this story is needed. Include any relevant technical context or business drivers.}
## Estimation
Story Points: {Story Points (1 SP=1 day of Human Development, or 10 minutes of AI development)}
## Acceptance Criteria
1. - [ ] {First criterion - ordered by logical progression}
2. - [ ] {Second criterion}
3. - [ ] {Third criterion}
{Use - [x] for completed items}
## Subtasks
1. - [ ] {Major Task Group 1}
1. - [ ] {Subtask}
2. - [ ] {Subtask}
3. - [ ] {Subtask}
2. - [ ] {Major Task Group 2}
1. - [ ] {Subtask}
2. - [ ] {Subtask}
3. - [ ] {Subtask}
{Use - [x] for completed items, - [-] for skipped/cancelled items}
## Testing Requirements:\*\*
- Reiterate the required code coverage percentage (e.g., >= 85%).
## Story Wrap Up (To be filled in AFTER agent execution):\*\*
- **Agent Model Used:** `<Agent Model Name/Version>`
- **Agent Credit or Cost:** `<Cost/Credits Consumed>`
- **Date/Time Completed:** `<Timestamp>`
- **Commit Hash:** `<Git Commit Hash of resulting code>`
- **Change Log**
- change X
- change Y
...

0
google-gems-prompts/architect.md → role-prompts/architect.md
View File

0
google-gems-prompts/ba.md → role-prompts/ba.md
View File

43
role-prompts/dev.md Normal file
View File

@@ -0,0 +1,43 @@
# Agile Workflow and core memory procedure RULES that MUST be followed EXACTLY!
## Core Initial Instructions Upon Startup:
When coming online, you will first check if a .ai/\*.story.md file exists with the highest sequence number and review the story so you know the current phase of the project.
If there is no story when you come online that is not in draft or in progress status, ask if the user wants to to draft the next sequence user story from the PRD if they did not instruct you to do so.
The user should indicate what story to work on next, and if the story file does not exist, create the draft for it using the information from the `ai/prd.md` and `ai/architecture.md` files. Always use the `ai/templates/template-story.md` file as a template for the story. The story will be named <story>-<n>.story.md added to `the ai/stories` folder
- Example: `ai/stories/story-1.story.md`, `ai/stories/story-2.story.md`
<critical>
You will ALWAYS wait for the user to mark the story status as approved before doing ANY work to implement the story.
</critical>
You will run tests and ensure tests pass before going to the next subtask within a story.
You will update the story file as subtasks are completed.
<critical>
Once all subtasks are complete, inform the user that the story is ready for their review and approval. You will not proceed further at this point.
</critical>
## During Development
Once a story has been marked as In Progress, and you are told to proceed with development:
- Update story files as subtasks are completed.
- If you are unsure of the next step, ask the user for clarification, and then update the story as needed to maintain a very clear memory of decisions.
- Reference the `ai/architecture.md` if the story is inefficient or needs additional technical documentation so you are in sync with the Architects plans.
- When prompted by the user with command `update story`, update the current story to:
- Reflect the current state.
- Clarify next steps.
- Ensure the chat log in the story is up to date with any chat thread interactions
- Continue to verify the story is correct and the next steps are clear.
- Remember that a story is not complete if you have not also run ALL stories and verified all stories pass.
- Do not tell the user the story is complete, or mark the story as complete unless you have run ALL the tests.
## YOU DO NOT NEED TO ASK to:
- Run unit Tests during the development process until they pass.
- Update the story AC and tasks as they are completed.\

0
google-gems-prompts/pm.md → role-prompts/pm.md
View File

0
google-gems-prompts/po.md → role-prompts/po.md
View File

0
google-gems-prompts/ux.md → role-prompts/ux.md
View File