ros/BMAD-METHOD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

alpha build v4

Browse Source
This commit is contained in:
Brian Madison
2025-06-08 20:55:44 -05:00
parent 8ad54024d5
commit 5647fff955
22 changed files with 43031 additions and 7803 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
agent-teams/team-technical.yml
View File

@@ -5,6 +5,5 @@ bundle:
agents:
- bmad
- fullstack-architect
- devops
- ux-expert
- dev

1
agents/architect.yml
View File

@@ -13,7 +13,6 @@ dependencies:
- create-deep-research-prompt
templates:
- architecture-tmpl
- infrastructure-architecture-tmpl
- brownfield-architecture-tmpl
checklists:
- architect-checklist

28
agents/devops.yml
View File

@@ -1,28 +0,0 @@
agent:
name: Alex
id: devops
title: DevOps Platform Engineer
description: >-
Alex loves when things are running secure, stable, reliable and performant. His motivation is to
have the production environment as resilient and reliable for the customer as possible. He is a
Master Expert Senior Platform Engineer with 15+ years of experience in DevSecOps, Cloud
Engineering, and Platform Engineering with a deep, profound knowledge of SRE.
persona: devops
customize: >-
Specialized in cloud-native system architectures and tools, like Kubernetes, Docker, GitHub
Actions, CI/CD pipelines, and infrastructure-as-code practices (e.g., Terraform, CloudFormation,
Bicep, etc.).
dependencies:
tasks:
- create-doc-from-template
- infra/review-infrastructure
- infra/validate-infrastructure
templates:
- infrastructure-architecture-tmpl
- infrastructure-platform-from-arch-tmpl
checklists:
- infrastructure-checklist
data:
- technical-preferences
utils:
- template-format

3
agents/fullstack-architect.yml
View File

@@ -22,7 +22,8 @@ dependencies:
templates:
- architecture-tmpl
- front-end-architecture-tmpl
- infrastructure-architecture-tmpl
- fullstack-architecture-tmpl
- brownfield-architecture-tmpl
checklists:
- architect-checklist

37
web-bundles/agents/analyst.txt
View File

@@ -170,11 +170,11 @@ Confirm with the user their preferred interaction style:
### 4. Template Processing Rules
**CRITICAL: Never display template markup, LLM instructions, or examples to users**
#### CRITICAL: Never display template markup, LLM instructions, or examples to users
- Replace all {{placeholders}} with actual content
- Execute all [[LLM: instructions]] internally
- Process <<REPEAT>> sections as needed
- Process `<<REPEAT>>` sections as needed
- Evaluate ^^CONDITION^^ blocks and include only if applicable
- Use @{examples} for guidance but never output them
@@ -408,7 +408,9 @@ To perform deep research effectively, please be aware:
{Link to or summarize findings from any initial research conducted (e.g., `deep-research-report-BA.md`).}
## PM Prompt
## Next Steps
### PM Prompt
This Project Brief provides the full context for {Project Name}. Please start in 'PRD Generation Mode', review the brief thoroughly to work with the user to create the PRD section by section as the template indicates, asking for any necessary clarification or suggesting improvements as your mode 1 programming allows.
@@ -417,3 +419,32 @@ This Project Brief provides the full context for Mealmate. Please start in 'PRD
==================== END: templates#project-brief-tmpl ====================
==================== START: utils#template-format ====================
# Template Format Conventions
Templates in the BMAD method use standardized markup for AI processing. These conventions ensure consistent document generation.
## Template Markup Elements
- **{{placeholders}}**: Variables to be replaced with actual content
- **[[LLM: instructions]]**: Internal processing instructions for AI agents (never shown to users)
- **<<REPEAT>>** sections: Content blocks that may be repeated as needed
- **^^CONDITION^^** blocks: Conditional content included only if criteria are met
- **@{examples}**: Example content for guidance (never output to users)
## Processing Rules
- Replace all {{placeholders}} with project-specific content
- Execute all [[LLM: instructions]] internally without showing users
- Process conditional and repeat blocks as specified
- Use examples for guidance but never include them in final output
- Present only clean, formatted content to users
## Critical Guidelines
- **NEVER display template markup, LLM instructions, or examples to users**
- Template elements are for AI processing only
- Focus on faithful template execution and clean output
- All template-specific instructions are embedded within templates
==================== END: utils#template-format ====================

763
web-bundles/agents/architect.txt
View File

