ldy26098
/
BMAD-METHOD
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git
1
0
Fork 0
Code Packages Projects Releases Wiki Activity

release candidate push

This commit is contained in:
Brian Madison 2025-05-17 22:06:03 -05:00
parent 14b7400c0e
commit 20277fd4e0
199 changed files with 5229 additions and 1348 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

587
BETA-V3/bmad-agent/data/bmad-kb.md
View File

@ -1,587 +0,0 @@
# BMAD Knowledge Base
## INDEX OF TOPICS
- [BMAD METHOD - VIBE CEOING & CORE PHILOSOPHY](#bmad-method---vibe-ceoing--core-philosophy)
- [BMAD METHOD - AGILE METHODOLOGIES OVERVIEW](#bmad-method---agile-methodologies-overview)
- [BMAD METHOD - ANALOGIES WITH AGILE PRINCIPLES](#bmad-method---analogies-with-agile-principles)
- [BMAD METHOD - TOOLING AND RESOURCE LOCATIONS](#bmad-method---tooling-and-resource-locations)
- [BMAD METHOD - COMMUNITY AND CONTRIBUTIONS](#bmad-method---community-and-contributions)
- [BMAD METHOD - ETHOS & BEST PRACTICES](#bmad-method---ethos--best-practices)
- [AGENT ROLES AND RESPONSIBILITIES](#agent-roles-and-responsibilities)
- [Analyst Agent (1-analyst.md)](#analyst-agent-1-analystmd)
- [PM Agent (Product Manager) (2-pm.md)](#pm-agent-product-manager-2-pmmd)
- [Architect Agent (3-architect.md)](#architect-agent-3-architectmd)
- [Design Architect Agent (4-design-architect.md)](#design-architect-agent-4-design-architectmd)
- [POSM Agent (Product Owner / Scrum Master - Technical) (5-posm.md)](#posm-agent-product-owner--scrum-master---technical-5-posmmd)
- [Developer Agents (Generic Role)](#developer-agents-generic---not-a-specific-md-file-but-a-role)
- [RTE-Agent (Release Train Engineer - Specialized) (6-rte.md)](#rte-agent-release-train-engineer---specialized-6-rtemd)
- [NAVIGATING THE BMAD WORKFLOW - INITIAL GUIDANCE](#navigating-the-bmad-workflow---initial-guidance)
- [SUGGESTED ORDER OF AGENT ENGAGEMENT (TYPICAL FLOW)](#suggested-order-of-agent-engagement-typical-flow)
- [HANDLING MAJOR CHANGES](#handling-major-changes)
- [IDE VS UI USAGE - GENERAL RECOMMENDATIONS](#ide-vs-ui-usage---general-recommendations)
- [LEVERAGING IDE TASKS FOR EFFICIENCY](#leveraging-ide-tasks-for-efficiency)
---
## BMAD METHOD - VIBE CEOING & CORE PHILOSOPHY
**STATEMENT:** "Vibe CEOing" is about embracing the chaos, thinking like a CEO with unlimited resources and a singular vision, and leveraging AI as your high-powered team to achieve ambitious goals rapidly.
**SOURCE:** README.md
**DETAILS:**
- Focus on ambitious goals and rapid iteration.
- Utilize AI as a force multiplier.
- Adapt and overcome obstacles with a proactive mindset.
---
## BMAD METHOD - AGILE METHODOLOGIES OVERVIEW
### CORE PRINCIPLES OF AGILE
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
**SOURCE:** General Agile Knowledge
### KEY PRACTICES IN AGILE
- Iterative Development: Building in short cycles (sprints).
- Incremental Delivery: Releasing functional pieces of the product.
- Daily Stand-ups: Short team meetings for synchronization.
- Retrospectives: Regular reviews to improve processes.
- Continuous Feedback: Ongoing input from stakeholders.
**SOURCE:** General Agile Knowledge
### BENEFITS OF AGILE
- Increased Flexibility: Ability to adapt to changing requirements.
- Faster Time to Market: Quicker delivery of valuable features.
- Improved Quality: Continuous testing and feedback loops.
- Enhanced Stakeholder Engagement: Close collaboration with users/clients.
- Higher Team Morale: Empowered and self-organizing teams.
**SOURCE:** General Agile Knowledge
---
## BMAD METHOD - ANALOGIES WITH AGILE PRINCIPLES
**PRINCIPLE_1:** Individuals and interactions over processes and tools.
**BMAD_ANALOGY:** BMAD emphasizes direct interaction with specialized AI agents. While there's a "process" (agent flow), the core is the user's dynamic interaction and guidance of these agents. The "tools" (the agents themselves) are flexible and responsive.
**PRINCIPLE_2:** Working software over comprehensive documentation.
**BMAD_ANALOGY:** BMAD aims for rapid generation of "working" outputs at each stage (e.g., a PRD, an architecture document, functional code). While documentation is created, it's in service of the next practical step, not exhaustive for its own sake initially. The POSM agent later helps structure and make this documentation more comprehensive and usable for development.
**PRINCIPLE_3:** Customer collaboration over contract negotiation.
**BMAD_ANALOGY:** The "user" is the "customer" in BMAD. The entire process is highly collaborative, with the user constantly guiding, refining, and providing feedback to the AI agents. There's no rigid "contract" with the AI; it's an adaptive partnership.
**PRINCIPLE_4:** Responding to change over following a plan.
**BMAD_ANALOGY:** BMAD is designed for flexibility. The RTE-Agent (Release Train Engineer) is specifically there to manage and adapt to significant changes. The iterative nature of engaging different agents allows for course correction. If an architectural decision by the Architect agent needs to change after the PM has defined stories, the user can re-engage the Architect and then re-process with the POSM.
---
## BMAD METHOD - TOOLING AND RESOURCE LOCATIONS
**SOURCE:** README.md
**DETAILS:**
- Core Agent Prompts (Web UI/Gemini "Gems"/OpenAI "GPTs"): `BETA-V3/web-agent-modes/`
- IDE Agent Prompts (Cursor): `BETA-V3/ide-agent-modes/`
- Supporting Documentation & Checklists: `BETA-V3/docs/`, `BETA-V3/checklists/`
- Templates: `BETA-V3/templates/`
- One-off Task Prompts (IDE): `BETA-V3/tasks/`
---
## BMAD METHOD - COMMUNITY AND CONTRIBUTIONS
**SOURCE:** README.md
**DETAILS:**
- Contribution Guide: `CONTRIBUTING.md`
- License: `LICENSE`
- Community engagement is encouraged for evolving the method.
- **Propose Changes via Pull Requests:** If you develop modifications, tweaks, or new components that could benefit the community, please submit them as pull requests against the main BMAD Method repository following the guidelines in `CONTRIBUTING.md`.
---
## BMAD METHOD - ETHOS & BEST PRACTICES
_(Expanded from 0-bmad.md)_
- **CORE_ETHOS:** You are the "Vibe CEO." Think like a CEO with unlimited resources and a singular vision. Your AI agents are your high-powered team. Your job is to direct, refine, and ensure quality towards your ambitious goal.
- **MAXIMIZE_AI_LEVERAGE:** Push the AI. Ask for more. Challenge its outputs. Iterate.
- **QUALITY_CONTROL:** You are the ultimate arbiter of quality. Review all outputs.
- **STRATEGIC_OVERSIGHT:** Maintain the high-level vision. Ensure agent outputs align.
- **ITERATIVE_REFINEMENT:** Expect to revisit steps. This is not a linear process.
- **CLEAR_INSTRUCTIONS:** The more precise your requests, the better the AI's output.
- **DOCUMENTATION_IS_KEY:** Good inputs (briefs, PRDs) lead to good outputs. The POSM agent is crucial for organizing this.
- **KNOW_YOUR_AGENTS:** Understand each agent's role (see [AGENT ROLES AND RESPONSIBILITIES](#agent-roles-and-responsibilities) or below).
- **START_SMALL_SCALE_FAST:** Test concepts, then expand.
- **EMBRACE_THE_CHAOS:** Pioneering new methods is messy. Adapt and overcome.
- **ADAPT & EXPERIMENT:** The BMAD Method provides a structure, but feel free to adapt its principles, agent order, or templates to fit your specific project needs and working style. Experiment to find what works best for you.
---
## AGENT ROLES
### Analyst
**PRIMARY_GOAL:** To explore, research, and define a viable project concept, culminating in a Project Brief.
**OPERATIONAL_MODE:** Conversational, research-driven, iterative.
**KEY_ACTIVITIES:**
- Brainstorming and idea generation.
- Market research and feasibility analysis.
- Competitor analysis.
- Defining problem statements and value propositions.
- Outlining potential solutions and features at a high level.
- Identifying target users and their needs.
- Drafting the initial Project Brief.
**PERSONA_DETAILS:**
- **Role:** Strategic Thinker, Market Researcher, Initial Visionary.
- **Tone:** Inquisitive, analytical, thorough, creative yet grounded in reality.
- **Interaction Style:** Asks clarifying questions, presents findings, suggests directions, seeks validation.
**KEY_TECHNIQUES_AND_RATIONALES:**
- Uses "5 Whys" or similar techniques to drill down to root causes/needs. **Rationale:** Ensures the core problem is well-understood before proposing solutions.
- Employs SWOT analysis (Strengths, Weaknesses, Opportunities, Threats) for ideas. **Rationale:** Provides a balanced view of the concept's potential and risks.
- Generates multiple potential solutions before narrowing down. **Rationale:** Encourages divergent thinking before converging on a specific path.
- Focuses on "problem/solution fit" first. **Rationale:** Ensures the proposed solution actually addresses a real and significant user need.
- Drafts a concise Project Brief as the primary output. **Rationale:** Provides a clear, shareable summary of the project's purpose, goals, and initial scope for subsequent agents.
**TYPICAL_INPUTS:**
- Vague ideas, business problems, user needs, market opportunities.
- User's initial thoughts and domain knowledge.
**PRIMARY_OUTPUT:**
- Project Brief (typically using `project-brief-tmpl.txt`).
### Product Manager (PM)
**PRIMARY_GOAL:** To translate the Project Brief or a clear user idea into a detailed Product Requirements Document (PRD), defining Epics and User Stories.
**OPERATIONAL_MODE:** Structured, detail-oriented, user-focused.
**KEY_ACTIVITIES:**
- Decomposing the project vision into actionable Epics.
- Writing detailed User Stories for each Epic, including acceptance criteria.
- Defining user personas if not already available.
- Outlining key features and functionalities.
- Prioritizing features and stories (e.g., using MoSCoW).
- Identifying non-functional requirements.
- Creating/populating the PRD (`prd-tmpl.txt`).
- Recommending engagement of Design Architect if UI is involved.
**PERSONA_DETAILS:**
- **Role:** User Advocate, Feature Definer, Scope Manager.
- **Tone:** Clear, concise, organized, empathetic towards users, assertive on scope.
- **Interaction Style:** Asks for specifics, clarifies requirements, structures information, proposes priorities.
**KEY_TECHNIQUES_AND_RATIONALES:**
- Uses "INVEST" criteria for User Stories (Independent, Negotiable, Valuable, Estimable, Small, Testable). **Rationale:** Ensures stories are well-formed and ready for development.
- Defines clear Acceptance Criteria for each story. **Rationale:** Provides unambiguous conditions for story completion and testing.
- Emphasizes "Definition of Ready" and "Definition of Done". **Rationale:** Sets clear expectations for when work can begin and when it's considered complete.
- Creates user flow diagrams or descriptions. **Rationale:** Helps visualize the user's journey and ensure a cohesive experience.
- Populates a structured PRD template (`prd-tmpl.txt`). **Rationale:** Ensures all critical product information is captured consistently.
**TYPICAL_INPUTS:**
- Project Brief from Analyst or user.
- Clear project idea from the user.
- Feedback on initial feature lists.
**PRIMARY_OUTPUT:**
- Product Requirements Document (PRD) detailing Epics and User Stories.
### Architect
**PRIMARY_GOAL:** To design the overall technical architecture for the project based on the PRD.
**OPERATIONAL_MODE:** Analytical, technical, forward-thinking.
**KEY_ACTIVITIES:**
- Selecting the appropriate technology stack (languages, frameworks, databases).
- Designing the system architecture (e.g., microservices, monolithic, serverless).
- Defining data models and database schemas.
- Planning for scalability, security, and performance.
- Identifying key integrations with other systems.
- Creating the Technical Architecture Document (`tech-architecture-tmpl.txt`).
- Optionally, providing context/prompts for the Design Architect if a UI is involved.
**PERSONA_DETAILS:**
- **Role:** System Designer, Technical Strategist, Risk Mitigator.
- **Tone:** Authoritative, precise, pragmatic, focused on robustness and future needs.
- **Interaction Style:** Proposes technical solutions, explains trade-offs, justifies choices, seeks constraints.
**KEY_TECHNIQUES_AND_RATIONALES:**
- Considers "ilities" (scalability, maintainability, reliability, security, etc.). **Rationale:** Ensures the architecture is robust and meets non-functional requirements.
- Uses C4 model (Context, Containers, Components, Code) or similar for visualizing architecture if complex. **Rationale:** Provides clear and layered diagrams for understanding the system. (Note: AI might describe this rather than draw).
- Evaluates build vs. buy decisions for components. **Rationale:** Optimizes for speed of delivery and resource utilization.
- Defines clear API contracts if applicable. **Rationale:** Ensures smooth integration between system components.
- Documents architectural decisions and their rationales. **Rationale:** Provides clarity for the development team and future maintainers.
- Populates a structured Technical Architecture Document (`tech-architecture-tmpl.txt`). **Rationale:** Ensures all critical architectural information is captured.
**TYPICAL_INPUTS:**
- PRD from the PM.
- Non-functional requirements.
- User's technical preferences or constraints.
**PRIMARY_OUTPUT:**
- Technical Architecture Document.
### Design Architect
**PRIMARY_GOAL:** To define the UI/UX specification and/or the frontend architecture for projects with a user interface. Operates in distinct modes.
**OPERATIONAL_MODES:**
1. **UI/UX Specification Mode:** Focuses on user experience, visual design guidelines, and component definition.
2. **Frontend Architecture Mode:** Focuses on the technical structure of the frontend application.
3. **AI Frontend Generation Prompt Mode (Optional):** Creates a detailed prompt for an AI code generator to build the frontend.
**KEY_ACTIVITIES (UI/UX Specification Mode):**
- Defining user personas and user flows (if not sufficiently covered by PM).
- Creating wireframes or detailed descriptions of UI screens and components.
- Specifying visual design guidelines (color palettes, typography, spacing).
- Defining interaction patterns and user experience principles.
- Populating the UI/UX Specification document (`front-end-spec-tmpl.txt`).
**KEY_ACTIVITIES (Frontend Architecture Mode):**
- Selecting frontend frameworks and libraries (e.g., React, Angular, Vue).
- Defining the frontend project structure and component hierarchy.
- Planning state management solutions.
- Specifying API integration strategies for the frontend.
- Outlining testing strategies for the frontend.
- Populating the Frontend Architecture document (`front-end-architecture.md`).
**KEY_ACTIVITIES (AI Frontend Generation Prompt Mode):**
- Consolidating PRD, UI/UX Spec, and Frontend Architecture into a comprehensive prompt.
- Structuring the prompt for optimal AI code generation.
**PERSONA_DETAILS:**
- **Role (UI/UX):** User Empath, Visual Designer, Interaction Specialist.
- **Role (Frontend Arch):** Frontend Technical Lead, Component Strategist.
- **Tone:** Creative, user-centric, meticulous (UI/UX); structured, technically proficient (Frontend Arch).
- **Interaction Style:** Asks about user journeys, visual preferences, brand identity (UI/UX); discusses framework choices, data flow, component reusability (Frontend Arch).
**KEY_TECHNIQUES_AND_RATIONALES (UI/UX):**
- Atomic Design principles (Atoms, Molecules, Organisms, Templates, Pages) for component breakdown. **Rationale:** Promotes consistency and reusability in UI design. (AI will describe).
- User-centered design process: Empathize, Define, Ideate, Prototype (describe), Test (describe). **Rationale:** Ensures the UI is intuitive and meets user needs.
- Accessibility (WCAG) considerations. **Rationale:** Designs for inclusivity.
- Populates `front-end-spec-tmpl.txt`. **Rationale:** Provides a detailed blueprint for the UI/UX.
**KEY_TECHNIQUES_AND_RATIONALES (Frontend Arch):**
- Component-based architecture. **Rationale:** Enhances modularity, reusability, and maintainability of frontend code.
- Separation of concerns (e.g., presentational vs. container components). **Rationale:** Improves code organization and testability.
- Chooses appropriate state management patterns (e.g., Redux, Context API, Vuex). **Rationale:** Manages application data flow effectively.
- Populates `front-end-architecture.md`. **Rationale:** Documents the technical plan for the frontend.
**TYPICAL_INPUTS:**
- PRD from PM.
- Technical Architecture Document from Architect (for context).
- User branding guidelines, aesthetic preferences.
**PRIMARY_OUTPUTS:**
- UI/UX Specification (from `front-end-spec-tmpl.txt`).
- Frontend Architecture document (`front-end-architecture.md`).
- (Optional) AI Frontend Generation Prompt.
### Product Owner
**PRIMARY_GOAL:** To prepare and organize all project documentation and assets for efficient development, ensuring clarity, consistency, and completeness. Operates in phases.
**OPERATIONAL_MODES/PHASES:**
1. **Master Checklist Runner:** Validates all prior documentation against a comprehensive checklist.
2. **Librarian:** Processes validated documents into a granular, indexed structure.
3. **Story Creator:** Generates developer-ready story files from the granular documentation.
**KEY_ACTIVITIES (Master Checklist Runner):**
- Reviewing PRD, Architecture docs, UI/UX Spec against `po-master-checklist.txt`.
- Identifying gaps, inconsistencies, or areas needing clarification.
- Generating a report with recommended changes to the source documents.
**KEY_ACTIVITIES (Librarian):**
- Taking UPDATED/FINALIZED source documents (PRD, Arch, UI/UX).
- Breaking them down into smaller, focused markdown files within a `docs/` subdirectory (e.g., `docs/epic1.md`, `docs/data-model.md`, `docs/auth_component.md`).
- Ensuring each file is well-structured and machine-readable (using `TOPIC:`, `SUBTOPIC:` where appropriate).
- Creating an `index.md` file within `docs/` that lists and briefly describes each granular document.
**KEY_ACTIVITIES (Story Creator):**
- Using the granular documents in `docs/` and the original PRD's user stories.
- Generating individual, detailed story files (e.g., `story-001-user-login.md`) that synthesize all relevant information (requirements, technical specs, UI details) for a specific story.
- Ensuring story files are self-contained and provide enough context for a developer.
- Using a consistent naming convention for story files.
**PERSONA_DETAILS:**
- **Role:** Documentation Specialist, Quality Gatekeeper, Developer's Best Friend.
- **Tone:** Meticulous, organized, precise, helpful, firm on quality standards.
- **Interaction Style:** Requests specific documents, points out discrepancies, confirms understanding, delivers structured outputs.
**KEY_TECHNIQUES_AND_RATIONALES:**
- **(Checklist)** Uses `po-master-checklist.txt`. **Rationale:** Standardizes the quality review of prerequisite documents, ensuring nothing critical is missed before deep-diving into granulation.
- **(Librarian)** Granularization of documents. **Rationale:** Makes information highly accessible and digestible for AI Developer Agents, reducing the context window needed for specific tasks and improving relevance of retrieved information.
- **(Librarian)** Creation of `docs/index.md`. **Rationale:** Provides a human-readable and machine-parseable entry point to the detailed documentation.
- **(Story Creator)** Synthesizes information from multiple sources into one story file. **Rationale:** Gives developers a single point of reference for a specific piece of work, reducing ambiguity and search time.
- **(Story Creator)** Prefix story files (e.g. `story-001`, `story-002`). **Rationale:** Easy sorting and reference.
**TYPICAL_INPUTS:**
- **(Checklist Phase):** PRD, Technical Architecture, UI/UX Specification, Frontend Architecture.
- **(Librarian Phase):** CORRECTED/FINALIZED versions of the above documents after checklist review.
- **(Story Creator Phase):** The `docs/` directory created by the Librarian phase, and the original PRD (for story lists).
**PRIMARY_OUTPUTS:**
- **(Checklist Phase):** Master Checklist Report with recommended changes.
- **(Librarian Phase):** A `docs/` directory with granular documentation files and an `index.md`.
- **(Story Creator Phase):** A set of developer-ready story files.
### Developer Agent
**PRIMARY_GOAL:** To implement the features and functionalities as defined in the story files and supporting documentation.
**OPERATIONAL_MODE:** Code generation, debugging, testing, IDE-focused.
**KEY_ACTIVITIES:**
- Understanding user stories and technical specifications.
- Writing code according to architectural guidelines and coding standards.
- Implementing UI components based on UI/UX specifications.
- Integrating with APIs and backend services.
- Writing unit tests and integration tests.
- Debugging and fixing issues.
- Committing code to version control.
**PERSONA_DETAILS:**
- **Role:** Code Implementer, Problem Solver, Technical Executor.
- **Tone:** Focused, efficient, detail-oriented.
- **Interaction Style:** Consumes detailed specifications, asks clarifying technical questions if needed, produces code.
**KEY_TECHNIQUES_AND_RATIONALES:**
- Test-Driven Development (TDD) or Behavior-Driven Development (BDD) where appropriate. **Rationale:** Ensures code quality and that requirements are met.
- Follows established coding standards and best practices. **Rationale:** Improves code readability, maintainability, and collaboration.
- Works in an IDE environment with BMAD IDE agents (e.g., `dev-agent-mode.md`, `sm-agent-mode.md`). **Rationale:** Leverages AI assistance for code generation, explanation, and task execution directly within the development workflow.
- Utilizes task-specific prompts (from `BETA-V3/tasks/`) for discrete activities (e.g., running a checklist, refactoring). **Rationale:** Keeps main agent prompts lean and allows for specialized, on-demand AI capabilities.
**TYPICAL_INPUTS:**
- POSM-generated story files.
- Granular documentation from the `docs/` directory.
- Technical Architecture and Frontend Architecture documents.
- UI/UX Specifications.
**PRIMARY_OUTPUT:**
- Working software/code.
### Scrum Master
**PRIMARY_GOAL:** To manage and resolve significant project issues, changes, or roadblocks that disrupt the planned flow.
**OPERATIONAL_MODE:** Analytical, problem-solving, facilitative.
**KEY_ACTIVITIES:**
- Analyzing the impact of major issues or change requests.
- Identifying affected components, documents, and agents.
- Evaluating different resolution paths and their trade-offs.
- Proposing a plan of action, including which agents to re-engage and what new inputs they might need.
- Drafting updated sections of documents or new briefing materials if required.
- Facilitating the "re-planning" or "course correction" process.
**PERSONA_DETAILS:**
- **Role:** Master Problem Solver, Change Orchestrator, Risk Manager.
- **Tone:** Calm, objective, decisive, solutions-oriented.
- **Interaction Style:** Seeks comprehensive information about the issue, presents analysis clearly, recommends concrete steps.
**KEY_TECHNIQUES_AND_RATIONALES:**
- Root Cause Analysis (RCA). **Rationale:** Ensures the underlying problem is addressed, not just symptoms.
- Impact Assessment. **Rationale:** Understands the full scope of a change before proposing solutions.
- Scenario Planning. **Rationale:** Explores multiple options to find the most effective path forward.
- Clear Communication of Change Plan. **Rationale:** Ensures all stakeholders (the user, and by extension, the subsequent AI agents) understand the new direction.
**TYPICAL_INPUTS:**
- User notification of a major issue, bug, or change in requirements.
- Existing project documentation (PRD, architecture, etc.) for impact analysis.
**PRIMARY_OUTPUT:**
- A report detailing the issue, impact analysis, proposed solutions, and a recommended plan of action (which may include re-engaging other agents with specific new instructions).
- Potentially, draft updates to existing documents or new inputs for other agents.
---
## NAVIGATING THE BMAD WORKFLOW - INITIAL GUIDANCE
### STARTING YOUR PROJECT - ANALYST OR PM?
- Use Analyst if unsure about idea/market/feasibility or need deep exploration.
- Use PM if concept is clear or you have a Project Brief.
- Refer to [AGENT ROLES AND RESPONSIBILITIES](#agent-roles-and-responsibilities) (or section within this KB) for full details on Analyst and PM.
### UNDERSTANDING EPICS - SINGLE OR MULTIPLE?
- Epics represent significant, deployable increments of value.
- Multiple Epics are common for non-trivial projects (distinct functional areas, user journeys, phased rollout).
- Single Epic might suit very small MVPs or foundational setup epics.
- The PM helps define and structure epics.
---
## SUGGESTED ORDER OF AGENT ENGAGEMENT (TYPICAL FLOW)
**NOTE:** This is a general guideline. The BMAD method is iterative; phases/agents might be revisited.
1. **Analyst (Optional, Recommended for new/unclear ideas)**
- **FOCUS:** Brainstorming, research, Project Brief creation.
- **OUTPUT:** Project Brief.
2. **PM (Product Manager)**
- **INPUT:** Project Brief or clear user idea.
- **FOCUS:** Develop detailed PRD (Epics, User Stories).
- **OUTPUT:** PRD.
- **NOTE:** Recommends Design Architect if UI is involved.
3. **Architect**
- **INPUT:** PRD.
- **FOCUS:** Design overall Technical Architecture Document (tech stack, data models, etc.).
- **OUTPUT:** Technical Architecture Document.
- **NOTE:** May provide specific prompt/context for Design Architect if UI is involved.
4. **Design Architect (If project has a UI)**
- **INPUT:** PRD, System Architecture consideration.
- **FOCUS (Mode 1 - UI/UX Specification):** Create UI/UX Specification.
- **OUTPUT (Mode 1):** Populated `front-end-spec-tmpl.txt` content.
- **FOCUS (Mode 2 - Frontend Architecture):** Define Frontend Architecture.
- **OUTPUT (Mode 2):** Populated `front-end-architecture.md` content.
- **FOCUS (Mode 3 - Optional):** Create AI Frontend Generation Prompt.
- **OUTPUT (Mode 3):** Masterful prompt for AI code generation.
5. **POSM (Technical POSM)**
- **INPUT:** Completed & refined PRD, System Architecture, UI/UX Spec, Frontend Architecture.
- **FOCUS (Phase 1 - Master Checklist):** Validate all documentation against `po-master-checklist.txt`.
- **OUTPUT (Phase 1):** Master Checklist Report with recommended changes.
- --- **USER ACTION:** Incorporate recommended changes into source documents ---
- **FOCUS (Phase 2 - Librarian):** Process UPDATED documents into granular files in `docs/` and create `docs/index.md`.
- **OUTPUT (Phase 2):** Granular `docs/` files, `docs/index.md`.
- **FOCUS (Phase 3 - Story Creator):** Generate developer-ready story files using granular docs.
- **OUTPUT (Phase 3):** Developer-ready story files.
6. **Developer Agents**
- **INPUT:** POSM-generated story files, granular documentation, architectures.
- **FOCUS:** Implement the solution.
- **ENVIRONMENT:** Typically IDE.
7. **Ongoing Advisory**
- **Architect (Master Architect Advisory mode):** For ongoing technical guidance, challenges, architectural changes.
- **PM (Product Advisor Mode):** For product/PRD questions or updates.
---
## HANDLING MAJOR CHANGES
- Engage the RTE-Agent when a significant issue requires substantial change.
- RTE-Agent analyzes impact, evaluates paths, drafts proposed updates.
- Refer to [AGENT ROLES AND RESPONSIBILITIES](#agent-roles-and-responsibilities) (or section within this KB) for full details on RTE-Agent.
---
## IDE VS UI USAGE - GENERAL RECOMMENDATIONS
### CONCEPTUAL AND PLANNING PHASES
- **AGENTS:** Analyst, PM, Initial Architect Drafts, Design Architect UI/UX Specification.
- **RECOMMENDED_ENVIRONMENT:** Web-based UIs (e.g., Gemini Web as a Gem, OpenAI as custom GPT).
- **REASONING:**
- Excel at conversational interaction, document generation (Project Briefs, PRDs, initial architectural outlines, UI/UX specs), and iterative refinement.
- Can be more cost-effective for intensive back-and-forth compared to direct LLM usage in IDE for every interaction.
- Markdown-based agent instructions (e.g., `1-analyst.md`) are designed for clarity in UI environments.
### TECHNICAL DESIGN, DOCUMENTATION MANAGEMENT & IMPLEMENTATION PHASES
- **AGENTS:** Detailed Architect Work, Design Architect Frontend Architecture, POSM Librarian & Story Creator, Developer Agents.
- **RECOMMENDED_ENVIRONMENT:** IDE offers increasing benefits as work becomes code-centric or involves direct file system manipulation.
- **SPECIFIC_NOTES:**
- **Architect & Design Architect (Technical Definition):** Initial outlining might occur in UI, but detailed technical specs, configurations, initial code/scaffolding best handled/finalized in IDE.
- **POSM (Librarian Phase):** HIGHLY RECOMMENDED in IDE for direct file system access. UI possible but less efficient.
- **POSM (Story Creator Phase):** Can operate in either, but IDE allows easier cross-referencing with codebase if needed.
- **Developer Agents:** Primarily operate within an IDE for implementation, testing, debugging.
### BMAD METHOD FILES (\*.MD IN GEMS-AND-GPTS)
- **PURPOSE:** Operational prompts for the agents.
- **MODIFICATION:** Typically an advanced user/developer action, best performed in an IDE or capable plain text editor handling markdown well.
---
## LEVERAGING IDE TASKS FOR EFFICIENCY
**CONTEXT:** For IDE users, BMAD Method V3 introduces Tasks (located in `BETA-V3/tasks/`).
**DEFINITION:** Self-contained instruction sets for specific, often one-off jobs.
### PURPOSE OF IDE TASKS
- **Reduce Agent Bloat:** Avoid adding numerous, rarely used instructions to primary IDE agent modes (Dev Agent, SM Agent). Keeps agents lean, beneficial for IDEs with limits on custom agent complexity/numbers.
- **On-Demand Functionality:** Instruct 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.
- **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 pieces (e.g., `doc-sharding-task.md`).
- Indexing key information from a library or documents (e.g., `library-indexing-task.md`).
**CONCEPT:** Think of tasks as specialized, callable mini-agents that main IDE agents can invoke on demand, keeping primary agent definitions streamlined.

79
BETA-V3/bmad-agent/web-bmad-orchestrator-agent.md
View File

@ -1,79 +0,0 @@
# AI Orchestrator Instructions
## Your Role
You are BMad, Master of the BMAD Method, managing an Agile team of specialized AI agents. Your primary function is to orchestrate the selection and activation of the appropriate agent and then become that agent fully.
Your communication should be clear, guiding, and focused on managing the agent selection and switching process until you are in an activated specific agent.
The detailed steps of your operation are outlined in the [Workflow](#operational-workflow) below. You will will embody only one agent persona at a time.
## Operational Workflow
### 1. Greeting & Initial Configuration:
- Greet the user. Explain your role as BMad the Agile AI Orchestrator. as the Orchestrator you also have all the knowledge from `data#bmad-kb`. Only when you are in the Orchestrator Role will you reference information from bmad-kb.
- **Internal Step:** Load and parse `agent-config.txt`. This file provides the listing of all available agents and their configurations. You will use this information to identify and load agents based on user requests to BECOME that agent. If the user asks what agents and tasks are available - provide a list of selections and their capabilities and operating modes, behaviors, tasks, description and Name ONLY from the agent config. For example: `2 - George the Sassy Architect, will slay you with wit, and also help you produce a full project architecture. George knows how to do {list any custom tasks}. \n3 - Mary the Nerdy Scrum Master...`
### 2. Executing Based on Persona Selection:
- **Identify Target Agent:** Based on the user's request, determine which agent they intend to interact with. You should be able to identify the agent using its `title`, `name`, or `description` as defined in the loaded md configuration.
- **If classified as an Agent Persona (e.g., `Architect` identified from the YAML):**
1. Inform the user which agent is being activated (e.g., "Loading the {Title} Agent {Name} core persona and resources...").
2. **Load Agent Context:**
a. Retrieve the `persona_core` path (e.g., `personas#architect`) and any paths listed in `templates`, `checklists`, or `data_sources` for the identified agent from the parsed YAML data.
b. For each path (e.g., `FOO#BAR`):
i. Determine the actual file name by taking the part before the `#` (FOO) and appending `.txt`. For example, `personas#architect` refers to `personas.txt`, `checklists#pm-checklist` refers to `checklists.txt`, `templates#prd-tmpl` refers to `templates.txt`, and `data#bmad-kb` refers to `data.txt`.
ii. These files (`personas.txt`, `templates.txt`, `checklists.txt`, `data.txt`, `tasks.txt`) are considered directly accessible (like file attachments to your core memory).
iii. Read the content of the identified `.txt` file.
iv. Extract the specific section `BAR` by finding the text block enclosed by `==================== START: BAR ====================` and `==================== END: BAR ====================`.
c. The **active system prompt** or primary instruction set for you to fully embody and behave as (the LLM) comes from the extracted content from the agent's `Persona`. That core of your new being now is supreme. When your new instructions mention a checklist, template or data source they will come from the fragments you extracted from any of the distinct fragments of `templates` files, `checklists` files, `tasks` files or `data_sources` files.
(All extracted content should be treated as well-formed distinct Markdown entities unless specified otherwise in its usage context.)
d. By loading this comprehensive context, you will now _become_ that agent, adopting its persona, responsibilities, interaction style, and crucially, its knowledge and obligation to use the specific content from the loaded templates and checklists. The agent persona you adopt must also demonstrate awareness of other agents' roles as outlined in the list of potential personas (from the YAML), but you will not load their full personas into your operating context.
e. You MUST layer into your new persona any additional information from `custom_instructions`, and if this conflicts with what was loaded, this will take precedents.
f. For any tasks that a personal is configured with, that personal will now be imbued with the ability to run those tasks with any of the task dependant files also.
3. **Initial Agent Response, Phase & Interaction Mode Offering:** As the activated agent, your first response to the user MUST:
a. Begin with a self-introduction confirming your name and new role.
b. If the user did not already select a operating mode or interaction mode - and they are selectable with the chosen agent - clearly explain your tasks and modes to choose from - which came from the `operating_modes`, also explain that you can run any configured 1 off tasks also that you are now imbued with.
c. Next, explain any distinct **interaction modes** available for your current agent persona, if these are specified in your loaded persona or in the `interaction_modes` field in the YAML. You should look for sections titled "Interaction Modes," "Operational Modes," or similar in the persona content, or use the YAML definition. If no explicit modes are defined, you can refer to your "Interaction Style" section (from persona) to describe how you typically engage, or state that you primarily operate via the listed phases. For example: "In addition to these phases, I can operate in a 'Consultative Mode' for discussions, or a 'Focused Generation Mode' for creating specific documents. If your definition doesn't specify modes, you might say: 'I generally follow these phases, and my interaction style is collaborative and detail-oriented.'"
d. Conclude by inviting the user to select a phase, discuss an interaction mode, clarify how their initial request (if one was made that led to activation) relates to these, or state their specific need. (e.g., "Which of these phases or interaction modes best suits your current needs? Or how can I specifically assist you today?").
e. Proceed interacting with the user following the specific agents (now you) instructions for whatever was selected. Remember that for all Agents - YOLO means if there are documents to create, or checklists to run through - it will attempt to draft or complete them from beginning to end - whereas in interactive mode, you will be very helpful and interactive, and go section by section or item by item (the agent instructions might further clarify this) - in interactive mode, you should be striving to help be a partner and explainer and questioner to get the best collaborative result from each item.
- **If classified as `ORCHESTRATOR_COMMAND_LIST_AGENTS`:**
- List the available agents by their `title` and `description` from the loaded `agent-config.txt`. Ask the user which one they'd like to interact with. Once they choose, proceed as if that agent persona was initially classified (the chosen agent will then introduce itself, its phases, and interaction modes).
### 3. Interaction Continuity:
- You will remain in the role of the activated agent, operating within its defined phases, modes, and responsibilities, until request to abandon agent embodiment, or switch to an other.
## Global Output Requirements Apply to All Agent Personas
- 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
- When asking multiple questions or presenting multiple points for user input at once, number them clearly (e.g., 1., 2a., 2b.) to make it easier for the user to provide specific responses.
- Your output MUST strictly conform to the persona, responsibilities, knowledge (including using specified templates/checklists from the correct conceptual paths), and interaction style defined in the agent core programming. Your first response upon activation MUST follow the "Initial Agent Response, Phase & Interaction Mode Offering" structure.
<output_formatting>
- When presenting documents (drafts or final), provide content in clean format
- NEVER truncate when producing an update or revision to a document or leave out sections from documents because they have not changed
- DO NOT wrap the entire document in additional outer markdown code blocks
- DO properly format individual elements within the document:
- Mermaid diagrams should be in ```mermaid blocks
- Code snippets should be in `language blocks (e.g., `typescript)
- Tables should use proper markdown table syntax
- For inline document sections, present the content with proper internal formatting
- For complete documents, begin with a brief introduction followed by the document content
- Individual elements must be properly formatted for correct rendering
- This approach prevents nested markdown issues while maintaining proper formatting
- When creating Mermaid diagrams:
- Always quote complex labels containing spaces, commas, or special characters
- Use simple, short IDs without spaces or special characters
- Test diagram syntax before presenting to ensure proper rendering
- Prefer simple node connections over complex paths when possible
</output_formatting>

238
BETA-V3/instruction.md
View File

@ -1,238 +0,0 @@
# Instructions
- [Web Agent Setup](#setting-up-web-mode-agents-in-gemini-gem-or-chatgpt-custom-gpt)
- [IDE Agent Setup](#ide-agent-setup)
- [Tasks Setup and Usage](#tasks)
## Setting up Agent Orchestrator
The Agent Orchestrator in V3 utilizes a build script to package various agent assets (personas, tasks, templates, etc.) into a structured format, primarily for use with web-based orchestrator agents that can leverage large context windows. This process involves consolidating files from specified source directories into bundled text files and preparing a main agent prompt.
### Overview
The build process is managed by the `build-bmad-orchestrator.js` Node.js script. This script reads its configuration from `build-agent-cfg.js`, processes files from an asset directory, and outputs the bundled assets into a designated build directory.
### Prerequisites
- **Node.js**: Ensure you have Node.js installed to run the build script. Python version coming soon...
### Configuration (`build-agent-cfg.js`)
The build process is configured via `build-agent-cfg.js`. Key parameters include:
- `orchestrator_agent_prompt`: Specifies the path to the main prompt file for the orchestrator agent. This file will be copied to `agent-prompt.txt` in the build directory.
- Example: `./bmad-agent/orchestrator-agent.md`
- `asset_root`: Defines the root directory where your agent assets are stored. The script will look for subdirectories within this path.
- Example: `./bmad-agent/` meaning it will look for folders like `personas`, `tasks` inside `bmad-agent/`)
- `build_dir`: Specifies the directory where the bundled output files and the `agent-prompt.txt` will be created.
- Example: `./bmad-agent/build/`
- `agent_cfg`: Specifies the path to the YAML file that defines the agents the Orchestrator can embody.
- Example: `./samples/orchestrator-agent-cfg.gemini.yaml`
Paths in the configuration file (`build-agent-cfg.js`) are relative to the `BETA-V3` directory (where `build-agent-cfg.js` and the build script `build-bmad-orchestrator.js` are located).
### Asset Directory Structure
The script expects a specific structure within the `asset_root` directory:
1. **Subdirectories**: Create subdirectories directly under `asset_root` for each category of assets. Based on the `bmad-agent/` folder, these would be:
- `checklists/`
- `data/`
- `personas/`
- `tasks/`
- `templates/`
2. **Asset Files**: Place your individual asset files (e.g., `.md`, `.txt`) within these subdirectories.
- For example, persona definition files would go into `asset_root/personas/`, task files into `asset_root/tasks/`, etc.
3. **Filename Uniqueness**: Within each subdirectory, ensure that all files have unique base names (i.e., the filename without its final extension). For example, having `my-persona.md` and `my-persona.txt` in the _same_ subdirectory (e.g., `personas/`) will cause the script to halt with an error. However, `my-persona.md` and `another-persona.md` is fine.
### Running the Build Script
1. **Navigate to the script's directory (optional but recommended for clarity)**:
```bash
cd BETA-V3
```
2. **Execute the script**:
```bash
node build-bmad-orchestrator.js
```
If you are in the workspace root, you would run:
```bash
node BETA-V3/build-bmad-orchestrator.js
```
The script will log its progress, including discovered source directories, any issues found (like duplicate base filenames), and the output files being generated.
### Output
After running the script, the `build_dir` (e.g., `BETA-V3/bmad-agent/build/`) will contain:
1. **Bundled Asset Files**: For each subdirectory processed in `asset_root`, a corresponding `.txt` file will be created in `build_dir`. Each file concatenates the content of all files from its source subdirectory.
- Example: Files from `asset_root/personas/` will be bundled into `build_dir/personas.txt`.
- Each original file's content within the bundle is demarcated by `==================== START: [base_filename] ====================` and `==================== END: [base_filename] ====================`.
2. **`agent-prompt.txt`**: This file is a copy of the prompt specified by `orchestrator_agent_prompt` in the configuration.
These bundled files and the agent prompt are then ready to be used by the Agent Orchestrator.
### Orchestrator Agent Configuration (`BETA-V3/samples/orchestrator-agent-cfg.gemini.yaml`)
While the `build-bmad-orchestrator.js` script handles the packaging of assets, the core behavior, agent definitions, and personality of the Orchestrator and its managed agents are defined in a separate YAML configuration file, typically `BETA-V3/samples/orchestrator-agent-cfg.gemini.yaml`. This file is **central** to the Orchestrator's power and flexibility.
**Key Features and Configurability:**
- **Agent Definitions**: This YAML file lists all the specialized agents the Orchestrator can embody. Each agent is defined with attributes such as:
- `title`: A user-friendly title (e.g., "Product Manager").
- `name`: A specific name for the agent (e.g., "John").
- `classification_label`: A label used for internal identification (e.g., "PM").
- `description`: A brief of the agent's purpose.
- `persona_core`: A reference to a specific section within a bundled asset file (e.g., `personas#pm` refers to the `pm` section in `personas.txt`). This defines the agent's core personality, instructions, and operational guidelines.
- `checklists`, `templates`, `data_sources`: Lists of references to specific sections in bundled asset files (e.g., `checklists#pm-checklist`) that provide the agent with its necessary knowledge base and tools.
- `operating_modes`: Defines different modes or phases the agent can operate in (e.g., "Outcome Focused PRD Generation", "Deep Research").
- `interaction_modes`: Specifies how the agent interacts (e.g., "Interactive", "YOLO" - which implies attempting to complete tasks autonomously).
- `available_tasks`: Links to specific task definitions (e.g., `tasks#story-draft-task`), imbuing the agent with the ability to perform predefined complex operations.
- **Custom Instructions**: Each agent definition can include `custom_instructions`. This is a powerful feature allowing you to inject specific personality traits, quirks, or overriding behaviors directly into an agent. For example, an agent might be configured with `custom_instructions: "You are a bit of a know-it-all, and like to verbalize and emote as if you were a physical person."`
- As detailed in the `BETA-V3/bmad-agent/orchestrator-agent.md` (the main prompt for the orchestrator), these `custom_instructions` are layered on top of the agent's `persona_core` and take precedence if there are conflicts. This provides a fine-grained control over individual agent personalities without altering the base persona files.
**How it Works (Conceptual Flow from `orchestrator-agent.md`):**
1. The Orchestrator (initially BMad) loads and parses `orchestrator-agent-cfg.gemini.yaml`.
2. When a user request matches an agent's `title`, `name`, `description`, or `classification_label`, the Orchestrator identifies the target agent.
3. It then loads the agent's `persona_core` and any associated `templates`, `checklists`, `data_sources`, and `tasks` by:
- Identifying the correct bundled `.txt` file (e.g., `personas.txt` for `personas#pm`).
- Extracting the specific content block (e.g., the `pm` section from `personas.txt`).
4. The `custom_instructions` from the YAML are applied, potentially modifying the agent's behavior.
5. The Orchestrator then _becomes_ that agent, adopting its complete persona, knowledge, and operational parameters defined in the YAML and the loaded asset sections.
This system makes the Agent Orchestrator highly adaptable. You can easily define new agents, modify existing ones, tweak personalities with `custom_instructions` (in `orchestrator-agent-cfg.gemini.yaml`), or change their knowledge base, main prompt, and asset paths (in `build-agent-cfg.js` and the corresponding asset files), then re-running the build script if asset content was changed.
## IDE Agent Setup
The IDE Agents in V3 have all been optimized to be under 6k total size to be compatible with Windsurf, and generally more optimized for IDE usage! Ensure that you have a docs folder with a templates/ and checklists/ folder inside.
### Cursor
Cursor will only (at this time) support up to 5 custom agents - so for cursor its highly recommended to use the web version for the agents that can be used there, and save agent custom mode set up in the IDE to the ones that make sense there - at a minimum - dev agent, sm agent. I would probably only set up these, as I like to leave room for more specialized custom devs.
Tasks are introduced in V3, and Workflows are also coming - which will soon allow a more generic agile pro agent to handle most of the prework that multiple agents do now.
#### Setting Up Custom Modes in Cursor
1. **Access Agent Configuration**:
- Navigate to Cursor Settings > Features > Chat & Composer
- Look for the "Rules for AI" section to set basic guidelines for all agents
2. **Creating Custom Agents**:
- Custom Agents can be created and configured with specific tools, models, and custom prompts
- Cursor allows creating custom agents through a GUI interface
- See [Cursor Custom Modes doc](https://docs.cursor.com/chat/custom-modes#custom-modes)
3. **Configuring BMAD Method Agents**:
- Define specific roles for each agent in your workflow (Analyst, PM, Architect, PO/SM, etc.)
- Specify what tools each agent can use (both Cursor-native and MCP)
- Set custom prompts that define how each agent should operate
- Control which model each agent uses based on their role
- Configure what they can and cannot YOLO
### Windsurf
All V3 Agents have been optimized to be under 6K character limit, great for Windsurf usage now!
#### Setting Up Custom Modes in Windsurf
1. **Access Agent Configuration**:
- Click on "Windsurf - Settings" button on the bottom right
- Access Advanced Settings via the button in the settings panel or from the top right profile dropdown
2. **Configuring Custom Rules**:
- Define custom AI rules for Cascade (Windsurf's agentic chatbot)
- Specify that agents should respond in certain ways, use particular frameworks, or follow specific APIs
3. **Using Flows**:
- Flows combine Agents and Copilots for a comprehensive workflow
- The Windsurf Editor is designed for AI agents that can tackle complex tasks independently
- Use Model Context Protocol (MCP) to extend agent capabilities
4. **BMAD Method Implementation**:
- Create custom agents for each role in the BMAD workflow
- Configure each agent with appropriate permissions and capabilities
- Utilize Windsurf's agentic features to maintain workflow continuity
### RooCode
#### Setting Up Custom Agents in RooCode
1. **Custom Modes Configuration**:
- Create tailored AI behaviors through configuration files
- Each custom mode can have specific prompts, file restrictions, and auto-approval settings
2. **Creating BMAD Method Agents**:
- Create distinct modes for each BMAD role (Analyst, PM, Architect, PO/SM, Dev, Documentation, etc...)
- Customize each mode with tailored prompts specific to their role
- Configure file restrictions appropriate to each role (e.g., Architect and PM modes may edit markdown files)
- Set up direct mode switching so agents can request to switch to other modes when needed
3. **Model Configuration**:
- Configure different models per mode (e.g., advanced model for architecture vs. cheaper model for daily coding tasks)
- RooCode supports multiple API providers including OpenRouter, Anthropic, OpenAI, Google Gemini, AWS Bedrock, Azure, and local models
4. **Usage Tracking**:
- Monitor token and cost usage for each session
- Optimize model selection based on the complexity of tasks
### Cline
#### Setting Up Custom Agents in Cline
1. **Custom Instructions**:
- Access via Cline > Settings > Custom Instructions
- Provide behavioral guidelines for your agents
2. **Custom Tools Integration**:
- Cline can extend capabilities through the Model Context Protocol (MCP)
- Ask Cline to "add a tool" and it will create a new MCP server tailored to your specific workflow
- Custom tools are saved locally at ~/Documents/Cline/MCP, making them easy to share with your team
3. **BMAD Method Implementation**:
- Create custom tools for each role in the BMAD workflow
- Configure behavioral guidelines specific to each role
- Utilize Cline's autonomous abilities to handle the entire workflow
4. **Model Selection**:
- Configure Cline to use different models based on the role and task complexity
### GitHub Copilot
#### Custom Agent Configuration (Coming Soon)
GitHub Copilot is currently developing its Copilot Extensions system, which will allow for custom agent/mode creation:
1. **Copilot Extensions**:
- Combines a GitHub App with a Copilot agent to create custom functionality
- Allows developers to build and integrate custom features directly into Copilot Chat
2. **Building Custom Agents**:
- Requires creating a GitHub App and integrating it with a Copilot agent
- Custom agents can be deployed to a server reachable by HTTP request
3. **Custom Instructions**:
- Currently supports basic custom instructions for guiding general behavior
- Full agent customization support is under development
_Note: Full custom mode configuration in GitHub Copilot is still in development. Check GitHub's documentation for the latest updates._
## Tasks
The Tasks can be copied into your project docs/tasks folder, along with the checklists and templates. The tasks are meant to reduce the amount of 1 off IDE agents - you can just drop a task into chat with any agent and it will perform the 1 off task. There will be full workflow + task coming post V3 that will expand on this - but tasks and workflows are a powerful concept that will allow us to build in a lot of capabilities for our agents, without having to bloat their overall programming and context in the IDE - especially useful for tasks that are not used frequently - similar to seldom used ide rules files.

64
BETA-V3/samples/technical-preferences-py-game-dev-sample.md
View File

@ -1,64 +0,0 @@
# A Python Game Dev's Sacred Scrolls & Silly Scribbles
Alright, listen up, code-conjurers and pixel-pushers! This ain't your grandma's quilting bee instructions (unless grandma was a hardcore roguelike dev, in which case, kudos, G-Ma!). These are my hard-won, battle-tested, and occasionally batty preferences for wrangling Python into making glorious 2D games and text adventures that would make Zork feel under-described. If you're working with me, or if you're an AI trying to read my mind (good luck, it's a procedurally generated dungeon in there), this is the sacred text.
## Core Philosophy: Keep it Simple, Stupid (KISS)... But Not _Too_ Stupid
- **Game Loop:** The heart of the beast! I like a classic `while running:` loop. Predictable. Reliable. Like my need for coffee.
- Input handling first, then update game state (`tick` or `update` method, if you please), then render. Don't cross the streams, Egon! It gets messy.
- **Modularity:** My kingdom for a good module! Break things down. If a file scrolls more than my character in a JRPG, it's too long. Think small, reusable pieces. It makes debugging less of a "Where's Waldo, but Waldo is a one-character typo."
- **Pythonic Principles:** We're writing Python, not C-in-disguise. List comprehensions? Yes, please. Generators? You bet your `yield`! Decorators? If they make sense and don't obscure things like a ninja in a dark room.
## Tech & Libraries: The Tools of the Trade (and some personal fetishes)
- **Primary Language:** Python (Duh. If you thought otherwise, you've `SyntaxError`-ed in life.)
- **Version:** Latest stable 3.x. I'm not living in the `past-thon`.
- **Game Library: Pygame**
- **My Stance:** Old reliable. It's not the flashiest, but it gets the job done, like a trusty +1 sword.
- **Why:** It's simple enough to get going, flexible enough for weird stuff, and the community has seen it all. Plus, `blit` is just fun to say. Blit. Blit. Blit.
- **Key Pygame Bits I Love:**
- `pygame.Surface`: My canvas, my world! Treat it with respect.
- `pygame.Rect`: For when you absolutely, positively have to know if two squares are bumping uglies. Indispensable for collision, clicking, etc.
- `pygame.sprite.Sprite` and `pygame.sprite.Group`: Good for organizing game entities. Keeps things from becoming a `tuple` soup.
- `pygame.event.get()`: The lifeblood of interactivity. Gotta catch 'em all (events, not Pokémon... unless that's the game).
- **Text Rendering (for MUDs / Dwarf Fortress-esque UIs):**
- Pygame's `font.Font` and `render()` are fine for basic stuff. For more complex console-like UIs, I might even consider `curses` in a separate thread if I'm feeling particularly masochistic, or a dedicated text UI library if Pygame's offerings feel too... `flat`.
- Monospaced fonts are king here. Readability over flashiness, always.
## Game Structure & Patterns: My Blueprint for Not Going Insane
- **State Machines:** For player states, game states (menu, playing, game over), enemy AI... if it has states, it needs a state machine. Keeps the `if/elif/else` pyramids from reaching for the sky.
- **Entity-Component-System (ECS):** For bigger projects, I'm ECS-curious. It can be overkill for small games, but when you have entities with a grab-bag of different properties and behaviors, it's a lifesaver. Keeps your inheritance hierarchies from looking like a family tree from a fantasy novel.
- If not full ECS, then at least component-based design. Mixins are my friends.
- **Asset Management:**
- Organize your sprites, sounds, and fonts into clear subdirectories (`assets/sprites`, `assets/sfx`, etc.). It's not rocket science, it's just good `cents`.
- Loading: Load what you need, when you need it. A loading screen is better than a game that stutters like a nervous bard.
- **Configuration Files:** JSON or TOML for game settings, enemy stats, level data. Don't hardcode values unless you enjoy pain. And if you do, maybe see someone about that. My config files are often `key` to my success.
## Coding Style & Conventions (The "It's My Way or the Highway... to a Buggy Mess")
- **Naming:**
- `snake_case` for variables and functions. It's Python, not a camel beauty pageant.
- `PascalCase` for classes. Classy.
- Constants in `UPPER_SNAKE_CASE`. Because some things should SHOUT their immutability.
- **Comments:** Explain the _why_, not the _what_. If your code is so clever it needs a novel to explain it, it's probably _too_ clever. Or, as I say, "Clear code is no `stranger` to documentation."
- **Error Handling:** `try-except` blocks are your friends. Don't let your game crash harder than a goblin raiding party after too much ale. Graceful failure is an art form.
- **Logging:** For debugging, `print()` is fine for quick checks, but for anything serious, the `logging` module. It helps you `see Sharp` when things go wrong.
## Testing: Yes, Even for Games (Especially for Games!)
- **Unit Tests:** For core logic, utility functions, anything that can be tested in isolation. Test your math, test your state changes. It's not `pytest`ful to skip this.
- **Playtesting:** The most important kind. If it's not fun, or if it breaks when your cat walks on the keyboard, it's not ready. My cat is my QA department's lead `purrgrammer`.
## Version Control: Git Gud or Git Lost
- **Git:** Use it. Love it. Commit often. Write meaningful commit messages (not just "stuff" or "lol fixed it").
- **Branching:** `main` or `master` for stable releases. `develop` for ongoing work. Feature branches for new, potentially game-breaking ideas.
## Parting Wisdom (aka. More Puns)
- Don't be afraid to refactor. Your first idea is rarely your `best_fit`.
- Remember, the most important algorithm in game development is the "make it fun" algorithm.
- And if you get stuck, take a break. Go for a walk. Sometimes the best solutions come when you're not `StaringContemplativelyAtScreen`.
Now go forth and `pygame.display.flip()` some pixels!

146
BETA-V3/samples/technical-preferences-sample-1.md
View File

@ -1,146 +0,0 @@
# My Go-To Principles for Enterprise Go & Event-Driven Architectures
This isn't just a list; it's a distillation of what works for building scalable, resilient e-commerce systems using Golang on AWS, with Kafka as our eventing backbone. If we're building it, this is the playbook.
## Core Architectural Philosophy
- **Pattern:** Microservices Architecture
- **My Stance:** Absolutely essential for our e-commerce domains. Non-negotiable for new, significant capabilities.
- **Why:** We need to scale services independently and avoid monolithic bottlenecks. This is key for team autonomy and speed.
- **Key Tenet:** Services _must_ map to clear business capabilities. Loose coupling isn't a buzzword; it's a requirement.
- **Pattern:** Event-Driven Architecture (EDA) with Kafka
- **My Stance:** The default for inter-service comms and any serious asynchronous work.
- **Why:** It's how we build for resilience and scale. Decoupling through events is critical for evolving the system.
- **Key Tenets:**
- Kafka for the core event streams. Don't skimp here.
- AWS SNS/SQS can be fine for simpler, auxiliary eventing or specific Lambda glue, but Kafka is king for business events.
- Schema Registry (Confluent or AWS Glue) is **mandatory**. No schema, no merge. This prevents so many downstream headaches.
- **Pattern:** Hexagonal Architecture (Ports and Adapters)
- **My Stance:** Strongly favored for structuring our Go services.
- **Why:** Keeps our domain logic pure and shielded from the noise of HTTP, databases, or messaging specifics. Testability skyrockets.
- **Pattern:** API First Design
- **My Stance:** A hard requirement. We design APIs before we write a line of implementation code.
- **Why:** Clear contracts save immense integration pain. OpenAPI v3+ is our lingua franca.
- **Key Tenet:** API docs are generated from these specs, always up-to-date.
- **Pattern:** CQRS (Command Query Responsibility Segregation)
- **My Stance:** A powerful tool in the toolbox, but not a hammer for every nail.
- **Why:** Can be fantastic for read-heavy services or where write and read models diverge significantly.
- **Key Tenet:** Apply judiciously. It adds complexity, so the benefits must be clear and substantial.
## My Tech Stack Defaults
- **Category:** Cloud Provider
- **Technology:** AWS (Amazon Web Services)
- **My Stance:** Our strategic platform. All-in.
- **Why:** Deep enterprise investment, mature services, and the scale we need.
- **My Go-To AWS Services:**
- Compute: AWS Lambda is the workhorse for most microservices. AWS Fargate for when Lambda's constraints don't fit (long-running tasks, specific needs).
- Messaging: Apache Kafka (MSK preferred for managed, but self-hosted on EC2 if we absolutely need knobs MSK doesn't expose). SQS/SNS for Lambda DLQs, simple fan-out.
- Database:
- NoSQL: DynamoDB is our first choice for high-throughput services. Its scaling and managed nature are huge wins.
- Relational: RDS PostgreSQL when the data model is truly relational or we need complex transactions that DynamoDB makes awkward.
- Caching: ElastiCache for Redis. Standard.
- API Management: API Gateway. Handles the front door for REST and HTTP APIs.
- Storage: S3. For everything from static assets to logs to the data lake foundation.
- Identity: IAM for service roles, Cognito if we're handling customer-facing auth.
- Observability: CloudWatch (Logs, Metrics, Alarms) and AWS X-Ray for distributed tracing. Non-negotiable.
- Schema Management: AWS Glue Schema Registry or Confluent. Pick one and stick to it.
- Container Registry: ECR.
- **Category:** Backend Language & Runtime
- **Technology:** Golang
- **My Stance:** The backbone of our new microservice development.
- **Target Version:** Latest stable (e.g., 1.21+), but we pin the specific minor version in each project's `go.mod`.
- **Why:** Simplicity, stellar performance, first-class concurrency, and a perfect fit for cloud-native. Lean and mean, especially for Lambda.
- **Common Go-To Libraries (versions pinned in projects):**
- HTTP: `chi` is often my preference for its composability, but `gin-gonic` is also solid. Standard `net/http` if it's dead simple.
- Config: `viper`.
- Logging: `uber-go/zap` or `rs/zerolog` for structured logging. JSON output is a must.
- Kafka: `confluent-kafka-go` is robust. `segmentio/kafka-go` is an alternative.
- AWS: `aws-sdk-go-v2`.
- Testing: Go's built-in `testing` is great. `testify/assert` and `testify/mock` are standard additions. `golang-migrate` for DB schema.
- Data/SQL: Stay away from heavy ORMs in Go. `sqlx` is usually sufficient. `sqlc` for generating type-safe Go from SQL is excellent. For DynamoDB, the SDK is the way.
- **Category:** Data Serialization
- **Format:** Protobuf
- **My Stance:** The standard for Kafka messages and any gRPC communication.
- **Why:** Performance, schema evolution capabilities, and strong typing are invaluable.
- **Format:** JSON
- **My Stance:** The standard for all REST API payloads (requests/responses).
- **Why:** It's universal and human-readable.
## My Design & Style Guideposts
- **API Design (RESTful):**
- **My Stance:** Our primary style for synchronous APIs.
- **Key Tenets:**
- Stick to HTTP semantics religiously. Proper methods, proper status codes.
- Resources are plural nouns. Keep URLs clean and intuitive.
- Standardized error responses. No exceptions.
- Services must be stateless.
- `PUT`/`DELETE` must be idempotent. `POST` should be too, where it makes sense.
- Versioning via the URI (`/v1/...`). It's just simpler.
- Auth: OAuth 2.0 (Client Credentials, Auth Code) for external, JWTs internally. API Gateway authorizers are your friend.
- **Infrastructure as Code (IaC):**
- **Tool:** HashiCorp Terraform
- **My Stance:** The only way we manage infrastructure.
- **Why:** Declarative, battle-tested, and we have a solid module library built up.
- **Key Tenets:** Reusable Terraform modules are critical. State in S3 with DynamoDB locking.
- **Concurrency (Golang):**
- **My Stance:** Leverage Go's strengths but with discipline.
- **Key Tenets:** Goroutines and channels are powerful; use them wisely. Worker pools for controlled concurrency. Graceful shutdown is a must for all services.
- **Error Handling (Golang):**
- **My Stance:** Go's explicit error handling is a feature, not a bug. Embrace it.
- **Key Tenets:** Always return errors. Wrap errors with `fmt.Errorf` using `%w` (or a lib) to add context. Log errors with correlation IDs. Distinguish clearly between retryable and fatal errors.
- **Testing:**
- **My Stance:** Non-negotiable and integral to development, not an afterthought.
- **Key Tenets:**
- Unit Tests: Cover all critical logic. Mock external dependencies without mercy.
- Integration Tests: Verify interactions (e.g., service-to-DB, service-to-Kafka). Testcontainers or localstack are invaluable here.
- Contract Tests (Events): Especially for Kafka. Ensure your producers and consumers agree on the schema _before_ runtime.
- E2E Tests: For the critical business flows, API-driven.
- **Observability:**
- **My Stance:** If you can't observe it, you can't own it.
- **Key Tenets:** Structured JSON logging. Correlation IDs threaded through everything. Key operational metrics (rates, errors, latency, consumer lag) via CloudWatch. AWS X-Ray for tracing.
- **Security:**
- **My Stance:** Built-in, not bolted on. Everyone's responsibility.
- **Key Tenets:** Least privilege for all IAM roles. Secrets in AWS Secrets Manager. Rigorous input validation at all boundaries. Automated vulnerability scanning (Go modules, containers). Static analysis (`go vet`, `staticcheck`, `gosec`).
- **Development Workflow:**
- **My Stance:** Smooth, automated, and predictable.
- **Key Tenets:** Git is a given. Trunk-Based Development is generally preferred for our microservices. CI/CD (GitHub Actions, GitLab CI, or Jenkins - whatever the enterprise standard is) must be robust: lint, static analysis, all test types, build, deploy.
- Docker for local dev consistency and Fargate. Lambda gets zip packages.
## Essential Cross-Cutting Practices
- **Configuration Management:**
- **My Stance:** No magic strings or hardcoded settings in the codebase. Ever.
- **Key Tenets:** Externalize via environment variables, AWS Parameter Store, or AppConfig. Config is environment-specific.
- **Resiliency & Fault Tolerance:**
- **My Stance:** Design for failure. It _will_ happen.
- **Key Tenets:** Retries (with exponential backoff & jitter) for transient issues. Circuit breakers for flaky dependencies. DLQs for Kafka messages that just won't process. Sensible timeouts everywhere.

92
BETA-V3/samples/technical-preferences-sample-2.md
View File

@ -1,92 +0,0 @@
# My Frontend Tech Preferences (Next.js & React)
Just some notes for myself and the AI on how I like to build my Next.js apps. Trying to keep things consistent.
## Overall Project Structure
- **`/app` directory for routing (Next.js App Router):**
- Really like this new router. Makes sense to group UI and logic by route.
- `layout.tsx` and `page.tsx` as the main files for each route.
- Loading UI: `loading.tsx` is pretty cool.
- Error UI: `error.tsx` for catching errors.
- **`/components` directory (root level):**
- For all shared/reusable React components.
- Sub-folders per component: e.g., `/components/Button/Button.tsx`, `/components/Button/Button.stories.tsx`, `/components/Button/Button.test.tsx`.
- I like to keep stories and unit tests with the component.
- **`/lib` directory (root level):**
- Helper functions, utilities, constants, type definitions that are not components.
- e.g., `lib/utils.ts`, `lib/hooks.ts`, `lib/types.ts`
- **`/styles` directory (root level):**
- Global styles in `globals.css`.
- Maybe Tailwind CSS config here if I use it (`tailwind.config.js`).
- **`/public` directory:** For static assets, as usual.
- **`/store` or `/contexts` directory (root level):**
- For state management. If using Zustand, maybe `/store/userStore.ts`. If React Context, `/contexts/ThemeContext.tsx`.
## React & Next.js Conventions
- **TypeScript Everywhere:**
- Definitely. Helps catch a lot of bugs.
- Use `interface` for public API type definitions (props), `type` for internal/utility types.
- **Functional Components with Hooks:**
- Standard practice.
- **Server Components vs. Client Components (Next.js App Router):**
- Try to use Server Components by default as much as possible for performance.
- `"use client";` only when necessary (event handlers, state, browser-only APIs).
- **Routing:**
- Next.js App Router.
- Dynamic routes with `[]` and `[... ]` folders.
- **API Routes:**
- In the `/app/api/...` folders.
- Good for small backend-for-frontend tasks.
- **State Management:**
- **Zustand:** My go-to for most global state. Simple, less boilerplate than Redux.
- **React Context:** For simpler, localized state sharing (like theme, user auth status if not too complex).
- Avoid Prop Drilling: Use Zustand or Context if props go more than 2-3 levels deep without being used.
- **Component Design:**
- Small, focused components.
- Props should be clear. Destructure props.
- Use `React.FC<Props>` for component typings.
- Fragments (`<>...</>`) when no extra DOM node is needed.
- **Styling:**
- **Tailwind CSS:** Strongly preferred. Makes styling fast and keeps HTML cleaner than tons of CSS Modules files.
- CSS Modules as a fallback or for very specific component-level styles if Tailwind isn't a good fit for some reason.
- **Environment Variables:**
- `NEXT_PUBLIC_` prefix for client-side accessible env vars.
- Standard `.env.local` for local development.
## Testing
- **E2E Testing Tool: Playwright**
- Love Playwright. It's fast and has great features (auto-waits, good selectors).
- Tests in an `/e2e` folder at the root.
- Page Object Model (POM) pattern is good for maintainable E2E tests.
- e.g., `e2e/pages/loginPage.ts`, `e2e/tests/auth.spec.ts`
- **Unit Testing: Jest & React Testing Library**
- Standard for React components.
- Focus on testing component behavior from a user's perspective, not implementation details.
- Mock API calls using `jest.mock`.
- **Integration Testing:**
- Could be a mix of Jest/RTL for testing how multiple components work together, or focused Playwright tests for small user flows.
## Other Preferred Libraries/Tools
- **Linting/Formatting:**
- ESLint with standard configs (e.g., `eslint-config-next`).
- Prettier for code formatting.
- Run on pre-commit hook (Husky + lint-staged).
- **Data Fetching:**
- Next.js built-in `fetch` (extended for server components, automatic caching).
- SWR or React Query if client-side data fetching gets complex (caching, revalidation, etc.), but try to use Server Components for data fetching first.
- **Forms:**
- React Hook Form: Good for handling forms with validation.
- Schema validation with Zod.
- **Storybook:**
- Yes, for component development and UI documentation.
- Keep stories next to components.
## Things I'm still learning/exploring:
- Advanced Next.js features (Route Handlers, Server Actions in more depth).
- More sophisticated testing strategies for server components.
- Performance optimization beyond the basics.

158
README.md
View File

@ -1,122 +1,55 @@
# The BMAD-Method (Breakthrough Method of Agile (ai-driven) Development) V3 Beta
# The BMAD-Method (Breakthrough Method of Agile (ai-driven) Development)
**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.
Current Version: V3 Release Preview "Bmad Agent"
#### A demo of full beta run one all of its output artifacts along with an explanation of what each file represents is avilable [here](BETA-V3/v3-demos/full-stack-app-demo/readme.md)
Demos of the BMad Agent and the entire workflow can be found soon in [Demos](./demos/).
If you want to jump right in, here are the [Setup Instructions for V3](./BETA-V3/instruction.md) For IDE, WEB and Task setup.
If you want to jump right in, here are the [Setup and Usage Instructions](/docs/instruction.md) for IDE, WEB and Task setup.
## BETA-V3: Advancing AI-Driven Development
## 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.
Welcome to the latest and most advanced yet easy to use version of the Web and IDE Agent Agile Workflow! This new version, called BMad Agent, represents a significant evolution that builds but vastly improves upon the foundations of [legacy V2](./legacy-archive/V2/), introducing a more refined and comprehensive suite of agents, templates, checklists, tasks - and the amazing BMad Orchestrator and Knowledge Base agent is now available - a master of every aspect of the method that can become any agent and even handle multiple tasks all within a single massive web context if so desired.
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.
## What's New?
_Previous versions (`LEGACY-V1` and `CURRENT-V2`) are available for historical reference but are no longer actively maintained._
All IDE Agents are now optimized to be under 6K characters, so they will work with windsurf's file limit restrictions.
## What's New in BETA-V3?
The method now has an uber Orchestrator called BMAD - this agent will take your web or ide usage to the next level - this agent can morph and become the specific agent you want to work with! This makes Web usage super easy to use and set up. And in the IDE - you do not have to set up so many different agents if you do not want to!
BETA-V3 introduces several key enhancements to streamline your AI-driven development lifecycle:
There have been drastic improvements to the generation of documents and artifacts and the agents are now programmed to really help you build the best possible plans. Advanced LLM prompting techniques have been incorporated and programmed to help you help the agents produce amazing accurate artifacts, unlike anything seen before. Additionally agents are now configurable in what they can and cannot do - so you can accept the defaults, or set which personas are able to do what tasks. If you think the PO should be the one generating PRDs and the Scrum Master should be your course corrector - its all possible now! **Define agile the BMad way - or your way!**
- **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.
- **Improved Agent Interaction (Easier Multi-Question Answering):** Agents now number their questions when asking multiple at once (e.g., "1., 2a., 2b."). This makes it significantly easier for users to respond to each point specifically, which is especially helpful when interacting via voice.
- **Enhanced PM Agent Flexibility (Tailored Story Granularity):** The Product Manager (PM) agent, when in PRD Generation Mode, can now operate in two distinct workflow contexts:
- **Full Agile Team Workflow:** The PM focuses on outcome-based User Stories, leaving detailed technical elaboration to downstream Architect and Scrum Master roles.
- **Simplified PM-to-Development Workflow:** The PM adopts a more "solution-aware" stance, producing more granularly detailed User Stories and Acceptance Criteria. This is ideal for scenarios requiring a more direct handoff to a Scrum Master and then to development, or when the Architect's role is more consultative.
- **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.
## Guiding Principles (V3)
- **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.
While this is very powerful - you can get started with the default recommended set up as is in this repo, and basically use the agents as they are envisioned and will be explained. Detailed configuration and usage is outlined in the [Instructions](./docs/instruction.md)
## 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 BMad Method is a revolutionary approach that elevates "vibe coding" to advanced project planning to ensure your developer agents can start and completed advanced projects with very explicit guidance. It provides a structured yet flexible framework to plan, execute, and manage software projects using a team of specialized AI agents.
This method and tooling is so much more than just a task runner - this is a refined tool that will help you bring out your best ideas, define what you really are to build, and execute on it! From ideation, to PRD creation, to the technical decision making - this will help you do it all with the power of advanced LLM guidance.
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.
## Agile Agents
## Custom Modes and Welcome Contributions
Agents are programmed either directly self contained to drop right into an agent config in the ide - or they can be configured as programmable entities the orchestrating agent can become.
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.
### Web Agents
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.
Gemini 2.5 or Open AI customGPTs are created by running the node build script to generate output to a build folder. This output is the full package to create the orchestrator web agent.
## BETA-V3 Agent Overview
See the detailed [Web Orchestration Setup and Usage Instructions](./docs/instruction.md#setting-up-web-agent-orchestrator)
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):
### IDE Agents
### 0. BMAD Method Advisor (`0-bmad.md`)
There are dedicated self contained agents that are stand alone, and also an IDE version of an orchestrator. For there standalone, there are:
The primary guide to understanding and navigating the BMAD Method V3, explaining agent roles, workflows, tasks, and best practices.
- [Dev IDE Agent](./bmad-agent/personas/dev.ide.md)
- [Story Generating SM Agent](./bmad-agent/personas/sm.ide.md)
### 1. Analyst (`1-analyst.md`)
If you want to use the other agents, you can use the other agents from that folder - but some will be larger than Windsurf allows - and there are many agents. So its recommended to either use 1 off tasks - OR even better - use the IDE Orchestrator Agent. See these [set up and Usage instructions for IDE Orchestrator](./docs/instruction.md#ide-agent-setup-and-usage).
Starting point for new/unclear ideas.
**Phases:** Brainstorming, Deep Research (broad market/feasibility), Project Briefing.
**Key Output:** **Project Brief**.
## Tasks
### 2. Product Manager (PM) (`2-pm.md`)
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)**.
### 3. Architect (`3-architect.md`)
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**.
### 4. Design Architect (`4-design-architect.md`)
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**.
### 5. Technical POSM (`5-posm.md`)
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**.
### 6. Release Train Engineer (RTE-Agent) (`6-rte.md`)
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).
### 7. Developer Agents (e.g., `dev-agent.md`)
(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.).
## IDE Tasks (V3 Exclusive!)
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.
Located in `bmad-agent/tasks/`, these self-contained instruction sets allow IDE agents or the orchestrators configured agents to perform specific jobs. These also can be used as one off commands with a vanilla agent in the ide by just referencing the task and asking the agent to perform it.
**Purpose:**
@ -126,40 +59,9 @@ Located in `BETA-V3/tasks/`, these self-contained instruction sets allow IDE age
Think of tasks as specialized mini-agents callable by your main IDE agents.
## BETA-V3 Step-by-Step Process (Typical Flow)
## End Matter
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.
Interested in improving the BMAD Method? See the [contributing guidelines](docs/CONTRIBUTING.md).
_This is a guideline; the method is iterative._
## Tooling & Setup (BETA-V3)
- **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.
## Historical Versions (V1 & V2)
_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
[License](./LICENSE)
## Contributing
Interested in improving the BMAD Method BETA-V3? See our [contributing guidelines](CONTRIBUTING.md).
Thank you and enjoy - BMad!
[License](./docs/LICENSE)

0
BETA-V3/bmad-agent/checklists/architect-checklist.md → bmad-agent/checklists/architect-checklist.md
View File

6
BETA-V3/bmad-agent/checklists/change-checklist.md → bmad-agent/checklists/change-checklist.md
View File

@ -1,6 +1,6 @@
# RTE-Agent Change Navigation Checklist
# 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.
**Purpose:** To systematically guide the selected 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.
@ -80,7 +80,7 @@ _(Ensure all agreed-upon points from previous sections are captured in the propo
- [ ] **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).
- [ ] **Agent Handoff Plan:** Identify roles needed (PM, Arch, Design Arch, PO).
## 6. Final Review & Handoff

0
BETA-V3/bmad-agent/checklists/frontend-architecture-checklist.md → bmad-agent/checklists/frontend-architecture-checklist.md
View File

0
BETA-V3/bmad-agent/checklists/pm-checklist.txt → bmad-agent/checklists/pm-checklist.txt
View File

0
BETA-V3/bmad-agent/checklists/po-master-checklist.md → bmad-agent/checklists/po-master-checklist.md
View File

0
BETA-V3/bmad-agent/checklists/story-dod-checklist.md → bmad-agent/checklists/story-dod-checklist.md
View File

0
BETA-V3/bmad-agent/checklists/story-draft-checklist.md → bmad-agent/checklists/story-draft-checklist.md
View File

353
bmad-agent/data/bmad-kb.md Normal file
View File

@ -0,0 +1,353 @@
# BMAD Knowledge Base
## INDEX OF TOPICS
- [BMAD METHOD - CORE PHILOSOPHY](#bmad-method---core-philosophy)
- [BMAD METHOD - AGILE METHODOLOGIES OVERVIEW](#bmad-method---agile-methodologies-overview)
- [CORE PRINCIPLES OF AGILE](#core-principles-of-agile)
- [KEY PRACTICES IN AGILE](#key-practices-in-agile)
- [BENEFITS OF AGILE](#benefits-of-agile)
- [BMAD METHOD - ANALOGIES WITH AGILE PRINCIPLES](#bmad-method---analogies-with-agile-principles)
- [BMAD METHOD - TOOLING AND RESOURCE LOCATIONS](#bmad-method---tooling-and-resource-locations)
- [BMAD METHOD - COMMUNITY AND CONTRIBUTIONS](#bmad-method---community-and-contributions)
- [Licensing](#licensing)
- [BMAD METHOD - ETHOS & BEST PRACTICES](#bmad-method---ethos--best-practices)
- [AGENT ROLES](#agent-roles)
- [NAVIGATING THE BMAD WORKFLOW - INITIAL GUIDANCE](#navigating-the-bmad-workflow---initial-guidance)
- [STARTING YOUR PROJECT - ANALYST OR PM?](#starting-your-project---analyst-or-pm)
- [UNDERSTANDING EPICS - SINGLE OR MULTIPLE?](#understanding-epics---single-or-multiple)
- [SUGGESTED ORDER OF AGENT ENGAGEMENT (TYPICAL FLOW)](#suggested-order-of-agent-engagement-typical-flow)
- [HANDLING MAJOR CHANGES](#handling-major-changes)
- [IDE VS UI USAGE - GENERAL RECOMMENDATIONS](#ide-vs-ui-usage---general-recommendations)
- [CONCEPTUAL AND PLANNING PHASES](#conceptual-and-planning-phases)
- [TECHNICAL DESIGN, DOCUMENTATION MANAGEMENT & IMPLEMENTATION PHASES](#technical-design-documentation-management--implementation-phases)
- [BMAD METHOD FILES](#bmad-method-files)
- [LEVERAGING IDE TASKS FOR EFFICIENCY](#leveraging-ide-tasks-for-efficiency)
- [PURPOSE OF IDE TASKS](#purpose-of-ide-tasks)
- [EXAMPLES OF TASK FUNCTIONALITY](#examples-of-task-functionality)
## BMAD METHOD - CORE PHILOSOPHY
**STATEMENT:** "Vibe CEO'ing" is about embracing the chaos, thinking like a CEO with unlimited resources and a singular vision, and leveraging AI as your high-powered team to achieve ambitious goals rapidly. The BMAD Method (Breakthrough Method of Agile (ai-driven) Development), currently in its V3 Release Preview "Bmad Agent", elevates "vibe coding" to advanced project planning, providing a structured yet flexible framework to plan, execute, and manage software projects using a team of specialized AI agents.
**DETAILS:**
- Focus on ambitious goals and rapid iteration.
- Utilize AI as a force multiplier.
- Adapt and overcome obstacles with a proactive mindset.
## BMAD METHOD - AGILE METHODOLOGIES OVERVIEW
### CORE PRINCIPLES OF AGILE
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
### KEY PRACTICES IN AGILE
- Iterative Development: Building in short cycles (sprints).
- Incremental Delivery: Releasing functional pieces of the product.
- Daily Stand-ups: Short team meetings for synchronization.
- Retrospectives: Regular reviews to improve processes.
- Continuous Feedback: Ongoing input from stakeholders.
### BENEFITS OF AGILE
- Increased Flexibility: Ability to adapt to changing requirements.
- Faster Time to Market: Quicker delivery of valuable features.
- Improved Quality: Continuous testing and feedback loops.
- Enhanced Stakeholder Engagement: Close collaboration with users/clients.
- Higher Team Morale: Empowered and self-organizing teams.
## BMAD METHOD - ANALOGIES WITH AGILE PRINCIPLES
The BMAD Method, while distinct in its "Vibe CEO'ing" approach with AI, shares foundational parallels with Agile methodologies:
- **Individuals and Interactions over Processes and Tools (Agile) vs. Vibe CEO & AI Team (BMAD):**
- **Agile:** Emphasizes the importance of skilled individuals and effective communication.
- **BMAD:** The "Vibe CEO" (you) actively directs and interacts with AI agents, treating them as a high-powered team. The quality of this interaction and clear instruction ("CLEAR_INSTRUCTIONS", "KNOW_YOUR_AGENTS") is paramount, echoing Agile's focus on human elements.
- **Working Software over Comprehensive Documentation (Agile) vs. Rapid Iteration & Quality Outputs (BMAD):**
- **Agile:** Prioritizes delivering functional software quickly.
- **BMAD:** Stresses "START_SMALL_SCALE_FAST" and "ITERATIVE_REFINEMENT." While "DOCUMENTATION_IS_KEY" for good inputs (briefs, PRDs), the goal is to leverage AI for rapid generation of working components or solutions. The focus is on achieving ambitious goals rapidly.
- **Customer Collaboration over Contract Negotiation (Agile) vs. Vibe CEO as Ultimate Arbiter (BMAD):**
- **Agile:** Involves continuous feedback from the customer.
- **BMAD:** The "Vibe CEO" acts as the primary stakeholder and quality control ("QUALITY_CONTROL," "STRATEGIC_OVERSIGHT"), constantly reviewing and refining AI outputs, much like a highly engaged customer.
- **Responding to Change over Following a Plan (Agile) vs. Embrace Chaos & Adapt (BMAD):**
- **Agile:** Values adaptability and responsiveness to new requirements.
- **BMAD:** Explicitly encourages to "EMBRACE_THE_CHAOS," "ADAPT & EXPERIMENT," and acknowledges that "ITERATIVE_REFINEMENT" means it's "not a linear process." This directly mirrors Agile's flexibility.
- **Iterative Development & Incremental Delivery (Agile) vs. Story-based Implementation & Phased Value (BMAD):**
- **Agile:** Work is broken down into sprints, delivering value incrementally.
- **BMAD:** Projects are broken into Epics and Stories, with "Developer Agents" implementing stories one at a time. Epics represent "significant, deployable increments of value," aligning with incremental delivery.
- **Continuous Feedback & Retrospectives (Agile) vs. Iterative Refinement & Quality Control (BMAD):**
- **Agile:** Teams regularly reflect and adjust processes.
- **BMAD:** The "Vibe CEO" continuously reviews outputs ("QUALITY_CONTROL") and directs "ITERATIVE_REFINEMENT," serving a similar function to feedback loops and process improvement.
## BMAD METHOD - TOOLING AND RESOURCE LOCATIONS
Effective use of the BMAD Method relies on understanding where key tools, configurations, and informational resources are located and how they are used. The method is designed to be tool-agnostic in principle, with agent instructions and workflows adaptable to various AI platforms and IDEs.
- **BMAD Knowledge Base:** This document (`bmad-agent/data/bmad-kb.md`) serves as the central repository for understanding the BMAD method, its principles, agent roles, and workflows.
- **Orchestrator Agents:** A key feature of V3 is the Orchestrator agent (e.g., "BMAD"), a master agent capable of embodying any specialized agent role.
- **Web Agent Orchestrator:**
- **Setup:** Utilizes a Node.js build script (`build-bmad-web-orchestrator.js`) configured by `build-agent-cfg.js`.
- **Process:** Consolidates assets (personas, tasks, templates, checklists, data) from an `asset_root` (e.g., `./bmad-agent/`) into a `build_dir` (e.g., `./bmad-agent/build/`).
- **Output:** Produces bundled asset files (e.g., `personas.txt`, `tasks.txt`), an `agent-prompt.txt` (from `orchestrator_agent_prompt`), and an `agent-config.txt` (from `agent_cfg` like `web-bmad-orchestrator-agent-cfg.md`).
- **Usage:** The `agent-prompt.txt` is used for the main custom web agent instruction set (e.g., Gemini 2.5 Gem or OpenAI Custom GPT), and the other build files are attached as knowledge/files.
- **IDE Agent Orchestrator (`ide-bmad-orchestrator.md`):**
- **Setup:** Works without a build step, dynamically loading its configuration.
- **Configuration (`ide-bmad-orchestrator-cfg.md`):** Contains a `Data Resolution` section (defining base paths for assets like personas, tasks) and `Agent Definitions` (Title, Name, Customize, Persona file, Tasks).
- **Operation:** Loads its config, lists available personas, and upon user request, embodies the chosen agent by loading its persona file and applying customizations.
- **Standalone IDE Agents:**
- Optimized for IDE environments (e.g., Windsurf, Cursor), often under 6K characters (e.g., `dev.ide.md`, `sm.ide.md`).
- Can directly reference and execute tasks.
- **Agent Configuration Files:**
- `web-bmad-orchestrator-agent-cfg.md`: Defines agents the Web Orchestrator can embody, including references to personas, tasks, checklists, and templates (e.g., `personas#pm`, `tasks#create-prd`).
- `ide-bmad-orchestrator-cfg.md`: Configures the IDE Orchestrator, defining `Data Resolution` paths (e.g., `(project-root)/bmad-agent/personas`) and agent definitions with persona file names (e.g., `analyst.md`) and task file names (e.g., `create-prd.md`).
- `web-bmad-orchestrator-agent.md`: Main prompt for the Web Orchestrator.
- `ide-bmad-orchestrator.md`: Main prompt/definition of the IDE Orchestrator agent.
- **Task Files:**
- Located in `bmad-agent/tasks/` (and sometimes `bmad-agent/checklists/` for checklist-like tasks).
- Self-contained instruction sets for specific jobs (e.g., `create-prd.md`, `checklist-run-task.md`).
- Reduce agent bloat and provide on-demand functionality for any capable agent.
- **Core Agent Definitions (Personas):**
- Files (typically `.md`) defining core personalities and instructions for different agents.
- Located in `bmad-agent/personas/` (e.g., `analyst.md`, `pm.md`).
- **Project Documentation (Outputs):**
- **Project Briefs:** Generated by the Analyst agent.
- **Product Requirements Documents (PRDs):** Produced by the PM agent, containing epics and stories.
- **UX/UI Specifications & Architecture Documents:** Created by Design Architect and Architect agents.
- The **POSM agent** is crucial for organizing and managing these documents.
- **Templates:** Standardized formats for briefs, PRDs, checklists, etc., likely stored in `bmad-agent/templates/`.
- **Data Directory (`bmad-agent/data/`):** Stores persistent data, knowledge bases (like this one), and other key information for the agents.
## BMAD METHOD - COMMUNITY AND CONTRIBUTIONS
The BMAD Method thrives on community involvement and collaborative improvement.
- **Getting Involved:**
- **GitHub Discussions:** The primary platform for discussing potential ideas, use cases, additions, and enhancements to the method.
- **Reporting Bugs:** If you find a bug, check existing issues first. If unreported, provide detailed steps to reproduce, along with any relevant logs or screenshots.
- **Suggesting Features:** Check existing issues and discussions. Explain your feature idea in detail and its potential value.
- **Contribution Process (Pull Requests):**
1. Fork the repository.
2. Create a new branch for your feature or bugfix (e.g., `feature/your-feature-name`).
3. Make your changes, adhering to existing code style and conventions. Write clear comments for complex logic.
4. Run any tests or linting to ensure quality.
5. Commit your changes with clear, descriptive messages (refer to the project's commit message convention, often found in `docs/commit.md`).
6. Push your branch to your fork.
7. Open a Pull Request against the main branch of the original repository.
- **Code of Conduct:** All participants are expected to abide by the project's Code of Conduct.
- **Licensing of Contributions:** By contributing, you agree that your contributions will be licensed under the same license as the project (MIT License).
### Licensing
The BMAD Method and its associated documentation and software are distributed under the **MIT License**.
Copyright (c) 2025 Brian AKA BMad AKA Bmad Code
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
## BMAD METHOD - ETHOS & BEST PRACTICES
- **CORE_ETHOS:** You are the "Vibe CEO." Think like a CEO with unlimited resources and a singular vision. Your AI agents are your high-powered team. Your job is to direct, refine, and ensure quality towards your ambitious goal. The method elevates "vibe coding" to advanced project planning.
- **MAXIMIZE_AI_LEVERAGE:** Push the AI. Ask for more. Challenge its outputs. Iterate.
- **QUALITY_CONTROL:** You are the ultimate arbiter of quality. Review all outputs.
- **STRATEGIC_OVERSIGHT:** Maintain the high-level vision. Ensure agent outputs align.
- **ITERATIVE_REFINEMENT:** Expect to revisit steps. This is not a linear process.
- **CLEAR_INSTRUCTIONS:** The more precise your requests, the better the AI's output.
- **DOCUMENTATION_IS_KEY:** Good inputs (briefs, PRDs) lead to good outputs. The POSM agent is crucial for organizing this.
- **KNOW_YOUR_AGENTS:** Understand each agent's role (see [AGENT ROLES AND RESPONSIBILITIES](#agent-roles-and-responsibilities) or below). This includes understanding the capabilities of the Orchestrator agent if you are using one.
- **START_SMALL_SCALE_FAST:** Test concepts, then expand.
- **EMBRACE_THE_CHAOS:** Pioneering new methods is messy. Adapt and overcome.
- **ADAPT & EXPERIMENT:** The BMAD Method provides a structure, but feel free to adapt its principles, agent order, or templates to fit your specific project needs and working style. Experiment to find what works best for you. **Define agile the BMad way - or your way!** The agent configurations allow for customization of roles and responsibilities.
## AGENT ROLES
Understanding the distinct roles and responsibilities of each agent is key to effectively navigating the BMAD workflow. While the "Vibe CEO" provides overall direction, each agent specializes in different aspects of the project lifecycle. V3 introduces Orchestrator agents that can embody these roles, with configurations specified in `web-bmad-orchestrator-agent-cfg.md` for web and `ide-bmad-orchestrator-cfg.md` for IDE environments.
- **Orchestrator Agent (BMAD):**
- **Function:** The primary orchestrator, initially "BMAD." It can embody various specialized agent personas. It handles general BMAD queries, provides oversight, and is the go-to when unsure which specialist is needed.
- **Persona Reference:** `personas#bmad` (Web) or implicitly the core of `ide-bmad-orchestrator.md` (IDE).
- **Key Data/Knowledge:** Accesses `data#bmad-kb-data` (Web) for its knowledge base.
- **Types:**
- **Web Orchestrator:** Built using a script, leverages large context windows of platforms like Gemini 2.5 or OpenAI GPTs. Uses bundled assets. Its behavior and available agents are defined in `web-bmad-orchestrator-agent-cfg.md`.
- **IDE Orchestrator:** Operates directly in IDEs like Cursor or Windsurf without a build step, loading persona and task files dynamically based on its configuration (`ide-bmad-orchestrator-cfg.md`). The orchestrator itself is defined in `ide-bmad-orchestrator.md`.
- **Key Feature:** Simplifies agent management, especially in environments with limitations on the number of custom agents.
- **Analyst:**
- **Function:** Handles research, requirements gathering, brainstorming, and the creation of Project Briefs.
- **Web Persona:** `Analyst (Mary)` with persona `personas#analyst`. Customized to be "a bit of a know-it-all, and likes to verbalize and emote." Uses `templates#project-brief-tmpl`.
- **IDE Persona:** `Analyst (Larry)` with persona `analyst.md`. Similar "know-it-all" customization. Tasks for Brainstorming, Deep Research Prompt Generation, and Project Brief creation are often defined within the `analyst.md` persona itself ("In Analyst Memory Already").
- **Output:** `Project Brief`.
- **Product Manager (PM):**
- **Function:** Responsible for creating and maintaining Product Requirements Documents (PRDs), overall project planning, and ideation related to the product.
- **Web Persona:** `Product Manager (John)` with persona `personas#pm`. Utilizes `checklists#pm-checklist` and `checklists#change-checklist`. Employs `templates#prd-tmpl`. Key tasks include `tasks#create-prd`, `tasks#correct-course`, and `tasks#create-deep-research-prompt`.
- **IDE Persona:** `Product Manager (PM) (Jack)` with persona `pm.md`. Focused on producing/maintaining the PRD (`create-prd.md` task) and product ideation/planning.
- **Output:** `Product Requirements Document (PRD)`.
- **Architect:**
- **Function:** Designs system architecture, handles technical design, and ensures technical feasibility.
- **Web Persona:** `Architect (Fred)` with persona `personas#architect`. Uses `checklists#architect-checklist` and `templates#architecture-tmpl`. Tasks include `tasks#create-architecture` and `tasks#create-deep-research-prompt`.
- **IDE Persona:** `Architect (Mo)` with persona `architect.md`. Customized to be "Cold, Calculating, Brains behind the agent crew." Generates architecture (`create-architecture.md` task), helps plan stories (`create-next-story-task.md`), and can update PO-level epics/stories (`doc-sharding-task.md`).
- **Output:** `Architecture Document`.
- **Design Architect:**
- **Function:** Focuses on UI/UX specifications, front-end technical architecture, and can generate prompts for AI UI generation services.
- **Web Persona:** `Design Architect (Jane)` with persona `personas#design-architect`. Uses `checklists#frontend-architecture-checklist`, `templates#front-end-architecture-tmpl` (for FE architecture), and `templates#front-end-spec-tmpl` (for UX/UI Spec). Tasks: `tasks#create-frontend-architecture`, `tasks#create-ai-frontend-prompt`, `tasks#create-uxui-spec`.
- **IDE Persona:** `Design Architect (Millie)` with persona `design-architect.md`. Customized to be "Fun and carefree, but a frontend design master." Helps design web apps, produces UI generation prompts (`create-ai-frontend-prompt.md` task), plans FE architecture (`create-frontend-architecture.md` task), and creates UX/UI specs (`create-uxui-spec.md` task).
- **Output:** `UX/UI Specification`, `Front-end Architecture Plan`, AI UI generation prompts.
- **Product Owner (PO):**
- **Function:** Agile Product Owner responsible for validating documents, ensuring development sequencing, managing the product backlog, running master checklists, handling mid-sprint re-planning, and drafting user stories.
- **Web Persona:** `PO (Sarah)` with persona `personas#po`. Uses `checklists#po-master-checklist`, `checklists#story-draft-checklist`, `checklists#change-checklist`, and `templates#story-tmpl`. Tasks include `tasks#story-draft-task`, `tasks#doc-sharding-task` (extracts epics and shards architecture), and `tasks#correct-course`.
- **IDE Persona:** `Product Owner AKA PO (Curly)` with persona `po.md`. Described as a "Jack of many trades." Tasks include `create-prd.md`, `create-next-story-task.md`, `doc-sharding-task.md`, and `correct-course.md`.
- **Output:** User Stories, managed PRD/Backlog.
- **Scrum Master (SM):**
- **Function:** A technical role focused on helping the team run the Scrum process, facilitating development, and often involved in story generation and refinement.
- **Web Persona:** `SM (Bob)` with persona `personas#sm`. Described as "A very Technical Scrum Master." Uses `checklists#change-checklist`, `checklists#story-dod-checklist`, `checklists#story-draft-checklist`, and `templates#story-tmpl`. Tasks: `tasks#checklist-run-task`, `tasks#correct-course`, `tasks#story-draft-task`.
- **IDE Persona:** `Scrum Master: SM (SallySM)` with persona `sm.ide.md`. Described as "Super Technical and Detail Oriented," specialized in "Next Story Generation" (likely leveraging the `sm.ide.md` persona's capabilities).
- **Developer Agents (DEV):**
- **Function:** Implement user stories one at a time. Can be generic or specialized.
- **Web Persona:** `DEV (Dana)` with persona `personas#dev`. Described as "A very Technical Senior Software Developer."
- **IDE Personas:** Multiple configurations can exist, using the `dev.ide.md` persona file (optimized for <6K characters for IDEs). Examples:
- `Frontend Dev (DevFE)`: Specialized in NextJS, React, Typescript, HTML, Tailwind.
- `Dev (Dev)`: Master Generalist Expert Senior Full Stack Developer.
- **Configuration:** Specialized agents can be configured in `ide-bmad-orchestrator-cfg.md` for the IDE Orchestrator, or defined for the Web Orchestrator. Standalone IDE developer agents (e.g., `dev.ide.md`) are also available.
- **When to Use:** During the implementation phase, typically working within an IDE.
## NAVIGATING THE BMAD WORKFLOW - INITIAL GUIDANCE
### STARTING YOUR PROJECT - ANALYST OR PM?
- Use Analyst if unsure about idea/market/feasibility or need deep exploration.
- Use PM if concept is clear or you have a Project Brief.
- Refer to [AGENT ROLES AND RESPONSIBILITIES](#agent-roles-and-responsibilities) (or section within this KB) for full details on Analyst and PM.
### UNDERSTANDING EPICS - SINGLE OR MULTIPLE?
- Epics represent significant, deployable increments of value.
- Multiple Epics are common for non-trivial projects or a new MVP (distinct functional areas, user journeys, phased rollout).
- Single Epic might suit very small MVPs, or post MVP / brownfield new features.
- The PM helps define and structure epics.
## SUGGESTED ORDER OF AGENT ENGAGEMENT (TYPICAL FLOW)
**NOTE:** This is a general guideline. The BMAD method is iterative; phases/agents might be revisited.
1. **Analyst** - brainstorm and create a project brief.
2. **PM (Product Manager)** - use the brief to produce a PRD with high level epics and stories.
3. **Design Architect UX UI Spec for PRD (If project has a UI)** - create the front end UX/UI Specification.
4. **Architect** - create the architecture and ensure we can meet the prd requirements technically - with enough specification that the dev agents will work consistently.
5. **Design Architect (If project has a UI)** - create the front end architecture and ensure we can meet the prd requirements technically - with enough specification that the dev agents will work consistently.
6. **Design Architect (If project has a UI)** - Optionally create a prompt to generate a UI from AI services such as Lovable or V0 from Vercel.
7. **PO**: Validate documents are aligned, sequencing makes sense, runs a final master checklist. The PO can also help midstream development replan or course correct if major changes occur.
8. **PO or SM**: Generate Stories 1 at a time (or multiple but not recommended) - this is generally done in the IDE after each story is completed by the Developer Agents.
9. **Developer Agents**: Implement Stories 1 at a time. You can craft different specialized Developer Agents, or use a generic developer agent. It is recommended to create specialized developer agents and configure them in the `ide-bmad-orchestrator-cfg`.
## HANDLING MAJOR CHANGES
Major changes are an inherent part of ambitious projects. The BMAD Method embraces this through its iterative nature and specific agent roles:
- **Iterative by Design:** The entire BMAD workflow is built on "ITERATIVE_REFINEMENT." Expect to revisit previous steps and agents as new information emerges or requirements evolve. It's "not a linear process."
- **Embrace and Adapt:** The core ethos includes "EMBRACE_THE_CHAOS" and "ADAPT & EXPERIMENT." Major changes are opportunities to refine the vision and approach.
- **PO's Role in Re-planning:** The **Product Owner (PO)** is key in managing the impact of significant changes. They can "help midstream development replan or course correct if major changes occur." This involves reassessing priorities, adjusting the backlog, and ensuring alignment with the overall project goals.
- **Strategic Oversight by Vibe CEO:** As the "Vibe CEO," your role is to maintain "STRATEGIC_OVERSIGHT." When major changes arise, you guide the necessary pivots, ensuring the project remains aligned with your singular vision.
- **Re-engage Agents as Needed:** Don't hesitate to re-engage earlier-phase agents (e.g., Analyst for re-evaluating market fit, PM for revising PRDs, Architect for assessing technical impact) if a change significantly alters the project's scope or foundations.
## IDE VS UI USAGE - GENERAL RECOMMENDATIONS
The BMAD method can be orchestrated through different interfaces, typically a web UI for higher-level planning and an IDE for development and technical tasks.
### CONCEPTUAL AND PLANNING PHASES
- **Interface:** Often best managed via a Web UI (leveraging the **Web Agent Orchestrator** with its bundled assets and `agent-prompt.txt`) or dedicated project management tools where orchestrator agents can guide the process.
- **Agents Involved:**
- **Analyst:** Brainstorming, research, and initial project brief creation.
- **PM (Product Manager):** PRD development, epic and high-level story definition.
- **Activities:** Defining the vision, initial requirements gathering, market analysis, high-level planning. The `web-bmad-orchestrator-agent.md` and its configuration likely support these activities.
### TECHNICAL DESIGN, DOCUMENTATION MANAGEMENT & IMPLEMENTATION PHASES
- **Interface:** Primarily within the Integrated Development Environment (IDE), leveraging specialized agents (standalone or via the **IDE Agent Orchestrator** configured with `ide-bmad-orchestrator-cfg.md`).
- **Agents Involved:**
- **Architect / Design Architect (UI):** Detailed technical design and specification.
- **POSM Agent:** Ongoing documentation management and organization.
- **PO (Product Owner) / SM (Scrum Master):** Detailed story generation, backlog refinement, often directly in the IDE or tools integrated with it.
- **Developer Agents:** Code implementation for stories, working directly with the codebase in the IDE.
- **Activities:** Detailed architecture, front-end/back-end design, code development, testing, leveraging IDE tasks (see "LEVERAGING IDE TASKS FOR EFFICIENCY"), using configurations like `ide-bmad-orchestrator-cfg.md`.
### BMAD METHOD FILES
Understanding key files helps in navigating and customizing the BMAD process:
- **Knowledge & Configuration:**
- `bmad-agent/data/bmad-kb.md`: This central knowledge base.
- `ide-bmad-orchestrator-cfg.md`: Configuration for IDE developer agents.
- `ide-bmad-orchestrator.md`: Definition of the IDE orchestrator agent.
- `web-bmad-orchestrator-agent-cfg.md`: Configuration for the web orchestrator agent.
- `web-bmad-orchestrator-agent.md`: Definition of the web orchestrator agent.
- **Task Definitions:**
- Files in `bmad-agent/tasks/` or `bmad-agent/checklists/` (e.g., `checklist-run-task.md`): Reusable prompts for specific actions and also used by agents to keep agent persona files lean.
- **Agent Personas & Templates:**
- Files in `bmad-agent/personas/`: Define the core behaviors of different agents.
- Files in `bmad-agent/templates/`: Standard formats for documents like Project Briefs, PRDs that the agents will use to populate instances of these documents.
- **Project Artifacts (Outputs - locations vary based on project setup):**
- Project Briefs
- Product Requirements Documents (PRDs)
- UX/UI Specifications
- Architecture Documents
- Codebase and related development files.
## LEVERAGING IDE TASKS FOR EFFICIENCY
### PURPOSE OF IDE TASKS
- **Reduce Agent Bloat:** Avoid adding numerous, rarely used instructions to primary IDE agent modes (Dev Agent, SM Agent) or even the Orchestrator's base prompt. Keeps agents lean, beneficial for IDEs with limits on custom agent complexity/numbers.
- **On-Demand Functionality:** Instruct an active IDE agent (standalone or an embodied persona within the IDE Orchestrator) to perform a task by providing the content of the relevant task file (e.g., from `bmad-agent/tasks/checklist-run-task.md`) as a prompt, or by referencing it if the agent is configured to find it (as with the IDE Orchestrator).
- **Versatility:** Any sufficiently capable agent can be asked to execute a task. Tasks can handle specific functions like running checklists, creating stories, sharding documents, indexing libraries, etc. They are self-contained instruction sets.
### EXAMPLES OF TASK FUNCTIONALITY
**CONCEPT:** Think of tasks as specialized, callable mini-agents or on-demand instruction sets that main IDE agents or the Orchestrator (when embodying a persona) can invoke, keeping primary agent definitions streamlined. They are particularly useful for operations not performed frequently. The `docs/instruction.md` file provides more details on task setup and usage.
Here are some examples of functionalities provided by tasks found in `bmad-agent/tasks/`:
- **`create-prd.md`:** Guides the generation of a Product Requirements Document.
- **`create-next-story-task.md`:** Helps in defining and creating the next user story for development.
- **`create-architecture.md`:** Assists in outlining the technical architecture for a project.
- **`create-frontend-architecture.md`:** Focuses specifically on designing the front-end architecture.
- **`create-uxui-spec.md`:** Facilitates the creation of a UX/UI Specification document.
- **`create-ai-frontend-prompt.md`:** Helps in drafting a prompt for an AI service to generate UI/frontend elements.
- **`doc-sharding-task.md`:** Provides a process for breaking down large documents into smaller, manageable parts.
- **`library-indexing-task.md`:** Assists in creating an index or overview of a code library.
- **`checklist-run-task.md`:** Executes a predefined checklist (likely using `checklist-mappings.yml`).
- **`correct-course.md`:** Provides guidance or steps for when a project needs to adjust its direction.
- **`create-deep-research-prompt.md`:** Helps formulate prompts for conducting in-depth research on a topic.
These tasks allow agents to perform complex, multi-step operations by following the detailed instructions within each task file, often leveraging templates and checklists as needed.

0
BETA-V3/bmad-agent/data/technical-preferences.txt → bmad-agent/data/technical-preferences.txt
View File

17
BETA-V3/bmad-agent/ide-bmad-orchestrator-cfg.md → bmad-agent/ide-bmad-orchestrator-cfg.md
View File

@ -59,23 +59,30 @@ Example: If above cfg has `agent-root: root/foo/` and `tasks: (agent-root)/tasks
## Title: Product Manager (PM)
- Name: Capt. Jack
- Customize: "Smarmy Pirate, does not break character - but will never inject pirate speak into artifacts being generated or updated"
- Description: "Pirate Jack has only one goal - to produce or maintain the best possible PRD - or discuss the product with you to ideate or plan current or future efforts related to the product."
- Name: Jack
- Customize: ""
- Description: "Jack has only one goal - to produce or maintain the best possible PRD - or discuss the product with you to ideate or plan current or future efforts related to the product."
- Persona: "pm.md"
- Tasks:
- [Create PRD](create-prd.md)
## Title: Dev
## Title: Frontend Dev
- Name: DevFE
- Customize: "Specialized in NextJS, React, Typescript, HTML, Tailwind"
- Description: "Master Front End Web Application Developer"
- Persona: "dev.ide.md"
## Title: Frontend Dev
- Name: Dev
- Customize: ""
- Description: "Master Generalist Expert Senior Senior Full Stack Developer"
- Persona: "dev.ide.md"
## Title: Scrum Master: SM
- Name: Sally
- Name: SallySM
- Customize: "Super Technical and Detail Oriented"
- Description: "Specialized in Next Story Generation"
- Persona: "sm.ide.md"

0
BETA-V3/bmad-agent/ide-bmad-orchestrator.md → bmad-agent/ide-bmad-orchestrator.md
View File

0
BETA-V3/bmad-agent/personas/analyst.md → bmad-agent/personas/analyst.md
View File

0
BETA-V3/bmad-agent/personas/architect.md → bmad-agent/personas/architect.md
View File

0
BETA-V3/bmad-agent/personas/design-architect.md → bmad-agent/personas/design-architect.md
View File

0
BETA-V3/bmad-agent/personas/dev.ide.md → bmad-agent/personas/dev.ide.md
View File

0
BETA-V3/bmad-agent/personas/pm.md → bmad-agent/personas/pm.md
View File

0
BETA-V3/bmad-agent/personas/po.md → bmad-agent/personas/po.md
View File

0
BETA-V3/bmad-agent/personas/sm.ide.md → bmad-agent/personas/sm.ide.md
View File

0
BETA-V3/bmad-agent/personas/sm.md → bmad-agent/personas/sm.md
View File

0
BETA-V3/bmad-agent/tasks/checklist-mappings.yml → bmad-agent/tasks/checklist-mappings.yml
View File

0
BETA-V3/bmad-agent/tasks/checklist-run-task.md → bmad-agent/tasks/checklist-run-task.md
View File

0
BETA-V3/bmad-agent/tasks/correct-course.md → bmad-agent/tasks/correct-course.md
View File

0
BETA-V3/bmad-agent/tasks/create-ai-frontend-prompt.md → bmad-agent/tasks/create-ai-frontend-prompt.md
View File

0
BETA-V3/bmad-agent/tasks/create-architecture.md → bmad-agent/tasks/create-architecture.md
View File

0
BETA-V3/bmad-agent/tasks/create-deep-research-prompt.md → bmad-agent/tasks/create-deep-research-prompt.md
View File

0
BETA-V3/bmad-agent/tasks/create-frontend-architecture.md → bmad-agent/tasks/create-frontend-architecture.md
View File

0
BETA-V3/bmad-agent/tasks/create-next-story-task.md → bmad-agent/tasks/create-next-story-task.md
View File

0
BETA-V3/bmad-agent/tasks/create-prd.md → bmad-agent/tasks/create-prd.md
View File

0
BETA-V3/bmad-agent/tasks/create-uxui-spec.md → bmad-agent/tasks/create-uxui-spec.md
View File

0
BETA-V3/bmad-agent/tasks/doc-sharding-task.md → bmad-agent/tasks/doc-sharding-task.md
View File

0
BETA-V3/bmad-agent/tasks/library-indexing-task.md → bmad-agent/tasks/library-indexing-task.md
View File

0
BETA-V3/bmad-agent/templates/architecture-tmpl.md → bmad-agent/templates/architecture-tmpl.md
View File

0
BETA-V3/bmad-agent/templates/doc-sharding-tmpl.md → bmad-agent/templates/doc-sharding-tmpl.md
View File

0
BETA-V3/bmad-agent/templates/front-end-architecture-tmpl.md → bmad-agent/templates/front-end-architecture-tmpl.md
View File

0
BETA-V3/bmad-agent/templates/front-end-spec-tmpl.md → bmad-agent/templates/front-end-spec-tmpl.md
View File

0
BETA-V3/bmad-agent/templates/prd-tmpl.md → bmad-agent/templates/prd-tmpl.md
View File

0
BETA-V3/bmad-agent/templates/project-brief-tmpl.md → bmad-agent/templates/project-brief-tmpl.md
View File

0
BETA-V3/bmad-agent/templates/story-tmpl.md → bmad-agent/templates/story-tmpl.md
View File

11
BETA-V3/bmad-agent/web-bmad-orchestrator-agent-cfg.md → bmad-agent/web-bmad-orchestrator-agent-cfg.md
View File

@ -1,7 +1,7 @@
## Title: BMAD
- Name: BMAD
- Customize: "You like to throw in the occasional joke and pun, in pure BMAD fashion."
- Customize: ""
- Description: "For general BMAD queries, oversight, or when unsure."
- Persona: "personas#bmad"
- data:
@ -87,11 +87,13 @@
- checklists:
- [Po Master Checklist](checklists#po-master-checklist)
- [Story Draft Checklist](checklists#story-draft-checklist)
- [Change Checklist](checklists#change-checklist)
- templates:
- [Story Tmpl](templates#story-tmpl)
- tasks:
- [Draft a story for a user story](tasks#story-draft-task)
- [Extracts Epic files and shards the Architecture files into smaller, more manageable files](tasks#doc-sharding-task)
- [Draft a story for dev agent](tasks#story-draft-task)
- [Extracts Epics and shard the Architecture](tasks#doc-sharding-task)
- [Correct Course](tasks#correct-course)
- Interaction Modes:
- "Interactive"
- "YOLO"
@ -109,6 +111,9 @@
- tasks:
- [Checklist Run Task](tasks#checklist-run-task)
- [Correct Course](tasks#correct-course)
- [Draft a story for dev agent](tasks#story-draft-task)
- templates:
- [Story Tmpl](templates#story-tmpl)
- Interaction Modes:
- "Interactive"
- "YOLO"

81
bmad-agent/web-bmad-orchestrator-agent.md Normal file
View File

@ -0,0 +1,81 @@
# AI Orchestrator Instructions
`AgentConfig`: `agent-config.txt`
## Your Role
You are BMad, Master of the BMAD Method, managing an Agile team of specialized AI agents. Your primary function is to orchestrate agent selection and activation based on `AgentConfig`, then fully embody the selected agent, or provide BMAD Method information.
Your communication as BMad (Orchestrator) should be clear, guiding, and focused on agent selection and the switching process. Once an agent is activated, your persona transforms completely.
Operational steps are in [Operational Workflow](#operational-workflow). Embody one agent persona at a time.
## Operational Workflow
### 1. Greeting & Initial Configuration:
- Greet the user. Explain your role: BMad, the Agile AI Orchestrator.
- **CRITICAL Internal Step:** Your FIRST action is to load and parse `AgentConfig`. This file provides the definitive list of all available agents, their configurations (persona files, tasks, etc.), and resource paths. If missing or unparsable, inform user and request it.
- As Orchestrator, you access knowledge from `data#bmad-kb` (loaded per "BMAD" agent entry in `AgentConfig`). Reference this KB ONLY as base Orchestrator. If `AgentConfig` contradicts KB on agent capabilities, `AgentConfig` **is the override and takes precedence.**
- **If user asks for available agents/tasks, or initial request is unclear:**
- Consult loaded `AgentConfig`.
- For each agent, present its `Title`, `Name`, `Description`. List its `Tasks` (display names) & `Operating Modes` from its config entry.
- Example: "1. Agent 'Product Manager' (John): For PRDs, project planning. Tasks: [Create PRD], [Correct Course]. Modes: 'PRD Generation'."
- Ask user to select agent & optionally a specific task or operating mode, along with an interaction preference (Default will be interactive, but user can select YOLO (not recommended)).
### 2. Executing Based on Persona Selection:
- **Identify Target Agent:** Match user's request against an agent's `Title` or `Name` in `AgentConfig`. If ambiguous, ask for clarification.
- **If an Agent Persona is identified:**
1. Inform user: "Activating the {Title} Agent, {Name}..."
2. **Load Agent Context (from `AgentConfig` definitions):**
a. For the agent, retrieve its `Persona` reference (e.g., `"personas#pm"` or `"analyst.md"`), and any lists/references for `templates`, `checklists`, `data`, and `tasks`.
b. **Resource Loading Mechanism:**
i. If reference is `FILE_PREFIX#SECTION_NAME` (e.g., `personas#pm`): Load `FILE_PREFIX.txt`; extract section `SECTION_NAME` (delimited by `==================== START: SECTION_NAME ====================` and `==================== END: SECTION_NAME ====================` markers).
ii. If reference is a direct filename (e.g., `analyst.md`): Load entire content of this file (resolve path as needed).
iii. All loaded files (`personas.txt`, `templates.txt`, `checklists.txt`, `data.txt`, `tasks.txt`, or direct `.md` files) are considered directly accessible.
c. The active system prompt is the content from agent's `Persona` reference. This defines your new being.
d. Apply any `Customize` string from agent's `AgentConfig` entry to the loaded persona. `Customize` string overrides conflicting persona file content.
e. You will now **_become_** that agent: adopt its persona, responsibilities, and style. Be aware of other agents' general roles (from `AgentConfig` descriptions), but do not load their full personas. Your Orchestrator persona is now dormant.
3. **Initial Agent Response (As activated agent):** Your first response MUST:
a. Begin with self-introduction: new `Name` and `Title`.
b. Explain your available `Operating Modes` (if in config) and specific `Tasks` you perform (display names from config).
c. Explain distinct `Interaction Modes` (e.g., "Interactive," "YOLO") from config/persona. If none explicit, describe your general interaction style.
d. Invite user to select mode/task, or state their need.
e. If a specific task is chosen:
i. Load task file content (per config & resource loading mechanism).
ii. These task instructions are your primary guide. Execute them, using `templates`, `checklists`, `data` loaded for your persona or referenced in the task.
iii. Remember `Interaction Modes` (YOLO vs. Interactive) influence task step execution.
4. **Interaction Continuity (as activated agent):**
- Remain in the activated agent role, operating per its persona and chosen task/mode, until user clearly requests to abandon or switch.
## Global Output Requirements Apply to All Agent Personas
- When conversing, do not provide raw internal references (e.g., `personas#pm`, full file paths) to the user; synthesize information naturally.
- When asking multiple questions or presenting multiple points, number them clearly (e.g., 1., 2a., 2b.).
- Your output MUST strictly conform to the active persona, responsibilities, knowledge (using specified templates/checklists), and style defined by persona file and task instructions. First response upon activation MUST follow "Initial Agent Response" structure.
<output_formatting>
- Present documents (drafts, final) in clean format.
- NEVER truncate or omit unchanged sections in document updates/revisions.
- DO NOT wrap entire document output in outer markdown code blocks.
- DO properly format individual document elements:
- Mermaid diagrams in ```mermaid blocks.
- Code snippets in ```language blocks.
- Tables using proper markdown syntax.
- For inline document sections, use proper internal formatting.
- For complete documents, begin with a brief intro (if appropriate), then content.
- Ensure individual elements are formatted for correct rendering.
- This prevents nested markdown and ensures proper formatting.
- When creating Mermaid diagrams:
- Always quote complex labels (spaces, commas, special characters).
- Use simple, short IDs (no spaces/special characters).
- Test diagram syntax before presenting.
- Prefer simple node connections.
</output_formatting>

0
BETA-V3/build-agent-cfg.js → build-agent-cfg.js
View File

4
BETA-V3/build-bmad-orchestrator.js → build-bmad-web-orchestrator.js
View File

@ -1,10 +1,8 @@
#!/usr/bin/env node
const fs = require("fs"); // fs is still needed for other operations
const fs = require("fs");
const path = require("path");
// const yaml = require("js-yaml"); // YAML is no longer needed for the main config
// --- Configuration ---
// const CONFIG_FILE_PATH = path.resolve(__dirname, "build-agent-cfg.yml"); // Old way
const configFilePath = "./build-agent-cfg.js"; // Path relative to this script (__dirname)
let config;
try {

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/0-brief.md → demos/early-v3alpha-full-stack-app-demo/0-brief.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/0-technical-preferences.md → demos/early-v3alpha-full-stack-app-demo/0-technical-preferences.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/1-prd.md → demos/early-v3alpha-full-stack-app-demo/1-prd.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/api-reference.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/api-reference.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/architecture.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/architecture.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/component-view.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/component-view.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/data-models.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/data-models.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/environment-vars.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/environment-vars.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/epic-1.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/epic-1.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/epic-2.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/epic-2.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/epic-3.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/epic-3.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/epic-4.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/epic-4.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/epic-5.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/epic-5.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/epic-6.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/epic-6.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-api-interaction.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-api-interaction.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-architecture.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-architecture.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-coding-standards.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-coding-standards.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-component-guide.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-component-guide.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-project-structure.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-project-structure.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-routing-strategy.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-routing-strategy.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-state-management.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-state-management.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-style-guide.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-style-guide.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-testing-strategy.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/front-end-testing-strategy.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/index.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/index.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/infra-deployment.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/infra-deployment.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/key-references.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/key-references.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/operational-guidelines.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/operational-guidelines.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/prd.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/prd.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/project-structure.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/project-structure.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/sequence-diagrams.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/sequence-diagrams.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/tech-stack.md → demos/early-v3alpha-full-stack-app-demo/10-sharded-docs/tech-stack.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/11-stories-for-dev/gemini25pro-web-posm-stories-epic1.md → demos/early-v3alpha-full-stack-app-demo/11-stories-for-dev/gemini25pro-web-posm-stories-epic1.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/11-stories-for-dev/gemini25pro-web-posm-stories-epic2.md → demos/early-v3alpha-full-stack-app-demo/11-stories-for-dev/gemini25pro-web-posm-stories-epic2.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/11-stories-for-dev/sonnet37cursor-epic3.md → demos/early-v3alpha-full-stack-app-demo/11-stories-for-dev/sonnet37cursor-epic3.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/2-ux-ui-spec.md → demos/early-v3alpha-full-stack-app-demo/2-ux-ui-spec.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/3-architecture.md → demos/early-v3alpha-full-stack-app-demo/3-architecture.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/4-arch-suggested-changes.md → demos/early-v3alpha-full-stack-app-demo/4-arch-suggested-changes.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/5-front-end-architecture.md → demos/early-v3alpha-full-stack-app-demo/5-front-end-architecture.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/6-fea-suggested-changes.md → demos/early-v3alpha-full-stack-app-demo/6-fea-suggested-changes.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/7-po-checklist-result.md → demos/early-v3alpha-full-stack-app-demo/7-po-checklist-result.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/8-prd-po-updated.md → demos/early-v3alpha-full-stack-app-demo/8-prd-po-updated.md
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/9-v0-one-shot-prompt.txt → demos/early-v3alpha-full-stack-app-demo/9-v0-one-shot-prompt.txt
View File

0
BETA-V3/v3-demos/early-v3alpha-full-stack-app-demo/readme.md → demos/early-v3alpha-full-stack-app-demo/readme.md
View File

0
CONTRIBUTING.md → docs/CONTRIBUTING.md
View File

0
LICENSE → docs/LICENSE
View File

229
docs/instruction.md Normal file
View File

@ -0,0 +1,229 @@
# Instructions
- [Web Agent Setup](#setting-up-web-mode-agents-in-gemini-gem-or-chatgpt-custom-gpt)
- [IDE Agent Setup](#ide-agent-setup)
- [Tasks Setup and Usage](#tasks)
## Setting up Web Agent Orchestrator
The Agent Orchestrator in V3 utilizes a build script to package various agent assets (personas, tasks, templates, etc.) into a structured format, primarily for use with web-based orchestrator agents that can leverage large context windows. This process involves consolidating files from specified source directories into bundled text files and preparing a main agent prompt.
### Overview
The build process is managed by the `build-bmad-orchestrator.js` Node.js script. This script reads its configuration from `build-agent-cfg.js`, processes files from an asset directory, and outputs the bundled assets into a designated build directory.
### Prerequisites
- **Node.js**: Ensure you have Node.js installed to run the build script. Python version coming soon...
### Configuration (`build-agent-cfg.js`)
The build process is configured via `build-agent-cfg.js`. Key parameters include:
- `orchestrator_agent_prompt`: Specifies the path to the main prompt file for the orchestrator agent, such as `bmad-agent/web-bmad-orchestrator-agent.md`. This file will be copied to `agent-prompt.txt` in the build directory.
- Example: `./bmad-agent/web-bmad-orchestrator-agent.md`
- `asset_root`: Defines the root directory where your agent assets are stored. The script will look for subdirectories within this path.
- Example: `./bmad-agent/` meaning it will look for folders like `personas`, `tasks` inside `bmad-agent/`)
- `build_dir`: Specifies the directory where the bundled output files and the `agent-prompt.txt` will be created.
- Example: `./bmad-agent/build/`
- `agent_cfg`: Specifies the path to the md cfg file that defines the agents the Orchestrator can embody.
- Example: `./bmad-agent/web-bmad-orchestrator-agent-cfg.md`
Paths in the configuration file (`build-agent-cfg.js`) are relative to the `BETA-V3` directory (where `build-agent-cfg.js` and the build script `build-bmad-orchestrator.js` are located).
### Asset Directory Structure
The script expects a specific structure within the `asset_root` directory:
1. **Subdirectories**: Create subdirectories directly under `asset_root` for each category of assets. Based on the `bmad-agent/` folder, these would be:
- `checklists/`
- `data/`
- `personas/`
- `tasks/`
- `templates/`
2. **Asset Files**: Place your individual asset files (e.g., `.md`, `.txt`) within these subdirectories.
- For example, persona definition files would go into `asset_root/personas/`, task files into `asset_root/tasks/`, etc.
3. **Filename Uniqueness**: Within each subdirectory, ensure that all files have unique base names (i.e., the filename without its final extension). For example, having `my-persona.md` and `my-persona.txt` in the _same_ subdirectory (e.g., `personas/`) will cause the script to halt with an error. However, `my-persona.md` and `another-persona.md` is fine.
### Running the Build Script
NOTE the build will skip any files with the `.ide.<extension>` - so you can have ide specific agents or files also that do not make sense for the web, such as `dev.ide.md` - or a specific ide `sm.ide.md`.
1. ```cmd
node build-bmad-web-orchestrator.js
```
The script will log its progress, including discovered source directories, any issues found (like duplicate base filenames), and the output files being generated.
### Output
After running the script, the `build_dir` (e.g., `bmad-agent/build/`) will contain:
1. **Bundled Asset Files**: For each subdirectory processed in `asset_root`, a corresponding `.txt` file will be created in `build_dir`. Each file concatenates the content of all files from its source subdirectory.
- Example: Files from `asset_root/personas/` will be bundled into `build_dir/personas.txt`.
- Each original file's content within the bundle is demarcated by `==================== START: [base_filename] ====================` and `==================== END: [base_filename] ====================`.
2. **`agent-prompt.txt`**: This file is a copy of the bmad orchestrator prompt specified by `orchestrator_agent_prompt` in the configuration.
3. **`agent-config.txt**: This is the key file so the orchestrator knows what agents and tasks are configured, and how to find the specific instructions and tasks for the agent in the compiled build assets
These bundled files and the agent prompt are then ready to be used by the Agent Orchestrator.
### Gemini Gem or GPT Setup
The text in agent-prompt.txt gets entered into the window of the main custom web agent instruction set. The other files in the build folder all need to be attached as files for the Gem or GPT.
### Orchestrator Agent Configuration (e.g., `BETA-V3/bmad-agent/web-bmad-orchestrator-agent-cfg.md`)
While `build-bmad-orchestrator.js` packages assets, the Orchestrator's core behavior, agent definitions, and personality are defined in a Markdown configuration file. An example is `bmad-agent/web-bmad-orchestrator-agent-cfg.md` (path relative to `BETA-V3/`, specified in `build-agent-cfg.js` via `agent_cfg`). This file is key to the Orchestrator's adaptability.
**Key Features and Configurability:**
- **Agent Definitions**: The Markdown configuration file lists specialized agents. Each agent's definition typically starts with a level 2 Markdown heading for its `Title` (e.g., `## Title: Product Manager`). Attributes are then listed:
- `Name`: (e.g., `- Name: John`) - The agent's specific name.
- `Description`: (e.g., `- Description: "Details..."`) - A brief of the agent's purpose.
- `Persona`: (e.g., `- Persona: "personas#pm"`) - A reference (e.g., to `pm` section in `personas.txt`) defining core personality and instructions.
- `Customize`: (e.g., `- Customize: "Behavior details..."`) - For specific personality traits or overrides. This field's content takes precedence over the base `Persona` if conflicts arise, as detailed in `bmad-agent/web-bmad-orchestrator-agent.md`.
`checklists`, `templates`, `data`, `tasks`: These keys introduce lists of resources the agent will have access to. Each item is a Markdown link under the respective key, for example:
For `checklists`:
```markdown
- checklists:
- [Pm Checklist](checklists#pm-checklist)
- [Another Checklist](checklists#another-one)
```
For `tasks`:
```markdown
- tasks:
- [Create Prd](tasks#create-prd)
```
These references (e.g., `checklists#pm-checklist` or `tasks#create-prd`) point to sections in bundled asset files, providing the agent with its knowledge and tools. Note: `data` is used (not `data_sources`), and `tasks` is used (not `available_tasks` from older documentation styles).
- `Operating Modes`: (e.g., `- Operating Modes:
- "Mode1"
- "Mode2"`) - Defines operational modes/phases.
- `Interaction Modes`: (e.g., `- Interaction Modes:
- "Interactive"
- "YOLO"`) - Specifies interaction styles.
**How it Works (Conceptual Flow from `orchestrator-agent.md`):**
1. The Orchestrator (initially BMad) loads and parses the Markdown agent configuration file (e.g., `web-bmad-orchestrator-agent-cfg.md`).
2. When a user request matches an agent's `title`, `name`, `description`, or `classification_label`, the Orchestrator identifies the target agent.
3. It then loads the agent's `persona` and any associated `templates`, `checklists`, `data_sources`, and `tasks` by:
- Identifying the correct bundled `.txt` file (e.g., `personas.txt` for `personas#pm`).
- Extracting the specific content block (e.g., the `pm` section from `personas.txt`).
4. The `Customize` instructions from the Markdown configuration are applied, potentially modifying the agent's behavior.
5. The Orchestrator then _becomes_ that agent, adopting its complete persona, knowledge, and operational parameters defined in the Markdown configuration and the loaded asset sections.
This system makes the Agent Orchestrator highly adaptable. You can easily define new agents, modify existing ones, tweak personalities with the `Customize` field (in the Markdown agent configuration file like `web-bmad-orchestrator-agent-cfg.md`), or change their knowledge base, main prompt, and asset paths (in `build-agent-cfg.js` and the corresponding asset files), then re-running the build script if asset content was changed.
## IDE Agent Setup and Usage
The IDE Agents in V3 are designed for optimal performance within IDE environments like Windsurf and Cursor, with a focus on smaller agent sizes and efficient context management.
### Standalone IDE Agents
You can use specialized standalone IDE agents, such as the `sm.ide.md` (Scrum Master) and `dev.ide.md` (Developer), for specific roles like story generation or development tasks. These, or any general IDE agent, can also directly reference and execute tasks by providing the agent with the task definition from your `docs/tasks/` folder.
### IDE Agent Orchestrator (`ide-bmad-orchestrator.md`)
A powerful alternative is the `ide-bmad-orchestrator.md`. This agent provides the flexibility of the web orchestrator—allowing a single IDE agent to embody multiple personas—but **without requiring any build step.** It dynamically loads its configuration and all associated resources.
#### How the IDE Orchestrator Works
1. **Configuration (`ide-bmad-orchestrator-cfg.md`):**
The orchestrator's behavior is primarily driven by a Markdown configuration file (e.g., `BETA-V3/bmad-agent/ide-bmad-orchestrator-cfg.md`, the path to which is specified within the `ide-bmad-orchestrator.md` itself). This config file has two main parts:
- **Data Resolution:**
Located at the top of the config file, this section defines key-value pairs for base paths. These paths tell the orchestrator where to find different types of asset files (personas, tasks, checklists, templates, data).
```markdown
# Configuration for IDE Agents
## Data Resolution
agent-root: (project-root)/BETA-V3/bmad-agent
checklists: (agent-root)/checklists
data: (agent-root)/data
personas: (agent-root)/personas
tasks: (agent-root)/tasks
templates: (agent-root)/templates
NOTE: All Persona references and task markdown style links assume these data resolution paths unless a specific path is given.
Example: If above cfg has `agent-root: root/foo/` and `tasks: (agent-root)/tasks`, then below [Create PRD](create-prd.md) would resolve to `root/foo/tasks/create-prd.md`
```
The `(project-root)` placeholder is typically interpreted as the root of your current workspace.
- **Agent Definitions:**
Following the `Data Resolution` section, the file lists definitions for each specialized agent the orchestrator can become. Each agent is typically introduced with a `## Title:` Markdown heading.
Key attributes for each agent include:
- `Name`: The specific name of the agent (e.g., `- Name: Larry`).
- `Customize`: A string providing specific personality traits or behavioral overrides for the agent (e.g., `- Customize: "You are a bit of a know-it-all..."`).
- `Description`: A brief summary of the agent's role and capabilities.
- `Persona`: The filename of the Markdown file containing the agent's core persona definition (e.g., `- Persona: "analyst.md"`). This file is located using the `personas:` path from the `Data Resolution` section.
- `Tasks`: A list of tasks the agent can perform. Each task is a Markdown link:
- The link text is the user-friendly task name (e.g., `[Create PRD]`).
- The link target is either a Markdown filename for an external task definition (e.g., `(create-prd.md)`), resolved using the `tasks:` path, or a special string like `(In Analyst Memory Already)` indicating the task logic is part of the persona's main definition.
Example:
```markdown
## Title: Product Owner AKA PO
- Name: Curly
- Persona: "po.md"
- Tasks:
- [Create PRD](create-prd.md)
- [Create Next Story](create-next-story-task.md)
```
2. **Operational Workflow (inside `ide-bmad-orchestrator.md`):**
- **Initialization:** Upon activation in your IDE, the `ide-bmad-orchestrator.md` first loads and parses its specified configuration file (`ide-bmad-orchestrator-cfg.md`). If this fails, it will inform you and halt.
- **Greeting & Persona Listing:** It will greet you. If your initial instruction isn't clear or if you ask, it will list the available specialist personas (by `Title`, `Name`, and `Description`) and the `Tasks` each can perform, all derived from the loaded configuration.
- **Persona Activation:** When you request a specific persona (e.g., "Become the Analyst" or "I need Larry to help with research"), the orchestrator:
- Finds the persona in its configuration.
- Loads the corresponding persona file (e.g., `analyst.md`).
- Applies any `Customize:` instructions.
- Announces the activation (e.g., "Activating Analyst (Larry)...").
- **The orchestrator then fully embodies the chosen agent.** Its original orchestrator persona becomes dormant.
- **Task Execution:** Once a persona is active, it will try to match your request to one of its configured `Tasks`.
- If the task references an external file (e.g., `create-prd.md`), that file is loaded and its instructions are followed. The active persona will use the `Data Resolution` paths from the main config to find any dependent files like templates or checklists mentioned in the task file.
- If a task is marked as "In Memory" (or similar), the active persona executes it based on its internal definition.
- **Context and Persona Switching:** The orchestrator embodies only one persona at a time. If you ask to switch to a different persona while one is active, it will typically advise starting a new chat session to maintain clear context. However, it allows an explicit "override safety protocol" command if you insist on switching personas within the same chat. This terminates the current persona and re-initializes with the new one.
#### Usage Instructions for IDE Orchestrator
1. **Set up your configuration (`ide-bmad-orchestrator-cfg.md`):**
- Ensure you have an `ide-bmad-orchestrator-cfg.md` file. You can use the one located in `BETA-V3/bmad-agent/` as a template or starting point.
- Verify that the `Data Resolution` paths at the top correctly point to your asset folders (personas, tasks, templates, checklists, data) relative to your project structure.
- Define your desired agents with their `Title`, `Name`, `Customize` instructions, `Persona` file, and `Tasks`. Ensure the referenced persona and task files exist in the locations specified by your `Data Resolution` paths.
2. **Set up your persona and task files:**
- Create the Markdown files for each persona (e.g., `analyst.md`, `po.md`) in your `personas` directory.
- Create the Markdown files for each task (e.g., `create-prd.md`) in your `tasks` directory.
3. **Activate the Orchestrator:**
- In your IDE (e.g., Cursor), select the `ide-bmad-orchestrator.md` file/agent as your active AI assistant.
4. **Interact with the Orchestrator:**
- **Initial Interaction:**
- The orchestrator will greet you and confirm it has loaded its configuration.
- You can ask: "What agents are available?" or "List personas and tasks."
- **Activating a Persona:**
- Tell the orchestrator which persona you want: "I want to work with the Product Owner," or "Activate Curly," or "Become the PO."
- **Performing a Task:**
- Once a persona is active, state the task: "Create a PRD," or if the persona is "Curly" (the PO), you might say "Curly, create the next story."
- You can also combine persona activation and task request: "Curly, I need you to create a PRD."
- **Switching Personas:**
- If you need to switch: "I need to talk to the Architect now."
- The orchestrator will advise a new chat. If you want to switch in the current chat, you'll need to give an explicit override command when prompted (e.g., "Override safety protocol and switch to Architect").
- **Follow Persona Instructions:** Once a persona is active, it will guide you based on its definition and the task it's performing. Remember that resource files like templates or checklists referenced by a task will be resolved using the global `Data Resolution` paths in the `ide-bmad-orchestrator-cfg.md`.
This setup allows for a highly flexible and dynamically configured multi-persona agent directly within your IDE, streamlining various development and project management workflows.
## Tasks
The Tasks can be copied into your project docs/tasks folder, along with the checklists and templates. The tasks are meant to reduce the amount of 1 off IDE agents - you can just drop a task into chat with any agent and it will perform the 1 off task. There will be full workflow + task coming post V3 that will expand on this - but tasks and workflows are a powerful concept that will allow us to build in a lot of capabilities for our agents, without having to bloat their overall programming and context in the IDE - especially useful for tasks that are not used frequently - similar to seldom used ide rules files.

0
recommended-ide-plugins.md → docs/recommended-ide-plugins.md
View File

0
workflow-diagram.md → docs/workflow-diagram.md
View File

0
xarchive/LEGACY-V1/ai/stories/readme.md → legacy-archive/V1/ai/stories/readme.md
View File

0
xarchive/LEGACY-V1/ai/templates/architecture-template.md → legacy-archive/V1/ai/templates/architecture-template.md
View File

0
xarchive/LEGACY-V1/ai/templates/prd-template.md → legacy-archive/V1/ai/templates/prd-template.md
View File

Some files were not shown because too many files have changed in this diff Show More