diff --git a/dist/agents/analyst.txt b/bundles/agents/analyst.txt similarity index 99% rename from dist/agents/analyst.txt rename to bundles/agents/analyst.txt index 0fd0ddccc..4ba809e0c 100644 --- a/dist/agents/analyst.txt +++ b/bundles/agents/analyst.txt @@ -149,7 +149,7 @@ If user selects Option 1, present numbered list of techniques from the brainstor 1. Apply selected technique according to data file description 2. Keep engaging with technique until user indicates they want to: - Choose a different technique - - Apply current ideas to a new technique + - Apply current ideas to a new technique - Move to convergent phase - End session @@ -1133,12 +1133,12 @@ sections: - id: introduction instruction: | This template guides creation of a comprehensive Project Brief that serves as the foundational input for product development. - + Start by asking the user which mode they prefer: - + 1. **Interactive Mode** - Work through each section collaboratively 2. **YOLO Mode** - Generate complete draft for review and refinement - + Before beginning, understand what inputs are available (brainstorming results, market research, competitive analysis, initial ideas) and gather project context. - id: executive-summary @@ -1459,7 +1459,7 @@ sections: instruction: Map the end-to-end customer experience for primary segments template: | For primary customer segment: - + 1. **Awareness:** {{discovery_process}} 2. **Consideration:** {{evaluation_criteria}} 3. **Purchase:** {{decision_triggers}} @@ -1660,7 +1660,7 @@ sections: title: Competitor Prioritization Matrix instruction: | Help categorize competitors by market share and strategic threat level - + Create a 2x2 matrix: - Priority 1 (Core Competitors): High Market Share + High Threat - Priority 2 (Emerging Threats): Low Market Share + High Threat @@ -1764,7 +1764,7 @@ sections: title: Positioning Map instruction: | Describe competitor positions on key dimensions - + Create a positioning description using 2 key dimensions relevant to the market, such as: - Price vs. Features - Ease of Use vs. Power @@ -1799,7 +1799,7 @@ sections: title: Blue Ocean Opportunities instruction: | Identify uncontested market spaces - + List opportunities to create new market space: - Underserved segments - Unaddressed use cases @@ -1903,11 +1903,11 @@ sections: - id: summary-details template: | **Topic:** {{session_topic}} - + **Session Goals:** {{stated_goals}} - + **Techniques Used:** {{techniques_list}} - + **Total Ideas Generated:** {{total_ideas}} - id: key-themes title: "Key Themes Identified:" @@ -2032,7 +2032,7 @@ sections: - id: footer content: | --- - + *Session facilitated using the BMAD-METHOD brainstorming framework* ==================== END: .bmad-core/templates/brainstorming-output-tmpl.yaml ==================== @@ -2113,7 +2113,7 @@ BMad transforms you into a "Vibe CEO" - directing a team of specialized AI agent **Best for**: ChatGPT, Claude, Gemini users who want to start immediately -1. Navigate to `dist/teams/` +1. Navigate to `bundles/teams/` 2. Copy `team-fullstack.txt` content 3. Create new Gemini Gem or CustomGPT 4. Upload file with instructions: "Your critical operating instructions are attached, do not break character as directed" @@ -2433,8 +2433,8 @@ The BMad-Method is built around a modular architecture centered on the `bmad-cor #### Web UI Environment -- Uses pre-built bundles from `dist/teams` for stand alone 1 upload files for all agents and their assets with an orchestrating agent -- Single text files containing all agent dependencies are in `dist/agents/` - these are unnecessary unless you want to create a web agent that is only a single agent and not a team +- Uses pre-built bundles from `bundles/teams` for stand alone 1 upload files for all agents and their assets with an orchestrating agent +- Single text files containing all agent dependencies are in `bundles/agents/` - these are unnecessary unless you want to create a web agent that is only a single agent and not a team - Created by the web-builder tool for upload to web interfaces - Provides complete context in one package @@ -2581,7 +2581,7 @@ Each status change requires user verification and approval before proceeding. #### Greenfield Development - Business analysis and market research -- Product requirements and feature definition +- Product requirements and feature definition - System architecture and design - Development execution - Testing and deployment @@ -2690,7 +2690,7 @@ Templates with Level 2 headings (`##`) can be automatically sharded: ```markdown ## Goals and Background Context -## Requirements +## Requirements ## User Interface Design Goals ## Success Metrics ``` diff --git a/dist/agents/architect.txt b/bundles/agents/architect.txt similarity index 100% rename from dist/agents/architect.txt rename to bundles/agents/architect.txt diff --git a/dist/agents/bmad-master.txt b/bundles/agents/bmad-master.txt similarity index 99% rename from dist/agents/bmad-master.txt rename to bundles/agents/bmad-master.txt index b3e3b5a14..bf1ff3a72 100644 --- a/dist/agents/bmad-master.txt +++ b/bundles/agents/bmad-master.txt @@ -290,7 +290,7 @@ If user selects Option 1, present numbered list of techniques from the brainstor 1. Apply selected technique according to data file description 2. Keep engaging with technique until user indicates they want to: - Choose a different technique - - Apply current ideas to a new technique + - Apply current ideas to a new technique - Move to convergent phase - End session @@ -2169,20 +2169,20 @@ sections: - id: intro-content content: | This document outlines the overall project architecture for {{project_name}}, including backend systems, shared services, and non-UI specific concerns. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development, ensuring consistency and adherence to chosen patterns and technologies. - + **Relationship to Frontend Architecture:** If the project includes a significant user interface, a separate Frontend Architecture Document will detail the frontend-specific design and MUST be used in conjunction with this document. Core technology stack choices documented herein (see "Tech Stack") are definitive for the entire project, including any frontend components. - id: starter-template title: Starter Template or Existing Project instruction: | Before proceeding further with architecture design, check if the project is based on a starter template or existing codebase: - + 1. Review the PRD and brainstorming brief for any mentions of: - Starter templates (e.g., Create React App, Next.js, Vue CLI, Angular CLI, etc.) - Existing projects or codebases being used as a foundation - Boilerplate projects or scaffolding tools - Previous projects to be cloned or adapted - + 2. If a starter template or existing project is mentioned: - Ask the user to provide access via one of these methods: - Link to the starter template documentation @@ -2195,16 +2195,16 @@ sections: - Existing architectural patterns and conventions - Any limitations or constraints imposed by the starter - Use this analysis to inform and align your architecture decisions - + 3. If no starter template is mentioned but this is a greenfield project: - Suggest appropriate starter templates based on the tech stack preferences - Explain the benefits (faster setup, best practices, community support) - Let the user decide whether to use one - + 4. If the user confirms no starter template will be used: - Proceed with architecture design from scratch - Note that manual setup will be required for all tooling and configuration - + Document the decision here before proceeding with the architecture design. If none, just say N/A elicit: true - id: changelog @@ -2232,7 +2232,7 @@ sections: title: High Level Overview instruction: | Based on the PRD's Technical Assumptions section, describe: - + 1. The main architectural style (e.g., Monolith, Microservices, Serverless, Event-Driven) 2. Repository structure decision from PRD (Monorepo/Polyrepo) 3. Service architecture decision from PRD @@ -2249,17 +2249,17 @@ sections: - Data flow directions - External integrations - User entry points - + - id: architectural-patterns title: Architectural and Design Patterns instruction: | List the key high-level patterns that will guide the architecture. For each pattern: - + 1. Present 2-3 viable options if multiple exist 2. Provide your recommendation with clear rationale 3. Get user confirmation before finalizing 4. These patterns should align with the PRD's technical assumptions and project goals - + Common patterns to consider: - Architectural style patterns (Serverless, Event-Driven, Microservices, CQRS, Hexagonal) - Code organization patterns (Dependency Injection, Repository, Module, Factory) @@ -2275,23 +2275,23 @@ sections: title: Tech Stack instruction: | This is the DEFINITIVE technology selection section. Work with the user to make specific choices: - + 1. Review PRD technical assumptions and any preferences from .bmad-core/data/technical-preferences.yaml or an attached technical-preferences 2. For each category, present 2-3 viable options with pros/cons 3. Make a clear recommendation based on project needs 4. Get explicit user approval for each selection 5. Document exact versions (avoid "latest" - pin specific versions) 6. This table is the single source of truth - all other docs must reference these choices - + Key decisions to finalize - before displaying the table, ensure you are aware of or ask the user about - let the user know if they are not sure on any that you can also provide suggestions with rationale: - + - Starter templates (if any) - Languages and runtimes with exact versions - Frameworks and libraries / packages - Cloud provider and key services choices - Database and storage solutions - if unclear suggest sql or nosql or other types depending on the project and depending on cloud provider offer a suggestion - Development tools - + Upon render of the table, ensure the user is aware of the importance of this sections choices, should also look for gaps or disagreements with anything, ask for any clarifications if something is unclear why its in the list, and also right away elicit feedback - this statement and the options should be rendered and then prompt right all before allowing user input. elicit: true sections: @@ -2315,13 +2315,13 @@ sections: title: Data Models instruction: | Define the core data models/entities: - + 1. Review PRD requirements and identify key business entities 2. For each model, explain its purpose and relationships 3. Include key attributes and data types 4. Show relationships between models 5. Discuss design decisions with user - + Create a clear conceptual model before moving to database schema. elicit: true repeatable: true @@ -2330,11 +2330,11 @@ sections: title: "{{model_name}}" template: | **Purpose:** {{model_purpose}} - + **Key Attributes:** - {{attribute_1}}: {{type_1}} - {{description_1}} - {{attribute_2}}: {{type_2}} - {{description_2}} - + **Relationships:** - {{relationship_1}} - {{relationship_2}} @@ -2343,7 +2343,7 @@ sections: title: Components instruction: | Based on the architectural patterns, tech stack, and data models from above: - + 1. Identify major logical components/services and their responsibilities 2. Consider the repository structure (monorepo/polyrepo) from PRD 3. Define clear boundaries and interfaces between components @@ -2352,7 +2352,7 @@ sections: - Key interfaces/APIs exposed - Dependencies on other components - Technology specifics based on tech stack choices - + 5. Create component diagrams where helpful elicit: true sections: @@ -2361,13 +2361,13 @@ sections: title: "{{component_name}}" template: | **Responsibility:** {{component_description}} - + **Key Interfaces:** - {{interface_1}} - {{interface_2}} - + **Dependencies:** {{dependencies}} - + **Technology Stack:** {{component_tech_details}} - id: component-diagrams title: Component Diagrams @@ -2384,13 +2384,13 @@ sections: condition: Project requires external API integrations instruction: | For each external service integration: - + 1. Identify APIs needed based on PRD requirements and component design 2. If documentation URLs are unknown, ask user for specifics 3. Document authentication methods and security considerations 4. List specific endpoints that will be used 5. Note any rate limits or usage constraints - + If no external APIs are needed, state this explicitly and skip to next section. elicit: true repeatable: true @@ -2403,10 +2403,10 @@ sections: - **Base URL(s):** {{api_base_url}} - **Authentication:** {{auth_method}} - **Rate Limits:** {{rate_limits}} - + **Key Endpoints Used:** - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}} - + **Integration Notes:** {{integration_considerations}} - id: core-workflows @@ -2415,13 +2415,13 @@ sections: mermaid_type: sequence instruction: | Illustrate key system workflows using sequence diagrams: - + 1. Identify critical user journeys from PRD 2. Show component interactions including external APIs 3. Include error handling paths 4. Document async operations 5. Create both high-level and detailed diagrams as needed - + Focus on workflows that clarify architecture decisions or complex interactions. elicit: true @@ -2432,13 +2432,13 @@ sections: language: yaml instruction: | If the project includes a REST API: - + 1. Create an OpenAPI 3.0 specification 2. Include all endpoints from epics/stories 3. Define request/response schemas based on data models 4. Document authentication requirements 5. Include example requests/responses - + Use YAML format for better readability. If no REST API, skip this section. elicit: true template: | @@ -2455,13 +2455,13 @@ sections: title: Database Schema instruction: | Transform the conceptual data models into concrete database schemas: - + 1. Use the database type(s) selected in Tech Stack 2. Create schema definitions using appropriate notation 3. Include indexes, constraints, and relationships 4. Consider performance and scalability 5. For NoSQL, show document structures - + Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.) elicit: true @@ -2471,14 +2471,14 @@ sections: language: plaintext instruction: | Create a project folder structure that reflects: - + 1. The chosen repository structure (monorepo/polyrepo) 2. The service architecture (monolith/microservices/serverless) 3. The selected tech stack and languages 4. Component organization from above 5. Best practices for the chosen frameworks 6. Clear separation of concerns - + Adapt the structure based on project needs. For monorepos, show service separation. For serverless, show function organization. Include language-specific conventions. elicit: true examples: @@ -2496,13 +2496,13 @@ sections: title: Infrastructure and Deployment instruction: | Define the deployment architecture and practices: - + 1. Use IaC tool selected in Tech Stack 2. Choose deployment strategy appropriate for the architecture 3. Define environments and promotion flow 4. Establish rollback procedures 5. Consider security, monitoring, and cost optimization - + Get user input on deployment preferences and CI/CD tool choices. elicit: true sections: @@ -2538,13 +2538,13 @@ sections: title: Error Handling Strategy instruction: | Define comprehensive error handling approach: - + 1. Choose appropriate patterns for the language/framework from Tech Stack 2. Define logging standards and tools 3. Establish error categories and handling rules 4. Consider observability and debugging needs 5. Ensure security (no sensitive data in logs) - + This section guides both AI and human developers in consistent error handling. elicit: true sections: @@ -2591,13 +2591,13 @@ sections: title: Coding Standards instruction: | These standards are MANDATORY for AI agents. Work with user to define ONLY the critical rules needed to prevent bad code. Explain that: - + 1. This section directly controls AI developer behavior 2. Keep it minimal - assume AI knows general best practices 3. Focus on project-specific conventions and gotchas 4. Overly detailed standards bloat context and slow development 5. Standards will be extracted to separate file for dev agent use - + For each standard, get explicit user confirmation it's necessary. elicit: true sections: @@ -2619,7 +2619,7 @@ sections: - "Never use console.log in production code - use logger" - "All API responses must use ApiResponse wrapper type" - "Database queries must use repository pattern, never direct ORM" - + Avoid obvious rules like "use SOLID principles" or "write clean code" repeatable: true template: "- **{{rule_name}}:** {{rule_description}}" @@ -2637,14 +2637,14 @@ sections: title: Test Strategy and Standards instruction: | Work with user to define comprehensive test strategy: - + 1. Use test frameworks from Tech Stack 2. Decide on TDD vs test-after approach 3. Define test organization and naming 4. Establish coverage goals 5. Determine integration test infrastructure 6. Plan for test data and external dependencies - + Note: Basic info goes in Coding Standards for dev agent. This detailed section is for QA agent and team reference. elicit: true sections: @@ -2665,7 +2665,7 @@ sections: - **Location:** {{unit_test_location}} - **Mocking Library:** {{mocking_library}} - **Coverage Requirement:** {{unit_coverage}} - + **AI Agent Requirements:** - Generate tests for all public methods - Cover edge cases and error conditions @@ -2707,7 +2707,7 @@ sections: title: Security instruction: | Define MANDATORY security requirements for AI and human developers: - + 1. Focus on implementation-specific rules 2. Reference security tools from Tech Stack 3. Define clear patterns for common scenarios @@ -2776,16 +2776,16 @@ sections: title: Next Steps instruction: | After completing the architecture: - + 1. If project has UI components: - Use "Frontend Architecture Mode" - Provide this document as input - + 2. For all projects: - Review with Product Owner - Begin story implementation with Dev agent - Set up infrastructure with DevOps agent - + 3. Include specific prompts for next agents if needed sections: - id: architect-prompt @@ -2818,40 +2818,40 @@ sections: title: Introduction instruction: | IMPORTANT - SCOPE AND ASSESSMENT REQUIRED: - + This architecture document is for SIGNIFICANT enhancements to existing projects that require comprehensive architectural planning. Before proceeding: - + 1. **Verify Complexity**: Confirm this enhancement requires architectural planning. For simple additions, recommend: "For simpler changes that don't require architectural planning, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead." - + 2. **REQUIRED INPUTS**: - Completed brownfield-prd.md - Existing project technical documentation (from docs folder or user-provided) - Access to existing project structure (IDE or uploaded files) - + 3. **DEEP ANALYSIS MANDATE**: You MUST conduct thorough analysis of the existing codebase, architecture patterns, and technical constraints before making ANY architectural recommendations. Every suggestion must be based on actual project analysis, not assumptions. - + 4. **CONTINUOUS VALIDATION**: Throughout this process, explicitly validate your understanding with the user. For every architectural decision, confirm: "Based on my analysis of your existing system, I recommend [decision] because [evidence from actual project]. Does this align with your system's reality?" - + If any required inputs are missing, request them before proceeding. elicit: true sections: - id: intro-content content: | This document outlines the architectural approach for enhancing {{project_name}} with {{enhancement_description}}. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development of new features while ensuring seamless integration with the existing system. - + **Relationship to Existing Architecture:** This document supplements existing project architecture by defining how new components will integrate with current systems. Where conflicts arise between new and existing patterns, this document provides guidance on maintaining consistency while implementing enhancements. - id: existing-project-analysis title: Existing Project Analysis instruction: | Analyze the existing project structure and architecture: - + 1. Review existing documentation in docs folder 2. Examine current technology stack and versions 3. Identify existing architectural patterns and conventions 4. Note current deployment and infrastructure setup 5. Document any constraints or limitations - + CRITICAL: After your analysis, explicitly validate your findings: "Based on my analysis of your project, I've identified the following about your existing system: [key findings]. Please confirm these observations are accurate before I proceed with architectural recommendations." elicit: true sections: @@ -2880,12 +2880,12 @@ sections: title: Enhancement Scope and Integration Strategy instruction: | Define how the enhancement will integrate with the existing system: - + 1. Review the brownfield PRD enhancement scope 2. Identify integration points with existing code 3. Define boundaries between new and existing functionality 4. Establish compatibility requirements - + VALIDATION CHECKPOINT: Before presenting the integration strategy, confirm: "Based on my analysis, the integration approach I'm proposing takes into account [specific existing system characteristics]. These integration points and boundaries respect your current architecture patterns. Is this assessment accurate?" elicit: true sections: @@ -2914,7 +2914,7 @@ sections: title: Tech Stack Alignment instruction: | Ensure new components align with existing technology choices: - + 1. Use existing technology stack as the foundation 2. Only introduce new technologies if absolutely necessary 3. Justify any new additions with clear rationale @@ -2937,7 +2937,7 @@ sections: title: Data Models and Schema Changes instruction: | Define new data models and how they integrate with existing schema: - + 1. Identify new entities required for the enhancement 2. Define relationships with existing data models 3. Plan database schema changes (additions, modifications) @@ -2953,11 +2953,11 @@ sections: template: | **Purpose:** {{model_purpose}} **Integration:** {{integration_with_existing}} - + **Key Attributes:** - {{attribute_1}}: {{type_1}} - {{description_1}} - {{attribute_2}}: {{type_2}} - {{description_2}} - + **Relationships:** - **With Existing:** {{existing_relationships}} - **With New:** {{new_relationships}} @@ -2969,7 +2969,7 @@ sections: - **Modified Tables:** {{modified_tables_list}} - **New Indexes:** {{new_indexes_list}} - **Migration Strategy:** {{migration_approach}} - + **Backward Compatibility:** - {{compatibility_measure_1}} - {{compatibility_measure_2}} @@ -2978,12 +2978,12 @@ sections: title: Component Architecture instruction: | Define new components and their integration with existing architecture: - + 1. Identify new components required for the enhancement 2. Define interfaces with existing components 3. Establish clear boundaries and responsibilities 4. Plan integration points and data flow - + MANDATORY VALIDATION: Before presenting component architecture, confirm: "The new components I'm proposing follow the existing architectural patterns I identified in your codebase: [specific patterns]. The integration interfaces respect your current component structure and communication patterns. Does this match your project's reality?" elicit: true sections: @@ -2996,15 +2996,15 @@ sections: template: | **Responsibility:** {{component_description}} **Integration Points:** {{integration_points}} - + **Key Interfaces:** - {{interface_1}} - {{interface_2}} - + **Dependencies:** - **Existing Components:** {{existing_dependencies}} - **New Components:** {{new_dependencies}} - + **Technology Stack:** {{component_tech_details}} - id: interaction-diagram title: Component Interaction Diagram @@ -3017,7 +3017,7 @@ sections: condition: Enhancement requires API changes instruction: | Define new API endpoints and integration with existing APIs: - + 1. Plan new API endpoints required for the enhancement 2. Ensure consistency with existing API patterns 3. Define authentication and authorization integration @@ -3067,17 +3067,17 @@ sections: - **Base URL:** {{api_base_url}} - **Authentication:** {{auth_method}} - **Integration Method:** {{integration_approach}} - + **Key Endpoints Used:** - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}} - + **Error Handling:** {{error_handling_strategy}} - id: source-tree-integration title: Source Tree Integration instruction: | Define how new code will integrate with existing project structure: - + 1. Follow existing project organization patterns 2. Identify where new files/folders will be placed 3. Ensure consistency with existing naming conventions @@ -3116,7 +3116,7 @@ sections: title: Infrastructure and Deployment Integration instruction: | Define how the enhancement will be deployed alongside existing infrastructure: - + 1. Use existing deployment pipeline and infrastructure 2. Identify any infrastructure changes needed 3. Plan deployment strategy to minimize risk @@ -3146,7 +3146,7 @@ sections: title: Coding Standards and Conventions instruction: | Ensure new code follows existing project conventions: - + 1. Document existing coding standards from project analysis 2. Identify any enhancement-specific requirements 3. Ensure consistency with existing codebase patterns @@ -3177,7 +3177,7 @@ sections: title: Testing Strategy instruction: | Define testing approach for the enhancement: - + 1. Integrate with existing test suite 2. Ensure existing functionality remains intact 3. Plan for testing new features @@ -3217,7 +3217,7 @@ sections: title: Security Integration instruction: | Ensure security consistency with existing system: - + 1. Follow existing security patterns and tools 2. Ensure new features don't introduce vulnerabilities 3. Maintain existing security posture @@ -3252,7 +3252,7 @@ sections: title: Next Steps instruction: | After completing the brownfield architecture: - + 1. Review integration points with existing system 2. Begin story implementation with Dev agent 3. Set up deployment pipeline integration @@ -3297,19 +3297,19 @@ sections: title: Intro Project Analysis and Context instruction: | IMPORTANT - SCOPE ASSESSMENT REQUIRED: - + This PRD is for SIGNIFICANT enhancements to existing projects that require comprehensive planning and multiple stories. Before proceeding: - + 1. **Assess Enhancement Complexity**: If this is a simple feature addition or bug fix that could be completed in 1-2 focused development sessions, STOP and recommend: "For simpler changes, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead. This full PRD process is designed for substantial enhancements that require architectural planning and multiple coordinated stories." - + 2. **Project Context**: Determine if we're working in an IDE with the project already loaded or if the user needs to provide project information. If project files are available, analyze existing documentation in the docs folder. If insufficient documentation exists, recommend running the document-project task first. - + 3. **Deep Assessment Requirement**: You MUST thoroughly analyze the existing project structure, patterns, and constraints before making ANY suggestions. Every recommendation must be grounded in actual project analysis, not assumptions. - + Gather comprehensive information about the existing project. This section must be completed before proceeding with requirements. - + CRITICAL: Throughout this analysis, explicitly confirm your understanding with the user. For every assumption you make about the existing project, ask: "Based on my analysis, I understand that [assumption]. Is this correct?" - + Do not proceed with any recommendations until the user has validated your understanding of the existing system. sections: - id: existing-project-overview @@ -3335,7 +3335,7 @@ sections: - Note: "Document-project analysis available - using existing technical documentation" - List key documents created by document-project - Skip the missing documentation check below - + Otherwise, check for existing documentation: sections: - id: available-docs @@ -3459,7 +3459,7 @@ sections: If document-project output available: - Extract from "Actual Tech Stack" table in High Level Architecture section - Include version numbers and any noted constraints - + Otherwise, document the current technology stack: template: | **Languages**: {{languages}} @@ -3498,7 +3498,7 @@ sections: - Reference "Technical Debt and Known Issues" section - Include "Workarounds and Gotchas" that might impact enhancement - Note any identified constraints from "Critical Technical Debt" - + Build risk assessment incorporating existing known issues: template: | **Technical Risks**: {{technical_risks}} @@ -3521,7 +3521,7 @@ sections: title: "Epic 1: {{enhancement_title}}" instruction: | Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality - + CRITICAL STORY SEQUENCING FOR BROWNFIELD: - Stories must ensure existing functionality remains intact - Each story should include verification that existing features still work @@ -3534,7 +3534,7 @@ sections: - Each story must deliver value while maintaining system integrity template: | **Epic Goal**: {{epic_goal}} - + **Integration Requirements**: {{integration_requirements}} sections: - id: story @@ -3640,7 +3640,7 @@ sections: title: Competitor Prioritization Matrix instruction: | Help categorize competitors by market share and strategic threat level - + Create a 2x2 matrix: - Priority 1 (Core Competitors): High Market Share + High Threat - Priority 2 (Emerging Threats): Low Market Share + High Threat @@ -3744,7 +3744,7 @@ sections: title: Positioning Map instruction: | Describe competitor positions on key dimensions - + Create a positioning description using 2 key dimensions relevant to the market, such as: - Price vs. Features - Ease of Use vs. Power @@ -3779,7 +3779,7 @@ sections: title: Blue Ocean Opportunities instruction: | Identify uncontested market spaces - + List opportunities to create new market space: - Underserved segments - Unaddressed use cases @@ -3876,16 +3876,16 @@ sections: title: Template and Framework Selection instruction: | Review provided documents including PRD, UX-UI Specification, and main Architecture Document. Focus on extracting technical implementation details needed for AI frontend tools and developer agents. Ask the user for any of these documents if you are unable to locate and were not provided. - + Before proceeding with frontend architecture design, check if the project is using a frontend starter template or existing codebase: - + 1. Review the PRD, main architecture document, and brainstorming brief for mentions of: - Frontend starter templates (e.g., Create React App, Next.js, Vite, Vue CLI, Angular CLI, etc.) - UI kit or component library starters - Existing frontend projects being used as a foundation - Admin dashboard templates or other specialized starters - Design system implementations - + 2. If a frontend starter template or existing project is mentioned: - Ask the user to provide access via one of these methods: - Link to the starter template documentation @@ -3901,7 +3901,7 @@ sections: - Testing setup and patterns - Build and development scripts - Use this analysis to ensure your frontend architecture aligns with the starter's patterns - + 3. If no frontend starter is mentioned but this is a new UI, ensure we know what the ui language and framework is: - Based on the framework choice, suggest appropriate starters: - React: Create React App, Next.js, Vite + React @@ -3909,11 +3909,11 @@ sections: - Angular: Angular CLI - Or suggest popular UI templates if applicable - Explain benefits specific to frontend development - + 4. If the user confirms no starter template will be used: - Note that all tooling, bundling, and configuration will need manual setup - Proceed with frontend architecture from scratch - + Document the starter template decision and any constraints it imposes before proceeding. sections: - id: changelog @@ -4085,7 +4085,7 @@ sections: title: Introduction instruction: | Review provided documents including Project Brief, PRD, and any user research to gather context. Focus on understanding user needs, pain points, and desired outcomes before beginning the specification. - + Establish the document's purpose and scope. Keep the content below but ensure project name is properly substituted. content: | This document defines the user experience goals, information architecture, user flows, and visual design specifications for {{project_name}}'s user interface. It serves as the foundation for visual design and frontend development, ensuring a cohesive and user-centered experience. @@ -4094,7 +4094,7 @@ sections: title: Overall UX Goals & Principles instruction: | Work with the user to establish and document the following. If not already defined, facilitate a discussion to determine: - + 1. Target User Personas - elicit details or confirm existing ones from PRD 2. Key Usability Goals - understand what success looks like for users 3. Core Design Principles - establish 3-5 guiding principles @@ -4135,7 +4135,7 @@ sections: title: Information Architecture (IA) instruction: | Collaborate with the user to create a comprehensive information architecture: - + 1. Build a Site Map or Screen Inventory showing all major areas 2. Define the Navigation Structure (primary, secondary, breadcrumbs) 3. Use Mermaid diagrams for visual representation @@ -4165,22 +4165,22 @@ sections: title: Navigation Structure template: | **Primary Navigation:** {{primary_nav_description}} - + **Secondary Navigation:** {{secondary_nav_description}} - + **Breadcrumb Strategy:** {{breadcrumb_strategy}} - id: user-flows title: User Flows instruction: | For each critical user task identified in the PRD: - + 1. Define the user's goal clearly 2. Map out all steps including decision points 3. Consider edge cases and error states 4. Use Mermaid flow diagrams for clarity 5. Link to external tools (Figma/Miro) if detailed flows exist there - + Create subsections for each major flow. elicit: true repeatable: true @@ -4189,9 +4189,9 @@ sections: title: "{{flow_name}}" template: | **User Goal:** {{flow_goal}} - + **Entry Points:** {{entry_points}} - + **Success Criteria:** {{success_criteria}} sections: - id: flow-diagram @@ -4222,14 +4222,14 @@ sections: title: "{{screen_name}}" template: | **Purpose:** {{screen_purpose}} - + **Key Elements:** - {{element_1}} - {{element_2}} - {{element_3}} - + **Interaction Notes:** {{interaction_notes}} - + **Design File Reference:** {{specific_frame_link}} - id: component-library @@ -4248,11 +4248,11 @@ sections: title: "{{component_name}}" template: | **Purpose:** {{component_purpose}} - + **Variants:** {{component_variants}} - + **States:** {{component_states}} - + **Usage Guidelines:** {{usage_guidelines}} - id: branding-style @@ -4298,13 +4298,13 @@ sections: title: Iconography template: | **Icon Library:** {{icon_library}} - + **Usage Guidelines:** {{icon_guidelines}} - id: spacing-layout title: Spacing & Layout template: | **Grid System:** {{grid_system}} - + **Spacing Scale:** {{spacing_scale}} - id: accessibility @@ -4322,12 +4322,12 @@ sections: - Color contrast ratios: {{contrast_requirements}} - Focus indicators: {{focus_requirements}} - Text sizing: {{text_requirements}} - + **Interaction:** - Keyboard navigation: {{keyboard_requirements}} - Screen reader support: {{screen_reader_requirements}} - Touch targets: {{touch_requirements}} - + **Content:** - Alternative text: {{alt_text_requirements}} - Heading structure: {{heading_requirements}} @@ -4354,11 +4354,11 @@ sections: title: Adaptation Patterns template: | **Layout Changes:** {{layout_adaptations}} - + **Navigation Changes:** {{nav_adaptations}} - + **Content Priority:** {{content_adaptations}} - + **Interaction Changes:** {{interaction_adaptations}} - id: animation @@ -4392,7 +4392,7 @@ sections: title: Next Steps instruction: | After completing the UI/UX specification: - + 1. Recommend review with stakeholders 2. Suggest creating/updating visual designs in design tool 3. Prepare for handoff to Design Architect for frontend architecture @@ -4440,33 +4440,33 @@ sections: elicit: true content: | This document outlines the complete fullstack architecture for {{project_name}}, including backend systems, frontend implementation, and their integration. It serves as the single source of truth for AI-driven development, ensuring consistency across the entire technology stack. - + This unified approach combines what would traditionally be separate backend and frontend architecture documents, streamlining the development process for modern fullstack applications where these concerns are increasingly intertwined. sections: - id: starter-template title: Starter Template or Existing Project instruction: | Before proceeding with architecture design, check if the project is based on any starter templates or existing codebases: - + 1. Review the PRD and other documents for mentions of: - Fullstack starter templates (e.g., T3 Stack, MEAN/MERN starters, Django + React templates) - Monorepo templates (e.g., Nx, Turborepo starters) - Platform-specific starters (e.g., Vercel templates, AWS Amplify starters) - Existing projects being extended or cloned - + 2. If starter templates or existing projects are mentioned: - Ask the user to provide access (links, repos, or files) - Analyze to understand pre-configured choices and constraints - Note any architectural decisions already made - Identify what can be modified vs what must be retained - + 3. If no starter is mentioned but this is greenfield: - Suggest appropriate fullstack starters based on tech preferences - Consider platform-specific options (Vercel, AWS, etc.) - Let user decide whether to use one - + 4. Document the decision and any constraints it imposes - + If none, state "N/A - Greenfield project" - id: changelog title: Change Log @@ -4492,17 +4492,17 @@ sections: title: Platform and Infrastructure Choice instruction: | Based on PRD requirements and technical assumptions, make a platform recommendation: - + 1. Consider common patterns (not an exhaustive list, use your own best judgement and search the web as needed for emerging trends): - **Vercel + Supabase**: For rapid development with Next.js, built-in auth/storage - **AWS Full Stack**: For enterprise scale with Lambda, API Gateway, S3, Cognito - **Azure**: For .NET ecosystems or enterprise Microsoft environments - **Google Cloud**: For ML/AI heavy applications or Google ecosystem integration - + 2. Present 2-3 viable options with clear pros/cons 3. Make a recommendation with rationale 4. Get explicit user confirmation - + Document the choice and key services that will be used. template: | **Platform:** {{selected_platform}} @@ -4512,7 +4512,7 @@ sections: title: Repository Structure instruction: | Define the repository approach based on PRD requirements and platform choice, explain your rationale or ask questions to the user if unsure: - + 1. For modern fullstack apps, monorepo is often preferred 2. Consider tooling (Nx, Turborepo, Lerna, npm workspaces) 3. Define package/app boundaries @@ -4534,7 +4534,7 @@ sections: - Databases and storage - External integrations - CDN and caching layers - + Use appropriate diagram type for clarity. - id: architectural-patterns title: Architectural Patterns @@ -4544,7 +4544,7 @@ sections: - Frontend patterns (e.g., Component-based, State management) - Backend patterns (e.g., Repository, CQRS, Event-driven) - Integration patterns (e.g., BFF, API Gateway) - + For each pattern, provide recommendation and rationale. repeatable: true template: "- **{{pattern_name}}:** {{pattern_description}} - _Rationale:_ {{rationale}}" @@ -4558,7 +4558,7 @@ sections: title: Tech Stack instruction: | This is the DEFINITIVE technology selection for the entire project. Work with user to finalize all choices. This table is the single source of truth - all development must use these exact versions. - + Key areas to cover: - Frontend and backend languages/frameworks - Databases and caching @@ -4567,7 +4567,7 @@ sections: - Testing tools for both frontend and backend - Build and deployment tools - Monitoring and logging - + Upon render, elicit feedback immediately. elicit: true sections: @@ -4602,14 +4602,14 @@ sections: title: Data Models instruction: | Define the core data models/entities that will be shared between frontend and backend: - + 1. Review PRD requirements and identify key business entities 2. For each model, explain its purpose and relationships 3. Include key attributes and data types 4. Show relationships between models 5. Create TypeScript interfaces that can be shared 6. Discuss design decisions with user - + Create a clear conceptual model before moving to database schema. elicit: true repeatable: true @@ -4618,7 +4618,7 @@ sections: title: "{{model_name}}" template: | **Purpose:** {{model_purpose}} - + **Key Attributes:** - {{attribute_1}}: {{type_1}} - {{description_1}} - {{attribute_2}}: {{type_2}} - {{description_2}} @@ -4637,7 +4637,7 @@ sections: title: API Specification instruction: | Based on the chosen API style from Tech Stack: - + 1. If REST API, create an OpenAPI 3.0 specification 2. If GraphQL, provide the GraphQL schema 3. If tRPC, show router definitions @@ -4645,7 +4645,7 @@ sections: 5. Define request/response schemas based on data models 6. Document authentication requirements 7. Include example requests/responses - + Use appropriate format for the chosen API style. If no API (e.g., static site), skip this section. elicit: true sections: @@ -4680,7 +4680,7 @@ sections: title: Components instruction: | Based on the architectural patterns, tech stack, and data models from above: - + 1. Identify major logical components/services across the fullstack 2. Consider both frontend and backend components 3. Define clear boundaries and interfaces between components @@ -4689,7 +4689,7 @@ sections: - Key interfaces/APIs exposed - Dependencies on other components - Technology specifics based on tech stack choices - + 5. Create component diagrams where helpful elicit: true sections: @@ -4698,13 +4698,13 @@ sections: title: "{{component_name}}" template: | **Responsibility:** {{component_description}} - + **Key Interfaces:** - {{interface_1}} - {{interface_2}} - + **Dependencies:** {{dependencies}} - + **Technology Stack:** {{component_tech_details}} - id: component-diagrams title: Component Diagrams @@ -4721,13 +4721,13 @@ sections: condition: Project requires external API integrations instruction: | For each external service integration: - + 1. Identify APIs needed based on PRD requirements and component design 2. If documentation URLs are unknown, ask user for specifics 3. Document authentication methods and security considerations 4. List specific endpoints that will be used 5. Note any rate limits or usage constraints - + If no external APIs are needed, state this explicitly and skip to next section. elicit: true repeatable: true @@ -4740,10 +4740,10 @@ sections: - **Base URL(s):** {{api_base_url}} - **Authentication:** {{auth_method}} - **Rate Limits:** {{rate_limits}} - + **Key Endpoints Used:** - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}} - + **Integration Notes:** {{integration_considerations}} - id: core-workflows @@ -4752,14 +4752,14 @@ sections: mermaid_type: sequence instruction: | Illustrate key system workflows using sequence diagrams: - + 1. Identify critical user journeys from PRD 2. Show component interactions including external APIs 3. Include both frontend and backend flows 4. Include error handling paths 5. Document async operations 6. Create both high-level and detailed diagrams as needed - + Focus on workflows that clarify architecture decisions or complex interactions. elicit: true @@ -4767,13 +4767,13 @@ sections: title: Database Schema instruction: | Transform the conceptual data models into concrete database schemas: - + 1. Use the database type(s) selected in Tech Stack 2. Create schema definitions using appropriate notation 3. Include indexes, constraints, and relationships 4. Consider performance and scalability 5. For NoSQL, show document structures - + Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.) elicit: true @@ -4989,13 +4989,13 @@ sections: template: | # Start all services {{start_all_command}} - + # Start frontend only {{start_frontend_command}} - + # Start backend only {{start_backend_command}} - + # Run tests {{test_commands}} - id: environment-config @@ -5008,10 +5008,10 @@ sections: template: | # Frontend (.env.local) {{frontend_env_vars}} - + # Backend (.env) {{backend_env_vars}} - + # Shared {{shared_env_vars}} @@ -5028,7 +5028,7 @@ sections: - **Build Command:** {{frontend_build_command}} - **Output Directory:** {{frontend_output_dir}} - **CDN/Edge:** {{cdn_strategy}} - + **Backend Deployment:** - **Platform:** {{backend_deploy_platform}} - **Build Command:** {{backend_build_command}} @@ -5059,12 +5059,12 @@ sections: - CSP Headers: {{csp_policy}} - XSS Prevention: {{xss_strategy}} - Secure Storage: {{storage_strategy}} - + **Backend Security:** - Input Validation: {{validation_approach}} - Rate Limiting: {{rate_limit_config}} - CORS Policy: {{cors_config}} - + **Authentication Security:** - Token Storage: {{token_strategy}} - Session Management: {{session_approach}} @@ -5076,7 +5076,7 @@ sections: - Bundle Size Target: {{bundle_size}} - Loading Strategy: {{loading_approach}} - Caching Strategy: {{fe_cache_strategy}} - + **Backend Performance:** - Response Time Target: {{response_target}} - Database Optimization: {{db_optimization}} @@ -5214,7 +5214,7 @@ sections: - JavaScript errors - API response times - User interactions - + **Backend Metrics:** - Request rate - Error rate @@ -5359,7 +5359,7 @@ sections: instruction: Map the end-to-end customer experience for primary segments template: | For primary customer segment: - + 1. **Awareness:** {{discovery_process}} 2. **Consideration:** {{evaluation_criteria}} 3. **Purchase:** {{decision_triggers}} @@ -5540,7 +5540,7 @@ sections: condition: PRD has UX/UI requirements instruction: | Capture high-level UI/UX vision to guide Design Architect and to inform story creation. Steps: - + 1. Pre-fill all subsections with educated guesses based on project context 2. Present the complete rendered section to user 3. Clearly let the user know where assumptions were made @@ -5582,7 +5582,7 @@ sections: title: Technical Assumptions instruction: | Gather technical decisions that will guide the Architect. Steps: - + 1. Check if .bmad-core/data/technical-preferences.yaml or an attached technical-preferences file exists - use it to pre-populate choices 2. Ask user about: languages, frameworks, starter templates, libraries, APIs, deployment targets 3. For unknowns, offer guidance based on project goals and MVP scope @@ -5610,9 +5610,9 @@ sections: title: Epic List instruction: | Present a high-level list of all epics for user approval. Each epic should have a title and a short (1 sentence) goal statement. This allows the user to review the overall structure before diving into details. - + CRITICAL: Epics MUST be logically sequential following agile best practices: - + - Each epic should deliver a significant, end-to-end, fully deployable increment of testable functionality - Epic 1 must establish foundational project infrastructure (app setup, Git, CI/CD, core services) unless we are adding new functionality to an existing app, while also delivering an initial piece of functionality, even as simple as a health-check route or display of a simple canary page - remember this when we produce the stories for the first epic! - Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed @@ -5631,11 +5631,11 @@ sections: repeatable: true instruction: | After the epic list is approved, present each epic with all its stories and acceptance criteria as a complete review unit. - + For each epic provide expanded goal (2-3 sentences describing the objective and value all the stories will achieve). - + CRITICAL STORY SEQUENCING REQUIREMENTS: - + - Stories within each epic MUST be logically sequential - Each story should be a "vertical slice" delivering complete functionality aside from early enabler stories for project foundation - No story should depend on work from a later story or epic @@ -5663,7 +5663,7 @@ sections: repeatable: true instruction: | Define clear, comprehensive, and testable acceptance criteria that: - + - Precisely define what "done" means from a functional perspective - Are unambiguous and serve as basis for verification - Include any critical non-functional requirements from the PRD @@ -5717,12 +5717,12 @@ sections: - id: introduction instruction: | This template guides creation of a comprehensive Project Brief that serves as the foundational input for product development. - + Start by asking the user which mode they prefer: - + 1. **Interactive Mode** - Work through each section collaboratively 2. **YOLO Mode** - Generate complete draft for review and refinement - + Before beginning, understand what inputs are available (brainstorming results, market research, competitive analysis, initial ideas) and gather project context. - id: executive-summary @@ -5925,7 +5925,7 @@ workflow: elicitation: advanced-elicitation agent_config: - editable_sections: + editable_sections: - Status - Story - Acceptance Criteria @@ -5942,7 +5942,7 @@ sections: instruction: Select the current status of the story owner: scrum-master editors: [scrum-master, dev-agent] - + - id: story title: Story type: template-text @@ -5954,7 +5954,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: acceptance-criteria title: Acceptance Criteria type: numbered-list @@ -5962,7 +5962,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: tasks-subtasks title: Tasks / Subtasks type: bullet-list @@ -5979,7 +5979,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master, dev-agent] - + - id: dev-notes title: Dev Notes instruction: | @@ -6003,7 +6003,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: change-log title: Change Log type: table @@ -6011,7 +6011,7 @@ sections: instruction: Track changes made to this story document owner: scrum-master editors: [scrum-master, dev-agent, qa-agent] - + - id: dev-agent-record title: Dev Agent Record instruction: This section is populated by the development agent during implementation @@ -6024,25 +6024,25 @@ sections: instruction: Record the specific AI agent model and version used for development owner: dev-agent editors: [dev-agent] - + - id: debug-log-references title: Debug Log References instruction: Reference any debug logs or traces generated during development owner: dev-agent editors: [dev-agent] - + - id: completion-notes title: Completion Notes List instruction: Notes about the completion of tasks and any issues encountered owner: dev-agent editors: [dev-agent] - + - id: file-list title: File List instruction: List all files created, modified, or affected during story implementation owner: dev-agent editors: [dev-agent] - + - id: qa-results title: QA Results instruction: Results from QA Agent QA review of the completed story implementation @@ -7843,7 +7843,7 @@ BMad transforms you into a "Vibe CEO" - directing a team of specialized AI agent **Best for**: ChatGPT, Claude, Gemini users who want to start immediately -1. Navigate to `dist/teams/` +1. Navigate to `bundles/teams/` 2. Copy `team-fullstack.txt` content 3. Create new Gemini Gem or CustomGPT 4. Upload file with instructions: "Your critical operating instructions are attached, do not break character as directed" @@ -8163,8 +8163,8 @@ The BMad-Method is built around a modular architecture centered on the `bmad-cor #### Web UI Environment -- Uses pre-built bundles from `dist/teams` for stand alone 1 upload files for all agents and their assets with an orchestrating agent -- Single text files containing all agent dependencies are in `dist/agents/` - these are unnecessary unless you want to create a web agent that is only a single agent and not a team +- Uses pre-built bundles from `bundles/teams` for stand alone 1 upload files for all agents and their assets with an orchestrating agent +- Single text files containing all agent dependencies are in `bundles/agents/` - these are unnecessary unless you want to create a web agent that is only a single agent and not a team - Created by the web-builder tool for upload to web interfaces - Provides complete context in one package @@ -8311,7 +8311,7 @@ Each status change requires user verification and approval before proceeding. #### Greenfield Development - Business analysis and market research -- Product requirements and feature definition +- Product requirements and feature definition - System architecture and design - Development execution - Testing and deployment @@ -8420,7 +8420,7 @@ Templates with Level 2 headings (`##`) can be automatically sharded: ```markdown ## Goals and Background Context -## Requirements +## Requirements ## User Interface Design Goals ## Success Metrics ``` diff --git a/dist/agents/bmad-orchestrator.txt b/bundles/agents/bmad-orchestrator.txt similarity index 99% rename from dist/agents/bmad-orchestrator.txt rename to bundles/agents/bmad-orchestrator.txt index bafd9498d..7fd4bea1a 100644 --- a/dist/agents/bmad-orchestrator.txt +++ b/bundles/agents/bmad-orchestrator.txt @@ -551,7 +551,7 @@ BMad transforms you into a "Vibe CEO" - directing a team of specialized AI agent **Best for**: ChatGPT, Claude, Gemini users who want to start immediately -1. Navigate to `dist/teams/` +1. Navigate to `bundles/teams/` 2. Copy `team-fullstack.txt` content 3. Create new Gemini Gem or CustomGPT 4. Upload file with instructions: "Your critical operating instructions are attached, do not break character as directed" @@ -871,8 +871,8 @@ The BMad-Method is built around a modular architecture centered on the `bmad-cor #### Web UI Environment -- Uses pre-built bundles from `dist/teams` for stand alone 1 upload files for all agents and their assets with an orchestrating agent -- Single text files containing all agent dependencies are in `dist/agents/` - these are unnecessary unless you want to create a web agent that is only a single agent and not a team +- Uses pre-built bundles from `bundles/teams` for stand alone 1 upload files for all agents and their assets with an orchestrating agent +- Single text files containing all agent dependencies are in `bundles/agents/` - these are unnecessary unless you want to create a web agent that is only a single agent and not a team - Created by the web-builder tool for upload to web interfaces - Provides complete context in one package @@ -1019,7 +1019,7 @@ Each status change requires user verification and approval before proceeding. #### Greenfield Development - Business analysis and market research -- Product requirements and feature definition +- Product requirements and feature definition - System architecture and design - Development execution - Testing and deployment @@ -1128,7 +1128,7 @@ Templates with Level 2 headings (`##`) can be automatically sharded: ```markdown ## Goals and Background Context -## Requirements +## Requirements ## User Interface Design Goals ## Success Metrics ``` diff --git a/dist/agents/dev.txt b/bundles/agents/dev.txt similarity index 100% rename from dist/agents/dev.txt rename to bundles/agents/dev.txt diff --git a/dist/agents/pm.txt b/bundles/agents/pm.txt similarity index 100% rename from dist/agents/pm.txt rename to bundles/agents/pm.txt diff --git a/dist/agents/po.txt b/bundles/agents/po.txt similarity index 100% rename from dist/agents/po.txt rename to bundles/agents/po.txt diff --git a/dist/agents/qa.txt b/bundles/agents/qa.txt similarity index 100% rename from dist/agents/qa.txt rename to bundles/agents/qa.txt diff --git a/dist/agents/sm.txt b/bundles/agents/sm.txt similarity index 100% rename from dist/agents/sm.txt rename to bundles/agents/sm.txt diff --git a/dist/agents/ux-expert.txt b/bundles/agents/ux-expert.txt similarity index 100% rename from dist/agents/ux-expert.txt rename to bundles/agents/ux-expert.txt diff --git a/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-designer.txt b/bundles/expansion-packs/bmad-2d-phaser-game-dev/agents/game-designer.txt similarity index 100% rename from dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-designer.txt rename to bundles/expansion-packs/bmad-2d-phaser-game-dev/agents/game-designer.txt diff --git a/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-developer.txt b/bundles/expansion-packs/bmad-2d-phaser-game-dev/agents/game-developer.txt similarity index 98% rename from dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-developer.txt rename to bundles/expansion-packs/bmad-2d-phaser-game-dev/agents/game-developer.txt index 3f86f40fc..ef4058375 100644 --- a/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-developer.txt +++ b/bundles/expansion-packs/bmad-2d-phaser-game-dev/agents/game-developer.txt @@ -214,7 +214,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive game architecture document specifically for Phaser 3 + TypeScript projects. This should provide the technical foundation for all game development stories and epics. - + If available, review any provided documents: Game Design Document (GDD), Technical Preferences. This architecture should support all game mechanics defined in the GDD. - id: introduction @@ -222,7 +222,7 @@ sections: instruction: Establish the document's purpose and scope for game development content: | This document outlines the complete technical architecture for {{game_title}}, a 2D game built with Phaser 3 and TypeScript. It serves as the technical foundation for AI-driven game development, ensuring consistency and scalability across all game systems. - + This architecture is designed to support the gameplay mechanics defined in the Game Design Document while maintaining 60 FPS performance and cross-platform compatibility. sections: - id: change-log @@ -241,7 +241,7 @@ sections: title: Architecture Summary instruction: | Provide a comprehensive overview covering: - + - Game engine choice and configuration - Project structure and organization - Key systems and their interactions @@ -294,7 +294,7 @@ sections: ├── docs/ # Documentation │ ├── stories/ # Development stories │ └── architecture/ # Technical docs - └── dist/ # Built game files + └── bundles/ # Built game files - id: module-organization title: Module Organization instruction: Define how TypeScript modules should be organized @@ -329,23 +329,23 @@ sections: title: Scene Management System template: | **Purpose:** Handle game flow and scene transitions - + **Key Components:** - + - Scene loading and unloading - Data passing between scenes - Transition effects - Memory management - + **Implementation Requirements:** - + - Preload scene for asset loading - Menu system with navigation - Gameplay scenes with state management - Pause/resume functionality - + **Files to Create:** - + - `src/scenes/BootScene.ts` - `src/scenes/PreloadScene.ts` - `src/scenes/MenuScene.ts` @@ -355,23 +355,23 @@ sections: title: Game State Management template: | **Purpose:** Track player progress and game status - + **State Categories:** - + - Player progress (levels, unlocks) - Game settings (audio, controls) - Session data (current level, score) - Persistent data (achievements, statistics) - + **Implementation Requirements:** - + - Save/load system with localStorage - State validation and error recovery - Cross-session data persistence - Settings management - + **Files to Create:** - + - `src/systems/GameState.ts` - `src/systems/SaveManager.ts` - `src/types/GameData.ts` @@ -379,23 +379,23 @@ sections: title: Asset Management System template: | **Purpose:** Efficient loading and management of game assets - + **Asset Categories:** - + - Sprite sheets and animations - Audio files and music - Level data and configurations - UI assets and fonts - + **Implementation Requirements:** - + - Progressive loading strategy - Asset caching and optimization - Error handling for failed loads - Memory management for large assets - + **Files to Create:** - + - `src/systems/AssetManager.ts` - `src/config/AssetConfig.ts` - `src/utils/AssetLoader.ts` @@ -403,23 +403,23 @@ sections: title: Input Management System template: | **Purpose:** Handle all player input across platforms - + **Input Types:** - + - Keyboard controls - Mouse/pointer interaction - Touch gestures (mobile) - Gamepad support (optional) - + **Implementation Requirements:** - + - Input mapping and configuration - Touch-friendly mobile controls - Input buffering for responsive gameplay - Customizable control schemes - + **Files to Create:** - + - `src/systems/InputManager.ts` - `src/utils/TouchControls.ts` - `src/types/InputTypes.ts` @@ -432,19 +432,19 @@ sections: title: "{{mechanic_name}} System" template: | **Purpose:** {{system_purpose}} - + **Core Functionality:** - + - {{feature_1}} - {{feature_2}} - {{feature_3}} - + **Dependencies:** {{required_systems}} - + **Performance Considerations:** {{optimization_notes}} - + **Files to Create:** - + - `src/systems/{{system_name}}.ts` - `src/gameObjects/{{related_object}}.ts` - `src/types/{{system_types}}.ts` @@ -452,65 +452,65 @@ sections: title: Physics & Collision System template: | **Physics Engine:** {{physics_choice}} (Arcade Physics/Matter.js) - + **Collision Categories:** - + - Player collision - Enemy interactions - Environmental objects - Collectibles and items - + **Implementation Requirements:** - + - Optimized collision detection - Physics body management - Collision callbacks and events - Performance monitoring - + **Files to Create:** - + - `src/systems/PhysicsManager.ts` - `src/utils/CollisionGroups.ts` - id: audio-system title: Audio System template: | **Audio Requirements:** - + - Background music with looping - Sound effects for actions - Audio settings and volume control - Mobile audio optimization - + **Implementation Features:** - + - Audio sprite management - Dynamic music system - Spatial audio (if applicable) - Audio pooling for performance - + **Files to Create:** - + - `src/systems/AudioManager.ts` - `src/config/AudioConfig.ts` - id: ui-system title: UI System template: | **UI Components:** - + - HUD elements (score, health, etc.) - Menu navigation - Modal dialogs - Settings screens - + **Implementation Requirements:** - + - Responsive layout system - Touch-friendly interface - Keyboard navigation support - Animation and transitions - + **Files to Create:** - + - `src/systems/UIManager.ts` - `src/gameObjects/UI/` - `src/types/UITypes.ts` diff --git a/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-sm.txt b/bundles/expansion-packs/bmad-2d-phaser-game-dev/agents/game-sm.txt similarity index 100% rename from dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-sm.txt rename to bundles/expansion-packs/bmad-2d-phaser-game-dev/agents/game-sm.txt diff --git a/dist/expansion-packs/bmad-2d-phaser-game-dev/teams/phaser-2d-nodejs-game-team.txt b/bundles/expansion-packs/bmad-2d-phaser-game-dev/teams/phaser-2d-nodejs-game-team.txt similarity index 98% rename from dist/expansion-packs/bmad-2d-phaser-game-dev/teams/phaser-2d-nodejs-game-team.txt rename to bundles/expansion-packs/bmad-2d-phaser-game-dev/teams/phaser-2d-nodejs-game-team.txt index 36536fb72..b56014c10 100644 --- a/dist/expansion-packs/bmad-2d-phaser-game-dev/teams/phaser-2d-nodejs-game-team.txt +++ b/bundles/expansion-packs/bmad-2d-phaser-game-dev/teams/phaser-2d-nodejs-game-team.txt @@ -463,7 +463,7 @@ If user selects Option 1, present numbered list of techniques from the brainstor 1. Apply selected technique according to data file description 2. Keep engaging with technique until user indicates they want to: - Choose a different technique - - Apply current ideas to a new technique + - Apply current ideas to a new technique - Move to convergent phase - End session @@ -1441,12 +1441,12 @@ sections: - id: introduction instruction: | This template guides creation of a comprehensive Project Brief that serves as the foundational input for product development. - + Start by asking the user which mode they prefer: - + 1. **Interactive Mode** - Work through each section collaboratively 2. **YOLO Mode** - Generate complete draft for review and refinement - + Before beginning, understand what inputs are available (brainstorming results, market research, competitive analysis, initial ideas) and gather project context. - id: executive-summary @@ -1767,7 +1767,7 @@ sections: instruction: Map the end-to-end customer experience for primary segments template: | For primary customer segment: - + 1. **Awareness:** {{discovery_process}} 2. **Consideration:** {{evaluation_criteria}} 3. **Purchase:** {{decision_triggers}} @@ -1968,7 +1968,7 @@ sections: title: Competitor Prioritization Matrix instruction: | Help categorize competitors by market share and strategic threat level - + Create a 2x2 matrix: - Priority 1 (Core Competitors): High Market Share + High Threat - Priority 2 (Emerging Threats): Low Market Share + High Threat @@ -2072,7 +2072,7 @@ sections: title: Positioning Map instruction: | Describe competitor positions on key dimensions - + Create a positioning description using 2 key dimensions relevant to the market, such as: - Price vs. Features - Ease of Use vs. Power @@ -2107,7 +2107,7 @@ sections: title: Blue Ocean Opportunities instruction: | Identify uncontested market spaces - + List opportunities to create new market space: - Underserved segments - Unaddressed use cases @@ -2211,11 +2211,11 @@ sections: - id: summary-details template: | **Topic:** {{session_topic}} - + **Session Goals:** {{stated_goals}} - + **Techniques Used:** {{techniques_list}} - + **Total Ideas Generated:** {{total_ideas}} - id: key-themes title: "Key Themes Identified:" @@ -2340,7 +2340,7 @@ sections: - id: footer content: | --- - + *Session facilitated using the BMAD-METHOD brainstorming framework* ==================== END: .bmad-2d-phaser-game-dev/templates/brainstorming-output-tmpl.yaml ==================== @@ -3351,7 +3351,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive Game Design Document that will serve as the foundation for all game development work. The GDD should be detailed enough that developers can create user stories and epics from it. Focus on gameplay systems, mechanics, and technical requirements that can be broken down into implementable features. - + If available, review any provided documents or ask if any are optionally available: Project Brief, Market Research, Competitive Analysis - id: executive-summary @@ -3396,7 +3396,7 @@ sections: instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions. template: | **Primary Loop ({{duration}} seconds):** - + 1. {{action_1}} ({{time_1}}s) 2. {{action_2}} ({{time_2}}s) 3. {{action_3}} ({{time_3}}s) @@ -3406,12 +3406,12 @@ sections: instruction: Clearly define success and failure states template: | **Victory Conditions:** - + - {{win_condition_1}} - {{win_condition_2}} - + **Failure States:** - + - {{loss_condition_1}} - {{loss_condition_2}} @@ -3427,17 +3427,17 @@ sections: title: "{{mechanic_name}}" template: | **Description:** {{detailed_description}} - + **Player Input:** {{input_method}} - + **System Response:** {{game_response}} - + **Implementation Notes:** - + - {{tech_requirement_1}} - {{tech_requirement_2}} - {{performance_consideration}} - + **Dependencies:** {{other_mechanics_needed}} - id: controls title: Controls @@ -3456,9 +3456,9 @@ sections: title: Player Progression template: | **Progression Type:** {{linear|branching|metroidvania}} - + **Key Milestones:** - + 1. **{{milestone_1}}** - {{unlock_description}} 2. **{{milestone_2}}** - {{unlock_description}} 3. **{{milestone_3}}** - {{unlock_description}} @@ -3495,9 +3495,9 @@ sections: **Duration:** {{target_time}} **Key Elements:** {{required_mechanics}} **Difficulty:** {{relative_difficulty}} - + **Structure Template:** - + - Introduction: {{intro_description}} - Challenge: {{main_challenge}} - Resolution: {{completion_requirement}} @@ -3523,13 +3523,13 @@ sections: title: Platform Specific template: | **Desktop:** - + - Resolution: {{min_resolution}} - {{max_resolution}} - Input: Keyboard, Mouse, Gamepad - Browser: Chrome 80+, Firefox 75+, Safari 13+ - + **Mobile:** - + - Resolution: {{mobile_min}} - {{mobile_max}} - Input: Touch, Tilt (optional) - OS: iOS 13+, Android 8+ @@ -3538,14 +3538,14 @@ sections: instruction: Define asset specifications for the art and audio teams template: | **Visual Assets:** - + - Art Style: {{style_description}} - Color Palette: {{color_specification}} - Animation: {{animation_requirements}} - UI Resolution: {{ui_specs}} - + **Audio Assets:** - + - Music Style: {{music_genre}} - Sound Effects: {{sfx_requirements}} - Voice Acting: {{voice_needs}} @@ -3558,7 +3558,7 @@ sections: title: Engine Configuration template: | **Phaser 3 Setup:** - + - TypeScript: Strict mode enabled - Physics: {{physics_system}} (Arcade/Matter) - Renderer: WebGL with Canvas fallback @@ -3567,7 +3567,7 @@ sections: title: Code Architecture template: | **Required Systems:** - + - Scene Management - State Management - Asset Loading @@ -3579,7 +3579,7 @@ sections: title: Data Management template: | **Save Data:** - + - Progress tracking - Settings persistence - Statistics collection @@ -3697,7 +3697,7 @@ sections: - id: initial-setup instruction: | This template creates comprehensive level design documentation that guides both content creation and technical implementation. This document should provide enough detail for developers to create level loading systems and for designers to create specific levels. - + If available, review: Game Design Document (GDD), Game Architecture Document. This document should align with the game mechanics and technical systems defined in those documents. - id: introduction @@ -3705,7 +3705,7 @@ sections: instruction: Establish the purpose and scope of level design for this game content: | This document defines the level design framework for {{game_title}}, providing guidelines for creating engaging, balanced levels that support the core gameplay mechanics defined in the Game Design Document. - + This framework ensures consistency across all levels while providing flexibility for creative level design within established technical and design constraints. sections: - id: change-log @@ -3752,29 +3752,29 @@ sections: title: "{{category_name}} Levels" template: | **Purpose:** {{gameplay_purpose}} - + **Target Duration:** {{min_time}} - {{max_time}} minutes - + **Difficulty Range:** {{difficulty_scale}} - + **Key Mechanics Featured:** - + - {{mechanic_1}} - {{usage_description}} - {{mechanic_2}} - {{usage_description}} - + **Player Objectives:** - + - Primary: {{primary_objective}} - Secondary: {{secondary_objective}} - Hidden: {{secret_objective}} - + **Success Criteria:** - + - {{completion_requirement_1}} - {{completion_requirement_2}} - + **Technical Requirements:** - + - Maximum entities: {{entity_limit}} - Performance target: {{fps_target}} FPS - Memory budget: {{memory_limit}}MB @@ -3789,11 +3789,11 @@ sections: instruction: Based on GDD requirements, define the overall level organization template: | **Organization Type:** {{linear|hub_world|open_world}} - + **Total Level Count:** {{number}} - + **World Breakdown:** - + - World 1: {{level_count}} levels - {{theme}} - {{difficulty_range}} - World 2: {{level_count}} levels - {{theme}} - {{difficulty_range}} - World 3: {{level_count}} levels - {{theme}} - {{difficulty_range}} @@ -3828,7 +3828,7 @@ sections: instruction: Define how players access new levels template: | **Progression Gates:** - + - Linear progression: Complete previous level - Star requirements: {{star_count}} stars to unlock - Skill gates: Demonstrate {{skill_requirement}} @@ -3843,17 +3843,17 @@ sections: instruction: Define all environmental components that can be used in levels template: | **Terrain Types:** - + - {{terrain_1}}: {{properties_and_usage}} - {{terrain_2}}: {{properties_and_usage}} - + **Interactive Objects:** - + - {{object_1}}: {{behavior_and_purpose}} - {{object_2}}: {{behavior_and_purpose}} - + **Hazards and Obstacles:** - + - {{hazard_1}}: {{damage_and_behavior}} - {{hazard_2}}: {{damage_and_behavior}} - id: collectibles-rewards @@ -3861,18 +3861,18 @@ sections: instruction: Define all collectible items and their placement rules template: | **Collectible Types:** - + - {{collectible_1}}: {{value_and_purpose}} - {{collectible_2}}: {{value_and_purpose}} - + **Placement Guidelines:** - + - Mandatory collectibles: {{placement_rules}} - Optional collectibles: {{placement_rules}} - Secret collectibles: {{placement_rules}} - + **Reward Distribution:** - + - Easy to find: {{percentage}}% - Moderate challenge: {{percentage}}% - High skill required: {{percentage}}% @@ -3881,18 +3881,18 @@ sections: instruction: Define how enemies should be placed and balanced in levels template: | **Enemy Categories:** - + - {{enemy_type_1}}: {{behavior_and_usage}} - {{enemy_type_2}}: {{behavior_and_usage}} - + **Placement Principles:** - + - Introduction encounters: {{guideline}} - Standard encounters: {{guideline}} - Challenge encounters: {{guideline}} - + **Difficulty Scaling:** - + - Enemy count progression: {{scaling_rule}} - Enemy type introduction: {{pacing_rule}} - Encounter complexity: {{complexity_rule}} @@ -3905,14 +3905,14 @@ sections: title: Level Layout Principles template: | **Spatial Design:** - + - Grid size: {{grid_dimensions}} - Minimum path width: {{width_units}} - Maximum vertical distance: {{height_units}} - Safe zones placement: {{safety_guidelines}} - + **Navigation Design:** - + - Clear path indication: {{visual_cues}} - Landmark placement: {{landmark_rules}} - Dead end avoidance: {{dead_end_policy}} @@ -3922,13 +3922,13 @@ sections: instruction: Define how to control the rhythm and pace of gameplay within levels template: | **Action Sequences:** - + - High intensity duration: {{max_duration}} - Rest period requirement: {{min_rest_time}} - Intensity variation: {{pacing_pattern}} - + **Learning Sequences:** - + - New mechanic introduction: {{teaching_method}} - Practice opportunity: {{practice_duration}} - Skill application: {{application_context}} @@ -3937,14 +3937,14 @@ sections: instruction: Define how to create appropriate challenges for each level type template: | **Challenge Types:** - + - Execution challenges: {{skill_requirements}} - Puzzle challenges: {{complexity_guidelines}} - Time challenges: {{time_pressure_rules}} - Resource challenges: {{resource_management}} - + **Difficulty Calibration:** - + - Skill check frequency: {{frequency_guidelines}} - Failure recovery: {{retry_mechanics}} - Hint system integration: {{help_system}} @@ -3958,7 +3958,7 @@ sections: instruction: Define how level data should be structured for implementation template: | **Level File Format:** - + - Data format: {{json|yaml|custom}} - File naming: `level_{{world}}_{{number}}.{{extension}}` - Data organization: {{structure_description}} @@ -3996,14 +3996,14 @@ sections: instruction: Define how level assets are organized and loaded template: | **Tilemap Requirements:** - + - Tile size: {{tile_dimensions}}px - Tileset organization: {{tileset_structure}} - Layer organization: {{layer_system}} - Collision data: {{collision_format}} - + **Audio Integration:** - + - Background music: {{music_requirements}} - Ambient sounds: {{ambient_system}} - Dynamic audio: {{dynamic_audio_rules}} @@ -4012,19 +4012,19 @@ sections: instruction: Define performance requirements for level systems template: | **Entity Limits:** - + - Maximum active entities: {{entity_limit}} - Maximum particles: {{particle_limit}} - Maximum audio sources: {{audio_limit}} - + **Memory Management:** - + - Texture memory budget: {{texture_memory}}MB - Audio memory budget: {{audio_memory}}MB - Level loading time: <{{load_time}}s - + **Culling and LOD:** - + - Off-screen culling: {{culling_distance}} - Level-of-detail rules: {{lod_system}} - Asset streaming: {{streaming_requirements}} @@ -4037,13 +4037,13 @@ sections: title: Automated Testing template: | **Performance Testing:** - + - Frame rate validation: Maintain {{fps_target}} FPS - Memory usage monitoring: Stay under {{memory_limit}}MB - Loading time verification: Complete in <{{load_time}}s - + **Gameplay Testing:** - + - Completion path validation: All objectives achievable - Collectible accessibility: All items reachable - Softlock prevention: No unwinnable states @@ -4071,14 +4071,14 @@ sections: title: Balance Validation template: | **Metrics Collection:** - + - Completion rate: Target {{completion_percentage}}% - Average completion time: {{target_time}} ± {{variance}} - Death count per level: <{{max_deaths}} - Collectible discovery rate: {{discovery_percentage}}% - + **Iteration Guidelines:** - + - Adjustment criteria: {{criteria_for_changes}} - Testing sample size: {{minimum_testers}} - Validation period: {{testing_duration}} @@ -4091,14 +4091,14 @@ sections: title: Design Phase template: | **Concept Development:** - + 1. Define level purpose and goals 2. Create rough layout sketch 3. Identify key mechanics and challenges 4. Estimate difficulty and duration - + **Documentation Requirements:** - + - Level design brief - Layout diagrams - Mechanic integration notes @@ -4107,15 +4107,15 @@ sections: title: Implementation Phase template: | **Technical Implementation:** - + 1. Create level data file 2. Build tilemap and layout 3. Place entities and objects 4. Configure level logic and triggers 5. Integrate audio and visual effects - + **Quality Assurance:** - + 1. Automated testing execution 2. Internal playtesting 3. Performance validation @@ -4124,14 +4124,14 @@ sections: title: Integration Phase template: | **Game Integration:** - + 1. Level progression integration 2. Save system compatibility 3. Analytics integration 4. Achievement system integration - + **Final Validation:** - + 1. Full game context testing 2. Performance regression testing 3. Platform compatibility verification @@ -4184,7 +4184,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document. - + This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design. - id: game-vision @@ -4241,7 +4241,7 @@ sections: repeatable: true template: | **Core Mechanic: {{mechanic_name}}** - + - **Description:** {{how_it_works}} - **Player Value:** {{why_its_fun}} - **Implementation Scope:** {{complexity_estimate}} @@ -4268,12 +4268,12 @@ sections: title: Technical Constraints template: | **Platform Requirements:** - + - Primary: {{platform_1}} - {{requirements}} - Secondary: {{platform_2}} - {{requirements}} - + **Technical Specifications:** - + - Engine: Phaser 3 + TypeScript - Performance Target: {{fps_target}} FPS on {{target_device}} - Memory Budget: <{{memory_limit}}MB @@ -4311,10 +4311,10 @@ sections: title: Competitive Analysis template: | **Direct Competitors:** - + - {{competitor_1}}: {{strengths_and_weaknesses}} - {{competitor_2}}: {{strengths_and_weaknesses}} - + **Differentiation Strategy:** {{how_we_differ_and_why_thats_valuable}} - id: market-opportunity @@ -4338,16 +4338,16 @@ sections: title: Content Categories template: | **Core Content:** - + - {{content_type_1}}: {{quantity_and_description}} - {{content_type_2}}: {{quantity_and_description}} - + **Optional Content:** - + - {{optional_content_type}}: {{quantity_and_description}} - + **Replay Elements:** - + - {{replayability_features}} - id: difficulty-accessibility title: Difficulty and Accessibility @@ -4414,13 +4414,13 @@ sections: title: Player Experience Metrics template: | **Engagement Goals:** - + - Tutorial completion rate: >{{percentage}}% - Average session length: {{duration}} minutes - Player retention: D1 {{d1}}%, D7 {{d7}}%, D30 {{d30}}% - + **Quality Benchmarks:** - + - Player satisfaction: >{{rating}}/10 - Completion rate: >{{percentage}}% - Technical performance: {{fps_target}} FPS consistent @@ -4428,13 +4428,13 @@ sections: title: Development Metrics template: | **Technical Targets:** - + - Zero critical bugs at launch - Performance targets met on all platforms - Load times under {{seconds}}s - + **Process Goals:** - + - Development timeline adherence - Feature scope completion - Quality assurance standards @@ -4443,7 +4443,7 @@ sections: condition: has_business_goals template: | **Commercial Goals:** - + - {{revenue_target}} in first {{time_period}} - {{user_acquisition_target}} players in first {{time_period}} - {{retention_target}} monthly active users @@ -4496,12 +4496,12 @@ sections: title: Validation Plan template: | **Concept Testing:** - + - {{validation_method_1}} - {{timeline}} - {{validation_method_2}} - {{timeline}} - + **Prototype Testing:** - + - {{testing_approach}} - {{timeline}} - {{feedback_collection_method}} - {{timeline}} @@ -4747,7 +4747,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive game architecture document specifically for Phaser 3 + TypeScript projects. This should provide the technical foundation for all game development stories and epics. - + If available, review any provided documents: Game Design Document (GDD), Technical Preferences. This architecture should support all game mechanics defined in the GDD. - id: introduction @@ -4755,7 +4755,7 @@ sections: instruction: Establish the document's purpose and scope for game development content: | This document outlines the complete technical architecture for {{game_title}}, a 2D game built with Phaser 3 and TypeScript. It serves as the technical foundation for AI-driven game development, ensuring consistency and scalability across all game systems. - + This architecture is designed to support the gameplay mechanics defined in the Game Design Document while maintaining 60 FPS performance and cross-platform compatibility. sections: - id: change-log @@ -4774,7 +4774,7 @@ sections: title: Architecture Summary instruction: | Provide a comprehensive overview covering: - + - Game engine choice and configuration - Project structure and organization - Key systems and their interactions @@ -4827,7 +4827,7 @@ sections: ├── docs/ # Documentation │ ├── stories/ # Development stories │ └── architecture/ # Technical docs - └── dist/ # Built game files + └── bundles/ # Built game files - id: module-organization title: Module Organization instruction: Define how TypeScript modules should be organized @@ -4862,23 +4862,23 @@ sections: title: Scene Management System template: | **Purpose:** Handle game flow and scene transitions - + **Key Components:** - + - Scene loading and unloading - Data passing between scenes - Transition effects - Memory management - + **Implementation Requirements:** - + - Preload scene for asset loading - Menu system with navigation - Gameplay scenes with state management - Pause/resume functionality - + **Files to Create:** - + - `src/scenes/BootScene.ts` - `src/scenes/PreloadScene.ts` - `src/scenes/MenuScene.ts` @@ -4888,23 +4888,23 @@ sections: title: Game State Management template: | **Purpose:** Track player progress and game status - + **State Categories:** - + - Player progress (levels, unlocks) - Game settings (audio, controls) - Session data (current level, score) - Persistent data (achievements, statistics) - + **Implementation Requirements:** - + - Save/load system with localStorage - State validation and error recovery - Cross-session data persistence - Settings management - + **Files to Create:** - + - `src/systems/GameState.ts` - `src/systems/SaveManager.ts` - `src/types/GameData.ts` @@ -4912,23 +4912,23 @@ sections: title: Asset Management System template: | **Purpose:** Efficient loading and management of game assets - + **Asset Categories:** - + - Sprite sheets and animations - Audio files and music - Level data and configurations - UI assets and fonts - + **Implementation Requirements:** - + - Progressive loading strategy - Asset caching and optimization - Error handling for failed loads - Memory management for large assets - + **Files to Create:** - + - `src/systems/AssetManager.ts` - `src/config/AssetConfig.ts` - `src/utils/AssetLoader.ts` @@ -4936,23 +4936,23 @@ sections: title: Input Management System template: | **Purpose:** Handle all player input across platforms - + **Input Types:** - + - Keyboard controls - Mouse/pointer interaction - Touch gestures (mobile) - Gamepad support (optional) - + **Implementation Requirements:** - + - Input mapping and configuration - Touch-friendly mobile controls - Input buffering for responsive gameplay - Customizable control schemes - + **Files to Create:** - + - `src/systems/InputManager.ts` - `src/utils/TouchControls.ts` - `src/types/InputTypes.ts` @@ -4965,19 +4965,19 @@ sections: title: "{{mechanic_name}} System" template: | **Purpose:** {{system_purpose}} - + **Core Functionality:** - + - {{feature_1}} - {{feature_2}} - {{feature_3}} - + **Dependencies:** {{required_systems}} - + **Performance Considerations:** {{optimization_notes}} - + **Files to Create:** - + - `src/systems/{{system_name}}.ts` - `src/gameObjects/{{related_object}}.ts` - `src/types/{{system_types}}.ts` @@ -4985,65 +4985,65 @@ sections: title: Physics & Collision System template: | **Physics Engine:** {{physics_choice}} (Arcade Physics/Matter.js) - + **Collision Categories:** - + - Player collision - Enemy interactions - Environmental objects - Collectibles and items - + **Implementation Requirements:** - + - Optimized collision detection - Physics body management - Collision callbacks and events - Performance monitoring - + **Files to Create:** - + - `src/systems/PhysicsManager.ts` - `src/utils/CollisionGroups.ts` - id: audio-system title: Audio System template: | **Audio Requirements:** - + - Background music with looping - Sound effects for actions - Audio settings and volume control - Mobile audio optimization - + **Implementation Features:** - + - Audio sprite management - Dynamic music system - Spatial audio (if applicable) - Audio pooling for performance - + **Files to Create:** - + - `src/systems/AudioManager.ts` - `src/config/AudioConfig.ts` - id: ui-system title: UI System template: | **UI Components:** - + - HUD elements (score, health, etc.) - Menu navigation - Modal dialogs - Settings screens - + **Implementation Requirements:** - + - Responsive layout system - Touch-friendly interface - Keyboard navigation support - Animation and transitions - + **Files to Create:** - + - `src/systems/UIManager.ts` - `src/gameObjects/UI/` - `src/types/UITypes.ts` @@ -6399,21 +6399,21 @@ sections: - id: initial-setup instruction: | This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality. - + Before starting, ensure you have access to: - + - Game Design Document (GDD) - Game Architecture Document - Any existing stories in this epic - + The story should be specific enough that a developer can implement it without requiring additional design decisions. - id: story-header content: | - **Epic:** {{epic_name}} - **Story ID:** {{story_id}} - **Priority:** {{High|Medium|Low}} - **Points:** {{story_points}} + **Epic:** {{epic_name}} + **Story ID:** {{story_id}} + **Priority:** {{High|Medium|Low}} + **Points:** {{story_points}} **Status:** Draft - id: description @@ -6454,12 +6454,12 @@ sections: title: Files to Create/Modify template: | **New Files:** - + - `{{file_path_1}}` - {{purpose}} - `{{file_path_2}}` - {{purpose}} - + **Modified Files:** - + - `{{existing_file_1}}` - {{changes_needed}} - `{{existing_file_2}}` - {{changes_needed}} - id: class-interface-definitions @@ -6474,15 +6474,15 @@ sections: {{property_2}}: {{type}}; {{method_1}}({{params}}): {{return_type}}; } - + // {{class_name}} class {{class_name}} extends {{phaser_class}} { private {{property}}: {{type}}; - + constructor({{params}}) { // Implementation requirements } - + public {{method}}({{params}}): {{return_type}} { // Method requirements } @@ -6492,15 +6492,15 @@ sections: instruction: Specify how this feature integrates with existing systems template: | **Scene Integration:** - + - {{scene_name}}: {{integration_details}} - + **System Dependencies:** - + - {{system_name}}: {{dependency_description}} - + **Event Communication:** - + - Emits: `{{event_name}}` when {{condition}} - Listens: `{{event_name}}` to {{response}} @@ -6512,7 +6512,7 @@ sections: title: Dev Agent Record template: | **Tasks:** - + - [ ] {{task_1_description}} - [ ] {{task_2_description}} - [ ] {{task_3_description}} @@ -6520,18 +6520,18 @@ sections: - [ ] Write unit tests for {{component}} - [ ] Integration testing with {{related_system}} - [ ] Performance testing and optimization - + **Debug Log:** | Task | File | Change | Reverted? | |------|------|--------|-----------| | | | | | - + **Completion Notes:** - + - + **Change Log:** - + - id: game-design-context @@ -6539,13 +6539,13 @@ sections: instruction: Reference the specific sections of the GDD that this story implements template: | **GDD Reference:** {{section_name}} ({{page_or_section_number}}) - + **Game Mechanic:** {{mechanic_name}} - + **Player Experience Goal:** {{experience_description}} - + **Balance Parameters:** - + - {{parameter_1}}: {{value_or_range}} - {{parameter_2}}: {{value_or_range}} @@ -6557,11 +6557,11 @@ sections: title: Unit Tests template: | **Test Files:** - + - `tests/{{component_name}}.test.ts` - + **Test Scenarios:** - + - {{test_scenario_1}} - {{test_scenario_2}} - {{edge_case_test}} @@ -6569,12 +6569,12 @@ sections: title: Game Testing template: | **Manual Test Cases:** - + 1. {{test_case_1_description}} - + - Expected: {{expected_behavior}} - Performance: {{performance_expectation}} - + 2. {{test_case_2_description}} - Expected: {{expected_behavior}} - Edge Case: {{edge_case_handling}} @@ -6582,7 +6582,7 @@ sections: title: Performance Tests template: | **Metrics to Verify:** - + - Frame rate maintains {{fps_target}} FPS - Memory usage stays under {{memory_limit}}MB - {{feature_specific_performance_metric}} @@ -6592,15 +6592,15 @@ sections: instruction: List any dependencies that must be completed before this story can be implemented template: | **Story Dependencies:** - + - {{story_id}}: {{dependency_description}} - + **Technical Dependencies:** - + - {{system_or_file}}: {{requirement}} - + **Asset Dependencies:** - + - {{asset_type}}: {{asset_description}} - Location: `{{asset_path}}` @@ -6623,17 +6623,17 @@ sections: instruction: Any additional context, design decisions, or implementation notes template: | **Implementation Notes:** - + - {{note_1}} - {{note_2}} - + **Design Decisions:** - + - {{decision_1}}: {{rationale}} - {{decision_2}}: {{rationale}} - + **Future Considerations:** - + - {{future_enhancement_1}} - {{future_optimization_1}} ==================== END: .bmad-2d-phaser-game-dev/templates/game-story-tmpl.yaml ==================== @@ -6655,7 +6655,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive game architecture document specifically for Phaser 3 + TypeScript projects. This should provide the technical foundation for all game development stories and epics. - + If available, review any provided documents: Game Design Document (GDD), Technical Preferences. This architecture should support all game mechanics defined in the GDD. - id: introduction @@ -6663,7 +6663,7 @@ sections: instruction: Establish the document's purpose and scope for game development content: | This document outlines the complete technical architecture for {{game_title}}, a 2D game built with Phaser 3 and TypeScript. It serves as the technical foundation for AI-driven game development, ensuring consistency and scalability across all game systems. - + This architecture is designed to support the gameplay mechanics defined in the Game Design Document while maintaining 60 FPS performance and cross-platform compatibility. sections: - id: change-log @@ -6682,7 +6682,7 @@ sections: title: Architecture Summary instruction: | Provide a comprehensive overview covering: - + - Game engine choice and configuration - Project structure and organization - Key systems and their interactions @@ -6735,7 +6735,7 @@ sections: ├── docs/ # Documentation │ ├── stories/ # Development stories │ └── architecture/ # Technical docs - └── dist/ # Built game files + └── bundles/ # Built game files - id: module-organization title: Module Organization instruction: Define how TypeScript modules should be organized @@ -6770,23 +6770,23 @@ sections: title: Scene Management System template: | **Purpose:** Handle game flow and scene transitions - + **Key Components:** - + - Scene loading and unloading - Data passing between scenes - Transition effects - Memory management - + **Implementation Requirements:** - + - Preload scene for asset loading - Menu system with navigation - Gameplay scenes with state management - Pause/resume functionality - + **Files to Create:** - + - `src/scenes/BootScene.ts` - `src/scenes/PreloadScene.ts` - `src/scenes/MenuScene.ts` @@ -6796,23 +6796,23 @@ sections: title: Game State Management template: | **Purpose:** Track player progress and game status - + **State Categories:** - + - Player progress (levels, unlocks) - Game settings (audio, controls) - Session data (current level, score) - Persistent data (achievements, statistics) - + **Implementation Requirements:** - + - Save/load system with localStorage - State validation and error recovery - Cross-session data persistence - Settings management - + **Files to Create:** - + - `src/systems/GameState.ts` - `src/systems/SaveManager.ts` - `src/types/GameData.ts` @@ -6820,23 +6820,23 @@ sections: title: Asset Management System template: | **Purpose:** Efficient loading and management of game assets - + **Asset Categories:** - + - Sprite sheets and animations - Audio files and music - Level data and configurations - UI assets and fonts - + **Implementation Requirements:** - + - Progressive loading strategy - Asset caching and optimization - Error handling for failed loads - Memory management for large assets - + **Files to Create:** - + - `src/systems/AssetManager.ts` - `src/config/AssetConfig.ts` - `src/utils/AssetLoader.ts` @@ -6844,23 +6844,23 @@ sections: title: Input Management System template: | **Purpose:** Handle all player input across platforms - + **Input Types:** - + - Keyboard controls - Mouse/pointer interaction - Touch gestures (mobile) - Gamepad support (optional) - + **Implementation Requirements:** - + - Input mapping and configuration - Touch-friendly mobile controls - Input buffering for responsive gameplay - Customizable control schemes - + **Files to Create:** - + - `src/systems/InputManager.ts` - `src/utils/TouchControls.ts` - `src/types/InputTypes.ts` @@ -6873,19 +6873,19 @@ sections: title: "{{mechanic_name}} System" template: | **Purpose:** {{system_purpose}} - + **Core Functionality:** - + - {{feature_1}} - {{feature_2}} - {{feature_3}} - + **Dependencies:** {{required_systems}} - + **Performance Considerations:** {{optimization_notes}} - + **Files to Create:** - + - `src/systems/{{system_name}}.ts` - `src/gameObjects/{{related_object}}.ts` - `src/types/{{system_types}}.ts` @@ -6893,65 +6893,65 @@ sections: title: Physics & Collision System template: | **Physics Engine:** {{physics_choice}} (Arcade Physics/Matter.js) - + **Collision Categories:** - + - Player collision - Enemy interactions - Environmental objects - Collectibles and items - + **Implementation Requirements:** - + - Optimized collision detection - Physics body management - Collision callbacks and events - Performance monitoring - + **Files to Create:** - + - `src/systems/PhysicsManager.ts` - `src/utils/CollisionGroups.ts` - id: audio-system title: Audio System template: | **Audio Requirements:** - + - Background music with looping - Sound effects for actions - Audio settings and volume control - Mobile audio optimization - + **Implementation Features:** - + - Audio sprite management - Dynamic music system - Spatial audio (if applicable) - Audio pooling for performance - + **Files to Create:** - + - `src/systems/AudioManager.ts` - `src/config/AudioConfig.ts` - id: ui-system title: UI System template: | **UI Components:** - + - HUD elements (score, health, etc.) - Menu navigation - Modal dialogs - Settings screens - + **Implementation Requirements:** - + - Responsive layout system - Touch-friendly interface - Keyboard navigation support - Animation and transitions - + **Files to Create:** - + - `src/systems/UIManager.ts` - `src/gameObjects/UI/` - `src/types/UITypes.ts` @@ -7271,7 +7271,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document. - + This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design. - id: game-vision @@ -7328,7 +7328,7 @@ sections: repeatable: true template: | **Core Mechanic: {{mechanic_name}}** - + - **Description:** {{how_it_works}} - **Player Value:** {{why_its_fun}} - **Implementation Scope:** {{complexity_estimate}} @@ -7355,12 +7355,12 @@ sections: title: Technical Constraints template: | **Platform Requirements:** - + - Primary: {{platform_1}} - {{requirements}} - Secondary: {{platform_2}} - {{requirements}} - + **Technical Specifications:** - + - Engine: Phaser 3 + TypeScript - Performance Target: {{fps_target}} FPS on {{target_device}} - Memory Budget: <{{memory_limit}}MB @@ -7398,10 +7398,10 @@ sections: title: Competitive Analysis template: | **Direct Competitors:** - + - {{competitor_1}}: {{strengths_and_weaknesses}} - {{competitor_2}}: {{strengths_and_weaknesses}} - + **Differentiation Strategy:** {{how_we_differ_and_why_thats_valuable}} - id: market-opportunity @@ -7425,16 +7425,16 @@ sections: title: Content Categories template: | **Core Content:** - + - {{content_type_1}}: {{quantity_and_description}} - {{content_type_2}}: {{quantity_and_description}} - + **Optional Content:** - + - {{optional_content_type}}: {{quantity_and_description}} - + **Replay Elements:** - + - {{replayability_features}} - id: difficulty-accessibility title: Difficulty and Accessibility @@ -7501,13 +7501,13 @@ sections: title: Player Experience Metrics template: | **Engagement Goals:** - + - Tutorial completion rate: >{{percentage}}% - Average session length: {{duration}} minutes - Player retention: D1 {{d1}}%, D7 {{d7}}%, D30 {{d30}}% - + **Quality Benchmarks:** - + - Player satisfaction: >{{rating}}/10 - Completion rate: >{{percentage}}% - Technical performance: {{fps_target}} FPS consistent @@ -7515,13 +7515,13 @@ sections: title: Development Metrics template: | **Technical Targets:** - + - Zero critical bugs at launch - Performance targets met on all platforms - Load times under {{seconds}}s - + **Process Goals:** - + - Development timeline adherence - Feature scope completion - Quality assurance standards @@ -7530,7 +7530,7 @@ sections: condition: has_business_goals template: | **Commercial Goals:** - + - {{revenue_target}} in first {{time_period}} - {{user_acquisition_target}} players in first {{time_period}} - {{retention_target}} monthly active users @@ -7583,12 +7583,12 @@ sections: title: Validation Plan template: | **Concept Testing:** - + - {{validation_method_1}} - {{timeline}} - {{validation_method_2}} - {{timeline}} - + **Prototype Testing:** - + - {{testing_approach}} - {{timeline}} - {{feedback_collection_method}} - {{timeline}} @@ -7630,7 +7630,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive Game Design Document that will serve as the foundation for all game development work. The GDD should be detailed enough that developers can create user stories and epics from it. Focus on gameplay systems, mechanics, and technical requirements that can be broken down into implementable features. - + If available, review any provided documents or ask if any are optionally available: Project Brief, Market Research, Competitive Analysis - id: executive-summary @@ -7675,7 +7675,7 @@ sections: instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions. template: | **Primary Loop ({{duration}} seconds):** - + 1. {{action_1}} ({{time_1}}s) 2. {{action_2}} ({{time_2}}s) 3. {{action_3}} ({{time_3}}s) @@ -7685,12 +7685,12 @@ sections: instruction: Clearly define success and failure states template: | **Victory Conditions:** - + - {{win_condition_1}} - {{win_condition_2}} - + **Failure States:** - + - {{loss_condition_1}} - {{loss_condition_2}} @@ -7706,17 +7706,17 @@ sections: title: "{{mechanic_name}}" template: | **Description:** {{detailed_description}} - + **Player Input:** {{input_method}} - + **System Response:** {{game_response}} - + **Implementation Notes:** - + - {{tech_requirement_1}} - {{tech_requirement_2}} - {{performance_consideration}} - + **Dependencies:** {{other_mechanics_needed}} - id: controls title: Controls @@ -7735,9 +7735,9 @@ sections: title: Player Progression template: | **Progression Type:** {{linear|branching|metroidvania}} - + **Key Milestones:** - + 1. **{{milestone_1}}** - {{unlock_description}} 2. **{{milestone_2}}** - {{unlock_description}} 3. **{{milestone_3}}** - {{unlock_description}} @@ -7774,9 +7774,9 @@ sections: **Duration:** {{target_time}} **Key Elements:** {{required_mechanics}} **Difficulty:** {{relative_difficulty}} - + **Structure Template:** - + - Introduction: {{intro_description}} - Challenge: {{main_challenge}} - Resolution: {{completion_requirement}} @@ -7802,13 +7802,13 @@ sections: title: Platform Specific template: | **Desktop:** - + - Resolution: {{min_resolution}} - {{max_resolution}} - Input: Keyboard, Mouse, Gamepad - Browser: Chrome 80+, Firefox 75+, Safari 13+ - + **Mobile:** - + - Resolution: {{mobile_min}} - {{mobile_max}} - Input: Touch, Tilt (optional) - OS: iOS 13+, Android 8+ @@ -7817,14 +7817,14 @@ sections: instruction: Define asset specifications for the art and audio teams template: | **Visual Assets:** - + - Art Style: {{style_description}} - Color Palette: {{color_specification}} - Animation: {{animation_requirements}} - UI Resolution: {{ui_specs}} - + **Audio Assets:** - + - Music Style: {{music_genre}} - Sound Effects: {{sfx_requirements}} - Voice Acting: {{voice_needs}} @@ -7837,7 +7837,7 @@ sections: title: Engine Configuration template: | **Phaser 3 Setup:** - + - TypeScript: Strict mode enabled - Physics: {{physics_system}} (Arcade/Matter) - Renderer: WebGL with Canvas fallback @@ -7846,7 +7846,7 @@ sections: title: Code Architecture template: | **Required Systems:** - + - Scene Management - State Management - Asset Loading @@ -7858,7 +7858,7 @@ sections: title: Data Management template: | **Save Data:** - + - Progress tracking - Settings persistence - Statistics collection @@ -7976,21 +7976,21 @@ sections: - id: initial-setup instruction: | This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality. - + Before starting, ensure you have access to: - + - Game Design Document (GDD) - Game Architecture Document - Any existing stories in this epic - + The story should be specific enough that a developer can implement it without requiring additional design decisions. - id: story-header content: | - **Epic:** {{epic_name}} - **Story ID:** {{story_id}} - **Priority:** {{High|Medium|Low}} - **Points:** {{story_points}} + **Epic:** {{epic_name}} + **Story ID:** {{story_id}} + **Priority:** {{High|Medium|Low}} + **Points:** {{story_points}} **Status:** Draft - id: description @@ -8031,12 +8031,12 @@ sections: title: Files to Create/Modify template: | **New Files:** - + - `{{file_path_1}}` - {{purpose}} - `{{file_path_2}}` - {{purpose}} - + **Modified Files:** - + - `{{existing_file_1}}` - {{changes_needed}} - `{{existing_file_2}}` - {{changes_needed}} - id: class-interface-definitions @@ -8051,15 +8051,15 @@ sections: {{property_2}}: {{type}}; {{method_1}}({{params}}): {{return_type}}; } - + // {{class_name}} class {{class_name}} extends {{phaser_class}} { private {{property}}: {{type}}; - + constructor({{params}}) { // Implementation requirements } - + public {{method}}({{params}}): {{return_type}} { // Method requirements } @@ -8069,15 +8069,15 @@ sections: instruction: Specify how this feature integrates with existing systems template: | **Scene Integration:** - + - {{scene_name}}: {{integration_details}} - + **System Dependencies:** - + - {{system_name}}: {{dependency_description}} - + **Event Communication:** - + - Emits: `{{event_name}}` when {{condition}} - Listens: `{{event_name}}` to {{response}} @@ -8089,7 +8089,7 @@ sections: title: Dev Agent Record template: | **Tasks:** - + - [ ] {{task_1_description}} - [ ] {{task_2_description}} - [ ] {{task_3_description}} @@ -8097,18 +8097,18 @@ sections: - [ ] Write unit tests for {{component}} - [ ] Integration testing with {{related_system}} - [ ] Performance testing and optimization - + **Debug Log:** | Task | File | Change | Reverted? | |------|------|--------|-----------| | | | | | - + **Completion Notes:** - + - + **Change Log:** - + - id: game-design-context @@ -8116,13 +8116,13 @@ sections: instruction: Reference the specific sections of the GDD that this story implements template: | **GDD Reference:** {{section_name}} ({{page_or_section_number}}) - + **Game Mechanic:** {{mechanic_name}} - + **Player Experience Goal:** {{experience_description}} - + **Balance Parameters:** - + - {{parameter_1}}: {{value_or_range}} - {{parameter_2}}: {{value_or_range}} @@ -8134,11 +8134,11 @@ sections: title: Unit Tests template: | **Test Files:** - + - `tests/{{component_name}}.test.ts` - + **Test Scenarios:** - + - {{test_scenario_1}} - {{test_scenario_2}} - {{edge_case_test}} @@ -8146,12 +8146,12 @@ sections: title: Game Testing template: | **Manual Test Cases:** - + 1. {{test_case_1_description}} - + - Expected: {{expected_behavior}} - Performance: {{performance_expectation}} - + 2. {{test_case_2_description}} - Expected: {{expected_behavior}} - Edge Case: {{edge_case_handling}} @@ -8159,7 +8159,7 @@ sections: title: Performance Tests template: | **Metrics to Verify:** - + - Frame rate maintains {{fps_target}} FPS - Memory usage stays under {{memory_limit}}MB - {{feature_specific_performance_metric}} @@ -8169,15 +8169,15 @@ sections: instruction: List any dependencies that must be completed before this story can be implemented template: | **Story Dependencies:** - + - {{story_id}}: {{dependency_description}} - + **Technical Dependencies:** - + - {{system_or_file}}: {{requirement}} - + **Asset Dependencies:** - + - {{asset_type}}: {{asset_description}} - Location: `{{asset_path}}` @@ -8200,17 +8200,17 @@ sections: instruction: Any additional context, design decisions, or implementation notes template: | **Implementation Notes:** - + - {{note_1}} - {{note_2}} - + **Design Decisions:** - + - {{decision_1}}: {{rationale}} - {{decision_2}}: {{rationale}} - + **Future Considerations:** - + - {{future_enhancement_1}} - {{future_optimization_1}} ==================== END: .bmad-2d-phaser-game-dev/templates/game-story-tmpl.yaml ==================== @@ -8232,7 +8232,7 @@ sections: - id: initial-setup instruction: | This template creates comprehensive level design documentation that guides both content creation and technical implementation. This document should provide enough detail for developers to create level loading systems and for designers to create specific levels. - + If available, review: Game Design Document (GDD), Game Architecture Document. This document should align with the game mechanics and technical systems defined in those documents. - id: introduction @@ -8240,7 +8240,7 @@ sections: instruction: Establish the purpose and scope of level design for this game content: | This document defines the level design framework for {{game_title}}, providing guidelines for creating engaging, balanced levels that support the core gameplay mechanics defined in the Game Design Document. - + This framework ensures consistency across all levels while providing flexibility for creative level design within established technical and design constraints. sections: - id: change-log @@ -8287,29 +8287,29 @@ sections: title: "{{category_name}} Levels" template: | **Purpose:** {{gameplay_purpose}} - + **Target Duration:** {{min_time}} - {{max_time}} minutes - + **Difficulty Range:** {{difficulty_scale}} - + **Key Mechanics Featured:** - + - {{mechanic_1}} - {{usage_description}} - {{mechanic_2}} - {{usage_description}} - + **Player Objectives:** - + - Primary: {{primary_objective}} - Secondary: {{secondary_objective}} - Hidden: {{secret_objective}} - + **Success Criteria:** - + - {{completion_requirement_1}} - {{completion_requirement_2}} - + **Technical Requirements:** - + - Maximum entities: {{entity_limit}} - Performance target: {{fps_target}} FPS - Memory budget: {{memory_limit}}MB @@ -8324,11 +8324,11 @@ sections: instruction: Based on GDD requirements, define the overall level organization template: | **Organization Type:** {{linear|hub_world|open_world}} - + **Total Level Count:** {{number}} - + **World Breakdown:** - + - World 1: {{level_count}} levels - {{theme}} - {{difficulty_range}} - World 2: {{level_count}} levels - {{theme}} - {{difficulty_range}} - World 3: {{level_count}} levels - {{theme}} - {{difficulty_range}} @@ -8363,7 +8363,7 @@ sections: instruction: Define how players access new levels template: | **Progression Gates:** - + - Linear progression: Complete previous level - Star requirements: {{star_count}} stars to unlock - Skill gates: Demonstrate {{skill_requirement}} @@ -8378,17 +8378,17 @@ sections: instruction: Define all environmental components that can be used in levels template: | **Terrain Types:** - + - {{terrain_1}}: {{properties_and_usage}} - {{terrain_2}}: {{properties_and_usage}} - + **Interactive Objects:** - + - {{object_1}}: {{behavior_and_purpose}} - {{object_2}}: {{behavior_and_purpose}} - + **Hazards and Obstacles:** - + - {{hazard_1}}: {{damage_and_behavior}} - {{hazard_2}}: {{damage_and_behavior}} - id: collectibles-rewards @@ -8396,18 +8396,18 @@ sections: instruction: Define all collectible items and their placement rules template: | **Collectible Types:** - + - {{collectible_1}}: {{value_and_purpose}} - {{collectible_2}}: {{value_and_purpose}} - + **Placement Guidelines:** - + - Mandatory collectibles: {{placement_rules}} - Optional collectibles: {{placement_rules}} - Secret collectibles: {{placement_rules}} - + **Reward Distribution:** - + - Easy to find: {{percentage}}% - Moderate challenge: {{percentage}}% - High skill required: {{percentage}}% @@ -8416,18 +8416,18 @@ sections: instruction: Define how enemies should be placed and balanced in levels template: | **Enemy Categories:** - + - {{enemy_type_1}}: {{behavior_and_usage}} - {{enemy_type_2}}: {{behavior_and_usage}} - + **Placement Principles:** - + - Introduction encounters: {{guideline}} - Standard encounters: {{guideline}} - Challenge encounters: {{guideline}} - + **Difficulty Scaling:** - + - Enemy count progression: {{scaling_rule}} - Enemy type introduction: {{pacing_rule}} - Encounter complexity: {{complexity_rule}} @@ -8440,14 +8440,14 @@ sections: title: Level Layout Principles template: | **Spatial Design:** - + - Grid size: {{grid_dimensions}} - Minimum path width: {{width_units}} - Maximum vertical distance: {{height_units}} - Safe zones placement: {{safety_guidelines}} - + **Navigation Design:** - + - Clear path indication: {{visual_cues}} - Landmark placement: {{landmark_rules}} - Dead end avoidance: {{dead_end_policy}} @@ -8457,13 +8457,13 @@ sections: instruction: Define how to control the rhythm and pace of gameplay within levels template: | **Action Sequences:** - + - High intensity duration: {{max_duration}} - Rest period requirement: {{min_rest_time}} - Intensity variation: {{pacing_pattern}} - + **Learning Sequences:** - + - New mechanic introduction: {{teaching_method}} - Practice opportunity: {{practice_duration}} - Skill application: {{application_context}} @@ -8472,14 +8472,14 @@ sections: instruction: Define how to create appropriate challenges for each level type template: | **Challenge Types:** - + - Execution challenges: {{skill_requirements}} - Puzzle challenges: {{complexity_guidelines}} - Time challenges: {{time_pressure_rules}} - Resource challenges: {{resource_management}} - + **Difficulty Calibration:** - + - Skill check frequency: {{frequency_guidelines}} - Failure recovery: {{retry_mechanics}} - Hint system integration: {{help_system}} @@ -8493,7 +8493,7 @@ sections: instruction: Define how level data should be structured for implementation template: | **Level File Format:** - + - Data format: {{json|yaml|custom}} - File naming: `level_{{world}}_{{number}}.{{extension}}` - Data organization: {{structure_description}} @@ -8531,14 +8531,14 @@ sections: instruction: Define how level assets are organized and loaded template: | **Tilemap Requirements:** - + - Tile size: {{tile_dimensions}}px - Tileset organization: {{tileset_structure}} - Layer organization: {{layer_system}} - Collision data: {{collision_format}} - + **Audio Integration:** - + - Background music: {{music_requirements}} - Ambient sounds: {{ambient_system}} - Dynamic audio: {{dynamic_audio_rules}} @@ -8547,19 +8547,19 @@ sections: instruction: Define performance requirements for level systems template: | **Entity Limits:** - + - Maximum active entities: {{entity_limit}} - Maximum particles: {{particle_limit}} - Maximum audio sources: {{audio_limit}} - + **Memory Management:** - + - Texture memory budget: {{texture_memory}}MB - Audio memory budget: {{audio_memory}}MB - Level loading time: <{{load_time}}s - + **Culling and LOD:** - + - Off-screen culling: {{culling_distance}} - Level-of-detail rules: {{lod_system}} - Asset streaming: {{streaming_requirements}} @@ -8572,13 +8572,13 @@ sections: title: Automated Testing template: | **Performance Testing:** - + - Frame rate validation: Maintain {{fps_target}} FPS - Memory usage monitoring: Stay under {{memory_limit}}MB - Loading time verification: Complete in <{{load_time}}s - + **Gameplay Testing:** - + - Completion path validation: All objectives achievable - Collectible accessibility: All items reachable - Softlock prevention: No unwinnable states @@ -8606,14 +8606,14 @@ sections: title: Balance Validation template: | **Metrics Collection:** - + - Completion rate: Target {{completion_percentage}}% - Average completion time: {{target_time}} ± {{variance}} - Death count per level: <{{max_deaths}} - Collectible discovery rate: {{discovery_percentage}}% - + **Iteration Guidelines:** - + - Adjustment criteria: {{criteria_for_changes}} - Testing sample size: {{minimum_testers}} - Validation period: {{testing_duration}} @@ -8626,14 +8626,14 @@ sections: title: Design Phase template: | **Concept Development:** - + 1. Define level purpose and goals 2. Create rough layout sketch 3. Identify key mechanics and challenges 4. Estimate difficulty and duration - + **Documentation Requirements:** - + - Level design brief - Layout diagrams - Mechanic integration notes @@ -8642,15 +8642,15 @@ sections: title: Implementation Phase template: | **Technical Implementation:** - + 1. Create level data file 2. Build tilemap and layout 3. Place entities and objects 4. Configure level logic and triggers 5. Integrate audio and visual effects - + **Quality Assurance:** - + 1. Automated testing execution 2. Internal playtesting 3. Performance validation @@ -8659,14 +8659,14 @@ sections: title: Integration Phase template: | **Game Integration:** - + 1. Level progression integration 2. Save system compatibility 3. Analytics integration 4. Achievement system integration - + **Final Validation:** - + 1. Full game context testing 2. Performance regression testing 3. Platform compatibility verification diff --git a/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-designer.txt b/bundles/expansion-packs/bmad-2d-unity-game-dev/agents/game-designer.txt similarity index 100% rename from dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-designer.txt rename to bundles/expansion-packs/bmad-2d-unity-game-dev/agents/game-designer.txt diff --git a/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-developer.txt b/bundles/expansion-packs/bmad-2d-unity-game-dev/agents/game-developer.txt similarity index 100% rename from dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-developer.txt rename to bundles/expansion-packs/bmad-2d-unity-game-dev/agents/game-developer.txt diff --git a/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-sm.txt b/bundles/expansion-packs/bmad-2d-unity-game-dev/agents/game-sm.txt similarity index 100% rename from dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-sm.txt rename to bundles/expansion-packs/bmad-2d-unity-game-dev/agents/game-sm.txt diff --git a/dist/expansion-packs/bmad-2d-unity-game-dev/teams/unity-2d-game-team.txt b/bundles/expansion-packs/bmad-2d-unity-game-dev/teams/unity-2d-game-team.txt similarity index 100% rename from dist/expansion-packs/bmad-2d-unity-game-dev/teams/unity-2d-game-team.txt rename to bundles/expansion-packs/bmad-2d-unity-game-dev/teams/unity-2d-game-team.txt diff --git a/dist/expansion-packs/bmad-infrastructure-devops/agents/infra-devops-platform.txt b/bundles/expansion-packs/bmad-infrastructure-devops/agents/infra-devops-platform.txt similarity index 100% rename from dist/expansion-packs/bmad-infrastructure-devops/agents/infra-devops-platform.txt rename to bundles/expansion-packs/bmad-infrastructure-devops/agents/infra-devops-platform.txt diff --git a/dist/teams/team-all.txt b/bundles/teams/team-all.txt similarity index 99% rename from dist/teams/team-all.txt rename to bundles/teams/team-all.txt index b8ef72fc9..3b5778f8d 100644 --- a/dist/teams/team-all.txt +++ b/bundles/teams/team-all.txt @@ -1013,7 +1013,7 @@ BMad transforms you into a "Vibe CEO" - directing a team of specialized AI agent **Best for**: ChatGPT, Claude, Gemini users who want to start immediately -1. Navigate to `dist/teams/` +1. Navigate to `bundles/teams/` 2. Copy `team-fullstack.txt` content 3. Create new Gemini Gem or CustomGPT 4. Upload file with instructions: "Your critical operating instructions are attached, do not break character as directed" @@ -1333,8 +1333,8 @@ The BMad-Method is built around a modular architecture centered on the `bmad-cor #### Web UI Environment -- Uses pre-built bundles from `dist/teams` for stand alone 1 upload files for all agents and their assets with an orchestrating agent -- Single text files containing all agent dependencies are in `dist/agents/` - these are unnecessary unless you want to create a web agent that is only a single agent and not a team +- Uses pre-built bundles from `bundles/teams` for stand alone 1 upload files for all agents and their assets with an orchestrating agent +- Single text files containing all agent dependencies are in `bundles/agents/` - these are unnecessary unless you want to create a web agent that is only a single agent and not a team - Created by the web-builder tool for upload to web interfaces - Provides complete context in one package @@ -1481,7 +1481,7 @@ Each status change requires user verification and approval before proceeding. #### Greenfield Development - Business analysis and market research -- Product requirements and feature definition +- Product requirements and feature definition - System architecture and design - Development execution - Testing and deployment @@ -1590,7 +1590,7 @@ Templates with Level 2 headings (`##`) can be automatically sharded: ```markdown ## Goals and Background Context -## Requirements +## Requirements ## User Interface Design Goals ## Success Metrics ``` @@ -1997,7 +1997,7 @@ If user selects Option 1, present numbered list of techniques from the brainstor 1. Apply selected technique according to data file description 2. Keep engaging with technique until user indicates they want to: - Choose a different technique - - Apply current ideas to a new technique + - Apply current ideas to a new technique - Move to convergent phase - End session @@ -2757,12 +2757,12 @@ sections: - id: introduction instruction: | This template guides creation of a comprehensive Project Brief that serves as the foundational input for product development. - + Start by asking the user which mode they prefer: - + 1. **Interactive Mode** - Work through each section collaboratively 2. **YOLO Mode** - Generate complete draft for review and refinement - + Before beginning, understand what inputs are available (brainstorming results, market research, competitive analysis, initial ideas) and gather project context. - id: executive-summary @@ -3083,7 +3083,7 @@ sections: instruction: Map the end-to-end customer experience for primary segments template: | For primary customer segment: - + 1. **Awareness:** {{discovery_process}} 2. **Consideration:** {{evaluation_criteria}} 3. **Purchase:** {{decision_triggers}} @@ -3284,7 +3284,7 @@ sections: title: Competitor Prioritization Matrix instruction: | Help categorize competitors by market share and strategic threat level - + Create a 2x2 matrix: - Priority 1 (Core Competitors): High Market Share + High Threat - Priority 2 (Emerging Threats): Low Market Share + High Threat @@ -3388,7 +3388,7 @@ sections: title: Positioning Map instruction: | Describe competitor positions on key dimensions - + Create a positioning description using 2 key dimensions relevant to the market, such as: - Price vs. Features - Ease of Use vs. Power @@ -3423,7 +3423,7 @@ sections: title: Blue Ocean Opportunities instruction: | Identify uncontested market spaces - + List opportunities to create new market space: - Underserved segments - Unaddressed use cases @@ -3527,11 +3527,11 @@ sections: - id: summary-details template: | **Topic:** {{session_topic}} - + **Session Goals:** {{stated_goals}} - + **Techniques Used:** {{techniques_list}} - + **Total Ideas Generated:** {{total_ideas}} - id: key-themes title: "Key Themes Identified:" @@ -3656,7 +3656,7 @@ sections: - id: footer content: | --- - + *Session facilitated using the BMAD-METHOD brainstorming framework* ==================== END: .bmad-core/templates/brainstorming-output-tmpl.yaml ==================== @@ -3818,20 +3818,20 @@ sections: - id: intro-content content: | This document outlines the overall project architecture for {{project_name}}, including backend systems, shared services, and non-UI specific concerns. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development, ensuring consistency and adherence to chosen patterns and technologies. - + **Relationship to Frontend Architecture:** If the project includes a significant user interface, a separate Frontend Architecture Document will detail the frontend-specific design and MUST be used in conjunction with this document. Core technology stack choices documented herein (see "Tech Stack") are definitive for the entire project, including any frontend components. - id: starter-template title: Starter Template or Existing Project instruction: | Before proceeding further with architecture design, check if the project is based on a starter template or existing codebase: - + 1. Review the PRD and brainstorming brief for any mentions of: - Starter templates (e.g., Create React App, Next.js, Vue CLI, Angular CLI, etc.) - Existing projects or codebases being used as a foundation - Boilerplate projects or scaffolding tools - Previous projects to be cloned or adapted - + 2. If a starter template or existing project is mentioned: - Ask the user to provide access via one of these methods: - Link to the starter template documentation @@ -3844,16 +3844,16 @@ sections: - Existing architectural patterns and conventions - Any limitations or constraints imposed by the starter - Use this analysis to inform and align your architecture decisions - + 3. If no starter template is mentioned but this is a greenfield project: - Suggest appropriate starter templates based on the tech stack preferences - Explain the benefits (faster setup, best practices, community support) - Let the user decide whether to use one - + 4. If the user confirms no starter template will be used: - Proceed with architecture design from scratch - Note that manual setup will be required for all tooling and configuration - + Document the decision here before proceeding with the architecture design. If none, just say N/A elicit: true - id: changelog @@ -3881,7 +3881,7 @@ sections: title: High Level Overview instruction: | Based on the PRD's Technical Assumptions section, describe: - + 1. The main architectural style (e.g., Monolith, Microservices, Serverless, Event-Driven) 2. Repository structure decision from PRD (Monorepo/Polyrepo) 3. Service architecture decision from PRD @@ -3898,17 +3898,17 @@ sections: - Data flow directions - External integrations - User entry points - + - id: architectural-patterns title: Architectural and Design Patterns instruction: | List the key high-level patterns that will guide the architecture. For each pattern: - + 1. Present 2-3 viable options if multiple exist 2. Provide your recommendation with clear rationale 3. Get user confirmation before finalizing 4. These patterns should align with the PRD's technical assumptions and project goals - + Common patterns to consider: - Architectural style patterns (Serverless, Event-Driven, Microservices, CQRS, Hexagonal) - Code organization patterns (Dependency Injection, Repository, Module, Factory) @@ -3924,23 +3924,23 @@ sections: title: Tech Stack instruction: | This is the DEFINITIVE technology selection section. Work with the user to make specific choices: - + 1. Review PRD technical assumptions and any preferences from .bmad-core/data/technical-preferences.yaml or an attached technical-preferences 2. For each category, present 2-3 viable options with pros/cons 3. Make a clear recommendation based on project needs 4. Get explicit user approval for each selection 5. Document exact versions (avoid "latest" - pin specific versions) 6. This table is the single source of truth - all other docs must reference these choices - + Key decisions to finalize - before displaying the table, ensure you are aware of or ask the user about - let the user know if they are not sure on any that you can also provide suggestions with rationale: - + - Starter templates (if any) - Languages and runtimes with exact versions - Frameworks and libraries / packages - Cloud provider and key services choices - Database and storage solutions - if unclear suggest sql or nosql or other types depending on the project and depending on cloud provider offer a suggestion - Development tools - + Upon render of the table, ensure the user is aware of the importance of this sections choices, should also look for gaps or disagreements with anything, ask for any clarifications if something is unclear why its in the list, and also right away elicit feedback - this statement and the options should be rendered and then prompt right all before allowing user input. elicit: true sections: @@ -3964,13 +3964,13 @@ sections: title: Data Models instruction: | Define the core data models/entities: - + 1. Review PRD requirements and identify key business entities 2. For each model, explain its purpose and relationships 3. Include key attributes and data types 4. Show relationships between models 5. Discuss design decisions with user - + Create a clear conceptual model before moving to database schema. elicit: true repeatable: true @@ -3979,11 +3979,11 @@ sections: title: "{{model_name}}" template: | **Purpose:** {{model_purpose}} - + **Key Attributes:** - {{attribute_1}}: {{type_1}} - {{description_1}} - {{attribute_2}}: {{type_2}} - {{description_2}} - + **Relationships:** - {{relationship_1}} - {{relationship_2}} @@ -3992,7 +3992,7 @@ sections: title: Components instruction: | Based on the architectural patterns, tech stack, and data models from above: - + 1. Identify major logical components/services and their responsibilities 2. Consider the repository structure (monorepo/polyrepo) from PRD 3. Define clear boundaries and interfaces between components @@ -4001,7 +4001,7 @@ sections: - Key interfaces/APIs exposed - Dependencies on other components - Technology specifics based on tech stack choices - + 5. Create component diagrams where helpful elicit: true sections: @@ -4010,13 +4010,13 @@ sections: title: "{{component_name}}" template: | **Responsibility:** {{component_description}} - + **Key Interfaces:** - {{interface_1}} - {{interface_2}} - + **Dependencies:** {{dependencies}} - + **Technology Stack:** {{component_tech_details}} - id: component-diagrams title: Component Diagrams @@ -4033,13 +4033,13 @@ sections: condition: Project requires external API integrations instruction: | For each external service integration: - + 1. Identify APIs needed based on PRD requirements and component design 2. If documentation URLs are unknown, ask user for specifics 3. Document authentication methods and security considerations 4. List specific endpoints that will be used 5. Note any rate limits or usage constraints - + If no external APIs are needed, state this explicitly and skip to next section. elicit: true repeatable: true @@ -4052,10 +4052,10 @@ sections: - **Base URL(s):** {{api_base_url}} - **Authentication:** {{auth_method}} - **Rate Limits:** {{rate_limits}} - + **Key Endpoints Used:** - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}} - + **Integration Notes:** {{integration_considerations}} - id: core-workflows @@ -4064,13 +4064,13 @@ sections: mermaid_type: sequence instruction: | Illustrate key system workflows using sequence diagrams: - + 1. Identify critical user journeys from PRD 2. Show component interactions including external APIs 3. Include error handling paths 4. Document async operations 5. Create both high-level and detailed diagrams as needed - + Focus on workflows that clarify architecture decisions or complex interactions. elicit: true @@ -4081,13 +4081,13 @@ sections: language: yaml instruction: | If the project includes a REST API: - + 1. Create an OpenAPI 3.0 specification 2. Include all endpoints from epics/stories 3. Define request/response schemas based on data models 4. Document authentication requirements 5. Include example requests/responses - + Use YAML format for better readability. If no REST API, skip this section. elicit: true template: | @@ -4104,13 +4104,13 @@ sections: title: Database Schema instruction: | Transform the conceptual data models into concrete database schemas: - + 1. Use the database type(s) selected in Tech Stack 2. Create schema definitions using appropriate notation 3. Include indexes, constraints, and relationships 4. Consider performance and scalability 5. For NoSQL, show document structures - + Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.) elicit: true @@ -4120,14 +4120,14 @@ sections: language: plaintext instruction: | Create a project folder structure that reflects: - + 1. The chosen repository structure (monorepo/polyrepo) 2. The service architecture (monolith/microservices/serverless) 3. The selected tech stack and languages 4. Component organization from above 5. Best practices for the chosen frameworks 6. Clear separation of concerns - + Adapt the structure based on project needs. For monorepos, show service separation. For serverless, show function organization. Include language-specific conventions. elicit: true examples: @@ -4145,13 +4145,13 @@ sections: title: Infrastructure and Deployment instruction: | Define the deployment architecture and practices: - + 1. Use IaC tool selected in Tech Stack 2. Choose deployment strategy appropriate for the architecture 3. Define environments and promotion flow 4. Establish rollback procedures 5. Consider security, monitoring, and cost optimization - + Get user input on deployment preferences and CI/CD tool choices. elicit: true sections: @@ -4187,13 +4187,13 @@ sections: title: Error Handling Strategy instruction: | Define comprehensive error handling approach: - + 1. Choose appropriate patterns for the language/framework from Tech Stack 2. Define logging standards and tools 3. Establish error categories and handling rules 4. Consider observability and debugging needs 5. Ensure security (no sensitive data in logs) - + This section guides both AI and human developers in consistent error handling. elicit: true sections: @@ -4240,13 +4240,13 @@ sections: title: Coding Standards instruction: | These standards are MANDATORY for AI agents. Work with user to define ONLY the critical rules needed to prevent bad code. Explain that: - + 1. This section directly controls AI developer behavior 2. Keep it minimal - assume AI knows general best practices 3. Focus on project-specific conventions and gotchas 4. Overly detailed standards bloat context and slow development 5. Standards will be extracted to separate file for dev agent use - + For each standard, get explicit user confirmation it's necessary. elicit: true sections: @@ -4268,7 +4268,7 @@ sections: - "Never use console.log in production code - use logger" - "All API responses must use ApiResponse wrapper type" - "Database queries must use repository pattern, never direct ORM" - + Avoid obvious rules like "use SOLID principles" or "write clean code" repeatable: true template: "- **{{rule_name}}:** {{rule_description}}" @@ -4286,14 +4286,14 @@ sections: title: Test Strategy and Standards instruction: | Work with user to define comprehensive test strategy: - + 1. Use test frameworks from Tech Stack 2. Decide on TDD vs test-after approach 3. Define test organization and naming 4. Establish coverage goals 5. Determine integration test infrastructure 6. Plan for test data and external dependencies - + Note: Basic info goes in Coding Standards for dev agent. This detailed section is for QA agent and team reference. elicit: true sections: @@ -4314,7 +4314,7 @@ sections: - **Location:** {{unit_test_location}} - **Mocking Library:** {{mocking_library}} - **Coverage Requirement:** {{unit_coverage}} - + **AI Agent Requirements:** - Generate tests for all public methods - Cover edge cases and error conditions @@ -4356,7 +4356,7 @@ sections: title: Security instruction: | Define MANDATORY security requirements for AI and human developers: - + 1. Focus on implementation-specific rules 2. Reference security tools from Tech Stack 3. Define clear patterns for common scenarios @@ -4425,16 +4425,16 @@ sections: title: Next Steps instruction: | After completing the architecture: - + 1. If project has UI components: - Use "Frontend Architecture Mode" - Provide this document as input - + 2. For all projects: - Review with Product Owner - Begin story implementation with Dev agent - Set up infrastructure with DevOps agent - + 3. Include specific prompts for next agents if needed sections: - id: architect-prompt @@ -4467,16 +4467,16 @@ sections: title: Template and Framework Selection instruction: | Review provided documents including PRD, UX-UI Specification, and main Architecture Document. Focus on extracting technical implementation details needed for AI frontend tools and developer agents. Ask the user for any of these documents if you are unable to locate and were not provided. - + Before proceeding with frontend architecture design, check if the project is using a frontend starter template or existing codebase: - + 1. Review the PRD, main architecture document, and brainstorming brief for mentions of: - Frontend starter templates (e.g., Create React App, Next.js, Vite, Vue CLI, Angular CLI, etc.) - UI kit or component library starters - Existing frontend projects being used as a foundation - Admin dashboard templates or other specialized starters - Design system implementations - + 2. If a frontend starter template or existing project is mentioned: - Ask the user to provide access via one of these methods: - Link to the starter template documentation @@ -4492,7 +4492,7 @@ sections: - Testing setup and patterns - Build and development scripts - Use this analysis to ensure your frontend architecture aligns with the starter's patterns - + 3. If no frontend starter is mentioned but this is a new UI, ensure we know what the ui language and framework is: - Based on the framework choice, suggest appropriate starters: - React: Create React App, Next.js, Vite + React @@ -4500,11 +4500,11 @@ sections: - Angular: Angular CLI - Or suggest popular UI templates if applicable - Explain benefits specific to frontend development - + 4. If the user confirms no starter template will be used: - Note that all tooling, bundling, and configuration will need manual setup - Proceed with frontend architecture from scratch - + Document the starter template decision and any constraints it imposes before proceeding. sections: - id: changelog @@ -4679,33 +4679,33 @@ sections: elicit: true content: | This document outlines the complete fullstack architecture for {{project_name}}, including backend systems, frontend implementation, and their integration. It serves as the single source of truth for AI-driven development, ensuring consistency across the entire technology stack. - + This unified approach combines what would traditionally be separate backend and frontend architecture documents, streamlining the development process for modern fullstack applications where these concerns are increasingly intertwined. sections: - id: starter-template title: Starter Template or Existing Project instruction: | Before proceeding with architecture design, check if the project is based on any starter templates or existing codebases: - + 1. Review the PRD and other documents for mentions of: - Fullstack starter templates (e.g., T3 Stack, MEAN/MERN starters, Django + React templates) - Monorepo templates (e.g., Nx, Turborepo starters) - Platform-specific starters (e.g., Vercel templates, AWS Amplify starters) - Existing projects being extended or cloned - + 2. If starter templates or existing projects are mentioned: - Ask the user to provide access (links, repos, or files) - Analyze to understand pre-configured choices and constraints - Note any architectural decisions already made - Identify what can be modified vs what must be retained - + 3. If no starter is mentioned but this is greenfield: - Suggest appropriate fullstack starters based on tech preferences - Consider platform-specific options (Vercel, AWS, etc.) - Let user decide whether to use one - + 4. Document the decision and any constraints it imposes - + If none, state "N/A - Greenfield project" - id: changelog title: Change Log @@ -4731,17 +4731,17 @@ sections: title: Platform and Infrastructure Choice instruction: | Based on PRD requirements and technical assumptions, make a platform recommendation: - + 1. Consider common patterns (not an exhaustive list, use your own best judgement and search the web as needed for emerging trends): - **Vercel + Supabase**: For rapid development with Next.js, built-in auth/storage - **AWS Full Stack**: For enterprise scale with Lambda, API Gateway, S3, Cognito - **Azure**: For .NET ecosystems or enterprise Microsoft environments - **Google Cloud**: For ML/AI heavy applications or Google ecosystem integration - + 2. Present 2-3 viable options with clear pros/cons 3. Make a recommendation with rationale 4. Get explicit user confirmation - + Document the choice and key services that will be used. template: | **Platform:** {{selected_platform}} @@ -4751,7 +4751,7 @@ sections: title: Repository Structure instruction: | Define the repository approach based on PRD requirements and platform choice, explain your rationale or ask questions to the user if unsure: - + 1. For modern fullstack apps, monorepo is often preferred 2. Consider tooling (Nx, Turborepo, Lerna, npm workspaces) 3. Define package/app boundaries @@ -4773,7 +4773,7 @@ sections: - Databases and storage - External integrations - CDN and caching layers - + Use appropriate diagram type for clarity. - id: architectural-patterns title: Architectural Patterns @@ -4783,7 +4783,7 @@ sections: - Frontend patterns (e.g., Component-based, State management) - Backend patterns (e.g., Repository, CQRS, Event-driven) - Integration patterns (e.g., BFF, API Gateway) - + For each pattern, provide recommendation and rationale. repeatable: true template: "- **{{pattern_name}}:** {{pattern_description}} - _Rationale:_ {{rationale}}" @@ -4797,7 +4797,7 @@ sections: title: Tech Stack instruction: | This is the DEFINITIVE technology selection for the entire project. Work with user to finalize all choices. This table is the single source of truth - all development must use these exact versions. - + Key areas to cover: - Frontend and backend languages/frameworks - Databases and caching @@ -4806,7 +4806,7 @@ sections: - Testing tools for both frontend and backend - Build and deployment tools - Monitoring and logging - + Upon render, elicit feedback immediately. elicit: true sections: @@ -4841,14 +4841,14 @@ sections: title: Data Models instruction: | Define the core data models/entities that will be shared between frontend and backend: - + 1. Review PRD requirements and identify key business entities 2. For each model, explain its purpose and relationships 3. Include key attributes and data types 4. Show relationships between models 5. Create TypeScript interfaces that can be shared 6. Discuss design decisions with user - + Create a clear conceptual model before moving to database schema. elicit: true repeatable: true @@ -4857,7 +4857,7 @@ sections: title: "{{model_name}}" template: | **Purpose:** {{model_purpose}} - + **Key Attributes:** - {{attribute_1}}: {{type_1}} - {{description_1}} - {{attribute_2}}: {{type_2}} - {{description_2}} @@ -4876,7 +4876,7 @@ sections: title: API Specification instruction: | Based on the chosen API style from Tech Stack: - + 1. If REST API, create an OpenAPI 3.0 specification 2. If GraphQL, provide the GraphQL schema 3. If tRPC, show router definitions @@ -4884,7 +4884,7 @@ sections: 5. Define request/response schemas based on data models 6. Document authentication requirements 7. Include example requests/responses - + Use appropriate format for the chosen API style. If no API (e.g., static site), skip this section. elicit: true sections: @@ -4919,7 +4919,7 @@ sections: title: Components instruction: | Based on the architectural patterns, tech stack, and data models from above: - + 1. Identify major logical components/services across the fullstack 2. Consider both frontend and backend components 3. Define clear boundaries and interfaces between components @@ -4928,7 +4928,7 @@ sections: - Key interfaces/APIs exposed - Dependencies on other components - Technology specifics based on tech stack choices - + 5. Create component diagrams where helpful elicit: true sections: @@ -4937,13 +4937,13 @@ sections: title: "{{component_name}}" template: | **Responsibility:** {{component_description}} - + **Key Interfaces:** - {{interface_1}} - {{interface_2}} - + **Dependencies:** {{dependencies}} - + **Technology Stack:** {{component_tech_details}} - id: component-diagrams title: Component Diagrams @@ -4960,13 +4960,13 @@ sections: condition: Project requires external API integrations instruction: | For each external service integration: - + 1. Identify APIs needed based on PRD requirements and component design 2. If documentation URLs are unknown, ask user for specifics 3. Document authentication methods and security considerations 4. List specific endpoints that will be used 5. Note any rate limits or usage constraints - + If no external APIs are needed, state this explicitly and skip to next section. elicit: true repeatable: true @@ -4979,10 +4979,10 @@ sections: - **Base URL(s):** {{api_base_url}} - **Authentication:** {{auth_method}} - **Rate Limits:** {{rate_limits}} - + **Key Endpoints Used:** - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}} - + **Integration Notes:** {{integration_considerations}} - id: core-workflows @@ -4991,14 +4991,14 @@ sections: mermaid_type: sequence instruction: | Illustrate key system workflows using sequence diagrams: - + 1. Identify critical user journeys from PRD 2. Show component interactions including external APIs 3. Include both frontend and backend flows 4. Include error handling paths 5. Document async operations 6. Create both high-level and detailed diagrams as needed - + Focus on workflows that clarify architecture decisions or complex interactions. elicit: true @@ -5006,13 +5006,13 @@ sections: title: Database Schema instruction: | Transform the conceptual data models into concrete database schemas: - + 1. Use the database type(s) selected in Tech Stack 2. Create schema definitions using appropriate notation 3. Include indexes, constraints, and relationships 4. Consider performance and scalability 5. For NoSQL, show document structures - + Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.) elicit: true @@ -5228,13 +5228,13 @@ sections: template: | # Start all services {{start_all_command}} - + # Start frontend only {{start_frontend_command}} - + # Start backend only {{start_backend_command}} - + # Run tests {{test_commands}} - id: environment-config @@ -5247,10 +5247,10 @@ sections: template: | # Frontend (.env.local) {{frontend_env_vars}} - + # Backend (.env) {{backend_env_vars}} - + # Shared {{shared_env_vars}} @@ -5267,7 +5267,7 @@ sections: - **Build Command:** {{frontend_build_command}} - **Output Directory:** {{frontend_output_dir}} - **CDN/Edge:** {{cdn_strategy}} - + **Backend Deployment:** - **Platform:** {{backend_deploy_platform}} - **Build Command:** {{backend_build_command}} @@ -5298,12 +5298,12 @@ sections: - CSP Headers: {{csp_policy}} - XSS Prevention: {{xss_strategy}} - Secure Storage: {{storage_strategy}} - + **Backend Security:** - Input Validation: {{validation_approach}} - Rate Limiting: {{rate_limit_config}} - CORS Policy: {{cors_config}} - + **Authentication Security:** - Token Storage: {{token_strategy}} - Session Management: {{session_approach}} @@ -5315,7 +5315,7 @@ sections: - Bundle Size Target: {{bundle_size}} - Loading Strategy: {{loading_approach}} - Caching Strategy: {{fe_cache_strategy}} - + **Backend Performance:** - Response Time Target: {{response_target}} - Database Optimization: {{db_optimization}} @@ -5453,7 +5453,7 @@ sections: - JavaScript errors - API response times - User interactions - + **Backend Metrics:** - Request rate - Error rate @@ -5484,40 +5484,40 @@ sections: title: Introduction instruction: | IMPORTANT - SCOPE AND ASSESSMENT REQUIRED: - + This architecture document is for SIGNIFICANT enhancements to existing projects that require comprehensive architectural planning. Before proceeding: - + 1. **Verify Complexity**: Confirm this enhancement requires architectural planning. For simple additions, recommend: "For simpler changes that don't require architectural planning, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead." - + 2. **REQUIRED INPUTS**: - Completed brownfield-prd.md - Existing project technical documentation (from docs folder or user-provided) - Access to existing project structure (IDE or uploaded files) - + 3. **DEEP ANALYSIS MANDATE**: You MUST conduct thorough analysis of the existing codebase, architecture patterns, and technical constraints before making ANY architectural recommendations. Every suggestion must be based on actual project analysis, not assumptions. - + 4. **CONTINUOUS VALIDATION**: Throughout this process, explicitly validate your understanding with the user. For every architectural decision, confirm: "Based on my analysis of your existing system, I recommend [decision] because [evidence from actual project]. Does this align with your system's reality?" - + If any required inputs are missing, request them before proceeding. elicit: true sections: - id: intro-content content: | This document outlines the architectural approach for enhancing {{project_name}} with {{enhancement_description}}. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development of new features while ensuring seamless integration with the existing system. - + **Relationship to Existing Architecture:** This document supplements existing project architecture by defining how new components will integrate with current systems. Where conflicts arise between new and existing patterns, this document provides guidance on maintaining consistency while implementing enhancements. - id: existing-project-analysis title: Existing Project Analysis instruction: | Analyze the existing project structure and architecture: - + 1. Review existing documentation in docs folder 2. Examine current technology stack and versions 3. Identify existing architectural patterns and conventions 4. Note current deployment and infrastructure setup 5. Document any constraints or limitations - + CRITICAL: After your analysis, explicitly validate your findings: "Based on my analysis of your project, I've identified the following about your existing system: [key findings]. Please confirm these observations are accurate before I proceed with architectural recommendations." elicit: true sections: @@ -5546,12 +5546,12 @@ sections: title: Enhancement Scope and Integration Strategy instruction: | Define how the enhancement will integrate with the existing system: - + 1. Review the brownfield PRD enhancement scope 2. Identify integration points with existing code 3. Define boundaries between new and existing functionality 4. Establish compatibility requirements - + VALIDATION CHECKPOINT: Before presenting the integration strategy, confirm: "Based on my analysis, the integration approach I'm proposing takes into account [specific existing system characteristics]. These integration points and boundaries respect your current architecture patterns. Is this assessment accurate?" elicit: true sections: @@ -5580,7 +5580,7 @@ sections: title: Tech Stack Alignment instruction: | Ensure new components align with existing technology choices: - + 1. Use existing technology stack as the foundation 2. Only introduce new technologies if absolutely necessary 3. Justify any new additions with clear rationale @@ -5603,7 +5603,7 @@ sections: title: Data Models and Schema Changes instruction: | Define new data models and how they integrate with existing schema: - + 1. Identify new entities required for the enhancement 2. Define relationships with existing data models 3. Plan database schema changes (additions, modifications) @@ -5619,11 +5619,11 @@ sections: template: | **Purpose:** {{model_purpose}} **Integration:** {{integration_with_existing}} - + **Key Attributes:** - {{attribute_1}}: {{type_1}} - {{description_1}} - {{attribute_2}}: {{type_2}} - {{description_2}} - + **Relationships:** - **With Existing:** {{existing_relationships}} - **With New:** {{new_relationships}} @@ -5635,7 +5635,7 @@ sections: - **Modified Tables:** {{modified_tables_list}} - **New Indexes:** {{new_indexes_list}} - **Migration Strategy:** {{migration_approach}} - + **Backward Compatibility:** - {{compatibility_measure_1}} - {{compatibility_measure_2}} @@ -5644,12 +5644,12 @@ sections: title: Component Architecture instruction: | Define new components and their integration with existing architecture: - + 1. Identify new components required for the enhancement 2. Define interfaces with existing components 3. Establish clear boundaries and responsibilities 4. Plan integration points and data flow - + MANDATORY VALIDATION: Before presenting component architecture, confirm: "The new components I'm proposing follow the existing architectural patterns I identified in your codebase: [specific patterns]. The integration interfaces respect your current component structure and communication patterns. Does this match your project's reality?" elicit: true sections: @@ -5662,15 +5662,15 @@ sections: template: | **Responsibility:** {{component_description}} **Integration Points:** {{integration_points}} - + **Key Interfaces:** - {{interface_1}} - {{interface_2}} - + **Dependencies:** - **Existing Components:** {{existing_dependencies}} - **New Components:** {{new_dependencies}} - + **Technology Stack:** {{component_tech_details}} - id: interaction-diagram title: Component Interaction Diagram @@ -5683,7 +5683,7 @@ sections: condition: Enhancement requires API changes instruction: | Define new API endpoints and integration with existing APIs: - + 1. Plan new API endpoints required for the enhancement 2. Ensure consistency with existing API patterns 3. Define authentication and authorization integration @@ -5733,17 +5733,17 @@ sections: - **Base URL:** {{api_base_url}} - **Authentication:** {{auth_method}} - **Integration Method:** {{integration_approach}} - + **Key Endpoints Used:** - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}} - + **Error Handling:** {{error_handling_strategy}} - id: source-tree-integration title: Source Tree Integration instruction: | Define how new code will integrate with existing project structure: - + 1. Follow existing project organization patterns 2. Identify where new files/folders will be placed 3. Ensure consistency with existing naming conventions @@ -5782,7 +5782,7 @@ sections: title: Infrastructure and Deployment Integration instruction: | Define how the enhancement will be deployed alongside existing infrastructure: - + 1. Use existing deployment pipeline and infrastructure 2. Identify any infrastructure changes needed 3. Plan deployment strategy to minimize risk @@ -5812,7 +5812,7 @@ sections: title: Coding Standards and Conventions instruction: | Ensure new code follows existing project conventions: - + 1. Document existing coding standards from project analysis 2. Identify any enhancement-specific requirements 3. Ensure consistency with existing codebase patterns @@ -5843,7 +5843,7 @@ sections: title: Testing Strategy instruction: | Define testing approach for the enhancement: - + 1. Integrate with existing test suite 2. Ensure existing functionality remains intact 3. Plan for testing new features @@ -5883,7 +5883,7 @@ sections: title: Security Integration instruction: | Ensure security consistency with existing system: - + 1. Follow existing security patterns and tools 2. Ensure new features don't introduce vulnerabilities 3. Maintain existing security posture @@ -5918,7 +5918,7 @@ sections: title: Next Steps instruction: | After completing the brownfield architecture: - + 1. Review integration points with existing system 2. Begin story implementation with Dev agent 3. Set up deployment pipeline integration @@ -7272,7 +7272,7 @@ sections: condition: PRD has UX/UI requirements instruction: | Capture high-level UI/UX vision to guide Design Architect and to inform story creation. Steps: - + 1. Pre-fill all subsections with educated guesses based on project context 2. Present the complete rendered section to user 3. Clearly let the user know where assumptions were made @@ -7314,7 +7314,7 @@ sections: title: Technical Assumptions instruction: | Gather technical decisions that will guide the Architect. Steps: - + 1. Check if .bmad-core/data/technical-preferences.yaml or an attached technical-preferences file exists - use it to pre-populate choices 2. Ask user about: languages, frameworks, starter templates, libraries, APIs, deployment targets 3. For unknowns, offer guidance based on project goals and MVP scope @@ -7342,9 +7342,9 @@ sections: title: Epic List instruction: | Present a high-level list of all epics for user approval. Each epic should have a title and a short (1 sentence) goal statement. This allows the user to review the overall structure before diving into details. - + CRITICAL: Epics MUST be logically sequential following agile best practices: - + - Each epic should deliver a significant, end-to-end, fully deployable increment of testable functionality - Epic 1 must establish foundational project infrastructure (app setup, Git, CI/CD, core services) unless we are adding new functionality to an existing app, while also delivering an initial piece of functionality, even as simple as a health-check route or display of a simple canary page - remember this when we produce the stories for the first epic! - Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed @@ -7363,11 +7363,11 @@ sections: repeatable: true instruction: | After the epic list is approved, present each epic with all its stories and acceptance criteria as a complete review unit. - + For each epic provide expanded goal (2-3 sentences describing the objective and value all the stories will achieve). - + CRITICAL STORY SEQUENCING REQUIREMENTS: - + - Stories within each epic MUST be logically sequential - Each story should be a "vertical slice" delivering complete functionality aside from early enabler stories for project foundation - No story should depend on work from a later story or epic @@ -7395,7 +7395,7 @@ sections: repeatable: true instruction: | Define clear, comprehensive, and testable acceptance criteria that: - + - Precisely define what "done" means from a functional perspective - Are unambiguous and serve as basis for verification - Include any critical non-functional requirements from the PRD @@ -7437,19 +7437,19 @@ sections: title: Intro Project Analysis and Context instruction: | IMPORTANT - SCOPE ASSESSMENT REQUIRED: - + This PRD is for SIGNIFICANT enhancements to existing projects that require comprehensive planning and multiple stories. Before proceeding: - + 1. **Assess Enhancement Complexity**: If this is a simple feature addition or bug fix that could be completed in 1-2 focused development sessions, STOP and recommend: "For simpler changes, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead. This full PRD process is designed for substantial enhancements that require architectural planning and multiple coordinated stories." - + 2. **Project Context**: Determine if we're working in an IDE with the project already loaded or if the user needs to provide project information. If project files are available, analyze existing documentation in the docs folder. If insufficient documentation exists, recommend running the document-project task first. - + 3. **Deep Assessment Requirement**: You MUST thoroughly analyze the existing project structure, patterns, and constraints before making ANY suggestions. Every recommendation must be grounded in actual project analysis, not assumptions. - + Gather comprehensive information about the existing project. This section must be completed before proceeding with requirements. - + CRITICAL: Throughout this analysis, explicitly confirm your understanding with the user. For every assumption you make about the existing project, ask: "Based on my analysis, I understand that [assumption]. Is this correct?" - + Do not proceed with any recommendations until the user has validated your understanding of the existing system. sections: - id: existing-project-overview @@ -7475,7 +7475,7 @@ sections: - Note: "Document-project analysis available - using existing technical documentation" - List key documents created by document-project - Skip the missing documentation check below - + Otherwise, check for existing documentation: sections: - id: available-docs @@ -7599,7 +7599,7 @@ sections: If document-project output available: - Extract from "Actual Tech Stack" table in High Level Architecture section - Include version numbers and any noted constraints - + Otherwise, document the current technology stack: template: | **Languages**: {{languages}} @@ -7638,7 +7638,7 @@ sections: - Reference "Technical Debt and Known Issues" section - Include "Workarounds and Gotchas" that might impact enhancement - Note any identified constraints from "Critical Technical Debt" - + Build risk assessment incorporating existing known issues: template: | **Technical Risks**: {{technical_risks}} @@ -7661,7 +7661,7 @@ sections: title: "Epic 1: {{enhancement_title}}" instruction: | Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality - + CRITICAL STORY SEQUENCING FOR BROWNFIELD: - Stories must ensure existing functionality remains intact - Each story should include verification that existing features still work @@ -7674,7 +7674,7 @@ sections: - Each story must deliver value while maintaining system integrity template: | **Epic Goal**: {{epic_goal}} - + **Integration Requirements**: {{integration_requirements}} sections: - id: story @@ -8279,7 +8279,7 @@ workflow: elicitation: advanced-elicitation agent_config: - editable_sections: + editable_sections: - Status - Story - Acceptance Criteria @@ -8296,7 +8296,7 @@ sections: instruction: Select the current status of the story owner: scrum-master editors: [scrum-master, dev-agent] - + - id: story title: Story type: template-text @@ -8308,7 +8308,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: acceptance-criteria title: Acceptance Criteria type: numbered-list @@ -8316,7 +8316,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: tasks-subtasks title: Tasks / Subtasks type: bullet-list @@ -8333,7 +8333,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master, dev-agent] - + - id: dev-notes title: Dev Notes instruction: | @@ -8357,7 +8357,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: change-log title: Change Log type: table @@ -8365,7 +8365,7 @@ sections: instruction: Track changes made to this story document owner: scrum-master editors: [scrum-master, dev-agent, qa-agent] - + - id: dev-agent-record title: Dev Agent Record instruction: This section is populated by the development agent during implementation @@ -8378,25 +8378,25 @@ sections: instruction: Record the specific AI agent model and version used for development owner: dev-agent editors: [dev-agent] - + - id: debug-log-references title: Debug Log References instruction: Reference any debug logs or traces generated during development owner: dev-agent editors: [dev-agent] - + - id: completion-notes title: Completion Notes List instruction: Notes about the completion of tasks and any issues encountered owner: dev-agent editors: [dev-agent] - + - id: file-list title: File List instruction: List all files created, modified, or affected during story implementation owner: dev-agent editors: [dev-agent] - + - id: qa-results title: QA Results instruction: Results from QA Agent QA review of the completed story implementation @@ -9343,7 +9343,7 @@ sections: title: Introduction instruction: | Review provided documents including Project Brief, PRD, and any user research to gather context. Focus on understanding user needs, pain points, and desired outcomes before beginning the specification. - + Establish the document's purpose and scope. Keep the content below but ensure project name is properly substituted. content: | This document defines the user experience goals, information architecture, user flows, and visual design specifications for {{project_name}}'s user interface. It serves as the foundation for visual design and frontend development, ensuring a cohesive and user-centered experience. @@ -9352,7 +9352,7 @@ sections: title: Overall UX Goals & Principles instruction: | Work with the user to establish and document the following. If not already defined, facilitate a discussion to determine: - + 1. Target User Personas - elicit details or confirm existing ones from PRD 2. Key Usability Goals - understand what success looks like for users 3. Core Design Principles - establish 3-5 guiding principles @@ -9393,7 +9393,7 @@ sections: title: Information Architecture (IA) instruction: | Collaborate with the user to create a comprehensive information architecture: - + 1. Build a Site Map or Screen Inventory showing all major areas 2. Define the Navigation Structure (primary, secondary, breadcrumbs) 3. Use Mermaid diagrams for visual representation @@ -9423,22 +9423,22 @@ sections: title: Navigation Structure template: | **Primary Navigation:** {{primary_nav_description}} - + **Secondary Navigation:** {{secondary_nav_description}} - + **Breadcrumb Strategy:** {{breadcrumb_strategy}} - id: user-flows title: User Flows instruction: | For each critical user task identified in the PRD: - + 1. Define the user's goal clearly 2. Map out all steps including decision points 3. Consider edge cases and error states 4. Use Mermaid flow diagrams for clarity 5. Link to external tools (Figma/Miro) if detailed flows exist there - + Create subsections for each major flow. elicit: true repeatable: true @@ -9447,9 +9447,9 @@ sections: title: "{{flow_name}}" template: | **User Goal:** {{flow_goal}} - + **Entry Points:** {{entry_points}} - + **Success Criteria:** {{success_criteria}} sections: - id: flow-diagram @@ -9480,14 +9480,14 @@ sections: title: "{{screen_name}}" template: | **Purpose:** {{screen_purpose}} - + **Key Elements:** - {{element_1}} - {{element_2}} - {{element_3}} - + **Interaction Notes:** {{interaction_notes}} - + **Design File Reference:** {{specific_frame_link}} - id: component-library @@ -9506,11 +9506,11 @@ sections: title: "{{component_name}}" template: | **Purpose:** {{component_purpose}} - + **Variants:** {{component_variants}} - + **States:** {{component_states}} - + **Usage Guidelines:** {{usage_guidelines}} - id: branding-style @@ -9556,13 +9556,13 @@ sections: title: Iconography template: | **Icon Library:** {{icon_library}} - + **Usage Guidelines:** {{icon_guidelines}} - id: spacing-layout title: Spacing & Layout template: | **Grid System:** {{grid_system}} - + **Spacing Scale:** {{spacing_scale}} - id: accessibility @@ -9580,12 +9580,12 @@ sections: - Color contrast ratios: {{contrast_requirements}} - Focus indicators: {{focus_requirements}} - Text sizing: {{text_requirements}} - + **Interaction:** - Keyboard navigation: {{keyboard_requirements}} - Screen reader support: {{screen_reader_requirements}} - Touch targets: {{touch_requirements}} - + **Content:** - Alternative text: {{alt_text_requirements}} - Heading structure: {{heading_requirements}} @@ -9612,11 +9612,11 @@ sections: title: Adaptation Patterns template: | **Layout Changes:** {{layout_adaptations}} - + **Navigation Changes:** {{nav_adaptations}} - + **Content Priority:** {{content_adaptations}} - + **Interaction Changes:** {{interaction_adaptations}} - id: animation @@ -9650,7 +9650,7 @@ sections: title: Next Steps instruction: | After completing the UI/UX specification: - + 1. Recommend review with stakeholders 2. Suggest creating/updating visual designs in design tool 3. Prepare for handoff to Design Architect for frontend architecture @@ -9697,9 +9697,9 @@ workflow: notes: | Determine enhancement complexity to route to appropriate path: - Single story (< 4 hours) → Use brownfield-create-story task - - Small feature (1-3 stories) → Use brownfield-create-epic task + - Small feature (1-3 stories) → Use brownfield-create-epic task - Major enhancement (multiple epics) → Continue with full workflow - + Ask user: "Can you describe the enhancement scope? Is this a small fix, a feature addition, or a major enhancement requiring architectural changes?" - step: routing_decision @@ -9860,7 +9860,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -9868,40 +9868,40 @@ workflow: graph TD A[Start: Brownfield Enhancement] --> B[analyst: classify enhancement scope] B --> C{Enhancement Size?} - + C -->|Single Story| D[pm: brownfield-create-story] C -->|1-3 Stories| E[pm: brownfield-create-epic] C -->|Major Enhancement| F[analyst: check documentation] - + D --> END1[To Dev Implementation] E --> END2[To Story Creation] - + F --> G{Docs Adequate?} G -->|No| H[architect: document-project] G -->|Yes| I[pm: brownfield PRD] H --> I - + I --> J{Architecture Needed?} J -->|Yes| K[architect: architecture.md] J -->|No| L[po: validate artifacts] K --> L - + L --> M{PO finds issues?} M -->|Yes| N[Fix issues] M -->|No| O[po: shard documents] N --> L - + O --> P[sm: create story] P --> Q{Story Type?} Q -->|Sharded PRD| R[create-next-story] Q -->|Brownfield Docs| S[create-brownfield-story] - + R --> T{Review draft?} S --> T T -->|Yes| U[review & approve] T -->|No| V[dev: implement] U --> V - + V --> W{QA review?} W -->|Yes| X[qa: review] W -->|No| Y{More stories?} @@ -9944,35 +9944,35 @@ workflow: {{if single_story}}: Proceeding with brownfield-create-story task for immediate implementation. {{if small_feature}}: Creating focused epic with brownfield-create-epic task. {{if major_enhancement}}: Continuing with comprehensive planning workflow. - + documentation_assessment: | Documentation assessment complete: {{if adequate}}: Existing documentation is sufficient. Proceeding directly to PRD creation. {{if inadequate}}: Running document-project to capture current system state before PRD. - + document_project_to_pm: | Project analysis complete. Key findings documented in: - {{document_list}} Use these findings to inform PRD creation and avoid re-analyzing the same aspects. - + pm_to_architect_decision: | - PRD complete and saved as docs/prd.md. + PRD complete and saved as docs/prd.md. Architectural changes identified: {{yes/no}} {{if yes}}: Proceeding to create architecture document for: {{specific_changes}} {{if no}}: No architectural changes needed. Proceeding to validation. - + architect_to_po: "Architecture complete. Save it as docs/architecture.md. Please validate all artifacts for integration safety." - + po_to_sm: | - All artifacts validated. + All artifacts validated. Documentation type available: {{sharded_prd / brownfield_docs}} {{if sharded}}: Use standard create-next-story task. {{if brownfield}}: Use create-brownfield-story task to handle varied documentation formats. - + sm_story_creation: | Creating story from {{documentation_type}}. {{if missing_context}}: May need to gather additional context from user during story creation. - + complete: "All planning artifacts validated and development can begin. Stories will be created based on available documentation format." ==================== END: .bmad-core/workflows/brownfield-fullstack.yaml ==================== @@ -10106,7 +10106,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -10120,7 +10120,7 @@ workflow: F -->|Yes| G[Return to relevant agent for fixes] F -->|No| H[po: shard documents] G --> E - + H --> I[sm: create story] I --> J{Review draft story?} J -->|Yes| K[analyst/pm: review & approve story] @@ -10303,7 +10303,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -10318,7 +10318,7 @@ workflow: G -->|Yes| H[Return to relevant agent for fixes] G -->|No| I[po: shard documents] H --> F - + I --> J[sm: create story] J --> K{Review draft story?} K -->|Yes| L[analyst/pm: review & approve story] @@ -10528,7 +10528,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -10550,7 +10550,7 @@ workflow: I -->|Yes| J[Return to relevant agent for fixes] I -->|No| K[po: shard documents] J --> H - + K --> L[sm: create story] L --> M{Review draft story?} M -->|Yes| N[analyst/pm: review & approve story] @@ -10747,7 +10747,7 @@ workflow: notes: | All stories implemented and reviewed! Service development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -10764,7 +10764,7 @@ workflow: H -->|Yes| I[Return to relevant agent for fixes] H -->|No| J[po: shard documents] I --> G - + J --> K[sm: create story] K --> L{Review draft story?} L -->|Yes| M[analyst/pm: review & approve story] @@ -10975,7 +10975,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -10997,7 +10997,7 @@ workflow: I -->|Yes| J[Return to relevant agent for fixes] I -->|No| K[po: shard documents] J --> H - + K --> L[sm: create story] L --> M{Review draft story?} M -->|Yes| N[analyst/pm: review & approve story] diff --git a/dist/teams/team-fullstack.txt b/bundles/teams/team-fullstack.txt similarity index 99% rename from dist/teams/team-fullstack.txt rename to bundles/teams/team-fullstack.txt index 7a8f5cc40..83c012250 100644 --- a/dist/teams/team-fullstack.txt +++ b/bundles/teams/team-fullstack.txt @@ -868,7 +868,7 @@ BMad transforms you into a "Vibe CEO" - directing a team of specialized AI agent **Best for**: ChatGPT, Claude, Gemini users who want to start immediately -1. Navigate to `dist/teams/` +1. Navigate to `bundles/teams/` 2. Copy `team-fullstack.txt` content 3. Create new Gemini Gem or CustomGPT 4. Upload file with instructions: "Your critical operating instructions are attached, do not break character as directed" @@ -1188,8 +1188,8 @@ The BMad-Method is built around a modular architecture centered on the `bmad-cor #### Web UI Environment -- Uses pre-built bundles from `dist/teams` for stand alone 1 upload files for all agents and their assets with an orchestrating agent -- Single text files containing all agent dependencies are in `dist/agents/` - these are unnecessary unless you want to create a web agent that is only a single agent and not a team +- Uses pre-built bundles from `bundles/teams` for stand alone 1 upload files for all agents and their assets with an orchestrating agent +- Single text files containing all agent dependencies are in `bundles/agents/` - these are unnecessary unless you want to create a web agent that is only a single agent and not a team - Created by the web-builder tool for upload to web interfaces - Provides complete context in one package @@ -1336,7 +1336,7 @@ Each status change requires user verification and approval before proceeding. #### Greenfield Development - Business analysis and market research -- Product requirements and feature definition +- Product requirements and feature definition - System architecture and design - Development execution - Testing and deployment @@ -1445,7 +1445,7 @@ Templates with Level 2 headings (`##`) can be automatically sharded: ```markdown ## Goals and Background Context -## Requirements +## Requirements ## User Interface Design Goals ## Success Metrics ``` @@ -1852,7 +1852,7 @@ If user selects Option 1, present numbered list of techniques from the brainstor 1. Apply selected technique according to data file description 2. Keep engaging with technique until user indicates they want to: - Choose a different technique - - Apply current ideas to a new technique + - Apply current ideas to a new technique - Move to convergent phase - End session @@ -2612,12 +2612,12 @@ sections: - id: introduction instruction: | This template guides creation of a comprehensive Project Brief that serves as the foundational input for product development. - + Start by asking the user which mode they prefer: - + 1. **Interactive Mode** - Work through each section collaboratively 2. **YOLO Mode** - Generate complete draft for review and refinement - + Before beginning, understand what inputs are available (brainstorming results, market research, competitive analysis, initial ideas) and gather project context. - id: executive-summary @@ -2938,7 +2938,7 @@ sections: instruction: Map the end-to-end customer experience for primary segments template: | For primary customer segment: - + 1. **Awareness:** {{discovery_process}} 2. **Consideration:** {{evaluation_criteria}} 3. **Purchase:** {{decision_triggers}} @@ -3139,7 +3139,7 @@ sections: title: Competitor Prioritization Matrix instruction: | Help categorize competitors by market share and strategic threat level - + Create a 2x2 matrix: - Priority 1 (Core Competitors): High Market Share + High Threat - Priority 2 (Emerging Threats): Low Market Share + High Threat @@ -3243,7 +3243,7 @@ sections: title: Positioning Map instruction: | Describe competitor positions on key dimensions - + Create a positioning description using 2 key dimensions relevant to the market, such as: - Price vs. Features - Ease of Use vs. Power @@ -3278,7 +3278,7 @@ sections: title: Blue Ocean Opportunities instruction: | Identify uncontested market spaces - + List opportunities to create new market space: - Underserved segments - Unaddressed use cases @@ -3382,11 +3382,11 @@ sections: - id: summary-details template: | **Topic:** {{session_topic}} - + **Session Goals:** {{stated_goals}} - + **Techniques Used:** {{techniques_list}} - + **Total Ideas Generated:** {{total_ideas}} - id: key-themes title: "Key Themes Identified:" @@ -3511,7 +3511,7 @@ sections: - id: footer content: | --- - + *Session facilitated using the BMAD-METHOD brainstorming framework* ==================== END: .bmad-core/templates/brainstorming-output-tmpl.yaml ==================== @@ -4285,7 +4285,7 @@ sections: condition: PRD has UX/UI requirements instruction: | Capture high-level UI/UX vision to guide Design Architect and to inform story creation. Steps: - + 1. Pre-fill all subsections with educated guesses based on project context 2. Present the complete rendered section to user 3. Clearly let the user know where assumptions were made @@ -4327,7 +4327,7 @@ sections: title: Technical Assumptions instruction: | Gather technical decisions that will guide the Architect. Steps: - + 1. Check if .bmad-core/data/technical-preferences.yaml or an attached technical-preferences file exists - use it to pre-populate choices 2. Ask user about: languages, frameworks, starter templates, libraries, APIs, deployment targets 3. For unknowns, offer guidance based on project goals and MVP scope @@ -4355,9 +4355,9 @@ sections: title: Epic List instruction: | Present a high-level list of all epics for user approval. Each epic should have a title and a short (1 sentence) goal statement. This allows the user to review the overall structure before diving into details. - + CRITICAL: Epics MUST be logically sequential following agile best practices: - + - Each epic should deliver a significant, end-to-end, fully deployable increment of testable functionality - Epic 1 must establish foundational project infrastructure (app setup, Git, CI/CD, core services) unless we are adding new functionality to an existing app, while also delivering an initial piece of functionality, even as simple as a health-check route or display of a simple canary page - remember this when we produce the stories for the first epic! - Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed @@ -4376,11 +4376,11 @@ sections: repeatable: true instruction: | After the epic list is approved, present each epic with all its stories and acceptance criteria as a complete review unit. - + For each epic provide expanded goal (2-3 sentences describing the objective and value all the stories will achieve). - + CRITICAL STORY SEQUENCING REQUIREMENTS: - + - Stories within each epic MUST be logically sequential - Each story should be a "vertical slice" delivering complete functionality aside from early enabler stories for project foundation - No story should depend on work from a later story or epic @@ -4408,7 +4408,7 @@ sections: repeatable: true instruction: | Define clear, comprehensive, and testable acceptance criteria that: - + - Precisely define what "done" means from a functional perspective - Are unambiguous and serve as basis for verification - Include any critical non-functional requirements from the PRD @@ -4450,19 +4450,19 @@ sections: title: Intro Project Analysis and Context instruction: | IMPORTANT - SCOPE ASSESSMENT REQUIRED: - + This PRD is for SIGNIFICANT enhancements to existing projects that require comprehensive planning and multiple stories. Before proceeding: - + 1. **Assess Enhancement Complexity**: If this is a simple feature addition or bug fix that could be completed in 1-2 focused development sessions, STOP and recommend: "For simpler changes, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead. This full PRD process is designed for substantial enhancements that require architectural planning and multiple coordinated stories." - + 2. **Project Context**: Determine if we're working in an IDE with the project already loaded or if the user needs to provide project information. If project files are available, analyze existing documentation in the docs folder. If insufficient documentation exists, recommend running the document-project task first. - + 3. **Deep Assessment Requirement**: You MUST thoroughly analyze the existing project structure, patterns, and constraints before making ANY suggestions. Every recommendation must be grounded in actual project analysis, not assumptions. - + Gather comprehensive information about the existing project. This section must be completed before proceeding with requirements. - + CRITICAL: Throughout this analysis, explicitly confirm your understanding with the user. For every assumption you make about the existing project, ask: "Based on my analysis, I understand that [assumption]. Is this correct?" - + Do not proceed with any recommendations until the user has validated your understanding of the existing system. sections: - id: existing-project-overview @@ -4488,7 +4488,7 @@ sections: - Note: "Document-project analysis available - using existing technical documentation" - List key documents created by document-project - Skip the missing documentation check below - + Otherwise, check for existing documentation: sections: - id: available-docs @@ -4612,7 +4612,7 @@ sections: If document-project output available: - Extract from "Actual Tech Stack" table in High Level Architecture section - Include version numbers and any noted constraints - + Otherwise, document the current technology stack: template: | **Languages**: {{languages}} @@ -4651,7 +4651,7 @@ sections: - Reference "Technical Debt and Known Issues" section - Include "Workarounds and Gotchas" that might impact enhancement - Note any identified constraints from "Critical Technical Debt" - + Build risk assessment incorporating existing known issues: template: | **Technical Risks**: {{technical_risks}} @@ -4674,7 +4674,7 @@ sections: title: "Epic 1: {{enhancement_title}}" instruction: | Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality - + CRITICAL STORY SEQUENCING FOR BROWNFIELD: - Stories must ensure existing functionality remains intact - Each story should include verification that existing features still work @@ -4687,7 +4687,7 @@ sections: - Each story must deliver value while maintaining system integrity template: | **Epic Goal**: {{epic_goal}} - + **Integration Requirements**: {{integration_requirements}} sections: - id: story @@ -5356,7 +5356,7 @@ sections: title: Introduction instruction: | Review provided documents including Project Brief, PRD, and any user research to gather context. Focus on understanding user needs, pain points, and desired outcomes before beginning the specification. - + Establish the document's purpose and scope. Keep the content below but ensure project name is properly substituted. content: | This document defines the user experience goals, information architecture, user flows, and visual design specifications for {{project_name}}'s user interface. It serves as the foundation for visual design and frontend development, ensuring a cohesive and user-centered experience. @@ -5365,7 +5365,7 @@ sections: title: Overall UX Goals & Principles instruction: | Work with the user to establish and document the following. If not already defined, facilitate a discussion to determine: - + 1. Target User Personas - elicit details or confirm existing ones from PRD 2. Key Usability Goals - understand what success looks like for users 3. Core Design Principles - establish 3-5 guiding principles @@ -5406,7 +5406,7 @@ sections: title: Information Architecture (IA) instruction: | Collaborate with the user to create a comprehensive information architecture: - + 1. Build a Site Map or Screen Inventory showing all major areas 2. Define the Navigation Structure (primary, secondary, breadcrumbs) 3. Use Mermaid diagrams for visual representation @@ -5436,22 +5436,22 @@ sections: title: Navigation Structure template: | **Primary Navigation:** {{primary_nav_description}} - + **Secondary Navigation:** {{secondary_nav_description}} - + **Breadcrumb Strategy:** {{breadcrumb_strategy}} - id: user-flows title: User Flows instruction: | For each critical user task identified in the PRD: - + 1. Define the user's goal clearly 2. Map out all steps including decision points 3. Consider edge cases and error states 4. Use Mermaid flow diagrams for clarity 5. Link to external tools (Figma/Miro) if detailed flows exist there - + Create subsections for each major flow. elicit: true repeatable: true @@ -5460,9 +5460,9 @@ sections: title: "{{flow_name}}" template: | **User Goal:** {{flow_goal}} - + **Entry Points:** {{entry_points}} - + **Success Criteria:** {{success_criteria}} sections: - id: flow-diagram @@ -5493,14 +5493,14 @@ sections: title: "{{screen_name}}" template: | **Purpose:** {{screen_purpose}} - + **Key Elements:** - {{element_1}} - {{element_2}} - {{element_3}} - + **Interaction Notes:** {{interaction_notes}} - + **Design File Reference:** {{specific_frame_link}} - id: component-library @@ -5519,11 +5519,11 @@ sections: title: "{{component_name}}" template: | **Purpose:** {{component_purpose}} - + **Variants:** {{component_variants}} - + **States:** {{component_states}} - + **Usage Guidelines:** {{usage_guidelines}} - id: branding-style @@ -5569,13 +5569,13 @@ sections: title: Iconography template: | **Icon Library:** {{icon_library}} - + **Usage Guidelines:** {{icon_guidelines}} - id: spacing-layout title: Spacing & Layout template: | **Grid System:** {{grid_system}} - + **Spacing Scale:** {{spacing_scale}} - id: accessibility @@ -5593,12 +5593,12 @@ sections: - Color contrast ratios: {{contrast_requirements}} - Focus indicators: {{focus_requirements}} - Text sizing: {{text_requirements}} - + **Interaction:** - Keyboard navigation: {{keyboard_requirements}} - Screen reader support: {{screen_reader_requirements}} - Touch targets: {{touch_requirements}} - + **Content:** - Alternative text: {{alt_text_requirements}} - Heading structure: {{heading_requirements}} @@ -5625,11 +5625,11 @@ sections: title: Adaptation Patterns template: | **Layout Changes:** {{layout_adaptations}} - + **Navigation Changes:** {{nav_adaptations}} - + **Content Priority:** {{content_adaptations}} - + **Interaction Changes:** {{interaction_adaptations}} - id: animation @@ -5663,7 +5663,7 @@ sections: title: Next Steps instruction: | After completing the UI/UX specification: - + 1. Recommend review with stakeholders 2. Suggest creating/updating visual designs in design tool 3. Prepare for handoff to Design Architect for frontend architecture @@ -5712,20 +5712,20 @@ sections: - id: intro-content content: | This document outlines the overall project architecture for {{project_name}}, including backend systems, shared services, and non-UI specific concerns. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development, ensuring consistency and adherence to chosen patterns and technologies. - + **Relationship to Frontend Architecture:** If the project includes a significant user interface, a separate Frontend Architecture Document will detail the frontend-specific design and MUST be used in conjunction with this document. Core technology stack choices documented herein (see "Tech Stack") are definitive for the entire project, including any frontend components. - id: starter-template title: Starter Template or Existing Project instruction: | Before proceeding further with architecture design, check if the project is based on a starter template or existing codebase: - + 1. Review the PRD and brainstorming brief for any mentions of: - Starter templates (e.g., Create React App, Next.js, Vue CLI, Angular CLI, etc.) - Existing projects or codebases being used as a foundation - Boilerplate projects or scaffolding tools - Previous projects to be cloned or adapted - + 2. If a starter template or existing project is mentioned: - Ask the user to provide access via one of these methods: - Link to the starter template documentation @@ -5738,16 +5738,16 @@ sections: - Existing architectural patterns and conventions - Any limitations or constraints imposed by the starter - Use this analysis to inform and align your architecture decisions - + 3. If no starter template is mentioned but this is a greenfield project: - Suggest appropriate starter templates based on the tech stack preferences - Explain the benefits (faster setup, best practices, community support) - Let the user decide whether to use one - + 4. If the user confirms no starter template will be used: - Proceed with architecture design from scratch - Note that manual setup will be required for all tooling and configuration - + Document the decision here before proceeding with the architecture design. If none, just say N/A elicit: true - id: changelog @@ -5775,7 +5775,7 @@ sections: title: High Level Overview instruction: | Based on the PRD's Technical Assumptions section, describe: - + 1. The main architectural style (e.g., Monolith, Microservices, Serverless, Event-Driven) 2. Repository structure decision from PRD (Monorepo/Polyrepo) 3. Service architecture decision from PRD @@ -5792,17 +5792,17 @@ sections: - Data flow directions - External integrations - User entry points - + - id: architectural-patterns title: Architectural and Design Patterns instruction: | List the key high-level patterns that will guide the architecture. For each pattern: - + 1. Present 2-3 viable options if multiple exist 2. Provide your recommendation with clear rationale 3. Get user confirmation before finalizing 4. These patterns should align with the PRD's technical assumptions and project goals - + Common patterns to consider: - Architectural style patterns (Serverless, Event-Driven, Microservices, CQRS, Hexagonal) - Code organization patterns (Dependency Injection, Repository, Module, Factory) @@ -5818,23 +5818,23 @@ sections: title: Tech Stack instruction: | This is the DEFINITIVE technology selection section. Work with the user to make specific choices: - + 1. Review PRD technical assumptions and any preferences from .bmad-core/data/technical-preferences.yaml or an attached technical-preferences 2. For each category, present 2-3 viable options with pros/cons 3. Make a clear recommendation based on project needs 4. Get explicit user approval for each selection 5. Document exact versions (avoid "latest" - pin specific versions) 6. This table is the single source of truth - all other docs must reference these choices - + Key decisions to finalize - before displaying the table, ensure you are aware of or ask the user about - let the user know if they are not sure on any that you can also provide suggestions with rationale: - + - Starter templates (if any) - Languages and runtimes with exact versions - Frameworks and libraries / packages - Cloud provider and key services choices - Database and storage solutions - if unclear suggest sql or nosql or other types depending on the project and depending on cloud provider offer a suggestion - Development tools - + Upon render of the table, ensure the user is aware of the importance of this sections choices, should also look for gaps or disagreements with anything, ask for any clarifications if something is unclear why its in the list, and also right away elicit feedback - this statement and the options should be rendered and then prompt right all before allowing user input. elicit: true sections: @@ -5858,13 +5858,13 @@ sections: title: Data Models instruction: | Define the core data models/entities: - + 1. Review PRD requirements and identify key business entities 2. For each model, explain its purpose and relationships 3. Include key attributes and data types 4. Show relationships between models 5. Discuss design decisions with user - + Create a clear conceptual model before moving to database schema. elicit: true repeatable: true @@ -5873,11 +5873,11 @@ sections: title: "{{model_name}}" template: | **Purpose:** {{model_purpose}} - + **Key Attributes:** - {{attribute_1}}: {{type_1}} - {{description_1}} - {{attribute_2}}: {{type_2}} - {{description_2}} - + **Relationships:** - {{relationship_1}} - {{relationship_2}} @@ -5886,7 +5886,7 @@ sections: title: Components instruction: | Based on the architectural patterns, tech stack, and data models from above: - + 1. Identify major logical components/services and their responsibilities 2. Consider the repository structure (monorepo/polyrepo) from PRD 3. Define clear boundaries and interfaces between components @@ -5895,7 +5895,7 @@ sections: - Key interfaces/APIs exposed - Dependencies on other components - Technology specifics based on tech stack choices - + 5. Create component diagrams where helpful elicit: true sections: @@ -5904,13 +5904,13 @@ sections: title: "{{component_name}}" template: | **Responsibility:** {{component_description}} - + **Key Interfaces:** - {{interface_1}} - {{interface_2}} - + **Dependencies:** {{dependencies}} - + **Technology Stack:** {{component_tech_details}} - id: component-diagrams title: Component Diagrams @@ -5927,13 +5927,13 @@ sections: condition: Project requires external API integrations instruction: | For each external service integration: - + 1. Identify APIs needed based on PRD requirements and component design 2. If documentation URLs are unknown, ask user for specifics 3. Document authentication methods and security considerations 4. List specific endpoints that will be used 5. Note any rate limits or usage constraints - + If no external APIs are needed, state this explicitly and skip to next section. elicit: true repeatable: true @@ -5946,10 +5946,10 @@ sections: - **Base URL(s):** {{api_base_url}} - **Authentication:** {{auth_method}} - **Rate Limits:** {{rate_limits}} - + **Key Endpoints Used:** - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}} - + **Integration Notes:** {{integration_considerations}} - id: core-workflows @@ -5958,13 +5958,13 @@ sections: mermaid_type: sequence instruction: | Illustrate key system workflows using sequence diagrams: - + 1. Identify critical user journeys from PRD 2. Show component interactions including external APIs 3. Include error handling paths 4. Document async operations 5. Create both high-level and detailed diagrams as needed - + Focus on workflows that clarify architecture decisions or complex interactions. elicit: true @@ -5975,13 +5975,13 @@ sections: language: yaml instruction: | If the project includes a REST API: - + 1. Create an OpenAPI 3.0 specification 2. Include all endpoints from epics/stories 3. Define request/response schemas based on data models 4. Document authentication requirements 5. Include example requests/responses - + Use YAML format for better readability. If no REST API, skip this section. elicit: true template: | @@ -5998,13 +5998,13 @@ sections: title: Database Schema instruction: | Transform the conceptual data models into concrete database schemas: - + 1. Use the database type(s) selected in Tech Stack 2. Create schema definitions using appropriate notation 3. Include indexes, constraints, and relationships 4. Consider performance and scalability 5. For NoSQL, show document structures - + Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.) elicit: true @@ -6014,14 +6014,14 @@ sections: language: plaintext instruction: | Create a project folder structure that reflects: - + 1. The chosen repository structure (monorepo/polyrepo) 2. The service architecture (monolith/microservices/serverless) 3. The selected tech stack and languages 4. Component organization from above 5. Best practices for the chosen frameworks 6. Clear separation of concerns - + Adapt the structure based on project needs. For monorepos, show service separation. For serverless, show function organization. Include language-specific conventions. elicit: true examples: @@ -6039,13 +6039,13 @@ sections: title: Infrastructure and Deployment instruction: | Define the deployment architecture and practices: - + 1. Use IaC tool selected in Tech Stack 2. Choose deployment strategy appropriate for the architecture 3. Define environments and promotion flow 4. Establish rollback procedures 5. Consider security, monitoring, and cost optimization - + Get user input on deployment preferences and CI/CD tool choices. elicit: true sections: @@ -6081,13 +6081,13 @@ sections: title: Error Handling Strategy instruction: | Define comprehensive error handling approach: - + 1. Choose appropriate patterns for the language/framework from Tech Stack 2. Define logging standards and tools 3. Establish error categories and handling rules 4. Consider observability and debugging needs 5. Ensure security (no sensitive data in logs) - + This section guides both AI and human developers in consistent error handling. elicit: true sections: @@ -6134,13 +6134,13 @@ sections: title: Coding Standards instruction: | These standards are MANDATORY for AI agents. Work with user to define ONLY the critical rules needed to prevent bad code. Explain that: - + 1. This section directly controls AI developer behavior 2. Keep it minimal - assume AI knows general best practices 3. Focus on project-specific conventions and gotchas 4. Overly detailed standards bloat context and slow development 5. Standards will be extracted to separate file for dev agent use - + For each standard, get explicit user confirmation it's necessary. elicit: true sections: @@ -6162,7 +6162,7 @@ sections: - "Never use console.log in production code - use logger" - "All API responses must use ApiResponse wrapper type" - "Database queries must use repository pattern, never direct ORM" - + Avoid obvious rules like "use SOLID principles" or "write clean code" repeatable: true template: "- **{{rule_name}}:** {{rule_description}}" @@ -6180,14 +6180,14 @@ sections: title: Test Strategy and Standards instruction: | Work with user to define comprehensive test strategy: - + 1. Use test frameworks from Tech Stack 2. Decide on TDD vs test-after approach 3. Define test organization and naming 4. Establish coverage goals 5. Determine integration test infrastructure 6. Plan for test data and external dependencies - + Note: Basic info goes in Coding Standards for dev agent. This detailed section is for QA agent and team reference. elicit: true sections: @@ -6208,7 +6208,7 @@ sections: - **Location:** {{unit_test_location}} - **Mocking Library:** {{mocking_library}} - **Coverage Requirement:** {{unit_coverage}} - + **AI Agent Requirements:** - Generate tests for all public methods - Cover edge cases and error conditions @@ -6250,7 +6250,7 @@ sections: title: Security instruction: | Define MANDATORY security requirements for AI and human developers: - + 1. Focus on implementation-specific rules 2. Reference security tools from Tech Stack 3. Define clear patterns for common scenarios @@ -6319,16 +6319,16 @@ sections: title: Next Steps instruction: | After completing the architecture: - + 1. If project has UI components: - Use "Frontend Architecture Mode" - Provide this document as input - + 2. For all projects: - Review with Product Owner - Begin story implementation with Dev agent - Set up infrastructure with DevOps agent - + 3. Include specific prompts for next agents if needed sections: - id: architect-prompt @@ -6361,16 +6361,16 @@ sections: title: Template and Framework Selection instruction: | Review provided documents including PRD, UX-UI Specification, and main Architecture Document. Focus on extracting technical implementation details needed for AI frontend tools and developer agents. Ask the user for any of these documents if you are unable to locate and were not provided. - + Before proceeding with frontend architecture design, check if the project is using a frontend starter template or existing codebase: - + 1. Review the PRD, main architecture document, and brainstorming brief for mentions of: - Frontend starter templates (e.g., Create React App, Next.js, Vite, Vue CLI, Angular CLI, etc.) - UI kit or component library starters - Existing frontend projects being used as a foundation - Admin dashboard templates or other specialized starters - Design system implementations - + 2. If a frontend starter template or existing project is mentioned: - Ask the user to provide access via one of these methods: - Link to the starter template documentation @@ -6386,7 +6386,7 @@ sections: - Testing setup and patterns - Build and development scripts - Use this analysis to ensure your frontend architecture aligns with the starter's patterns - + 3. If no frontend starter is mentioned but this is a new UI, ensure we know what the ui language and framework is: - Based on the framework choice, suggest appropriate starters: - React: Create React App, Next.js, Vite + React @@ -6394,11 +6394,11 @@ sections: - Angular: Angular CLI - Or suggest popular UI templates if applicable - Explain benefits specific to frontend development - + 4. If the user confirms no starter template will be used: - Note that all tooling, bundling, and configuration will need manual setup - Proceed with frontend architecture from scratch - + Document the starter template decision and any constraints it imposes before proceeding. sections: - id: changelog @@ -6573,33 +6573,33 @@ sections: elicit: true content: | This document outlines the complete fullstack architecture for {{project_name}}, including backend systems, frontend implementation, and their integration. It serves as the single source of truth for AI-driven development, ensuring consistency across the entire technology stack. - + This unified approach combines what would traditionally be separate backend and frontend architecture documents, streamlining the development process for modern fullstack applications where these concerns are increasingly intertwined. sections: - id: starter-template title: Starter Template or Existing Project instruction: | Before proceeding with architecture design, check if the project is based on any starter templates or existing codebases: - + 1. Review the PRD and other documents for mentions of: - Fullstack starter templates (e.g., T3 Stack, MEAN/MERN starters, Django + React templates) - Monorepo templates (e.g., Nx, Turborepo starters) - Platform-specific starters (e.g., Vercel templates, AWS Amplify starters) - Existing projects being extended or cloned - + 2. If starter templates or existing projects are mentioned: - Ask the user to provide access (links, repos, or files) - Analyze to understand pre-configured choices and constraints - Note any architectural decisions already made - Identify what can be modified vs what must be retained - + 3. If no starter is mentioned but this is greenfield: - Suggest appropriate fullstack starters based on tech preferences - Consider platform-specific options (Vercel, AWS, etc.) - Let user decide whether to use one - + 4. Document the decision and any constraints it imposes - + If none, state "N/A - Greenfield project" - id: changelog title: Change Log @@ -6625,17 +6625,17 @@ sections: title: Platform and Infrastructure Choice instruction: | Based on PRD requirements and technical assumptions, make a platform recommendation: - + 1. Consider common patterns (not an exhaustive list, use your own best judgement and search the web as needed for emerging trends): - **Vercel + Supabase**: For rapid development with Next.js, built-in auth/storage - **AWS Full Stack**: For enterprise scale with Lambda, API Gateway, S3, Cognito - **Azure**: For .NET ecosystems or enterprise Microsoft environments - **Google Cloud**: For ML/AI heavy applications or Google ecosystem integration - + 2. Present 2-3 viable options with clear pros/cons 3. Make a recommendation with rationale 4. Get explicit user confirmation - + Document the choice and key services that will be used. template: | **Platform:** {{selected_platform}} @@ -6645,7 +6645,7 @@ sections: title: Repository Structure instruction: | Define the repository approach based on PRD requirements and platform choice, explain your rationale or ask questions to the user if unsure: - + 1. For modern fullstack apps, monorepo is often preferred 2. Consider tooling (Nx, Turborepo, Lerna, npm workspaces) 3. Define package/app boundaries @@ -6667,7 +6667,7 @@ sections: - Databases and storage - External integrations - CDN and caching layers - + Use appropriate diagram type for clarity. - id: architectural-patterns title: Architectural Patterns @@ -6677,7 +6677,7 @@ sections: - Frontend patterns (e.g., Component-based, State management) - Backend patterns (e.g., Repository, CQRS, Event-driven) - Integration patterns (e.g., BFF, API Gateway) - + For each pattern, provide recommendation and rationale. repeatable: true template: "- **{{pattern_name}}:** {{pattern_description}} - _Rationale:_ {{rationale}}" @@ -6691,7 +6691,7 @@ sections: title: Tech Stack instruction: | This is the DEFINITIVE technology selection for the entire project. Work with user to finalize all choices. This table is the single source of truth - all development must use these exact versions. - + Key areas to cover: - Frontend and backend languages/frameworks - Databases and caching @@ -6700,7 +6700,7 @@ sections: - Testing tools for both frontend and backend - Build and deployment tools - Monitoring and logging - + Upon render, elicit feedback immediately. elicit: true sections: @@ -6735,14 +6735,14 @@ sections: title: Data Models instruction: | Define the core data models/entities that will be shared between frontend and backend: - + 1. Review PRD requirements and identify key business entities 2. For each model, explain its purpose and relationships 3. Include key attributes and data types 4. Show relationships between models 5. Create TypeScript interfaces that can be shared 6. Discuss design decisions with user - + Create a clear conceptual model before moving to database schema. elicit: true repeatable: true @@ -6751,7 +6751,7 @@ sections: title: "{{model_name}}" template: | **Purpose:** {{model_purpose}} - + **Key Attributes:** - {{attribute_1}}: {{type_1}} - {{description_1}} - {{attribute_2}}: {{type_2}} - {{description_2}} @@ -6770,7 +6770,7 @@ sections: title: API Specification instruction: | Based on the chosen API style from Tech Stack: - + 1. If REST API, create an OpenAPI 3.0 specification 2. If GraphQL, provide the GraphQL schema 3. If tRPC, show router definitions @@ -6778,7 +6778,7 @@ sections: 5. Define request/response schemas based on data models 6. Document authentication requirements 7. Include example requests/responses - + Use appropriate format for the chosen API style. If no API (e.g., static site), skip this section. elicit: true sections: @@ -6813,7 +6813,7 @@ sections: title: Components instruction: | Based on the architectural patterns, tech stack, and data models from above: - + 1. Identify major logical components/services across the fullstack 2. Consider both frontend and backend components 3. Define clear boundaries and interfaces between components @@ -6822,7 +6822,7 @@ sections: - Key interfaces/APIs exposed - Dependencies on other components - Technology specifics based on tech stack choices - + 5. Create component diagrams where helpful elicit: true sections: @@ -6831,13 +6831,13 @@ sections: title: "{{component_name}}" template: | **Responsibility:** {{component_description}} - + **Key Interfaces:** - {{interface_1}} - {{interface_2}} - + **Dependencies:** {{dependencies}} - + **Technology Stack:** {{component_tech_details}} - id: component-diagrams title: Component Diagrams @@ -6854,13 +6854,13 @@ sections: condition: Project requires external API integrations instruction: | For each external service integration: - + 1. Identify APIs needed based on PRD requirements and component design 2. If documentation URLs are unknown, ask user for specifics 3. Document authentication methods and security considerations 4. List specific endpoints that will be used 5. Note any rate limits or usage constraints - + If no external APIs are needed, state this explicitly and skip to next section. elicit: true repeatable: true @@ -6873,10 +6873,10 @@ sections: - **Base URL(s):** {{api_base_url}} - **Authentication:** {{auth_method}} - **Rate Limits:** {{rate_limits}} - + **Key Endpoints Used:** - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}} - + **Integration Notes:** {{integration_considerations}} - id: core-workflows @@ -6885,14 +6885,14 @@ sections: mermaid_type: sequence instruction: | Illustrate key system workflows using sequence diagrams: - + 1. Identify critical user journeys from PRD 2. Show component interactions including external APIs 3. Include both frontend and backend flows 4. Include error handling paths 5. Document async operations 6. Create both high-level and detailed diagrams as needed - + Focus on workflows that clarify architecture decisions or complex interactions. elicit: true @@ -6900,13 +6900,13 @@ sections: title: Database Schema instruction: | Transform the conceptual data models into concrete database schemas: - + 1. Use the database type(s) selected in Tech Stack 2. Create schema definitions using appropriate notation 3. Include indexes, constraints, and relationships 4. Consider performance and scalability 5. For NoSQL, show document structures - + Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.) elicit: true @@ -7122,13 +7122,13 @@ sections: template: | # Start all services {{start_all_command}} - + # Start frontend only {{start_frontend_command}} - + # Start backend only {{start_backend_command}} - + # Run tests {{test_commands}} - id: environment-config @@ -7141,10 +7141,10 @@ sections: template: | # Frontend (.env.local) {{frontend_env_vars}} - + # Backend (.env) {{backend_env_vars}} - + # Shared {{shared_env_vars}} @@ -7161,7 +7161,7 @@ sections: - **Build Command:** {{frontend_build_command}} - **Output Directory:** {{frontend_output_dir}} - **CDN/Edge:** {{cdn_strategy}} - + **Backend Deployment:** - **Platform:** {{backend_deploy_platform}} - **Build Command:** {{backend_build_command}} @@ -7192,12 +7192,12 @@ sections: - CSP Headers: {{csp_policy}} - XSS Prevention: {{xss_strategy}} - Secure Storage: {{storage_strategy}} - + **Backend Security:** - Input Validation: {{validation_approach}} - Rate Limiting: {{rate_limit_config}} - CORS Policy: {{cors_config}} - + **Authentication Security:** - Token Storage: {{token_strategy}} - Session Management: {{session_approach}} @@ -7209,7 +7209,7 @@ sections: - Bundle Size Target: {{bundle_size}} - Loading Strategy: {{loading_approach}} - Caching Strategy: {{fe_cache_strategy}} - + **Backend Performance:** - Response Time Target: {{response_target}} - Database Optimization: {{db_optimization}} @@ -7347,7 +7347,7 @@ sections: - JavaScript errors - API response times - User interactions - + **Backend Metrics:** - Request rate - Error rate @@ -7378,40 +7378,40 @@ sections: title: Introduction instruction: | IMPORTANT - SCOPE AND ASSESSMENT REQUIRED: - + This architecture document is for SIGNIFICANT enhancements to existing projects that require comprehensive architectural planning. Before proceeding: - + 1. **Verify Complexity**: Confirm this enhancement requires architectural planning. For simple additions, recommend: "For simpler changes that don't require architectural planning, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead." - + 2. **REQUIRED INPUTS**: - Completed brownfield-prd.md - Existing project technical documentation (from docs folder or user-provided) - Access to existing project structure (IDE or uploaded files) - + 3. **DEEP ANALYSIS MANDATE**: You MUST conduct thorough analysis of the existing codebase, architecture patterns, and technical constraints before making ANY architectural recommendations. Every suggestion must be based on actual project analysis, not assumptions. - + 4. **CONTINUOUS VALIDATION**: Throughout this process, explicitly validate your understanding with the user. For every architectural decision, confirm: "Based on my analysis of your existing system, I recommend [decision] because [evidence from actual project]. Does this align with your system's reality?" - + If any required inputs are missing, request them before proceeding. elicit: true sections: - id: intro-content content: | This document outlines the architectural approach for enhancing {{project_name}} with {{enhancement_description}}. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development of new features while ensuring seamless integration with the existing system. - + **Relationship to Existing Architecture:** This document supplements existing project architecture by defining how new components will integrate with current systems. Where conflicts arise between new and existing patterns, this document provides guidance on maintaining consistency while implementing enhancements. - id: existing-project-analysis title: Existing Project Analysis instruction: | Analyze the existing project structure and architecture: - + 1. Review existing documentation in docs folder 2. Examine current technology stack and versions 3. Identify existing architectural patterns and conventions 4. Note current deployment and infrastructure setup 5. Document any constraints or limitations - + CRITICAL: After your analysis, explicitly validate your findings: "Based on my analysis of your project, I've identified the following about your existing system: [key findings]. Please confirm these observations are accurate before I proceed with architectural recommendations." elicit: true sections: @@ -7440,12 +7440,12 @@ sections: title: Enhancement Scope and Integration Strategy instruction: | Define how the enhancement will integrate with the existing system: - + 1. Review the brownfield PRD enhancement scope 2. Identify integration points with existing code 3. Define boundaries between new and existing functionality 4. Establish compatibility requirements - + VALIDATION CHECKPOINT: Before presenting the integration strategy, confirm: "Based on my analysis, the integration approach I'm proposing takes into account [specific existing system characteristics]. These integration points and boundaries respect your current architecture patterns. Is this assessment accurate?" elicit: true sections: @@ -7474,7 +7474,7 @@ sections: title: Tech Stack Alignment instruction: | Ensure new components align with existing technology choices: - + 1. Use existing technology stack as the foundation 2. Only introduce new technologies if absolutely necessary 3. Justify any new additions with clear rationale @@ -7497,7 +7497,7 @@ sections: title: Data Models and Schema Changes instruction: | Define new data models and how they integrate with existing schema: - + 1. Identify new entities required for the enhancement 2. Define relationships with existing data models 3. Plan database schema changes (additions, modifications) @@ -7513,11 +7513,11 @@ sections: template: | **Purpose:** {{model_purpose}} **Integration:** {{integration_with_existing}} - + **Key Attributes:** - {{attribute_1}}: {{type_1}} - {{description_1}} - {{attribute_2}}: {{type_2}} - {{description_2}} - + **Relationships:** - **With Existing:** {{existing_relationships}} - **With New:** {{new_relationships}} @@ -7529,7 +7529,7 @@ sections: - **Modified Tables:** {{modified_tables_list}} - **New Indexes:** {{new_indexes_list}} - **Migration Strategy:** {{migration_approach}} - + **Backward Compatibility:** - {{compatibility_measure_1}} - {{compatibility_measure_2}} @@ -7538,12 +7538,12 @@ sections: title: Component Architecture instruction: | Define new components and their integration with existing architecture: - + 1. Identify new components required for the enhancement 2. Define interfaces with existing components 3. Establish clear boundaries and responsibilities 4. Plan integration points and data flow - + MANDATORY VALIDATION: Before presenting component architecture, confirm: "The new components I'm proposing follow the existing architectural patterns I identified in your codebase: [specific patterns]. The integration interfaces respect your current component structure and communication patterns. Does this match your project's reality?" elicit: true sections: @@ -7556,15 +7556,15 @@ sections: template: | **Responsibility:** {{component_description}} **Integration Points:** {{integration_points}} - + **Key Interfaces:** - {{interface_1}} - {{interface_2}} - + **Dependencies:** - **Existing Components:** {{existing_dependencies}} - **New Components:** {{new_dependencies}} - + **Technology Stack:** {{component_tech_details}} - id: interaction-diagram title: Component Interaction Diagram @@ -7577,7 +7577,7 @@ sections: condition: Enhancement requires API changes instruction: | Define new API endpoints and integration with existing APIs: - + 1. Plan new API endpoints required for the enhancement 2. Ensure consistency with existing API patterns 3. Define authentication and authorization integration @@ -7627,17 +7627,17 @@ sections: - **Base URL:** {{api_base_url}} - **Authentication:** {{auth_method}} - **Integration Method:** {{integration_approach}} - + **Key Endpoints Used:** - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}} - + **Error Handling:** {{error_handling_strategy}} - id: source-tree-integration title: Source Tree Integration instruction: | Define how new code will integrate with existing project structure: - + 1. Follow existing project organization patterns 2. Identify where new files/folders will be placed 3. Ensure consistency with existing naming conventions @@ -7676,7 +7676,7 @@ sections: title: Infrastructure and Deployment Integration instruction: | Define how the enhancement will be deployed alongside existing infrastructure: - + 1. Use existing deployment pipeline and infrastructure 2. Identify any infrastructure changes needed 3. Plan deployment strategy to minimize risk @@ -7706,7 +7706,7 @@ sections: title: Coding Standards and Conventions instruction: | Ensure new code follows existing project conventions: - + 1. Document existing coding standards from project analysis 2. Identify any enhancement-specific requirements 3. Ensure consistency with existing codebase patterns @@ -7737,7 +7737,7 @@ sections: title: Testing Strategy instruction: | Define testing approach for the enhancement: - + 1. Integrate with existing test suite 2. Ensure existing functionality remains intact 3. Plan for testing new features @@ -7777,7 +7777,7 @@ sections: title: Security Integration instruction: | Ensure security consistency with existing system: - + 1. Follow existing security patterns and tools 2. Ensure new features don't introduce vulnerabilities 3. Maintain existing security posture @@ -7812,7 +7812,7 @@ sections: title: Next Steps instruction: | After completing the brownfield architecture: - + 1. Review integration points with existing system 2. Begin story implementation with Dev agent 3. Set up deployment pipeline integration @@ -8436,7 +8436,7 @@ workflow: elicitation: advanced-elicitation agent_config: - editable_sections: + editable_sections: - Status - Story - Acceptance Criteria @@ -8453,7 +8453,7 @@ sections: instruction: Select the current status of the story owner: scrum-master editors: [scrum-master, dev-agent] - + - id: story title: Story type: template-text @@ -8465,7 +8465,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: acceptance-criteria title: Acceptance Criteria type: numbered-list @@ -8473,7 +8473,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: tasks-subtasks title: Tasks / Subtasks type: bullet-list @@ -8490,7 +8490,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master, dev-agent] - + - id: dev-notes title: Dev Notes instruction: | @@ -8514,7 +8514,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: change-log title: Change Log type: table @@ -8522,7 +8522,7 @@ sections: instruction: Track changes made to this story document owner: scrum-master editors: [scrum-master, dev-agent, qa-agent] - + - id: dev-agent-record title: Dev Agent Record instruction: This section is populated by the development agent during implementation @@ -8535,25 +8535,25 @@ sections: instruction: Record the specific AI agent model and version used for development owner: dev-agent editors: [dev-agent] - + - id: debug-log-references title: Debug Log References instruction: Reference any debug logs or traces generated during development owner: dev-agent editors: [dev-agent] - + - id: completion-notes title: Completion Notes List instruction: Notes about the completion of tasks and any issues encountered owner: dev-agent editors: [dev-agent] - + - id: file-list title: File List instruction: List all files created, modified, or affected during story implementation owner: dev-agent editors: [dev-agent] - + - id: qa-results title: QA Results instruction: Results from QA Agent QA review of the completed story implementation @@ -9026,9 +9026,9 @@ workflow: notes: | Determine enhancement complexity to route to appropriate path: - Single story (< 4 hours) → Use brownfield-create-story task - - Small feature (1-3 stories) → Use brownfield-create-epic task + - Small feature (1-3 stories) → Use brownfield-create-epic task - Major enhancement (multiple epics) → Continue with full workflow - + Ask user: "Can you describe the enhancement scope? Is this a small fix, a feature addition, or a major enhancement requiring architectural changes?" - step: routing_decision @@ -9189,7 +9189,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -9197,40 +9197,40 @@ workflow: graph TD A[Start: Brownfield Enhancement] --> B[analyst: classify enhancement scope] B --> C{Enhancement Size?} - + C -->|Single Story| D[pm: brownfield-create-story] C -->|1-3 Stories| E[pm: brownfield-create-epic] C -->|Major Enhancement| F[analyst: check documentation] - + D --> END1[To Dev Implementation] E --> END2[To Story Creation] - + F --> G{Docs Adequate?} G -->|No| H[architect: document-project] G -->|Yes| I[pm: brownfield PRD] H --> I - + I --> J{Architecture Needed?} J -->|Yes| K[architect: architecture.md] J -->|No| L[po: validate artifacts] K --> L - + L --> M{PO finds issues?} M -->|Yes| N[Fix issues] M -->|No| O[po: shard documents] N --> L - + O --> P[sm: create story] P --> Q{Story Type?} Q -->|Sharded PRD| R[create-next-story] Q -->|Brownfield Docs| S[create-brownfield-story] - + R --> T{Review draft?} S --> T T -->|Yes| U[review & approve] T -->|No| V[dev: implement] U --> V - + V --> W{QA review?} W -->|Yes| X[qa: review] W -->|No| Y{More stories?} @@ -9273,35 +9273,35 @@ workflow: {{if single_story}}: Proceeding with brownfield-create-story task for immediate implementation. {{if small_feature}}: Creating focused epic with brownfield-create-epic task. {{if major_enhancement}}: Continuing with comprehensive planning workflow. - + documentation_assessment: | Documentation assessment complete: {{if adequate}}: Existing documentation is sufficient. Proceeding directly to PRD creation. {{if inadequate}}: Running document-project to capture current system state before PRD. - + document_project_to_pm: | Project analysis complete. Key findings documented in: - {{document_list}} Use these findings to inform PRD creation and avoid re-analyzing the same aspects. - + pm_to_architect_decision: | - PRD complete and saved as docs/prd.md. + PRD complete and saved as docs/prd.md. Architectural changes identified: {{yes/no}} {{if yes}}: Proceeding to create architecture document for: {{specific_changes}} {{if no}}: No architectural changes needed. Proceeding to validation. - + architect_to_po: "Architecture complete. Save it as docs/architecture.md. Please validate all artifacts for integration safety." - + po_to_sm: | - All artifacts validated. + All artifacts validated. Documentation type available: {{sharded_prd / brownfield_docs}} {{if sharded}}: Use standard create-next-story task. {{if brownfield}}: Use create-brownfield-story task to handle varied documentation formats. - + sm_story_creation: | Creating story from {{documentation_type}}. {{if missing_context}}: May need to gather additional context from user during story creation. - + complete: "All planning artifacts validated and development can begin. Stories will be created based on available documentation format." ==================== END: .bmad-core/workflows/brownfield-fullstack.yaml ==================== @@ -9435,7 +9435,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -9449,7 +9449,7 @@ workflow: F -->|Yes| G[Return to relevant agent for fixes] F -->|No| H[po: shard documents] G --> E - + H --> I[sm: create story] I --> J{Review draft story?} J -->|Yes| K[analyst/pm: review & approve story] @@ -9632,7 +9632,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -9647,7 +9647,7 @@ workflow: G -->|Yes| H[Return to relevant agent for fixes] G -->|No| I[po: shard documents] H --> F - + I --> J[sm: create story] J --> K{Review draft story?} K -->|Yes| L[analyst/pm: review & approve story] @@ -9857,7 +9857,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -9879,7 +9879,7 @@ workflow: I -->|Yes| J[Return to relevant agent for fixes] I -->|No| K[po: shard documents] J --> H - + K --> L[sm: create story] L --> M{Review draft story?} M -->|Yes| N[analyst/pm: review & approve story] @@ -10076,7 +10076,7 @@ workflow: notes: | All stories implemented and reviewed! Service development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -10093,7 +10093,7 @@ workflow: H -->|Yes| I[Return to relevant agent for fixes] H -->|No| J[po: shard documents] I --> G - + J --> K[sm: create story] K --> L{Review draft story?} L -->|Yes| M[analyst/pm: review & approve story] @@ -10304,7 +10304,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -10326,7 +10326,7 @@ workflow: I -->|Yes| J[Return to relevant agent for fixes] I -->|No| K[po: shard documents] J --> H - + K --> L[sm: create story] L --> M{Review draft story?} M -->|Yes| N[analyst/pm: review & approve story] diff --git a/dist/teams/team-ide-minimal.txt b/bundles/teams/team-ide-minimal.txt similarity index 99% rename from dist/teams/team-ide-minimal.txt rename to bundles/teams/team-ide-minimal.txt index 7b707d54b..b60fa6e1f 100644 --- a/dist/teams/team-ide-minimal.txt +++ b/bundles/teams/team-ide-minimal.txt @@ -775,7 +775,7 @@ BMad transforms you into a "Vibe CEO" - directing a team of specialized AI agent **Best for**: ChatGPT, Claude, Gemini users who want to start immediately -1. Navigate to `dist/teams/` +1. Navigate to `bundles/teams/` 2. Copy `team-fullstack.txt` content 3. Create new Gemini Gem or CustomGPT 4. Upload file with instructions: "Your critical operating instructions are attached, do not break character as directed" @@ -1095,8 +1095,8 @@ The BMad-Method is built around a modular architecture centered on the `bmad-cor #### Web UI Environment -- Uses pre-built bundles from `dist/teams` for stand alone 1 upload files for all agents and their assets with an orchestrating agent -- Single text files containing all agent dependencies are in `dist/agents/` - these are unnecessary unless you want to create a web agent that is only a single agent and not a team +- Uses pre-built bundles from `bundles/teams` for stand alone 1 upload files for all agents and their assets with an orchestrating agent +- Single text files containing all agent dependencies are in `bundles/agents/` - these are unnecessary unless you want to create a web agent that is only a single agent and not a team - Created by the web-builder tool for upload to web interfaces - Provides complete context in one package @@ -1243,7 +1243,7 @@ Each status change requires user verification and approval before proceeding. #### Greenfield Development - Business analysis and market research -- Product requirements and feature definition +- Product requirements and feature definition - System architecture and design - Development execution - Testing and deployment @@ -1352,7 +1352,7 @@ Templates with Level 2 headings (`##`) can be automatically sharded: ```markdown ## Goals and Background Context -## Requirements +## Requirements ## User Interface Design Goals ## Success Metrics ``` @@ -2537,7 +2537,7 @@ workflow: elicitation: advanced-elicitation agent_config: - editable_sections: + editable_sections: - Status - Story - Acceptance Criteria @@ -2554,7 +2554,7 @@ sections: instruction: Select the current status of the story owner: scrum-master editors: [scrum-master, dev-agent] - + - id: story title: Story type: template-text @@ -2566,7 +2566,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: acceptance-criteria title: Acceptance Criteria type: numbered-list @@ -2574,7 +2574,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: tasks-subtasks title: Tasks / Subtasks type: bullet-list @@ -2591,7 +2591,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master, dev-agent] - + - id: dev-notes title: Dev Notes instruction: | @@ -2615,7 +2615,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: change-log title: Change Log type: table @@ -2623,7 +2623,7 @@ sections: instruction: Track changes made to this story document owner: scrum-master editors: [scrum-master, dev-agent, qa-agent] - + - id: dev-agent-record title: Dev Agent Record instruction: This section is populated by the development agent during implementation @@ -2636,25 +2636,25 @@ sections: instruction: Record the specific AI agent model and version used for development owner: dev-agent editors: [dev-agent] - + - id: debug-log-references title: Debug Log References instruction: Reference any debug logs or traces generated during development owner: dev-agent editors: [dev-agent] - + - id: completion-notes title: Completion Notes List instruction: Notes about the completion of tasks and any issues encountered owner: dev-agent editors: [dev-agent] - + - id: file-list title: File List instruction: List all files created, modified, or affected during story implementation owner: dev-agent editors: [dev-agent] - + - id: qa-results title: QA Results instruction: Results from QA Agent QA review of the completed story implementation diff --git a/dist/teams/team-no-ui.txt b/bundles/teams/team-no-ui.txt similarity index 99% rename from dist/teams/team-no-ui.txt rename to bundles/teams/team-no-ui.txt index b146f37a9..3fe87b891 100644 --- a/dist/teams/team-no-ui.txt +++ b/bundles/teams/team-no-ui.txt @@ -811,7 +811,7 @@ BMad transforms you into a "Vibe CEO" - directing a team of specialized AI agent **Best for**: ChatGPT, Claude, Gemini users who want to start immediately -1. Navigate to `dist/teams/` +1. Navigate to `bundles/teams/` 2. Copy `team-fullstack.txt` content 3. Create new Gemini Gem or CustomGPT 4. Upload file with instructions: "Your critical operating instructions are attached, do not break character as directed" @@ -1131,8 +1131,8 @@ The BMad-Method is built around a modular architecture centered on the `bmad-cor #### Web UI Environment -- Uses pre-built bundles from `dist/teams` for stand alone 1 upload files for all agents and their assets with an orchestrating agent -- Single text files containing all agent dependencies are in `dist/agents/` - these are unnecessary unless you want to create a web agent that is only a single agent and not a team +- Uses pre-built bundles from `bundles/teams` for stand alone 1 upload files for all agents and their assets with an orchestrating agent +- Single text files containing all agent dependencies are in `bundles/agents/` - these are unnecessary unless you want to create a web agent that is only a single agent and not a team - Created by the web-builder tool for upload to web interfaces - Provides complete context in one package @@ -1279,7 +1279,7 @@ Each status change requires user verification and approval before proceeding. #### Greenfield Development - Business analysis and market research -- Product requirements and feature definition +- Product requirements and feature definition - System architecture and design - Development execution - Testing and deployment @@ -1388,7 +1388,7 @@ Templates with Level 2 headings (`##`) can be automatically sharded: ```markdown ## Goals and Background Context -## Requirements +## Requirements ## User Interface Design Goals ## Success Metrics ``` @@ -1795,7 +1795,7 @@ If user selects Option 1, present numbered list of techniques from the brainstor 1. Apply selected technique according to data file description 2. Keep engaging with technique until user indicates they want to: - Choose a different technique - - Apply current ideas to a new technique + - Apply current ideas to a new technique - Move to convergent phase - End session @@ -2555,12 +2555,12 @@ sections: - id: introduction instruction: | This template guides creation of a comprehensive Project Brief that serves as the foundational input for product development. - + Start by asking the user which mode they prefer: - + 1. **Interactive Mode** - Work through each section collaboratively 2. **YOLO Mode** - Generate complete draft for review and refinement - + Before beginning, understand what inputs are available (brainstorming results, market research, competitive analysis, initial ideas) and gather project context. - id: executive-summary @@ -2881,7 +2881,7 @@ sections: instruction: Map the end-to-end customer experience for primary segments template: | For primary customer segment: - + 1. **Awareness:** {{discovery_process}} 2. **Consideration:** {{evaluation_criteria}} 3. **Purchase:** {{decision_triggers}} @@ -3082,7 +3082,7 @@ sections: title: Competitor Prioritization Matrix instruction: | Help categorize competitors by market share and strategic threat level - + Create a 2x2 matrix: - Priority 1 (Core Competitors): High Market Share + High Threat - Priority 2 (Emerging Threats): Low Market Share + High Threat @@ -3186,7 +3186,7 @@ sections: title: Positioning Map instruction: | Describe competitor positions on key dimensions - + Create a positioning description using 2 key dimensions relevant to the market, such as: - Price vs. Features - Ease of Use vs. Power @@ -3221,7 +3221,7 @@ sections: title: Blue Ocean Opportunities instruction: | Identify uncontested market spaces - + List opportunities to create new market space: - Underserved segments - Unaddressed use cases @@ -3325,11 +3325,11 @@ sections: - id: summary-details template: | **Topic:** {{session_topic}} - + **Session Goals:** {{stated_goals}} - + **Techniques Used:** {{techniques_list}} - + **Total Ideas Generated:** {{total_ideas}} - id: key-themes title: "Key Themes Identified:" @@ -3454,7 +3454,7 @@ sections: - id: footer content: | --- - + *Session facilitated using the BMAD-METHOD brainstorming framework* ==================== END: .bmad-core/templates/brainstorming-output-tmpl.yaml ==================== @@ -4228,7 +4228,7 @@ sections: condition: PRD has UX/UI requirements instruction: | Capture high-level UI/UX vision to guide Design Architect and to inform story creation. Steps: - + 1. Pre-fill all subsections with educated guesses based on project context 2. Present the complete rendered section to user 3. Clearly let the user know where assumptions were made @@ -4270,7 +4270,7 @@ sections: title: Technical Assumptions instruction: | Gather technical decisions that will guide the Architect. Steps: - + 1. Check if .bmad-core/data/technical-preferences.yaml or an attached technical-preferences file exists - use it to pre-populate choices 2. Ask user about: languages, frameworks, starter templates, libraries, APIs, deployment targets 3. For unknowns, offer guidance based on project goals and MVP scope @@ -4298,9 +4298,9 @@ sections: title: Epic List instruction: | Present a high-level list of all epics for user approval. Each epic should have a title and a short (1 sentence) goal statement. This allows the user to review the overall structure before diving into details. - + CRITICAL: Epics MUST be logically sequential following agile best practices: - + - Each epic should deliver a significant, end-to-end, fully deployable increment of testable functionality - Epic 1 must establish foundational project infrastructure (app setup, Git, CI/CD, core services) unless we are adding new functionality to an existing app, while also delivering an initial piece of functionality, even as simple as a health-check route or display of a simple canary page - remember this when we produce the stories for the first epic! - Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed @@ -4319,11 +4319,11 @@ sections: repeatable: true instruction: | After the epic list is approved, present each epic with all its stories and acceptance criteria as a complete review unit. - + For each epic provide expanded goal (2-3 sentences describing the objective and value all the stories will achieve). - + CRITICAL STORY SEQUENCING REQUIREMENTS: - + - Stories within each epic MUST be logically sequential - Each story should be a "vertical slice" delivering complete functionality aside from early enabler stories for project foundation - No story should depend on work from a later story or epic @@ -4351,7 +4351,7 @@ sections: repeatable: true instruction: | Define clear, comprehensive, and testable acceptance criteria that: - + - Precisely define what "done" means from a functional perspective - Are unambiguous and serve as basis for verification - Include any critical non-functional requirements from the PRD @@ -4393,19 +4393,19 @@ sections: title: Intro Project Analysis and Context instruction: | IMPORTANT - SCOPE ASSESSMENT REQUIRED: - + This PRD is for SIGNIFICANT enhancements to existing projects that require comprehensive planning and multiple stories. Before proceeding: - + 1. **Assess Enhancement Complexity**: If this is a simple feature addition or bug fix that could be completed in 1-2 focused development sessions, STOP and recommend: "For simpler changes, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead. This full PRD process is designed for substantial enhancements that require architectural planning and multiple coordinated stories." - + 2. **Project Context**: Determine if we're working in an IDE with the project already loaded or if the user needs to provide project information. If project files are available, analyze existing documentation in the docs folder. If insufficient documentation exists, recommend running the document-project task first. - + 3. **Deep Assessment Requirement**: You MUST thoroughly analyze the existing project structure, patterns, and constraints before making ANY suggestions. Every recommendation must be grounded in actual project analysis, not assumptions. - + Gather comprehensive information about the existing project. This section must be completed before proceeding with requirements. - + CRITICAL: Throughout this analysis, explicitly confirm your understanding with the user. For every assumption you make about the existing project, ask: "Based on my analysis, I understand that [assumption]. Is this correct?" - + Do not proceed with any recommendations until the user has validated your understanding of the existing system. sections: - id: existing-project-overview @@ -4431,7 +4431,7 @@ sections: - Note: "Document-project analysis available - using existing technical documentation" - List key documents created by document-project - Skip the missing documentation check below - + Otherwise, check for existing documentation: sections: - id: available-docs @@ -4555,7 +4555,7 @@ sections: If document-project output available: - Extract from "Actual Tech Stack" table in High Level Architecture section - Include version numbers and any noted constraints - + Otherwise, document the current technology stack: template: | **Languages**: {{languages}} @@ -4594,7 +4594,7 @@ sections: - Reference "Technical Debt and Known Issues" section - Include "Workarounds and Gotchas" that might impact enhancement - Note any identified constraints from "Critical Technical Debt" - + Build risk assessment incorporating existing known issues: template: | **Technical Risks**: {{technical_risks}} @@ -4617,7 +4617,7 @@ sections: title: "Epic 1: {{enhancement_title}}" instruction: | Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality - + CRITICAL STORY SEQUENCING FOR BROWNFIELD: - Stories must ensure existing functionality remains intact - Each story should include verification that existing features still work @@ -4630,7 +4630,7 @@ sections: - Each story must deliver value while maintaining system integrity template: | **Epic Goal**: {{epic_goal}} - + **Integration Requirements**: {{integration_requirements}} sections: - id: story @@ -5249,20 +5249,20 @@ sections: - id: intro-content content: | This document outlines the overall project architecture for {{project_name}}, including backend systems, shared services, and non-UI specific concerns. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development, ensuring consistency and adherence to chosen patterns and technologies. - + **Relationship to Frontend Architecture:** If the project includes a significant user interface, a separate Frontend Architecture Document will detail the frontend-specific design and MUST be used in conjunction with this document. Core technology stack choices documented herein (see "Tech Stack") are definitive for the entire project, including any frontend components. - id: starter-template title: Starter Template or Existing Project instruction: | Before proceeding further with architecture design, check if the project is based on a starter template or existing codebase: - + 1. Review the PRD and brainstorming brief for any mentions of: - Starter templates (e.g., Create React App, Next.js, Vue CLI, Angular CLI, etc.) - Existing projects or codebases being used as a foundation - Boilerplate projects or scaffolding tools - Previous projects to be cloned or adapted - + 2. If a starter template or existing project is mentioned: - Ask the user to provide access via one of these methods: - Link to the starter template documentation @@ -5275,16 +5275,16 @@ sections: - Existing architectural patterns and conventions - Any limitations or constraints imposed by the starter - Use this analysis to inform and align your architecture decisions - + 3. If no starter template is mentioned but this is a greenfield project: - Suggest appropriate starter templates based on the tech stack preferences - Explain the benefits (faster setup, best practices, community support) - Let the user decide whether to use one - + 4. If the user confirms no starter template will be used: - Proceed with architecture design from scratch - Note that manual setup will be required for all tooling and configuration - + Document the decision here before proceeding with the architecture design. If none, just say N/A elicit: true - id: changelog @@ -5312,7 +5312,7 @@ sections: title: High Level Overview instruction: | Based on the PRD's Technical Assumptions section, describe: - + 1. The main architectural style (e.g., Monolith, Microservices, Serverless, Event-Driven) 2. Repository structure decision from PRD (Monorepo/Polyrepo) 3. Service architecture decision from PRD @@ -5329,17 +5329,17 @@ sections: - Data flow directions - External integrations - User entry points - + - id: architectural-patterns title: Architectural and Design Patterns instruction: | List the key high-level patterns that will guide the architecture. For each pattern: - + 1. Present 2-3 viable options if multiple exist 2. Provide your recommendation with clear rationale 3. Get user confirmation before finalizing 4. These patterns should align with the PRD's technical assumptions and project goals - + Common patterns to consider: - Architectural style patterns (Serverless, Event-Driven, Microservices, CQRS, Hexagonal) - Code organization patterns (Dependency Injection, Repository, Module, Factory) @@ -5355,23 +5355,23 @@ sections: title: Tech Stack instruction: | This is the DEFINITIVE technology selection section. Work with the user to make specific choices: - + 1. Review PRD technical assumptions and any preferences from .bmad-core/data/technical-preferences.yaml or an attached technical-preferences 2. For each category, present 2-3 viable options with pros/cons 3. Make a clear recommendation based on project needs 4. Get explicit user approval for each selection 5. Document exact versions (avoid "latest" - pin specific versions) 6. This table is the single source of truth - all other docs must reference these choices - + Key decisions to finalize - before displaying the table, ensure you are aware of or ask the user about - let the user know if they are not sure on any that you can also provide suggestions with rationale: - + - Starter templates (if any) - Languages and runtimes with exact versions - Frameworks and libraries / packages - Cloud provider and key services choices - Database and storage solutions - if unclear suggest sql or nosql or other types depending on the project and depending on cloud provider offer a suggestion - Development tools - + Upon render of the table, ensure the user is aware of the importance of this sections choices, should also look for gaps or disagreements with anything, ask for any clarifications if something is unclear why its in the list, and also right away elicit feedback - this statement and the options should be rendered and then prompt right all before allowing user input. elicit: true sections: @@ -5395,13 +5395,13 @@ sections: title: Data Models instruction: | Define the core data models/entities: - + 1. Review PRD requirements and identify key business entities 2. For each model, explain its purpose and relationships 3. Include key attributes and data types 4. Show relationships between models 5. Discuss design decisions with user - + Create a clear conceptual model before moving to database schema. elicit: true repeatable: true @@ -5410,11 +5410,11 @@ sections: title: "{{model_name}}" template: | **Purpose:** {{model_purpose}} - + **Key Attributes:** - {{attribute_1}}: {{type_1}} - {{description_1}} - {{attribute_2}}: {{type_2}} - {{description_2}} - + **Relationships:** - {{relationship_1}} - {{relationship_2}} @@ -5423,7 +5423,7 @@ sections: title: Components instruction: | Based on the architectural patterns, tech stack, and data models from above: - + 1. Identify major logical components/services and their responsibilities 2. Consider the repository structure (monorepo/polyrepo) from PRD 3. Define clear boundaries and interfaces between components @@ -5432,7 +5432,7 @@ sections: - Key interfaces/APIs exposed - Dependencies on other components - Technology specifics based on tech stack choices - + 5. Create component diagrams where helpful elicit: true sections: @@ -5441,13 +5441,13 @@ sections: title: "{{component_name}}" template: | **Responsibility:** {{component_description}} - + **Key Interfaces:** - {{interface_1}} - {{interface_2}} - + **Dependencies:** {{dependencies}} - + **Technology Stack:** {{component_tech_details}} - id: component-diagrams title: Component Diagrams @@ -5464,13 +5464,13 @@ sections: condition: Project requires external API integrations instruction: | For each external service integration: - + 1. Identify APIs needed based on PRD requirements and component design 2. If documentation URLs are unknown, ask user for specifics 3. Document authentication methods and security considerations 4. List specific endpoints that will be used 5. Note any rate limits or usage constraints - + If no external APIs are needed, state this explicitly and skip to next section. elicit: true repeatable: true @@ -5483,10 +5483,10 @@ sections: - **Base URL(s):** {{api_base_url}} - **Authentication:** {{auth_method}} - **Rate Limits:** {{rate_limits}} - + **Key Endpoints Used:** - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}} - + **Integration Notes:** {{integration_considerations}} - id: core-workflows @@ -5495,13 +5495,13 @@ sections: mermaid_type: sequence instruction: | Illustrate key system workflows using sequence diagrams: - + 1. Identify critical user journeys from PRD 2. Show component interactions including external APIs 3. Include error handling paths 4. Document async operations 5. Create both high-level and detailed diagrams as needed - + Focus on workflows that clarify architecture decisions or complex interactions. elicit: true @@ -5512,13 +5512,13 @@ sections: language: yaml instruction: | If the project includes a REST API: - + 1. Create an OpenAPI 3.0 specification 2. Include all endpoints from epics/stories 3. Define request/response schemas based on data models 4. Document authentication requirements 5. Include example requests/responses - + Use YAML format for better readability. If no REST API, skip this section. elicit: true template: | @@ -5535,13 +5535,13 @@ sections: title: Database Schema instruction: | Transform the conceptual data models into concrete database schemas: - + 1. Use the database type(s) selected in Tech Stack 2. Create schema definitions using appropriate notation 3. Include indexes, constraints, and relationships 4. Consider performance and scalability 5. For NoSQL, show document structures - + Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.) elicit: true @@ -5551,14 +5551,14 @@ sections: language: plaintext instruction: | Create a project folder structure that reflects: - + 1. The chosen repository structure (monorepo/polyrepo) 2. The service architecture (monolith/microservices/serverless) 3. The selected tech stack and languages 4. Component organization from above 5. Best practices for the chosen frameworks 6. Clear separation of concerns - + Adapt the structure based on project needs. For monorepos, show service separation. For serverless, show function organization. Include language-specific conventions. elicit: true examples: @@ -5576,13 +5576,13 @@ sections: title: Infrastructure and Deployment instruction: | Define the deployment architecture and practices: - + 1. Use IaC tool selected in Tech Stack 2. Choose deployment strategy appropriate for the architecture 3. Define environments and promotion flow 4. Establish rollback procedures 5. Consider security, monitoring, and cost optimization - + Get user input on deployment preferences and CI/CD tool choices. elicit: true sections: @@ -5618,13 +5618,13 @@ sections: title: Error Handling Strategy instruction: | Define comprehensive error handling approach: - + 1. Choose appropriate patterns for the language/framework from Tech Stack 2. Define logging standards and tools 3. Establish error categories and handling rules 4. Consider observability and debugging needs 5. Ensure security (no sensitive data in logs) - + This section guides both AI and human developers in consistent error handling. elicit: true sections: @@ -5671,13 +5671,13 @@ sections: title: Coding Standards instruction: | These standards are MANDATORY for AI agents. Work with user to define ONLY the critical rules needed to prevent bad code. Explain that: - + 1. This section directly controls AI developer behavior 2. Keep it minimal - assume AI knows general best practices 3. Focus on project-specific conventions and gotchas 4. Overly detailed standards bloat context and slow development 5. Standards will be extracted to separate file for dev agent use - + For each standard, get explicit user confirmation it's necessary. elicit: true sections: @@ -5699,7 +5699,7 @@ sections: - "Never use console.log in production code - use logger" - "All API responses must use ApiResponse wrapper type" - "Database queries must use repository pattern, never direct ORM" - + Avoid obvious rules like "use SOLID principles" or "write clean code" repeatable: true template: "- **{{rule_name}}:** {{rule_description}}" @@ -5717,14 +5717,14 @@ sections: title: Test Strategy and Standards instruction: | Work with user to define comprehensive test strategy: - + 1. Use test frameworks from Tech Stack 2. Decide on TDD vs test-after approach 3. Define test organization and naming 4. Establish coverage goals 5. Determine integration test infrastructure 6. Plan for test data and external dependencies - + Note: Basic info goes in Coding Standards for dev agent. This detailed section is for QA agent and team reference. elicit: true sections: @@ -5745,7 +5745,7 @@ sections: - **Location:** {{unit_test_location}} - **Mocking Library:** {{mocking_library}} - **Coverage Requirement:** {{unit_coverage}} - + **AI Agent Requirements:** - Generate tests for all public methods - Cover edge cases and error conditions @@ -5787,7 +5787,7 @@ sections: title: Security instruction: | Define MANDATORY security requirements for AI and human developers: - + 1. Focus on implementation-specific rules 2. Reference security tools from Tech Stack 3. Define clear patterns for common scenarios @@ -5856,16 +5856,16 @@ sections: title: Next Steps instruction: | After completing the architecture: - + 1. If project has UI components: - Use "Frontend Architecture Mode" - Provide this document as input - + 2. For all projects: - Review with Product Owner - Begin story implementation with Dev agent - Set up infrastructure with DevOps agent - + 3. Include specific prompts for next agents if needed sections: - id: architect-prompt @@ -5898,16 +5898,16 @@ sections: title: Template and Framework Selection instruction: | Review provided documents including PRD, UX-UI Specification, and main Architecture Document. Focus on extracting technical implementation details needed for AI frontend tools and developer agents. Ask the user for any of these documents if you are unable to locate and were not provided. - + Before proceeding with frontend architecture design, check if the project is using a frontend starter template or existing codebase: - + 1. Review the PRD, main architecture document, and brainstorming brief for mentions of: - Frontend starter templates (e.g., Create React App, Next.js, Vite, Vue CLI, Angular CLI, etc.) - UI kit or component library starters - Existing frontend projects being used as a foundation - Admin dashboard templates or other specialized starters - Design system implementations - + 2. If a frontend starter template or existing project is mentioned: - Ask the user to provide access via one of these methods: - Link to the starter template documentation @@ -5923,7 +5923,7 @@ sections: - Testing setup and patterns - Build and development scripts - Use this analysis to ensure your frontend architecture aligns with the starter's patterns - + 3. If no frontend starter is mentioned but this is a new UI, ensure we know what the ui language and framework is: - Based on the framework choice, suggest appropriate starters: - React: Create React App, Next.js, Vite + React @@ -5931,11 +5931,11 @@ sections: - Angular: Angular CLI - Or suggest popular UI templates if applicable - Explain benefits specific to frontend development - + 4. If the user confirms no starter template will be used: - Note that all tooling, bundling, and configuration will need manual setup - Proceed with frontend architecture from scratch - + Document the starter template decision and any constraints it imposes before proceeding. sections: - id: changelog @@ -6110,33 +6110,33 @@ sections: elicit: true content: | This document outlines the complete fullstack architecture for {{project_name}}, including backend systems, frontend implementation, and their integration. It serves as the single source of truth for AI-driven development, ensuring consistency across the entire technology stack. - + This unified approach combines what would traditionally be separate backend and frontend architecture documents, streamlining the development process for modern fullstack applications where these concerns are increasingly intertwined. sections: - id: starter-template title: Starter Template or Existing Project instruction: | Before proceeding with architecture design, check if the project is based on any starter templates or existing codebases: - + 1. Review the PRD and other documents for mentions of: - Fullstack starter templates (e.g., T3 Stack, MEAN/MERN starters, Django + React templates) - Monorepo templates (e.g., Nx, Turborepo starters) - Platform-specific starters (e.g., Vercel templates, AWS Amplify starters) - Existing projects being extended or cloned - + 2. If starter templates or existing projects are mentioned: - Ask the user to provide access (links, repos, or files) - Analyze to understand pre-configured choices and constraints - Note any architectural decisions already made - Identify what can be modified vs what must be retained - + 3. If no starter is mentioned but this is greenfield: - Suggest appropriate fullstack starters based on tech preferences - Consider platform-specific options (Vercel, AWS, etc.) - Let user decide whether to use one - + 4. Document the decision and any constraints it imposes - + If none, state "N/A - Greenfield project" - id: changelog title: Change Log @@ -6162,17 +6162,17 @@ sections: title: Platform and Infrastructure Choice instruction: | Based on PRD requirements and technical assumptions, make a platform recommendation: - + 1. Consider common patterns (not an exhaustive list, use your own best judgement and search the web as needed for emerging trends): - **Vercel + Supabase**: For rapid development with Next.js, built-in auth/storage - **AWS Full Stack**: For enterprise scale with Lambda, API Gateway, S3, Cognito - **Azure**: For .NET ecosystems or enterprise Microsoft environments - **Google Cloud**: For ML/AI heavy applications or Google ecosystem integration - + 2. Present 2-3 viable options with clear pros/cons 3. Make a recommendation with rationale 4. Get explicit user confirmation - + Document the choice and key services that will be used. template: | **Platform:** {{selected_platform}} @@ -6182,7 +6182,7 @@ sections: title: Repository Structure instruction: | Define the repository approach based on PRD requirements and platform choice, explain your rationale or ask questions to the user if unsure: - + 1. For modern fullstack apps, monorepo is often preferred 2. Consider tooling (Nx, Turborepo, Lerna, npm workspaces) 3. Define package/app boundaries @@ -6204,7 +6204,7 @@ sections: - Databases and storage - External integrations - CDN and caching layers - + Use appropriate diagram type for clarity. - id: architectural-patterns title: Architectural Patterns @@ -6214,7 +6214,7 @@ sections: - Frontend patterns (e.g., Component-based, State management) - Backend patterns (e.g., Repository, CQRS, Event-driven) - Integration patterns (e.g., BFF, API Gateway) - + For each pattern, provide recommendation and rationale. repeatable: true template: "- **{{pattern_name}}:** {{pattern_description}} - _Rationale:_ {{rationale}}" @@ -6228,7 +6228,7 @@ sections: title: Tech Stack instruction: | This is the DEFINITIVE technology selection for the entire project. Work with user to finalize all choices. This table is the single source of truth - all development must use these exact versions. - + Key areas to cover: - Frontend and backend languages/frameworks - Databases and caching @@ -6237,7 +6237,7 @@ sections: - Testing tools for both frontend and backend - Build and deployment tools - Monitoring and logging - + Upon render, elicit feedback immediately. elicit: true sections: @@ -6272,14 +6272,14 @@ sections: title: Data Models instruction: | Define the core data models/entities that will be shared between frontend and backend: - + 1. Review PRD requirements and identify key business entities 2. For each model, explain its purpose and relationships 3. Include key attributes and data types 4. Show relationships between models 5. Create TypeScript interfaces that can be shared 6. Discuss design decisions with user - + Create a clear conceptual model before moving to database schema. elicit: true repeatable: true @@ -6288,7 +6288,7 @@ sections: title: "{{model_name}}" template: | **Purpose:** {{model_purpose}} - + **Key Attributes:** - {{attribute_1}}: {{type_1}} - {{description_1}} - {{attribute_2}}: {{type_2}} - {{description_2}} @@ -6307,7 +6307,7 @@ sections: title: API Specification instruction: | Based on the chosen API style from Tech Stack: - + 1. If REST API, create an OpenAPI 3.0 specification 2. If GraphQL, provide the GraphQL schema 3. If tRPC, show router definitions @@ -6315,7 +6315,7 @@ sections: 5. Define request/response schemas based on data models 6. Document authentication requirements 7. Include example requests/responses - + Use appropriate format for the chosen API style. If no API (e.g., static site), skip this section. elicit: true sections: @@ -6350,7 +6350,7 @@ sections: title: Components instruction: | Based on the architectural patterns, tech stack, and data models from above: - + 1. Identify major logical components/services across the fullstack 2. Consider both frontend and backend components 3. Define clear boundaries and interfaces between components @@ -6359,7 +6359,7 @@ sections: - Key interfaces/APIs exposed - Dependencies on other components - Technology specifics based on tech stack choices - + 5. Create component diagrams where helpful elicit: true sections: @@ -6368,13 +6368,13 @@ sections: title: "{{component_name}}" template: | **Responsibility:** {{component_description}} - + **Key Interfaces:** - {{interface_1}} - {{interface_2}} - + **Dependencies:** {{dependencies}} - + **Technology Stack:** {{component_tech_details}} - id: component-diagrams title: Component Diagrams @@ -6391,13 +6391,13 @@ sections: condition: Project requires external API integrations instruction: | For each external service integration: - + 1. Identify APIs needed based on PRD requirements and component design 2. If documentation URLs are unknown, ask user for specifics 3. Document authentication methods and security considerations 4. List specific endpoints that will be used 5. Note any rate limits or usage constraints - + If no external APIs are needed, state this explicitly and skip to next section. elicit: true repeatable: true @@ -6410,10 +6410,10 @@ sections: - **Base URL(s):** {{api_base_url}} - **Authentication:** {{auth_method}} - **Rate Limits:** {{rate_limits}} - + **Key Endpoints Used:** - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}} - + **Integration Notes:** {{integration_considerations}} - id: core-workflows @@ -6422,14 +6422,14 @@ sections: mermaid_type: sequence instruction: | Illustrate key system workflows using sequence diagrams: - + 1. Identify critical user journeys from PRD 2. Show component interactions including external APIs 3. Include both frontend and backend flows 4. Include error handling paths 5. Document async operations 6. Create both high-level and detailed diagrams as needed - + Focus on workflows that clarify architecture decisions or complex interactions. elicit: true @@ -6437,13 +6437,13 @@ sections: title: Database Schema instruction: | Transform the conceptual data models into concrete database schemas: - + 1. Use the database type(s) selected in Tech Stack 2. Create schema definitions using appropriate notation 3. Include indexes, constraints, and relationships 4. Consider performance and scalability 5. For NoSQL, show document structures - + Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.) elicit: true @@ -6659,13 +6659,13 @@ sections: template: | # Start all services {{start_all_command}} - + # Start frontend only {{start_frontend_command}} - + # Start backend only {{start_backend_command}} - + # Run tests {{test_commands}} - id: environment-config @@ -6678,10 +6678,10 @@ sections: template: | # Frontend (.env.local) {{frontend_env_vars}} - + # Backend (.env) {{backend_env_vars}} - + # Shared {{shared_env_vars}} @@ -6698,7 +6698,7 @@ sections: - **Build Command:** {{frontend_build_command}} - **Output Directory:** {{frontend_output_dir}} - **CDN/Edge:** {{cdn_strategy}} - + **Backend Deployment:** - **Platform:** {{backend_deploy_platform}} - **Build Command:** {{backend_build_command}} @@ -6729,12 +6729,12 @@ sections: - CSP Headers: {{csp_policy}} - XSS Prevention: {{xss_strategy}} - Secure Storage: {{storage_strategy}} - + **Backend Security:** - Input Validation: {{validation_approach}} - Rate Limiting: {{rate_limit_config}} - CORS Policy: {{cors_config}} - + **Authentication Security:** - Token Storage: {{token_strategy}} - Session Management: {{session_approach}} @@ -6746,7 +6746,7 @@ sections: - Bundle Size Target: {{bundle_size}} - Loading Strategy: {{loading_approach}} - Caching Strategy: {{fe_cache_strategy}} - + **Backend Performance:** - Response Time Target: {{response_target}} - Database Optimization: {{db_optimization}} @@ -6884,7 +6884,7 @@ sections: - JavaScript errors - API response times - User interactions - + **Backend Metrics:** - Request rate - Error rate @@ -6915,40 +6915,40 @@ sections: title: Introduction instruction: | IMPORTANT - SCOPE AND ASSESSMENT REQUIRED: - + This architecture document is for SIGNIFICANT enhancements to existing projects that require comprehensive architectural planning. Before proceeding: - + 1. **Verify Complexity**: Confirm this enhancement requires architectural planning. For simple additions, recommend: "For simpler changes that don't require architectural planning, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead." - + 2. **REQUIRED INPUTS**: - Completed brownfield-prd.md - Existing project technical documentation (from docs folder or user-provided) - Access to existing project structure (IDE or uploaded files) - + 3. **DEEP ANALYSIS MANDATE**: You MUST conduct thorough analysis of the existing codebase, architecture patterns, and technical constraints before making ANY architectural recommendations. Every suggestion must be based on actual project analysis, not assumptions. - + 4. **CONTINUOUS VALIDATION**: Throughout this process, explicitly validate your understanding with the user. For every architectural decision, confirm: "Based on my analysis of your existing system, I recommend [decision] because [evidence from actual project]. Does this align with your system's reality?" - + If any required inputs are missing, request them before proceeding. elicit: true sections: - id: intro-content content: | This document outlines the architectural approach for enhancing {{project_name}} with {{enhancement_description}}. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development of new features while ensuring seamless integration with the existing system. - + **Relationship to Existing Architecture:** This document supplements existing project architecture by defining how new components will integrate with current systems. Where conflicts arise between new and existing patterns, this document provides guidance on maintaining consistency while implementing enhancements. - id: existing-project-analysis title: Existing Project Analysis instruction: | Analyze the existing project structure and architecture: - + 1. Review existing documentation in docs folder 2. Examine current technology stack and versions 3. Identify existing architectural patterns and conventions 4. Note current deployment and infrastructure setup 5. Document any constraints or limitations - + CRITICAL: After your analysis, explicitly validate your findings: "Based on my analysis of your project, I've identified the following about your existing system: [key findings]. Please confirm these observations are accurate before I proceed with architectural recommendations." elicit: true sections: @@ -6977,12 +6977,12 @@ sections: title: Enhancement Scope and Integration Strategy instruction: | Define how the enhancement will integrate with the existing system: - + 1. Review the brownfield PRD enhancement scope 2. Identify integration points with existing code 3. Define boundaries between new and existing functionality 4. Establish compatibility requirements - + VALIDATION CHECKPOINT: Before presenting the integration strategy, confirm: "Based on my analysis, the integration approach I'm proposing takes into account [specific existing system characteristics]. These integration points and boundaries respect your current architecture patterns. Is this assessment accurate?" elicit: true sections: @@ -7011,7 +7011,7 @@ sections: title: Tech Stack Alignment instruction: | Ensure new components align with existing technology choices: - + 1. Use existing technology stack as the foundation 2. Only introduce new technologies if absolutely necessary 3. Justify any new additions with clear rationale @@ -7034,7 +7034,7 @@ sections: title: Data Models and Schema Changes instruction: | Define new data models and how they integrate with existing schema: - + 1. Identify new entities required for the enhancement 2. Define relationships with existing data models 3. Plan database schema changes (additions, modifications) @@ -7050,11 +7050,11 @@ sections: template: | **Purpose:** {{model_purpose}} **Integration:** {{integration_with_existing}} - + **Key Attributes:** - {{attribute_1}}: {{type_1}} - {{description_1}} - {{attribute_2}}: {{type_2}} - {{description_2}} - + **Relationships:** - **With Existing:** {{existing_relationships}} - **With New:** {{new_relationships}} @@ -7066,7 +7066,7 @@ sections: - **Modified Tables:** {{modified_tables_list}} - **New Indexes:** {{new_indexes_list}} - **Migration Strategy:** {{migration_approach}} - + **Backward Compatibility:** - {{compatibility_measure_1}} - {{compatibility_measure_2}} @@ -7075,12 +7075,12 @@ sections: title: Component Architecture instruction: | Define new components and their integration with existing architecture: - + 1. Identify new components required for the enhancement 2. Define interfaces with existing components 3. Establish clear boundaries and responsibilities 4. Plan integration points and data flow - + MANDATORY VALIDATION: Before presenting component architecture, confirm: "The new components I'm proposing follow the existing architectural patterns I identified in your codebase: [specific patterns]. The integration interfaces respect your current component structure and communication patterns. Does this match your project's reality?" elicit: true sections: @@ -7093,15 +7093,15 @@ sections: template: | **Responsibility:** {{component_description}} **Integration Points:** {{integration_points}} - + **Key Interfaces:** - {{interface_1}} - {{interface_2}} - + **Dependencies:** - **Existing Components:** {{existing_dependencies}} - **New Components:** {{new_dependencies}} - + **Technology Stack:** {{component_tech_details}} - id: interaction-diagram title: Component Interaction Diagram @@ -7114,7 +7114,7 @@ sections: condition: Enhancement requires API changes instruction: | Define new API endpoints and integration with existing APIs: - + 1. Plan new API endpoints required for the enhancement 2. Ensure consistency with existing API patterns 3. Define authentication and authorization integration @@ -7164,17 +7164,17 @@ sections: - **Base URL:** {{api_base_url}} - **Authentication:** {{auth_method}} - **Integration Method:** {{integration_approach}} - + **Key Endpoints Used:** - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}} - + **Error Handling:** {{error_handling_strategy}} - id: source-tree-integration title: Source Tree Integration instruction: | Define how new code will integrate with existing project structure: - + 1. Follow existing project organization patterns 2. Identify where new files/folders will be placed 3. Ensure consistency with existing naming conventions @@ -7213,7 +7213,7 @@ sections: title: Infrastructure and Deployment Integration instruction: | Define how the enhancement will be deployed alongside existing infrastructure: - + 1. Use existing deployment pipeline and infrastructure 2. Identify any infrastructure changes needed 3. Plan deployment strategy to minimize risk @@ -7243,7 +7243,7 @@ sections: title: Coding Standards and Conventions instruction: | Ensure new code follows existing project conventions: - + 1. Document existing coding standards from project analysis 2. Identify any enhancement-specific requirements 3. Ensure consistency with existing codebase patterns @@ -7274,7 +7274,7 @@ sections: title: Testing Strategy instruction: | Define testing approach for the enhancement: - + 1. Integrate with existing test suite 2. Ensure existing functionality remains intact 3. Plan for testing new features @@ -7314,7 +7314,7 @@ sections: title: Security Integration instruction: | Ensure security consistency with existing system: - + 1. Follow existing security patterns and tools 2. Ensure new features don't introduce vulnerabilities 3. Maintain existing security posture @@ -7349,7 +7349,7 @@ sections: title: Next Steps instruction: | After completing the brownfield architecture: - + 1. Review integration points with existing system 2. Begin story implementation with Dev agent 3. Set up deployment pipeline integration @@ -7973,7 +7973,7 @@ workflow: elicitation: advanced-elicitation agent_config: - editable_sections: + editable_sections: - Status - Story - Acceptance Criteria @@ -7990,7 +7990,7 @@ sections: instruction: Select the current status of the story owner: scrum-master editors: [scrum-master, dev-agent] - + - id: story title: Story type: template-text @@ -8002,7 +8002,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: acceptance-criteria title: Acceptance Criteria type: numbered-list @@ -8010,7 +8010,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: tasks-subtasks title: Tasks / Subtasks type: bullet-list @@ -8027,7 +8027,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master, dev-agent] - + - id: dev-notes title: Dev Notes instruction: | @@ -8051,7 +8051,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: change-log title: Change Log type: table @@ -8059,7 +8059,7 @@ sections: instruction: Track changes made to this story document owner: scrum-master editors: [scrum-master, dev-agent, qa-agent] - + - id: dev-agent-record title: Dev Agent Record instruction: This section is populated by the development agent during implementation @@ -8072,25 +8072,25 @@ sections: instruction: Record the specific AI agent model and version used for development owner: dev-agent editors: [dev-agent] - + - id: debug-log-references title: Debug Log References instruction: Reference any debug logs or traces generated during development owner: dev-agent editors: [dev-agent] - + - id: completion-notes title: Completion Notes List instruction: Notes about the completion of tasks and any issues encountered owner: dev-agent editors: [dev-agent] - + - id: file-list title: File List instruction: List all files created, modified, or affected during story implementation owner: dev-agent editors: [dev-agent] - + - id: qa-results title: QA Results instruction: Results from QA Agent QA review of the completed story implementation @@ -8680,7 +8680,7 @@ workflow: notes: | All stories implemented and reviewed! Service development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -8697,7 +8697,7 @@ workflow: H -->|Yes| I[Return to relevant agent for fixes] H -->|No| J[po: shard documents] I --> G - + J --> K[sm: create story] K --> L{Review draft story?} L -->|Yes| M[analyst/pm: review & approve story] @@ -8881,7 +8881,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -8895,7 +8895,7 @@ workflow: F -->|Yes| G[Return to relevant agent for fixes] F -->|No| H[po: shard documents] G --> E - + H --> I[sm: create story] I --> J{Review draft story?} J -->|Yes| K[analyst/pm: review & approve story]