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

140
BETA-V3/draft-readme.md Normal file
View File

@@ -0,0 +1,140 @@
# The BMAD-Method (Breakthrough Method of Agile (ai-driven) Development) - BETA-V3
## 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 (this document!) 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)

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.