From 62cee232c48f9d84a355e891dd3d36c99dca6357 Mon Sep 17 00:00:00 2001 From: minhtrungcc Date: Sun, 7 Sep 2025 13:25:16 +0700 Subject: [PATCH] feat: add hierarchical section indices to all template files MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Added numbered indices to section headings across all template files for better document structure and navigation - Main sections use single numbers (1., 2., 3.) - Subsections use decimal notation (1.1., 1.2., 2.1.) - Sub-subsections use triple decimal notation (1.1.1., 1.1.2.) - Updated templates: architecture, fullstack-architecture, prd, front-end-architecture, brownfield-architecture, brownfield-prd 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude --- bmad-core/templates/architecture-tmpl.yaml | 112 ++++++------ .../brownfield-architecture-tmpl.yaml | 110 ++++++------ bmad-core/templates/brownfield-prd-tmpl.yaml | 68 +++---- .../front-end-architecture-tmpl.yaml | 52 +++--- .../fullstack-architecture-tmpl.yaml | 166 +++++++++--------- bmad-core/templates/prd-tmpl.yaml | 54 +++--- 6 files changed, 281 insertions(+), 281 deletions(-) diff --git a/bmad-core/templates/architecture-tmpl.yaml b/bmad-core/templates/architecture-tmpl.yaml index f5d508aa..8cc3f429 100644 --- a/bmad-core/templates/architecture-tmpl.yaml +++ b/bmad-core/templates/architecture-tmpl.yaml @@ -14,7 +14,7 @@ workflow: sections: - id: introduction - title: Introduction + title: 1. Introduction instruction: | If available, review any provided relevant documents to gather all relevant context before beginning. If at a minimum you cannot locate docs/prd.md ask the user what docs will provide the basis for the architecture. sections: @@ -25,7 +25,7 @@ sections: **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 + title: 1.1. 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: @@ -60,19 +60,19 @@ sections: Document the decision here before proceeding with the architecture design. If none, just say N/A elicit: true - id: changelog - title: Change Log + title: 1.2. Change Log type: table columns: [Date, Version, Description, Author] instruction: Track document versions and changes - id: high-level-architecture - title: High Level Architecture + title: 2. High Level Architecture instruction: | This section contains multiple subsections that establish the foundation of the architecture. Present all subsections together at once. elicit: true sections: - id: technical-summary - title: Technical Summary + title: 2.1. Technical Summary instruction: | Provide a brief paragraph (3-5 sentences) overview of: - The system's overall architecture style @@ -81,7 +81,7 @@ sections: - Core architectural patterns being used - Reference back to the PRD goals and how this architecture supports them - id: high-level-overview - title: High Level Overview + title: 2.2. High Level Overview instruction: | Based on the PRD's Technical Assumptions section, describe: @@ -91,7 +91,7 @@ sections: 4. Primary user interaction flow or data flow at a conceptual level 5. Key architectural decisions and their rationale - id: project-diagram - title: High Level Project Diagram + title: 2.3. High Level Project Diagram type: mermaid mermaid_type: graph instruction: | @@ -103,7 +103,7 @@ sections: - User entry points - id: architectural-patterns - title: Architectural and Design Patterns + title: 2.4. Architectural and Design Patterns instruction: | List the key high-level patterns that will guide the architecture. For each pattern: @@ -124,7 +124,7 @@ sections: - "**Event-Driven Communication:** Using SNS/SQS for service decoupling - _Rationale:_ Supports async processing and system resilience" - id: tech-stack - title: Tech Stack + title: 3. Tech Stack instruction: | This is the DEFINITIVE technology selection section. Work with the user to make specific choices: @@ -148,13 +148,13 @@ sections: elicit: true sections: - id: cloud-infrastructure - title: Cloud Infrastructure + title: 3.1. Cloud Infrastructure template: | - **Provider:** {{cloud_provider}} - **Key Services:** {{core_services_list}} - **Deployment Regions:** {{regions}} - id: technology-stack-table - title: Technology Stack Table + title: 3.2. Technology Stack Table type: table columns: [Category, Technology, Version, Purpose, Rationale] instruction: Populate the technology stack table with all relevant technologies @@ -164,7 +164,7 @@ sections: - "| **Framework** | NestJS | 10.3.2 | Backend framework | Enterprise-ready, good DI, matches team patterns |" - id: data-models - title: Data Models + title: 4. Data Models instruction: | Define the core data models/entities: @@ -192,7 +192,7 @@ sections: - {{relationship_2}} - id: components - title: Components + title: 5. Components instruction: | Based on the architectural patterns, tech stack, and data models from above: @@ -222,7 +222,7 @@ sections: **Technology Stack:** {{component_tech_details}} - id: component-diagrams - title: Component Diagrams + title: 5.1. Component Diagrams type: mermaid instruction: | Create Mermaid diagrams to visualize component relationships. Options: @@ -232,7 +232,7 @@ sections: Choose the most appropriate for clarity - id: external-apis - title: External APIs + title: 6. External APIs condition: Project requires external API integrations instruction: | For each external service integration: @@ -262,7 +262,7 @@ sections: **Integration Notes:** {{integration_considerations}} - id: core-workflows - title: Core Workflows + title: 7. Core Workflows type: mermaid mermaid_type: sequence instruction: | @@ -278,7 +278,7 @@ sections: elicit: true - id: rest-api-spec - title: REST API Spec + title: 8. REST API Spec condition: Project includes REST API type: code language: yaml @@ -304,7 +304,7 @@ sections: description: {{server_description}} - id: database-schema - title: Database Schema + title: 9. Database Schema instruction: | Transform the conceptual data models into concrete database schemas: @@ -318,7 +318,7 @@ sections: elicit: true - id: source-tree - title: Source Tree + title: 10. Source Tree type: code language: plaintext instruction: | @@ -345,7 +345,7 @@ sections: └── package.json # Root package.json with workspaces - id: infrastructure-deployment - title: Infrastructure and Deployment + title: 11. Infrastructure and Deployment instruction: | Define the deployment architecture and practices: @@ -359,35 +359,35 @@ sections: elicit: true sections: - id: infrastructure-as-code - title: Infrastructure as Code + title: 11.1. Infrastructure as Code template: | - **Tool:** {{iac_tool}} {{version}} - **Location:** `{{iac_directory}}` - **Approach:** {{iac_approach}} - id: deployment-strategy - title: Deployment Strategy + title: 11.2. Deployment Strategy template: | - **Strategy:** {{deployment_strategy}} - **CI/CD Platform:** {{cicd_platform}} - **Pipeline Configuration:** `{{pipeline_config_location}}` - id: environments - title: Environments + title: 11.3. Environments repeatable: true template: "- **{{env_name}}:** {{env_purpose}} - {{env_details}}" - id: promotion-flow - title: Environment Promotion Flow + title: 11.4. Environment Promotion Flow type: code language: text template: "{{promotion_flow_diagram}}" - id: rollback-strategy - title: Rollback Strategy + title: 11.5. Rollback Strategy template: | - **Primary Method:** {{rollback_method}} - **Trigger Conditions:** {{rollback_triggers}} - **Recovery Time Objective:** {{rto}} - id: error-handling-strategy - title: Error Handling Strategy + title: 12. Error Handling Strategy instruction: | Define comprehensive error handling approach: @@ -401,13 +401,13 @@ sections: elicit: true sections: - id: general-approach - title: General Approach + title: 12.1. General Approach template: | - **Error Model:** {{error_model}} - **Exception Hierarchy:** {{exception_structure}} - **Error Propagation:** {{propagation_rules}} - id: logging-standards - title: Logging Standards + title: 12.2. Logging Standards template: | - **Library:** {{logging_library}} {{version}} - **Format:** {{log_format}} @@ -417,30 +417,30 @@ sections: - Service Context: {{service_context}} - User Context: {{user_context_rules}} - id: error-patterns - title: Error Handling Patterns + title: 12.3. Error Handling Patterns sections: - id: external-api-errors - title: External API Errors + title: 12.3.1. External API Errors template: | - **Retry Policy:** {{retry_strategy}} - **Circuit Breaker:** {{circuit_breaker_config}} - **Timeout Configuration:** {{timeout_settings}} - **Error Translation:** {{error_mapping_rules}} - id: business-logic-errors - title: Business Logic Errors + title: 12.3.2. Business Logic Errors template: | - **Custom Exceptions:** {{business_exception_types}} - **User-Facing Errors:** {{user_error_format}} - **Error Codes:** {{error_code_system}} - id: data-consistency - title: Data Consistency + title: 12.3.3. Data Consistency template: | - **Transaction Strategy:** {{transaction_approach}} - **Compensation Logic:** {{compensation_patterns}} - **Idempotency:** {{idempotency_approach}} - id: coding-standards - title: Coding Standards + title: 13. 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: @@ -454,18 +454,18 @@ sections: elicit: true sections: - id: core-standards - title: Core Standards + title: 13.1. Core Standards template: | - **Languages & Runtimes:** {{languages_and_versions}} - **Style & Linting:** {{linter_config}} - **Test Organization:** {{test_file_convention}} - id: naming-conventions - title: Naming Conventions + title: 13.2. Naming Conventions type: table columns: [Element, Convention, Example] instruction: Only include if deviating from language defaults - id: critical-rules - title: Critical Rules + title: 13.3. Critical Rules instruction: | List ONLY rules that AI might violate or project-specific requirements. Examples: - "Never use console.log in production code - use logger" @@ -476,7 +476,7 @@ sections: repeatable: true template: "- **{{rule_name}}:** {{rule_description}}" - id: language-specifics - title: Language-Specific Guidelines + title: 13.4. Language-Specific Guidelines condition: Critical language-specific rules needed instruction: Add ONLY if critical for preventing AI mistakes. Most teams don't need this section. sections: @@ -486,7 +486,7 @@ sections: template: "- **{{rule_topic}}:** {{rule_detail}}" - id: test-strategy - title: Test Strategy and Standards + title: 14. Test Strategy and Standards instruction: | Work with user to define comprehensive test strategy: @@ -501,16 +501,16 @@ sections: elicit: true sections: - id: testing-philosophy - title: Testing Philosophy + title: 14.1. Testing Philosophy template: | - **Approach:** {{test_approach}} - **Coverage Goals:** {{coverage_targets}} - **Test Pyramid:** {{test_distribution}} - id: test-types - title: Test Types and Organization + title: 14.2. Test Types and Organization sections: - id: unit-tests - title: Unit Tests + title: 14.2.1. Unit Tests template: | - **Framework:** {{unit_test_framework}} {{version}} - **File Convention:** {{unit_test_naming}} @@ -524,7 +524,7 @@ sections: - Follow AAA pattern (Arrange, Act, Assert) - Mock all external dependencies - id: integration-tests - title: Integration Tests + title: 14.2.2. Integration Tests template: | - **Scope:** {{integration_scope}} - **Location:** {{integration_test_location}} @@ -535,28 +535,28 @@ sections: - "**Message Queue:** Embedded Kafka for tests" - "**External APIs:** WireMock for stubbing" - id: e2e-tests - title: End-to-End Tests + title: 14.2.3. End-to-End Tests template: | - **Framework:** {{e2e_framework}} {{version}} - **Scope:** {{e2e_scope}} - **Environment:** {{e2e_environment}} - **Test Data:** {{e2e_data_strategy}} - id: test-data-management - title: Test Data Management + title: 14.3. Test Data Management template: | - **Strategy:** {{test_data_approach}} - **Fixtures:** {{fixture_location}} - **Factories:** {{factory_pattern}} - **Cleanup:** {{cleanup_strategy}} - id: continuous-testing - title: Continuous Testing + title: 14.4. Continuous Testing template: | - **CI Integration:** {{ci_test_stages}} - **Performance Tests:** {{perf_test_approach}} - **Security Tests:** {{security_test_approach}} - id: security - title: Security + title: 15. Security instruction: | Define MANDATORY security requirements for AI and human developers: @@ -568,7 +568,7 @@ sections: elicit: true sections: - id: input-validation - title: Input Validation + title: 15.1. Input Validation template: | - **Validation Library:** {{validation_library}} - **Validation Location:** {{where_to_validate}} @@ -577,7 +577,7 @@ sections: - Validation at API boundary before processing - Whitelist approach preferred over blacklist - id: auth-authorization - title: Authentication & Authorization + title: 15.2. Authentication & Authorization template: | - **Auth Method:** {{auth_implementation}} - **Session Management:** {{session_approach}} @@ -585,7 +585,7 @@ sections: - {{auth_pattern_1}} - {{auth_pattern_2}} - id: secrets-management - title: Secrets Management + title: 15.3. Secrets Management template: | - **Development:** {{dev_secrets_approach}} - **Production:** {{prod_secrets_service}} @@ -594,38 +594,38 @@ sections: - Access via configuration service only - No secrets in logs or error messages - id: api-security - title: API Security + title: 15.4. API Security template: | - **Rate Limiting:** {{rate_limit_implementation}} - **CORS Policy:** {{cors_configuration}} - **Security Headers:** {{required_headers}} - **HTTPS Enforcement:** {{https_approach}} - id: data-protection - title: Data Protection + title: 15.5. Data Protection template: | - **Encryption at Rest:** {{encryption_at_rest}} - **Encryption in Transit:** {{encryption_in_transit}} - **PII Handling:** {{pii_rules}} - **Logging Restrictions:** {{what_not_to_log}} - id: dependency-security - title: Dependency Security + title: 15.6. Dependency Security template: | - **Scanning Tool:** {{dependency_scanner}} - **Update Policy:** {{update_frequency}} - **Approval Process:** {{new_dep_process}} - id: security-testing - title: Security Testing + title: 15.7. Security Testing template: | - **SAST Tool:** {{static_analysis}} - **DAST Tool:** {{dynamic_analysis}} - **Penetration Testing:** {{pentest_schedule}} - id: checklist-results - title: Checklist Results Report + title: 16. Checklist Results Report instruction: Before running the checklist, offer to output the full architecture document. Once user confirms, execute the architect-checklist and populate results here. - id: next-steps - title: Next Steps + title: 17. Next Steps instruction: | After completing the architecture: @@ -641,7 +641,7 @@ sections: 3. Include specific prompts for next agents if needed sections: - id: architect-prompt - title: Architect Prompt + title: 17.1. Architect Prompt condition: Project has UI components instruction: | Create a brief prompt to hand off to Architect for Frontend Architecture creation. Include: diff --git a/bmad-core/templates/brownfield-architecture-tmpl.yaml b/bmad-core/templates/brownfield-architecture-tmpl.yaml index 259c6161..0a2f5f7a 100644 --- a/bmad-core/templates/brownfield-architecture-tmpl.yaml +++ b/bmad-core/templates/brownfield-architecture-tmpl.yaml @@ -14,7 +14,7 @@ workflow: sections: - id: introduction - title: Introduction + title: 1. Introduction instruction: | IMPORTANT - SCOPE AND ASSESSMENT REQUIRED: @@ -41,7 +41,7 @@ sections: **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 + title: 1.1. Existing Project Analysis instruction: | Analyze the existing project structure and architecture: @@ -55,28 +55,28 @@ sections: elicit: true sections: - id: current-state - title: Current Project State + title: 1.1.1. Current Project State template: | - **Primary Purpose:** {{existing_project_purpose}} - **Current Tech Stack:** {{existing_tech_summary}} - **Architecture Style:** {{existing_architecture_style}} - **Deployment Method:** {{existing_deployment_approach}} - id: available-docs - title: Available Documentation + title: 1.1.2. Available Documentation type: bullet-list template: "- {{existing_docs_summary}}" - id: constraints - title: Identified Constraints + title: 1.1.3. Identified Constraints type: bullet-list template: "- {{constraint}}" - id: changelog - title: Change Log + title: 1.2. Change Log type: table columns: [Change, Date, Version, Description, Author] instruction: Track document versions and changes - id: enhancement-scope - title: Enhancement Scope and Integration Strategy + title: 2. Enhancement Scope and Integration Strategy instruction: | Define how the enhancement will integrate with the existing system: @@ -89,20 +89,20 @@ sections: elicit: true sections: - id: enhancement-overview - title: Enhancement Overview + title: 2.1. Enhancement Overview template: | **Enhancement Type:** {{enhancement_type}} **Scope:** {{enhancement_scope}} **Integration Impact:** {{integration_impact_level}} - id: integration-approach - title: Integration Approach + title: 2.2. Integration Approach template: | **Code Integration Strategy:** {{code_integration_approach}} **Database Integration:** {{database_integration_approach}} **API Integration:** {{api_integration_approach}} **UI Integration:** {{ui_integration_approach}} - id: compatibility-requirements - title: Compatibility Requirements + title: 2.3. Compatibility Requirements template: | - **Existing API Compatibility:** {{api_compatibility}} - **Database Schema Compatibility:** {{db_compatibility}} @@ -110,7 +110,7 @@ sections: - **Performance Impact:** {{performance_constraints}} - id: tech-stack-alignment - title: Tech Stack Alignment + title: 3. Tech Stack Alignment instruction: | Ensure new components align with existing technology choices: @@ -121,19 +121,19 @@ sections: elicit: true sections: - id: existing-stack - title: Existing Technology Stack + title: 3.1. Existing Technology Stack type: table columns: [Category, Current Technology, Version, Usage in Enhancement, Notes] instruction: Document the current stack that must be maintained or integrated with - id: new-tech-additions - title: New Technology Additions + title: 3.2. New Technology Additions condition: Enhancement requires new technologies type: table columns: [Technology, Version, Purpose, Rationale, Integration Method] instruction: Only include if new technologies are required for the enhancement - id: data-models - title: Data Models and Schema Changes + title: 4. Data Models and Schema Changes instruction: | Define new data models and how they integrate with existing schema: @@ -144,11 +144,11 @@ sections: elicit: true sections: - id: new-models - title: New Data Models + title: 4.1. New Data Models repeatable: true sections: - id: model - title: "{{model_name}}" + title: "4.1.1. {{model_name}}" template: | **Purpose:** {{model_purpose}} **Integration:** {{integration_with_existing}} @@ -161,7 +161,7 @@ sections: - **With Existing:** {{existing_relationships}} - **With New:** {{new_relationships}} - id: schema-integration - title: Schema Integration Strategy + title: 4.2. Schema Integration Strategy template: | **Database Changes Required:** - **New Tables:** {{new_tables_list}} @@ -174,7 +174,7 @@ sections: - {{compatibility_measure_2}} - id: component-architecture - title: Component Architecture + title: 5. Component Architecture instruction: | Define new components and their integration with existing architecture: @@ -187,11 +187,11 @@ sections: elicit: true sections: - id: new-components - title: New Components + title: 5.1. New Components repeatable: true sections: - id: component - title: "{{component_name}}" + title: "5.1.1. {{component_name}}" template: | **Responsibility:** {{component_description}} **Integration Points:** {{integration_points}} @@ -206,13 +206,13 @@ sections: **Technology Stack:** {{component_tech_details}} - id: interaction-diagram - title: Component Interaction Diagram + title: 5.2. Component Interaction Diagram type: mermaid mermaid_type: graph instruction: Create Mermaid diagram showing how new components interact with existing ones - id: api-design - title: API Design and Integration + title: 6. API Design and Integration condition: Enhancement requires API changes instruction: | Define new API endpoints and integration with existing APIs: @@ -224,17 +224,17 @@ sections: elicit: true sections: - id: api-strategy - title: API Integration Strategy + title: 6.1. API Integration Strategy template: | **API Integration Strategy:** {{api_integration_strategy}} **Authentication:** {{auth_integration}} **Versioning:** {{versioning_approach}} - id: new-endpoints - title: New API Endpoints + title: 6.2. New API Endpoints repeatable: true sections: - id: endpoint - title: "{{endpoint_name}}" + title: "6.2.1. {{endpoint_name}}" template: | - **Method:** {{http_method}} - **Endpoint:** {{endpoint_path}} @@ -242,24 +242,24 @@ sections: - **Integration:** {{integration_with_existing}} sections: - id: request - title: Request + title: 6.2.1.1. Request type: code language: json template: "{{request_schema}}" - id: response - title: Response + title: 6.2.1.2. Response type: code language: json template: "{{response_schema}}" - id: external-api-integration - title: External API Integration + title: 7. External API Integration condition: Enhancement requires new external APIs instruction: Document new external API integrations required for the enhancement repeatable: true sections: - id: external-api - title: "{{api_name}} API" + title: "7.1. {{api_name}} API" template: | - **Purpose:** {{api_purpose}} - **Documentation:** {{api_docs_url}} @@ -273,7 +273,7 @@ sections: **Error Handling:** {{error_handling_strategy}} - id: source-tree-integration - title: Source Tree Integration + title: 8. Source Tree Integration instruction: | Define how new code will integrate with existing project structure: @@ -284,13 +284,13 @@ sections: elicit: true sections: - id: existing-structure - title: Existing Project Structure + title: 8.1. Existing Project Structure type: code language: plaintext instruction: Document relevant parts of current structure template: "{{existing_structure_relevant_parts}}" - id: new-file-organization - title: New File Organization + title: 8.2. New File Organization type: code language: plaintext instruction: Show only new additions to existing structure @@ -305,14 +305,14 @@ sections: │ │ └── {{new_file_3}} # New addition │ └── {{new_folder_2}}/ # {{purpose_2}} - id: integration-guidelines - title: Integration Guidelines + title: 8.3. Integration Guidelines template: | - **File Naming:** {{file_naming_consistency}} - **Folder Organization:** {{folder_organization_approach}} - **Import/Export Patterns:** {{import_export_consistency}} - id: infrastructure-deployment - title: Infrastructure and Deployment Integration + title: 9. Infrastructure and Deployment Integration instruction: | Define how the enhancement will be deployed alongside existing infrastructure: @@ -323,26 +323,26 @@ sections: elicit: true sections: - id: existing-infrastructure - title: Existing Infrastructure + title: 9.1. Existing Infrastructure template: | **Current Deployment:** {{existing_deployment_summary}} **Infrastructure Tools:** {{existing_infrastructure_tools}} **Environments:** {{existing_environments}} - id: enhancement-deployment - title: Enhancement Deployment Strategy + title: 9.2. Enhancement Deployment Strategy template: | **Deployment Approach:** {{deployment_approach}} **Infrastructure Changes:** {{infrastructure_changes}} **Pipeline Integration:** {{pipeline_integration}} - id: rollback-strategy - title: Rollback Strategy + title: 9.3. Rollback Strategy template: | **Rollback Method:** {{rollback_method}} **Risk Mitigation:** {{risk_mitigation}} **Monitoring:** {{monitoring_approach}} - id: coding-standards - title: Coding Standards and Conventions + title: 10. Coding Standards and Conventions instruction: | Ensure new code follows existing project conventions: @@ -353,19 +353,19 @@ sections: elicit: true sections: - id: existing-standards - title: Existing Standards Compliance + title: 10.1. Existing Standards Compliance template: | **Code Style:** {{existing_code_style}} **Linting Rules:** {{existing_linting}} **Testing Patterns:** {{existing_test_patterns}} **Documentation Style:** {{existing_doc_style}} - id: enhancement-standards - title: Enhancement-Specific Standards + title: 10.2. Enhancement-Specific Standards condition: New patterns needed for enhancement repeatable: true template: "- **{{standard_name}}:** {{standard_description}}" - id: integration-rules - title: Critical Integration Rules + title: 10.3. Critical Integration Rules template: | - **Existing API Compatibility:** {{api_compatibility_rule}} - **Database Integration:** {{db_integration_rule}} @@ -373,7 +373,7 @@ sections: - **Logging Consistency:** {{logging_consistency}} - id: testing-strategy - title: Testing Strategy + title: 11. Testing Strategy instruction: | Define testing approach for the enhancement: @@ -384,36 +384,36 @@ sections: elicit: true sections: - id: existing-test-integration - title: Integration with Existing Tests + title: 11.1. Integration with Existing Tests template: | **Existing Test Framework:** {{existing_test_framework}} **Test Organization:** {{existing_test_organization}} **Coverage Requirements:** {{existing_coverage_requirements}} - id: new-testing - title: New Testing Requirements + title: 11.2. New Testing Requirements sections: - id: unit-tests - title: Unit Tests for New Components + title: 11.2.1. Unit Tests for New Components template: | - **Framework:** {{test_framework}} - **Location:** {{test_location}} - **Coverage Target:** {{coverage_target}} - **Integration with Existing:** {{test_integration}} - id: integration-tests - title: Integration Tests + title: 11.2.2. Integration Tests template: | - **Scope:** {{integration_test_scope}} - **Existing System Verification:** {{existing_system_verification}} - **New Feature Testing:** {{new_feature_testing}} - id: regression-tests - title: Regression Testing + title: 11.2.3. Regression Testing template: | - **Existing Feature Verification:** {{regression_test_approach}} - **Automated Regression Suite:** {{automated_regression}} - **Manual Testing Requirements:** {{manual_testing_requirements}} - id: security-integration - title: Security Integration + title: 12. Security Integration instruction: | Ensure security consistency with existing system: @@ -424,31 +424,31 @@ sections: elicit: true sections: - id: existing-security - title: Existing Security Measures + title: 12.1. Existing Security Measures template: | **Authentication:** {{existing_auth}} **Authorization:** {{existing_authz}} **Data Protection:** {{existing_data_protection}} **Security Tools:** {{existing_security_tools}} - id: enhancement-security - title: Enhancement Security Requirements + title: 12.2. Enhancement Security Requirements template: | **New Security Measures:** {{new_security_measures}} **Integration Points:** {{security_integration_points}} **Compliance Requirements:** {{compliance_requirements}} - id: security-testing - title: Security Testing + title: 12.3. Security Testing template: | **Existing Security Tests:** {{existing_security_tests}} **New Security Test Requirements:** {{new_security_tests}} **Penetration Testing:** {{pentest_requirements}} - id: checklist-results - title: Checklist Results Report + title: 13. Checklist Results Report instruction: Execute the architect-checklist and populate results here, focusing on brownfield-specific validation - id: next-steps - title: Next Steps + title: 14. Next Steps instruction: | After completing the brownfield architecture: @@ -458,7 +458,7 @@ sections: 4. Plan rollback and monitoring procedures sections: - id: story-manager-handoff - title: Story Manager Handoff + title: 14.1. Story Manager Handoff instruction: | Create a brief prompt for Story Manager to work with this brownfield enhancement. Include: - Reference to this architecture document @@ -467,7 +467,7 @@ sections: - First story to implement with clear integration checkpoints - Emphasis on maintaining existing system integrity throughout implementation - id: developer-handoff - title: Developer Handoff + title: 14.2. Developer Handoff instruction: | Create a brief prompt for developers starting implementation. Include: - Reference to this architecture and existing coding standards analyzed from actual project diff --git a/bmad-core/templates/brownfield-prd-tmpl.yaml b/bmad-core/templates/brownfield-prd-tmpl.yaml index 3df90c5e..66584445 100644 --- a/bmad-core/templates/brownfield-prd-tmpl.yaml +++ b/bmad-core/templates/brownfield-prd-tmpl.yaml @@ -14,7 +14,7 @@ workflow: sections: - id: intro-analysis - title: Intro Project Analysis and Context + title: 1. Intro Project Analysis and Context instruction: | IMPORTANT - SCOPE ASSESSMENT REQUIRED: @@ -33,23 +33,23 @@ sections: Do not proceed with any recommendations until the user has validated your understanding of the existing system. sections: - id: existing-project-overview - title: Existing Project Overview + title: 1.1. Existing Project Overview instruction: Check if document-project analysis was already performed. If yes, reference that output instead of re-analyzing. sections: - id: analysis-source - title: Analysis Source + title: 1.1.1. Analysis Source instruction: | Indicate one of the following: - Document-project output available at: {{path}} - IDE-based fresh analysis - User-provided information - id: current-state - title: Current Project State + title: 1.1.2. Current Project State instruction: | - If document-project output exists: Extract summary from "High Level Architecture" and "Technical Summary" sections - Otherwise: Brief description of what the project currently does and its primary purpose - id: documentation-analysis - title: Available Documentation Analysis + title: 1.2. Available Documentation Analysis instruction: | If document-project was run: - Note: "Document-project analysis available - using existing technical documentation" @@ -59,7 +59,7 @@ sections: Otherwise, check for existing documentation: sections: - id: available-docs - title: Available Documentation + title: 1.2.1. Available Documentation type: checklist items: - Tech Stack Documentation [[LLM: If from document-project, check ✓]] @@ -74,11 +74,11 @@ sections: - If document-project was already run: "Using existing project analysis from document-project output." - If critical documentation is missing and no document-project: "I recommend running the document-project task first..." - id: enhancement-scope - title: Enhancement Scope Definition + title: 1.3. Enhancement Scope Definition instruction: Work with user to clearly define what type of enhancement this is. This is critical for scoping and approach. sections: - id: enhancement-type - title: Enhancement Type + title: 1.3.1. Enhancement Type type: checklist instruction: Determine with user which applies items: @@ -91,10 +91,10 @@ sections: - Bug Fix and Stability Improvements - "Other: {{other_type}}" - id: enhancement-description - title: Enhancement Description + title: 1.3.2. Enhancement Description instruction: 2-3 sentences describing what the user wants to add or change - id: impact-assessment - title: Impact Assessment + title: 1.3.3. Impact Assessment type: checklist instruction: Assess the scope of impact on existing codebase items: @@ -103,43 +103,43 @@ sections: - Significant Impact (substantial existing code changes) - Major Impact (architectural changes required) - id: goals-context - title: Goals and Background Context + title: 1.4. Goals and Background Context sections: - id: goals - title: Goals + title: 1.4.1. Goals type: bullet-list instruction: Bullet list of 1-line desired outcomes this enhancement will deliver if successful - id: background - title: Background Context + title: 1.4.2. Background Context type: paragraphs instruction: 1-2 short paragraphs explaining why this enhancement is needed, what problem it solves, and how it fits with the existing project - id: changelog - title: Change Log + title: 1.5. Change Log type: table columns: [Change, Date, Version, Description, Author] - id: requirements - title: Requirements + title: 2. Requirements instruction: | Draft functional and non-functional requirements based on your validated understanding of the existing project. Before presenting requirements, confirm: "These requirements are based on my understanding of your existing system. Please review carefully and confirm they align with your project's reality." elicit: true sections: - id: functional - title: Functional + title: 2.1. Functional type: numbered-list prefix: FR instruction: Each Requirement will be a bullet markdown with identifier starting with FR examples: - "FR1: The existing Todo List will integrate with the new AI duplicate detection service without breaking current functionality." - id: non-functional - title: Non Functional + title: 2.2. Non Functional type: numbered-list prefix: NFR instruction: Each Requirement will be a bullet markdown with identifier starting with NFR. Include constraints from existing system examples: - "NFR1: Enhancement must maintain existing performance characteristics and not exceed current memory usage by more than 20%." - id: compatibility - title: Compatibility Requirements + title: 2.3. Compatibility Requirements instruction: Critical for brownfield - what must remain compatible type: numbered-list prefix: CR @@ -155,26 +155,26 @@ sections: template: "CR4: {{integration_compatibility}}" - id: ui-enhancement-goals - title: User Interface Enhancement Goals + title: 3. User Interface Enhancement Goals condition: Enhancement includes UI changes instruction: For UI changes, capture how they will integrate with existing UI patterns and design systems sections: - id: existing-ui-integration - title: Integration with Existing UI + title: 3.1. Integration with Existing UI instruction: Describe how new UI elements will fit with existing design patterns, style guides, and component libraries - id: modified-screens - title: Modified/New Screens and Views + title: 3.2. Modified/New Screens and Views instruction: List only the screens/views that will be modified or added - id: ui-consistency - title: UI Consistency Requirements + title: 3.3. UI Consistency Requirements instruction: Specific requirements for maintaining visual and interaction consistency with existing application - id: technical-constraints - title: Technical Constraints and Integration Requirements + title: 4. Technical Constraints and Integration Requirements instruction: This section replaces separate architecture documentation. Gather detailed technical constraints from existing project analysis. sections: - id: existing-tech-stack - title: Existing Technology Stack + title: 4.1. Existing Technology Stack instruction: | If document-project output available: - Extract from "Actual Tech Stack" table in High Level Architecture section @@ -188,7 +188,7 @@ sections: **Infrastructure**: {{infrastructure}} **External Dependencies**: {{external_dependencies}} - id: integration-approach - title: Integration Approach + title: 4.2. Integration Approach instruction: Define how the enhancement will integrate with existing architecture template: | **Database Integration Strategy**: {{database_integration}} @@ -196,7 +196,7 @@ sections: **Frontend Integration Strategy**: {{frontend_integration}} **Testing Integration Strategy**: {{testing_integration}} - id: code-organization - title: Code Organization and Standards + title: 4.3. Code Organization and Standards instruction: Based on existing project analysis, define how new code will fit existing patterns template: | **File Structure Approach**: {{file_structure}} @@ -204,7 +204,7 @@ sections: **Coding Standards**: {{coding_standards}} **Documentation Standards**: {{documentation_standards}} - id: deployment-operations - title: Deployment and Operations + title: 4.4. Deployment and Operations instruction: How the enhancement fits existing deployment pipeline template: | **Build Process Integration**: {{build_integration}} @@ -212,7 +212,7 @@ sections: **Monitoring and Logging**: {{monitoring_logging}} **Configuration Management**: {{config_management}} - id: risk-assessment - title: Risk Assessment and Mitigation + title: 4.5. Risk Assessment and Mitigation instruction: | If document-project output available: - Reference "Technical Debt and Known Issues" section @@ -227,18 +227,18 @@ sections: **Mitigation Strategies**: {{mitigation_strategies}} - id: epic-structure - title: Epic and Story Structure + title: 5. Epic and Story Structure instruction: | For brownfield projects, favor a single comprehensive epic unless the user is clearly requesting multiple unrelated enhancements. Before presenting the epic structure, confirm: "Based on my analysis of your existing project, I believe this enhancement should be structured as [single epic/multiple epics] because [rationale based on actual project analysis]. Does this align with your understanding of the work required?" elicit: true sections: - id: epic-approach - title: Epic Approach + title: 5.1. Epic Approach instruction: Explain the rationale for epic structure - typically single epic for brownfield unless multiple unrelated features template: "**Epic Structure Decision**: {{epic_decision}} with rationale" - id: epic-details - title: "Epic 1: {{enhancement_title}}" + title: "6. Epic 1: {{enhancement_title}}" instruction: | Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality @@ -258,7 +258,7 @@ sections: **Integration Requirements**: {{integration_requirements}} sections: - id: story - title: "Story 1.{{story_number}} {{story_title}}" + title: "6.1. Story 1.{{story_number}} {{story_title}}" repeatable: true template: | As a {{user_type}}, @@ -266,12 +266,12 @@ sections: so that {{benefit}}. sections: - id: acceptance-criteria - title: Acceptance Criteria + title: 6.1.1. Acceptance Criteria type: numbered-list instruction: Define criteria that include both new functionality and existing system integrity item_template: "{{criterion_number}}: {{criteria}}" - id: integration-verification - title: Integration Verification + title: 6.1.2. Integration Verification instruction: Specific verification steps to ensure existing functionality remains intact type: numbered-list prefix: IV diff --git a/bmad-core/templates/front-end-architecture-tmpl.yaml b/bmad-core/templates/front-end-architecture-tmpl.yaml index 4ef2db43..dbd3d40a 100644 --- a/bmad-core/templates/front-end-architecture-tmpl.yaml +++ b/bmad-core/templates/front-end-architecture-tmpl.yaml @@ -14,7 +14,7 @@ workflow: sections: - id: template-framework-selection - title: Template and Framework Selection + title: 1. 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. @@ -58,18 +58,18 @@ sections: Document the starter template decision and any constraints it imposes before proceeding. sections: - id: changelog - title: Change Log + title: 1.1. Change Log type: table columns: [Date, Version, Description, Author] instruction: Track document versions and changes - id: frontend-tech-stack - title: Frontend Tech Stack + title: 2. Frontend Tech Stack instruction: Extract from main architecture's Technology Stack Table. This section MUST remain synchronized with the main architecture document. elicit: true sections: - id: tech-stack-table - title: Technology Stack Table + title: 2.1. Technology Stack Table type: table columns: [Category, Technology, Version, Purpose, Rationale] instruction: Fill in appropriate technology choices based on the selected framework and project requirements. @@ -99,95 +99,95 @@ sections: - ["Dev Tools", "{{dev_tools}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"] - id: project-structure - title: Project Structure + title: 3. Project Structure instruction: Define exact directory structure for AI tools based on the chosen framework. Be specific about where each type of file goes. Generate a structure that follows the framework's best practices and conventions. elicit: true type: code language: plaintext - id: component-standards - title: Component Standards + title: 4. Component Standards instruction: Define exact patterns for component creation based on the chosen framework. elicit: true sections: - id: component-template - title: Component Template + title: 4.1. Component Template instruction: Generate a minimal but complete component template following the framework's best practices. Include TypeScript types, proper imports, and basic structure. type: code language: typescript - id: naming-conventions - title: Naming Conventions + title: 4.2. Naming Conventions instruction: Provide naming conventions specific to the chosen framework for components, files, services, state management, and other architectural elements. - id: state-management - title: State Management + title: 5. State Management instruction: Define state management patterns based on the chosen framework. elicit: true sections: - id: store-structure - title: Store Structure + title: 5.1. Store Structure instruction: Generate the state management directory structure appropriate for the chosen framework and selected state management solution. type: code language: plaintext - id: state-template - title: State Management Template + title: 5.2. State Management Template instruction: Provide a basic state management template/example following the framework's recommended patterns. Include TypeScript types and common operations like setting, updating, and clearing state. type: code language: typescript - id: api-integration - title: API Integration + title: 6. API Integration instruction: Define API service patterns based on the chosen framework. elicit: true sections: - id: service-template - title: Service Template + title: 6.1. Service Template instruction: Provide an API service template that follows the framework's conventions. Include proper TypeScript types, error handling, and async patterns. type: code language: typescript - id: api-client-config - title: API Client Configuration + title: 6.2. API Client Configuration instruction: Show how to configure the HTTP client for the chosen framework, including authentication interceptors/middleware and error handling. type: code language: typescript - id: routing - title: Routing + title: 7. Routing instruction: Define routing structure and patterns based on the chosen framework. elicit: true sections: - id: route-configuration - title: Route Configuration + title: 7.1. Route Configuration instruction: Provide routing configuration appropriate for the chosen framework. Include protected route patterns, lazy loading where applicable, and authentication guards/middleware. type: code language: typescript - id: styling-guidelines - title: Styling Guidelines + title: 8. Styling Guidelines instruction: Define styling approach based on the chosen framework. elicit: true sections: - id: styling-approach - title: Styling Approach + title: 8.1. Styling Approach instruction: Describe the styling methodology appropriate for the chosen framework (CSS Modules, Styled Components, Tailwind, etc.) and provide basic patterns. - id: global-theme - title: Global Theme Variables + title: 8.2. Global Theme Variables instruction: Provide a CSS custom properties (CSS variables) theme system that works across all frameworks. Include colors, spacing, typography, shadows, and dark mode support. type: code language: css - id: testing-requirements - title: Testing Requirements + title: 9. Testing Requirements instruction: Define minimal testing requirements based on the chosen framework. elicit: true sections: - id: component-test-template - title: Component Test Template + title: 9.1. Component Test Template instruction: Provide a basic component test template using the framework's recommended testing library. Include examples of rendering tests, user interaction tests, and mocking. type: code language: typescript - id: testing-best-practices - title: Testing Best Practices + title: 9.2. Testing Best Practices type: numbered-list items: - "**Unit Tests**: Test individual components in isolation" @@ -198,19 +198,19 @@ sections: - "**Mock External Dependencies**: API calls, routing, state management" - id: environment-configuration - title: Environment Configuration + title: 10. Environment Configuration instruction: List required environment variables based on the chosen framework. Show the appropriate format and naming conventions for the framework. elicit: true - id: frontend-developer-standards - title: Frontend Developer Standards + title: 11. Frontend Developer Standards sections: - id: critical-coding-rules - title: Critical Coding Rules + title: 11.1. Critical Coding Rules instruction: List essential rules that prevent common AI mistakes, including both universal rules and framework-specific ones. elicit: true - id: quick-reference - title: Quick Reference + title: 11.2. Quick Reference instruction: | Create a framework-specific cheat sheet with: - Common commands (dev server, build, test) diff --git a/bmad-core/templates/fullstack-architecture-tmpl.yaml b/bmad-core/templates/fullstack-architecture-tmpl.yaml index a5d2c1d3..fcbc2459 100644 --- a/bmad-core/templates/fullstack-architecture-tmpl.yaml +++ b/bmad-core/templates/fullstack-architecture-tmpl.yaml @@ -14,7 +14,7 @@ workflow: sections: - id: introduction - title: Introduction + title: 1. Introduction instruction: | If available, review any provided relevant documents to gather all relevant context before beginning. At minimum, you should have access to docs/prd.md and docs/front-end-spec.md. Ask the user for any documents you need but cannot locate. This template creates a unified architecture that covers both backend and frontend concerns to guide AI-driven fullstack development. elicit: true @@ -24,7 +24,7 @@ sections: 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 + title: 1.1. Starter Template or Existing Project instruction: | Before proceeding with architecture design, check if the project is based on any starter templates or existing codebases: @@ -49,18 +49,18 @@ sections: If none, state "N/A - Greenfield project" - id: changelog - title: Change Log + title: 1.2. Change Log type: table columns: [Date, Version, Description, Author] instruction: Track document versions and changes - id: high-level-architecture - title: High Level Architecture + title: 2. High Level Architecture instruction: This section contains multiple subsections that establish the foundation. Present all subsections together, then elicit feedback on the complete section. elicit: true sections: - id: technical-summary - title: Technical Summary + title: 2.1. Technical Summary instruction: | Provide a comprehensive overview (4-6 sentences) covering: - Overall architectural style and deployment approach @@ -69,7 +69,7 @@ sections: - Infrastructure platform and services - How this architecture achieves PRD goals - id: platform-infrastructure - title: Platform and Infrastructure Choice + title: 2.2. Platform and Infrastructure Choice instruction: | Based on PRD requirements and technical assumptions, make a platform recommendation: @@ -89,7 +89,7 @@ sections: **Key Services:** {{core_services_list}} **Deployment Host and Regions:** {{regions}} - id: repository-structure - title: Repository Structure + title: 2.3. 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: @@ -102,7 +102,7 @@ sections: **Monorepo Tool:** {{monorepo_tool_if_applicable}} **Package Organization:** {{package_strategy}} - id: architecture-diagram - title: High Level Architecture Diagram + title: 2.4. High Level Architecture Diagram type: mermaid mermaid_type: graph instruction: | @@ -117,7 +117,7 @@ sections: Use appropriate diagram type for clarity. - id: architectural-patterns - title: Architectural Patterns + title: 2.5. Architectural Patterns instruction: | List patterns that will guide both frontend and backend development. Include patterns for: - Overall architecture (e.g., Jamstack, Serverless, Microservices) @@ -135,7 +135,7 @@ sections: - "**API Gateway Pattern:** Single entry point for all API calls - _Rationale:_ Centralized auth, rate limiting, and monitoring" - id: tech-stack - title: Tech Stack + title: 3. 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. @@ -152,7 +152,7 @@ sections: elicit: true sections: - id: tech-stack-table - title: Technology Stack Table + title: 3.1. Technology Stack Table type: table columns: [Category, Technology, Version, Purpose, Rationale] rows: @@ -197,7 +197,7 @@ sections: - ["CSS Framework", "{{css_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"] - id: data-models - title: Data Models + title: 4. Data Models instruction: | Define the core data models/entities that will be shared between frontend and backend: @@ -232,7 +232,7 @@ sections: template: "- {{relationship}}" - id: api-spec - title: API Specification + title: 5. API Specification instruction: | Based on the chosen API style from Tech Stack: @@ -248,7 +248,7 @@ sections: elicit: true sections: - id: rest-api - title: REST API Specification + title: 5.1. REST API Specification condition: API style is REST type: code language: yaml @@ -262,20 +262,20 @@ sections: - url: {{server_url}} description: {{server_description}} - id: graphql-api - title: GraphQL Schema + title: 5.2. GraphQL Schema condition: API style is GraphQL type: code language: graphql template: "{{graphql_schema}}" - id: trpc-api - title: tRPC Router Definitions + title: 5.3. tRPC Router Definitions condition: API style is tRPC type: code language: typescript template: "{{trpc_routers}}" - id: components - title: Components + title: 6. Components instruction: | Based on the architectural patterns, tech stack, and data models from above: @@ -305,7 +305,7 @@ sections: **Technology Stack:** {{component_tech_details}} - id: component-diagrams - title: Component Diagrams + title: 6.1. Component Diagrams type: mermaid instruction: | Create Mermaid diagrams to visualize component relationships. Options: @@ -315,7 +315,7 @@ sections: Choose the most appropriate for clarity - id: external-apis - title: External APIs + title: 7. External APIs condition: Project requires external API integrations instruction: | For each external service integration: @@ -345,7 +345,7 @@ sections: **Integration Notes:** {{integration_considerations}} - id: core-workflows - title: Core Workflows + title: 8. Core Workflows type: mermaid mermaid_type: sequence instruction: | @@ -362,7 +362,7 @@ sections: elicit: true - id: database-schema - title: Database Schema + title: 9. Database Schema instruction: | Transform the conceptual data models into concrete database schemas: @@ -376,85 +376,85 @@ sections: elicit: true - id: frontend-architecture - title: Frontend Architecture + title: 10. Frontend Architecture instruction: Define frontend-specific architecture details. After each subsection, note if user wants to refine before continuing. elicit: true sections: - id: component-architecture - title: Component Architecture + title: 10.1. Component Architecture instruction: Define component organization and patterns based on chosen framework. sections: - id: component-organization - title: Component Organization + title: 10.1.1. Component Organization type: code language: text template: "{{component_structure}}" - id: component-template - title: Component Template + title: 10.1.2. Component Template type: code language: typescript template: "{{component_template}}" - id: state-management - title: State Management Architecture + title: 10.2. State Management Architecture instruction: Detail state management approach based on chosen solution. sections: - id: state-structure - title: State Structure + title: 10.2.1. State Structure type: code language: typescript template: "{{state_structure}}" - id: state-patterns - title: State Management Patterns + title: 10.2.2. State Management Patterns type: bullet-list template: "- {{pattern}}" - id: routing-architecture - title: Routing Architecture + title: 10.3. Routing Architecture instruction: Define routing structure based on framework choice. sections: - id: route-organization - title: Route Organization + title: 10.3.1. Route Organization type: code language: text template: "{{route_structure}}" - id: protected-routes - title: Protected Route Pattern + title: 10.3.2. Protected Route Pattern type: code language: typescript template: "{{protected_route_example}}" - id: frontend-services - title: Frontend Services Layer + title: 10.4. Frontend Services Layer instruction: Define how frontend communicates with backend. sections: - id: api-client-setup - title: API Client Setup + title: 10.4.1. API Client Setup type: code language: typescript template: "{{api_client_setup}}" - id: service-example - title: Service Example + title: 10.4.2. Service Example type: code language: typescript template: "{{service_example}}" - id: backend-architecture - title: Backend Architecture + title: 11. Backend Architecture instruction: Define backend-specific architecture details. Consider serverless vs traditional server approaches. elicit: true sections: - id: service-architecture - title: Service Architecture + title: 11.1. Service Architecture instruction: Based on platform choice, define service organization. sections: - id: serverless-architecture condition: Serverless architecture chosen sections: - id: function-organization - title: Function Organization + title: 11.1.1. Function Organization type: code language: text template: "{{function_structure}}" - id: function-template - title: Function Template + title: 11.1.2. Function Template type: code language: typescript template: "{{function_template}}" @@ -462,46 +462,46 @@ sections: condition: Traditional server architecture chosen sections: - id: controller-organization - title: Controller/Route Organization + title: 11.1.3. Controller/Route Organization type: code language: text template: "{{controller_structure}}" - id: controller-template - title: Controller Template + title: 11.1.4. Controller Template type: code language: typescript template: "{{controller_template}}" - id: database-architecture - title: Database Architecture + title: 11.2. Database Architecture instruction: Define database schema and access patterns. sections: - id: schema-design - title: Schema Design + title: 11.2.1. Schema Design type: code language: sql template: "{{database_schema}}" - id: data-access-layer - title: Data Access Layer + title: 11.2.2. Data Access Layer type: code language: typescript template: "{{repository_pattern}}" - id: auth-architecture - title: Authentication and Authorization + title: 11.3. Authentication and Authorization instruction: Define auth implementation details. sections: - id: auth-flow - title: Auth Flow + title: 11.3.1. Auth Flow type: mermaid mermaid_type: sequence template: "{{auth_flow_diagram}}" - id: auth-middleware - title: Middleware/Guards + title: 11.3.2. Middleware/Guards type: code language: typescript template: "{{auth_middleware}}" - id: unified-project-structure - title: Unified Project Structure + title: 12. Unified Project Structure instruction: Create a monorepo structure that accommodates both frontend and backend. Adapt based on chosen tools and frameworks. elicit: true type: code @@ -563,25 +563,25 @@ sections: └── README.md - id: development-workflow - title: Development Workflow + title: 13. Development Workflow instruction: Define the development setup and workflow for the fullstack application. elicit: true sections: - id: local-setup - title: Local Development Setup + title: 13.1. Local Development Setup sections: - id: prerequisites - title: Prerequisites + title: 13.1.1. Prerequisites type: code language: bash template: "{{prerequisites_commands}}" - id: initial-setup - title: Initial Setup + title: 13.1.2. Initial Setup type: code language: bash template: "{{setup_commands}}" - id: dev-commands - title: Development Commands + title: 13.1.3. Development Commands type: code language: bash template: | @@ -597,10 +597,10 @@ sections: # Run tests {{test_commands}} - id: environment-config - title: Environment Configuration + title: 13.2. Environment Configuration sections: - id: env-vars - title: Required Environment Variables + title: 13.2.1. Required Environment Variables type: code language: bash template: | @@ -614,12 +614,12 @@ sections: {{shared_env_vars}} - id: deployment-architecture - title: Deployment Architecture + title: 14. Deployment Architecture instruction: Define deployment strategy based on platform choice. elicit: true sections: - id: deployment-strategy - title: Deployment Strategy + title: 14.1. Deployment Strategy template: | **Frontend Deployment:** - **Platform:** {{frontend_deploy_platform}} @@ -632,12 +632,12 @@ sections: - **Build Command:** {{backend_build_command}} - **Deployment Method:** {{deployment_method}} - id: cicd-pipeline - title: CI/CD Pipeline + title: 14.2. CI/CD Pipeline type: code language: yaml template: "{{cicd_pipeline_config}}" - id: environments - title: Environments + title: 14.3. Environments type: table columns: [Environment, Frontend URL, Backend URL, Purpose] rows: @@ -646,12 +646,12 @@ sections: - ["Production", "{{prod_fe_url}}", "{{prod_be_url}}", "Live environment"] - id: security-performance - title: Security and Performance + title: 15. Security and Performance instruction: Define security and performance considerations for the fullstack application. elicit: true sections: - id: security-requirements - title: Security Requirements + title: 15.1. Security Requirements template: | **Frontend Security:** - CSP Headers: {{csp_policy}} @@ -668,7 +668,7 @@ sections: - Session Management: {{session_approach}} - Password Policy: {{password_requirements}} - id: performance-optimization - title: Performance Optimization + title: 15.2. Performance Optimization template: | **Frontend Performance:** - Bundle Size Target: {{bundle_size}} @@ -681,12 +681,12 @@ sections: - Caching Strategy: {{be_cache_strategy}} - id: testing-strategy - title: Testing Strategy + title: 16. Testing Strategy instruction: Define comprehensive testing approach for fullstack application. elicit: true sections: - id: testing-pyramid - title: Testing Pyramid + title: 16.1. Testing Pyramid type: code language: text template: | @@ -696,49 +696,49 @@ sections: / \ Frontend Unit Backend Unit - id: test-organization - title: Test Organization + title: 16.2. Test Organization sections: - id: frontend-tests - title: Frontend Tests + title: 16.2.1. Frontend Tests type: code language: text template: "{{frontend_test_structure}}" - id: backend-tests - title: Backend Tests + title: 16.2.2. Backend Tests type: code language: text template: "{{backend_test_structure}}" - id: e2e-tests - title: E2E Tests + title: 16.2.3. E2E Tests type: code language: text template: "{{e2e_test_structure}}" - id: test-examples - title: Test Examples + title: 16.3. Test Examples sections: - id: frontend-test - title: Frontend Component Test + title: 16.3.1. Frontend Component Test type: code language: typescript template: "{{frontend_test_example}}" - id: backend-test - title: Backend API Test + title: 16.3.2. Backend API Test type: code language: typescript template: "{{backend_test_example}}" - id: e2e-test - title: E2E Test + title: 16.3.3. E2E Test type: code language: typescript template: "{{e2e_test_example}}" - id: coding-standards - title: Coding Standards + title: 17. Coding Standards instruction: Define MINIMAL but CRITICAL standards for AI agents. Focus only on project-specific rules that prevent common mistakes. These will be used by dev agents. elicit: true sections: - id: critical-rules - title: Critical Fullstack Rules + title: 17.1. Critical Fullstack Rules repeatable: true template: "- **{{rule_name}}:** {{rule_description}}" examples: @@ -748,7 +748,7 @@ sections: - "**Error Handling:** All API routes must use the standard error handler" - "**State Updates:** Never mutate state directly - use proper state management patterns" - id: naming-conventions - title: Naming Conventions + title: 17.2. Naming Conventions type: table columns: [Element, Frontend, Backend, Example] rows: @@ -758,17 +758,17 @@ sections: - ["Database Tables", "-", "snake_case", "`user_profiles`"] - id: error-handling - title: Error Handling Strategy + title: 18. Error Handling Strategy instruction: Define unified error handling across frontend and backend. elicit: true sections: - id: error-flow - title: Error Flow + title: 18.1. Error Flow type: mermaid mermaid_type: sequence template: "{{error_flow_diagram}}" - id: error-format - title: Error Response Format + title: 18.2. Error Response Format type: code language: typescript template: | @@ -782,30 +782,30 @@ sections: }; } - id: frontend-error-handling - title: Frontend Error Handling + title: 18.3. Frontend Error Handling type: code language: typescript template: "{{frontend_error_handler}}" - id: backend-error-handling - title: Backend Error Handling + title: 18.4. Backend Error Handling type: code language: typescript template: "{{backend_error_handler}}" - id: monitoring - title: Monitoring and Observability + title: 19. Monitoring and Observability instruction: Define monitoring strategy for fullstack application. elicit: true sections: - id: monitoring-stack - title: Monitoring Stack + title: 19.1. Monitoring Stack template: | - **Frontend Monitoring:** {{frontend_monitoring}} - **Backend Monitoring:** {{backend_monitoring}} - **Error Tracking:** {{error_tracking}} - **Performance Monitoring:** {{perf_monitoring}} - id: key-metrics - title: Key Metrics + title: 19.2. Key Metrics template: | **Frontend Metrics:** - Core Web Vitals @@ -820,5 +820,5 @@ sections: - Database query performance - id: checklist-results - title: Checklist Results Report + title: 20. Checklist Results Report instruction: Before running the checklist, offer to output the full architecture document. Once user confirms, execute the architect-checklist and populate results here. diff --git a/bmad-core/templates/prd-tmpl.yaml b/bmad-core/templates/prd-tmpl.yaml index 804f6d45..d40032da 100644 --- a/bmad-core/templates/prd-tmpl.yaml +++ b/bmad-core/templates/prd-tmpl.yaml @@ -14,38 +14,38 @@ workflow: sections: - id: goals-context - title: Goals and Background Context + title: 1. Goals and Background Context instruction: | Ask if Project Brief document is available. If NO Project Brief exists, STRONGLY recommend creating one first using project-brief-tmpl (it provides essential foundation: problem statement, target users, success metrics, MVP scope, constraints). If user insists on PRD without brief, gather this information during Goals section. If Project Brief exists, review and use it to populate Goals (bullet list of desired outcomes) and Background Context (1-2 paragraphs on what this solves and why) so we can determine what is and is not in scope for PRD mvp. Either way this is critical to determine the requirements. Include Change Log table. sections: - id: goals - title: Goals + title: 1.1. Goals type: bullet-list instruction: Bullet list of 1 line desired outcomes the PRD will deliver if successful - user and project desires - id: background - title: Background Context + title: 1.2. Background Context type: paragraphs instruction: 1-2 short paragraphs summarizing the background context, such as what we learned in the brief without being redundant with the goals, what and why this solves a problem, what the current landscape or need is - id: changelog - title: Change Log + title: 1.3. Change Log type: table columns: [Date, Version, Description, Author] instruction: Track document versions and changes - id: requirements - title: Requirements + title: 2. Requirements instruction: Draft the list of functional and non functional requirements under the two child sections elicit: true sections: - id: functional - title: Functional + title: 2.1. Functional type: numbered-list prefix: FR instruction: Each Requirement will be a bullet markdown and an identifier sequence starting with FR examples: - "FR6: The Todo List uses AI to detect and warn against potentially duplicate todo items that are worded differently." - id: non-functional - title: Non Functional + title: 2.2. Non Functional type: numbered-list prefix: NFR instruction: Each Requirement will be a bullet markdown and an identifier sequence starting with NFR @@ -53,7 +53,7 @@ sections: - "NFR1: AWS service usage must aim to stay within free-tier limits where feasible." - id: ui-goals - title: User Interface Design Goals + title: 3. User Interface Design Goals condition: PRD has UX/UI requirements instruction: | Capture high-level UI/UX vision to guide Design Architect and to inform story creation. Steps: @@ -69,11 +69,11 @@ sections: platforms: [Web Responsive, Mobile Only, Desktop Only, Cross-Platform] sections: - id: ux-vision - title: Overall UX Vision + title: 3.1. Overall UX Vision - id: interaction-paradigms - title: Key Interaction Paradigms + title: 3.2. Key Interaction Paradigms - id: core-screens - title: Core Screens and Views + title: 3.3. Core Screens and Views instruction: From a product perspective, what are the most critical screens or views necessary to deliver the the PRD values and goals? This is meant to be Conceptual High Level to Drive Rough Epic or User Stories examples: - "Login Screen" @@ -81,22 +81,22 @@ sections: - "Item Detail Page" - "Settings Page" - id: accessibility - title: "Accessibility: {None|WCAG AA|WCAG AAA|Custom Requirements}" + title: "3.4. Accessibility: {None|WCAG AA|WCAG AAA|Custom Requirements}" - id: branding - title: Branding + title: 3.5. Branding instruction: Any known branding elements or style guides that must be incorporated? examples: - "Replicate the look and feel of early 1900s black and white cinema, including animated effects replicating film damage or projector glitches during page or state transitions." - "Attached is the full color pallet and tokens for our corporate branding." - id: target-platforms - title: "Target Device and Platforms: {Web Responsive|Mobile Only|Desktop Only|Cross-Platform}" + title: "3.6. Target Device and Platforms: {Web Responsive|Mobile Only|Desktop Only|Cross-Platform}" examples: - "Web Responsive, and all mobile platforms" - "iPhone Only" - "ASCII Windows Desktop" - id: technical-assumptions - title: Technical Assumptions + title: 4. Technical Assumptions instruction: | Gather technical decisions that will guide the Architect. Steps: @@ -112,19 +112,19 @@ sections: testing: [Unit Only, Unit + Integration, Full Testing Pyramid] sections: - id: repository-structure - title: "Repository Structure: {Monorepo|Polyrepo|Multi-repo}" + title: "4.1. Repository Structure: {Monorepo|Polyrepo|Multi-repo}" - id: service-architecture - title: Service Architecture + title: 4.2. Service Architecture instruction: "CRITICAL DECISION - Document the high-level service architecture (e.g., Monolith, Microservices, Serverless functions within a Monorepo)." - id: testing-requirements - title: Testing Requirements + title: 4.3. Testing Requirements instruction: "CRITICAL DECISION - Document the testing requirements, unit only, integration, e2e, manual, need for manual testing convenience methods)." - id: additional-assumptions - title: Additional Technical Assumptions and Requests + title: 4.4. Additional Technical Assumptions and Requests instruction: Throughout the entire process of drafting this document, if any other technical assumptions are raised or discovered appropriate for the architect, add them here as additional bulleted items - id: epic-list - title: Epic List + title: 5. 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. @@ -144,7 +144,7 @@ sections: - "Epic 4: Reporting & Analytics: Provide insights and data visualization for users" - id: epic-details - title: Epic {{epic_number}} {{epic_title}} + title: 6. Epic {{epic_number}} {{epic_title}} repeatable: true instruction: | After the epic list is approved, present each epic with all its stories and acceptance criteria as a complete review unit. @@ -166,7 +166,7 @@ sections: template: "{{epic_goal}}" sections: - id: story - title: Story {{epic_number}}.{{story_number}} {{story_title}} + title: 6.{{epic_number}}.{{story_number}} Story {{epic_number}}.{{story_number}} {{story_title}} repeatable: true template: | As a {{user_type}}, @@ -174,7 +174,7 @@ sections: so that {{benefit}}. sections: - id: acceptance-criteria - title: Acceptance Criteria + title: 6.{{epic_number}}.{{story_number}}.1. Acceptance Criteria type: numbered-list item_template: "{{criterion_number}}: {{criteria}}" repeatable: true @@ -189,15 +189,15 @@ sections: - Avoid cross-cutting concerns that should be in other stories or PRD sections - id: checklist-results - title: Checklist Results Report + title: 7. Checklist Results Report instruction: Before running the checklist and drafting the prompts, offer to output the full updated PRD. If outputting it, confirm with the user that you will be proceeding to run the checklist and produce the report. Once the user confirms, execute the pm-checklist and populate the results in this section. - id: next-steps - title: Next Steps + title: 8. Next Steps sections: - id: ux-expert-prompt - title: UX Expert Prompt + title: 8.1. UX Expert Prompt instruction: This section will contain the prompt for the UX Expert, keep it short and to the point to initiate create architecture mode using this document as input. - id: architect-prompt - title: Architect Prompt + title: 8.2. Architect Prompt instruction: This section will contain the prompt for the Architect, keep it short and to the point to initiate create architecture mode using this document as input.