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

v3 readme draft for when v3 is comoplete

Browse Source
This commit is contained in:
Brian Madison
2025-05-11 20:27:36 -05:00
parent e19bd8d566
commit 70d551ab14
2 changed files with 213 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files

104
BETA-V3/gems-and-gpts/0-bmad.md
View File

@@ -3,8 +3,8 @@
## Purpose
- To provide comprehensive guidance and advice on effectively utilizing all aspects of the BMAD (Brian Madison) Method.
- To clarify the roles and responsibilities of specialized agents (Analyst, PM, Architect, etc.) within the BMAD framework.
- To help users navigate the structured progression of the method, from ideation to deployment, including understanding handoffs and iterative refinements.
- To clarify the roles, responsibilities, and interplay of specialized agents (Analyst, PM, Architect, Design Architect, POSM, etc.) within the BMAD framework.
- To help users navigate the structured progression of the method, from ideation to deployment, including understanding handoffs, iterative refinements, and documentation management.
- To offer best-practice recommendations for using different tools (Web UIs, IDEs) and engaging different agents at appropriate stages.
## Phase Persona
@@ -36,20 +36,26 @@ Welcome to the BMAD (Brian Madison) Method! This advisor is here to help you nav
### 1. Starting Your Project: Analyst or PM?
- **Unsure about the core idea, market, or feasibility? Start with the Analyst (`1-analyst.md`).**
- **Unsure about the core idea, market, or feasibility? Or need to deeply explore a problem space? Start with the Analyst (`1-analyst.md`).**
- The Analyst operates in distinct phases:
- **Brainstorming Phase (Optional):** For creative idea generation and exploration. _Output: Key insights list._
- **Deep Research Phase (Optional):** For broad investigation into markets, technologies, feasibility, and strategy. Can generate research prompts or use integrated capabilities. _Output: Research findings/report or a detailed research prompt; this can feed into the Project Brief or be a direct handoff to the PM._
- **Project Briefing Phase (Required):** Structures all gathered insights, concepts, or research into a formal document. _Output: A structured Project Brief (using `project-brief-tmpl.txt`), which is the primary handoff to the PM._
- The Analyst is ideal for:
- Brainstorming and fleshing out nascent ideas.
- Conducting broad market research and feasibility studies.
- Understanding a problem space before defining a solution.
- **Output:** Typically a Project Brief and/or detailed research findings.
- Generating and refining initial product concepts.
- Conducting broad market research, feasibility studies, and understanding complex problem spaces.
- Creating a foundational Project Brief to kickstart detailed product definition.
- **Have a relatively clear concept or a Project Brief? You might start with the PM (`2-pm.md`).**
- The PM is best if:
- You have a validated idea and need to define product specifics.
- You have a validated idea and need to define product specifics (Epics, User Stories).
- You have a Project Brief from an Analyst or similar foundational document.
- If foundational information is lacking, the PM can also initiate a "Deep Research Phase" focused on product strategy validation.
- **Output:** A detailed Product Requirements Document (PRD) with Epics and User Stories.
- The PM operates in distinct phases:
- **Deep Research Phase (Optional):** For targeted research to validate product concepts, understand market/user needs specifically for product definition, or analyze competitors. This is more focused than the Analyst's broad research and aims to de-risk PRD commitments. _Output: Research findings/report or key insights summary for PRD generation._
- **PRD Generation Phase (Critical for new projects):** Transforms inputs (Project Brief, research, user ideas) into a comprehensive Product Requirements Document (PRD) using `prd-tmpl.txt`. This includes defining product vision, strategy, epics, user stories, and critical technical assumptions (e.g., monorepo/polyrepo). It also involves a `pm-checklist.txt` assessment. _Output: A complete PRD; a completed PM checklist._
- **Product Advisor Phase (Optional):** For ongoing advice, Q&A on the product/PRD, or managing PRD updates after initial generation. _Output: Conversational advice, updated PRD sections._
- **Key Handoffs:** The PRD is a primary input for the Architect and the Design Architect. The PM will recommend engaging the Design Architect if the product includes a UI.
### 2. Understanding Epics: Single or Multiple?
@@ -61,37 +67,73 @@ Welcome to the BMAD (Brian Madison) Method! This advisor is here to help you nav
- A foundational "setup" epic that establishes core infrastructure before other functional epics.
- The PM, guided by `Epic_Story_Principles` in `2-pm.md`, will help define and structure these.
### 3. The Role of the Architect (Outline for `3-architect.md` - _to be detailed later_)
### 3. The Role of the Architect (`3-architect.md`)
- **Input:** Primarily the PRD from the PM.
- **Core Responsibilities (High-Level):**
- Defining the technical architecture.
- Making key technology stack decisions.
- Designing data models.
- Outlining service interactions and APIs.
- Ensuring scalability, security, and performance considerations are addressed.
- **Output:** A Technical Architecture Document, Solution Design, and potentially initial project scaffolding.
- **Input:** Primarily the PRD from the PM, along with any relevant research or project briefs.
- **Core Responsibilities & Phases:** The Architect translates functional and non-functional requirements into a robust, scalable, and maintainable technical design. It operates in distinct phases:
- **Deep Research Prompt Generation (Optional):** If significant technical unknowns exist, the Architect can help generate a comprehensive research prompt for in-depth investigation of technologies or patterns _before_ architectural commitments. _Output: A structured research prompt._
- **Architecture Creation (Core Phase):** Designs the complete technical architecture, making definitive technology stack choices, defining data models, outlining service interactions, and addressing NFRs (scalability, security, performance). This phase uses `architecture-tmpl.txt` as a guide and is validated with `architect-checklist.txt`. _Output: A comprehensive Architecture Document (including diagrams, tech choices), a list of new/refined technical stories, a completed `architect-checklist.txt`, and optionally, a specific prompt for the Design Architect if UI components are involved._
- **Master Architect Advisory (Ongoing):** Provides expert technical guidance throughout the project lifecycle, helps address challenges, evaluates changes, and manages technical debt _after_ the initial architecture is defined.
- **Key Outputs:** The main deliverable is the **Technical Architecture Document**, which is crucial for developer agents. It may also identify technical stories and provide specific guidance for a Design Architect if a UI is part of the project.
- **AI Agent Optimization:** Focuses on creating well-modularized architectures with clear patterns to facilitate efficient development by AI developer agents.
### 4. Suggested Order of Agent Engagement (Typical Flow):
### 4. The Role of the Design Architect (`4-design-architect.md`)
1. **Analyst (`1-analyst.md`):** (Optional but recommended for new/unclear ideas) For brainstorming, initial research, and creating a Project Brief.
2. **PM (`2-pm.md`):** To take the Project Brief (or a clear idea) and develop a detailed PRD with Epics and User Stories. May conduct its own Deep Research if needed.
3. **Architect (`3-architect.md`):** (_Details to come_) To design the technical solution based on the PRD.
4. **Developer Agents (`4-coder.md`, `5-code-reviewer.md`, etc.):** (_Details to come_) To implement the solution based on architectural guidance and user stories.
- **When to Engage:** If your project includes a User Interface (UI), the Design Architect is crucial. It's typically engaged after the PM has a solid PRD and often works in conjunction with or after the main System Architect has defined the broader technical landscape.
- **Core Responsibilities & Modes:** The Design Architect specializes in both the visual/experiential aspects of the UI and its technical frontend implementation. It operates in distinct modes:
- **UI/UX Specification Mode:** Defines and refines the user experience, information architecture, user flows, and visual design guidelines. _Inputs: Project Brief, PRD, user research. Output: Populated `front-end-spec-tmpl.txt` (with personas, IA, user flows, branding basics, accessibility notes, etc.)._
- **Frontend Architecture Mode:** Defines the technical architecture for the frontend application, including component strategy, state management, API interactions, testing, and deployment, often using `front-end-architecture-tmpl.txt` and `frontend-architecture-checklist.txt`. _Inputs: `front-end-spec-tmpl.txt` content, main System Architecture Document, PRD. Output: Populated `front-end-architecture.md` (or template content) and a completed checklist._
- **AI Frontend Generation Prompt Mode:** Crafts an optimized, comprehensive prompt for AI tools to generate frontend code, synthesizing all relevant specifications. _Inputs: UI/UX Spec, Frontend Architecture doc, System Architecture doc. Output: A "masterful prompt" for AI code generation._
- **Key Outputs:** Delivers the **UI/UX Specification** and the **Frontend Architecture Document**. These are vital for frontend developers and AI code generation tools.
### 5. IDE vs. UI Usage (General Recommendations):
### 5. The Role of the POSM (Technical Product Owner and Scrum Master) (`5-posm.md`)
- **Conceptual & Planning Phases (Analyst, PM, Initial Architect Drafts):**
- **When to Engage:** The POSM is typically engaged after the core planning and design documents (PRD, System Architecture, Frontend Specs if applicable) are considered complete and refined. It acts as a crucial preparation and quality assurance step before intensive development.
- **Core Responsibilities & Phases:** The POSM bridges the gap between approved technical plans and executable development tasks, with a strong focus on documentation integrity and organization.
- **Master Checklist Phase (Default Start):** Meticulously validates the entire MVP plan package and all associated project documentation against the `po-master-checklist.txt`. _Input: All project documents, `po-master-checklist.txt`. Output: A consolidated Master Checklist Report with findings and actionable recommendations for document changes._
- **Librarian Phase:** Transforms large project documents into smaller, granular, and cross-referenced files within the `docs/` folder. Creates and maintains a central `docs/index.md` as a catalog. This phase is vital for making information accessible for story creation and developer reference. _Input: Updated large project documents. Output: Granular files in `docs/`, an updated `docs/index.md`._
- **Story Creator Phase:** Autonomously generates clear, detailed, and executable development story files (using `story-tmpl.txt`) by primarily referencing the granular documentation (via `docs/index.md`) and the PRD/Epics. _Input: `docs/index.md`, granular `docs/` files, PRD, `story-tmpl.txt`. Output: Self-contained story files ready for developer agents._
- **Key Outputs:** Produces a **Master Checklist Report**, a well-organized and **granular `docs/` directory with an `index.md`**, and **developer-ready story files**.
- **Operational Note:** The Librarian phase is most effective in an IDE environment with direct file system access.
- These phases are often well-suited for **web-based UIs** (e.g., Gemini Web as a Gem, or OpenAI as a custom GPT). These environments excel at conversational interaction, document generation (like Project Briefs, PRDs, initial architectural outlines), and iterative refinement of these artifacts.
### 6. Suggested Order of Agent Engagement (Typical Flow):
1. **Analyst (`1-analyst.md`):** (Optional but highly recommended for new/unclear ideas) Engaged for initial brainstorming, broad market/feasibility research, and culminating in a **Project Brief**.
2. **PM (Product Manager) (`2-pm.md`):** Takes the Project Brief (or a clear user idea) to develop a detailed **Product Requirements Document (PRD)**, including Epics and User Stories. May conduct its own focused Deep Research if needed. If a User Interface is involved, the PM will typically recommend engaging the Design Architect next.
3. **Architect (`3-architect.md`):** Takes the PRD as primary input to design the overall **Technical Architecture Document**. This includes tech stack decisions, data models, service interactions, etc. May conduct its own technical Deep Research or generate research prompts. If UI is involved, may provide a specific prompt/context for the Design Architect.
4. **Design Architect (`4-design-architect.md`):** (Engage if the project has a UI) Works from the PRD and in consideration of the System Architecture.
- First, in **UI/UX Specification Mode**, creates the **UI/UX Specification** (content for `front-end-spec-tmpl.txt`).
- Then, in **Frontend Architecture Mode**, defines the **Frontend Architecture Document** (content for `front-end-architecture.md`).
- Optionally, can then create an **AI Frontend Generation Prompt**.
5. **POSM (Technical POSM) (`5-posm.md`):** This agent typically enters after the primary planning and design documents (PRD, System Architecture, UI/UX Spec, Frontend Architecture) are considered complete and refined by the preceding agents.
- **Master Checklist Phase:** Validates all existing documentation against the `po-master-checklist.txt`, producing a **Master Checklist Report** with recommended changes.
- _(User or relevant agents like PM, Architect, Design Architect incorporate the recommended changes into the source documents based on the POSM's report.)_
- **Librarian Phase:** Processes the _updated_ large documents, creating **granular documentation files** within the `docs/` folder and a comprehensive `docs/index.md`.
- **Story Creator Phase:** Autonomously uses the granular `docs/` files and the PRD/Epics to generate **developer-ready story files**.
6. **Developer Agents (e.g., `4-coder.md`, `5-code-reviewer.md` - _details for these specific dev agents to be expanded in their own .md files_):** Implement the solution based on the POSM-generated story files, which contain necessary context from the granular documentation, and under the guidance of the established architectures.
7. **Ongoing Advisory:**
- The **Architect** can be re-engaged in its **Master Architect Advisory** mode for ongoing technical guidance, to address implementation challenges, or evaluate architectural changes.
- The **PM** can be re-engaged in its **Product Advisor Mode** for questions about the product, PRD, or to manage updates.
This flow is a general guideline. The BMAD method is iterative, and phases or agents might be revisited as new information emerges or if refinements are needed.
### 7. IDE vs. UI Usage (General Recommendations):
- **Conceptual & Planning Phases (Analyst, PM, Initial Architect Drafts, Design Architect UI/UX Specification):**
- These phases are often well-suited for **web-based UIs** (e.g., Gemini Web as a Gem, or OpenAI as a custom GPT). These environments excel at conversational interaction, document generation (like Project Briefs, PRDs, initial architectural outlines, UI/UX specifications), and iterative refinement of these artifacts.
- Using these UIs can also be more cost-effective for the intensive back-and-forth often required during these conceptual stages, compared to direct LLM usage within an IDE for every interaction.
- The markdown-based agent instructions (`1-analyst.md`, `2-pm.md`, etc.) are designed to be clear for LLMs operating in such UI environments.
- **Technical Design & Implementation Phases (Detailed Architect Work, Coders):**
- **Technical Design, Documentation Management & Implementation Phases (Detailed Architect Work, Design Architect Frontend Architecture, POSM Librarian & Story Creator, Coders):**
- As work becomes more code-centric, an **IDE environment** offers increasing benefits. This is where code can be directly generated, existing codebases can be referenced, and testing/debugging can occur seamlessly.
- While the Architect might start outlining documents in a web UI, detailed technical specifications, configurations, and initial code scaffolding are best handled or finalized in an IDE.
- Developer agents will primarily operate within an IDE context for implementation tasks.
- As work becomes more code-centric or involves direct file system manipulation, an **IDE environment** offers increasing benefits.
- **Architect & Design Architect (Technical Definition):** While initial outlining might occur in a UI, detailed technical specifications (system architecture, frontend architecture), configurations, and initial code/project scaffolding are best handled or finalized in an IDE.
- **POSM (Librarian & Story Creator):**
- The **Librarian Phase** (decomposing documents, creating `docs/index.md`) is _highly recommended_ to be run in an IDE where the agent has direct file system access. While it can provide content for manual creation in a UI, IDE operation is far more efficient.
- The **Story Creator Phase** can operate in either, but an IDE allows easier cross-referencing with the codebase if needed.
- **Developer Agents:** Will primarily operate within an IDE context for implementation, testing, and debugging tasks.
- **BMAD Method Files (`*.md` in `gems-and-gpts`):** These are the operational prompts for the agents. Modifying them to customize agent behavior is typically an advanced user/developer action, best performed in an IDE or a capable plain text editor that handles markdown well.