brownfield experimental docs added to templates
This commit is contained in:
Brian Madison
@@ -1,188 +0,0 @@
|
||||
workflow:
|
||||
id: api-only
|
||||
name: API-First Development
|
||||
description: >-
|
||||
Workflow for building REST APIs, GraphQL services, or microservices
|
||||
without frontend components.
|
||||
type: greenfield
|
||||
project_types:
|
||||
- rest-api
|
||||
- graphql-api
|
||||
- microservice
|
||||
- backend-service
|
||||
|
||||
stages:
|
||||
- id: api-discovery
|
||||
name: API Requirements Discovery
|
||||
description: Understand API consumers and requirements
|
||||
steps:
|
||||
- agent: analyst
|
||||
action: API Requirements Analysis
|
||||
description: >-
|
||||
Analyze API consumers, use cases, and integration requirements
|
||||
outputs:
|
||||
- api-requirements
|
||||
- consumer-analysis
|
||||
prompts:
|
||||
- "Who will consume this API? Internal services, mobile apps, third parties?"
|
||||
- "What are the main operations and data flows?"
|
||||
|
||||
- id: api-design
|
||||
name: API Product Design
|
||||
description: Design API as a product
|
||||
steps:
|
||||
- agent: pm
|
||||
action: API Product Strategy
|
||||
description: >-
|
||||
Define API product strategy, versioning, and roadmap
|
||||
inputs:
|
||||
- api-requirements
|
||||
outputs:
|
||||
- api-product-spec
|
||||
- api-roadmap
|
||||
prompts:
|
||||
- "What's the API versioning strategy?"
|
||||
- "How will the API evolve over time?"
|
||||
|
||||
- agent: architect
|
||||
action: API Architecture Design
|
||||
description: >-
|
||||
Design RESTful resources, GraphQL schema, or service contracts
|
||||
inputs:
|
||||
- api-product-spec
|
||||
outputs:
|
||||
- api-design-doc
|
||||
- openapi-spec
|
||||
- data-contracts
|
||||
prompts:
|
||||
- "Let's design the API endpoints and data models"
|
||||
- "Define authentication and authorization strategy"
|
||||
|
||||
- id: technical-design
|
||||
name: Technical Architecture
|
||||
description: Design backend architecture and infrastructure
|
||||
steps:
|
||||
- agent: architect
|
||||
action: Backend Architecture
|
||||
description: >-
|
||||
Design service architecture, database, and integrations
|
||||
inputs:
|
||||
- api-design-doc
|
||||
outputs:
|
||||
- backend-architecture
|
||||
- database-design
|
||||
- integration-architecture
|
||||
prompts:
|
||||
- "Design the service layer architecture"
|
||||
- "What databases and caching strategies?"
|
||||
|
||||
- agent: devops
|
||||
action: API Infrastructure
|
||||
description: >-
|
||||
Design API gateway, rate limiting, monitoring, and deployment
|
||||
inputs:
|
||||
- backend-architecture
|
||||
outputs:
|
||||
- api-infrastructure
|
||||
- monitoring-strategy
|
||||
- deployment-plan
|
||||
prompts:
|
||||
- "Design API gateway and rate limiting"
|
||||
- "Define monitoring and alerting strategy"
|
||||
|
||||
- id: validation
|
||||
name: API Design Validation
|
||||
description: Validate API design and documentation
|
||||
steps:
|
||||
- agent: po
|
||||
action: API Design Review
|
||||
description: >-
|
||||
Review API design for completeness and usability
|
||||
inputs:
|
||||
- api-design-doc
|
||||
- openapi-spec
|
||||
outputs:
|
||||
- api-validation-report
|
||||
- api-documentation
|
||||
prompts:
|
||||
- "Review API design for developer experience"
|
||||
- "Is the API documentation complete?"
|
||||
|
||||
- id: development-planning
|
||||
name: Implementation Planning
|
||||
description: Plan API implementation sprints
|
||||
steps:
|
||||
- agent: sm
|
||||
action: API Development Stories
|
||||
description: >-
|
||||
Create stories for endpoints, middleware, and infrastructure
|
||||
inputs:
|
||||
- api-design-doc
|
||||
- backend-architecture
|
||||
outputs:
|
||||
- api-stories
|
||||
- implementation-plan
|
||||
prompts:
|
||||
- "Break down API into implementation stories"
|
||||
- "Prioritize endpoints for phased delivery"
|
||||
|
||||
- agent: qa
|
||||
action: API Test Planning
|
||||
description: >-
|
||||
Create API testing strategy and automation plan
|
||||
inputs:
|
||||
- openapi-spec
|
||||
- api-stories
|
||||
outputs:
|
||||
- api-test-strategy
|
||||
- contract-tests
|
||||
- performance-tests
|
||||
prompts:
|
||||
- "Design API contract testing approach"
|
||||
- "Plan load testing and performance benchmarks"
|
||||
|
||||
- id: developer-experience
|
||||
name: Developer Experience
|
||||
description: Prepare API for developers
|
||||
steps:
|
||||
- agent: dev
|
||||
action: SDK & Documentation Planning
|
||||
description: >-
|
||||
Plan SDK development and interactive documentation
|
||||
inputs:
|
||||
- openapi-spec
|
||||
- api-documentation
|
||||
outputs:
|
||||
- sdk-requirements
|
||||
- doc-portal-plan
|
||||
prompts:
|
||||
- "Which language SDKs are needed?"
|
||||
- "Plan interactive API documentation"
|
||||
|
||||
transitions:
|
||||
- from: api-discovery
|
||||
to: api-design
|
||||
condition: requirements analyzed
|
||||
- from: api-design
|
||||
to: technical-design
|
||||
condition: api spec completed
|
||||
- from: technical-design
|
||||
to: validation
|
||||
condition: architecture completed
|
||||
- from: validation
|
||||
to: development-planning
|
||||
condition: design approved
|
||||
- from: development-planning
|
||||
to: developer-experience
|
||||
condition: stories created
|
||||
|
||||
artifacts:
|
||||
openapi-spec:
|
||||
format: openapi-3.0
|
||||
description: Complete API specification
|
||||
api-design-doc:
|
||||
template: api-design-tmpl
|
||||
description: API design decisions and patterns
|
||||
contract-tests:
|
||||
format: postman-collection
|
||||
description: API contract test suite
|
||||
@@ -1,229 +0,0 @@
|
||||
workflow:
|
||||
id: backend-service
|
||||
name: Backend Service Development
|
||||
description: >-
|
||||
Workflow for building microservices, backend APIs, or data processing services
|
||||
with focus on scalability, reliability, and maintainability.
|
||||
type: greenfield
|
||||
project_types:
|
||||
- microservice
|
||||
- data-pipeline
|
||||
- background-worker
|
||||
- event-processor
|
||||
|
||||
stages:
|
||||
- id: service-discovery
|
||||
name: Service Requirements
|
||||
description: Define service boundaries and responsibilities
|
||||
steps:
|
||||
- agent: analyst
|
||||
action: Service Analysis
|
||||
description: >-
|
||||
Analyze service requirements, boundaries, and integrations
|
||||
outputs:
|
||||
- service-brief
|
||||
- integration-requirements
|
||||
- data-flow-analysis
|
||||
prompts:
|
||||
- "What is this service's primary responsibility?"
|
||||
- "What other services will it interact with?"
|
||||
- "What are the data input/output requirements?"
|
||||
|
||||
- id: service-design
|
||||
name: Service Design
|
||||
description: Design service architecture and contracts
|
||||
steps:
|
||||
- agent: architect
|
||||
action: Service Architecture
|
||||
description: >-
|
||||
Design service internals, API contracts, and data models
|
||||
inputs:
|
||||
- service-brief
|
||||
- integration-requirements
|
||||
outputs:
|
||||
- service-architecture
|
||||
- api-contracts
|
||||
- event-schemas
|
||||
- data-models
|
||||
prompts:
|
||||
- "Design the service architecture pattern"
|
||||
- "Define API contracts and event schemas"
|
||||
- "Choose appropriate data storage solutions"
|
||||
|
||||
- agent: architect
|
||||
action: Integration Design
|
||||
description: >-
|
||||
Design service mesh, messaging, and integration patterns
|
||||
inputs:
|
||||
- service-architecture
|
||||
- integration-requirements
|
||||
outputs:
|
||||
- integration-architecture
|
||||
- messaging-patterns
|
||||
- service-mesh-config
|
||||
prompts:
|
||||
- "Design inter-service communication"
|
||||
- "Choose messaging patterns (sync/async)"
|
||||
- "Define service discovery approach"
|
||||
|
||||
- id: reliability-design
|
||||
name: Reliability & Performance
|
||||
description: Design for production reliability
|
||||
steps:
|
||||
- agent: devops
|
||||
action: Production Architecture
|
||||
description: >-
|
||||
Design deployment, scaling, and reliability features
|
||||
inputs:
|
||||
- service-architecture
|
||||
outputs:
|
||||
- deployment-architecture
|
||||
- scaling-strategy
|
||||
- reliability-patterns
|
||||
- observability-design
|
||||
prompts:
|
||||
- "Design auto-scaling and load balancing"
|
||||
- "Plan fault tolerance and circuit breakers"
|
||||
- "Design comprehensive observability"
|
||||
|
||||
- agent: architect
|
||||
action: Performance Design
|
||||
description: >-
|
||||
Design caching, optimization, and performance strategies
|
||||
inputs:
|
||||
- service-architecture
|
||||
- data-flow-analysis
|
||||
outputs:
|
||||
- performance-architecture
|
||||
- caching-strategy
|
||||
- query-optimization
|
||||
prompts:
|
||||
- "Identify performance bottlenecks"
|
||||
- "Design caching layers"
|
||||
- "Optimize data access patterns"
|
||||
|
||||
- id: security-design
|
||||
name: Security Architecture
|
||||
description: Design security controls and compliance
|
||||
steps:
|
||||
- agent: architect
|
||||
action: Security Design
|
||||
description: >-
|
||||
Design authentication, authorization, and data security
|
||||
inputs:
|
||||
- service-architecture
|
||||
- api-contracts
|
||||
outputs:
|
||||
- security-architecture
|
||||
- auth-design
|
||||
- encryption-strategy
|
||||
- compliance-controls
|
||||
prompts:
|
||||
- "Design authentication and authorization"
|
||||
- "Plan data encryption at rest and in transit"
|
||||
- "Address compliance requirements"
|
||||
|
||||
- id: validation
|
||||
name: Architecture Validation
|
||||
description: Validate complete service design
|
||||
steps:
|
||||
- agent: po
|
||||
action: Service Design Review
|
||||
description: >-
|
||||
Review service design for completeness and alignment
|
||||
inputs:
|
||||
- service-architecture
|
||||
- integration-architecture
|
||||
- security-architecture
|
||||
outputs:
|
||||
- design-approval
|
||||
- risk-assessment
|
||||
prompts:
|
||||
- "Review service boundaries and responsibilities"
|
||||
- "Validate non-functional requirements"
|
||||
|
||||
- id: implementation-planning
|
||||
name: Implementation Planning
|
||||
description: Plan service implementation
|
||||
steps:
|
||||
- agent: sm
|
||||
action: Service Implementation Stories
|
||||
description: >-
|
||||
Create implementation stories with clear boundaries
|
||||
inputs:
|
||||
- service-architecture
|
||||
- api-contracts
|
||||
outputs:
|
||||
- implementation-stories
|
||||
- api-development-plan
|
||||
- integration-test-plan
|
||||
prompts:
|
||||
- "Break down into implementation stories"
|
||||
- "Define story dependencies"
|
||||
- "Plan incremental delivery"
|
||||
|
||||
- agent: qa
|
||||
action: Service Testing Strategy
|
||||
description: >-
|
||||
Design testing strategy for distributed systems
|
||||
inputs:
|
||||
- service-architecture
|
||||
- integration-architecture
|
||||
outputs:
|
||||
- test-strategy
|
||||
- contract-testing-plan
|
||||
- chaos-testing-plan
|
||||
- performance-test-plan
|
||||
prompts:
|
||||
- "Design contract testing approach"
|
||||
- "Plan chaos engineering tests"
|
||||
- "Define performance benchmarks"
|
||||
|
||||
- id: operational-readiness
|
||||
name: Operational Readiness
|
||||
description: Prepare for production deployment
|
||||
steps:
|
||||
- agent: devops
|
||||
action: Production Readiness
|
||||
description: >-
|
||||
Create runbooks, monitoring, and deployment procedures
|
||||
inputs:
|
||||
- deployment-architecture
|
||||
- observability-design
|
||||
outputs:
|
||||
- runbooks
|
||||
- monitoring-dashboards
|
||||
- alert-rules
|
||||
- deployment-procedures
|
||||
prompts:
|
||||
- "Create operational runbooks"
|
||||
- "Design monitoring dashboards"
|
||||
- "Define SLIs and SLOs"
|
||||
|
||||
transitions:
|
||||
- from: service-discovery
|
||||
to: service-design
|
||||
condition: requirements defined
|
||||
- from: service-design
|
||||
to: reliability-design
|
||||
condition: architecture completed
|
||||
- from: reliability-design
|
||||
to: security-design
|
||||
condition: reliability planned
|
||||
- from: security-design
|
||||
to: validation
|
||||
condition: security designed
|
||||
- from: validation
|
||||
to: implementation-planning
|
||||
condition: design approved
|
||||
- from: implementation-planning
|
||||
to: operational-readiness
|
||||
condition: stories created
|
||||
|
||||
key_artifacts:
|
||||
- Service architecture document
|
||||
- API contracts and schemas
|
||||
- Integration architecture
|
||||
- Security controls
|
||||
- Operational runbooks
|
||||
- Test strategies
|
||||
@@ -1,6 +1,6 @@
|
||||
workflow:
|
||||
id: brownfield-enhancement
|
||||
name: Brownfield Enhancement
|
||||
id: brownfield-fullstack
|
||||
name: Brownfield Full-Stack Enhancement
|
||||
description: >-
|
||||
Workflow for adding features, refactoring, or modernizing existing applications.
|
||||
Handles legacy code analysis and incremental improvements.
|
||||
@@ -33,7 +33,7 @@ workflow:
|
||||
- "Share any existing documentation or system diagrams"
|
||||
- "You can also share the codebase if you have access to it"
|
||||
|
||||
- agent: dev
|
||||
- agent: fullstack-architect
|
||||
action: Code Analysis
|
||||
description: >-
|
||||
Deep dive into codebase quality and structure
|
||||
@@ -66,7 +66,7 @@ workflow:
|
||||
- "What specific enhancements are we targeting?"
|
||||
- "Define success metrics for these improvements"
|
||||
|
||||
- agent: architect
|
||||
- agent: fullstack-architect
|
||||
action: Integration Architecture
|
||||
description: >-
|
||||
Design how new features integrate with existing system
|
||||
253
agent-team-workflows/brownfield-service.yml
Normal file
253
agent-team-workflows/brownfield-service.yml
Normal file
@@ -0,0 +1,253 @@
|
||||
workflow:
|
||||
id: brownfield-service
|
||||
name: Brownfield Service/API Enhancement
|
||||
description: >-
|
||||
Workflow for modernizing, refactoring, or enhancing existing backend services and APIs.
|
||||
Handles performance optimization, API versioning, microservice extraction, and technical debt.
|
||||
type: brownfield
|
||||
project_types:
|
||||
- service-modernization
|
||||
- api-enhancement
|
||||
- microservice-extraction
|
||||
- performance-optimization
|
||||
- technical-debt-reduction
|
||||
|
||||
stages:
|
||||
- id: service-analysis
|
||||
name: Service Assessment
|
||||
description: Analyze existing service and identify improvement areas
|
||||
steps:
|
||||
- agent: analyst
|
||||
action: Service Assessment
|
||||
description: >-
|
||||
Analyze current service architecture, performance, and technical debt
|
||||
inputs:
|
||||
- existing-service-code
|
||||
- performance-metrics
|
||||
- error-logs
|
||||
outputs:
|
||||
- service-assessment
|
||||
- performance-bottlenecks
|
||||
- technical-debt-analysis
|
||||
- integration-dependencies
|
||||
prompts:
|
||||
- "Let's analyze the current service architecture"
|
||||
- "What performance issues are you experiencing?"
|
||||
- "Share service metrics, logs, or documentation"
|
||||
|
||||
- agent: fullstack-architect
|
||||
action: Architecture Analysis
|
||||
description: >-
|
||||
Deep dive into service architecture and identify improvement opportunities
|
||||
inputs:
|
||||
- service-assessment
|
||||
- existing-service-code
|
||||
outputs:
|
||||
- architecture-assessment
|
||||
- refactoring-opportunities
|
||||
- modernization-candidates
|
||||
prompts:
|
||||
- "Analyze the service architecture patterns"
|
||||
- "Identify areas for modernization"
|
||||
|
||||
- id: enhancement-planning
|
||||
name: Service Enhancement Strategy
|
||||
description: Plan service improvements and modernization approach
|
||||
steps:
|
||||
- agent: pm
|
||||
action: Enhancement Strategy
|
||||
description: >-
|
||||
Define enhancement goals, priorities, and migration strategy
|
||||
inputs:
|
||||
- service-assessment
|
||||
- architecture-assessment
|
||||
outputs:
|
||||
- enhancement-strategy
|
||||
- migration-roadmap
|
||||
- risk-assessment
|
||||
prompts:
|
||||
- "What are the primary enhancement goals?"
|
||||
- "Define the migration strategy and timeline"
|
||||
|
||||
- agent: fullstack-architect
|
||||
action: Modernization Architecture
|
||||
description: >-
|
||||
Design target architecture for service modernization
|
||||
inputs:
|
||||
- enhancement-strategy
|
||||
- modernization-candidates
|
||||
outputs:
|
||||
- target-architecture
|
||||
- migration-patterns
|
||||
- backward-compatibility-plan
|
||||
prompts:
|
||||
- "Design the target service architecture"
|
||||
- "Plan for backward compatibility during migration"
|
||||
|
||||
- id: incremental-refactoring
|
||||
name: Incremental Refactoring Design
|
||||
description: Design safe, incremental refactoring approach
|
||||
steps:
|
||||
- agent: fullstack-architect
|
||||
action: Refactoring Strategy
|
||||
description: >-
|
||||
Design strangler fig pattern or other safe refactoring approaches
|
||||
inputs:
|
||||
- target-architecture
|
||||
- integration-dependencies
|
||||
outputs:
|
||||
- refactoring-strategy
|
||||
- service-extraction-plan
|
||||
- data-migration-strategy
|
||||
prompts:
|
||||
- "Design strangler fig or parallel run strategy"
|
||||
- "Plan service extraction and data migration"
|
||||
|
||||
- agent: devops
|
||||
action: Infrastructure Evolution
|
||||
description: >-
|
||||
Plan infrastructure changes and deployment strategy
|
||||
inputs:
|
||||
- refactoring-strategy
|
||||
- target-architecture
|
||||
outputs:
|
||||
- infrastructure-migration
|
||||
- deployment-strategy
|
||||
- monitoring-evolution
|
||||
- scaling-improvements
|
||||
prompts:
|
||||
- "Plan infrastructure for new architecture"
|
||||
- "Design zero-downtime deployment strategy"
|
||||
|
||||
- id: api-evolution
|
||||
name: API Versioning & Evolution
|
||||
description: Plan API changes and versioning strategy
|
||||
steps:
|
||||
- agent: fullstack-architect
|
||||
action: API Evolution Strategy
|
||||
description: >-
|
||||
Design API versioning and backward compatibility
|
||||
inputs:
|
||||
- target-architecture
|
||||
- integration-dependencies
|
||||
outputs:
|
||||
- api-versioning-strategy
|
||||
- contract-evolution-plan
|
||||
- deprecation-timeline
|
||||
prompts:
|
||||
- "Design API versioning strategy"
|
||||
- "Plan contract evolution and deprecation"
|
||||
|
||||
- id: data-strategy
|
||||
name: Data Migration & Consistency
|
||||
description: Plan data migration and consistency strategies
|
||||
steps:
|
||||
- agent: fullstack-architect
|
||||
action: Data Migration Planning
|
||||
description: >-
|
||||
Plan data migration, consistency, and synchronization
|
||||
inputs:
|
||||
- refactoring-strategy
|
||||
- data-migration-strategy
|
||||
outputs:
|
||||
- data-migration-plan
|
||||
- consistency-strategy
|
||||
- rollback-procedures
|
||||
prompts:
|
||||
- "Plan data migration with zero data loss"
|
||||
- "Design data consistency during transition"
|
||||
|
||||
- id: quality-assurance
|
||||
name: Testing & Quality Strategy
|
||||
description: Plan comprehensive testing for service changes
|
||||
steps:
|
||||
- agent: qa
|
||||
action: Service Testing Strategy
|
||||
description: >-
|
||||
Design testing approach for service modernization
|
||||
inputs:
|
||||
- refactoring-strategy
|
||||
- api-versioning-strategy
|
||||
outputs:
|
||||
- service-test-strategy
|
||||
- contract-testing-plan
|
||||
- performance-testing-plan
|
||||
- chaos-testing-strategy
|
||||
prompts:
|
||||
- "Design comprehensive service testing"
|
||||
- "Plan contract tests for API evolution"
|
||||
- "Design chaos engineering tests"
|
||||
|
||||
- id: monitoring-observability
|
||||
name: Enhanced Observability
|
||||
description: Plan improved monitoring and observability
|
||||
steps:
|
||||
- agent: devops
|
||||
action: Observability Enhancement
|
||||
description: >-
|
||||
Design enhanced monitoring, logging, and alerting
|
||||
inputs:
|
||||
- target-architecture
|
||||
- performance-bottlenecks
|
||||
outputs:
|
||||
- observability-strategy
|
||||
- sli-slo-definitions
|
||||
- alerting-improvements
|
||||
- dashboards-design
|
||||
prompts:
|
||||
- "Design comprehensive service observability"
|
||||
- "Define SLIs and SLOs for the service"
|
||||
|
||||
- id: implementation-planning
|
||||
name: Phased Implementation
|
||||
description: Create detailed implementation plan
|
||||
steps:
|
||||
- agent: sm
|
||||
action: Migration Story Planning
|
||||
description: >-
|
||||
Create stories for incremental service migration
|
||||
inputs:
|
||||
- migration-roadmap
|
||||
- refactoring-strategy
|
||||
outputs:
|
||||
- migration-stories
|
||||
- implementation-phases
|
||||
- dependency-management
|
||||
prompts:
|
||||
- "Break down migration into safe phases"
|
||||
- "Plan story dependencies and risks"
|
||||
|
||||
transitions:
|
||||
- from: service-analysis
|
||||
to: enhancement-planning
|
||||
condition: assessment complete
|
||||
- from: enhancement-planning
|
||||
to: incremental-refactoring
|
||||
condition: strategy defined
|
||||
- from: incremental-refactoring
|
||||
to: api-evolution
|
||||
condition: refactoring planned
|
||||
- from: api-evolution
|
||||
to: data-strategy
|
||||
condition: api strategy defined
|
||||
- from: data-strategy
|
||||
to: quality-assurance
|
||||
condition: data strategy planned
|
||||
- from: quality-assurance
|
||||
to: monitoring-observability
|
||||
condition: testing planned
|
||||
- from: monitoring-observability
|
||||
to: implementation-planning
|
||||
condition: observability designed
|
||||
|
||||
special_considerations:
|
||||
- name: Zero Downtime
|
||||
description: Ensure service remains available during migration
|
||||
- name: Data Integrity
|
||||
description: Maintain data consistency throughout migration
|
||||
- name: Client Impact
|
||||
description: Minimize impact on service consumers
|
||||
- name: Rollback Plan
|
||||
description: Always have a way to revert changes safely
|
||||
- name: Performance SLA
|
||||
description: Maintain or improve existing performance SLAs
|
||||
217
agent-team-workflows/brownfield-ui.yml
Normal file
217
agent-team-workflows/brownfield-ui.yml
Normal file
@@ -0,0 +1,217 @@
|
||||
workflow:
|
||||
id: brownfield-ui
|
||||
name: Brownfield UI/Frontend Enhancement
|
||||
description: >-
|
||||
Workflow for modernizing, redesigning, or enhancing existing frontend applications.
|
||||
Handles UI/UX improvements, framework migrations, and frontend refactoring.
|
||||
type: brownfield
|
||||
project_types:
|
||||
- ui-modernization
|
||||
- framework-migration
|
||||
- design-refresh
|
||||
- frontend-refactoring
|
||||
|
||||
stages:
|
||||
- id: ui-analysis
|
||||
name: Current UI Assessment
|
||||
description: Analyze existing frontend and identify improvement areas
|
||||
steps:
|
||||
- agent: analyst
|
||||
action: Frontend Assessment
|
||||
description: >-
|
||||
Analyze current frontend, user feedback, and performance issues
|
||||
inputs:
|
||||
- existing-frontend
|
||||
- user-feedback
|
||||
- analytics-data
|
||||
outputs:
|
||||
- frontend-assessment
|
||||
- usability-issues
|
||||
- performance-analysis
|
||||
prompts:
|
||||
- "Let's analyze the current frontend application"
|
||||
- "What are users' main pain points with the current UI?"
|
||||
- "Share analytics data or user feedback if available"
|
||||
|
||||
- agent: ux-expert
|
||||
action: UX Audit
|
||||
description: >-
|
||||
Conduct comprehensive UX audit and competitive analysis
|
||||
inputs:
|
||||
- frontend-assessment
|
||||
- user-feedback
|
||||
outputs:
|
||||
- ux-audit-report
|
||||
- competitor-analysis
|
||||
- accessibility-audit
|
||||
prompts:
|
||||
- "Let's audit the current user experience"
|
||||
- "How do competitors handle similar flows?"
|
||||
|
||||
- id: enhancement-strategy
|
||||
name: UI Enhancement Strategy
|
||||
description: Define UI improvement strategy and goals
|
||||
steps:
|
||||
- agent: pm
|
||||
action: UI Enhancement Planning
|
||||
description: >-
|
||||
Define enhancement goals, priorities, and success metrics
|
||||
inputs:
|
||||
- ux-audit-report
|
||||
- usability-issues
|
||||
outputs:
|
||||
- ui-enhancement-strategy
|
||||
- improvement-priorities
|
||||
- success-metrics
|
||||
prompts:
|
||||
- "What are the priority UI improvements?"
|
||||
- "Define success metrics for the redesign"
|
||||
|
||||
- agent: ux-expert
|
||||
action: Design Strategy
|
||||
description: >-
|
||||
Create design strategy and visual direction
|
||||
inputs:
|
||||
- ui-enhancement-strategy
|
||||
- competitor-analysis
|
||||
outputs:
|
||||
- design-strategy
|
||||
- visual-direction
|
||||
- brand-evolution
|
||||
prompts:
|
||||
- "Define the new visual direction"
|
||||
- "How should the brand evolve?"
|
||||
|
||||
- id: incremental-design
|
||||
name: Incremental UI Design
|
||||
description: Design improvements that can be rolled out incrementally
|
||||
steps:
|
||||
- agent: ux-expert
|
||||
action: Progressive Design System
|
||||
description: >-
|
||||
Create new design system that can coexist with existing UI
|
||||
inputs:
|
||||
- design-strategy
|
||||
- frontend-assessment
|
||||
outputs:
|
||||
- progressive-design-system
|
||||
- component-migration-plan
|
||||
- style-guide-evolution
|
||||
prompts:
|
||||
- "Design a system that can coexist with current UI"
|
||||
- "Plan component-by-component migration"
|
||||
|
||||
- agent: ui-architect
|
||||
action: Frontend Migration Architecture
|
||||
description: >-
|
||||
Design technical approach for gradual frontend migration
|
||||
inputs:
|
||||
- progressive-design-system
|
||||
- existing-frontend
|
||||
outputs:
|
||||
- migration-architecture
|
||||
- component-strategy
|
||||
- bundling-strategy
|
||||
prompts:
|
||||
- "Design incremental migration approach"
|
||||
- "How to avoid breaking existing functionality?"
|
||||
|
||||
- id: user-validation
|
||||
name: User Testing & Validation
|
||||
description: Validate new designs with users
|
||||
steps:
|
||||
- agent: ux-expert
|
||||
action: Prototype & Test
|
||||
description: >-
|
||||
Create prototypes and conduct user testing
|
||||
inputs:
|
||||
- progressive-design-system
|
||||
- improvement-priorities
|
||||
outputs:
|
||||
- interactive-prototypes
|
||||
- user-testing-results
|
||||
- design-iterations
|
||||
prompts:
|
||||
- "Let's create testable prototypes"
|
||||
- "Test with real users and iterate"
|
||||
|
||||
- id: technical-planning
|
||||
name: Implementation Planning
|
||||
description: Plan technical implementation of UI changes
|
||||
steps:
|
||||
- agent: ui-architect
|
||||
action: Technical Implementation Plan
|
||||
description: >-
|
||||
Create detailed technical plan for UI migration
|
||||
inputs:
|
||||
- migration-architecture
|
||||
- design-iterations
|
||||
outputs:
|
||||
- implementation-roadmap
|
||||
- risk-mitigation-plan
|
||||
- rollback-strategy
|
||||
prompts:
|
||||
- "Create step-by-step implementation plan"
|
||||
- "Plan for safe rollbacks if needed"
|
||||
|
||||
- agent: qa
|
||||
action: UI Testing Strategy
|
||||
description: >-
|
||||
Plan testing approach for UI changes
|
||||
inputs:
|
||||
- implementation-roadmap
|
||||
- user-testing-results
|
||||
outputs:
|
||||
- ui-test-strategy
|
||||
- visual-regression-tests
|
||||
- cross-browser-testing
|
||||
- accessibility-testing
|
||||
prompts:
|
||||
- "Plan comprehensive UI testing"
|
||||
- "Ensure no regressions in existing flows"
|
||||
|
||||
- id: deployment-strategy
|
||||
name: Gradual Rollout Planning
|
||||
description: Plan safe deployment of UI changes
|
||||
steps:
|
||||
- agent: ui-architect
|
||||
action: Feature Flag Strategy
|
||||
description: >-
|
||||
Design feature flagging for gradual UI rollout
|
||||
inputs:
|
||||
- implementation-roadmap
|
||||
- risk-mitigation-plan
|
||||
outputs:
|
||||
- feature-flag-design
|
||||
- a-b-testing-plan
|
||||
- monitoring-strategy
|
||||
prompts:
|
||||
- "Design A/B testing for new UI components"
|
||||
- "Plan feature flags for safe rollout"
|
||||
|
||||
transitions:
|
||||
- from: ui-analysis
|
||||
to: enhancement-strategy
|
||||
condition: assessment complete
|
||||
- from: enhancement-strategy
|
||||
to: incremental-design
|
||||
condition: strategy defined
|
||||
- from: incremental-design
|
||||
to: user-validation
|
||||
condition: designs ready
|
||||
- from: user-validation
|
||||
to: technical-planning
|
||||
condition: designs validated
|
||||
- from: technical-planning
|
||||
to: deployment-strategy
|
||||
condition: implementation planned
|
||||
|
||||
special_considerations:
|
||||
- name: User Adoption
|
||||
description: Plan for user training and change management
|
||||
- name: SEO Impact
|
||||
description: Ensure URL structure and SEO aren't negatively affected
|
||||
- name: Performance
|
||||
description: Maintain or improve existing performance metrics
|
||||
- name: Analytics
|
||||
description: Preserve analytics tracking through UI changes
|
||||
@@ -1,219 +0,0 @@
|
||||
workflow:
|
||||
id: frontend-only
|
||||
name: Frontend Application Development
|
||||
description: >-
|
||||
Workflow for building frontend applications that consume existing APIs.
|
||||
Perfect for SPAs, mobile apps, or micro-frontends.
|
||||
type: greenfield
|
||||
project_types:
|
||||
- spa
|
||||
- mobile-app
|
||||
- micro-frontend
|
||||
- static-site
|
||||
|
||||
stages:
|
||||
- id: frontend-discovery
|
||||
name: Frontend Requirements
|
||||
description: Understand user needs and API constraints
|
||||
steps:
|
||||
- agent: analyst
|
||||
action: Frontend Analysis
|
||||
description: >-
|
||||
Analyze user needs, existing APIs, and frontend requirements
|
||||
inputs:
|
||||
- api-documentation
|
||||
- user-requirements
|
||||
outputs:
|
||||
- frontend-brief
|
||||
- api-integration-plan
|
||||
prompts:
|
||||
- "What APIs will the frontend consume?"
|
||||
- "What are the key user interactions?"
|
||||
|
||||
- id: ux-design
|
||||
name: User Experience Design
|
||||
description: Design complete user experience
|
||||
steps:
|
||||
- agent: ux-expert
|
||||
action: Complete UX Process
|
||||
description: >-
|
||||
User research, personas, flows, wireframes, and prototypes
|
||||
inputs:
|
||||
- frontend-brief
|
||||
outputs:
|
||||
- user-research
|
||||
- personas
|
||||
- user-flows
|
||||
- wireframes
|
||||
- interactive-prototype
|
||||
prompts:
|
||||
- "Let's understand your users deeply"
|
||||
- "Design the complete user journey"
|
||||
|
||||
- agent: ux-expert
|
||||
action: Visual Design
|
||||
description: >-
|
||||
Create visual designs and style guide
|
||||
inputs:
|
||||
- wireframes
|
||||
- brand-guidelines
|
||||
outputs:
|
||||
- visual-designs
|
||||
- style-guide
|
||||
- design-tokens
|
||||
prompts:
|
||||
- "Create the visual language"
|
||||
- "Define colors, typography, and spacing"
|
||||
|
||||
- id: frontend-architecture
|
||||
name: Frontend Technical Design
|
||||
description: Design frontend architecture and components
|
||||
steps:
|
||||
- agent: ui-architect
|
||||
action: Frontend Architecture
|
||||
description: >-
|
||||
Design component architecture, state management, and routing
|
||||
inputs:
|
||||
- interactive-prototype
|
||||
- api-integration-plan
|
||||
outputs:
|
||||
- frontend-architecture
|
||||
- component-hierarchy
|
||||
- state-management-design
|
||||
- routing-design
|
||||
prompts:
|
||||
- "Design the frontend architecture"
|
||||
- "Choose framework and design patterns"
|
||||
|
||||
- agent: ui-architect
|
||||
action: Component Design System
|
||||
description: >-
|
||||
Create detailed component specifications and AI generation prompts
|
||||
inputs:
|
||||
- visual-designs
|
||||
- design-tokens
|
||||
outputs:
|
||||
- component-library-spec
|
||||
- ai-generation-prompts
|
||||
- accessibility-guidelines
|
||||
prompts:
|
||||
- "Design reusable component system"
|
||||
- "Create prompts for AI UI generation"
|
||||
|
||||
- id: api-integration
|
||||
name: API Integration Planning
|
||||
description: Plan API integration and data flow
|
||||
steps:
|
||||
- agent: fullstack-architect
|
||||
action: Integration Architecture
|
||||
description: >-
|
||||
Design API integration, data fetching, and caching strategies
|
||||
inputs:
|
||||
- api-documentation
|
||||
- frontend-architecture
|
||||
outputs:
|
||||
- integration-patterns
|
||||
- data-flow-design
|
||||
- error-handling-strategy
|
||||
- caching-strategy
|
||||
prompts:
|
||||
- "Design efficient API integration"
|
||||
- "Plan offline capabilities if needed"
|
||||
|
||||
- id: performance-planning
|
||||
name: Performance & Optimization
|
||||
description: Plan for optimal performance
|
||||
steps:
|
||||
- agent: ui-architect
|
||||
action: Performance Strategy
|
||||
description: >-
|
||||
Design performance optimization and PWA features
|
||||
inputs:
|
||||
- frontend-architecture
|
||||
outputs:
|
||||
- performance-budget
|
||||
- optimization-strategy
|
||||
- pwa-features
|
||||
prompts:
|
||||
- "Set performance budgets"
|
||||
- "Plan lazy loading and code splitting"
|
||||
|
||||
- id: validation
|
||||
name: Design Validation
|
||||
description: Validate all frontend designs
|
||||
steps:
|
||||
- agent: po
|
||||
action: Frontend Validation
|
||||
description: >-
|
||||
Validate UX, technical design, and accessibility
|
||||
inputs:
|
||||
- visual-designs
|
||||
- frontend-architecture
|
||||
- component-library-spec
|
||||
outputs:
|
||||
- design-approval
|
||||
- accessibility-review
|
||||
prompts:
|
||||
- "Review all designs for consistency"
|
||||
- "Validate accessibility compliance"
|
||||
|
||||
- id: development-planning
|
||||
name: Frontend Development Planning
|
||||
description: Plan implementation sprints
|
||||
steps:
|
||||
- agent: sm
|
||||
action: Frontend Stories
|
||||
description: >-
|
||||
Create component and feature stories
|
||||
inputs:
|
||||
- component-library-spec
|
||||
- frontend-architecture
|
||||
outputs:
|
||||
- component-stories
|
||||
- feature-stories
|
||||
- sprint-plan
|
||||
prompts:
|
||||
- "Break down into component stories"
|
||||
- "Plan progressive enhancement"
|
||||
|
||||
- agent: qa
|
||||
action: Frontend Testing Strategy
|
||||
description: >-
|
||||
Plan unit, integration, and E2E testing
|
||||
inputs:
|
||||
- component-stories
|
||||
- user-flows
|
||||
outputs:
|
||||
- test-strategy
|
||||
- e2e-test-scenarios
|
||||
- visual-regression-tests
|
||||
prompts:
|
||||
- "Design component testing approach"
|
||||
- "Plan E2E test scenarios"
|
||||
|
||||
transitions:
|
||||
- from: frontend-discovery
|
||||
to: ux-design
|
||||
condition: requirements understood
|
||||
- from: ux-design
|
||||
to: frontend-architecture
|
||||
condition: designs completed
|
||||
- from: frontend-architecture
|
||||
to: api-integration
|
||||
condition: architecture defined
|
||||
- from: api-integration
|
||||
to: performance-planning
|
||||
condition: integration planned
|
||||
- from: performance-planning
|
||||
to: validation
|
||||
condition: optimization planned
|
||||
- from: validation
|
||||
to: development-planning
|
||||
condition: designs approved
|
||||
|
||||
deliverables:
|
||||
- Interactive prototype
|
||||
- Component library specification
|
||||
- AI UI generation prompts
|
||||
- Frontend architecture document
|
||||
- Performance optimization plan
|
||||
@@ -1,227 +0,0 @@
|
||||
workflow:
|
||||
id: fullstack-app
|
||||
name: Full-Stack Application Development
|
||||
description: >-
|
||||
Comprehensive workflow for building production-ready full-stack applications
|
||||
with emphasis on UI/UX and scalable architecture.
|
||||
type: greenfield
|
||||
project_types:
|
||||
- web-app
|
||||
- saas
|
||||
- enterprise-app
|
||||
|
||||
stages:
|
||||
- id: discovery
|
||||
name: Discovery & Analysis
|
||||
description: Deep dive into requirements and market analysis
|
||||
steps:
|
||||
- agent: analyst
|
||||
action: Market & Requirements Analysis
|
||||
description: >-
|
||||
Analyze market, competitors, and gather detailed requirements
|
||||
outputs:
|
||||
- project-brief
|
||||
- market-analysis
|
||||
prompts:
|
||||
- "Let's analyze the market landscape for your application"
|
||||
- "What are your competitive advantages?"
|
||||
|
||||
- id: product-design
|
||||
name: Product Design
|
||||
description: Create comprehensive product specifications
|
||||
steps:
|
||||
- agent: pm
|
||||
action: Create Detailed PRD
|
||||
description: >-
|
||||
Create comprehensive PRD with user stories and success metrics
|
||||
inputs:
|
||||
- project-brief
|
||||
- market-analysis
|
||||
outputs:
|
||||
- prd
|
||||
- success-metrics
|
||||
prompts:
|
||||
- "Let's define detailed features and user stories"
|
||||
- "What metrics will measure success?"
|
||||
|
||||
- agent: ux-expert
|
||||
action: Complete UX Design
|
||||
description: >-
|
||||
Create user research, personas, flows, and detailed wireframes
|
||||
inputs:
|
||||
- prd
|
||||
outputs:
|
||||
- user-personas
|
||||
- user-flows
|
||||
- wireframes
|
||||
- ui-specifications
|
||||
prompts:
|
||||
- "Let's create detailed user personas"
|
||||
- "Time to design the complete user experience"
|
||||
|
||||
- id: ui-development
|
||||
name: UI Design & Prototyping
|
||||
description: Create high-fidelity designs and interactive prototypes
|
||||
steps:
|
||||
- agent: ui-architect
|
||||
action: UI Architecture & Design System
|
||||
description: >-
|
||||
Create design system, component library specs, and UI architecture
|
||||
inputs:
|
||||
- wireframes
|
||||
- ui-specifications
|
||||
outputs:
|
||||
- design-system
|
||||
- component-specs
|
||||
- ui-architecture
|
||||
prompts:
|
||||
- "Let's create a scalable design system"
|
||||
- "Define reusable component architecture"
|
||||
|
||||
- agent: ux-expert
|
||||
action: Generate UI Components
|
||||
description: >-
|
||||
Create AI prompts and generate actual UI components
|
||||
inputs:
|
||||
- design-system
|
||||
- component-specs
|
||||
outputs:
|
||||
- ui-generation-prompts
|
||||
- generated-components
|
||||
prompts:
|
||||
- "Let's create prompts for AI UI generation"
|
||||
- "Generate the core UI components"
|
||||
|
||||
- id: technical-architecture
|
||||
name: System Architecture
|
||||
description: Design complete technical architecture
|
||||
steps:
|
||||
- agent: fullstack-architect
|
||||
action: System Architecture Design
|
||||
description: >-
|
||||
Design complete system including microservices, APIs, and infrastructure
|
||||
inputs:
|
||||
- prd
|
||||
- ui-architecture
|
||||
outputs:
|
||||
- system-architecture
|
||||
- api-specifications
|
||||
- data-models
|
||||
prompts:
|
||||
- "Design the complete system architecture"
|
||||
- "Define API contracts and data models"
|
||||
|
||||
- agent: architect
|
||||
action: Backend Architecture
|
||||
description: >-
|
||||
Detail backend services, integrations, and technical specifications
|
||||
inputs:
|
||||
- system-architecture
|
||||
- api-specifications
|
||||
outputs:
|
||||
- backend-architecture
|
||||
- integration-specs
|
||||
prompts:
|
||||
- "Detail the backend service architecture"
|
||||
- "Define third-party integrations"
|
||||
|
||||
- agent: devops
|
||||
action: Infrastructure Design
|
||||
description: >-
|
||||
Design cloud infrastructure, CI/CD, and deployment architecture
|
||||
inputs:
|
||||
- system-architecture
|
||||
outputs:
|
||||
- infrastructure-design
|
||||
- deployment-architecture
|
||||
- ci-cd-pipeline
|
||||
prompts:
|
||||
- "Design the cloud infrastructure"
|
||||
- "Create CI/CD pipeline specifications"
|
||||
|
||||
- id: validation
|
||||
name: Comprehensive Validation
|
||||
description: Validate all artifacts and ensure alignment
|
||||
steps:
|
||||
- agent: po
|
||||
action: Full Artifact Validation
|
||||
description: >-
|
||||
Validate all documents, ensure alignment, and approve for development
|
||||
inputs:
|
||||
- prd
|
||||
- system-architecture
|
||||
- ui-architecture
|
||||
- infrastructure-design
|
||||
outputs:
|
||||
- validation-report
|
||||
- approved-artifacts
|
||||
prompts:
|
||||
- "Complete validation of all artifacts"
|
||||
- "Any final adjustments needed?"
|
||||
|
||||
- id: development-planning
|
||||
name: Sprint Planning
|
||||
description: Create detailed development plan and stories
|
||||
steps:
|
||||
- agent: sm
|
||||
action: Create Sprint Plan
|
||||
description: >-
|
||||
Create epics, user stories, and detailed sprint plan
|
||||
inputs:
|
||||
- approved-artifacts
|
||||
outputs:
|
||||
- epics
|
||||
- user-stories
|
||||
- sprint-plan
|
||||
- definition-of-done
|
||||
prompts:
|
||||
- "Let's break this into epics and stories"
|
||||
- "Create the sprint roadmap"
|
||||
|
||||
- id: quality-planning
|
||||
name: Quality Assurance Planning
|
||||
description: Define testing strategy and quality metrics
|
||||
steps:
|
||||
- agent: qa
|
||||
action: Test Strategy & Planning
|
||||
description: >-
|
||||
Create comprehensive test strategy and automation plan
|
||||
inputs:
|
||||
- prd
|
||||
- system-architecture
|
||||
- user-stories
|
||||
outputs:
|
||||
- test-strategy
|
||||
- test-cases
|
||||
- automation-plan
|
||||
prompts:
|
||||
- "Define the testing strategy"
|
||||
- "Plan test automation approach"
|
||||
|
||||
transitions:
|
||||
- from: discovery
|
||||
to: product-design
|
||||
condition: project-brief completed
|
||||
- from: product-design
|
||||
to: ui-development
|
||||
condition: prd and wireframes completed
|
||||
- from: ui-development
|
||||
to: technical-architecture
|
||||
condition: ui components designed
|
||||
- from: technical-architecture
|
||||
to: validation
|
||||
condition: all architecture completed
|
||||
- from: validation
|
||||
to: development-planning
|
||||
condition: artifacts approved
|
||||
- from: development-planning
|
||||
to: quality-planning
|
||||
condition: stories created
|
||||
|
||||
checkpoints:
|
||||
- after: product-design
|
||||
review: Stakeholder review of PRD and UX
|
||||
- after: technical-architecture
|
||||
review: Architecture review board
|
||||
- after: validation
|
||||
review: Final go/no-go decision
|
||||
126
agent-team-workflows/greenfield-fullstack.yml
Normal file
126
agent-team-workflows/greenfield-fullstack.yml
Normal file
@@ -0,0 +1,126 @@
|
||||
workflow:
|
||||
id: greenfield-fullstack
|
||||
name: Greenfield Full-Stack Application Development
|
||||
description: >-
|
||||
Agent workflow for building production-ready full-stack applications
|
||||
from concept to development-ready artifacts.
|
||||
type: greenfield
|
||||
project_types:
|
||||
- web-app
|
||||
- saas
|
||||
- enterprise-app
|
||||
|
||||
sequence:
|
||||
- agent: analyst
|
||||
creates: project-brief.md
|
||||
optional_steps:
|
||||
- brainstorming_session
|
||||
- market_research_prompt
|
||||
notes: "Can do brainstorming first, then optional deep research before creating project brief. SAVE OUTPUT: Copy final project-brief.md to your project's docs/ folder."
|
||||
|
||||
- agent: pm
|
||||
creates: prd.md
|
||||
requires: project-brief.md
|
||||
notes: "Creates PRD from project brief using prd-tmpl. SAVE OUTPUT: Copy final prd.md to your project's docs/ folder."
|
||||
|
||||
- agent: ux-expert
|
||||
creates: front-end-spec.md
|
||||
requires: prd.md
|
||||
optional_steps:
|
||||
- user_research_prompt
|
||||
notes: "Creates UI/UX specification using front-end-spec-tmpl. SAVE OUTPUT: Copy final front-end-spec.md to your project's docs/ folder."
|
||||
|
||||
- agent: ux-expert
|
||||
creates: v0_prompt (optional)
|
||||
requires: front-end-spec.md
|
||||
condition: user_wants_ai_generation
|
||||
notes: "OPTIONAL BUT RECOMMENDED: Generate AI UI prompt for tools like v0, Lovable, etc. Use the generate-ai-frontend-prompt task. User can then generate UI in external tool and download project structure."
|
||||
|
||||
- agent: fullstack-architect
|
||||
creates: fullstack-architecture.md
|
||||
requires:
|
||||
- prd.md
|
||||
- front-end-spec.md
|
||||
optional_steps:
|
||||
- technical_research_prompt
|
||||
- review_generated_ui_structure
|
||||
notes: "Creates comprehensive architecture using fullstack-architecture-tmpl. If user generated UI with v0/Lovable, can incorporate the project structure into architecture. May suggest changes to PRD stories or new stories. SAVE OUTPUT: Copy final fullstack-architecture.md to your project's docs/ folder."
|
||||
|
||||
- agent: pm
|
||||
updates: prd.md (if needed)
|
||||
requires: fullstack-architecture.md
|
||||
condition: architecture_suggests_prd_changes
|
||||
notes: "If architect suggests story changes, update PRD and re-export the complete unredacted prd.md to docs/ folder."
|
||||
|
||||
- agent: po
|
||||
validates: all_artifacts
|
||||
uses: po-master-checklist
|
||||
notes: "Validates all documents for consistency and completeness. May require updates to any document."
|
||||
|
||||
- agent: various
|
||||
updates: any_flagged_documents
|
||||
condition: po_checklist_issues
|
||||
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
|
||||
|
||||
- project_setup_guidance:
|
||||
action: guide_project_structure
|
||||
condition: user_has_generated_ui
|
||||
notes: "If user generated UI with v0/Lovable: For polyrepo setup, place downloaded project in separate frontend repo alongside backend repo. For monorepo, place in apps/web or packages/frontend directory. Review architecture document for specific guidance."
|
||||
|
||||
- development_order_guidance:
|
||||
action: guide_development_sequence
|
||||
notes: "Based on PRD stories: If stories are frontend-heavy, start with frontend project/directory first. If backend-heavy or API-first, start with backend. For tightly coupled features, follow story sequence in monorepo setup. Reference sharded PRD epics for development order."
|
||||
|
||||
- workflow_end:
|
||||
action: move_to_ide
|
||||
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
|
||||
|
||||
flow_diagram: |
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Start] --> B[analyst: project-brief.md]
|
||||
B --> C[pm: prd.md]
|
||||
C --> D[ux-expert: front-end-spec.md]
|
||||
D --> D2{Generate v0 prompt?}
|
||||
D2 -->|Yes| D3[ux-expert: create v0 prompt]
|
||||
D2 -->|No| E[fullstack-architect: fullstack-architecture.md]
|
||||
D3 --> D4[User: generate UI in v0/Lovable]
|
||||
D4 --> E
|
||||
E --> F{Architecture suggests PRD changes?}
|
||||
F -->|Yes| G[pm: update prd.md]
|
||||
F -->|No| H[po: validate all artifacts]
|
||||
G --> H
|
||||
H --> I{PO finds issues?}
|
||||
I -->|Yes| J[Return to relevant agent for fixes]
|
||||
I -->|No| K{Generated UI?}
|
||||
K -->|Yes| L[Guide project structure setup]
|
||||
K -->|No| M[Guide development order]
|
||||
L --> M
|
||||
M --> N[Move to IDE Environment]
|
||||
J --> H
|
||||
|
||||
B -.-> B1[Optional: brainstorming]
|
||||
B -.-> B2[Optional: market research]
|
||||
D -.-> D1[Optional: user research]
|
||||
E -.-> E1[Optional: technical research]
|
||||
|
||||
style N fill:#90EE90
|
||||
style D3 fill:#E6E6FA
|
||||
style D4 fill:#E6E6FA
|
||||
style L fill:#E6E6FA
|
||||
style M fill:#E6E6FA
|
||||
style B fill:#FFE4B5
|
||||
style C fill:#FFE4B5
|
||||
style D fill:#FFE4B5
|
||||
style E fill:#FFE4B5
|
||||
```
|
||||
|
||||
handoff_prompts:
|
||||
analyst_to_pm: "Project brief is complete. Save it as docs/project-brief.md in your project, then create the PRD."
|
||||
pm_to_ux: "PRD is ready. Save it as docs/prd.md in your project, then create the UI/UX specification."
|
||||
ux_to_architect: "UI/UX spec complete. Save it as docs/front-end-spec.md in your project, then create the fullstack architecture."
|
||||
architect_review: "Architecture complete. Save it as docs/fullstack-architecture.md. Do you suggest any changes to the PRD stories or need new stories added?"
|
||||
architect_to_pm: "Please update the PRD with the suggested story changes, then re-export the complete prd.md to docs/."
|
||||
updated_to_po: "All documents ready in docs/ folder. Please validate all artifacts for consistency."
|
||||
po_issues: "PO found issues with [document]. Please return to [agent] to fix and re-save the updated document."
|
||||
workflow_complete: "All planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."
|
||||
@@ -1,179 +0,0 @@
|
||||
workflow:
|
||||
id: greenfield-mvp
|
||||
name: Greenfield MVP Development
|
||||
description: >-
|
||||
Complete workflow for building a new MVP from scratch. Takes you from initial
|
||||
idea through planning, architecture, and development setup.
|
||||
type: greenfield
|
||||
project_types:
|
||||
- web-app
|
||||
- mobile-app
|
||||
- full-stack
|
||||
- app with microservice rest api
|
||||
|
||||
stages:
|
||||
- id: discovery
|
||||
name: Discovery & Requirements
|
||||
description: Understand the problem space and gather requirements
|
||||
steps:
|
||||
- agent: analyst
|
||||
action: Create Project Brief
|
||||
description: >-
|
||||
Brainstorm and document the project vision, goals, and high-level requirements
|
||||
outputs:
|
||||
- project-brief
|
||||
prompts:
|
||||
- "Let's explore your project idea. What problem are you trying to solve?"
|
||||
- "Who are your target users and what are their main pain points?"
|
||||
|
||||
- id: planning
|
||||
name: Product Planning
|
||||
description: Define the product and create detailed requirements
|
||||
steps:
|
||||
- agent: pm
|
||||
action: Create PRD
|
||||
description: >-
|
||||
Transform the project brief into a comprehensive Product Requirements Document
|
||||
inputs:
|
||||
- project-brief
|
||||
outputs:
|
||||
- prd
|
||||
prompts:
|
||||
- "Based on the project brief, let's define the MVP features"
|
||||
- "What are the must-have features vs nice-to-have for launch?"
|
||||
|
||||
- agent: ux-expert
|
||||
action: Design UX Strategy
|
||||
description: >-
|
||||
Create user flows, wireframes, and UI specifications
|
||||
inputs:
|
||||
- prd
|
||||
outputs:
|
||||
- ux-strategy
|
||||
- ui-specifications
|
||||
prompts:
|
||||
- "Let's map out the user journey for the core features"
|
||||
- "What UI patterns best serve your users' needs?"
|
||||
|
||||
- id: architecture
|
||||
name: Technical Architecture
|
||||
description: Design the system architecture and technical approach
|
||||
steps:
|
||||
- agent: fullstack-architect
|
||||
action: Create Architecture Document
|
||||
description: >-
|
||||
Design comprehensive system architecture covering all layers
|
||||
inputs:
|
||||
- prd
|
||||
- ui-specifications
|
||||
outputs:
|
||||
- architecture-doc
|
||||
prompts:
|
||||
- "Let's design a scalable architecture for your MVP"
|
||||
- "What are your performance and scaling requirements?"
|
||||
|
||||
- agent: ui-architect
|
||||
action: Create Frontend Architecture
|
||||
description: >-
|
||||
Detail the frontend architecture and component design
|
||||
inputs:
|
||||
- architecture-doc
|
||||
- ui-specifications
|
||||
outputs:
|
||||
- frontend-architecture
|
||||
- ui-prompt-specs
|
||||
prompts:
|
||||
- "Let's define the frontend stack and component architecture"
|
||||
- "Should we generate UI components with AI assistance?"
|
||||
|
||||
- id: validation
|
||||
name: Validation & Refinement
|
||||
description: Review and validate all planning artifacts
|
||||
steps:
|
||||
- agent: po
|
||||
action: Validate Artifacts
|
||||
description: >-
|
||||
Review all documents for consistency and completeness
|
||||
inputs:
|
||||
- project-brief
|
||||
- prd
|
||||
- architecture-doc
|
||||
- frontend-architecture
|
||||
outputs:
|
||||
- validation-report
|
||||
- change-requests
|
||||
prompts:
|
||||
- "Let's review all artifacts for consistency"
|
||||
- "Are there any gaps or conflicts to address?"
|
||||
|
||||
- id: development-planning
|
||||
name: Development Planning
|
||||
description: Create actionable development stories
|
||||
steps:
|
||||
- agent: sm
|
||||
action: Create User Stories
|
||||
description: >-
|
||||
Break down requirements into sprint-ready user stories
|
||||
inputs:
|
||||
- prd
|
||||
- architecture-doc
|
||||
- validation-report
|
||||
outputs:
|
||||
- user-stories
|
||||
- sprint-plan
|
||||
prompts:
|
||||
- "Let's create the first sprint's user stories"
|
||||
- "How should we prioritize the backlog?"
|
||||
|
||||
- id: development-handoff
|
||||
name: Development Handoff
|
||||
description: Transition to implementation phase
|
||||
steps:
|
||||
- agent: dev
|
||||
action: Development Setup
|
||||
description: >-
|
||||
Review all artifacts and set up development environment
|
||||
inputs:
|
||||
- architecture-doc
|
||||
- frontend-architecture
|
||||
- user-stories
|
||||
outputs:
|
||||
- dev-environment
|
||||
- implementation-plan
|
||||
prompts:
|
||||
- "Let's set up the development environment"
|
||||
- "Ready to start implementing the first story?"
|
||||
|
||||
transitions:
|
||||
- from: discovery
|
||||
to: planning
|
||||
condition: project-brief completed
|
||||
- from: planning
|
||||
to: architecture
|
||||
condition: prd and ui-specifications completed
|
||||
- from: architecture
|
||||
to: validation
|
||||
condition: all architecture docs completed
|
||||
- from: validation
|
||||
to: development-planning
|
||||
condition: validation passed
|
||||
- from: development-planning
|
||||
to: development-handoff
|
||||
condition: stories created
|
||||
|
||||
artifacts:
|
||||
project-brief:
|
||||
template: project-brief-tmpl
|
||||
description: High-level project vision and goals
|
||||
prd:
|
||||
template: prd-tmpl
|
||||
description: Detailed product requirements
|
||||
architecture-doc:
|
||||
template: fullstack-architecture-tmpl
|
||||
description: Complete system architecture
|
||||
frontend-architecture:
|
||||
template: front-end-architecture-tmpl
|
||||
description: Frontend-specific architecture
|
||||
user-stories:
|
||||
template: story-tmpl
|
||||
description: Development-ready user stories
|
||||
86
agent-team-workflows/greenfield-service.yml
Normal file
86
agent-team-workflows/greenfield-service.yml
Normal file
@@ -0,0 +1,86 @@
|
||||
workflow:
|
||||
id: greenfield-service
|
||||
name: Greenfield Service/API Development
|
||||
description: >-
|
||||
Agent workflow for building REST APIs, GraphQL services, or microservices
|
||||
without frontend requirements.
|
||||
type: greenfield
|
||||
project_types:
|
||||
- rest-api
|
||||
- graphql-api
|
||||
- microservice
|
||||
- backend-service
|
||||
|
||||
sequence:
|
||||
- agent: analyst
|
||||
creates: project-brief.md
|
||||
optional_steps:
|
||||
- brainstorming_session
|
||||
- market_research_prompt
|
||||
notes: "Can do brainstorming first, then optional deep research before creating project brief. SAVE OUTPUT: Copy final project-brief.md to your project's docs/ folder."
|
||||
|
||||
- agent: pm
|
||||
creates: prd.md
|
||||
requires: project-brief.md
|
||||
notes: "Creates PRD from project brief using prd-tmpl, focused on API/service requirements. SAVE OUTPUT: Copy final prd.md to your project's docs/ folder."
|
||||
|
||||
- agent: architect
|
||||
creates: architecture.md
|
||||
requires: prd.md
|
||||
optional_steps:
|
||||
- technical_research_prompt
|
||||
notes: "Creates backend/service architecture using architecture-tmpl. May suggest changes to PRD stories or new stories. SAVE OUTPUT: Copy final architecture.md to your project's docs/ folder."
|
||||
|
||||
- agent: pm
|
||||
updates: prd.md (if needed)
|
||||
requires: architecture.md
|
||||
condition: architecture_suggests_prd_changes
|
||||
notes: "If architect suggests story changes, update PRD and re-export the complete unredacted prd.md to docs/ folder."
|
||||
|
||||
- agent: po
|
||||
validates: all_artifacts
|
||||
uses: po-master-checklist
|
||||
notes: "Validates all documents for consistency and completeness. May require updates to any document."
|
||||
|
||||
- agent: various
|
||||
updates: any_flagged_documents
|
||||
condition: po_checklist_issues
|
||||
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
|
||||
|
||||
- workflow_end:
|
||||
action: move_to_ide
|
||||
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
|
||||
|
||||
flow_diagram: |
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Start] --> B[analyst: project-brief.md]
|
||||
B --> C[pm: prd.md]
|
||||
C --> D[architect: architecture.md]
|
||||
D --> E{Architecture suggests PRD changes?}
|
||||
E -->|Yes| F[pm: update prd.md]
|
||||
E -->|No| G[po: validate all artifacts]
|
||||
F --> G
|
||||
G --> H{PO finds issues?}
|
||||
H -->|Yes| I[Return to relevant agent for fixes]
|
||||
H -->|No| J[Move to IDE Environment]
|
||||
I --> G
|
||||
|
||||
B -.-> B1[Optional: brainstorming]
|
||||
B -.-> B2[Optional: market research]
|
||||
D -.-> D1[Optional: technical research]
|
||||
|
||||
style J fill:#90EE90
|
||||
style B fill:#FFE4B5
|
||||
style C fill:#FFE4B5
|
||||
style D fill:#FFE4B5
|
||||
```
|
||||
|
||||
handoff_prompts:
|
||||
analyst_to_pm: "Project brief is complete. Save it as docs/project-brief.md in your project, then create the PRD."
|
||||
pm_to_architect: "PRD is ready. Save it as docs/prd.md in your project, then create the service architecture."
|
||||
architect_review: "Architecture complete. Save it as docs/architecture.md. Do you suggest any changes to the PRD stories or need new stories added?"
|
||||
architect_to_pm: "Please update the PRD with the suggested story changes, then re-export the complete prd.md to docs/."
|
||||
updated_to_po: "All documents ready in docs/ folder. Please validate all artifacts for consistency."
|
||||
po_issues: "PO found issues with [document]. Please return to [agent] to fix and re-save the updated document."
|
||||
workflow_complete: "All planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."
|
||||
119
agent-team-workflows/greenfield-ui.yml
Normal file
119
agent-team-workflows/greenfield-ui.yml
Normal file
@@ -0,0 +1,119 @@
|
||||
workflow:
|
||||
id: greenfield-ui
|
||||
name: Greenfield UI/Frontend Development
|
||||
description: >-
|
||||
Agent workflow for building frontend applications that consume existing APIs.
|
||||
Perfect for SPAs, mobile apps, or micro-frontends.
|
||||
type: greenfield
|
||||
project_types:
|
||||
- spa
|
||||
- mobile-app
|
||||
- micro-frontend
|
||||
- static-site
|
||||
|
||||
sequence:
|
||||
- agent: analyst
|
||||
creates: project-brief.md
|
||||
optional_steps:
|
||||
- brainstorming_session
|
||||
- market_research_prompt
|
||||
notes: "Can do brainstorming first, then optional deep research before creating project brief. SAVE OUTPUT: Copy final project-brief.md to your project's docs/ folder."
|
||||
|
||||
- agent: pm
|
||||
creates: prd.md
|
||||
requires: project-brief.md
|
||||
notes: "Creates PRD from project brief using prd-tmpl, focused on UI/frontend requirements. SAVE OUTPUT: Copy final prd.md to your project's docs/ folder."
|
||||
|
||||
- agent: ux-expert
|
||||
creates: front-end-spec.md
|
||||
requires: prd.md
|
||||
optional_steps:
|
||||
- user_research_prompt
|
||||
notes: "Creates UI/UX specification using front-end-spec-tmpl. SAVE OUTPUT: Copy final front-end-spec.md to your project's docs/ folder."
|
||||
|
||||
- agent: ux-expert
|
||||
creates: v0_prompt (optional)
|
||||
requires: front-end-spec.md
|
||||
condition: user_wants_ai_generation
|
||||
notes: "OPTIONAL BUT RECOMMENDED: Generate AI UI prompt for tools like v0, Lovable, etc. Use the generate-ai-frontend-prompt task. User can then generate UI in external tool and download project structure."
|
||||
|
||||
- agent: ui-architect
|
||||
creates: front-end-architecture.md
|
||||
requires: front-end-spec.md
|
||||
optional_steps:
|
||||
- technical_research_prompt
|
||||
- review_generated_ui_structure
|
||||
notes: "Creates frontend architecture using front-end-architecture-tmpl. If user generated UI with v0/Lovable, can incorporate the project structure into architecture. May suggest changes to PRD stories or new stories. SAVE OUTPUT: Copy final front-end-architecture.md to your project's docs/ folder."
|
||||
|
||||
- agent: pm
|
||||
updates: prd.md (if needed)
|
||||
requires: front-end-architecture.md
|
||||
condition: architecture_suggests_prd_changes
|
||||
notes: "If architect suggests story changes, update PRD and re-export the complete unredacted prd.md to docs/ folder."
|
||||
|
||||
- agent: po
|
||||
validates: all_artifacts
|
||||
uses: po-master-checklist
|
||||
notes: "Validates all documents for consistency and completeness. May require updates to any document."
|
||||
|
||||
- agent: various
|
||||
updates: any_flagged_documents
|
||||
condition: po_checklist_issues
|
||||
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
|
||||
|
||||
- project_setup_guidance:
|
||||
action: guide_project_structure
|
||||
condition: user_has_generated_ui
|
||||
notes: "If user generated UI with v0/Lovable: For polyrepo setup, place downloaded project in separate frontend repo. For monorepo, place in apps/web or frontend/ directory. Review architecture document for specific guidance."
|
||||
|
||||
- workflow_end:
|
||||
action: move_to_ide
|
||||
notes: "All planning artifacts complete. Move to IDE environment to begin development. Explain to the user the IDE Development Workflow next steps: data#bmad-kb:IDE Development Workflow"
|
||||
|
||||
flow_diagram: |
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Start] --> B[analyst: project-brief.md]
|
||||
B --> C[pm: prd.md]
|
||||
C --> D[ux-expert: front-end-spec.md]
|
||||
D --> D2{Generate v0 prompt?}
|
||||
D2 -->|Yes| D3[ux-expert: create v0 prompt]
|
||||
D2 -->|No| E[ui-architect: front-end-architecture.md]
|
||||
D3 --> D4[User: generate UI in v0/Lovable]
|
||||
D4 --> E
|
||||
E --> F{Architecture suggests PRD changes?}
|
||||
F -->|Yes| G[pm: update prd.md]
|
||||
F -->|No| H[po: validate all artifacts]
|
||||
G --> H
|
||||
H --> I{PO finds issues?}
|
||||
I -->|Yes| J[Return to relevant agent for fixes]
|
||||
I -->|No| K{Generated UI?}
|
||||
K -->|Yes| L[Guide project structure setup]
|
||||
K -->|No| M[Move to IDE Environment]
|
||||
L --> M
|
||||
J --> H
|
||||
|
||||
B -.-> B1[Optional: brainstorming]
|
||||
B -.-> B2[Optional: market research]
|
||||
D -.-> D1[Optional: user research]
|
||||
E -.-> E1[Optional: technical research]
|
||||
|
||||
style M fill:#90EE90
|
||||
style D3 fill:#E6E6FA
|
||||
style D4 fill:#E6E6FA
|
||||
style L fill:#E6E6FA
|
||||
style B fill:#FFE4B5
|
||||
style C fill:#FFE4B5
|
||||
style D fill:#FFE4B5
|
||||
style E fill:#FFE4B5
|
||||
```
|
||||
|
||||
handoff_prompts:
|
||||
analyst_to_pm: "Project brief is complete. Save it as docs/project-brief.md in your project, then create the PRD."
|
||||
pm_to_ux: "PRD is ready. Save it as docs/prd.md in your project, then create the UI/UX specification."
|
||||
ux_to_architect: "UI/UX spec complete. Save it as docs/front-end-spec.md in your project, then create the frontend architecture."
|
||||
architect_review: "Frontend architecture complete. Save it as docs/front-end-architecture.md. Do you suggest any changes to the PRD stories or need new stories added?"
|
||||
architect_to_pm: "Please update the PRD with the suggested story changes, then re-export the complete prd.md to docs/."
|
||||
updated_to_po: "All documents ready in docs/ folder. Please validate all artifacts for consistency."
|
||||
po_issues: "PO found issues with [document]. Please return to [agent] to fix and re-save the updated document."
|
||||
workflow_complete: "All planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."
|
||||
@@ -14,3 +14,7 @@ agents:
|
||||
- pm
|
||||
- ux-expert
|
||||
- fullstack-architect
|
||||
|
||||
workflows:
|
||||
- greenfield-fullstack
|
||||
- brownfield-fullstack
|
||||
|
||||
@@ -9,3 +9,8 @@ agents:
|
||||
- pm
|
||||
- architect
|
||||
- po
|
||||
|
||||
workflows:
|
||||
- api-only
|
||||
- brownfield-enhancement
|
||||
- backend-service
|
||||
|
||||
@@ -6,3 +6,6 @@ bundle:
|
||||
agents:
|
||||
- bmad
|
||||
- fullstack-architect
|
||||
- devops
|
||||
- ux-expert
|
||||
- dev
|
||||
|
||||
@@ -518,6 +518,166 @@ For large documents (PRD, Architecture):
|
||||
3. Include context from completed work
|
||||
4. Validate against architecture and PRD
|
||||
|
||||
## IDE Development Workflow
|
||||
|
||||
### Post-Planning Phase: Transition to Implementation
|
||||
|
||||
Once you have completed the planning phase and have your core documents saved in your project's `docs/` folder, you're ready to begin the implementation cycle in your IDE environment.
|
||||
|
||||
#### Required Documents
|
||||
|
||||
Before starting implementation, ensure you have these documents in your `docs/` folder:
|
||||
|
||||
- `prd.md` - Product Requirements Document with epics and stories
|
||||
- `fullstack-architecture.md` OR both `architecture.md` and `front-end-architecture.md`
|
||||
- `project-brief.md` (reference)
|
||||
- `front-end-spec.md` (if applicable)
|
||||
|
||||
#### Step 1: Document Sharding
|
||||
|
||||
Large documents need to be broken down for IDE agents to work with effectively:
|
||||
|
||||
1. **Use BMAD Agent to Shard Documents**
|
||||
```
|
||||
Please shard the docs/prd.md document using the shard-doc task
|
||||
```
|
||||
2. **Shard Architecture Documents**
|
||||
|
||||
```
|
||||
Please shard the docs/fullstack-architecture.md document using the shard-doc task
|
||||
```
|
||||
|
||||
3. **Expected Folder Structure After Sharding**
|
||||
```
|
||||
docs/
|
||||
├── prd.md # Original PRD
|
||||
├── fullstack-architecture.md # Original architecture
|
||||
├── prd/ # Sharded PRD content
|
||||
│ ├── epic-1.md # Individual epic files
|
||||
│ ├── epic-2.md
|
||||
│ └── epic-N.md
|
||||
├── fullstack-architecture/ # Sharded architecture content
|
||||
│ ├── tech-stack.md
|
||||
│ ├── data-models.md
|
||||
│ ├── components.md
|
||||
│ └── [other-sections].md
|
||||
└── stories/ # Generated story files
|
||||
├── epic-1/
|
||||
│ ├── story-1-1.md
|
||||
│ └── story-1-2.md
|
||||
└── epic-2/
|
||||
└── story-2-1.md
|
||||
```
|
||||
|
||||
#### Step 2: SM ↔ DEV Implementation Cycle
|
||||
|
||||
The core development workflow follows a strict SM (Scrum Master) to DEV (Developer) cycle:
|
||||
|
||||
##### Story Creation (SM Agent)
|
||||
|
||||
1. **Switch to SM Agent**
|
||||
|
||||
```
|
||||
/sm
|
||||
```
|
||||
|
||||
2. **Create Next Story**
|
||||
|
||||
```
|
||||
Please create the next story for this project
|
||||
```
|
||||
|
||||
- SM agent will check existing stories in `docs/stories/`
|
||||
- Identifies what's complete vs in-progress
|
||||
- Determines the next logical story from the epics
|
||||
- Creates a new story file with proper sequencing
|
||||
|
||||
3. **Manual Story Selection** (if needed)
|
||||
```
|
||||
Please create story 1.1 from epic 1 (the first story)
|
||||
```
|
||||
|
||||
##### Story Review and Approval
|
||||
|
||||
1. **Review Generated Story**
|
||||
|
||||
- Check story file in `docs/stories/epic-X/story-X-Y.md`
|
||||
- Verify acceptance criteria are clear
|
||||
- Ensure story aligns with architecture
|
||||
|
||||
2. **Approve Story**
|
||||
- Edit the story file
|
||||
- Change status from `Draft` to `Approved`
|
||||
- Save the file
|
||||
|
||||
##### Story Development (DEV Agent)
|
||||
|
||||
1. **Switch to DEV Agent**
|
||||
|
||||
```
|
||||
/dev
|
||||
```
|
||||
|
||||
2. **Develop Next Story**
|
||||
|
||||
```
|
||||
Please develop the next approved story
|
||||
```
|
||||
|
||||
- DEV agent will find the next `Approved` story
|
||||
- Implements code according to story requirements
|
||||
- References architecture documents from sharded folders
|
||||
- Updates story status to `InProgress` then `Review`
|
||||
|
||||
3. **Manual Story Selection** (if needed)
|
||||
```
|
||||
Please develop story 1.1
|
||||
```
|
||||
|
||||
##### Story Completion
|
||||
|
||||
1. **Verify Implementation**
|
||||
|
||||
- Test the implemented functionality
|
||||
- Ensure acceptance criteria are met
|
||||
- Validate against architecture requirements
|
||||
|
||||
2. **Mark Story Complete**
|
||||
|
||||
- Edit the story file
|
||||
- Change status from `Review` to `Done`
|
||||
- Save the file
|
||||
|
||||
3. **Return to SM for Next Story**
|
||||
- SM agent will now see this story as complete
|
||||
- Can proceed to create the next sequential story
|
||||
|
||||
#### Sequential Development Best Practices
|
||||
|
||||
1. **Follow Epic Order**: Complete Epic 1 before Epic 2, etc.
|
||||
2. **Sequential Stories**: Complete Story 1.1 before Story 1.2
|
||||
3. **One Story at a Time**: Never have multiple stories `InProgress`
|
||||
4. **Clear Status Management**: Keep story statuses current
|
||||
5. **Architecture Alignment**: Regularly reference sharded architecture docs
|
||||
|
||||
#### Story Status Flow
|
||||
|
||||
```
|
||||
Draft → Approved → InProgress → Review → Done
|
||||
↑ ↑ ↑ ↑ ↑
|
||||
SM User DEV DEV User
|
||||
creates approves starts completes verifies
|
||||
```
|
||||
|
||||
#### Troubleshooting Common Issues
|
||||
|
||||
- **SM can't find next story**: Ensure current story is marked `Done`
|
||||
- **DEV can't find approved story**: Check story status is `Approved`
|
||||
- **Architecture conflicts**: Re-shard updated architecture documents
|
||||
- **Missing context**: Reference original docs in `docs/` folder
|
||||
|
||||
This cycle continues until all epics and stories are complete, delivering your fully implemented project according to the planned architecture and requirements.
|
||||
|
||||
## Best Practices
|
||||
|
||||
### When to Use Web vs IDE
|
||||
|
||||
@@ -40,3 +40,4 @@ When activated:
|
||||
- `*create-frontend-architecture` - Create a Frontend Architecture Document
|
||||
- `*create {template-name}` - Create a document using the specified template
|
||||
- `*list-templates` - Show available architecture templates
|
||||
- `*shard {doc}` - Run the shard-doc task against the selected document in the docs folder
|
||||
|
||||
@@ -17,12 +17,19 @@ I provide hands-on guidance for customizing and extending BMAD to your specific
|
||||
|
||||
Making BMAD work perfectly for your project through thoughtful agent selection and configuration.
|
||||
|
||||
---
|
||||
|
||||
When activated with /bmad, I can help you:
|
||||
|
||||
- Create new agents or teams
|
||||
- Build expansion packs
|
||||
- Optimize your BMAD workflow
|
||||
- Answer any BMAD Method questions
|
||||
- Shard documents
|
||||
|
||||
Available utilities: create-agent, create-ide-agent, create-team, create-expansion-pack
|
||||
Available utilities: create-agent, create-ide-agent, create-team, create-expansion-pack, tasks/shard-doc
|
||||
|
||||
## Commands
|
||||
|
||||
- `*help` - Show available commands
|
||||
- `*index-docs` - Run the index-docs task to update the documentation index in `/docs/index.md`
|
||||
- `*shard {doc}` - Run the shard-doc task against the selected document in the docs folder
|
||||
- `*create {agent|ide-agent|team|expansion-pack}` - can create any of these by running the corresponding item from the bmad-core/utils folder
|
||||
|
||||
@@ -19,10 +19,8 @@ You are Winston, the Fullstack Architect - a master of holistic system design wh
|
||||
## Commands
|
||||
|
||||
`*help` - Show available commands
|
||||
`*create-fullstack-architecture` - Create full system architecture
|
||||
`*review-stack` - Review and suggest technology stack
|
||||
`*design-api` - Design API structure and contracts
|
||||
`*plan-deployment` - Create deployment architecture
|
||||
`*create-fullstack-architecture` - Use task create-doc-from-template with fullstack-architecture-tmpl to create docs.fullstack-architecture.md
|
||||
`*shard {doc}` - Run the shard-doc task against the selected document in the docs folder
|
||||
|
||||
## Expertise
|
||||
|
||||
|
||||
@@ -40,3 +40,4 @@ When activated:
|
||||
- `*create {template-name}` - Create a document using the specified template (e.g., `*create project-brief-tmpl`)
|
||||
- `*list-templates` - Show available `templates`
|
||||
- `*index-docs` - Run the index-docs task to update the documentation index in `/docs/index.md`
|
||||
- `*shard {doc}` - Run the shard-doc task against the selected document in the docs folder
|
||||
|
||||
@@ -43,3 +43,4 @@ When activated:
|
||||
- `*list-templates` - Show all available templates
|
||||
- `*list-checklists` - Show available validation checklists
|
||||
- `*index-docs` - Run the index-docs task to update the documentation index in `/docs/index.md`
|
||||
- `*shard {doc}` - Run the shard-doc task against the selected document in the docs folder
|
||||
|
||||
@@ -42,3 +42,4 @@
|
||||
- execute the selected checklist
|
||||
- `*doc-shard` {PRD|Architecture|Other} - execute `bmad-core/tasks/shard-doc` task
|
||||
- `*index-docs` - Run the index-docs task to update the documentation index in `/docs/index.md`
|
||||
- `*shard {doc}` - Run the shard-doc task against the selected document in the docs folder
|
||||
|
||||
@@ -1,159 +0,0 @@
|
||||
# Infrastructure Review Task
|
||||
|
||||
## Purpose
|
||||
|
||||
To conduct a thorough review of existing infrastructure to identify improvement opportunities, security concerns, and alignment with best practices. This task helps maintain infrastructure health, optimize costs, and ensure continued alignment with organizational requirements.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Current infrastructure documentation
|
||||
- Monitoring and logging data
|
||||
- Recent incident reports
|
||||
- Cost and performance metrics
|
||||
- `infrastructure-checklist.md` (primary review framework)
|
||||
|
||||
## Key Activities & Instructions
|
||||
|
||||
### 1. Confirm Interaction Mode
|
||||
|
||||
- Ask the user: "How would you like to proceed with the infrastructure review? We can work:
|
||||
A. **Incrementally (Default & Recommended):** We'll work through each section of the checklist methodically, documenting findings for each item before moving to the next section. This provides a thorough review.
|
||||
B. **"YOLO" Mode:** I can perform a rapid assessment of all infrastructure components and present a comprehensive findings report. This is faster but may miss nuanced details."
|
||||
- Request the user to select their preferred mode and proceed accordingly.
|
||||
|
||||
### 2. Prepare for Review
|
||||
|
||||
- Gather and organize current infrastructure documentation
|
||||
- Access monitoring and logging systems for operational data
|
||||
- Review recent incident reports for recurring issues
|
||||
- Collect cost and performance metrics
|
||||
- <critical_rule>Establish review scope and boundaries with the user before proceeding</critical_rule>
|
||||
|
||||
### 3. Conduct Systematic Review
|
||||
|
||||
- **If "Incremental Mode" was selected:**
|
||||
- For each section of the infrastructure checklist:
|
||||
- **a. Present Section Focus:** Explain what aspects of infrastructure this section reviews
|
||||
- **b. Work Through Items:** Examine each checklist item against current infrastructure
|
||||
- **c. Document Current State:** Record how current implementation addresses or fails to address each item
|
||||
- **d. Identify Gaps:** Document improvement opportunities with specific recommendations
|
||||
- **e. [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)**
|
||||
- **f. Section Summary:** Provide an assessment summary before moving to the next section
|
||||
|
||||
- **If "YOLO Mode" was selected:**
|
||||
- Rapidly assess all infrastructure components
|
||||
- Document key findings and improvement opportunities
|
||||
- Present a comprehensive review report
|
||||
- <important_note>After presenting the full review in YOLO mode, you MAY still offer the 'Advanced Reflective & Elicitation Options' menu for deeper investigation of specific areas with issues.</important_note>
|
||||
|
||||
### 4. Generate Findings Report
|
||||
|
||||
- Summarize review findings by category (Security, Performance, Cost, Reliability, etc.)
|
||||
- Prioritize identified issues (Critical, High, Medium, Low)
|
||||
- Document recommendations with estimated effort and impact
|
||||
- Create an improvement roadmap with suggested timelines
|
||||
- Highlight cost optimization opportunities
|
||||
|
||||
### 5. BMAD Integration Assessment
|
||||
|
||||
- Evaluate how current infrastructure supports other BMAD agents:
|
||||
- **Development Support:** Assess how infrastructure enables Frontend Dev (Mira), Backend Dev (Enrique), and Full Stack Dev workflows
|
||||
- **Product Alignment:** Verify infrastructure supports PRD requirements from Product Owner (Oli)
|
||||
- **Architecture Compliance:** Check if implementation follows Architect (Alphonse) decisions
|
||||
- Document any gaps in BMAD integration
|
||||
|
||||
### 6. Architectural Escalation Assessment
|
||||
|
||||
- **DevOps/Platform → Architect Escalation Review:**
|
||||
- Evaluate review findings for issues requiring architectural intervention:
|
||||
- **Technical Debt Escalation:**
|
||||
- Identify infrastructure technical debt that impacts system architecture
|
||||
- Document technical debt items that require architectural redesign vs. operational fixes
|
||||
- Assess cumulative technical debt impact on system maintainability and scalability
|
||||
- **Performance/Security Issue Escalation:**
|
||||
- Identify performance bottlenecks that require architectural solutions (not just operational tuning)
|
||||
- Document security vulnerabilities that need architectural security pattern changes
|
||||
- Assess capacity and scalability issues requiring architectural scaling strategy revision
|
||||
- **Technology Evolution Escalation:**
|
||||
- Identify outdated technologies that need architectural migration planning
|
||||
- Document new technology opportunities that could improve system architecture
|
||||
- Assess technology compatibility issues requiring architectural integration strategy changes
|
||||
- **Escalation Decision Matrix:**
|
||||
- **Critical Architectural Issues:** Require immediate Architect Agent involvement for system redesign
|
||||
- **Significant Architectural Concerns:** Recommend Architect Agent review for potential architecture evolution
|
||||
- **Operational Issues:** Can be addressed through operational improvements without architectural changes
|
||||
- **Unclear/Ambiguous Issues:** When escalation level is uncertain, consult with user for guidance and decision
|
||||
- Document escalation recommendations with clear justification and impact assessment
|
||||
- <critical_rule>If escalation classification is unclear or ambiguous, HALT and ask user for guidance on appropriate escalation level and approach</critical_rule>
|
||||
|
||||
### 7. Present and Plan
|
||||
|
||||
- Prepare an executive summary of key findings
|
||||
- Create detailed technical documentation for implementation teams
|
||||
- Develop an action plan for critical and high-priority items
|
||||
- **Prepare Architectural Escalation Report** (if applicable):
|
||||
- Document all findings requiring Architect Agent attention
|
||||
- Provide specific recommendations for architectural changes or reviews
|
||||
- Include impact assessment and priority levels for architectural work
|
||||
- Prepare escalation summary for Architect Agent collaboration
|
||||
- Schedule follow-up reviews for specific areas
|
||||
- <important_note>Present findings in a way that enables clear decision-making on next steps and escalation needs.</important_note>
|
||||
|
||||
### 8. Execute Escalation Protocol
|
||||
|
||||
- **If Critical Architectural Issues Identified:**
|
||||
- **Immediate Escalation to Architect Agent:**
|
||||
- Present architectural escalation report with critical findings
|
||||
- Request architectural review and potential redesign for identified issues
|
||||
- Collaborate with Architect Agent on priority and timeline for architectural changes
|
||||
- Document escalation outcomes and planned architectural work
|
||||
- **If Significant Architectural Concerns Identified:**
|
||||
- **Scheduled Architectural Review:**
|
||||
- Prepare detailed technical findings for Architect Agent review
|
||||
- Request architectural assessment of identified concerns
|
||||
- Schedule collaborative planning session for potential architectural evolution
|
||||
- Document architectural recommendations and planned follow-up
|
||||
- **If Only Operational Issues Identified:**
|
||||
- Proceed with operational improvement planning without architectural escalation
|
||||
- Monitor for future architectural implications of operational changes
|
||||
- **If Unclear/Ambiguous Escalation Needed:**
|
||||
- **User Consultation Required:**
|
||||
- Present unclear findings and escalation options to user
|
||||
- Request user guidance on appropriate escalation level and approach
|
||||
- Document user decision and rationale for escalation approach
|
||||
- Proceed with user-directed escalation path
|
||||
- <critical_rule>All critical architectural escalations must be documented and acknowledged by Architect Agent before proceeding with implementation</critical_rule>
|
||||
|
||||
## Output
|
||||
|
||||
A comprehensive infrastructure review report that includes:
|
||||
|
||||
1. **Current state assessment** for each infrastructure component
|
||||
2. **Prioritized findings** with severity ratings
|
||||
3. **Detailed recommendations** with effort/impact estimates
|
||||
4. **Cost optimization opportunities**
|
||||
5. **BMAD integration assessment**
|
||||
6. **Architectural escalation assessment** with clear escalation recommendations
|
||||
7. **Action plan** for critical improvements and architectural work
|
||||
8. **Escalation documentation** for Architect Agent collaboration (if applicable)
|
||||
|
||||
## Offer Advanced Self-Refinement & Elicitation Options
|
||||
|
||||
Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.
|
||||
|
||||
"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):
|
||||
|
||||
**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**
|
||||
|
||||
1. **Root Cause Analysis & Pattern Recognition**
|
||||
2. **Industry Best Practice Comparison**
|
||||
3. **Future Scalability & Growth Impact Assessment**
|
||||
4. **Security Vulnerability & Threat Model Analysis**
|
||||
5. **Operational Efficiency & Automation Opportunities**
|
||||
6. **Cost Structure Analysis & Optimization Strategy**
|
||||
7. **Compliance & Governance Gap Assessment**
|
||||
8. **Finalize this Section and Proceed.**
|
||||
|
||||
After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."
|
||||
|
||||
REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNTIL the user indicates it is time to proceed to the next section (or selects #8)
|
||||
@@ -1,153 +0,0 @@
|
||||
# Infrastructure Validation Task
|
||||
|
||||
## Purpose
|
||||
|
||||
To comprehensively validate platform infrastructure changes against security, reliability, operational, and compliance requirements before deployment. This task ensures all platform infrastructure meets organizational standards, follows best practices, and properly integrates with the broader BMAD ecosystem.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Infrastructure Change Request (`docs/infrastructure/{ticketNumber}.change.md`)
|
||||
- **Infrastructure Architecture Document** (`docs/infrastructure-architecture.md` - from Architect Agent)
|
||||
- Infrastructure Guidelines (`docs/infrastructure/guidelines.md`)
|
||||
- Technology Stack Document (`docs/tech-stack.md`)
|
||||
- `infrastructure-checklist.md` (primary validation framework - 16 comprehensive sections)
|
||||
|
||||
## Key Activities & Instructions
|
||||
|
||||
### 1. Confirm Interaction Mode
|
||||
|
||||
- Ask the user: "How would you like to proceed with platform infrastructure validation? We can work:
|
||||
A. **Incrementally (Default & Recommended):** We'll work through each section of the checklist step-by-step, documenting compliance or gaps for each item before moving to the next section. This is best for thorough validation and detailed documentation of the complete platform stack.
|
||||
B. **"YOLO" Mode:** I can perform a rapid assessment of all checklist items and present a comprehensive validation report for review. This is faster but may miss nuanced details that would be caught in the incremental approach."
|
||||
- Request the user to select their preferred mode (e.g., "Please let me know if you'd prefer A or B.").
|
||||
- Once the user chooses, confirm the selected mode and proceed accordingly.
|
||||
|
||||
### 2. Initialize Platform Validation
|
||||
|
||||
- Review the infrastructure change documentation to understand platform implementation scope and purpose
|
||||
- Analyze the infrastructure architecture document for platform design patterns and compliance requirements
|
||||
- Examine infrastructure guidelines for organizational standards across all platform components
|
||||
- Prepare the validation environment and tools for comprehensive platform testing
|
||||
- <critical_rule>Verify the infrastructure change request is approved for validation. If not, HALT and inform the user.</critical_rule>
|
||||
|
||||
### 3. Architecture Design Review Gate
|
||||
|
||||
- **DevOps/Platform → Architect Design Review:**
|
||||
- Conduct systematic review of infrastructure architecture document for implementability
|
||||
- Evaluate architectural decisions against operational constraints and capabilities:
|
||||
- **Implementation Complexity:** Assess if proposed architecture can be implemented with available tools and expertise
|
||||
- **Operational Feasibility:** Validate that operational patterns are achievable within current organizational maturity
|
||||
- **Resource Availability:** Confirm required infrastructure resources are available and within budget constraints
|
||||
- **Technology Compatibility:** Verify selected technologies integrate properly with existing infrastructure
|
||||
- **Security Implementation:** Validate that security patterns can be implemented with current security toolchain
|
||||
- **Maintenance Overhead:** Assess ongoing operational burden and maintenance requirements
|
||||
- Document design review findings and recommendations:
|
||||
- **Approved Aspects:** Document architectural decisions that are implementable as designed
|
||||
- **Implementation Concerns:** Identify architectural decisions that may face implementation challenges
|
||||
- **Required Modifications:** Recommend specific changes needed to make architecture implementable
|
||||
- **Alternative Approaches:** Suggest alternative implementation patterns where needed
|
||||
- **Collaboration Decision Point:**
|
||||
- If **critical implementation blockers** identified: HALT validation and escalate to Architect Agent for architectural revision
|
||||
- If **minor concerns** identified: Document concerns and proceed with validation, noting required implementation adjustments
|
||||
- If **architecture approved**: Proceed with comprehensive platform validation
|
||||
- <critical_rule>All critical design review issues must be resolved before proceeding to detailed validation</critical_rule>
|
||||
|
||||
### 4. Execute Comprehensive Platform Validation Process
|
||||
|
||||
- **If "Incremental Mode" was selected:**
|
||||
- For each section of the infrastructure checklist (Sections 1-16):
|
||||
- **a. Present Section Purpose:** Explain what this section validates and why it's important for platform operations
|
||||
- **b. Work Through Items:** Present each checklist item, guide the user through validation, and document compliance or gaps
|
||||
- **c. Evidence Collection:** For each compliant item, document how compliance was verified
|
||||
- **d. Gap Documentation:** For each non-compliant item, document specific issues and proposed remediation
|
||||
- **e. Platform Integration Testing:** For platform engineering sections (13-16), validate integration between platform components
|
||||
- **f. [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)**
|
||||
- **g. Section Summary:** Provide a compliance percentage and highlight critical findings before moving to the next section
|
||||
|
||||
- **If "YOLO Mode" was selected:**
|
||||
- Work through all checklist sections rapidly (foundation infrastructure sections 1-12 + platform engineering sections 13-16)
|
||||
- Document compliance status for each item across all platform components
|
||||
- Identify and document critical non-compliance issues affecting platform operations
|
||||
- Present a comprehensive validation report for all sections
|
||||
- <important_note>After presenting the full validation report in YOLO mode, you MAY still offer the 'Advanced Reflective & Elicitation Options' menu for deeper investigation of specific sections with issues.</important_note>
|
||||
|
||||
### 5. Generate Comprehensive Platform Validation Report
|
||||
|
||||
- Summarize validation findings by section across all 16 checklist areas
|
||||
- Calculate and present overall compliance percentage for complete platform stack
|
||||
- Clearly document all non-compliant items with remediation plans prioritized by platform impact
|
||||
- Highlight critical security or operational risks affecting platform reliability
|
||||
- Include design review findings and architectural implementation recommendations
|
||||
- Provide validation signoff recommendation based on complete platform assessment
|
||||
- Document platform component integration validation results
|
||||
|
||||
### 6. BMAD Integration Assessment
|
||||
|
||||
- Review how platform infrastructure changes support other BMAD agents:
|
||||
- **Development Agent Alignment:** Verify platform infrastructure supports Frontend Dev, Backend Dev, and Full Stack Dev requirements including:
|
||||
- Container platform development environment provisioning
|
||||
- GitOps workflows for application deployment
|
||||
- Service mesh integration for development testing
|
||||
- Developer experience platform self-service capabilities
|
||||
- **Product Alignment:** Ensure platform infrastructure implements PRD requirements from Product Owner including:
|
||||
- Scalability and performance requirements through container platform
|
||||
- Deployment automation through GitOps workflows
|
||||
- Service reliability through service mesh implementation
|
||||
- **Architecture Alignment:** Validate that platform implementation aligns with architecture decisions including:
|
||||
- Technology selections implemented correctly across all platform components
|
||||
- Security architecture implemented in container platform, service mesh, and GitOps
|
||||
- Integration patterns properly implemented between platform components
|
||||
- Document all integration points and potential impacts on other agents' workflows
|
||||
|
||||
### 7. Next Steps Recommendation
|
||||
|
||||
- If validation successful:
|
||||
- Prepare platform deployment recommendation with component dependencies
|
||||
- Outline monitoring requirements for complete platform stack
|
||||
- Suggest knowledge transfer activities for platform operations
|
||||
- Document platform readiness certification
|
||||
- If validation failed:
|
||||
- Prioritize remediation actions by platform component and integration impact
|
||||
- Recommend blockers vs. non-blockers for platform deployment
|
||||
- Schedule follow-up validation with focus on failed platform components
|
||||
- Document platform risks and mitigation strategies
|
||||
- If design review identified architectural issues:
|
||||
- **Escalate to Architect Agent** for architectural revision and re-design
|
||||
- Document specific architectural changes required for implementability
|
||||
- Schedule follow-up design review after architectural modifications
|
||||
- Update documentation with validation results across all platform components
|
||||
- <important_note>Always ensure the Infrastructure Change Request status is updated to reflect the platform validation outcome.</important_note>
|
||||
|
||||
## Output
|
||||
|
||||
A comprehensive platform validation report documenting:
|
||||
|
||||
1. **Architecture Design Review Results** - Implementability assessment and architectural recommendations
|
||||
2. **Compliance percentage by checklist section** (all 16 sections including platform engineering)
|
||||
3. **Detailed findings for each non-compliant item** across foundation and platform components
|
||||
4. **Platform integration validation results** documenting component interoperability
|
||||
5. **Remediation recommendations with priority levels** based on platform impact
|
||||
6. **BMAD integration assessment results** for complete platform stack
|
||||
7. **Clear signoff recommendation** for platform deployment readiness or architectural revision requirements
|
||||
8. **Next steps for implementation or remediation** prioritized by platform dependencies
|
||||
|
||||
## Offer Advanced Self-Refinement & Elicitation Options
|
||||
|
||||
Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.
|
||||
|
||||
"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):
|
||||
|
||||
**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**
|
||||
|
||||
1. **Critical Security Assessment & Risk Analysis**
|
||||
2. **Platform Integration & Component Compatibility Evaluation**
|
||||
3. **Cross-Environment Consistency Review**
|
||||
4. **Technical Debt & Maintainability Analysis**
|
||||
5. **Compliance & Regulatory Alignment Deep Dive**
|
||||
6. **Cost Optimization & Resource Efficiency Analysis**
|
||||
7. **Operational Resilience & Platform Failure Mode Testing (Theoretical)**
|
||||
8. **Finalize this Section and Proceed.**
|
||||
|
||||
After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."
|
||||
|
||||
REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNTIL the user indicates it is time to proceed to the next section (or selects #8)
|
||||
@@ -52,6 +52,13 @@ Document the decision here before proceeding with the architecture design. In no
|
||||
|
||||
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
|
||||
|
||||
[[LLM: This section contains multiple subsections that establish the foundation of the architecture. Present all subsections together (Introduction, Technical Summary, High Level Overview, Project Diagram, and Architectural Patterns), then apply `tasks#advanced-elicitation` protocol to the complete High Level Architecture section. The user can choose to refine the entire section or specific subsections.]]
|
||||
@@ -715,16 +722,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.]]
|
||||
|
||||
542
bmad-core/templates/brownfield-architecture-tmpl.md
Normal file
542
bmad-core/templates/brownfield-architecture-tmpl.md
Normal file
@@ -0,0 +1,542 @@
|
||||
# {{Project Name}} Brownfield Enhancement Architecture
|
||||
|
||||
[[LLM: IMPORTANT - SCOPE AND ASSESSMENT REQUIRED:
|
||||
|
||||
This architecture document is for SIGNIFICANT enhancements to existing projects that require comprehensive architectural planning. Before proceeding:
|
||||
|
||||
1. **Verify Complexity**: Confirm this enhancement requires architectural planning. For simple additions, recommend: "For simpler changes that don't require architectural planning, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead."
|
||||
|
||||
2. **REQUIRED INPUTS**:
|
||||
|
||||
- Completed brownfield-prd.md
|
||||
- Existing project technical documentation (from docs folder or user-provided)
|
||||
- Access to existing project structure (IDE or uploaded files)
|
||||
|
||||
3. **DEEP ANALYSIS MANDATE**: You MUST conduct thorough analysis of the existing codebase, architecture patterns, and technical constraints before making ANY architectural recommendations. Every suggestion must be based on actual project analysis, not assumptions.
|
||||
|
||||
4. **CONTINUOUS VALIDATION**: Throughout this process, explicitly validate your understanding with the user. For every architectural decision, confirm: "Based on my analysis of your existing system, I recommend [decision] because [evidence from actual project]. Does this align with your system's reality?"
|
||||
|
||||
If any required inputs are missing, request them before proceeding.]]
|
||||
|
||||
## Introduction
|
||||
|
||||
[[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.
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
This document outlines the architectural approach for enhancing {{Project Name}} with {{Enhancement Description}}. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development of new features while ensuring seamless integration with the existing system.
|
||||
|
||||
**Relationship to Existing Architecture:**
|
||||
This document supplements existing project architecture by defining how new components will integrate with current systems. Where conflicts arise between new and existing patterns, this document provides guidance on maintaining consistency while implementing enhancements.
|
||||
|
||||
### Existing Project Analysis
|
||||
|
||||
[[LLM: Analyze the existing project structure and architecture:
|
||||
|
||||
1. Review existing documentation in docs folder
|
||||
2. Examine current technology stack and versions
|
||||
3. Identify existing architectural patterns and conventions
|
||||
4. Note current deployment and infrastructure setup
|
||||
5. Document any constraints or limitations
|
||||
|
||||
CRITICAL: After your analysis, explicitly validate your findings: "Based on my analysis of your project, I've identified the following about your existing system: [key findings]. Please confirm these observations are accurate before I proceed with architectural recommendations."
|
||||
|
||||
Present findings and apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
**Current Project State:**
|
||||
|
||||
- **Primary Purpose:** {{existing_project_purpose}}
|
||||
- **Current Tech Stack:** {{existing_tech_summary}}
|
||||
- **Architecture Style:** {{existing_architecture_style}}
|
||||
- **Deployment Method:** {{existing_deployment_approach}}
|
||||
|
||||
**Available Documentation:**
|
||||
|
||||
- {{existing_docs_summary}}
|
||||
|
||||
**Identified Constraints:**
|
||||
|
||||
- {{constraint_1}}
|
||||
- {{constraint_2}}
|
||||
- {{constraint_3}}
|
||||
|
||||
### Change Log
|
||||
|
||||
| Change | Date | Version | Description | Author |
|
||||
| ------ | ---- | ------- | ----------- | ------ |
|
||||
|
||||
## Enhancement Scope and Integration Strategy
|
||||
|
||||
[[LLM: Define how the enhancement will integrate with the existing system:
|
||||
|
||||
1. Review the brownfield PRD enhancement scope
|
||||
2. Identify integration points with existing code
|
||||
3. Define boundaries between new and existing functionality
|
||||
4. Establish compatibility requirements
|
||||
|
||||
VALIDATION CHECKPOINT: Before presenting the integration strategy, confirm: "Based on my analysis, the integration approach I'm proposing takes into account [specific existing system characteristics]. These integration points and boundaries respect your current architecture patterns. Is this assessment accurate?"
|
||||
|
||||
Present complete integration strategy and apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Enhancement Overview
|
||||
|
||||
**Enhancement Type:** {{enhancement_type}}
|
||||
**Scope:** {{enhancement_scope}}
|
||||
**Integration Impact:** {{integration_impact_level}}
|
||||
|
||||
### Integration Approach
|
||||
|
||||
**Code Integration Strategy:** {{code_integration_approach}}
|
||||
**Database Integration:** {{database_integration_approach}}
|
||||
**API Integration:** {{api_integration_approach}}
|
||||
**UI Integration:** {{ui_integration_approach}}
|
||||
|
||||
### Compatibility Requirements
|
||||
|
||||
- **Existing API Compatibility:** {{api_compatibility}}
|
||||
- **Database Schema Compatibility:** {{db_compatibility}}
|
||||
- **UI/UX Consistency:** {{ui_compatibility}}
|
||||
- **Performance Impact:** {{performance_constraints}}
|
||||
|
||||
## Tech Stack Alignment
|
||||
|
||||
[[LLM: Ensure new components align with existing technology choices:
|
||||
|
||||
1. Use existing technology stack as the foundation
|
||||
2. Only introduce new technologies if absolutely necessary
|
||||
3. Justify any new additions with clear rationale
|
||||
4. Ensure version compatibility with existing dependencies
|
||||
|
||||
Present complete tech stack alignment and apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Existing Technology Stack
|
||||
|
||||
[[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]]
|
||||
240
bmad-core/templates/brownfield-prd-tmpl.md
Normal file
240
bmad-core/templates/brownfield-prd-tmpl.md
Normal file
@@ -0,0 +1,240 @@
|
||||
# {{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.]]
|
||||
|
||||
## 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)
|
||||
|
||||
### Change Log
|
||||
|
||||
| Change | Date | Version | Description | Author |
|
||||
| ------ | ---- | ------- | ----------- | ------ |
|
||||
|
||||
## 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]]
|
||||
|
||||
## 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>>
|
||||
@@ -46,6 +46,13 @@
|
||||
|
||||
Document the starter template decision and any constraints it imposes before proceeding.]]
|
||||
|
||||
### Change Log
|
||||
|
||||
[[LLM: Track document versions and changes]]
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
| :--- | :------ | :---------- | :----- |
|
||||
|
||||
## Frontend Tech Stack
|
||||
|
||||
[[LLM: Extract from main architecture's Technology Stack Table. This section MUST remain synchronized with the main architecture document. After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
This document defines the user experience goals, information architecture, user flows, and visual design specifications for {{Project Name}}'s user interface. It serves as the foundation for visual design and frontend development, ensuring a cohesive and user-centered experience.
|
||||
|
||||
## Overall UX Goals & Principles
|
||||
### Overall UX Goals & Principles
|
||||
|
||||
[[LLM: Work with the user to establish and document the following. If not already defined, facilitate a discussion to determine:
|
||||
|
||||
@@ -23,33 +23,43 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
{{persona_descriptions}}
|
||||
|
||||
@{example: personas}
|
||||
|
||||
- **Power User:** Technical professionals who need advanced features and efficiency
|
||||
- **Casual User:** Occasional users who prioritize ease of use and clear guidance
|
||||
- **Administrator:** System managers who need control and oversight capabilities
|
||||
@{/example}
|
||||
@{/example}
|
||||
|
||||
### Usability Goals
|
||||
|
||||
{{usability_goals}}
|
||||
|
||||
@{example: usability_goals}
|
||||
|
||||
- Ease of learning: New users can complete core tasks within 5 minutes
|
||||
- Efficiency of use: Power users can complete frequent tasks with minimal clicks
|
||||
- Error prevention: Clear validation and confirmation for destructive actions
|
||||
- Memorability: Infrequent users can return without relearning
|
||||
@{/example}
|
||||
@{/example}
|
||||
|
||||
### Design Principles
|
||||
|
||||
{{design_principles}}
|
||||
|
||||
@{example: design_principles}
|
||||
|
||||
1. **Clarity over cleverness** - Prioritize clear communication over aesthetic innovation
|
||||
2. **Progressive disclosure** - Show only what's needed, when it's needed
|
||||
3. **Consistent patterns** - Use familiar UI patterns throughout the application
|
||||
4. **Immediate feedback** - Every action should have a clear, immediate response
|
||||
5. **Accessible by default** - Design for all users from the start
|
||||
@{/example}
|
||||
@{/example}
|
||||
|
||||
### Change Log
|
||||
|
||||
[[LLM: Track document versions and changes]]
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
| :--- | :------ | :---------- | :----- |
|
||||
|
||||
## Information Architecture (IA)
|
||||
|
||||
@@ -69,6 +79,7 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
```
|
||||
|
||||
@{example: sitemap}
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Homepage] --> B[Dashboard]
|
||||
@@ -83,6 +94,7 @@ graph TD
|
||||
D --> D2[Settings]
|
||||
D --> D3[Billing]
|
||||
```
|
||||
|
||||
@{/example}
|
||||
|
||||
### Navigation Structure
|
||||
@@ -106,6 +118,7 @@ graph TD
|
||||
Create subsections for each major flow. After presenting all flows, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
<<REPEAT: user_flow>>
|
||||
|
||||
### {{flow_name}}
|
||||
|
||||
**User Goal:** {{flow_goal}}
|
||||
@@ -121,6 +134,7 @@ Create subsections for each major flow. After presenting all flows, apply `tasks
|
||||
```
|
||||
|
||||
**Edge Cases & Error Handling:**
|
||||
|
||||
- {{edge_case_1}}
|
||||
- {{edge_case_2}}
|
||||
|
||||
@@ -128,6 +142,7 @@ Create subsections for each major flow. After presenting all flows, apply `tasks
|
||||
<</REPEAT>>
|
||||
|
||||
@{example: user_flow}
|
||||
|
||||
### User Registration
|
||||
|
||||
**User Goal:** Create a new account to access the platform
|
||||
@@ -153,10 +168,11 @@ graph TD
|
||||
```
|
||||
|
||||
**Edge Cases & Error Handling:**
|
||||
|
||||
- Duplicate email: Show inline error with password recovery option
|
||||
- Weak password: Real-time feedback on password strength
|
||||
- Network error: Preserve form data and show retry option
|
||||
@{/example}
|
||||
@{/example}
|
||||
|
||||
## Wireframes & Mockups
|
||||
|
||||
@@ -169,11 +185,13 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
### Key Screen Layouts
|
||||
|
||||
<<REPEAT: screen_layout>>
|
||||
|
||||
#### {{screen_name}}
|
||||
|
||||
**Purpose:** {{screen_purpose}}
|
||||
|
||||
**Key Elements:**
|
||||
|
||||
- {{element_1}}
|
||||
- {{element_2}}
|
||||
- {{element_3}}
|
||||
@@ -194,6 +212,7 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
### Core Components
|
||||
|
||||
<<REPEAT: component>>
|
||||
|
||||
#### {{component_name}}
|
||||
|
||||
**Purpose:** {{component_purpose}}
|
||||
@@ -206,6 +225,7 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
<</REPEAT>>
|
||||
|
||||
@{example: component}
|
||||
|
||||
#### Button
|
||||
|
||||
**Purpose:** Primary interaction element for user actions
|
||||
@@ -214,11 +234,12 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
**States:** Default, Hover, Active, Disabled, Loading
|
||||
|
||||
**Usage Guidelines:**
|
||||
**Usage Guidelines:**
|
||||
|
||||
- Use Primary for main CTAs (one per view)
|
||||
- Secondary for supporting actions
|
||||
- Destructive only for permanent deletions with confirmation
|
||||
@{/example}
|
||||
@{/example}
|
||||
|
||||
## Branding & Style Guide
|
||||
|
||||
@@ -232,19 +253,20 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Color Palette
|
||||
|
||||
| Color Type | Hex Code | Usage |
|
||||
|:-----------|:---------|:------|
|
||||
| **Primary** | {{primary_color}} | {{primary_usage}} |
|
||||
| **Secondary** | {{secondary_color}} | {{secondary_usage}} |
|
||||
| **Accent** | {{accent_color}} | {{accent_usage}} |
|
||||
| **Success** | {{success_color}} | Positive feedback, confirmations |
|
||||
| **Warning** | {{warning_color}} | Cautions, important notices |
|
||||
| **Error** | {{error_color}} | Errors, destructive actions |
|
||||
| **Neutral** | {{neutral_colors}} | Text, borders, backgrounds |
|
||||
| Color Type | Hex Code | Usage |
|
||||
| :------------ | :------------------ | :------------------------------- |
|
||||
| **Primary** | {{primary_color}} | {{primary_usage}} |
|
||||
| **Secondary** | {{secondary_color}} | {{secondary_usage}} |
|
||||
| **Accent** | {{accent_color}} | {{accent_usage}} |
|
||||
| **Success** | {{success_color}} | Positive feedback, confirmations |
|
||||
| **Warning** | {{warning_color}} | Cautions, important notices |
|
||||
| **Error** | {{error_color}} | Errors, destructive actions |
|
||||
| **Neutral** | {{neutral_colors}} | Text, borders, backgrounds |
|
||||
|
||||
### Typography
|
||||
|
||||
**Font Families:**
|
||||
|
||||
- **Primary:** {{primary_font}}
|
||||
- **Secondary:** {{secondary_font}}
|
||||
- **Monospace:** {{mono_font}}
|
||||
@@ -283,16 +305,19 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
### Key Requirements
|
||||
|
||||
**Visual:**
|
||||
|
||||
- Color contrast ratios: {{contrast_requirements}}
|
||||
- Focus indicators: {{focus_requirements}}
|
||||
- Text sizing: {{text_requirements}}
|
||||
|
||||
**Interaction:**
|
||||
|
||||
- Keyboard navigation: {{keyboard_requirements}}
|
||||
- Screen reader support: {{screen_reader_requirements}}
|
||||
- Touch targets: {{touch_requirements}}
|
||||
|
||||
**Content:**
|
||||
|
||||
- Alternative text: {{alt_text_requirements}}
|
||||
- Heading structure: {{heading_requirements}}
|
||||
- Form labels: {{form_requirements}}
|
||||
@@ -309,12 +334,12 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Breakpoints
|
||||
|
||||
| Breakpoint | Min Width | Max Width | Target Devices |
|
||||
|:-----------|:----------|:----------|:---------------|
|
||||
| Mobile | {{mobile_min}} | {{mobile_max}} | {{mobile_devices}} |
|
||||
| Tablet | {{tablet_min}} | {{tablet_max}} | {{tablet_devices}} |
|
||||
| Desktop | {{desktop_min}} | {{desktop_max}} | {{desktop_devices}} |
|
||||
| Wide | {{wide_min}} | - | {{wide_devices}} |
|
||||
| Breakpoint | Min Width | Max Width | Target Devices |
|
||||
| :--------- | :-------------- | :-------------- | :------------------ |
|
||||
| Mobile | {{mobile_min}} | {{mobile_max}} | {{mobile_devices}} |
|
||||
| Tablet | {{tablet_min}} | {{tablet_max}} | {{tablet_devices}} |
|
||||
| Desktop | {{desktop_min}} | {{desktop_max}} | {{desktop_devices}} |
|
||||
| Wide | {{wide_min}} | - | {{wide_devices}} |
|
||||
|
||||
### Adaptation Patterns
|
||||
|
||||
@@ -339,8 +364,9 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
### Key Animations
|
||||
|
||||
<<REPEAT: animation>>
|
||||
|
||||
- **{{animation_name}}:** {{animation_description}} (Duration: {{duration}}, Easing: {{easing}})
|
||||
<</REPEAT>>
|
||||
<</REPEAT>>
|
||||
|
||||
## Performance Considerations
|
||||
|
||||
@@ -380,14 +406,6 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
- [ ] Brand guidelines incorporated
|
||||
- [ ] Performance goals established
|
||||
|
||||
## Change Log
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
|:-----|:--------|:------------|:-------|
|
||||
| {{date}} | 1.0.0 | Initial UI/UX specification | {{author}} |
|
||||
|
||||
---
|
||||
|
||||
## Checklist Results
|
||||
|
||||
[[LLM: If a UI/UX checklist exists, run it against this document and report results here.]]
|
||||
[[LLM: If a UI/UX checklist exists, run it against this document and report results here.]]
|
||||
|
||||
@@ -40,6 +40,13 @@ This unified approach combines what would traditionally be separate backend and
|
||||
|
||||
If none, state "N/A - Greenfield project"
|
||||
|
||||
### Change Log
|
||||
|
||||
[[LLM: Track document versions and changes]]
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
| :--- | :------ | :---------- | :----- |
|
||||
|
||||
## High Level Architecture
|
||||
|
||||
[[LLM: This section contains multiple subsections that establish the foundation. Present all subsections together, then apply `tasks#advanced-elicitation` protocol to the complete section.]]
|
||||
@@ -221,7 +228,7 @@ After presenting all data models, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
- {{relationship_1}}
|
||||
- {{relationship_2}}
|
||||
<</REPEAT>>
|
||||
<</REPEAT>>
|
||||
|
||||
@{example: data_model}
|
||||
|
||||
@@ -261,7 +268,7 @@ interface UserProfile {
|
||||
|
||||
- Has many Posts (1:n)
|
||||
- Has one Profile (1:1)
|
||||
@{/example}
|
||||
@{/example}
|
||||
|
||||
## REST API Spec
|
||||
|
||||
@@ -988,20 +995,10 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
- Response time
|
||||
- Database query performance
|
||||
|
||||
## Change Log
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
| :------- | :------ | :----------------------------- | :--------- |
|
||||
| {{date}} | 1.0.0 | Initial fullstack architecture | {{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.]]
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
[[LLM: Provide specific next steps for implementation.]]
|
||||
|
||||
@@ -1,406 +0,0 @@
|
||||
# {{Project Name}} Infrastructure Architecture
|
||||
|
||||
[[LLM: Initial Setup
|
||||
|
||||
1. Replace {{Project Name}} with the actual project name throughout the document
|
||||
2. Gather and review required inputs:
|
||||
- Product Requirements Document (PRD) - Required for business needs and scale requirements
|
||||
- Main System Architecture - Required for infrastructure dependencies
|
||||
- Technical Preferences/Tech Stack Document - Required for technology choices
|
||||
- PRD Technical Assumptions - Required for cross-referencing repository and service architecture
|
||||
|
||||
If any required documents are missing, ask user: "I need the following documents to create a comprehensive infrastructure architecture: [list missing]. Would you like to proceed with available information or provide the missing documents first?"
|
||||
|
||||
3. <critical_rule>Cross-reference with PRD Technical Assumptions to ensure infrastructure decisions align with repository and service architecture decisions made in the system architecture.</critical_rule>
|
||||
|
||||
Output file location: `docs/infrastructure-architecture.md`]]
|
||||
|
||||
## Infrastructure Overview
|
||||
|
||||
[[LLM: Review the product requirements document to understand business needs and scale requirements. Analyze the main system architecture to identify infrastructure dependencies. Document non-functional requirements (performance, scalability, reliability, security). Cross-reference with PRD Technical Assumptions to ensure alignment with repository and service architecture decisions.]]
|
||||
|
||||
- Cloud Provider(s)
|
||||
- Core Services & Resources
|
||||
- Regional Architecture
|
||||
- Multi-environment Strategy
|
||||
|
||||
@{example: cloud_strategy}
|
||||
|
||||
- **Cloud Provider:** AWS (primary), with multi-cloud capability for critical services
|
||||
- **Core Services:** EKS for container orchestration, RDS for databases, S3 for storage, CloudFront for CDN
|
||||
- **Regional Architecture:** Multi-region active-passive with primary in us-east-1, DR in us-west-2
|
||||
- **Multi-environment Strategy:** Development, Staging, UAT, Production with identical infrastructure patterns
|
||||
|
||||
@{/example}
|
||||
|
||||
[[LLM: Infrastructure Elicitation Options
|
||||
Present user with domain-specific elicitation options:
|
||||
"For the Infrastructure Overview section, I can explore:
|
||||
1. **Multi-Cloud Strategy Analysis** - Evaluate cloud provider options and vendor lock-in considerations
|
||||
2. **Regional Distribution Planning** - Analyze latency requirements and data residency needs
|
||||
3. **Environment Isolation Strategy** - Design security boundaries and resource segregation
|
||||
4. **Scalability Patterns Review** - Assess auto-scaling needs and traffic patterns
|
||||
5. **Compliance Requirements Analysis** - Review regulatory and security compliance needs
|
||||
6. **Cost-Benefit Analysis** - Compare infrastructure options and TCO
|
||||
7. **Proceed to next section**
|
||||
|
||||
Select an option (1-7):"]]
|
||||
|
||||
## Infrastructure as Code (IaC)
|
||||
|
||||
[[LLM: Define IaC approach based on technical preferences and existing patterns. Consider team expertise, tooling ecosystem, and maintenance requirements.]]
|
||||
|
||||
- Tools & Frameworks
|
||||
- Repository Structure
|
||||
- State Management
|
||||
- Dependency Management
|
||||
|
||||
<critical_rule>All infrastructure must be defined as code. No manual resource creation in production environments.</critical_rule>
|
||||
|
||||
## Environment Configuration
|
||||
|
||||
[[LLM: Design environment strategy that supports the development workflow while maintaining security and cost efficiency. Reference the Environment Transition Strategy section for promotion details.]]
|
||||
|
||||
- Environment Promotion Strategy
|
||||
- Configuration Management
|
||||
- Secret Management
|
||||
- Feature Flag Integration
|
||||
|
||||
<<REPEAT: environment>>
|
||||
|
||||
### {{environment_name}} Environment
|
||||
|
||||
- **Purpose:** {{environment_purpose}}
|
||||
- **Resources:** {{environment_resources}}
|
||||
- **Access Control:** {{environment_access}}
|
||||
- **Data Classification:** {{environment_data_class}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
## Environment Transition Strategy
|
||||
|
||||
[[LLM: Detail the complete lifecycle of code and configuration changes from development to production. Include governance, testing gates, and rollback procedures.]]
|
||||
|
||||
- Development to Production Pipeline
|
||||
- Deployment Stages and Gates
|
||||
- Approval Workflows and Authorities
|
||||
- Rollback Procedures
|
||||
- Change Cadence and Release Windows
|
||||
- Environment-Specific Configuration Management
|
||||
|
||||
## Network Architecture
|
||||
|
||||
[[LLM: Design network topology considering security zones, traffic patterns, and compliance requirements. Reference main architecture for service communication patterns.
|
||||
|
||||
Create Mermaid diagram showing:
|
||||
- VPC/Network structure
|
||||
- Security zones and boundaries
|
||||
- Traffic flow patterns
|
||||
- Load balancer placement
|
||||
- Service mesh topology (if applicable)]]
|
||||
|
||||
- VPC/VNET Design
|
||||
- Subnet Strategy
|
||||
- Security Groups & NACLs
|
||||
- Load Balancers & API Gateways
|
||||
- Service Mesh (if applicable)
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph "Production VPC"
|
||||
subgraph "Public Subnets"
|
||||
ALB[Application Load Balancer]
|
||||
end
|
||||
subgraph "Private Subnets"
|
||||
EKS[EKS Cluster]
|
||||
RDS[(RDS Database)]
|
||||
end
|
||||
end
|
||||
Internet((Internet)) --> ALB
|
||||
ALB --> EKS
|
||||
EKS --> RDS
|
||||
```
|
||||
|
||||
^^CONDITION: uses_service_mesh^^
|
||||
|
||||
### Service Mesh Architecture
|
||||
|
||||
- **Mesh Technology:** {{service_mesh_tech}}
|
||||
- **Traffic Management:** {{traffic_policies}}
|
||||
- **Security Policies:** {{mesh_security}}
|
||||
- **Observability Integration:** {{mesh_observability}}
|
||||
|
||||
^^/CONDITION: uses_service_mesh^^
|
||||
|
||||
## Compute Resources
|
||||
|
||||
[[LLM: Select compute strategy based on application architecture (microservices, serverless, monolithic). Consider cost, scalability, and operational complexity.]]
|
||||
|
||||
- Container Strategy
|
||||
- Serverless Architecture
|
||||
- VM/Instance Configuration
|
||||
- Auto-scaling Approach
|
||||
|
||||
^^CONDITION: uses_kubernetes^^
|
||||
|
||||
### Kubernetes Architecture
|
||||
|
||||
- **Cluster Configuration:** {{k8s_cluster_config}}
|
||||
- **Node Groups:** {{k8s_node_groups}}
|
||||
- **Networking:** {{k8s_networking}}
|
||||
- **Storage Classes:** {{k8s_storage}}
|
||||
- **Security Policies:** {{k8s_security}}
|
||||
|
||||
^^/CONDITION: uses_kubernetes^^
|
||||
|
||||
## Data Resources
|
||||
|
||||
[[LLM: Design data infrastructure based on data architecture from main system design. Consider data volumes, access patterns, compliance, and recovery requirements.
|
||||
|
||||
Create data flow diagram showing:
|
||||
- Database topology
|
||||
- Replication patterns
|
||||
- Backup flows
|
||||
- Data migration paths]]
|
||||
|
||||
- Database Deployment Strategy
|
||||
- Backup & Recovery
|
||||
- Replication & Failover
|
||||
- Data Migration Strategy
|
||||
|
||||
## Security Architecture
|
||||
|
||||
[[LLM: Implement defense-in-depth strategy. Reference security requirements from PRD and compliance needs. Consider zero-trust principles where applicable.]]
|
||||
|
||||
- IAM & Authentication
|
||||
- Network Security
|
||||
- Data Encryption
|
||||
- Compliance Controls
|
||||
- Security Scanning & Monitoring
|
||||
|
||||
<critical_rule>Apply principle of least privilege for all access controls. Document all security exceptions with business justification.</critical_rule>
|
||||
|
||||
## Shared Responsibility Model
|
||||
|
||||
[[LLM: Clearly define boundaries between cloud provider, platform team, development team, and security team responsibilities. This is critical for operational success.]]
|
||||
|
||||
- Cloud Provider Responsibilities
|
||||
- Platform Team Responsibilities
|
||||
- Development Team Responsibilities
|
||||
- Security Team Responsibilities
|
||||
- Operational Monitoring Ownership
|
||||
- Incident Response Accountability Matrix
|
||||
|
||||
@{example: responsibility_matrix}
|
||||
|
||||
| Component | Cloud Provider | Platform Team | Dev Team | Security Team |
|
||||
|-----------|---------------|---------------|----------|---------------|
|
||||
| Physical Security | ✓ | - | - | Audit |
|
||||
| Network Security | Partial | ✓ | Config | Audit |
|
||||
| Application Security | - | Tools | ✓ | Review |
|
||||
| Data Encryption | Engine | Config | Implementation | Standards |
|
||||
|
||||
@{/example}
|
||||
|
||||
## Monitoring & Observability
|
||||
|
||||
[[LLM: Design comprehensive observability strategy covering metrics, logs, traces, and business KPIs. Ensure alignment with SLA/SLO requirements.]]
|
||||
|
||||
- Metrics Collection
|
||||
- Logging Strategy
|
||||
- Tracing Implementation
|
||||
- Alerting & Incident Response
|
||||
- Dashboards & Visualization
|
||||
|
||||
## CI/CD Pipeline
|
||||
|
||||
[[LLM: Design deployment pipeline that balances speed with safety. Include progressive deployment strategies and automated quality gates.
|
||||
|
||||
Create pipeline diagram showing:
|
||||
- Build stages
|
||||
- Test gates
|
||||
- Deployment stages
|
||||
- Approval points
|
||||
- Rollback triggers]]
|
||||
|
||||
- Pipeline Architecture
|
||||
- Build Process
|
||||
- Deployment Strategy
|
||||
- Rollback Procedures
|
||||
- Approval Gates
|
||||
|
||||
^^CONDITION: uses_progressive_deployment^^
|
||||
|
||||
### Progressive Deployment Strategy
|
||||
|
||||
- **Canary Deployment:** {{canary_config}}
|
||||
- **Blue-Green Deployment:** {{blue_green_config}}
|
||||
- **Feature Flags:** {{feature_flag_integration}}
|
||||
- **Traffic Splitting:** {{traffic_split_rules}}
|
||||
|
||||
^^/CONDITION: uses_progressive_deployment^^
|
||||
|
||||
## Disaster Recovery
|
||||
|
||||
[[LLM: Design DR strategy based on business continuity requirements. Define clear RTO/RPO targets and ensure they align with business needs.]]
|
||||
|
||||
- Backup Strategy
|
||||
- Recovery Procedures
|
||||
- RTO & RPO Targets
|
||||
- DR Testing Approach
|
||||
|
||||
<critical_rule>DR procedures must be tested at least quarterly. Document test results and improvement actions.</critical_rule>
|
||||
|
||||
## Cost Optimization
|
||||
|
||||
[[LLM: Balance cost efficiency with performance and reliability requirements. Include both immediate optimizations and long-term strategies.]]
|
||||
|
||||
- Resource Sizing Strategy
|
||||
- Reserved Instances/Commitments
|
||||
- Cost Monitoring & Reporting
|
||||
- Optimization Recommendations
|
||||
|
||||
## BMAD Integration Architecture
|
||||
|
||||
[[LLM: Design infrastructure to specifically support other BMAD agents and their workflows. This ensures the infrastructure enables the entire BMAD methodology.]]
|
||||
|
||||
### Development Agent Support
|
||||
- Container platform for development environments
|
||||
- GitOps workflows for application deployment
|
||||
- Service mesh integration for development testing
|
||||
- Developer self-service platform capabilities
|
||||
|
||||
### Product & Architecture Alignment
|
||||
- Infrastructure implementing PRD scalability requirements
|
||||
- Deployment automation supporting product iteration speed
|
||||
- Service reliability meeting product SLAs
|
||||
- Architecture patterns properly implemented in infrastructure
|
||||
|
||||
### Cross-Agent Integration Points
|
||||
- CI/CD pipelines supporting Frontend, Backend, and Full Stack development workflows
|
||||
- Monitoring and observability data accessible to QA and DevOps agents
|
||||
- Infrastructure enabling Design Architect's UI/UX performance requirements
|
||||
- Platform supporting Analyst's data collection and analysis needs
|
||||
|
||||
## DevOps/Platform Feasibility Review
|
||||
|
||||
[[LLM: CRITICAL STEP - Present architectural blueprint summary to DevOps/Platform Engineering Agent for feasibility review. Request specific feedback on:
|
||||
|
||||
- **Operational Complexity:** Are the proposed patterns implementable with current tooling and expertise?
|
||||
- **Resource Constraints:** Do infrastructure requirements align with available resources and budgets?
|
||||
- **Security Implementation:** Are security patterns achievable with current security toolchain?
|
||||
- **Operational Overhead:** Will the proposed architecture create excessive operational burden?
|
||||
- **Technology Constraints:** Are selected technologies compatible with existing infrastructure?
|
||||
|
||||
Document all feasibility feedback and concerns raised. Iterate on architectural decisions based on operational constraints and feedback.
|
||||
|
||||
<critical_rule>Address all critical feasibility concerns before proceeding to final architecture documentation. If critical blockers identified, revise architecture before continuing.</critical_rule>]]
|
||||
|
||||
### Feasibility Assessment Results
|
||||
|
||||
- **Green Light Items:** {{feasible_items}}
|
||||
- **Yellow Light Items:** {{items_needing_adjustment}}
|
||||
- **Red Light Items:** {{items_requiring_redesign}}
|
||||
- **Mitigation Strategies:** {{mitigation_plans}}
|
||||
|
||||
## Infrastructure Verification
|
||||
|
||||
### Validation Framework
|
||||
|
||||
This infrastructure architecture will be validated using the comprehensive `infrastructure-checklist.md`, with particular focus on Section 12: Architecture Documentation Validation. The checklist ensures:
|
||||
|
||||
- Completeness of architecture documentation
|
||||
- Consistency with broader system architecture
|
||||
- Appropriate level of detail for different stakeholders
|
||||
- Clear implementation guidance
|
||||
- Future evolution considerations
|
||||
|
||||
### Validation Process
|
||||
|
||||
The architecture documentation validation should be performed:
|
||||
|
||||
- After initial architecture development
|
||||
- After significant architecture changes
|
||||
- Before major implementation phases
|
||||
- During periodic architecture reviews
|
||||
|
||||
The Platform Engineer should use the infrastructure checklist to systematically validate all aspects of this architecture document.
|
||||
|
||||
## Implementation Handoff
|
||||
|
||||
[[LLM: Create structured handoff documentation for implementation team. This ensures architecture decisions are properly communicated and implemented.]]
|
||||
|
||||
### Architecture Decision Records (ADRs)
|
||||
|
||||
Create ADRs for key infrastructure decisions:
|
||||
- Cloud provider selection rationale
|
||||
- Container orchestration platform choice
|
||||
- Networking architecture decisions
|
||||
- Security implementation choices
|
||||
- Cost optimization trade-offs
|
||||
|
||||
### Implementation Validation Criteria
|
||||
|
||||
Define specific criteria for validating correct implementation:
|
||||
- Infrastructure as Code quality gates
|
||||
- Security compliance checkpoints
|
||||
- Performance benchmarks
|
||||
- Cost targets
|
||||
- Operational readiness criteria
|
||||
|
||||
### Knowledge Transfer Requirements
|
||||
|
||||
- Technical documentation for operations team
|
||||
- Runbook creation requirements
|
||||
- Training needs for platform team
|
||||
- Handoff meeting agenda items
|
||||
|
||||
## Infrastructure Evolution
|
||||
|
||||
[[LLM: Document the long-term vision and evolution path for the infrastructure. Consider technology trends, anticipated growth, and technical debt management.]]
|
||||
|
||||
- Technical Debt Inventory
|
||||
- Planned Upgrades and Migrations
|
||||
- Deprecation Schedule
|
||||
- Technology Roadmap
|
||||
- Capacity Planning
|
||||
- Scalability Considerations
|
||||
|
||||
## Integration with Application Architecture
|
||||
|
||||
[[LLM: Map infrastructure components to application services. Ensure infrastructure design supports application requirements and patterns defined in main architecture.]]
|
||||
|
||||
- Service-to-Infrastructure Mapping
|
||||
- Application Dependency Matrix
|
||||
- Performance Requirements Implementation
|
||||
- Security Requirements Implementation
|
||||
- Data Flow to Infrastructure Correlation
|
||||
- API Gateway and Service Mesh Integration
|
||||
|
||||
## Cross-Team Collaboration
|
||||
|
||||
[[LLM: Define clear interfaces and communication patterns between teams. This section is critical for operational success and should include specific touchpoints and escalation paths.]]
|
||||
|
||||
- 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
|
||||
|
||||
## Infrastructure Change Management
|
||||
|
||||
[[LLM: Define structured process for infrastructure changes. Include risk assessment, testing requirements, and rollback procedures.]]
|
||||
|
||||
- Change Request Process
|
||||
- Risk Assessment
|
||||
- Testing Strategy
|
||||
- Validation Procedures
|
||||
|
||||
[[LLM: Final Review - Ensure all sections are complete and consistent. Verify feasibility review was conducted and all concerns addressed. Apply final validation against infrastructure checklist.]]
|
||||
|
||||
---
|
||||
|
||||
*Document Version: 1.0*
|
||||
*Last Updated: {{current_date}}*
|
||||
*Next Review: {{review_date}}*
|
||||
Binary file not shown.
@@ -14,6 +14,13 @@
|
||||
|
||||
[[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]]
|
||||
@@ -178,27 +185,16 @@ 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 ------
|
||||
|
||||
@@ -43,7 +43,9 @@
|
||||
|
||||
{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.
|
||||
|
||||
|
||||
@@ -1,16 +1,16 @@
|
||||
# Story {EpicNum}.{StoryNum}: {Short Title Copied from Epic File}
|
||||
# Story {{EpicNum}}.{{StoryNum}}: {{Short Title Copied from Epic File}}
|
||||
|
||||
## Status: { Draft | Approved | InProgress | Review | Done }
|
||||
## 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
|
||||
|
||||
@@ -23,7 +23,7 @@
|
||||
|
||||
## 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
|
||||
|
||||
@@ -39,4 +39,7 @@
|
||||
|
||||
### 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 |
|
||||
| :--- | :------ | :---------- | :----- |
|
||||
|
||||
Reference in New Issue
Block a user