readme updates intro beta 3
This commit is contained in:
Brian Madison
92
BETA-V3/checklists/rte-checklist.txt
Normal file
92
BETA-V3/checklists/rte-checklist.txt
Normal file
@@ -0,0 +1,92 @@
|
||||
# RTE-Agent Change Navigation Checklist
|
||||
|
||||
**Purpose:** To systematically guide the RTE-Agent and user through the analysis and planning required when a significant change (pivot, tech issue, missing requirement, failed story) is identified during the BMAD workflow.
|
||||
|
||||
**Instructions:** Review each item with the user. Mark `[x]` for completed/confirmed, `[N/A]` if not applicable, or add notes for discussion points.
|
||||
|
||||
---
|
||||
|
||||
## 1. Understand the Trigger & Context
|
||||
|
||||
- [ ] **Identify Triggering Story:** Clearly identify the story (or stories) that revealed the issue.
|
||||
- [ ] **Define the Issue:** Articulate the core problem precisely.
|
||||
- [ ] Is it a technical limitation/dead-end?
|
||||
- [ ] Is it a newly discovered requirement?
|
||||
- [ ] Is it a fundamental misunderstanding of existing requirements?
|
||||
- [ ] Is it a necessary pivot based on feedback or new information?
|
||||
- [ ] Is it a failed/abandoned story needing a new approach?
|
||||
- [ ] **Assess Initial Impact:** Describe the immediate observed consequences (e.g., blocked progress, incorrect functionality, non-viable tech).
|
||||
- [ ] **Gather Evidence:** Note any specific logs, error messages, user feedback, or analysis that supports the issue definition.
|
||||
|
||||
## 2. Epic Impact Assessment
|
||||
|
||||
- [ ] **Analyze Current Epic:**
|
||||
- [ ] Can the current epic containing the trigger story still be completed?
|
||||
- [ ] Does the current epic need modification (story changes, additions, removals)?
|
||||
- [ ] Should the current epic be abandoned or fundamentally redefined?
|
||||
- [ ] **Analyze Future Epics:**
|
||||
- [ ] Review all remaining planned epics.
|
||||
- [ ] Does the issue require changes to planned stories in future epics?
|
||||
- [ ] Does the issue invalidate any future epics?
|
||||
- [ ] Does the issue necessitate the creation of entirely new epics?
|
||||
- [ ] Should the order/priority of future epics be changed?
|
||||
- [ ] **Summarize Epic Impact:** Briefly document the overall effect on the project's epic structure and flow.
|
||||
|
||||
## 3. Artifact Conflict & Impact Analysis
|
||||
|
||||
- [ ] **Review PRD:**
|
||||
- [ ] Does the issue conflict with the core goals or requirements stated in the PRD?
|
||||
- [ ] Does the PRD need clarification or updates based on the new understanding?
|
||||
- [ ] **Review Architecture Document:**
|
||||
- [ ] Does the issue conflict with the documented architecture (components, patterns, tech choices)?
|
||||
- [ ] Are specific components/diagrams/sections impacted?
|
||||
- [ ] Does the technology list need updating?
|
||||
- [ ] Do data models or schemas need revision?
|
||||
- [ ] Are external API integrations affected?
|
||||
- [ ] **Review Frontend Spec (if applicable):**
|
||||
- [ ] Does the issue conflict with the FE architecture, component library choice, or UI/UX design?
|
||||
- [ ] Are specific FE components or user flows impacted?
|
||||
- [ ] **Review Other Artifacts (if applicable):**
|
||||
- [ ] Consider impact on deployment scripts, IaC, monitoring setup, etc.
|
||||
- [ ] **Summarize Artifact Impact:** List all artifacts requiring updates and the nature of the changes needed.
|
||||
|
||||
## 4. Path Forward Evaluation
|
||||
|
||||
- [ ] **Option 1: Direct Adjustment / Integration:**
|
||||
- [ ] Can the issue be addressed by modifying/adding future stories within the existing plan?
|
||||
- [ ] Define the scope and nature of these adjustments.
|
||||
- [ ] Assess feasibility, effort, and risks of this path.
|
||||
- [ ] **Option 2: Potential Rollback:**
|
||||
- [ ] Would reverting completed stories significantly simplify addressing the issue?
|
||||
- [ ] Identify specific stories/commits to consider for rollback.
|
||||
- [ ] Assess the effort required for rollback.
|
||||
- [ ] Assess the impact of rollback (lost work, data implications).
|
||||
- [ ] Compare the net benefit/cost vs. Direct Adjustment.
|
||||
- [ ] **Option 3: PRD MVP Review & Potential Re-scoping:**
|
||||
- [ ] Is the original PRD MVP still achievable given the issue and constraints?
|
||||
- [ ] Does the MVP scope need reduction (removing features/epics)?
|
||||
- [ ] Do the core MVP goals need modification?
|
||||
- [ ] Are alternative approaches needed to meet the original MVP intent?
|
||||
- [ ] **Extreme Case:** Does the issue necessitate a fundamental replan or potentially a new PRD V2 (to be handled by PM)?
|
||||
- [ ] **Select Recommended Path:** Based on the evaluation, agree on the most viable path forward.
|
||||
|
||||
## 5. Sprint Change Proposal Components
|
||||
|
||||
_(Ensure all agreed-upon points from previous sections are captured in the proposal)_
|
||||
|
||||
- [ ] **Identified Issue Summary:** Clear, concise problem statement.
|
||||
- [ ] **Epic Impact Summary:** How epics are affected.
|
||||
- [ ] **Artifact Adjustment Needs:** List of documents to change.
|
||||
- [ ] **Recommended Path Forward:** Chosen solution with rationale.
|
||||
- [ ] **PRD MVP Impact:** Changes to scope/goals (if any).
|
||||
- [ ] **High-Level Action Plan:** Next steps for stories/updates.
|
||||
- [ ] **Agent Handoff Plan:** Identify roles needed (PM, Arch, Design Arch, POSM).
|
||||
|
||||
## 6. Final Review & Handoff
|
||||
|
||||
- [ ] **Review Checklist:** Confirm all relevant items were discussed.
|
||||
- [ ] **Review Sprint Change Proposal:** Ensure it accurately reflects the discussion and decisions.
|
||||
- [ ] **User Approval:** Obtain explicit user approval for the proposal.
|
||||
- [ ] **Confirm Next Steps:** Reiterate the handoff plan and the next actions to be taken by specific agents.
|
||||
|
||||
---
|
||||
@@ -1,142 +0,0 @@
|
||||
# The BMAD-Method (Breakthrough Method of Agile (ai-driven) Development) - BETA-V3
|
||||
|
||||
If you want to jump right in, here are the [Setup Instructions](./instruction.md) For IDE, WEB and Task setup.
|
||||
|
||||
## BETA-V3: Advancing AI-Driven Development
|
||||
|
||||
Welcome to **BETA-V3** of the BMAD Method! This version represents a significant evolution, building upon the foundations of V2 and introducing a more refined and comprehensive suite of agents, templates, and processes. The `BETA-V3` folder contains the latest implementation, designed to enhance collaboration, documentation, and the overall efficiency of developing projects with AI.
|
||||
|
||||
While `LEGACY-V1` and `CURRENT-V2` folders exist for historical reference, **BETA-V3** is the focus of ongoing development and represents the most advanced iteration of the BMAD Method.
|
||||
|
||||
## Custom Modes and Welcome Contributions
|
||||
|
||||
The BMAD community's input is invaluable! We encourage you to contribute by submitting Pull Requests for custom agent modes, new templates, or checklist enhancements tailored for the `BETA-V3` system. Whether for Web UIs (like Gemini Gems/Custom GPTs) or IDE custom modes, your contributions help expand our AI team's capabilities.
|
||||
|
||||
The Custom Agents in `BETA-V3` continue to follow best practices for LLM prompting (e.g., clear roles, instructions, and context) ensuring they work effectively across various AI platforms.
|
||||
|
||||
## 🔥 Demonstration Walkthrough 🔥
|
||||
|
||||
While a dedicated BETA-V3 video walkthrough is planned, the principles of interactive, phased agent collaboration are well-illustrated in the [V2 Video Walkthrough](https://youtu.be/p0barbrWgQA?si=PD1RyWNVDpdF3QJf). The [`V2-FULL-DEMO-WALKTHROUGH`](../V2-FULL-DEMO-WALKTHROUGH/demo.md) folder (relative to the root) showcases the power of the BMAD Method's step-by-step, human-in-the-loop approach. BETA-V3 further refines this interactivity and documentation linkage.
|
||||
|
||||
## What's New in BETA-V3?
|
||||
|
||||
BETA-V3 introduces several key enhancements to streamline your AI-driven development lifecycle:
|
||||
|
||||
- **Enhanced Agent Roles & Phases:** The core agents (Analyst, PM, Architect) have more clearly defined operational phases, inputs, and outputs, leading to smoother transitions.
|
||||
- **New Specialized Agents:**
|
||||
- **Design Architect:** A dedicated agent for projects with User Interfaces, handling UI/UX Specification and Frontend Technical Architecture in distinct modes.
|
||||
- **Technical POSM (Product Owner & Scrum Master):** A unified agent with critical new capabilities:
|
||||
- **Master Checklist Phase:** Validates all project documentation against a comprehensive checklist (`po-master-checklist.txt`).
|
||||
- **Librarian Phase:** Decomposes large documents into a granular, indexed (`docs/index.md`) documentation ecosystem within your project's `docs/` folder, optimizing for AI agent consumption and human navigability.
|
||||
- **Story Creator Phase:** Autonomously generates detailed, developer-ready story files using the granular documentation.
|
||||
- **Comprehensive & Updated Templates:** New and revised templates support the expanded agent capabilities, including:
|
||||
- `architecture-tmpl.txt` (for System Architecture)
|
||||
- `front-end-spec-tmpl.txt` (for UI/UX Specifications)
|
||||
- `front-end-architecture-tmpl.txt` (for Frontend Technical Architecture)
|
||||
- `story-tmpl.txt` (for developer stories)
|
||||
- And others, located in `BETA-V3/gems-and-gpts/templates/`.
|
||||
- **Detailed Checklists:** New and updated checklists ensure quality and completeness at each stage:
|
||||
- `pm-checklist.txt`
|
||||
- `architect-checklist.txt`
|
||||
- `frontend-architecture-checklist.txt`
|
||||
- `po-master-checklist.txt` (used by the POSM)
|
||||
- Located in `BETA-V3/gems-and-gpts/checklists/`.
|
||||
- **Streamlined Workflow & Documentation Focus:** A more explicit, iterative workflow incorporating all agents, with a strong emphasis on creating and maintaining a robust, granular, and indexed documentation structure to support development.
|
||||
- **Clear Agent Handoffs:** Improved clarity on what each agent produces and what the subsequent agent expects as input.
|
||||
- **Multi-Mode Agents:** Continued philosophy of agents operating in distinct modes or phases tailored to specific tasks.
|
||||
- **IDE and Web UI Parity:** Agent instructions and templates are designed for use in both web-based UIs (see `BETA-V3/gems-and-gpts/`) and IDE custom modes (guidance for IDE setup in `BETA-V3/agents/instructions.md` - _path to be confirmed or created_).
|
||||
|
||||
## Guiding Principles
|
||||
|
||||
- **No Rules Required (Flexibility):** The BMad Method agents are designed to be self-contained or reference project-specific documents, minimizing reliance on proprietary AI platform rule systems. This promotes flexibility and avoids platform lock-in.
|
||||
- **IDE Integration:** For optimal experience, especially for file system operations (like the POSM Librarian phase) and coding tasks, an IDE with custom agent support (e.g., Cursor, RooCode) is recommended. Instructions for setting up custom modes can be found in `BETA-V3/agents/instructions.md` (_path to be confirmed/created_).
|
||||
- **Iterative & Collaborative:** The method emphasizes a step-by-step, interactive process where agents collaborate with the user, pausing for input at key decision points.
|
||||
|
||||
## What is the BMad Method?
|
||||
|
||||
The BMad Method is a revolutionary approach that elevates "vibe coding" to "Vibe CEOing." It provides a structured yet flexible framework to plan, execute, and manage software projects using a team of specialized AI agents. BETA-V3 represents the latest advancement, enabling users to build faster, cheaper, and more effectively by leveraging AI from ideation through to implementation-ready developer stories.
|
||||
|
||||
The method is designed to be tool-agnostic in principle, with agent instructions and workflows adaptable to various AI platforms and IDEs.
|
||||
|
||||
Join the [Community Discussion Forum](https://github.com/bmadcode/BMAD-METHOD/discussions) to contribute and evolve these ideas.
|
||||
|
||||
## BETA-V3 Agent Overview
|
||||
|
||||
The `BETA-V3` system features a refined team of specialized AI agents:
|
||||
|
||||
### 0. BMAD Method Advisor (`0-bmad.md`)
|
||||
|
||||
The primary guide to understanding and navigating the BMAD Method, explaining agent roles, workflows, and best practices.
|
||||
|
||||
### 1. Analyst (`1-analyst.md`)
|
||||
|
||||
The starting point for new or unclear ideas.
|
||||
|
||||
- **Phases:** Brainstorming, Deep Research (broad market/feasibility), Project Briefing.
|
||||
- **Key Output:** A **Project Brief** to inform the PM.
|
||||
|
||||
### 2. Product Manager (PM) (`2-pm.md`)
|
||||
|
||||
Transforms ideas/briefs into detailed product plans.
|
||||
|
||||
- **Phases:** Deep Research (focused product strategy validation), PRD Generation (with Epics, User Stories, technical assumptions), Product Advisor.
|
||||
- **Key Output:** A comprehensive **Product Requirements Document (PRD)** for the Architect & Design Architect.
|
||||
|
||||
### 3. Architect (`3-architect.md`)
|
||||
|
||||
Defines the overall technical blueprint of the system.
|
||||
|
||||
- **Phases:** Deep Research Prompt Generation (for technical unknowns), Architecture Creation (defining tech stack, data models, services), Master Architect Advisory (ongoing guidance).
|
||||
- **Key Output:** The **Technical Architecture Document**.
|
||||
|
||||
### 4. Design Architect (`4-design-architect.md`)
|
||||
|
||||
Specializes in UI/UX and frontend technical strategy for projects with a user interface.
|
||||
|
||||
- **Modes:** UI/UX Specification (defining user experience, flows, visual guidelines), Frontend Architecture (defining frontend tech stack, components, state management), AI Frontend Generation Prompt (crafting prompts for AI code generators).
|
||||
- **Key Outputs:** **UI/UX Specification Document** (`front-end-spec-tmpl.txt` based) and **Frontend Architecture Document** (`front-end-architecture-tmpl.txt` based).
|
||||
|
||||
### 5. Technical POSM (`5-posm.md`)
|
||||
|
||||
Ensures documentation quality and prepares for development.
|
||||
|
||||
- **Phases:**
|
||||
- **Master Checklist Phase:** Validates all project docs against `po-master-checklist.txt`. Output: **Checklist Report**.
|
||||
- **Librarian Phase:** Decomposes large documents into granular files in `docs/`, creating/maintaining `docs/index.md`. Output: **Organized granular documentation**.
|
||||
- **Story Creator Phase:** Autonomously generates developer-ready **story files** from granular docs and PRD.
|
||||
- **Crucial for:** Documentation integrity and preparing actionable tasks for developers.
|
||||
|
||||
### 6. Developer Agents (e.g., `X-coder.md`, `Y-code-reviewer.md`)
|
||||
|
||||
(Specific prompts for these agents reside in `BETA-V3/agents/` or `BETA-V3/gems-and-gpts/`)
|
||||
Implement features based on stories from the POSM, adhering to defined architectures and coding standards.
|
||||
|
||||
## BETA-V3 Step-by-Step Process (Typical Flow)
|
||||
|
||||
1. **Analyst (`1-analyst.md`):** (Optional) Brainstorming, research -> **Project Brief**.
|
||||
2. **PM (`2-pm.md`):** Project Brief/idea -> **PRD** (Epics, Stories). Recommends Design Architect if UI.
|
||||
3. **Architect (`3-architect.md`):** PRD -> **System Architecture Document**.
|
||||
4. **Design Architect (`4-design-architect.md`):** (If UI) PRD, System Arch -> **UI/UX Spec**, then **Frontend Architecture Doc**. Optionally, an AI Frontend Generation Prompt.
|
||||
5. **POSM (`5-posm.md`) - Master Checklist Phase:** Validates all docs -> **Master Checklist Report**.
|
||||
6. _(User/Other Agents apply changes based on POSM's report to source documents)_.
|
||||
7. **POSM (`5-posm.md`) - Librarian Phase:** Processes updated docs -> **Granular `docs/` files & `docs/index.md`**.
|
||||
8. **POSM (`5-posm.md`) - Story Creator Phase:** Granular docs & PRD -> **Developer Story Files**.
|
||||
9. **Developer Agents:** Implement stories.
|
||||
10. **Ongoing Advisory:** Architect (Master Architect Advisory) & PM (Product Advisor) provide continuous support.
|
||||
|
||||
_This is a guideline; the BMAD method is iterative._
|
||||
|
||||
## Template & Tooling Information (BETA-V3)
|
||||
|
||||
- **Templates:** Core templates for agent outputs (Project Brief, PRD, Architecture, Frontend Specs, Stories, etc.) are located in `BETA-V3/gems-and-gpts/templates/`.
|
||||
- **Checklists:** Detailed checklists for various phases are in `BETA-V3/gems-and-gpts/checklists/`.
|
||||
- **Web UI (Gems/GPTs):** Agent instructions optimized for web UIs (Gemini Gems, Custom GPTs) are in `BETA-V3/gems-and-gpts/`. Attach templates from the `templates` folder to these. See `BETA-V3/gems-and-gpts/instruction.md`.
|
||||
- **IDE Custom Modes:** Guidance for setting up agents in IDEs can be found in `BETA-V3/agents/instructions.md` (This path is an example; actual IDE-specific prompts might be directly within `BETA-V3/gems-and-gpts/` or a dedicated `BETA-V3/agents/` folder if it's created for distinct IDE versions).
|
||||
|
||||
## License
|
||||
|
||||
[License](./LICENSE) (Assuming license is in root and applies)
|
||||
|
||||
## Contributing
|
||||
|
||||
Interested in improving the BMAD Method BETA-V3? See our [contributing guidelines](./CONTRIBUTING.md). (Assuming contributing guide is in root)
|
||||
88
BETA-V3/ide-agent-modes/rte-agent.md
Normal file
88
BETA-V3/ide-agent-modes/rte-agent.md
Normal file
@@ -0,0 +1,88 @@
|
||||
# Role: RTE-Agent (Change Navigator & Integration Expert)
|
||||
|
||||
## Critical Start Up Operating Instructions
|
||||
|
||||
<rule>When conversing, do not provide references to sections or documents the user provided, as this will be very confusing for the user as they generally are not understandable the way you provide them as your sectioning is not tied to navigable sections as documented</rule>
|
||||
|
||||
1. **Trigger & Context:** Confirm change trigger. User explains issue & perceived impact.
|
||||
|
||||
2. **Checklist Operation:** State phase is **[Change Navigation & Integration Phase](#change-navigation--integration-phase)**. Inform user of interactive `docs/checklists/rte-checklist.md` usage for analysis and _drafting proposed changes_.
|
||||
|
||||
3. **Interaction Mode (Checklist & Drafting):** Ask user: Incremental (default, section by section analysis, then propose changes) or YOLO (batched analysis & change proposals)? Confirm choice.
|
||||
|
||||
4. **Principles:** Act as neutral facilitator & PM/Technical expert for change integration. Guide objective assessment via checklist. _Draft specific, actionable updates_ to artifacts (stories, architecture). Focus on achievable MVP. Use project artifacts (e.g., from `docs/`) for checklist completion & change drafting.
|
||||
|
||||
---
|
||||
|
||||
## Change Navigation & Integration Phase
|
||||
|
||||
### Purpose
|
||||
|
||||
- Guide change response using `docs/checklists/rte-checklist.md`.
|
||||
- Analyze impacts (epics, artifacts, MVP) via checklist structure.
|
||||
- Explore solutions (adjust, rollback, rescope) as prompted by checklist.
|
||||
- **Draft specific proposed updates** to affected artifacts (epics, stories, architecture docs) based on analysis.
|
||||
- Produce "Sprint Change Proposal" containing analysis and **proposed edits** for user approval.
|
||||
- Ensure clear handoff _if_ changes require fundamental replanning (back to PM/Arch).
|
||||
|
||||
### Phase Persona
|
||||
|
||||
- **Role:** Checklist-Driven Change Facilitator, Analyst, Strategist, **Acting PM/Technical Editor for Changes**.
|
||||
- **Style:** Analytical, objective, structured, collaborative; completes `docs/checklists/rte-checklist.md` thoroughly with user, **proposes concrete artifact edits**.
|
||||
- **Expertise:** Agile/BMAD, impact/risk analysis, **PRD/epic/story writing, technical documentation updating**; skilled in guiding checklist use and **drafting specific change implementations**.
|
||||
|
||||
### Instructions
|
||||
|
||||
1. **Initiate Checklist:** Confirm context. Announce start of `docs/checklists/rte-checklist.md` process, per chosen interaction mode.
|
||||
|
||||
2. **Execute Checklist Analysis:** Interactively complete `docs/checklists/rte-checklist.md` Sections 1-4 (Context, Epic Impact, Artifact Conflict, Path Evaluation). For each item:
|
||||
|
||||
- Present prompt to user.
|
||||
- Request/gather information and analyze relevant artifacts (PRD, epics, architecture docs - likely found in `docs/` or project structure).
|
||||
- Discuss findings, mark item status (`[x]`, `[N/A]`, notes). Agree on Recommended Path (checklist Section 4).
|
||||
|
||||
3. **Draft Proposed Changes:** Based on the completed checklist analysis and the agreed path forward (excluding fundamental replans):
|
||||
|
||||
- Identify specific artifacts requiring updates (epics, stories, architecture doc sections, etc.).
|
||||
- **Draft the proposed changes directly.** Examples:
|
||||
- Revising story text or acceptance criteria.
|
||||
- Adding/removing/reordering stories within epics.
|
||||
- Proposing modified architecture diagram snippets (e.g., textual description or simplified Mermaid update).
|
||||
- Updating technology lists or specific configuration details.
|
||||
- Discuss and refine these proposed edits interactively with the user.
|
||||
|
||||
4. **Generate Proposal with Edits:**
|
||||
|
||||
- Synthesize the checklist analysis (Sections 1-4) and the **agreed-upon proposed edits** into the "Sprint Change Proposal" (incorporating checklist Section 5 components).
|
||||
- The proposal should clearly present:
|
||||
- The analysis summary (Issue, Impact, Path Rationale).
|
||||
- **The specific proposed edits** for each affected artifact.
|
||||
- Present the complete proposal draft for final user review.
|
||||
|
||||
5. **Finalize & Handoff:** Obtain user approval for the Sprint Change Proposal (including the specific edits).
|
||||
- Provide final document.
|
||||
- **If approved edits cover all necessary actions:** State completion or handoff to POSM for organization.
|
||||
- **If fundamental replan needed (rare case):** State next steps involve engaging PM/Architect with the proposal as context/prompt (per checklist Section 6).
|
||||
|
||||
### Output Deliverables
|
||||
|
||||
- Primary: **Sprint Change Proposal** (markdown), containing analysis summary and **specific proposed edits** to artifacts.
|
||||
- Implicit: Annotated `docs/checklists/rte-checklist.md` reflecting discussion.
|
||||
|
||||
### Output Formatting Critical Rules
|
||||
|
||||
**General Presentation & Content:**
|
||||
|
||||
- Present the Sprint Change Proposal (drafts or final) in a clean, well-structured, and complete markdown format.
|
||||
- Clearly delineate between analysis summary and proposed edits.
|
||||
- DO NOT truncate information. Strive for clarity and directness.
|
||||
|
||||
**Markdown Usage and Structure (to prevent nesting issues and ensure correct rendering):**
|
||||
|
||||
- **DO NOT** wrap the entire document output in additional outer markdown code blocks (e.g., a single \`\`\` encompassing everything). This is critical.
|
||||
- **DO** properly format all individual elements within the document, including inline sections and partial updates, for correct rendering. This is critical to prevent nested markdown issues and ensure correct rendering in various UIs or markdown processors. This includes:
|
||||
- Code snippets (if any, including proposed story text) must be enclosed in appropriate language-specific \`\`\` blocks.
|
||||
- Tables (if any) must use proper markdown table syntax.
|
||||
- Use standard markdown formatting (headings, lists, bolding) for clarity and structure.
|
||||
|
||||
---
|
||||
@@ -16,6 +16,7 @@ To set up web-mode agents, please refer to the table below. It outlines the agen
|
||||
| 3-architect | `BETA-V3/web-agent-modes/3-architect.md` | `BETA-V3/templates/architecture-tmpl.txt`, `BETA-V3/checklists/architect-checklist.txt` |
|
||||
| 4-design-architect | `BETA-V3/web-agent-modes/4-design-architect.md` | `BETA-V3/templates/front-end-architecture-tmpl.txt`, `BETA-V3/templates/front-end-spec-tmpl.txt`, `BETA-V3/checklists/frontend-architecture-checklist.txt` |
|
||||
| 5-posm | `BETA-V3/web-agent-modes/5-posm.md` | `BETA-V3/checklists/po-master-checklist.txt`, `BETA-V3/templates/story-tmpl.txt`, `BETA-V3/checklists/story-draft-checklist.txt`, `BETA-V3/checklists/story-dod-checklist.txt` |
|
||||
| 6-rte | `BETA-V3/web-agent-modes/6-rte.md` | `BETA-V3/checklists/rte-checklist.md` |
|
||||
|
||||
## IDE Agent Setup
|
||||
|
||||
|
||||
3
BETA-V3/v3-demos/project1/readme.md
Normal file
3
BETA-V3/v3-demos/project1/readme.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# Project 1 Demo
|
||||
|
||||
Hacker News AI Podcast NextJS Monorepo
|
||||
@@ -109,7 +109,18 @@ Welcome to the BMAD (Brian Madison) Method! This advisor is here to help you nav
|
||||
- **Key Outputs:** Produces a **Master Checklist Report**, a well-organized and **granular `docs/` directory with an `index.md`**, and **developer-ready story files** (which, in the case of agents like `sm-agent.md`, includes user validation).
|
||||
- **Operational Note:** The Librarian phase is most effective in an IDE environment with direct file system access.
|
||||
|
||||
### 6. Suggested Order of Agent Engagement (Typical Flow):
|
||||
### 6. Handling Major Changes: The RTE-Agent (`6-rte.md`)
|
||||
|
||||
- **When to Engage:** The Release Train Engineer (RTE-Agent) is your go-to specialist when a completed or failed story uncovers a significant issue requiring a substantial change in direction, technology, or reveals critical missing requirements.
|
||||
- **Core Responsibilities:**
|
||||
- The RTE-Agent uses a checklist (`docs/checklists/rte-checklist.md` for IDE mode, or attached `BETA-V3/checklists/rte-checklist.md` for web mode) to systematically analyze the impact of the change across epics, the PRD, architecture documents, and other artifacts.
|
||||
- It helps evaluate paths forward, including direct adjustments, potential rollbacks, or PRD MVP re-scoping.
|
||||
- Crucially, for most scenarios, the RTE-Agent acts as an "Acting PM/Technical Editor" and will **draft specific proposed updates** to the affected documents and stories.
|
||||
- **Key Output:** The **Sprint Change Proposal**, which contains the analysis, the recommended path, and the _drafted changes_ for your approval.
|
||||
- **When it Handoffs:** If the analysis determines a fundamental project replan or a major PRD rewrite is necessary, the RTE-Agent will prepare a detailed handoff to the PM or Architect, rather than drafting the entire overhaul itself.
|
||||
- **Purpose:** To ensure significant mid-project course corrections are managed effectively, allowing the project to adapt while maintaining focus on an achievable (though potentially revised) MVP.
|
||||
|
||||
### 7. 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.
|
||||
@@ -142,7 +153,7 @@ Welcome to the BMAD (Brian Madison) Method! This advisor is here to help you nav
|
||||
|
||||
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):
|
||||
### 8. IDE vs. UI Usage (General Recommendations):
|
||||
|
||||
- **Conceptual & Planning Phases (Analyst, PM, Initial Architect Drafts, Design Architect UI/UX Specification):**
|
||||
|
||||
@@ -161,6 +172,25 @@ Welcome to the BMAD (Brian Madison) Method! This advisor is here to help you nav
|
||||
|
||||
- **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.
|
||||
|
||||
### 9. Leveraging IDE Tasks for Efficiency
|
||||
|
||||
For IDE users, the BMAD Method V3 introduces a powerful concept of **Tasks**, located in the `BETA-V3/tasks/` directory. These tasks are self-contained instruction sets designed to perform specific, often one-off jobs that might not warrant a dedicated, persistent agent mode.
|
||||
|
||||
**Purpose of IDE Tasks:**
|
||||
|
||||
- **Reduce Agent Bloat:** Instead of adding numerous, rarely used instructions to your primary IDE agent modes (like the Dev Agent or SM Agent), tasks provide a lean way to execute specific functions. This is particularly beneficial for IDEs with limits on custom agent complexity or numbers.
|
||||
- **On-Demand Functionality:** You can instruct your active IDE agent to perform a task by providing the content of the relevant task file (e.g., `checklist-run-task.md`) as a prompt. The task file contains all the necessary instructions for the agent to complete that specific job.
|
||||
- **Versatility:** Any sufficiently capable agent can be asked to execute a task.
|
||||
|
||||
**Examples of Task Functionality:**
|
||||
|
||||
- Running a chosen checklist against a document (e.g., `checklist-run-task.md`).
|
||||
- Generating the next story file based on an epic (e.g., `create-next-story-task.md`).
|
||||
- Breaking down (sharding) a large document into smaller, more manageable pieces (e.g., `doc-sharding-task.md`).
|
||||
- Indexing key information from a library or set of documents (e.g., `library-indexing-task.md`).
|
||||
|
||||
Think of tasks as specialized, callable mini-agents that your main IDE agents can invoke on demand, keeping the primary agent definitions streamlined and focused on their core roles.
|
||||
|
||||
---
|
||||
|
||||
This initial guidance will be expanded with more expert intelligence as the V3 Beta evolves. Feel free to ask specific questions about the method at any time!
|
||||
|
||||
88
BETA-V3/web-agent-modes/6-rte.md
Normal file
88
BETA-V3/web-agent-modes/6-rte.md
Normal file
@@ -0,0 +1,88 @@
|
||||
# Role: RTE-Agent (Change Navigator & Integration Expert)
|
||||
|
||||
## Critical Start Up Operating Instructions
|
||||
|
||||
<rule>When conversing, do not provide references to sections or documents the user provided, as this will be very confusing for the user as they generally are not understandable the way you provide them as your sectioning is not tied to navigable sections as documented</rule>
|
||||
|
||||
1. **Trigger & Context:** Confirm change trigger. User explains issue & perceived impact.
|
||||
|
||||
2. **Checklist Operation:** State phase is **[Change Navigation & Integration Phase](#change-navigation--integration-phase)**. Inform user of interactive `rte-checklist.md` usage for analysis and _drafting proposed changes_.
|
||||
|
||||
3. **Interaction Mode (Checklist & Drafting):** Ask user: Incremental (default, section by section analysis, then propose changes) or YOLO (batched analysis & change proposals)? Confirm choice.
|
||||
|
||||
4. **Principles:** Act as neutral facilitator & PM/Technical expert for change integration. Guide objective assessment via checklist. _Draft specific, actionable updates_ to artifacts (stories, architecture). Focus on achievable MVP. Use project artifacts for checklist completion & change drafting.
|
||||
|
||||
---
|
||||
|
||||
## Change Navigation & Integration Phase
|
||||
|
||||
### Purpose
|
||||
|
||||
- Guide change response using `rte-checklist.md`.
|
||||
- Analyze impacts (epics, artifacts, MVP) via checklist structure.
|
||||
- Explore solutions (adjust, rollback, rescope) as prompted by checklist.
|
||||
- **Draft specific proposed updates** to affected artifacts (epics, stories, architecture docs) based on analysis.
|
||||
- Produce "Sprint Change Proposal" containing analysis and **proposed edits** for user approval.
|
||||
- Ensure clear handoff _if_ changes require fundamental replanning (back to PM/Arch).
|
||||
|
||||
### Phase Persona
|
||||
|
||||
- **Role:** Checklist-Driven Change Facilitator, Analyst, Strategist, **Acting PM/Technical Editor for Changes**.
|
||||
- **Style:** Analytical, objective, structured, collaborative; completes `rte-checklist.md` thoroughly with user, **proposes concrete artifact edits**.
|
||||
- **Expertise:** Agile/BMAD, impact/risk analysis, **PRD/epic/story writing, technical documentation updating**; skilled in guiding checklist use and **drafting specific change implementations**.
|
||||
|
||||
### Instructions
|
||||
|
||||
1. **Initiate Checklist:** Confirm context. Announce start of `BETA-V3/checklists/rte-checklist.md` process, per chosen interaction mode.
|
||||
|
||||
2. **Execute Checklist Analysis:** Interactively complete `rte-checklist.md` Sections 1-4 (Context, Epic Impact, Artifact Conflict, Path Evaluation). For each item:
|
||||
|
||||
- Present prompt to user.
|
||||
- Request/gather information and analyze relevant artifacts (PRD, epics, architecture, story history).
|
||||
- Discuss findings, mark item status (`[x]`, `[N/A]`, notes). Agree on Recommended Path (checklist Section 4).
|
||||
|
||||
3. **Draft Proposed Changes:** Based on the completed checklist analysis and the agreed path forward (excluding fundamental replans):
|
||||
|
||||
- Identify specific artifacts requiring updates (epics, stories, architecture doc sections, etc.).
|
||||
- **Draft the proposed changes directly.** Examples:
|
||||
- Revising story text or acceptance criteria.
|
||||
- Adding/removing/reordering stories within epics.
|
||||
- Proposing modified architecture diagram snippets (e.g., textual description or simplified Mermaid update).
|
||||
- Updating technology lists or specific configuration details.
|
||||
- Discuss and refine these proposed edits interactively with the user.
|
||||
|
||||
4. **Generate Proposal with Edits:**
|
||||
|
||||
- Synthesize the checklist analysis (Sections 1-4) and the **agreed-upon proposed edits** into the "Sprint Change Proposal" (incorporating checklist Section 5 components).
|
||||
- The proposal should clearly present:
|
||||
- The analysis summary (Issue, Impact, Path Rationale).
|
||||
- **The specific proposed edits** for each affected artifact.
|
||||
- Present the complete proposal draft for final user review.
|
||||
|
||||
5. **Finalize & Handoff:** Obtain user approval for the Sprint Change Proposal (including the specific edits).
|
||||
- Provide final document.
|
||||
- **If approved edits cover all necessary actions:** State completion or handoff to POSM for organization.
|
||||
- **If fundamental replan needed (rare case):** State next steps involve engaging PM/Architect with the proposal as context/prompt (per checklist Section 6).
|
||||
|
||||
### Output Deliverables
|
||||
|
||||
- Primary: **Sprint Change Proposal** (markdown), containing analysis summary and **specific proposed edits** to artifacts.
|
||||
- Implicit: Annotated `rte-checklist.md` reflecting discussion.
|
||||
|
||||
### Output Formatting Critical Rules
|
||||
|
||||
**General Presentation & Content:**
|
||||
|
||||
- Present the Sprint Change Proposal (drafts or final) in a clean, well-structured, and complete markdown format.
|
||||
- Clearly delineate between analysis summary and proposed edits.
|
||||
- DO NOT truncate information. Strive for clarity and directness.
|
||||
|
||||
**Markdown Usage and Structure (to prevent nesting issues and ensure correct rendering):**
|
||||
|
||||
- **DO NOT** wrap the entire document output in additional outer markdown code blocks (e.g., a single \`\`\` encompassing everything). This is critical.
|
||||
- **DO** properly format all individual elements within the document, including inline sections and partial updates, for correct rendering. This is critical to prevent nested markdown issues and ensure correct rendering in various UIs or markdown processors. This includes:
|
||||
- Code snippets (if any, including proposed story text) must be enclosed in appropriate language-specific \`\`\` blocks.
|
||||
- Tables (if any) must use proper markdown table syntax.
|
||||
- Use standard markdown formatting (headings, lists, bolding) for clarity and structure.
|
||||
|
||||
---
|
||||
320
README.md
320
README.md
@@ -1,268 +1,154 @@
|
||||
# The BMAD-Method (Breakthrough Method of Agile (ai-driven) Development)
|
||||
|
||||
## Beta V3
|
||||
**BETA-V3 is the current focus of development and represents the latest iteration of the BMAD Method.** Find all V3 resources in the `BETA-V3/` directory.
|
||||
|
||||
The initial release of Beta-V3 is now available. It still is undergoing testing and so far, it has solid web agents (for gems and gpts) and optimized slimmed down ide agents, and the introduction of ide tasks to handle one of jobs without needing a dedicated agent (helpful with cursor custom mode limit and also helps with windsurf reducing the size to keep ide agent modes below 6k characters).
|
||||
If you want to jump right in, here are the [Setup Instructions for V3](./BETA-V3/instruction.md) For IDE, WEB and Task setup.
|
||||
|
||||
## BETA-V3: Advancing AI-Driven Development
|
||||
|
||||
Welcome to **BETA-V3**! This version represents a significant evolution, building upon the foundations of V2 and introducing a more refined and comprehensive suite of agents, templates, checklists, and processes.
|
||||
|
||||
Feel free to try it out - its beta, so please know its still undergoing testing and updates and there are some significant (amazing improvements) changes.
|
||||
|
||||
**IMPORTANT NOTE ABOUT CHAT GPT CUSTOM GPTS:** When setting up Custom GPT's the max character limit is 8k. But the work around until the agent sizes get reduced is to attached the whole markdown agent profile as a file attachment to the gpt, then just give it a name and description. In the instructions - tell it something like "You are XYZ Agent and your system operating instructions, personality and programming are all contained in the attached knowledge file XYZ.MD. You never deviate from that files programming.
|
||||
_Previous versions (`LEGACY-V1` and `CURRENT-V2`) are available for historical reference but are no longer actively maintained._
|
||||
|
||||
## Major Update: V2 Final Release
|
||||
## What's New in BETA-V3?
|
||||
|
||||
The BMad Method has undergone a significant transformation with our V2 (beta) release! The previous implementation (still available in the `LEGACY-V1` folder) has been replaced by a drastically improved workflow and agent system in the `CURRENT-V2` folder.
|
||||
BETA-V3 introduces several key enhancements to streamline your AI-driven development lifecycle:
|
||||
|
||||
NOTE V1 will be removed soon and V2 will be the main mode going forward.
|
||||
- **Enhanced Agent Roles & Phases:** The core agents (Analyst, PM, Architect) have more clearly defined operational phases, inputs, and outputs, leading to smoother transitions.
|
||||
- **New Specialized Agents:**
|
||||
- **Design Architect (`4-design-architect.md`):** A dedicated agent for projects with User Interfaces, handling UI/UX Specification and Frontend Technical Architecture in distinct modes.
|
||||
- **Technical POSM (`5-posm.md`) (Product Owner & Scrum Master):** A unified agent with critical new capabilities:
|
||||
- **Master Checklist Phase:** Validates all project documentation against a comprehensive checklist (`po-master-checklist.txt`).
|
||||
- **Librarian Phase:** Decomposes large documents into a granular, indexed (`docs/index.md`) documentation ecosystem within your project's `docs/` folder, optimizing for AI agent consumption and human navigability (IDE recommended).
|
||||
- **Story Creator Phase:** Autonomously generates detailed, developer-ready story files using the granular documentation.
|
||||
- **Release Train Engineer (RTE-Agent) (`6-rte.md`):** A crucial agent for navigating significant mid-project changes (pivots, tech issues, missed requirements), analyzing impacts, and drafting necessary artifact updates.
|
||||
- **IDE Tasks (`BETA-V3/tasks/`):** Self-contained instruction sets for IDE agents to perform specific one-off jobs (e.g., run checklist, create next story, shard docs) without bloating main agent definitions. [Read more below](#ide-tasks-v3-exclusive).
|
||||
- **Comprehensive & Updated Templates:** New and revised templates support the expanded agent capabilities, located in `BETA-V3/templates/`.
|
||||
- **Detailed Checklists:** New and updated checklists ensure quality and completeness at each stage, located in `BETA-V3/checklists/`.
|
||||
- **Streamlined Workflow & Documentation Focus:** A more explicit, iterative workflow incorporating all agents, with a strong emphasis on creating and maintaining a robust, granular, and indexed documentation structure (`docs/`) to support development.
|
||||
- **Clear Agent Handoffs:** Improved clarity on what each agent produces and what the subsequent agent expects as input.
|
||||
- **Optimized IDE Agents:** IDE agent modes (`BETA-V3/ide-agent-modes/`) are optimized for size (<6k tokens) for broader IDE compatibility.
|
||||
- **Web UI Parity:** Agent instructions and templates are designed for use in both web-based UIs (instructions and files in `BETA-V3/web-agent-modes/`) and IDE custom modes.
|
||||
|
||||
## Custom Modes and Welcome Contributions
|
||||
## Guiding Principles (V3)
|
||||
|
||||
So many great suggestions and ideas coming from the community - please feel free to PR any suggested custom agent mode's for either Gems/GPTs or the IDE (or both) to help expand the pantheon of our AI team of helpers :)
|
||||
|
||||
The Custom Agents follow this [great way to format rules](https://docs.windsurf.com/windsurf/memories#best-practices) to keep them optimized for LLMs (and this guidance matches official sonnet, openAI, and Gemini prompting guides) and are proven to work well in Cursor, Windsurf, VSCode (+ Client, Roo, CoPilot)
|
||||
|
||||
## 🔥 Full Demonstration Walkthrough 🔥
|
||||
|
||||
**See it in action!** [Video Walkthrough](https://youtu.be/p0barbrWgQA?si=PD1RyWNVDpdF3QJf) - The [`V2-FULL-DEMO-WALKTHROUGH`](./V2-FULL-DEMO-WALKTHROUGH/demo.md) folder contains a complete end-to-end demonstration of the BMad Method V2 in action. This isn't just documentation—it's proof of how remarkably effective and powerful Vibe-CEO'ing with the BMAD Method is!
|
||||
|
||||
The walkthrough includes:
|
||||
|
||||
- **Full Gemini chat transcripts** for every phase of the process
|
||||
- **All output artifacts** that flow between agents
|
||||
- **Detailed commentary** on the interactive process
|
||||
|
||||
What makes this demo exceptional is seeing how the agents work in **interactive phases**, pausing at key decision points for human input rather than dumping massive documents at once. No other AI development methodology provides this level of collaborative workflow with documented results where the agent works with you step by step.
|
||||
|
||||
[Explore the demo](./V2-FULL-DEMO-WALKTHROUGH/) and see how this transforms software development from ideation to implementation-ready agent stories and tasks.
|
||||
|
||||
## What's New in V2?
|
||||
|
||||
- **Optimized Agent Prompts**: Completely revised agent prompts for better outputs
|
||||
- **Standardized Templates**: Comprehensive set of templates for consistent document creation
|
||||
- **Streamlined Workflow**: Clearer process from idea to deployment
|
||||
- **Improved Agile Integration**: Better support for agile methodologies
|
||||
- **Agent vs Gem Agent Distinction**: V2 has specific [gems](#custom-gems-and-gpts) (agent with embedded templates) in parity with the IDE agents.
|
||||
- **Comprehensive Checklists**: New detailed checklists for PM, Architect, and PO roles to ensure quality and completeness at each phase!
|
||||
- **Multi-Mode Agents**: Each agent now operates in distinct modes tailored to different project phases or complexity levels - allowing flexibility to match your project needs and knowledge level
|
||||
- **Reduced Redundancy**: V2 agents and gems use consistent XML-tagged formatting optimized for LLMs, making them more efficient and easier to maintain
|
||||
- **Dev-SM Parity**: The stories produced by the SM agent maintain parity with what the Dev agent is told to load on its own and expects, reducing duplication and ensuring smooth handoffs. If not using the dev agent custom mode, ensure your IDE agent rules include all information from the dev agent for compatibility. For example, the dev agent knows to load docs/coding-standards and project-structure - so this should not be repeated (but might be linked) in the generated stories.
|
||||
|
||||
## No Rules Required!
|
||||
|
||||
One of the biggest advantages of the BMad Method is that it doesn't require custom rules when using the custom agents. The dev agents and other personas are configured to automatically reference standards documents when coding. This provides two major benefits:
|
||||
|
||||
1. **No Platform Lock-in**: Work across any AI system without being tied to proprietary rule formats
|
||||
2. **Maximum Flexibility**: Still compatible with rules-based systems like Claude or Cursor if you prefer that approach
|
||||
|
||||
This flexibility allows you to choose the implementation that works best for your workflow while maintaining consistent quality across your project.
|
||||
|
||||
## IDE Agent Integration
|
||||
|
||||
The BMad Method now includes detailed [instructions for setting up custom agent modes](./CURRENT-V2/agents/instructions.md) in various IDEs. For the most direct translation of the full agent system, especially for the crucial SM and Dev agent roles, the following are recommended:
|
||||
|
||||
- **RooCode**: Excellent custom mode support with robust file permission controls and mode switching
|
||||
- **Cursor**: Strong custom agent capabilities with advanced context management
|
||||
|
||||
Both provide an optimal experience for implementing the BMAD workflow, though the method can be adapted to work with any IDE. See the full [instructions file](./CURRENT-V2/agents/instructions.md) for details on configuring each supported IDE.
|
||||
- **Environment Recommendations & Workflow:**
|
||||
- **Web UI Preferred for Initial Planning (Agents 0-5):** For initial ideation, research, PRD creation, architecture design, UI/UX specification, and initial documentation validation (Analyst, PM, Architect, Design Architect, and POSM Master Checklist phase), Web UIs (Gems/Custom GPTs) are highly effective and often more cost-efficient for the iterative, conversational nature of these tasks.
|
||||
- **POSM - Librarian & Story Creator:** While the POSM's Librarian phase (document sharding and indexing) is strongly recommended for an IDE due to file system operations, the Story Creator phase _can_ be done in a Web UI. However, an IDE is often preferred for easier cross-referencing with existing `docs/` content and the eventual codebase.
|
||||
- **IDE Recommended for Execution & Specialized Tasks:** For development (Dev Agent), detailed story generation (SM Agent or POSM Story Creator in IDE), and managing significant mid-project changes (RTE-Agent), an IDE environment with custom agent modes is generally more powerful and efficient. The core recommended IDE agents, especially after initial web-based planning, are the **Dev Agent, SM/Story Creator, and RTE-Agent**.
|
||||
- **Quality & Information Flow (V3 Enhancements):**
|
||||
- The **PM Agent** is tuned to produce higher quality, more detailed Epics and User Stories.
|
||||
- There's improved consistency between what the **SM Agent (or POSM in Story Creator mode)** includes in story files and what the **Dev Agent** expects. The SM focuses on embedding necessary contextual details directly into the story.
|
||||
- The **Dev Agent** is programmed to always consult standard project documents like `docs/coding-standards.md` and `docs/project-structure.md` upon starting a new story. This reduces the need to repeat this boilerplate information in every story file, keeping stories leaner and focused on the specific requirements.
|
||||
- **No Rules Required (Flexibility):** Agents primarily reference project documents (PRDs, architecture docs, coding standards, etc.) rather than relying heavily on proprietary AI platform rule systems. This promotes flexibility and reduces platform lock-in.
|
||||
- **Iterative & Collaborative:** The method emphasizes a step-by-step, interactive process where agents collaborate with the user, pausing for input and validation at key decision points.
|
||||
|
||||
## What is the BMad Method?
|
||||
|
||||
The BMad Method is a revolutionary approach that elevates "vibe coding" to the next level—what I call "Vibe CEOing." Unlike the spontaneity of pure vibe coding for quick prototypes, this method helps you plan, execute, and keep your project on track. Build faster, cheaper, and easier while leveraging AI-driven processes to accelerate and enhance the entire product development lifecycle from ideation and market fit through agentic code implementation.
|
||||
The BMad Method is a revolutionary approach that elevates "vibe coding" to "Vibe CEOing." It provides a structured yet flexible framework to plan, execute, and manage software projects using a team of specialized AI agents. BETA-V3 represents the latest advancement, enabling users to build faster, cheaper, and more effectively by leveraging AI from ideation through to implementation-ready developer stories.
|
||||
|
||||
This V2 release incorporates valuable feedback from V1 users and draws inspiration from projects like Claude's memory bank and the Taskmaster project. However, the BMad Method goes further by providing a comprehensive framework for those who want to thoroughly define and develop projects from conception to completion.
|
||||
The method is designed to be tool-agnostic in principle, with agent instructions and workflows adaptable to various AI platforms and IDEs.
|
||||
|
||||
This comprehensive, step-by-step approach transforms a product idea into a fully implemented application by:
|
||||
Join the [Community Discussion Forum](https://github.com/bmadcode/BMAD-METHOD/discussions) to contribute and evolve these ideas.
|
||||
|
||||
1. Structuring the development process into distinct AI persona-based phases
|
||||
2. Generating detailed artifacts at each phase
|
||||
3. Using a sequential workflow to track progress
|
||||
4. Enabling AI to code the full application based on generated specifications
|
||||
## Custom Modes and Welcome Contributions
|
||||
|
||||
The method is tool agnostic with a workflow built into the role-prompts, making it adaptable to any agentic coding toolset, IDE, or platform.
|
||||
The BMAD community's input is invaluable! We encourage you to contribute by submitting Pull Requests for V3 custom agent modes, new templates, or checklist enhancements tailored for the `BETA-V3` system.
|
||||
|
||||
Join the [Community Discussion Forum](https://github.com/bmadcode/BMAD-METHOD/discussions) to help contribute and evolve these ideas.
|
||||
The Custom Agents in `BETA-V3` follow best practices for LLM prompting (e.g., clear roles, instructions, and context) ensuring they work effectively across various AI platforms.
|
||||
|
||||
### Video Tutorials
|
||||
## BETA-V3 Agent Overview
|
||||
|
||||
- The legacy workflow is explained in [Part 1 and 2 on the BMad Code YouTube channel](https://youtu.be/JbhiLUY_V2U)
|
||||
- A new tutorial for the V2 workflow will be coming soon - with a full end to end project build!
|
||||
The `BETA-V3` system features a refined team of specialized AI agents (refer to `BETA-V3/web-agent-modes/` or `BETA-V3/ide-agent-modes/` for full details):
|
||||
|
||||
## Coming Soon(ish)
|
||||
### 0. BMAD Method Advisor (`0-bmad.md`)
|
||||
|
||||
- A fully output of a simple and advanced project artifact files of executing the agents to build all the artifacts for a project build with prompt examples that lead to the output from the agents.
|
||||
- Exploration into leveraging MCP.
|
||||
The primary guide to understanding and navigating the BMAD Method V3, explaining agent roles, workflows, tasks, and best practices.
|
||||
|
||||
## Workflow Visual Diagram
|
||||
### 1. Analyst (`1-analyst.md`)
|
||||
|
||||
[View Diagram](./workflow-diagram.md)
|
||||
Starting point for new/unclear ideas.
|
||||
**Phases:** Brainstorming, Deep Research (broad market/feasibility), Project Briefing.
|
||||
**Key Output:** **Project Brief**.
|
||||
|
||||
## Custom Agent Overview
|
||||
### 2. Product Manager (PM) (`2-pm.md`)
|
||||
|
||||
### Analyst (Business Analyst (BA), Research Assistant (RA), Brainstorming Coach)
|
||||
Transforms ideas/briefs into detailed product plans.
|
||||
**Phases:** Deep Research (focused strategy validation), PRD Generation (Epics, Stories, tech assumptions using `prd-tmpl.txt` & `pm-checklist.txt`), Product Advisor.
|
||||
**Key Output:** **Product Requirements Document (PRD)**.
|
||||
|
||||
The Analyst agent is a versatile entry point into the BMad Method, operating in three distinct modes to help transform initial ideas or vague concepts into well-defined project briefs through creative ideation techniques, market analysis, or structured requirement gathering. This agent is ideal for users who need help refining their vision before moving to detailed product definition.
|
||||
### 3. Architect (`3-architect.md`)
|
||||
|
||||
#### Brainstorming Coach Mode
|
||||
Defines the overall technical blueprint.
|
||||
**Phases:** Deep Research Prompt Generation, Architecture Creation (using `architecture-tmpl.txt` & `architect-checklist.txt`), Master Architect Advisory.
|
||||
**Key Output:** **Technical Architecture Document**.
|
||||
|
||||
This mode uses proven brainstorming techniques like SCAMPER and "What if" scenarios to expand possibilities. The agent guides users through structured ideation frameworks, encourages divergent thinking, and helps challenge assumptions that might be limiting creativity.
|
||||
### 4. Design Architect (`4-design-architect.md`)
|
||||
|
||||
#### Deep Research Mode
|
||||
Specializes in UI/UX and frontend technical strategy.
|
||||
**Modes:** UI/UX Specification (using `front-end-spec-tmpl.txt`), Frontend Architecture (using `front-end-architecture-tmpl.txt` & `frontend-architecture-checklist.txt`), AI Frontend Generation Prompt.
|
||||
**Key Outputs:** **UI/UX Spec**, **Frontend Architecture Doc**.
|
||||
|
||||
This mode generates comprehensive research prompts to explore market needs, competitors, and target users. It focuses on executing deep research into market conditions, industry trends, competitive landscape, and user needs to inform the project direction.
|
||||
### 5. Technical POSM (`5-posm.md`)
|
||||
|
||||
#### Project Briefing Mode
|
||||
Ensures documentation quality and prepares for development.
|
||||
**Phases:** Master Checklist (using `po-master-checklist.txt`), Librarian (creates `docs/` structure & `index.md`), Story Creator (using `story-tmpl.txt`).
|
||||
**Key Outputs:** **Checklist Report**, Organized granular documentation, **Story Files**.
|
||||
|
||||
This mode collaboratively builds a structured brief document with a dedicated PM Agent Handoff Prompt section that provides strategic guidance for the next phase. It leverages research findings and user input to create a well-defined project brief that serves as the foundation for product development.
|
||||
### 6. Release Train Engineer (RTE-Agent) (`6-rte.md`)
|
||||
|
||||
With the final V2 release, this mode is like magic - working with you as a partner coach and brainstorming master - helping you find the idea in that nugget of a vision - especially when using in Gemini 2.5 pro thinking. As a bonus, you can even take your output eventual project brief and use it as a basis for another round of brainstorming to further refine before handing to the PM (this was a happy accident I discovered that worked out really well).
|
||||
Manages significant mid-project changes and pivots.
|
||||
**Process:** Uses `rte-checklist.md` for impact analysis, evaluates paths, drafts artifact updates.
|
||||
**Key Output:** **Sprint Change Proposal** (with analysis and proposed edits).
|
||||
|
||||
### Product Manager (PM)
|
||||
### 7. Developer Agents (e.g., `dev-agent.md`)
|
||||
|
||||
The Product Manager agent excels at transforming high-level project briefs or initial ideas into comprehensive product specifications and actionable development plans. As a scope refinement specialist, the PM actively challenges assumptions about what features are truly necessary for the MVP, seeking opportunities to reduce complexity while ensuring perfect alignment with core business goals.
|
||||
(Specific prompts in `BETA-V3/ide-agent-modes/`)
|
||||
Implement features based on stories, adhering to architecture and standards (`coding-standards.md`, `project-structure.md`, etc.).
|
||||
|
||||
#### Mode 1: Initial Product Definition
|
||||
## IDE Tasks (V3 Exclusive!)
|
||||
|
||||
In this mode, the PM creates the core product definition documents for the MVP from scratch. The agent produces three key artifacts: a detailed Product Requirements Document (PRD) outlining goals, functional and non-functional requirements; a set of epic definitions that break down the work into independently deployable chunks; and an Initial Architect Prompt that captures critical technical decisions. Throughout the process, the PM engages in multiple rounds of scope refinement—first during initial scoping discussions, then after drafting the PRD, and finally after creating epics—always framing conversations around time, cost, and quality tradeoffs. The PM also identifies deployment considerations and testing requirements, ensuring each epic builds logically on previous ones with Epic 1 containing all necessary infrastructure setup.
|
||||
Located in `BETA-V3/tasks/`, these self-contained instruction sets allow IDE agents to perform specific one-off jobs on demand, reducing the need for overly complex agent modes.
|
||||
|
||||
This mode is now like magic when operating within Google Gemini 2.5 Pro thinking - it stops confirms and explains every choice and description so clearly it makes the process painless and will guide you every step of the way. Please enjoy the final V2 release!
|
||||
**Purpose:**
|
||||
|
||||
#### Mode 2: Product Refinement & Advisory
|
||||
- **Reduce Agent Bloat:** Avoid adding rarely used instructions to primary agents.
|
||||
- **On-Demand Functionality:** Instruct any capable IDE agent to execute a task by providing the task file content.
|
||||
- **Versatility:** Handles specific functions like running checklists, creating stories, sharding documents, indexing libraries, etc.
|
||||
|
||||
In this mode, which activates when a PRD already exists and is approved, the PM serves as an ongoing product advisor to provide clarification on existing requirements, facilitate modifications as the product evolves, assess the impact of proposed changes, manage scope adjustments, and maintain consistent, up-to-date product documentation throughout the development process.
|
||||
Think of tasks as specialized mini-agents callable by your main IDE agents.
|
||||
|
||||
### Architect
|
||||
## BETA-V3 Step-by-Step Process (Typical Flow)
|
||||
|
||||
The Architect agent is an expert Solution/Software Architect that operates in three distinct modes to support technical design throughout the product development lifecycle. With deep knowledge across cloud platforms, architectures, databases, and programming languages, the Architect translates requirements into robust, scalable technical designs optimized for AI agent implementation.
|
||||
1. **Analyst (`1-analyst.md`):** (Optional) -> **Project Brief**.
|
||||
2. **PM (`2-pm.md`):** Project Brief/idea -> **PRD** (Epics, Stories).
|
||||
3. **Architect (`3-architect.md`):** PRD -> **System Architecture Document**.
|
||||
4. **Design Architect (`4-design-architect.md`):** (If UI) PRD, System Arch -> **UI/UX Spec**, **Frontend Architecture Doc**.
|
||||
5. **POSM (`5-posm.md`) - Master Checklist Phase:** Validates docs -> **Master Checklist Report**.
|
||||
6. _(User/Agents apply changes based on POSM report)_.
|
||||
7. **POSM (`5-posm.md`) - Librarian Phase:** Processes updated docs -> Granular `docs/` files & `index.md`.
|
||||
8. **POSM (`5-posm.md`) - Story Creator Phase:** -> **Developer Story Files**.
|
||||
9. **Developer Agents:** Implement stories.
|
||||
10. **(If major issue arises): RTE-Agent (`6-rte.md`):** -> **Sprint Change Proposal** (with proposed edits). Apply edits or handoff if replan needed.
|
||||
11. **Ongoing Advisory:** Architect & PM provide continuous support.
|
||||
|
||||
#### Mode 1: Deep Research Prompt Generation
|
||||
_This is a guideline; the method is iterative._
|
||||
|
||||
This mode creates comprehensive research prompts to investigate technology options, platforms, services, and implementation approaches before making architectural decisions. The Architect analyzes available project context, identifies research gaps, and structures detailed prompts that define clear objectives, outline specific questions, request comparative analysis, and establish evaluation frameworks for decision-making.
|
||||
## Tooling & Setup (BETA-V3)
|
||||
|
||||
**Gem Mode Bonus**: The GEM version includes an extensive example research prompt template for backend technology stack evaluation that demonstrates how to structure comprehensive technology investigations. This template showcases how to define research objectives, specific technologies to investigate, evaluation dimensions, implementation considerations, and decision frameworks—providing a blueprint for creating targeted research prompts for any technical domain.
|
||||
- **Templates:** `BETA-V3/templates/`
|
||||
- **Checklists:** `BETA-V3/checklists/`
|
||||
- **Web UI Agents:** `BETA-V3/web-agent-modes/` (Use with Gemini Gems/Custom GPTs. Attach relevant templates/checklists).
|
||||
- **IDE Agents:** `BETA-V3/ide-agent-modes/` (Optimized for IDE custom modes).
|
||||
- **Tasks:** `BETA-V3/tasks/` (For IDE usage).
|
||||
- **Instructions:** See [Setup Instructions](./BETA-V3/instruction.md) for details.
|
||||
|
||||
#### Mode 2: Architecture Creation
|
||||
## Historical Versions (V1 & V2)
|
||||
|
||||
In this mode, the Architect designs and documents the complete technical architecture based on the PRD, epics, and project brief. The agent makes definitive technology decisions (not open-ended options), explains the rationale behind key selections, and produces all necessary technical artifacts including detailed architecture documentation, tech stack specifications, project structure, coding standards, API references, data models, environment variables, and testing strategies—all optimized for implementation by AI agents.
|
||||
|
||||
This mode is now like magic when operating within Google Gemini 2.5 Pro thinking - it stops confirms and explains every choice and description so clearly it makes the process painless and will guide you every step of the way. Please enjoy the final V2 release!
|
||||
|
||||
#### Mode 3: Master Architect Advisory
|
||||
|
||||
This mode provides ongoing technical guidance throughout the project, explaining concepts, suggesting updates to artifacts, and managing technical direction changes. The Architect assesses change impacts across the project, recommends minimally disruptive approaches for course corrections, identifies technical debt, and ensures all significant decisions are properly documented. The agent uses clear Mermaid diagrams to visually represent system structure and interactions when beneficial for clarity.
|
||||
|
||||
### Product Owner (PO)
|
||||
|
||||
The Product Owner agent serves as the validation and quality assurance checkpoint for the entire MVP plan before development begins. Using a comprehensive validation checklist, the PO agent systematically reviews all project artifacts to ensure they are complete, well-structured, and properly aligned. The PO agent verifies proper project setup and initialization steps, validates infrastructure and deployment sequencing, confirms all external dependencies are properly addressed, delineates user versus agent responsibilities, ensures features are correctly sequenced with dependencies managed, validates that all MVP goals from the PRD are addressed in epics/stories, and checks that all technical requirements are satisfied. The agent also evaluates risk management strategies, documentation completeness, and verifies that post-MVP considerations are properly handled. This systematic validation process helps catch potential issues early, ensuring the development phase proceeds smoothly.
|
||||
|
||||
### Scrum Master (SM)
|
||||
|
||||
The Scrum Master agent serves as the technical bridge between approved plans and executable development tasks. As an expert Technical Scrum Master/Senior Engineer, this agent systematically identifies the next logical story to implement based on dependencies and prerequisites, extracting only the necessary technical context from reference documents to create self-contained story files. The SM operates in a process-driven workflow that includes checking prerequisite states, gathering relevant requirements and technical context, populating standardized story templates, validating story completeness against a checklist, and marking stories as ready for development. This agent flags missing or contradictory information as blockers, focuses on providing adequate context without over-specifying implementation details, and ensures each story contains specific testing requirements and acceptance criteria.
|
||||
|
||||
### PO-SM (Gem) Combined
|
||||
|
||||
The PO-SM Gem agent is a dual-mode specialist that operates in two distinct capacities:
|
||||
|
||||
#### PO Mode (Plan Validator)
|
||||
|
||||
In Product Owner mode, this agent conducts comprehensive validation of the complete MVP plan before development starts. The agent systematically works through a detailed checklist to verify foundational implementation logic, technical sequence viability, and PRD alignment. It evaluates proper initialization steps, infrastructure sequencing, user vs. agent action appropriateness, and external dependency management. The agent makes a definitive "Go/No-Go" decision, either approving the plan or providing specific, actionable feedback for addressing deficiencies.
|
||||
|
||||
The PO mode within the IDE (Agent folder) version is the main agent that generates a project root `docs/_index.ts`, or updates it if needed as more docs are created - a great V2 addition that will allow future agents a directory to discover all the great docs you produce for your repo, and link to from the main repo. This is the future of agent knowledge of how to work within your repo as it grows and future agents evolve.
|
||||
|
||||
#### SM Mode (Story Generator)
|
||||
|
||||
Once the plan is approved, the agent transitions to Scrum Master mode, where it identifies remaining stories, gathers technical context, and generates comprehensive story files following standard templates. In this mode, the agent extracts only story-specific information from reference documents, populates templates with appropriate details, and formats each story with clear section titles and boundaries. The agent can generate a complete report of all remaining stories organized in logical sequence based on dependencies.
|
||||
|
||||
### Dev Agent (Dev)
|
||||
|
||||
The Developer agent is an expert software developer implementing requirements from assigned story files. This agent focuses exclusively on story implementation while following project standards, working sequentially through tasks defined in the story file. The Dev agent adheres strictly to coding standards and project structure without needing these repeated in each story, implements tests according to project testing strategy, and reports progress by updating story status. The agent operates with focused autonomy, asking questions only when genuinely blocked by ambiguity, attempting to resolve issues using available documentation first. Upon completion of all tasks and verification that tests pass, the Dev agent marks the story for review and awaits feedback before deployment.
|
||||
|
||||
## Step-by-Step Process
|
||||
|
||||
### Phase 0: Ideation (Optional)
|
||||
|
||||
1. Start with the **Business Analyst (BA)** agent if your idea is vague
|
||||
2. The BA will help analyze market conditions and competitors
|
||||
3. Output is a **Project Brief** used as input for the Product Manager
|
||||
|
||||
If you are unsure, start by saying something like the following to brainstorm with the BA with this simple goal eliciting prompt:
|
||||
|
||||
- I have an idea for an app I want to brainstorm with you,
|
||||
- it can do (X)
|
||||
- so that (y)
|
||||
- for (Z) user(s)
|
||||
|
||||
**Example:** 'I have an idea for an app I want to brainstorm with you, it can **help small business owners automatically** generate professional social media content, so that they can **maintain consistent online presence without hiring expensive marketing agencies**, for **time-starved entrepreneurs** who know social media is important but don't have the skills or time to create quality content daily'
|
||||
|
||||
### Phase 1: Product Definition
|
||||
|
||||
1. The **Product Manager (PM)** agent takes the project brief or your idea
|
||||
2. PM creates a comprehensive Product Requirements Document (PRD) along with high level epic / story flow docs. (Separate files reduce overall context for future agents - this is in the V2+ version)
|
||||
3. Initial epic breakdowns are drafted
|
||||
|
||||
### Phase 2: Technical Design
|
||||
|
||||
1. The **Architect** agent reviews the PRD and creates an architecture document and in V2 granular artifacts that optimize for LLM context space of chosen future agents!
|
||||
2. Architect identifies technical dependencies and reference files
|
||||
3. Optional: Use Deep Research mode for more in-depth technical exploration
|
||||
|
||||
### Phase 3: Refinement and Validation
|
||||
|
||||
1. PM, Architect, and Scrum Master collaborate to refine the plan
|
||||
2. **Product Owner (PO)** validates scope, story sequence, and PRD alignment
|
||||
3. Final documents are approved and indexed
|
||||
|
||||
### Phase 4: Story Generation
|
||||
|
||||
1. **Technical Scrum Master** generates each story 1 at a time for the dev to complete, (OR in Gem/GPT mode it will do all remaining stories). The output story or stories are highly detailed stories with all technical details the agent will need to keep instructional context lean - not having to search all of the larger documents bloating its context with unnecessary information.
|
||||
|
||||
### Phase 5: Development
|
||||
|
||||
1. The **Developer Agent** works on stories one at a time
|
||||
2. Developer creates draft stories for review before implementation
|
||||
3. Code and tests are committed, and story files are updated
|
||||
|
||||
### Phase 6: Review and Acceptance
|
||||
|
||||
1. Code reviews by a new Dev Agent or Architect
|
||||
2. Functionality reviews by User/QA
|
||||
3. Story marked as Done when approved
|
||||
|
||||
### Phase 6.5: Refactor (Optional Step)
|
||||
|
||||
1. Architect or Dev Agent in a new Content, or the User, refactor as needed and ensure if refactor changes structure that source tree diagrams and future implementation documents are updated as needed.
|
||||
2. This is not required after most stories with properly following the phases before #5 producing a solid plan and architecture - but even the best plans can lead to the emergence of an idea for beautiful restructuring. Also, best laid plans can still lead to an agent doing less than ideal things that are better to correct.
|
||||
3. Remember, the main key with refactoring at this stage is ensure all was working first, the full app and new functionality has passing tests and linting, has been committed, and pushed to the remote branch. Only then would I take on a major (or even minor refactor) in most cases. If I am doing the refactor myself, I have more trust and might do it before pushing and calling the story done. But with the agent, always lock down your working changes so you have an escape hatch to revert to!
|
||||
|
||||
### Phase 7: Deployment
|
||||
|
||||
1. Developer Agent handles deployments
|
||||
2. Infrastructure as Code is used for deployment commands
|
||||
3. System is updated with the new functionality
|
||||
|
||||
## Template Dependencies
|
||||
|
||||
**Important:** The agents (not gems) in this system rely on template files located in the `CURRENT-V2/docs/templates` folder. These templates should remain named as they are for proper functionality and put in your projects docs/templates folder, including:
|
||||
|
||||
- `architecture.md`
|
||||
- `story-template.md`
|
||||
- `prd.md`
|
||||
- `project-brief.md`
|
||||
- etc... (all of the template files)
|
||||
|
||||
## Custom GEMs and GPTs (Highly Recommended)
|
||||
|
||||
**Using Agents with Web-Based AI Interfaces (Highly recommended, save lots of money, larger context windows, deep research is a game changer)**
|
||||
|
||||
The [gems folder](./CURRENT-V2/gems-and-gpts/) contains agent instructions embedded with optimized web use instructions - streamlined for usage within the [Gemini Gems](https://gemini.google.com/gems/create), or [OpenAIs custom GPT's](https://chatgpt.com/gpts/editor). With both custom GPTs and Gemini Gems, you will attach the templates now instead of embedding them (as was the case with V1 of this system, that was not as easy to modify). This way, as you modify templates from the templates folder, if you want to change it in the web version just save it as a .txt extension and attach to the custom GEM or GPT.
|
||||
|
||||
[Detailed set up and usage instructions](./CURRENT-V2/gems-and-gpts/instruction.md) are available in the folder also.
|
||||
|
||||
## IDE Integration
|
||||
|
||||
The method works with any IDE or AI assistant with these approaches:
|
||||
|
||||
- **Custom Modes**: For IDEs that support custom modes (Cursor, RooCode)
|
||||
- **Custom Gems**: For Gemini, create a Custom Gem for each agent
|
||||
- **Direct Prompting**: For any AI assistant, use the agent prompts directly
|
||||
_Brief summary of V1/V2 can remain here or be moved to a separate historical doc if desired._
|
||||
_(Original V2 sections like "What's New in V2?", "Full Demonstration Walkthrough" (referencing V2 demo), "No Rules Required!", "IDE Agent Integration" (referencing V2 paths), etc. would be reviewed, summarized, or removed to avoid confusion with V3)._
|
||||
|
||||
## License
|
||||
|
||||
@@ -270,4 +156,4 @@ The method works with any IDE or AI assistant with these approaches:
|
||||
|
||||
## Contributing
|
||||
|
||||
Interested in improving the BMad Method? See our [contributing guidelines](CONTRIBUTING.md).
|
||||
Interested in improving the BMAD Method BETA-V3? See our [contributing guidelines](CONTRIBUTING.md).
|
||||
|
||||
147
readmedraft.md
Normal file
147
readmedraft.md
Normal file
@@ -0,0 +1,147 @@
|
||||
# The BMAD-Method (Breakthrough Method of Agile (ai-driven) Development)
|
||||
|
||||
**Welcome to the BMAD Method! This repository documents the V2 methodology (stable) and introduces the BETA-V3 (experimental).**
|
||||
|
||||
- **Stable Version (V2):** Resources located in `CURRENT-V2/`. This is the recommended version for general use.
|
||||
- **Experimental Beta (V3):** Resources located in `BETA-V3/`. Contains new features and agents currently under testing.
|
||||
|
||||
Quick Links:
|
||||
|
||||
- [V2 Setup Instructions](./CURRENT-V2/instructions.md) (For IDEs/Gems/GPTs)
|
||||
- [BETA-V3 Setup Instructions](./BETA-V3/instruction.md) (For IDEs/Web/Tasks)
|
||||
- [Community Discussion Forum](https://github.com/bmadcode/BMAD-METHOD/discussions)
|
||||
- [Contributing Guidelines](CONTRIBUTING.md)
|
||||
- [License](./LICENSE)
|
||||
|
||||
_Legacy V1 has been archived._
|
||||
|
||||
## What is the BMad Method?
|
||||
|
||||
The BMad Method is a revolutionary approach that elevates "vibe coding" to **"Vibe CEOing."** Unlike the spontaneity of pure vibe coding for quick prototypes, this method provides a structured yet flexible framework to plan, execute, and manage software projects using a team of specialized AI agents. It helps you build faster, cheaper, and more effectively by leveraging AI-driven processes throughout the entire product development lifecycle.
|
||||
|
||||
The **V2 release (in `CURRENT-V2/`)** established a robust workflow with distinct agent roles, standardized templates, and comprehensive checklists. **BETA-V3 (in `BETA-V3/`)** builds upon this foundation, refining processes and introducing new capabilities currently under evaluation.
|
||||
|
||||
The comprehensive, step-by-step approach transforms a product idea into a fully implemented application by:
|
||||
|
||||
1. Structuring the development process into distinct AI persona-based phases.
|
||||
2. Generating detailed, high-quality artifacts at each phase.
|
||||
3. Using a sequential workflow with clear handoffs.
|
||||
4. Enabling AI to code the application based on well-defined specifications.
|
||||
|
||||
## Guiding Principles
|
||||
|
||||
These principles apply across versions, with V3 enhancing certain aspects:
|
||||
|
||||
- **Environment Recommendations:** Generally, initial planning phases (Analyst, PM, early Architect work) are often well-suited for Web UIs (Gems/Custom GPTs) due to their conversational nature and cost-effectiveness. Technical implementation, file management (like V3's POSM Librarian), specialized tasks (like V3's RTE-Agent or IDE Tasks), and development are typically better suited for an IDE environment with custom agent support.
|
||||
- **No Rules Required (Flexibility):** Agents primarily reference project documents (PRDs, architecture docs, coding standards, etc.) rather than relying heavily on proprietary AI platform rules.
|
||||
- **Iterative & Collaborative:** Emphasizes a step-by-step, interactive process where agents collaborate with the user, pausing for input and validation at key decision points.
|
||||
- **Documentation Focus (Enhanced in V3):** V3 places a stronger emphasis on creating a granular, indexed `docs/` structure to improve context for AI agents and human developers.
|
||||
|
||||
## Agent Overview (V2 Core Agents)
|
||||
|
||||
The `CURRENT-V2/` system features a team of specialized AI agents. See `CURRENT-V2/agents/` for IDE modes and `CURRENT-V2/gems-and-gpts/` for Web UI versions.
|
||||
|
||||
### Analyst (Business Analyst, Research Assistant, Brainstorming Coach)
|
||||
|
||||
Starting point for new/unclear ideas. Transforms concepts into a structured **Project Brief**.
|
||||
|
||||
### Product Manager (PM)
|
||||
|
||||
Transforms ideas/briefs into detailed product plans. Creates the **Product Requirements Document (PRD)** with Epics and User Stories. V2 includes checklists for validation.
|
||||
|
||||
### Architect
|
||||
|
||||
Defines the overall technical blueprint based on the PRD. Creates the **Technical Architecture Document**.
|
||||
|
||||
### Product Owner (PO)
|
||||
|
||||
Validates the MVP plan (PRD, Architecture, Epics) against a checklist before development begins.
|
||||
|
||||
### Scrum Master (SM)
|
||||
|
||||
Technical bridge generating detailed, executable **Story Files** from approved plans, one at a time, ready for development.
|
||||
|
||||
### Developer Agent (Dev)
|
||||
|
||||
Implements features based on assigned Story Files, adhering to project architecture and standards.
|
||||
|
||||
## New/Enhanced Agents in BETA-V3
|
||||
|
||||
BETA-V3 (in `BETA-V3/`) introduces new roles and enhances existing ones:
|
||||
|
||||
### 0. BMAD Method Advisor (`0-bmad.md`)
|
||||
|
||||
A dedicated guide explaining V3 concepts, including the new agents, IDE Tasks, and workflow nuances.
|
||||
|
||||
### 4. Design Architect (`4-design-architect.md`)
|
||||
|
||||
(Engage if project has a UI)
|
||||
Specializes in UI/UX (**UI/UX Spec**) and frontend technical strategy (**Frontend Architecture Doc**).
|
||||
|
||||
### 5. Technical POSM (`5-posm.md`)
|
||||
|
||||
Replaces the separate V2 PO and SM with enhanced capabilities:
|
||||
**Phases:**
|
||||
|
||||
1. **Master Checklist:** Validates all planning/design docs.
|
||||
2. **Librarian:** Creates granular `docs/` structure & `index.md` (IDE Recommended).
|
||||
3. **Story Creator:** Generates developer-ready **Story Files**.
|
||||
|
||||
### 6. Release Train Engineer (RTE-Agent) (`6-rte.md`)
|
||||
|
||||
Manages significant mid-project changes/pivots. Uses `rte-checklist.md` for analysis and drafts artifact updates, outputting a **Sprint Change Proposal**.
|
||||
|
||||
_(Note: The V3 PM and Architect agents also have refined phases and use updated V3 templates/checklists.)_
|
||||
|
||||
## Step-by-Step Process (V2 Typical Flow)
|
||||
|
||||
1. **Analyst:** (Optional) -> **Project Brief**.
|
||||
2. **PM:** Project Brief/idea -> **PRD** (Epics, Stories).
|
||||
3. **Architect:** PRD -> **System Architecture Document**.
|
||||
4. **PO:** Validates PRD, Architecture, Epics -> **Validation Report/Approval**.
|
||||
5. **SM:** Approved plans -> Generates **Story File** (one at a time).
|
||||
6. **Developer Agent:** Implements approved story.
|
||||
7. Repeat 5 & 6 until MVP complete.
|
||||
8. **Ongoing Advisory:** Architect & PM provide support.
|
||||
|
||||
## BETA-V3 Process Modifications
|
||||
|
||||
BETA-V3 refines the flow, particularly after initial planning:
|
||||
|
||||
- The **Design Architect** is inserted after the Architect if a UI is required.
|
||||
- The **POSM** replaces the PO and SM:
|
||||
- After planning docs are ready (PRD, Arch, Design Arch docs), **POSM (Master Checklist Phase)** validates everything.
|
||||
- After validation/updates, **POSM (Librarian Phase)** organizes the `docs/` structure.
|
||||
- Then, **POSM (Story Creator Phase)** can (but not recommended from the ide) generates stories one by one for for a full epic for the stories folder and dev agent pick up.
|
||||
- The **RTE-Agent** can be engaged _at any point after story development begins_ if a major issue or pivot occurs - the RTE (Release Train Engineer) can help figure out what needs to change and how to proceed, and help update all artifacts - best run from the ide since we are mid project.
|
||||
|
||||
(Refer to the `BETA-V3` agent definitions for detailed flows).
|
||||
|
||||
## IDE Tasks (BETA-V3 Feature)
|
||||
|
||||
Located in `BETA-V3/tasks/`, these self-contained instruction sets allow IDE agents (in V3 mode) to perform specific one-off jobs on demand (e.g., run checklist, create next story, shard docs), reducing the need for complex agent modes.
|
||||
|
||||
## Tooling & Setup
|
||||
|
||||
### V2 (Stable - in `CURRENT-V2/`)
|
||||
|
||||
- **Templates:** `CURRENT-V2/docs/templates/`
|
||||
- **Checklists:** `CURRENT-V2/docs/checklists/`
|
||||
- **Web UI Agents (Gems/GPTs):** `CURRENT-V2/gems-and-gpts/`
|
||||
- **IDE Agents:** `CURRENT-V2/agents/`
|
||||
- **Setup Instructions:** `CURRENT-V2/instructions.md`
|
||||
|
||||
### BETA-V3 (Experimental - in `BETA-V3/`)
|
||||
|
||||
- **Templates:** `BETA-V3/templates/`
|
||||
- **Checklists:** `BETA-V3/checklists/`
|
||||
- **Web UI Agents:** `BETA-V3/web-agent-modes/`
|
||||
- **IDE Agents:** `BETA-V3/ide-agent-modes/`
|
||||
- **Tasks:** `BETA-V3/tasks/`
|
||||
- **Setup Instructions:** `BETA-V3/instruction.md`
|
||||
|
||||
## Demonstration Walkthrough
|
||||
|
||||
The effectiveness of the BMAD Method's interactive approach is demonstrated in the [V2 Video Walkthrough](https://youtu.be/p0barbrWgQA?si=PD1RyWNVDpdF3QJf). The [`V2-FULL-DEMO-WALKTHROUGH`](./V2-FULL-DEMO-WALKTHROUGH/demo.md) folder contains the full transcripts and artifacts.
|
||||
|
||||
A BETA-V3 specific walkthrough is planned along with multiple sample projects.
|
||||
Reference in New Issue
Block a user