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

feat: add hierarchical section indices to all template files 

- 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 <noreply@anthropic.com>
This commit is contained in:
minhtrungcc 2025-09-07 13:25:16 +07:00
parent de6c14df07
commit 62cee232c4
6 changed files with 281 additions and 281 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

112
bmad-core/templates/architecture-tmpl.yaml
View File

@ -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:

110
bmad-core/templates/brownfield-architecture-tmpl.yaml
View File

@ -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

68
bmad-core/templates/brownfield-prd-tmpl.yaml
View File

@ -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

52
bmad-core/templates/front-end-architecture-tmpl.yaml
View File

@ -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)

166
bmad-core/templates/fullstack-architecture-tmpl.yaml
View File

@ -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.

54
bmad-core/templates/prd-tmpl.yaml
View File

@ -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.