@@ -13,7 +13,7 @@ For system architecture, technical design, architecture checklists.
## Domain Expertise
### Core Architecture Design (90%+ confidence)
### Core Architecture Design
- **System Architecture & Design Patterns** - Microservices vs monolith decisions, event-driven architecture patterns, data flow and integration patterns, component relationships
- **Technology Selection & Standards** - Technology stack decisions and rationale, architectural standards and guidelines, vendor evaluation and selection
@@ -22,8 +22,7 @@ For system architecture, technical design, architecture checklists.
- **API & Integration Architecture** - API design standards and patterns, integration strategy across systems, event streaming vs RESTful patterns, service contracts
- **Enterprise Integration Architecture** - B2B integrations, external system connectivity, partner API strategies, legacy system integration patterns
### Strategic Architecture (70-90% confidence)
### Strategic Architecture
- **Data Architecture & Strategy** - Data modeling and storage strategy, data pipeline architecture (high-level), CQRS, event sourcing decisions, data governance
- **Multi-Cloud & Hybrid Architecture** - Cross-cloud strategies and patterns, hybrid cloud connectivity architecture, vendor lock-in mitigation strategies
@@ -34,7 +33,7 @@ For system architecture, technical design, architecture checklists.
- **AI/ML Architecture Strategy** - AI/ML system design patterns, model deployment architecture, data architecture for ML, AI governance frameworks
- **Distributed Systems Architecture** - Distributed system design, consistency models, CAP theorem applications
### Emerging Architecture (50-70% confidence)
### Emerging Architecture
- **Edge Computing and IoT** - Edge computing patterns, edge device integration, edge data processing strategies
- **Sustainability Architecture** - Green computing architecture, carbon-aware design, energy-efficient system patterns
@@ -121,11 +120,11 @@ Confirm with the user their preferred interaction style:
### 4. Template Processing Rules
**CRITICAL: Never display template markup, LLM instructions, or examples to users**
#### CRITICAL: Never display template markup, LLM instructions, or examples to users
- Replace all {{placeholders}} with actual content
- Execute all [[LLM: instructions]] internally
- Process <<REPEAT>> sections as needed
- Process `<<REPEAT>>` sections as needed
- Evaluate ^^CONDITION^^ blocks and include only if applicable
- Use @{examples} for guidance but never output them
@@ -506,7 +505,9 @@ To perform deep research effectively, please be aware:
## Introduction
[[LLM: This section establishes the document's purpose and scope. Keep the content below but ensure project name is properly substituted.]]
[[LLM: This section establishes the document's purpose and scope. Keep the content below but ensure project name is properly substituted.
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
This document outlines the overall project architecture for {{Project Name}}, including backend systems, shared services, and non-UI specific concerns. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development, ensuring consistency and adherence to chosen patterns and technologies.
@@ -548,7 +549,16 @@ If the project includes a significant user interface, a separate Frontend Archit
- Proceed with architecture design from scratch
- Note that manual setup will be required for all tooling and configuration
Document the decision here before proceeding with the architecture design. In none, just say N/A]]
Document the decision here before proceeding with the architecture design. In none, just say N/A
After presenting this starter template section, apply `tasks#advanced-elicitation` protocol]]
### Change Log
[[LLM: Track document versions and changes]]
| Date | Version | Description | Author |
| :--- | :------ | :---------- | :----- |
## High Level Architecture
@@ -844,7 +854,7 @@ servers:
^^/CONDITION: has_rest_api^^
[[LLM: After presenting the REST API spec (or skipping if not applicable), apply `tasks#advanced-elicitation` protocol]]
[[LLM: After presenting the REST API spec (or noting its absence if not applicable), apply `tasks#advanced-elicitation` protocol]]
## Database Schema
@@ -1213,16 +1223,6 @@ Note: Basic info goes in Coding Standards for dev agent. This detailed section i
[[LLM: After presenting the security section, apply `tasks#advanced-elicitation` protocol]]
## Change Log
[[LLM: Track document versions and changes]]
| Date | Version | Description | Author |
| :------- | :------ | :---------------------------- | :--------- |
| {{date}} | 1.0.0 | Initial architecture document | {{author}} |
---
## Checklist Results Report
[[LLM: Before running the checklist, offer to output the full architecture document. Once user confirms, execute the `architect-checklist` and populate results here.]]
@@ -1270,174 +1270,587 @@ Note: Basic info goes in Coding Standards for dev agent. This detailed section i
==================== END: templates#architecture-tmpl ====================
==================== START: templates#infrastructure-architecture-tmpl ====================
# {Project Name} Infrastructure Architecture
==================== START: templates#brownfield-architecture-tmpl ====================
# {{Project Name}} Brownfield Enhancement Architecture
## Infrastructure Overview
[[LLM: IMPORTANT - SCOPE AND ASSESSMENT REQUIRED:
- Cloud Provider(s)
- Core Services & Resources
- Regional Architecture
- Multi-environment Strategy
This architecture document is for SIGNIFICANT enhancements to existing projects that require comprehensive architectural planning. Before proceeding:
## Infrastructure as Code (IaC)
1. **Verify Complexity**: Confirm this enhancement requires architectural planning. For simple additions, recommend: "For simpler changes that don't require architectural planning, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead."
- Tools & Frameworks
- Repository Structure
- State Management
- Dependency Management
2. **REQUIRED INPUTS**:
## Environment Configuration
- Completed brownfield-prd.md
- Existing project technical documentation (from docs folder or user-provided)
- Access to existing project structure (IDE or uploaded files)
- Environment Promotion Strategy
- Configuration Management
- Secret Management
- Feature Flag Integration
3. **DEEP ANALYSIS MANDATE**: You MUST conduct thorough analysis of the existing codebase, architecture patterns, and technical constraints before making ANY architectural recommendations. Every suggestion must be based on actual project analysis, not assumptions.
## Environment Transition Strategy
4. **CONTINUOUS VALIDATION**: Throughout this process, explicitly validate your understanding with the user. For every architectural decision, confirm: "Based on my analysis of your existing system, I recommend [decision] because [evidence from actual project]. Does this align with your system's reality?"
- Development to Production Pipeline
- Deployment Stages and Gates
- Approval Workflows and Authorities
- Rollback Procedures
- Change Cadence and Release Windows
- Environment-Specific Configuration Management
If any required inputs are missing, request them before proceeding.]]
## Network Architecture
## Introduction
- VPC/VNET Design
- Subnet Strategy
- Security Groups & NACLs
- Load Balancers & API Gateways
- Service Mesh (if applicable)
[[LLM: This section establishes the document's purpose and scope for brownfield enhancements. Keep the content below but ensure project name and enhancement details are properly substituted.
## Compute Resources
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
- Container Strategy
- Serverless Architecture
- VM/Instance Configuration
- Auto-scaling Approach
This document outlines the architectural approach for enhancing {{Project Name}} with {{Enhancement Description}}. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development of new features while ensuring seamless integration with the existing system.
## Data Resources
**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.
- Database Deployment Strategy
- Backup & Recovery
- Replication & Failover
- Data Migration Strategy
### Existing Project Analysis
## Security Architecture
[[LLM: Analyze the existing project structure and architecture:
- IAM & Authentication
- Network Security
- Data Encryption
- Compliance Controls
- Security Scanning & Monitoring
1. Review existing documentation in docs folder
2. Examine current technology stack and versions
3. Identify existing architectural patterns and conventions
4. Note current deployment and infrastructure setup
5. Document any constraints or limitations
## Shared Responsibility Model
CRITICAL: After your analysis, explicitly validate your findings: "Based on my analysis of your project, I've identified the following about your existing system: [key findings]. Please confirm these observations are accurate before I proceed with architectural recommendations."
- Cloud Provider Responsibilities
- Platform Team Responsibilities
- Development Team Responsibilities
- Security Team Responsibilities
- Operational Monitoring Ownership
- Incident Response Accountability Matrix
Present findings and apply `tasks#advanced-elicitation` protocol]]
## Monitoring & Observability
**Current Project State:**
- Metrics Collection
- Logging Strategy
- Tracing Implementation
- Alerting & Incident Response
- Dashboards & Visualization
- **Primary Purpose:** {{existing_project_purpose}}
- **Current Tech Stack:** {{existing_tech_summary}}
- **Architecture Style:** {{existing_architecture_style}}
- **Deployment Method:** {{existing_deployment_approach}}
## CI/CD Pipeline
**Available Documentation:**
- Pipeline Architecture
- Build Process
- Deployment Strategy
- Rollback Procedures
- Approval Gates
- {{existing_docs_summary}}
## Disaster Recovery
**Identified Constraints:**
- Backup Strategy
- Recovery Procedures
- RTO & RPO Targets
- DR Testing Approach
- {{constraint_1}}
- {{constraint_2}}
- {{constraint_3}}
## Cost Optimization
### Change Log
- Resource Sizing Strategy
- Reserved Instances/Commitments
- Cost Monitoring & Reporting
- Optimization Recommendations
| Change | Date | Version | Description | Author |
| ------ | ---- | ------- | ----------- | ------ |
## Infrastructure Verification
## Enhancement Scope and Integration Strategy
### Validation Framework
[[LLM: Define how the enhancement will integrate with the existing system:
This infrastructure architecture will be validated using the comprehensive `infrastructure-checklist.md`, with particular focus on Section 12: Architecture Documentation Validation. The checklist ensures:
1. Review the brownfield PRD enhancement scope
2. Identify integration points with existing code
3. Define boundaries between new and existing functionality
4. Establish compatibility requirements
- Completeness of architecture documentation
- Consistency with broader system architecture
- Appropriate level of detail for different stakeholders
- Clear implementation guidance
- Future evolution considerations
VALIDATION CHECKPOINT: Before presenting the integration strategy, confirm: "Based on my analysis, the integration approach I'm proposing takes into account [specific existing system characteristics]. These integration points and boundaries respect your current architecture patterns. Is this assessment accurate?"
### Validation Process
Present complete integration strategy and apply `tasks#advanced-elicitation` protocol]]
The architecture documentation validation should be performed:
### Enhancement Overview
- After initial architecture development
- After significant architecture changes
- Before major implementation phases
- During periodic architecture reviews
**Enhancement Type:** {{enhancement_type}}
**Scope:** {{enhancement_scope}}
**Integration Impact:** {{integration_impact_level}}
The Platform Engineer should use the infrastructure checklist to systematically validate all aspects of this architecture document.
### Integration Approach
## Infrastructure Evolution
**Code Integration Strategy:** {{code_integration_approach}}
**Database Integration:** {{database_integration_approach}}
**API Integration:** {{api_integration_approach}}
**UI Integration:** {{ui_integration_approach}}
- Technical Debt Inventory
- Planned Upgrades and Migrations
- Deprecation Schedule
- Technology Roadmap
- Capacity Planning
- Scalability Considerations
### Compatibility Requirements
## Integration with Application Architecture
- **Existing API Compatibility:** {{api_compatibility}}
- **Database Schema Compatibility:** {{db_compatibility}}
- **UI/UX Consistency:** {{ui_compatibility}}
- **Performance Impact:** {{performance_constraints}}
- Service-to-Infrastructure Mapping
- Application Dependency Matrix
- Performance Requirements Implementation
- Security Requirements Implementation
- Data Flow to Infrastructure Correlation
- API Gateway and Service Mesh Integration
## Tech Stack Alignment
## Cross-Team Collaboration
[[LLM: Ensure new components align with existing technology choices:
- Platform Engineer and Developer Touchpoints
- Frontend/Backend Integration Requirements
- Product Requirements to Infrastructure Mapping
- Architecture Decision Impact Analysis
- Design Architect UI/UX Infrastructure Requirements
- Analyst Research Integration
1. Use existing technology stack as the foundation
2. Only introduce new technologies if absolutely necessary
3. Justify any new additions with clear rationale
4. Ensure version compatibility with existing dependencies
## Infrastructure Change Management
Present complete tech stack alignment and apply `tasks#advanced-elicitation` protocol]]
- Change Request Process
- Risk Assessment
- Testing Strategy
- Validation Procedures
### Existing Technology Stack
==================== END: templates#infrastructure-architecture-tmpl ====================
[[LLM: Document the current stack that must be maintained or integrated with]]
| Category | Current Technology | Version | Usage in Enhancement | Notes |
| :----------------- | :----------------- | :---------- | :------------------- | :-------- |
| **Language** | {{language}} | {{version}} | {{usage}} | {{notes}} |
| **Runtime** | {{runtime}} | {{version}} | {{usage}} | {{notes}} |
| **Framework** | {{framework}} | {{version}} | {{usage}} | {{notes}} |
| **Database** | {{database}} | {{version}} | {{usage}} | {{notes}} |
| **API Style** | {{api_style}} | {{version}} | {{usage}} | {{notes}} |
| **Authentication** | {{auth}} | {{version}} | {{usage}} | {{notes}} |
| **Testing** | {{test_framework}} | {{version}} | {{usage}} | {{notes}} |
| **Build Tool** | {{build_tool}} | {{version}} | {{usage}} | {{notes}} |
### New Technology Additions
[[LLM: Only include if new technologies are required for the enhancement]]
^^CONDITION: has_new_tech^^
| Technology | Version | Purpose | Rationale | Integration Method |
| :----------- | :---------- | :---------- | :------------ | :----------------- |
| {{new_tech}} | {{version}} | {{purpose}} | {{rationale}} | {{integration}} |
^^/CONDITION: has_new_tech^^
## Data Models and Schema Changes
[[LLM: Define new data models and how they integrate with existing schema:
1. Identify new entities required for the enhancement
2. Define relationships with existing data models
3. Plan database schema changes (additions, modifications)
4. Ensure backward compatibility
Present data model changes and apply `tasks#advanced-elicitation` protocol]]
### New Data Models
<<REPEAT: new_data_model>>
### {{model_name}}
**Purpose:** {{model_purpose}}
**Integration:** {{integration_with_existing}}
**Key Attributes:**
- {{attribute_1}}: {{type_1}} - {{description_1}}
- {{attribute_2}}: {{type_2}} - {{description_2}}
**Relationships:**
- **With Existing:** {{existing_relationships}}
- **With New:** {{new_relationships}}
<</REPEAT>>
### Schema Integration Strategy
**Database Changes Required:**
- **New Tables:** {{new_tables_list}}
- **Modified Tables:** {{modified_tables_list}}
- **New Indexes:** {{new_indexes_list}}
- **Migration Strategy:** {{migration_approach}}
**Backward Compatibility:**
- {{compatibility_measure_1}}
- {{compatibility_measure_2}}
## Component Architecture
[[LLM: Define new components and their integration with existing architecture:
1. Identify new components required for the enhancement
2. Define interfaces with existing components
3. Establish clear boundaries and responsibilities
4. Plan integration points and data flow
MANDATORY VALIDATION: Before presenting component architecture, confirm: "The new components I'm proposing follow the existing architectural patterns I identified in your codebase: [specific patterns]. The integration interfaces respect your current component structure and communication patterns. Does this match your project's reality?"
Present component architecture and apply `tasks#advanced-elicitation` protocol]]
### New Components
<<REPEAT: new_component>>
### {{component_name}}
**Responsibility:** {{component_description}}
**Integration Points:** {{integration_points}}
**Key Interfaces:**
- {{interface_1}}
- {{interface_2}}
**Dependencies:**
- **Existing Components:** {{existing_dependencies}}
- **New Components:** {{new_dependencies}}
**Technology Stack:** {{component_tech_details}}
<</REPEAT>>
### Component Interaction Diagram
[[LLM: Create Mermaid diagram showing how new components interact with existing ones]]
```mermaid
{{component_interaction_diagram}}
```
## API Design and Integration
[[LLM: Define new API endpoints and integration with existing APIs:
1. Plan new API endpoints required for the enhancement
2. Ensure consistency with existing API patterns
3. Define authentication and authorization integration
4. Plan versioning strategy if needed
Present API design and apply `tasks#advanced-elicitation` protocol]]
### New API Endpoints
^^CONDITION: has_new_api^^
**API Integration Strategy:** {{api_integration_strategy}}
**Authentication:** {{auth_integration}}
**Versioning:** {{versioning_approach}}
<<REPEAT: new_endpoint>>
#### {{endpoint_name}}
- **Method:** {{http_method}}
- **Endpoint:** {{endpoint_path}}
- **Purpose:** {{endpoint_purpose}}
- **Integration:** {{integration_with_existing}}
**Request:**
```json
{{request_schema}}
```
**Response:**
```json
{{response_schema}}
```
<</REPEAT>>
^^/CONDITION: has_new_api^^
## External API Integration
[[LLM: Document new external API integrations required for the enhancement]]
^^CONDITION: has_new_external_apis^^
<<REPEAT: external_api>>
### {{api_name}} API
- **Purpose:** {{api_purpose}}
- **Documentation:** {{api_docs_url}}
- **Base URL:** {{api_base_url}}
- **Authentication:** {{auth_method}}
- **Integration Method:** {{integration_approach}}
**Key Endpoints Used:**
- `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
**Error Handling:** {{error_handling_strategy}}
<</REPEAT>>
^^/CONDITION: has_new_external_apis^^
## Source Tree Integration
[[LLM: Define how new code will integrate with existing project structure:
1. Follow existing project organization patterns
2. Identify where new files/folders will be placed
3. Ensure consistency with existing naming conventions
4. Plan for minimal disruption to existing structure
Present integration plan and apply `tasks#advanced-elicitation` protocol]]
### Existing Project Structure
[[LLM: Document relevant parts of current structure]]
```plaintext
{{existing_structure_relevant_parts}}
```
### New File Organization
[[LLM: Show only new additions to existing structure]]
```plaintext
{{project-root}}/
├── {{existing_structure_context}}
│ ├── {{new_folder_1}}/ # {{purpose_1}}
│ │ ├── {{new_file_1}}
│ │ └── {{new_file_2}}
│ ├── {{existing_folder}}/ # Existing folder with additions
│ │ ├── {{existing_file}} # Existing file
│ │ └── {{new_file_3}} # New addition
│ └── {{new_folder_2}}/ # {{purpose_2}}
```
### Integration Guidelines
- **File Naming:** {{file_naming_consistency}}
- **Folder Organization:** {{folder_organization_approach}}
- **Import/Export Patterns:** {{import_export_consistency}}
## Infrastructure and Deployment Integration
[[LLM: Define how the enhancement will be deployed alongside existing infrastructure:
1. Use existing deployment pipeline and infrastructure
2. Identify any infrastructure changes needed
3. Plan deployment strategy to minimize risk
4. Define rollback procedures
Present deployment integration and apply `tasks#advanced-elicitation` protocol]]
### Existing Infrastructure
**Current Deployment:** {{existing_deployment_summary}}
**Infrastructure Tools:** {{existing_infrastructure_tools}}
**Environments:** {{existing_environments}}
### Enhancement Deployment Strategy
**Deployment Approach:** {{deployment_approach}}
**Infrastructure Changes:** {{infrastructure_changes}}
**Pipeline Integration:** {{pipeline_integration}}
### Rollback Strategy
**Rollback Method:** {{rollback_method}}
**Risk Mitigation:** {{risk_mitigation}}
**Monitoring:** {{monitoring_approach}}
## Coding Standards and Conventions
[[LLM: Ensure new code follows existing project conventions:
1. Document existing coding standards from project analysis
2. Identify any enhancement-specific requirements
3. Ensure consistency with existing codebase patterns
4. Define standards for new code organization
Present coding standards and apply `tasks#advanced-elicitation` protocol]]
### Existing Standards Compliance
**Code Style:** {{existing_code_style}}
**Linting Rules:** {{existing_linting}}
**Testing Patterns:** {{existing_test_patterns}}
**Documentation Style:** {{existing_doc_style}}
### Enhancement-Specific Standards
[[LLM: Only include if new patterns are needed for the enhancement]]
<<REPEAT: enhancement_standard>>
- **{{standard_name}}:** {{standard_description}}
<</REPEAT>>
### Critical Integration Rules
- **Existing API Compatibility:** {{api_compatibility_rule}}
- **Database Integration:** {{db_integration_rule}}
- **Error Handling:** {{error_handling_integration}}
- **Logging Consistency:** {{logging_consistency}}
## Testing Strategy
[[LLM: Define testing approach for the enhancement:
1. Integrate with existing test suite
2. Ensure existing functionality remains intact
3. Plan for testing new features
4. Define integration testing approach
Present testing strategy and apply `tasks#advanced-elicitation` protocol]]
### Integration with Existing Tests
**Existing Test Framework:** {{existing_test_framework}}
**Test Organization:** {{existing_test_organization}}
**Coverage Requirements:** {{existing_coverage_requirements}}
### New Testing Requirements
#### Unit Tests for New Components
- **Framework:** {{test_framework}}
- **Location:** {{test_location}}
- **Coverage Target:** {{coverage_target}}
- **Integration with Existing:** {{test_integration}}
#### Integration Tests
- **Scope:** {{integration_test_scope}}
- **Existing System Verification:** {{existing_system_verification}}
- **New Feature Testing:** {{new_feature_testing}}
#### Regression Testing
- **Existing Feature Verification:** {{regression_test_approach}}
- **Automated Regression Suite:** {{automated_regression}}
- **Manual Testing Requirements:** {{manual_testing_requirements}}
## Security Integration
[[LLM: Ensure security consistency with existing system:
1. Follow existing security patterns and tools
2. Ensure new features don't introduce vulnerabilities
3. Maintain existing security posture
4. Define security testing for new components
Present security integration and apply `tasks#advanced-elicitation` protocol]]
### Existing Security Measures
**Authentication:** {{existing_auth}}
**Authorization:** {{existing_authz}}
**Data Protection:** {{existing_data_protection}}
**Security Tools:** {{existing_security_tools}}
### Enhancement Security Requirements
**New Security Measures:** {{new_security_measures}}
**Integration Points:** {{security_integration_points}}
**Compliance Requirements:** {{compliance_requirements}}
### Security Testing
**Existing Security Tests:** {{existing_security_tests}}
**New Security Test Requirements:** {{new_security_tests}}
**Penetration Testing:** {{pentest_requirements}}
## Risk Assessment and Mitigation
[[LLM: Identify and plan for risks specific to brownfield development:
1. Technical integration risks
2. Deployment and operational risks
3. User impact and compatibility risks
4. Mitigation strategies for each risk
Present risk assessment and apply `tasks#advanced-elicitation` protocol]]
### Technical Risks
<<REPEAT: technical_risk>>
**Risk:** {{risk_description}}
**Impact:** {{impact_level}}
**Likelihood:** {{likelihood}}
**Mitigation:** {{mitigation_strategy}}
<</REPEAT>>
### Operational Risks
<<REPEAT: operational_risk>>
**Risk:** {{risk_description}}
**Impact:** {{impact_level}}
**Likelihood:** {{likelihood}}
**Mitigation:** {{mitigation_strategy}}
<</REPEAT>>
### Monitoring and Alerting
**Enhanced Monitoring:** {{monitoring_additions}}
**New Alerts:** {{new_alerts}}
**Performance Monitoring:** {{performance_monitoring}}
## Checklist Results Report
[[LLM: Execute the architect-checklist and populate results here, focusing on brownfield-specific validation]]
## Next Steps
[[LLM: After completing the brownfield architecture:
1. Review integration points with existing system
2. Begin story implementation with Dev agent
3. Set up deployment pipeline integration
4. Plan rollback and monitoring procedures]]
### Story Manager Handoff
[[LLM: Create a brief prompt for Story Manager to work with this brownfield enhancement. Include:
- Reference to this architecture document
- Key integration requirements validated with user
- Existing system constraints based on actual project analysis
- First story to implement with clear integration checkpoints
- Emphasis on maintaining existing system integrity throughout implementation]]
### Developer Handoff
[[LLM: Create a brief prompt for developers starting implementation. Include:
- Reference to this architecture and existing coding standards analyzed from actual project
- Integration requirements with existing codebase validated with user
- Key technical decisions based on real project constraints
- Existing system compatibility requirements with specific verification steps
- Clear sequencing of implementation to minimize risk to existing functionality]]
==================== END: templates#brownfield-architecture-tmpl ====================
==================== START: checklists#architect-checklist ====================
# Architect Solution Validation Checklist
This checklist serves as a comprehensive framework for the Architect to validate the technical design and architecture before development execution. The Architect should systematically work through each item, ensuring the architecture is robust, scalable, secure, and aligned with the product requirements.
[[LLM: INITIALIZATION INSTRUCTIONS - REQUIRED ARTIFACTS
Before proceeding with this checklist, ensure you have access to:
1. architecture.md - The primary architecture document (check docs/architecture.md)
2. prd.md - Product Requirements Document for requirements alignment (check docs/prd.md)
3. Any system diagrams referenced in the architecture
4. API documentation if available
5. Technology stack details and version specifications
IMPORTANT: If any required documents are missing or inaccessible, immediately ask the user for their location or content before proceeding.
VALIDATION APPROACH:
For each section, you must:
1. Deep Analysis - Don't just check boxes, thoroughly analyze each item against the provided documentation
2. Evidence-Based - Cite specific sections or quotes from the documents when validating
3. Critical Thinking - Question assumptions and identify gaps, not just confirm what's present
4. Risk Assessment - Consider what could go wrong with each architectural decision
EXECUTION MODE:
Ask the user if they want to work through the checklist:
- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
## 1. REQUIREMENTS ALIGNMENT
[[LLM: Before evaluating this section, take a moment to fully understand the product's purpose and goals from the PRD. What is the core problem being solved? Who are the users? What are the critical success factors? Keep these in mind as you validate alignment. For each item, don't just check if it's mentioned - verify that the architecture provides a concrete technical solution.]]
### 1.1 Functional Requirements Coverage
- [ ] Architecture supports all functional requirements in the PRD
@@ -1464,6 +1877,8 @@ This checklist serves as a comprehensive framework for the Architect to validate
## 2. ARCHITECTURE FUNDAMENTALS
[[LLM: Architecture clarity is crucial for successful implementation. As you review this section, visualize the system as if you were explaining it to a new developer. Are there any ambiguities that could lead to misinterpretation? Would an AI agent be able to implement this architecture without confusion? Look for specific diagrams, component definitions, and clear interaction patterns.]]
### 2.1 Architecture Clarity
- [ ] Architecture is documented with clear diagrams
@@ -1498,6 +1913,8 @@ This checklist serves as a comprehensive framework for the Architect to validate
## 3. TECHNICAL STACK & DECISIONS
[[LLM: Technology choices have long-term implications. For each technology decision, consider: Is this the simplest solution that could work? Are we over-engineering? Will this scale? What are the maintenance implications? Are there security vulnerabilities in the chosen versions? Verify that specific versions are defined, not ranges.]]
### 3.1 Technology Selection
- [ ] Selected technologies meet all requirements
@@ -1532,6 +1949,8 @@ This checklist serves as a comprehensive framework for the Architect to validate
## 4. RESILIENCE & OPERATIONAL READINESS
[[LLM: Production systems fail in unexpected ways. As you review this section, think about Murphy's Law - what could go wrong? Consider real-world scenarios: What happens during peak load? How does the system behave when a critical service is down? Can the operations team diagnose issues at 3 AM? Look for specific resilience patterns, not just mentions of "error handling".]]
### 4.1 Error Handling & Resilience
- [ ] Error handling strategy is comprehensive
@@ -1566,6 +1985,8 @@ This checklist serves as a comprehensive framework for the Architect to validate
## 5. SECURITY & COMPLIANCE
[[LLM: Security is not optional. Review this section with a hacker's mindset - how could someone exploit this system? Also consider compliance: Are there industry-specific regulations that apply? GDPR? HIPAA? PCI? Ensure the architecture addresses these proactively. Look for specific security controls, not just general statements.]]
### 5.1 Authentication & Authorization
- [ ] Authentication mechanism is clearly defined
@@ -1600,6 +2021,8 @@ This checklist serves as a comprehensive framework for the Architect to validate
## 6. IMPLEMENTATION GUIDANCE
[[LLM: Clear implementation guidance prevents costly mistakes. As you review this section, imagine you're a developer starting on day one. Do they have everything they need to be productive? Are coding standards clear enough to maintain consistency across the team? Look for specific examples and patterns.]]
### 6.1 Coding Standards & Practices
- [ ] Coding standards are defined
@@ -1634,6 +2057,8 @@ This checklist serves as a comprehensive framework for the Architect to validate
## 7. DEPENDENCY & INTEGRATION MANAGEMENT
[[LLM: Dependencies are often the source of production issues. For each dependency, consider: What happens if it's unavailable? Is there a newer version with security patches? Are we locked into a vendor? What's our contingency plan? Verify specific versions and fallback strategies.]]
### 7.1 External Dependencies
- [ ] All external dependencies are identified
@@ -1660,6 +2085,8 @@ This checklist serves as a comprehensive framework for the Architect to validate
## 8. AI AGENT IMPLEMENTATION SUITABILITY
[[LLM: This architecture may be implemented by AI agents. Review with extreme clarity in mind. Are patterns consistent? Is complexity minimized? Would an AI agent make incorrect assumptions? Remember: explicit is better than implicit. Look for clear file structures, naming conventions, and implementation patterns.]]
### 8.1 Modularity for AI Agents
- [ ] Components are sized appropriately for AI agent implementation
@@ -1692,6 +2119,41 @@ This checklist serves as a comprehensive framework for the Architect to validate
- [ ] Testing patterns are clearly defined
- [ ] Debugging guidance is provided
[[LLM: FINAL VALIDATION REPORT GENERATION
Now that you've completed the checklist, generate a comprehensive validation report that includes:
1. Executive Summary
- Overall architecture readiness (High/Medium/Low)
- Critical risks identified
- Key strengths of the architecture
2. Section Analysis
- Pass rate for each major section (percentage of items passed)
- Most concerning failures or gaps
- Sections requiring immediate attention
3. Risk Assessment
- Top 5 risks by severity
- Mitigation recommendations for each
- Timeline impact of addressing issues
4. Recommendations
- Must-fix items before development
- Should-fix items for better quality
- Nice-to-have improvements
5. AI Implementation Readiness
- Specific concerns for AI agent implementation
- Areas needing additional clarification
- Complexity hotspots to address
After presenting the report, ask the user if they would like detailed analysis of any specific section, especially those with warnings or failures.]]
==================== END: checklists#architect-checklist ====================
==================== START: data#technical-preferences ====================
@@ -1701,3 +2163,32 @@ None Listed
==================== END: data#technical-preferences ====================
==================== START: utils#template-format ====================
# Template Format Conventions
Templates in the BMAD method use standardized markup for AI processing. These conventions ensure consistent document generation.
## Template Markup Elements
- **{{placeholders}}**: Variables to be replaced with actual content
- **[[LLM: instructions]]**: Internal processing instructions for AI agents (never shown to users)
- **<<REPEAT>>** sections: Content blocks that may be repeated as needed
- **^^CONDITION^^** blocks: Conditional content included only if criteria are met
- **@{examples}**: Example content for guidance (never output to users)
## Processing Rules
- Replace all {{placeholders}} with project-specific content
- Execute all [[LLM: instructions]] internally without showing users
- Process conditional and repeat blocks as specified
- Use examples for guidance but never include them in final output
- Present only clean, formatted content to users
## Critical Guidelines
- **NEVER display template markup, LLM instructions, or examples to users**
- Template elements are for AI processing only
- Focus on faithful template execution and clean output
- All template-specific instructions are embedded within templates
==================== END: utils#template-format ====================

1064
web-bundles/agents/bmad.txt
View File

File diff suppressed because it is too large Load Diff

74
web-bundles/agents/dev.txt
View File

@@ -37,15 +37,35 @@ Master Generalist Expert Senior Senior Full Stack Developer
Before marking a story as 'Review', please go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
[[LLM: INITIALIZATION INSTRUCTIONS - STORY DOD VALIDATION
This checklist is for DEVELOPER AGENTS to self-validate their work before marking a story complete.
IMPORTANT: This is a self-assessment. Be honest about what's actually done vs what should be done. It's better to identify issues now than have them found in review.
EXECUTION APPROACH:
1. Go through each section systematically
2. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
3. Add brief comments explaining any [ ] or [N/A] items
4. Be specific about what was actually implemented
5. Flag any concerns or technical debt created
The goal is quality delivery, not just checking boxes.]]
## Checklist Items
1. **Requirements Met:**
[[LLM: Be specific - list each requirement and whether it's complete]]
- [ ] All functional requirements specified in the story are implemented.
- [ ] All acceptance criteria defined in the story are met.
2. **Coding Standards & Project Structure:**
[[LLM: Code quality matters for maintainability. Check each item carefully]]
- [ ] All new/modified code strictly adheres to `Operational Guidelines`.
- [ ] All new/modified code aligns with `Project Structure` (file locations, naming, etc.).
- [ ] Adherence to `Tech Stack` for technologies/versions used (if story introduces or modifies tech usage).
@@ -56,6 +76,8 @@ Before marking a story as 'Review', please go through each item in this checklis
3. **Testing:**
[[LLM: Testing proves your code works. Be honest about test coverage]]
- [ ] All required unit tests as per the story and `Operational Guidelines` Testing Strategy are implemented.
- [ ] All required integration tests (if applicable) as per the story and `Operational Guidelines` Testing Strategy are implemented.
- [ ] All tests (unit, integration, E2E if applicable) pass successfully.
@@ -63,15 +85,23 @@ Before marking a story as 'Review', please go through each item in this checklis
4. **Functionality & Verification:**
[[LLM: Did you actually run and test your code? Be specific about what you tested]]
- [ ] Functionality has been manually verified by the developer (e.g., running the app locally, checking UI, testing API endpoints).
- [ ] Edge cases and potential error conditions considered and handled gracefully.
5. **Story Administration:**
[[LLM: Documentation helps the next developer. What should they know?]]
- [ ] All tasks within the story file are marked as complete.
- [ ] Any clarifications or decisions made during development are documented in the story file or linked appropriately.
- [ ] The story wrap up section has been completed with notes of changes or information relevant to the next story or overall project, the agent model that was primarily used during development, and the changelog of any changes is properly updated.
6. **Dependencies, Build & Configuration:**
[[LLM: Build issues block everyone. Ensure everything compiles and runs cleanly]]
- [ ] Project builds successfully without errors.
- [ ] Project linting passes
- [ ] Any new dependencies added were either pre-approved in the story requirements OR explicitly approved by the user during development (approval documented in story file).
@@ -80,12 +110,27 @@ Before marking a story as 'Review', please go through each item in this checklis
- [ ] If new environment variables or configurations were introduced by the story, they are documented and handled securely.
7. **Documentation (If Applicable):**
[[LLM: Good documentation prevents future confusion. What needs explaining?]]
- [ ] Relevant inline code documentation (e.g., JSDoc, TSDoc, Python docstrings) for new public APIs or complex logic is complete.
- [ ] User-facing documentation updated, if changes impact users.
- [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.
## Final Confirmation
[[LLM: FINAL DOD SUMMARY
After completing the checklist:
1. Summarize what was accomplished in this story
2. List any items marked as [ ] Not Done with explanations
3. Identify any technical debt or follow-up work needed
4. Note any challenges or learnings for future stories
5. Confirm whether the story is truly ready for review
Be honest - it's better to flag issues now than have them discovered later.]]
- [ ] I, the Developer Agent, confirm that all applicable items above have been addressed.
==================== END: checklists#story-dod-checklist ====================
@@ -97,3 +142,32 @@ None Listed
==================== END: data#technical-preferences ====================
==================== START: utils#template-format ====================
# Template Format Conventions
Templates in the BMAD method use standardized markup for AI processing. These conventions ensure consistent document generation.
## Template Markup Elements
- **{{placeholders}}**: Variables to be replaced with actual content
- **[[LLM: instructions]]**: Internal processing instructions for AI agents (never shown to users)
- **<<REPEAT>>** sections: Content blocks that may be repeated as needed
- **^^CONDITION^^** blocks: Conditional content included only if criteria are met
- **@{examples}**: Example content for guidance (never output to users)
## Processing Rules
- Replace all {{placeholders}} with project-specific content
- Execute all [[LLM: instructions]] internally without showing users
- Process conditional and repeat blocks as specified
- Use examples for guidance but never include them in final output
- Present only clean, formatted content to users
## Critical Guidelines
- **NEVER display template markup, LLM instructions, or examples to users**
- Template elements are for AI processing only
- Focus on faithful template execution and clean output
- All template-specific instructions are embedded within templates
==================== END: utils#template-format ====================

1322
web-bundles/agents/devops.txt
View File

File diff suppressed because it is too large Load Diff

4981
web-bundles/agents/fullstack-architect.txt Normal file
View File

File diff suppressed because it is too large Load Diff

862
web-bundles/agents/pm.txt
View File

@@ -70,11 +70,11 @@ Confirm with the user their preferred interaction style:
### 4. Template Processing Rules
**CRITICAL: Never display template markup, LLM instructions, or examples to users**
#### CRITICAL: Never display template markup, LLM instructions, or examples to users
- Replace all {{placeholders}} with actual content
- Execute all [[LLM: instructions]] internally
- Process <<REPEAT>> sections as needed
- Process `<<REPEAT>>` sections as needed
- Evaluate ^^CONDITION^^ blocks and include only if applicable
- Use @{examples} for guidance but never output them
@@ -244,6 +244,348 @@ To perform deep research effectively, please be aware:
==================== END: tasks#create-deep-research-prompt ====================
==================== START: tasks#brownfield-create-epic ====================
# Create Brownfield Epic Task
## Purpose
Create a single epic for smaller brownfield enhancements that don't require the full PRD and Architecture documentation process. This task is for isolated features or modifications that can be completed within a focused scope.
## When to Use This Task
**Use this task when:**
- The enhancement can be completed in 1-3 stories
- No significant architectural changes are required
- The enhancement follows existing project patterns
- Integration complexity is minimal
- Risk to existing system is low
**Use the full brownfield PRD/Architecture process when:**
- The enhancement requires multiple coordinated stories
- Architectural planning is needed
- Significant integration work is required
- Risk assessment and mitigation planning is necessary
## Instructions
### 1. Project Analysis (Required)
Before creating the epic, gather essential information about the existing project:
**Existing Project Context:**
- [ ] Project purpose and current functionality understood
- [ ] Existing technology stack identified
- [ ] Current architecture patterns noted
- [ ] Integration points with existing system identified
**Enhancement Scope:**
- [ ] Enhancement clearly defined and scoped
- [ ] Impact on existing functionality assessed
- [ ] Required integration points identified
- [ ] Success criteria established
### 2. Epic Creation
Create a focused epic following this structure:
#### Epic Title
{{Enhancement Name}} - Brownfield Enhancement
#### Epic Goal
{{1-2 sentences describing what the epic will accomplish and why it adds value}}
#### Epic Description
**Existing System Context:**
- Current relevant functionality: {{brief description}}
- Technology stack: {{relevant existing technologies}}
- Integration points: {{where new work connects to existing system}}
**Enhancement Details:**
- What's being added/changed: {{clear description}}
- How it integrates: {{integration approach}}
- Success criteria: {{measurable outcomes}}
#### Stories
List 1-3 focused stories that complete the epic:
1. **Story 1:** {{Story title and brief description}}
2. **Story 2:** {{Story title and brief description}}
3. **Story 3:** {{Story title and brief description}}
#### Compatibility Requirements
- [ ] Existing APIs remain unchanged
- [ ] Database schema changes are backward compatible
- [ ] UI changes follow existing patterns
- [ ] Performance impact is minimal
#### Risk Mitigation
- **Primary Risk:** {{main risk to existing system}}
- **Mitigation:** {{how risk will be addressed}}
- **Rollback Plan:** {{how to undo changes if needed}}
#### Definition of Done
- [ ] All stories completed with acceptance criteria met
- [ ] Existing functionality verified through testing
- [ ] Integration points working correctly
- [ ] Documentation updated appropriately
- [ ] No regression in existing features
### 3. Validation Checklist
Before finalizing the epic, ensure:
**Scope Validation:**
- [ ] Epic can be completed in 1-3 stories maximum
- [ ] No architectural documentation is required
- [ ] Enhancement follows existing patterns
- [ ] Integration complexity is manageable
**Risk Assessment:**
- [ ] Risk to existing system is low
- [ ] Rollback plan is feasible
- [ ] Testing approach covers existing functionality
- [ ] Team has sufficient knowledge of integration points
**Completeness Check:**
- [ ] Epic goal is clear and achievable
- [ ] Stories are properly scoped
- [ ] Success criteria are measurable
- [ ] Dependencies are identified
### 4. Handoff to Story Manager
Once the epic is validated, provide this handoff to the Story Manager:
---
**Story Manager Handoff:**
"Please develop detailed user stories for this brownfield epic. Key considerations:
- This is an enhancement to an existing system running {{technology stack}}
- Integration points: {{list key integration points}}
- Existing patterns to follow: {{relevant existing patterns}}
- Critical compatibility requirements: {{key requirements}}
- Each story must include verification that existing functionality remains intact
The epic should maintain system integrity while delivering {{epic goal}}."
---
## Success Criteria
The epic creation is successful when:
1. Enhancement scope is clearly defined and appropriately sized
2. Integration approach respects existing system architecture
3. Risk to existing functionality is minimized
4. Stories are logically sequenced for safe implementation
5. Compatibility requirements are clearly specified
6. Rollback plan is feasible and documented
## Important Notes
- This task is specifically for SMALL brownfield enhancements
- If the scope grows beyond 3 stories, consider the full brownfield PRD process
- Always prioritize existing system integrity over new functionality
- When in doubt about scope or complexity, escalate to full brownfield planning
==================== END: tasks#brownfield-create-epic ====================
==================== START: tasks#brownfield-create-story ====================
# Create Brownfield Story Task
## Purpose
Create a single user story for very small brownfield enhancements that can be completed in one focused development session. This task is for minimal additions or bug fixes that require existing system integration awareness.
## When to Use This Task
**Use this task when:**
- The enhancement can be completed in a single story (2-4 hours of focused work)
- No new architecture or significant design is required
- The change follows existing patterns exactly
- Integration is straightforward with minimal risk
- Change is isolated with clear boundaries
**Use brownfield-create-epic when:**
- The enhancement requires 2-3 coordinated stories
- Some design work is needed
- Multiple integration points are involved
**Use the full brownfield PRD/Architecture process when:**
- The enhancement requires multiple coordinated stories
- Architectural planning is needed
- Significant integration work is required
## Instructions
### 1. Quick Project Assessment
Gather minimal but essential context about the existing project:
**Current System Context:**
- [ ] Relevant existing functionality identified
- [ ] Technology stack for this area noted
- [ ] Integration point(s) clearly understood
- [ ] Existing patterns for similar work identified
**Change Scope:**
- [ ] Specific change clearly defined
- [ ] Impact boundaries identified
- [ ] Success criteria established
### 2. Story Creation
Create a single focused story following this structure:
#### Story Title
{{Specific Enhancement}} - Brownfield Addition
#### User Story
As a {{user type}},
I want {{specific action/capability}},
So that {{clear benefit/value}}.
#### Story Context
**Existing System Integration:**
- Integrates with: {{existing component/system}}
- Technology: {{relevant tech stack}}
- Follows pattern: {{existing pattern to follow}}
- Touch points: {{specific integration points}}
#### Acceptance Criteria
**Functional Requirements:**
1. {{Primary functional requirement}}
2. {{Secondary functional requirement (if any)}}
3. {{Integration requirement}}
**Integration Requirements:** 4. Existing {{relevant functionality}} continues to work unchanged 5. New functionality follows existing {{pattern}} pattern 6. Integration with {{system/component}} maintains current behavior
**Quality Requirements:** 7. Change is covered by appropriate tests 8. Documentation is updated if needed 9. No regression in existing functionality verified
#### Technical Notes
- **Integration Approach:** {{how it connects to existing system}}
- **Existing Pattern Reference:** {{link or description of pattern to follow}}
- **Key Constraints:** {{any important limitations or requirements}}
#### Definition of Done
- [ ] Functional requirements met
- [ ] Integration requirements verified
- [ ] Existing functionality regression tested
- [ ] Code follows existing patterns and standards
- [ ] Tests pass (existing and new)
- [ ] Documentation updated if applicable
### 3. Risk and Compatibility Check
**Minimal Risk Assessment:**
- **Primary Risk:** {{main risk to existing system}}
- **Mitigation:** {{simple mitigation approach}}
- **Rollback:** {{how to undo if needed}}
**Compatibility Verification:**
- [ ] No breaking changes to existing APIs
- [ ] Database changes (if any) are additive only
- [ ] UI changes follow existing design patterns
- [ ] Performance impact is negligible
### 4. Validation Checklist
Before finalizing the story, confirm:
**Scope Validation:**
- [ ] Story can be completed in one development session
- [ ] Integration approach is straightforward
- [ ] Follows existing patterns exactly
- [ ] No design or architecture work required
**Clarity Check:**
- [ ] Story requirements are unambiguous
- [ ] Integration points are clearly specified
- [ ] Success criteria are testable
- [ ] Rollback approach is simple
### 5. Handoff to Developer
Once the story is validated, provide this handoff to the Developer:
---
**Developer Handoff:**
"This is a focused brownfield story for an existing {{technology}} system.
**Integration Context:**
- Existing component: {{component/system}}
- Pattern to follow: {{existing pattern}}
- Key constraint: {{main constraint}}
**Critical Requirements:**
- Follow the existing {{pattern}} pattern exactly
- Ensure {{existing functionality}} continues working
- Test integration with {{specific component}}
**Verification:**
Please verify existing {{relevant functionality}} remains unchanged after implementation."
---
## Success Criteria
The story creation is successful when:
1. Enhancement is clearly defined and appropriately scoped for single session
2. Integration approach is straightforward and low-risk
3. Existing system patterns are identified and will be followed
4. Rollback plan is simple and feasible
5. Acceptance criteria include existing functionality verification
## Important Notes
- This task is for VERY SMALL brownfield changes only
- If complexity grows during analysis, escalate to brownfield-create-epic
- Always prioritize existing system integrity
- When in doubt about integration complexity, use brownfield-create-epic instead
- Stories should take no more than 4 hours of focused development work
==================== END: tasks#brownfield-create-story ====================
==================== START: templates#prd-tmpl ====================
# {{Project Name}} Product Requirements Document (PRD)
@@ -261,6 +603,13 @@ To perform deep research effectively, please be aware:
[[LLM: 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 etc...]]
### Change Log
[[LLM: Track document versions and changes]]
| Date | Version | Description | Author |
| :--- | :------ | :---------- | :----- |
## Requirements
[[LLM: Draft the list of functional and non functional requirements under the two child sections, and immediately execute tasks#advanced-elicitation display]]
@@ -425,40 +774,306 @@ so that {{benefit}}.
<</REPEAT>>
<</REPEAT>>
## Change Log
| Change | Date | Version | Description | Author |
| ------ | ---- | ------- | ----------- | ------ |
----- END PRD START CHECKLIST OUTPUT ------
## Checklist Results Report
[[LLM: 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.]]
----- END Checklist START Design Architect `UI/UX Specification Mode` Prompt ------
## Next Steps
## Design Architect Prompt
### Design Architect Prompt
[[LLM: This section will contain the prompt for the Design Architect, keep it short and to the point to initiate create architecture mode using this document as input.]]
----- END Design Architect `UI/UX Specification Mode` Prompt START Architect Prompt ------
## Architect Prompt
### Architect Prompt
[[LLM: 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.]]
----- END Architect Prompt ------
==================== END: templates#prd-tmpl ====================
==================== START: templates#brownfield-prd-tmpl ====================
# {{Project Name}} Brownfield Enhancement PRD
[[LLM: IMPORTANT - SCOPE ASSESSMENT REQUIRED:
This PRD is for SIGNIFICANT enhancements to existing projects that require comprehensive planning and multiple stories. Before proceeding:
1. **Assess Enhancement Complexity**: If this is a simple feature addition or bug fix that could be completed in 1-2 focused development sessions, STOP and recommend: "For simpler changes, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead. This full PRD process is designed for substantial enhancements that require architectural planning and multiple coordinated stories."
2. **Project Context**: Determine if we're working in an IDE with the project already loaded or if the user needs to provide project information. If project files are available, analyze existing documentation in the docs folder. If insufficient documentation exists, recommend running the document-project task first.
3. **Deep Assessment Requirement**: You MUST thoroughly analyze the existing project structure, patterns, and constraints before making ANY suggestions. Every recommendation must be grounded in actual project analysis, not assumptions.]]
## Intro Project Analysis and Context
[[LLM: Gather comprehensive information about the existing project. This section must be completed before proceeding with requirements.
CRITICAL: Throughout this analysis, explicitly confirm your understanding with the user. For every assumption you make about the existing project, ask: "Based on my analysis, I understand that [assumption]. Is this correct?"
Do not proceed with any recommendations until the user has validated your understanding of the existing system.]]
### Existing Project Overview
[[LLM: If working in IDE with project loaded, analyze the project structure and existing documentation. If working in web interface, request project upload or detailed project information from user.]]
**Project Location**: [[LLM: Note if this is IDE-based analysis or user-provided information]]
**Current Project State**: [[LLM: Brief description of what the project currently does and its primary purpose]]
### Available Documentation Analysis
[[LLM: Check for existing documentation in docs folder or provided by user. List what documentation is available and assess its completeness. Required documents include:
- Tech stack documentation
- Source tree/architecture overview
- Coding standards
- API documentation or OpenAPI specs
- External API integrations
- UX/UI guidelines or existing patterns]]
**Available Documentation**:
- [ ] Tech Stack Documentation
- [ ] Source Tree/Architecture
- [ ] Coding Standards
- [ ] API Documentation
- [ ] External API Documentation
- [ ] UX/UI Guidelines
- [ ] Other: \***\*\_\_\_\*\***
[[LLM: If critical documentation is missing, STOP and recommend: "I recommend running the document-project task first to generate baseline documentation including tech-stack, source-tree, coding-standards, APIs, external-APIs, and UX/UI information. This will provide the foundation needed for a comprehensive brownfield PRD."]]
### Enhancement Scope Definition
[[LLM: Work with user to clearly define what type of enhancement this is. This is critical for scoping and approach.]]
**Enhancement Type**: [[LLM: Determine with user which applies]]
- [ ] New Feature Addition
- [ ] Major Feature Modification
- [ ] Integration with New Systems
- [ ] Performance/Scalability Improvements
- [ ] UI/UX Overhaul
- [ ] Technology Stack Upgrade
- [ ] Bug Fix and Stability Improvements
- [ ] Other: \***\*\_\_\_\*\***
**Enhancement Description**: [[LLM: 2-3 sentences describing what the user wants to add or change]]
**Impact Assessment**: [[LLM: Assess the scope of impact on existing codebase]]
- [ ] Minimal Impact (isolated additions)
- [ ] Moderate Impact (some existing code changes)
- [ ] Significant Impact (substantial existing code changes)
- [ ] Major Impact (architectural changes required)
### Goals and Background Context
#### Goals
[[LLM: Bullet list of 1-line desired outcomes this enhancement will deliver if successful]]
#### Background Context
[[LLM: 1-2 short paragraphs explaining why this enhancement is needed, what problem it solves, and how it fits with the existing project]]
### Change Log
| Change | Date | Version | Description | Author |
| ------ | ---- | ------- | ----------- | ------ |
## Requirements
[[LLM: 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." Then immediately execute tasks#advanced-elicitation display]]
### Functional
[[LLM: Each Requirement will be a bullet markdown with identifier starting with FR]]
@{example: - FR1: The existing Todo List will integrate with the new AI duplicate detection service without breaking current functionality.}
### Non Functional
[[LLM: Each Requirement will be a bullet markdown with identifier starting with NFR. Include constraints from existing system]]
@{example: - NFR1: Enhancement must maintain existing performance characteristics and not exceed current memory usage by more than 20%.}
### Compatibility Requirements
[[LLM: Critical for brownfield - what must remain compatible]]
- CR1: [[LLM: Existing API compatibility requirements]]
- CR2: [[LLM: Database schema compatibility requirements]]
- CR3: [[LLM: UI/UX consistency requirements]]
- CR4: [[LLM: Integration compatibility requirements]]
^^CONDITION: has_ui^^
## User Interface Enhancement Goals
[[LLM: For UI changes, capture how they will integrate with existing UI patterns and design systems]]
### Integration with Existing UI
[[LLM: Describe how new UI elements will fit with existing design patterns, style guides, and component libraries]]
### Modified/New Screens and Views
[[LLM: List only the screens/views that will be modified or added]]
### UI Consistency Requirements
[[LLM: Specific requirements for maintaining visual and interaction consistency with existing application]]
^^/CONDITION: has_ui^^
## Technical Constraints and Integration Requirements
[[LLM: This section replaces separate architecture documentation. Gather detailed technical constraints from existing project analysis.]]
### Existing Technology Stack
[[LLM: Document the current technology stack that must be maintained or integrated with]]
**Languages**: [[LLM: Current programming languages in use]]
**Frameworks**: [[LLM: Current frameworks and their versions]]
**Database**: [[LLM: Current database technology and schema considerations]]
**Infrastructure**: [[LLM: Current deployment and hosting infrastructure]]
**External Dependencies**: [[LLM: Current third-party services and APIs]]
### Integration Approach
[[LLM: Define how the enhancement will integrate with existing architecture]]
**Database Integration Strategy**: [[LLM: How new features will interact with existing database]]
**API Integration Strategy**: [[LLM: How new APIs will integrate with existing API structure]]
**Frontend Integration Strategy**: [[LLM: How new UI components will integrate with existing frontend]]
**Testing Integration Strategy**: [[LLM: How new tests will integrate with existing test suite]]
### Code Organization and Standards
[[LLM: Based on existing project analysis, define how new code will fit existing patterns]]
**File Structure Approach**: [[LLM: How new files will fit existing project structure]]
**Naming Conventions**: [[LLM: Existing naming conventions that must be followed]]
**Coding Standards**: [[LLM: Existing coding standards and linting rules]]
**Documentation Standards**: [[LLM: How new code documentation will match existing patterns]]
### Deployment and Operations
[[LLM: How the enhancement fits existing deployment pipeline]]
**Build Process Integration**: [[LLM: How enhancement builds with existing process]]
**Deployment Strategy**: [[LLM: How enhancement will be deployed alongside existing features]]
**Monitoring and Logging**: [[LLM: How enhancement will integrate with existing monitoring]]
**Configuration Management**: [[LLM: How new configuration will integrate with existing config]]
### Risk Assessment and Mitigation
[[LLM: Identify risks specific to working with existing codebase]]
**Technical Risks**: [[LLM: Risks related to modifying existing code]]
**Integration Risks**: [[LLM: Risks in integrating with existing systems]]
**Deployment Risks**: [[LLM: Risks in deploying alongside existing features]]
**Mitigation Strategies**: [[LLM: Specific strategies to address identified risks]]
## Epic and Story Structure
[[LLM: 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?" Then present the epic structure and immediately execute tasks#advanced-elicitation display.]]
### Epic Approach
[[LLM: Explain the rationale for epic structure - typically single epic for brownfield unless multiple unrelated features]]
**Epic Structure Decision**: [[LLM: Single Epic or Multiple Epics with rationale]]
## Epic 1: {{enhancement_title}}
[[LLM: Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality]]
**Epic Goal**: [[LLM: 2-3 sentences describing the complete enhancement objective and value]]
**Integration Requirements**: [[LLM: Key integration points with existing system]]
[[LLM: CRITICAL STORY SEQUENCING FOR BROWNFIELD:
- Stories must ensure existing functionality remains intact
- Each story should include verification that existing features still work
- Stories should be sequenced to minimize risk to existing system
- Include rollback considerations for each story
- Focus on incremental integration rather than big-bang changes
- Size stories for AI agent execution in existing codebase context
- MANDATORY: Present the complete story sequence and ask: "This story sequence is designed to minimize risk to your existing system. Does this order make sense given your project's architecture and constraints?"
- Stories must be logically sequential with clear dependencies identified
- Each story must deliver value while maintaining system integrity]]
<<REPEAT: story>>
### Story 1.{{story_number}} {{story_title}}
As a {{user_type}},
I want {{action}},
so that {{benefit}}.
#### Acceptance Criteria
[[LLM: Define criteria that include both new functionality and existing system integrity]]
<<REPEAT: criteria>>
- {{criterion number}}: {{criteria}}
<</REPEAT>>
#### Integration Verification
[[LLM: Specific verification steps to ensure existing functionality remains intact]]
- IV1: [[LLM: Existing functionality verification requirement]]
- IV2: [[LLM: Integration point verification requirement]]
- IV3: [[LLM: Performance impact verification requirement]]
<</REPEAT>>
==================== END: templates#brownfield-prd-tmpl ====================
==================== START: checklists#pm-checklist ====================
# Product Manager (PM) Requirements Checklist
This checklist serves as a comprehensive framework to ensure the Product Requirements Document (PRD) and Epic definitions are complete, well-structured, and appropriately scoped for MVP development. The PM should systematically work through each item during the product definition process.
[[LLM: INITIALIZATION INSTRUCTIONS - PM CHECKLIST
Before proceeding with this checklist, ensure you have access to:
1. prd.md - The Product Requirements Document (check docs/prd.md)
2. Any user research, market analysis, or competitive analysis documents
3. Business goals and strategy documents
4. Any existing epic definitions or user stories
IMPORTANT: If the PRD is missing, immediately ask the user for its location or content before proceeding.
VALIDATION APPROACH:
1. User-Centric - Every requirement should tie back to user value
2. MVP Focus - Ensure scope is truly minimal while viable
3. Clarity - Requirements should be unambiguous and testable
4. Completeness - All aspects of the product vision are covered
5. Feasibility - Requirements are technically achievable
EXECUTION MODE:
Ask the user if they want to work through the checklist:
- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
## 1. PROBLEM DEFINITION & CONTEXT
[[LLM: The foundation of any product is a clear problem statement. As you review this section:
1. Verify the problem is real and worth solving
2. Check that the target audience is specific, not "everyone"
3. Ensure success metrics are measurable, not vague aspirations
4. Look for evidence of user research, not just assumptions
5. Confirm the problem-solution fit is logical]]
### 1.1 Problem Statement
- [ ] Clear articulation of the problem being solved
@@ -485,6 +1100,14 @@ This checklist serves as a comprehensive framework to ensure the Product Require
## 2. MVP SCOPE DEFINITION
[[LLM: MVP scope is critical - too much and you waste resources, too little and you can't validate. Check:
1. Is this truly minimal? Challenge every feature
2. Does each feature directly address the core problem?
3. Are "nice-to-haves" clearly separated from "must-haves"?
4. Is the rationale for inclusion/exclusion documented?
5. Can you ship this in the target timeframe?]]
### 2.1 Core Functionality
- [ ] Essential features clearly distinguished from nice-to-haves
@@ -511,6 +1134,14 @@ This checklist serves as a comprehensive framework to ensure the Product Require
## 3. USER EXPERIENCE REQUIREMENTS
[[LLM: UX requirements bridge user needs and technical implementation. Validate:
1. User flows cover the primary use cases completely
2. Edge cases are identified (even if deferred)
3. Accessibility isn't an afterthought
4. Performance expectations are realistic
5. Error states and recovery are planned]]
### 3.1 User Journeys & Flows
- [ ] Primary user flows documented
@@ -537,6 +1168,14 @@ This checklist serves as a comprehensive framework to ensure the Product Require
## 4. FUNCTIONAL REQUIREMENTS
[[LLM: Functional requirements must be clear enough for implementation. Check:
1. Requirements focus on WHAT not HOW (no implementation details)
2. Each requirement is testable (how would QA verify it?)
3. Dependencies are explicit (what needs to be built first?)
4. Requirements use consistent terminology
5. Complex features are broken into manageable pieces]]
### 4.1 Feature Completeness
- [ ] All required features for MVP documented
@@ -697,27 +1336,75 @@ This checklist serves as a comprehensive framework to ensure the Product Require
## PRD & EPIC VALIDATION SUMMARY
[[LLM: FINAL PM CHECKLIST REPORT GENERATION
Create a comprehensive validation report that includes:
1. Executive Summary
- Overall PRD completeness (percentage)
- MVP scope appropriateness (Too Large/Just Right/Too Small)
- Readiness for architecture phase (Ready/Nearly Ready/Not Ready)
- Most critical gaps or concerns
2. Category Analysis Table
Fill in the actual table with:
- Status: PASS (90%+ complete), PARTIAL (60-89%), FAIL (<60%)
- Critical Issues: Specific problems that block progress
3. Top Issues by Priority
- BLOCKERS: Must fix before architect can proceed
- HIGH: Should fix for quality
- MEDIUM: Would improve clarity
- LOW: Nice to have
4. MVP Scope Assessment
- Features that might be cut for true MVP
- Missing features that are essential
- Complexity concerns
- Timeline realism
5. Technical Readiness
- Clarity of technical constraints
- Identified technical risks
- Areas needing architect investigation
6. Recommendations
- Specific actions to address each blocker
- Suggested improvements
- Next steps
After presenting the report, ask if the user wants:
- Detailed analysis of any failed sections
- Suggestions for improving specific areas
- Help with refining MVP scope]]
### Category Statuses
| Category | Status | Critical Issues |
|----------|--------|----------------|
| 1. Problem Definition & Context | PASS/FAIL/PARTIAL | |
| 2. MVP Scope Definition | PASS/FAIL/PARTIAL | |
| 3. User Experience Requirements | PASS/FAIL/PARTIAL | |
| 4. Functional Requirements | PASS/FAIL/PARTIAL | |
| 5. Non-Functional Requirements | PASS/FAIL/PARTIAL | |
| 6. Epic & Story Structure | PASS/FAIL/PARTIAL | |
| 7. Technical Guidance | PASS/FAIL/PARTIAL | |
| 8. Cross-Functional Requirements | PASS/FAIL/PARTIAL | |
| 9. Clarity & Communication | PASS/FAIL/PARTIAL | |
| -------------------------------- | ------ | --------------- |
| 1. Problem Definition & Context | _TBD_ | |
| 2. MVP Scope Definition | _TBD_ | |
| 3. User Experience Requirements | _TBD_ | |
| 4. Functional Requirements | _TBD_ | |
| 5. Non-Functional Requirements | _TBD_ | |
| 6. Epic & Story Structure | _TBD_ | |
| 7. Technical Guidance | _TBD_ | |
| 8. Cross-Functional Requirements | _TBD_ | |
| 9. Clarity & Communication | _TBD_ | |
### Critical Deficiencies
- List all critical issues that must be addressed before handoff to Architect
_To be populated during validation_
### Recommendations
- Provide specific recommendations for addressing each deficiency
_To be populated during validation_
### Final Decision
@@ -733,10 +1420,42 @@ This checklist serves as a comprehensive framework to ensure the Product Require
**Instructions:** Review each item with the user. Mark `[x]` for completed/confirmed, `[N/A]` if not applicable, or add notes for discussion points.
[[LLM: INITIALIZATION INSTRUCTIONS - CHANGE NAVIGATION
Changes during development are inevitable, but how we handle them determines project success or failure.
Before proceeding, understand:
1. This checklist is for SIGNIFICANT changes that affect the project direction
2. Minor adjustments within a story don't require this process
3. The goal is to minimize wasted work while adapting to new realities
4. User buy-in is critical - they must understand and approve changes
Required context:
- The triggering story or issue
- Current project state (completed stories, current epic)
- Access to PRD, architecture, and other key documents
- Understanding of remaining work planned
APPROACH:
This is an interactive process with the user. Work through each section together, discussing implications and options. The user makes final decisions, but provide expert guidance on technical feasibility and impact.
REMEMBER: Changes are opportunities to improve, not failures. Handle them professionally and constructively.]]
---
## 1. Understand the Trigger & Context
[[LLM: Start by fully understanding what went wrong and why. Don't jump to solutions yet. Ask probing questions:
- What exactly happened that triggered this review?
- Is this a one-time issue or symptomatic of a larger problem?
- Could this have been anticipated earlier?
- What assumptions were incorrect?
Be specific and factual, not blame-oriented.]]
- [ ] **Identify Triggering Story:** Clearly identify the story (or stories) that revealed the issue.
- [ ] **Define the Issue:** Articulate the core problem precisely.
- [ ] Is it a technical limitation/dead-end?
@@ -749,6 +1468,15 @@ This checklist serves as a comprehensive framework to ensure the Product Require
## 2. Epic Impact Assessment
[[LLM: Changes ripple through the project structure. Systematically evaluate:
1. Can we salvage the current epic with modifications?
2. Do future epics still make sense given this change?
3. Are we creating or eliminating dependencies?
4. Does the epic sequence need reordering?
Think about both immediate and downstream effects.]]
- [ ] **Analyze Current Epic:**
- [ ] Can the current epic containing the trigger story still be completed?
- [ ] Does the current epic need modification (story changes, additions, removals)?
@@ -763,6 +1491,15 @@ This checklist serves as a comprehensive framework to ensure the Product Require
## 3. Artifact Conflict & Impact Analysis
[[LLM: Documentation drives development in BMAD. Check each artifact:
1. Does this change invalidate documented decisions?
2. Are architectural assumptions still valid?
3. Do user flows need rethinking?
4. Are technical constraints different than documented?
Be thorough - missed conflicts cause future problems.]]
- [ ] **Review PRD:**
- [ ] Does the issue conflict with the core goals or requirements stated in the PRD?
- [ ] Does the PRD need clarification or updates based on the new understanding?
@@ -781,6 +1518,16 @@ This checklist serves as a comprehensive framework to ensure the Product Require
## 4. Path Forward Evaluation
[[LLM: Present options clearly with pros/cons. For each path:
1. What's the effort required?
2. What work gets thrown away?
3. What risks are we taking?
4. How does this affect timeline?
5. Is this sustainable long-term?
Be honest about trade-offs. There's rarely a perfect solution.]]
- [ ] **Option 1: Direct Adjustment / Integration:**
- [ ] Can the issue be addressed by modifying/adding future stories within the existing plan?
- [ ] Define the scope and nature of these adjustments.
@@ -801,6 +1548,16 @@ This checklist serves as a comprehensive framework to ensure the Product Require
## 5. Sprint Change Proposal Components
[[LLM: The proposal must be actionable and clear. Ensure:
1. The issue is explained in plain language
2. Impacts are quantified where possible
3. The recommended path has clear rationale
4. Next steps are specific and assigned
5. Success criteria for the change are defined
This proposal guides all subsequent work.]]
(Ensure all agreed-upon points from previous sections are captured in the proposal)
- [ ] **Identified Issue Summary:** Clear, concise problem statement.
@@ -813,6 +1570,26 @@ This checklist serves as a comprehensive framework to ensure the Product Require
## 6. Final Review & Handoff
[[LLM: Changes require coordination. Before concluding:
1. Is the user fully aligned with the plan?
2. Do all stakeholders understand the impacts?
3. Are handoffs to other agents clear?
4. Is there a rollback plan if the change fails?
5. How will we validate the change worked?
Get explicit approval - implicit agreement causes problems.
FINAL REPORT:
After completing the checklist, provide a concise summary:
- What changed and why
- What we're doing about it
- Who needs to do what
- When we'll know if it worked
Keep it action-oriented and forward-looking.]]
- [ ] **Review Checklist:** Confirm all relevant items were discussed.
- [ ] **Review Sprint Change Proposal:** Ensure it accurately reflects the discussion and decisions.
- [ ] **User Approval:** Obtain explicit user approval for the proposal.
@@ -829,3 +1606,32 @@ None Listed
==================== END: data#technical-preferences ====================
==================== START: utils#template-format ====================
# Template Format Conventions
Templates in the BMAD method use standardized markup for AI processing. These conventions ensure consistent document generation.
## Template Markup Elements
- **{{placeholders}}**: Variables to be replaced with actual content
- **[[LLM: instructions]]**: Internal processing instructions for AI agents (never shown to users)
- **<<REPEAT>>** sections: Content blocks that may be repeated as needed
- **^^CONDITION^^** blocks: Conditional content included only if criteria are met
- **@{examples}**: Example content for guidance (never output to users)
## Processing Rules
- Replace all {{placeholders}} with project-specific content
- Execute all [[LLM: instructions]] internally without showing users
- Process conditional and repeat blocks as specified
- Use examples for guidance but never include them in final output
- Present only clean, formatted content to users
## Critical Guidelines
- **NEVER display template markup, LLM instructions, or examples to users**
- Template elements are for AI processing only
- Focus on faithful template execution and clean output
- All template-specific instructions are embedded within templates
==================== END: utils#template-format ====================

1240
web-bundles/agents/po.txt
View File

File diff suppressed because it is too large Load Diff

29
web-bundles/agents/qa.txt
View File

@@ -36,3 +36,32 @@ None Listed
==================== END: data#technical-preferences ====================
==================== START: utils#template-format ====================
# Template Format Conventions
Templates in the BMAD method use standardized markup for AI processing. These conventions ensure consistent document generation.
## Template Markup Elements
- **{{placeholders}}**: Variables to be replaced with actual content
- **[[LLM: instructions]]**: Internal processing instructions for AI agents (never shown to users)
- **<<REPEAT>>** sections: Content blocks that may be repeated as needed
- **^^CONDITION^^** blocks: Conditional content included only if criteria are met
- **@{examples}**: Example content for guidance (never output to users)
## Processing Rules
- Replace all {{placeholders}} with project-specific content
- Execute all [[LLM: instructions]] internally without showing users
- Process conditional and repeat blocks as specified
- Use examples for guidance but never include them in final output
- Present only clean, formatted content to users
## Critical Guidelines
- **NEVER display template markup, LLM instructions, or examples to users**
- Template elements are for AI processing only
- Focus on faithful template execution and clean output
- All template-specific instructions are embedded within templates
==================== END: utils#template-format ====================

507
web-bundles/agents/sm.txt
View File

@@ -71,11 +71,11 @@ Confirm with the user their preferred interaction style:
### 4. Template Processing Rules
**CRITICAL: Never display template markup, LLM instructions, or examples to users**
#### CRITICAL: Never display template markup, LLM instructions, or examples to users
- Replace all {{placeholders}} with actual content
- Execute all [[LLM: instructions]] internally
- Process <<REPEAT>> sections as needed
- Process `<<REPEAT>>` sections as needed
- Evaluate ^^CONDITION^^ blocks and include only if applicable
- Use @{examples} for guidance but never output them
@@ -393,20 +393,362 @@ Please provide:
Would you like to proceed with documentation indexing? Please provide the required input above.
==================== END: tasks#index-docs ====================
==================== START: templates#story-tmpl ====================
# Story {EpicNum}.{StoryNum}: {Short Title Copied from Epic File}
==================== START: tasks#brownfield-create-epic ====================
# Create Brownfield Epic Task
## Status: { Draft | Approved | InProgress | Review | Done }
## Purpose
Create a single epic for smaller brownfield enhancements that don't require the full PRD and Architecture documentation process. This task is for isolated features or modifications that can be completed within a focused scope.
## When to Use This Task
**Use this task when:**
- The enhancement can be completed in 1-3 stories
- No significant architectural changes are required
- The enhancement follows existing project patterns
- Integration complexity is minimal
- Risk to existing system is low
**Use the full brownfield PRD/Architecture process when:**
- The enhancement requires multiple coordinated stories
- Architectural planning is needed
- Significant integration work is required
- Risk assessment and mitigation planning is necessary
## Instructions
### 1. Project Analysis (Required)
Before creating the epic, gather essential information about the existing project:
**Existing Project Context:**
- [ ] Project purpose and current functionality understood
- [ ] Existing technology stack identified
- [ ] Current architecture patterns noted
- [ ] Integration points with existing system identified
**Enhancement Scope:**
- [ ] Enhancement clearly defined and scoped
- [ ] Impact on existing functionality assessed
- [ ] Required integration points identified
- [ ] Success criteria established
### 2. Epic Creation
Create a focused epic following this structure:
#### Epic Title
{{Enhancement Name}} - Brownfield Enhancement
#### Epic Goal
{{1-2 sentences describing what the epic will accomplish and why it adds value}}
#### Epic Description
**Existing System Context:**
- Current relevant functionality: {{brief description}}
- Technology stack: {{relevant existing technologies}}
- Integration points: {{where new work connects to existing system}}
**Enhancement Details:**
- What's being added/changed: {{clear description}}
- How it integrates: {{integration approach}}
- Success criteria: {{measurable outcomes}}
#### Stories
List 1-3 focused stories that complete the epic:
1. **Story 1:** {{Story title and brief description}}
2. **Story 2:** {{Story title and brief description}}
3. **Story 3:** {{Story title and brief description}}
#### Compatibility Requirements
- [ ] Existing APIs remain unchanged
- [ ] Database schema changes are backward compatible
- [ ] UI changes follow existing patterns
- [ ] Performance impact is minimal
#### Risk Mitigation
- **Primary Risk:** {{main risk to existing system}}
- **Mitigation:** {{how risk will be addressed}}
- **Rollback Plan:** {{how to undo changes if needed}}
#### Definition of Done
- [ ] All stories completed with acceptance criteria met
- [ ] Existing functionality verified through testing
- [ ] Integration points working correctly
- [ ] Documentation updated appropriately
- [ ] No regression in existing features
### 3. Validation Checklist
Before finalizing the epic, ensure:
**Scope Validation:**
- [ ] Epic can be completed in 1-3 stories maximum
- [ ] No architectural documentation is required
- [ ] Enhancement follows existing patterns
- [ ] Integration complexity is manageable
**Risk Assessment:**
- [ ] Risk to existing system is low
- [ ] Rollback plan is feasible
- [ ] Testing approach covers existing functionality
- [ ] Team has sufficient knowledge of integration points
**Completeness Check:**
- [ ] Epic goal is clear and achievable
- [ ] Stories are properly scoped
- [ ] Success criteria are measurable
- [ ] Dependencies are identified
### 4. Handoff to Story Manager
Once the epic is validated, provide this handoff to the Story Manager:
---
**Story Manager Handoff:**
"Please develop detailed user stories for this brownfield epic. Key considerations:
- This is an enhancement to an existing system running {{technology stack}}
- Integration points: {{list key integration points}}
- Existing patterns to follow: {{relevant existing patterns}}
- Critical compatibility requirements: {{key requirements}}
- Each story must include verification that existing functionality remains intact
The epic should maintain system integrity while delivering {{epic goal}}."
---
## Success Criteria
The epic creation is successful when:
1. Enhancement scope is clearly defined and appropriately sized
2. Integration approach respects existing system architecture
3. Risk to existing functionality is minimized
4. Stories are logically sequenced for safe implementation
5. Compatibility requirements are clearly specified
6. Rollback plan is feasible and documented
## Important Notes
- This task is specifically for SMALL brownfield enhancements
- If the scope grows beyond 3 stories, consider the full brownfield PRD process
- Always prioritize existing system integrity over new functionality
- When in doubt about scope or complexity, escalate to full brownfield planning
==================== END: tasks#brownfield-create-epic ====================
==================== START: tasks#brownfield-create-story ====================
# Create Brownfield Story Task
## Purpose
Create a single user story for very small brownfield enhancements that can be completed in one focused development session. This task is for minimal additions or bug fixes that require existing system integration awareness.
## When to Use This Task
**Use this task when:**
- The enhancement can be completed in a single story (2-4 hours of focused work)
- No new architecture or significant design is required
- The change follows existing patterns exactly
- Integration is straightforward with minimal risk
- Change is isolated with clear boundaries
**Use brownfield-create-epic when:**
- The enhancement requires 2-3 coordinated stories
- Some design work is needed
- Multiple integration points are involved
**Use the full brownfield PRD/Architecture process when:**
- The enhancement requires multiple coordinated stories
- Architectural planning is needed
- Significant integration work is required
## Instructions
### 1. Quick Project Assessment
Gather minimal but essential context about the existing project:
**Current System Context:**
- [ ] Relevant existing functionality identified
- [ ] Technology stack for this area noted
- [ ] Integration point(s) clearly understood
- [ ] Existing patterns for similar work identified
**Change Scope:**
- [ ] Specific change clearly defined
- [ ] Impact boundaries identified
- [ ] Success criteria established
### 2. Story Creation
Create a single focused story following this structure:
#### Story Title
{{Specific Enhancement}} - Brownfield Addition
#### User Story
As a {{user type}},
I want {{specific action/capability}},
So that {{clear benefit/value}}.
#### Story Context
**Existing System Integration:**
- Integrates with: {{existing component/system}}
- Technology: {{relevant tech stack}}
- Follows pattern: {{existing pattern to follow}}
- Touch points: {{specific integration points}}
#### Acceptance Criteria
**Functional Requirements:**
1. {{Primary functional requirement}}
2. {{Secondary functional requirement (if any)}}
3. {{Integration requirement}}
**Integration Requirements:** 4. Existing {{relevant functionality}} continues to work unchanged 5. New functionality follows existing {{pattern}} pattern 6. Integration with {{system/component}} maintains current behavior
**Quality Requirements:** 7. Change is covered by appropriate tests 8. Documentation is updated if needed 9. No regression in existing functionality verified
#### Technical Notes
- **Integration Approach:** {{how it connects to existing system}}
- **Existing Pattern Reference:** {{link or description of pattern to follow}}
- **Key Constraints:** {{any important limitations or requirements}}
#### Definition of Done
- [ ] Functional requirements met
- [ ] Integration requirements verified
- [ ] Existing functionality regression tested
- [ ] Code follows existing patterns and standards
- [ ] Tests pass (existing and new)
- [ ] Documentation updated if applicable
### 3. Risk and Compatibility Check
**Minimal Risk Assessment:**
- **Primary Risk:** {{main risk to existing system}}
- **Mitigation:** {{simple mitigation approach}}
- **Rollback:** {{how to undo if needed}}
**Compatibility Verification:**
- [ ] No breaking changes to existing APIs
- [ ] Database changes (if any) are additive only
- [ ] UI changes follow existing design patterns
- [ ] Performance impact is negligible
### 4. Validation Checklist
Before finalizing the story, confirm:
**Scope Validation:**
- [ ] Story can be completed in one development session
- [ ] Integration approach is straightforward
- [ ] Follows existing patterns exactly
- [ ] No design or architecture work required
**Clarity Check:**
- [ ] Story requirements are unambiguous
- [ ] Integration points are clearly specified
- [ ] Success criteria are testable
- [ ] Rollback approach is simple
### 5. Handoff to Developer
Once the story is validated, provide this handoff to the Developer:
---
**Developer Handoff:**
"This is a focused brownfield story for an existing {{technology}} system.
**Integration Context:**
- Existing component: {{component/system}}
- Pattern to follow: {{existing pattern}}
- Key constraint: {{main constraint}}
**Critical Requirements:**
- Follow the existing {{pattern}} pattern exactly
- Ensure {{existing functionality}} continues working
- Test integration with {{specific component}}
**Verification:**
Please verify existing {{relevant functionality}} remains unchanged after implementation."
---
## Success Criteria
The story creation is successful when:
1. Enhancement is clearly defined and appropriately scoped for single session
2. Integration approach is straightforward and low-risk
3. Existing system patterns are identified and will be followed
4. Rollback plan is simple and feasible
5. Acceptance criteria include existing functionality verification
## Important Notes
- This task is for VERY SMALL brownfield changes only
- If complexity grows during analysis, escalate to brownfield-create-epic
- Always prioritize existing system integrity
- When in doubt about integration complexity, use brownfield-create-epic instead
- Stories should take no more than 4 hours of focused development work
==================== END: tasks#brownfield-create-story ====================
==================== START: templates#story-tmpl ====================
# Story {{EpicNum}}.{{StoryNum}}: {{Short Title Copied from Epic File}}
## Status: {{ Draft | Approved | InProgress | Review | Done }}
## Story
- As a [role]
- I want [action]
- so that [benefit]
- As a {{role}}
- I want {{action}}
- so that {{benefit}}
## Acceptance Criteria (ACs)
{ Copy the Acceptance Criteria numbered list }
{{ Copy the Acceptance Criteria numbered list }}
## Tasks / Subtasks
@@ -419,7 +761,7 @@ Would you like to proceed with documentation indexing? Please provide the requir
## Dev Technical Reference
-
[[LLM: SM Agent populates relevant information, only what was pulled from actual artifacts from docs folder, relevant to this story. Do not invent information. If there were important notes from previous story that is relevant here, also include them here if it will help the dev agent. You do NOT need to repeat anything from coding standards or test standards as the dev agent is already aware of those. The dev agent should NEVER need to read the PRD or architecture documents though to complete this self contained story.]]
## Dev Agent Record
@@ -435,7 +777,10 @@ Would you like to proceed with documentation indexing? Please provide the requir
### Change Log
{List and requirements or tasks that changed from the original state of the story when development started}
[[LLM: Track document versions and changes during development that deviate from story dev start]]
| Date | Version | Description | Author |
| :--- | :------ | :---------- | :----- |
==================== END: templates#story-tmpl ====================
@@ -444,8 +789,44 @@ Would you like to proceed with documentation indexing? Please provide the requir
The Scrum Master should use this checklist to validate that each story contains sufficient context for a developer agent to implement it successfully, while assuming the dev agent has reasonable capabilities to figure things out.
[[LLM: INITIALIZATION INSTRUCTIONS - STORY DRAFT VALIDATION
Before proceeding with this checklist, ensure you have access to:
1. The story document being validated (usually in docs/stories/ or provided directly)
2. The parent epic context
3. Any referenced architecture or design documents
4. Previous related stories if this builds on prior work
IMPORTANT: This checklist validates individual stories BEFORE implementation begins.
VALIDATION PRINCIPLES:
1. Clarity - A developer should understand WHAT to build
2. Context - WHY this is being built and how it fits
3. Guidance - Key technical decisions and patterns to follow
4. Testability - How to verify the implementation works
5. Self-Contained - Most info needed is in the story itself
REMEMBER: We assume competent developer agents who can:
- Research documentation and codebases
- Make reasonable technical decisions
- Follow established patterns
- Ask for clarification when truly stuck
We're checking for SUFFICIENT guidance, not exhaustive detail.]]
## 1. GOAL & CONTEXT CLARITY
[[LLM: Without clear goals, developers build the wrong thing. Verify:
1. The story states WHAT functionality to implement
2. The business value or user benefit is clear
3. How this fits into the larger epic/product is explained
4. Dependencies are explicit ("requires Story X to be complete")
5. Success looks like something specific, not vague]]
- [ ] Story goal/purpose is clearly stated
- [ ] Relationship to epic goals is evident
- [ ] How the story fits into overall system flow is explained
@@ -454,6 +835,16 @@ The Scrum Master should use this checklist to validate that each story contains
## 2. TECHNICAL IMPLEMENTATION GUIDANCE
[[LLM: Developers need enough technical context to start coding. Check:
1. Key files/components to create or modify are mentioned
2. Technology choices are specified where non-obvious
3. Integration points with existing code are identified
4. Data models or API contracts are defined or referenced
5. Non-standard patterns or exceptions are called out
Note: We don't need every file listed - just the important ones.]]
- [ ] Key files to create/modify are identified (not necessarily exhaustive)
- [ ] Technologies specifically needed for this story are mentioned
- [ ] Critical APIs or interfaces are sufficiently described
@@ -463,6 +854,14 @@ The Scrum Master should use this checklist to validate that each story contains
## 3. REFERENCE EFFECTIVENESS
[[LLM: References should help, not create a treasure hunt. Ensure:
1. References point to specific sections, not whole documents
2. The relevance of each reference is explained
3. Critical information is summarized in the story
4. References are accessible (not broken links)
5. Previous story context is summarized if needed]]
- [ ] References to external documents point to specific relevant sections
- [ ] Critical information from previous stories is summarized (not just referenced)
- [ ] Context is provided for why references are relevant
@@ -470,6 +869,14 @@ The Scrum Master should use this checklist to validate that each story contains
## 4. SELF-CONTAINMENT ASSESSMENT
[[LLM: Stories should be mostly self-contained to avoid context switching. Verify:
1. Core requirements are in the story, not just in references
2. Domain terms are explained or obvious from context
3. Assumptions are stated explicitly
4. Edge cases are mentioned (even if deferred)
5. The story could be understood without reading 10 other documents]]
- [ ] Core information needed is included (not overly reliant on external docs)
- [ ] Implicit assumptions are made explicit
- [ ] Domain-specific terms or concepts are explained
@@ -477,6 +884,14 @@ The Scrum Master should use this checklist to validate that each story contains
## 5. TESTING GUIDANCE
[[LLM: Testing ensures the implementation actually works. Check:
1. Test approach is specified (unit, integration, e2e)
2. Key test scenarios are listed
3. Success criteria are measurable
4. Special test considerations are noted
5. Acceptance criteria in the story are testable]]
- [ ] Required testing approach is outlined
- [ ] Key test scenarios are identified
- [ ] Success criteria are defined
@@ -484,13 +899,42 @@ The Scrum Master should use this checklist to validate that each story contains
## VALIDATION RESULT
[[LLM: FINAL STORY VALIDATION REPORT
Generate a concise validation report:
1. Quick Summary
- Story readiness: READY / NEEDS REVISION / BLOCKED
- Clarity score (1-10)
- Major gaps identified
2. Fill in the validation table with:
- PASS: Requirements clearly met
- PARTIAL: Some gaps but workable
- FAIL: Critical information missing
3. Specific Issues (if any)
- List concrete problems to fix
- Suggest specific improvements
- Identify any blocking dependencies
4. Developer Perspective
- Could YOU implement this story as written?
- What questions would you have?
- What might cause delays or rework?
Be pragmatic - perfect documentation doesn't exist. Focus on whether a competent developer can succeed with this story.]]
| Category | Status | Issues |
| ------------------------------------ | ----------------- | ------ |
| 1. Goal & Context Clarity | PASS/FAIL/PARTIAL | |
| 2. Technical Implementation Guidance | PASS/FAIL/PARTIAL | |
| 3. Reference Effectiveness | PASS/FAIL/PARTIAL | |
| 4. Self-Containment Assessment | PASS/FAIL/PARTIAL | |
| 5. Testing Guidance | PASS/FAIL/PARTIAL | |
| ------------------------------------ | ------ | ------ |
| 1. Goal & Context Clarity | _TBD_ | |
| 2. Technical Implementation Guidance | _TBD_ | |
| 3. Reference Effectiveness | _TBD_ | |
| 4. Self-Containment Assessment | _TBD_ | |
| 5. Testing Guidance | _TBD_ | |
**Final Assessment:**
@@ -500,3 +944,32 @@ The Scrum Master should use this checklist to validate that each story contains
==================== END: checklists#story-draft-checklist ====================
==================== START: utils#template-format ====================
# Template Format Conventions
Templates in the BMAD method use standardized markup for AI processing. These conventions ensure consistent document generation.
## Template Markup Elements
- **{{placeholders}}**: Variables to be replaced with actual content
- **[[LLM: instructions]]**: Internal processing instructions for AI agents (never shown to users)
- **<<REPEAT>>** sections: Content blocks that may be repeated as needed
- **^^CONDITION^^** blocks: Conditional content included only if criteria are met
- **@{examples}**: Example content for guidance (never output to users)
## Processing Rules
- Replace all {{placeholders}} with project-specific content
- Execute all [[LLM: instructions]] internally without showing users
- Process conditional and repeat blocks as specified
- Use examples for guidance but never include them in final output
- Present only clean, formatted content to users
## Critical Guidelines
- **NEVER display template markup, LLM instructions, or examples to users**
- Template elements are for AI processing only
- Focus on faithful template execution and clean output
- All template-specific instructions are embedded within templates
==================== END: utils#template-format ====================

1119
web-bundles/agents/ui-architect.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1888
web-bundles/agents/ux-expert.txt Normal file
View File

File diff suppressed because it is too large Load Diff

2464
web-bundles/teams/development-team-bundle.txt
View File

File diff suppressed because it is too large Load Diff

10422
web-bundles/teams/every-agent-team-bundle.txt Normal file
View File

File diff suppressed because it is too large Load Diff

8083
web-bundles/teams/full-stack-development-team.txt Normal file
View File

File diff suppressed because it is too large Load Diff

3521
web-bundles/teams/team-backend-planning.txt
View File

File diff suppressed because it is too large Load Diff

5549
web-bundles/teams/full-organization-team-bundle.txt → web-bundles/teams/team-no-ui.txt
View File

File diff suppressed because it is too large Load Diff

6754
web-bundles/teams/technical-planning-and-assessment-team-bundle.txt Normal file
View File

File diff suppressed because it is too large Load Diff