agent team workflows
This commit is contained in:
Brian Madison
@@ -54,7 +54,7 @@ Only needed if you want to customize agents:
|
||||
### Configuring Custom Agents
|
||||
|
||||
- Edit YAML files in `/agents/` to customize behavior
|
||||
- Create new team combinations in `team-*.yml` files
|
||||
- Create new team combinations in `/agent-teams/` directory
|
||||
- All configuration is now YAML-based for easy editing
|
||||
|
||||
### IDE Slash Commands
|
||||
|
||||
188
agent-team-workflows/api-only.yml
Normal file
188
agent-team-workflows/api-only.yml
Normal file
@@ -0,0 +1,188 @@
|
||||
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
|
||||
229
agent-team-workflows/backend-service.yml
Normal file
229
agent-team-workflows/backend-service.yml
Normal file
@@ -0,0 +1,229 @@
|
||||
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
|
||||
193
agent-team-workflows/brownfield-enhancement.yml
Normal file
193
agent-team-workflows/brownfield-enhancement.yml
Normal file
@@ -0,0 +1,193 @@
|
||||
workflow:
|
||||
id: brownfield-enhancement
|
||||
name: Brownfield Enhancement
|
||||
description: >-
|
||||
Workflow for adding features, refactoring, or modernizing existing applications.
|
||||
Handles legacy code analysis and incremental improvements.
|
||||
type: brownfield
|
||||
project_types:
|
||||
- feature-addition
|
||||
- refactoring
|
||||
- modernization
|
||||
- bug-fix
|
||||
|
||||
stages:
|
||||
- id: system-analysis
|
||||
name: Existing System Analysis
|
||||
description: Understand current system and identify improvement areas
|
||||
steps:
|
||||
- agent: analyst
|
||||
action: System Assessment
|
||||
description: >-
|
||||
Analyze existing system, codebase, and identify pain points
|
||||
inputs:
|
||||
- existing-documentation
|
||||
- codebase-access
|
||||
outputs:
|
||||
- system-assessment
|
||||
- improvement-opportunities
|
||||
- technical-debt-analysis
|
||||
prompts:
|
||||
- "Let's analyze the existing system architecture"
|
||||
- "What are the main pain points and technical debt?"
|
||||
- "Share any existing documentation or system diagrams"
|
||||
- "You can also share the codebase if you have access to it"
|
||||
|
||||
- agent: dev
|
||||
action: Code Analysis
|
||||
description: >-
|
||||
Deep dive into codebase quality and structure
|
||||
inputs:
|
||||
- codebase-access
|
||||
outputs:
|
||||
- code-quality-report
|
||||
- dependency-analysis
|
||||
- refactoring-candidates
|
||||
prompts:
|
||||
- "Let me analyze the code structure and quality"
|
||||
- "Identifying areas that need refactoring"
|
||||
|
||||
- id: enhancement-planning
|
||||
name: Enhancement Planning
|
||||
description: Plan improvements and new features
|
||||
steps:
|
||||
- agent: pm
|
||||
action: Enhancement Strategy
|
||||
description: >-
|
||||
Define enhancement goals and success criteria
|
||||
inputs:
|
||||
- system-assessment
|
||||
- improvement-opportunities
|
||||
outputs:
|
||||
- enhancement-prd
|
||||
- success-metrics
|
||||
- risk-assessment
|
||||
prompts:
|
||||
- "What specific enhancements are we targeting?"
|
||||
- "Define success metrics for these improvements"
|
||||
|
||||
- agent: architect
|
||||
action: Integration Architecture
|
||||
description: >-
|
||||
Design how new features integrate with existing system
|
||||
inputs:
|
||||
- enhancement-prd
|
||||
- system-assessment
|
||||
outputs:
|
||||
- integration-architecture
|
||||
- migration-strategy
|
||||
- compatibility-matrix
|
||||
prompts:
|
||||
- "How will new features integrate with existing code?"
|
||||
- "Design migration strategy for gradual rollout"
|
||||
|
||||
- id: incremental-design
|
||||
name: Incremental Design
|
||||
description: Design changes that don't break existing functionality
|
||||
steps:
|
||||
- agent: fullstack-architect
|
||||
action: Incremental Architecture
|
||||
description: >-
|
||||
Design architecture that allows gradual migration
|
||||
inputs:
|
||||
- integration-architecture
|
||||
- technical-debt-analysis
|
||||
outputs:
|
||||
- incremental-architecture
|
||||
- feature-flags-design
|
||||
- rollback-strategy
|
||||
prompts:
|
||||
- "Design architecture for incremental deployment"
|
||||
- "How do we maintain backward compatibility?"
|
||||
|
||||
- agent: devops
|
||||
action: Deployment Strategy
|
||||
description: >-
|
||||
Plan zero-downtime deployment and rollback procedures
|
||||
inputs:
|
||||
- incremental-architecture
|
||||
outputs:
|
||||
- deployment-strategy
|
||||
- canary-release-plan
|
||||
- monitoring-upgrades
|
||||
prompts:
|
||||
- "Design blue-green or canary deployment"
|
||||
- "Upgrade monitoring for new features"
|
||||
|
||||
- id: risk-mitigation
|
||||
name: Risk Assessment & Mitigation
|
||||
description: Identify and plan for risks in brownfield changes
|
||||
steps:
|
||||
- agent: qa
|
||||
action: Regression Risk Analysis
|
||||
description: >-
|
||||
Identify regression risks and test coverage gaps
|
||||
inputs:
|
||||
- code-quality-report
|
||||
- integration-architecture
|
||||
outputs:
|
||||
- regression-risk-matrix
|
||||
- test-gap-analysis
|
||||
- test-automation-plan
|
||||
prompts:
|
||||
- "What existing functionality might break?"
|
||||
- "Where do we need additional test coverage?"
|
||||
|
||||
- agent: po
|
||||
action: Change Impact Review
|
||||
description: >-
|
||||
Review all changes for business impact
|
||||
inputs:
|
||||
- enhancement-prd
|
||||
- risk-assessment
|
||||
- regression-risk-matrix
|
||||
outputs:
|
||||
- impact-analysis
|
||||
- stakeholder-communication
|
||||
- approval-checklist
|
||||
prompts:
|
||||
- "Review impact on existing users and workflows"
|
||||
- "Prepare stakeholder communication plan"
|
||||
|
||||
- id: implementation-planning
|
||||
name: Phased Implementation
|
||||
description: Create phased implementation plan
|
||||
steps:
|
||||
- agent: sm
|
||||
action: Phased Story Creation
|
||||
description: >-
|
||||
Create stories for incremental implementation
|
||||
inputs:
|
||||
- incremental-architecture
|
||||
- impact-analysis
|
||||
outputs:
|
||||
- implementation-phases
|
||||
- user-stories
|
||||
- dependency-map
|
||||
prompts:
|
||||
- "Break down into safe, incremental phases"
|
||||
- "Map dependencies between stories"
|
||||
|
||||
transitions:
|
||||
- from: system-analysis
|
||||
to: enhancement-planning
|
||||
condition: assessment complete
|
||||
- from: enhancement-planning
|
||||
to: incremental-design
|
||||
condition: strategy defined
|
||||
- from: incremental-design
|
||||
to: risk-mitigation
|
||||
condition: architecture approved
|
||||
- from: risk-mitigation
|
||||
to: implementation-planning
|
||||
condition: risks assessed
|
||||
|
||||
special_considerations:
|
||||
- name: Legacy Code
|
||||
description: Handle undocumented or poorly structured code
|
||||
- name: Data Migration
|
||||
description: Plan for data structure changes
|
||||
- name: User Training
|
||||
description: Consider impact on existing users
|
||||
- name: Rollback Plan
|
||||
description: Always have a way to revert changes
|
||||
219
agent-team-workflows/frontend-only.yml
Normal file
219
agent-team-workflows/frontend-only.yml
Normal file
@@ -0,0 +1,219 @@
|
||||
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
|
||||
227
agent-team-workflows/fullstack-app.yml
Normal file
227
agent-team-workflows/fullstack-app.yml
Normal file
@@ -0,0 +1,227 @@
|
||||
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
|
||||
179
agent-team-workflows/greenfield-mvp.yml
Normal file
179
agent-team-workflows/greenfield-mvp.yml
Normal file
@@ -0,0 +1,179 @@
|
||||
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
|
||||
@@ -5,13 +5,12 @@ bundle:
|
||||
|
||||
agents:
|
||||
- bmad
|
||||
- analyst
|
||||
- pm
|
||||
- ux-expert
|
||||
- architect
|
||||
- fullstack-architect
|
||||
- design-architect
|
||||
- po
|
||||
- sm
|
||||
- qa
|
||||
- dev
|
||||
- "*"
|
||||
|
||||
workflows:
|
||||
- greenfield-mvp
|
||||
- fullstack-app
|
||||
- api-only
|
||||
- brownfield-enhancement
|
||||
- frontend-only
|
||||
- backend-service
|
||||
16
agent-teams/team-fullstack.yml
Normal file
16
agent-teams/team-fullstack.yml
Normal file
@@ -0,0 +1,16 @@
|
||||
bundle:
|
||||
name: Full-Stack Development Team
|
||||
description: >-
|
||||
Comprehensive full-stack development team capable of handling both greenfield
|
||||
application development and brownfield enhancement projects. This team combines
|
||||
strategic planning, user experience design, and holistic system architecture
|
||||
to deliver complete solutions from concept to deployment. Specializes in
|
||||
full-stack applications, SaaS platforms, enterprise apps, feature additions,
|
||||
refactoring, and system modernization.
|
||||
target_environment: web
|
||||
|
||||
agents:
|
||||
- bmad
|
||||
- pm
|
||||
- ux-expert
|
||||
- fullstack-architect
|
||||
11
agent-teams/team-planning-no-ui.yml
Normal file
11
agent-teams/team-planning-no-ui.yml
Normal file
@@ -0,0 +1,11 @@
|
||||
bundle:
|
||||
name: Team Planning No UI
|
||||
description: This is a team that is responsible for planning the project without any UI/UX design. This is for backend only projects.
|
||||
target_environment: web
|
||||
|
||||
agents:
|
||||
- bmad
|
||||
- analyst
|
||||
- pm
|
||||
- architect
|
||||
- po
|
||||
@@ -16,3 +16,8 @@ dependencies:
|
||||
- bmad-kb
|
||||
utils:
|
||||
- orchestrator-commands
|
||||
- workflow-management
|
||||
- create-agent
|
||||
- create-ide-agent
|
||||
- create-team
|
||||
- create-expansion-pack
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
agent:
|
||||
id: pm
|
||||
name: John
|
||||
title: Product Manager
|
||||
description: >-
|
||||
|
||||
@@ -1,10 +0,0 @@
|
||||
bundle:
|
||||
name: Team Planning No UI
|
||||
target_environment: web
|
||||
|
||||
agents:
|
||||
- bmad
|
||||
- analyst
|
||||
- pm
|
||||
- architect
|
||||
- po
|
||||
@@ -1,9 +1,9 @@
|
||||
agent:
|
||||
name: Jane
|
||||
id: design-architect
|
||||
title: Design Architect
|
||||
id: ui-architect
|
||||
title: UI Architect
|
||||
description: For UI/UX specifications, front-end architecture, and UI 1-shot prompting.
|
||||
persona: design-architect
|
||||
persona: ui-architect
|
||||
customize: ""
|
||||
dependencies:
|
||||
tasks:
|
||||
@@ -18,7 +18,7 @@
|
||||
- [Business Analyst](#business-analyst)
|
||||
- [Product Manager](#product-manager)
|
||||
- [Architect](#architect)
|
||||
- [Design Architect](#design-architect)
|
||||
- [UI Architect](#ui-architect)
|
||||
- [Product Owner](#product-owner)
|
||||
- [Scrum Master](#scrum-master)
|
||||
- [Developer](#developer)
|
||||
@@ -370,7 +370,7 @@ npm run validate
|
||||
- Technology selection
|
||||
- Integration planning
|
||||
|
||||
### Design Architect
|
||||
### UI Architect
|
||||
|
||||
**Name**: Jane (Web) / Millie (IDE)
|
||||
**Purpose**: UI/UX and frontend architecture
|
||||
@@ -581,8 +581,8 @@ bmad-core/
|
||||
├── data/ # Knowledge bases and preferences
|
||||
└── ide-agents/ # Standalone IDE agent files
|
||||
|
||||
agents/ # YAML agent configurations
|
||||
bundles/ # Bundle configurations (team-*.yml)
|
||||
agents/ # Individual agent YAML configurations
|
||||
agent-teams/ # Team bundle configurations (team-*.yml)
|
||||
tools/ # Build tooling and scripts
|
||||
dist/ # Build output
|
||||
```
|
||||
|
||||
28
bmad-core/ide-agents/bmad.ide.md
Normal file
28
bmad-core/ide-agents/bmad.ide.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# /bmad
|
||||
|
||||
You are BMad, the BMAD Method orchestrator and expert guide.
|
||||
|
||||
## Expertise
|
||||
|
||||
- BMAD Method implementation
|
||||
- Agent creation and configuration
|
||||
- Team composition and dynamics
|
||||
- Expansion pack development
|
||||
|
||||
## Approach
|
||||
|
||||
I provide hands-on guidance for customizing and extending BMAD to your specific needs.
|
||||
|
||||
## Focus
|
||||
|
||||
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
|
||||
|
||||
Available utilities: create-agent, create-ide-agent, create-team, create-expansion-pack
|
||||
132
bmad-core/utils/create-agent.md
Normal file
132
bmad-core/utils/create-agent.md
Normal file
@@ -0,0 +1,132 @@
|
||||
# Create Agent Utility
|
||||
|
||||
This utility helps you create a new BMAD agent for web platforms (Gemini, ChatGPT, etc.).
|
||||
|
||||
## Process
|
||||
|
||||
Follow these steps to create a new agent:
|
||||
|
||||
### 1. Gather Basic Information
|
||||
|
||||
Ask the user for:
|
||||
|
||||
- **Agent ID**: A short, lowercase identifier (e.g., `data-analyst`, `security-expert`)
|
||||
- **Agent Name**: The character name (e.g., "Elena", "Marcus")
|
||||
- **Title**: Professional title (e.g., "Data Analyst", "Security Expert")
|
||||
- **Description**: A brief description of the agent's role and primary focus
|
||||
|
||||
### 2. Define Personality and Expertise
|
||||
|
||||
Ask about:
|
||||
|
||||
- **Personality traits**: How should this agent behave? (professional, friendly, detail-oriented, etc.)
|
||||
- **Communication style**: How do they speak? (formal, casual, technical, empathetic)
|
||||
- **Expertise areas**: What are they exceptionally good at?
|
||||
- **Years of experience**: How senior are they in their role?
|
||||
- **Motivations**: What drives them to excel?
|
||||
|
||||
### 3. Identify Capabilities
|
||||
|
||||
Determine what the agent can do:
|
||||
|
||||
- **Existing tasks**: Which existing tasks from `/bmad-core/tasks/` should this agent know?
|
||||
- **New tasks needed**: Does this agent need any specialized tasks that don't exist yet?
|
||||
- **Templates used**: Which document templates will this agent work with?
|
||||
- **Checklists**: Which quality checklists apply to this agent's work?
|
||||
|
||||
### 4. Create the Persona File
|
||||
|
||||
Create `/bmad-core/personas/{agent-id}.md` with this structure:
|
||||
|
||||
```markdown
|
||||
# {Agent Name} - {Title}
|
||||
|
||||
## Character Profile
|
||||
|
||||
**Name:** {Agent Name}
|
||||
**Title:** {Title}
|
||||
**Experience:** {Years} years in {field}
|
||||
|
||||
## Personality
|
||||
|
||||
{Describe personality traits, communication style, and approach to work}
|
||||
|
||||
## Core Expertise
|
||||
|
||||
{List main areas of expertise and specialization}
|
||||
|
||||
## Responsibilities
|
||||
|
||||
{List key responsibilities in bullet points}
|
||||
|
||||
## Working Style
|
||||
|
||||
{Describe how they approach problems, collaborate, and deliver results}
|
||||
|
||||
## Motivations
|
||||
|
||||
{What drives them to excel in their role}
|
||||
|
||||
## Catchphrases
|
||||
|
||||
{Optional: Any signature phrases or ways of speaking}
|
||||
```
|
||||
|
||||
### 5. Create the Agent Configuration
|
||||
|
||||
Create `/agents/{agent-id}.yml` with this structure:
|
||||
|
||||
```yaml
|
||||
agent:
|
||||
id: {agent-id}
|
||||
name: {Agent Name}
|
||||
title: {Title}
|
||||
description: >-
|
||||
{Full description of the agent's role and value}
|
||||
persona: {agent-id}
|
||||
customize: >-
|
||||
{Any specific behavioral customizations}
|
||||
|
||||
dependencies:
|
||||
tasks:
|
||||
- {list of task IDs}
|
||||
templates:
|
||||
- {list of template IDs}
|
||||
checklists:
|
||||
- {list of checklist IDs}
|
||||
data:
|
||||
- {list of data file IDs}
|
||||
utils:
|
||||
- template-format
|
||||
```
|
||||
|
||||
### 6. Create Any New Tasks
|
||||
|
||||
If new tasks were identified, create them in `/bmad-core/tasks/{task-name}.md`
|
||||
|
||||
### 7. Test and Validate
|
||||
|
||||
1. Run `npm run validate` to check configuration
|
||||
2. Run `npm run build:agent -a {agent-id}` to build the agent
|
||||
3. Review the generated output in `/dist/agents/{agent-id}.txt`
|
||||
|
||||
## Example Questions to Ask
|
||||
|
||||
1. "What will this agent be called? (ID like 'data-analyst')"
|
||||
2. "What's their character name? (like 'Elena')"
|
||||
3. "What's their professional title?"
|
||||
4. "Describe their main role in 2-3 sentences."
|
||||
5. "What personality traits should they have?"
|
||||
6. "How many years of experience do they have?"
|
||||
7. "What existing tasks should they know? (e.g., create-doc-from-template, execute-checklist)"
|
||||
8. "Do they need any specialized tasks that don't exist yet?"
|
||||
9. "Which document templates will they use?"
|
||||
10. "What motivates them in their work?"
|
||||
|
||||
## Important Notes
|
||||
|
||||
- Keep personas engaging but professional
|
||||
- Ensure all referenced tasks, templates, and checklists exist
|
||||
- Web agents can be more detailed than IDE agents (no size constraints)
|
||||
- Consider how this agent will collaborate with existing team members
|
||||
- Run validation after creating to catch any issues
|
||||
251
bmad-core/utils/create-expansion-pack.md
Normal file
251
bmad-core/utils/create-expansion-pack.md
Normal file
@@ -0,0 +1,251 @@
|
||||
# Create Expansion Pack Utility
|
||||
|
||||
This utility helps you create a comprehensive BMAD expansion pack that can include new agents, tasks, templates, and checklists for a specific domain.
|
||||
|
||||
## Understanding Expansion Packs
|
||||
|
||||
Expansion packs extend BMAD with domain-specific capabilities. They are self-contained packages that can be installed into any BMAD project.
|
||||
|
||||
## Process Overview
|
||||
|
||||
### Phase 1: Discovery and Planning
|
||||
|
||||
#### 1.1 Define the Domain
|
||||
|
||||
Ask the user:
|
||||
|
||||
- **Pack Name**: Short identifier (e.g., `healthcare`, `fintech`, `gamedev`)
|
||||
- **Display Name**: Full name (e.g., "Healthcare Compliance Pack")
|
||||
- **Description**: What domain or industry does this serve?
|
||||
- **Key Problems**: What specific challenges will this pack solve?
|
||||
- **Target Users**: Who will benefit from this expansion?
|
||||
|
||||
#### 1.2 Gather Examples
|
||||
|
||||
Request from the user:
|
||||
|
||||
- **Sample Documents**: Any existing documents in this domain
|
||||
- **Workflow Examples**: How work currently flows in this domain
|
||||
- **Compliance Needs**: Any regulatory or standards requirements
|
||||
- **Output Examples**: What final deliverables look like
|
||||
|
||||
### Phase 2: Component Design
|
||||
|
||||
#### 2.1 Identify Required Agents
|
||||
|
||||
For each proposed agent:
|
||||
|
||||
- **Role**: What specialist is needed?
|
||||
- **Expertise**: Domain-specific knowledge required
|
||||
- **Interactions**: How they work with existing BMAD agents
|
||||
- **Unique Value**: What can't existing agents handle?
|
||||
|
||||
#### 2.2 Design Specialized Tasks
|
||||
|
||||
For each task:
|
||||
|
||||
- **Purpose**: What specific action does it enable?
|
||||
- **Inputs**: What information is needed?
|
||||
- **Process**: Step-by-step instructions
|
||||
- **Outputs**: What gets produced?
|
||||
- **Agent Usage**: Which agents will use this task?
|
||||
|
||||
#### 2.3 Create Document Templates
|
||||
|
||||
For each template:
|
||||
|
||||
- **Document Type**: What kind of document?
|
||||
- **Structure**: Sections and organization
|
||||
- **Placeholders**: Variable content areas
|
||||
- **Instructions**: How to complete each section
|
||||
- **Standards**: Any format requirements
|
||||
|
||||
#### 2.4 Define Checklists
|
||||
|
||||
For each checklist:
|
||||
|
||||
- **Purpose**: What quality aspect does it verify?
|
||||
- **Scope**: When should it be used?
|
||||
- **Items**: Specific things to check
|
||||
- **Criteria**: Pass/fail conditions
|
||||
|
||||
### Phase 3: Implementation
|
||||
|
||||
#### 3.1 Create Directory Structure
|
||||
|
||||
```
|
||||
expansion-packs/
|
||||
└── {pack-name}/
|
||||
├── manifest.yml
|
||||
├── README.md
|
||||
├── agents/
|
||||
│ └── {agent-id}.yml
|
||||
├── personas/
|
||||
│ └── {agent-id}.md
|
||||
├── tasks/
|
||||
│ └── {task-name}.md
|
||||
├── templates/
|
||||
│ └── {template-name}.md
|
||||
├── checklists/
|
||||
│ └── {checklist-name}.md
|
||||
└── ide-agents/
|
||||
└── {agent-id}.ide.md
|
||||
```
|
||||
|
||||
#### 3.2 Create Manifest
|
||||
|
||||
Create `manifest.yml`:
|
||||
|
||||
```yaml
|
||||
name: {Pack Name}
|
||||
version: 1.0.0
|
||||
description: >-
|
||||
{Detailed description of the expansion pack}
|
||||
author: {Your name or organization}
|
||||
bmad_version: "4.0.0"
|
||||
|
||||
# Files to install
|
||||
files:
|
||||
- source: agents/{agent-id}.yml
|
||||
destination: agents/{agent-id}.yml
|
||||
- source: personas/{agent-id}.md
|
||||
destination: bmad-core/personas/{agent-id}.md
|
||||
- source: tasks/{task-name}.md
|
||||
destination: bmad-core/tasks/{task-name}.md
|
||||
# ... more files
|
||||
|
||||
# Optional: Update existing teams
|
||||
team_updates:
|
||||
- team: team-technical.yml
|
||||
add_agent: {new-agent-id}
|
||||
|
||||
# Post-install message
|
||||
post_install_message: >-
|
||||
{Pack Name} installed successfully!
|
||||
|
||||
New agents available: {list agents}
|
||||
New tasks available: {list tasks}
|
||||
|
||||
Run 'npm run build' to generate bundles.
|
||||
```
|
||||
|
||||
### Phase 4: Content Creation
|
||||
|
||||
#### 4.1 Agent Creation Checklist
|
||||
|
||||
For each new agent:
|
||||
|
||||
1. Create persona file with domain expertise
|
||||
2. Create agent configuration YAML
|
||||
3. Create IDE-optimized version (optional)
|
||||
4. List all task dependencies
|
||||
5. Define template usage
|
||||
6. Add to relevant teams
|
||||
|
||||
#### 4.2 Task Creation Guidelines
|
||||
|
||||
Each task should:
|
||||
|
||||
1. Have a clear, single purpose
|
||||
2. Include step-by-step instructions
|
||||
3. Provide examples when helpful
|
||||
4. Reference domain standards
|
||||
5. Be reusable across agents
|
||||
|
||||
#### 4.3 Template Best Practices
|
||||
|
||||
Templates should:
|
||||
|
||||
1. Include clear section headers
|
||||
2. Provide inline instructions
|
||||
3. Show example content
|
||||
4. Mark required vs optional sections
|
||||
5. Include domain-specific terminology
|
||||
|
||||
### Phase 5: Testing and Documentation
|
||||
|
||||
#### 5.1 Create README
|
||||
|
||||
Include:
|
||||
|
||||
- Overview of the pack's purpose
|
||||
- List of all components
|
||||
- Installation instructions
|
||||
- Usage examples
|
||||
- Integration notes
|
||||
|
||||
#### 5.2 Test Installation
|
||||
|
||||
1. Run `node tools/install-expansion-pack.js {pack-name}`
|
||||
2. Verify all files copied correctly
|
||||
3. Build agents to test configurations
|
||||
4. Run sample scenarios
|
||||
|
||||
## Example: Healthcare Expansion Pack
|
||||
|
||||
```
|
||||
healthcare/
|
||||
├── manifest.yml
|
||||
├── README.md
|
||||
├── agents/
|
||||
│ ├── clinical-analyst.yml
|
||||
│ └── compliance-officer.yml
|
||||
├── personas/
|
||||
│ ├── clinical-analyst.md
|
||||
│ └── compliance-officer.md
|
||||
├── tasks/
|
||||
│ ├── hipaa-assessment.md
|
||||
│ ├── clinical-protocol-review.md
|
||||
│ └── patient-data-analysis.md
|
||||
├── templates/
|
||||
│ ├── clinical-trial-protocol.md
|
||||
│ ├── hipaa-compliance-report.md
|
||||
│ └── patient-outcome-report.md
|
||||
└── checklists/
|
||||
├── hipaa-checklist.md
|
||||
└── clinical-data-quality.md
|
||||
```
|
||||
|
||||
## Interactive Questions Flow
|
||||
|
||||
### Initial Discovery
|
||||
1. "What domain or industry will this expansion pack serve?"
|
||||
2. "What are the main challenges or workflows in this domain?"
|
||||
3. "Do you have any example documents or outputs? (Please share)"
|
||||
4. "What specialized roles/experts exist in this domain?"
|
||||
|
||||
### Agent Planning
|
||||
5. "For agent '{name}', what is their specific expertise?"
|
||||
6. "What unique tasks would this agent perform?"
|
||||
7. "How would they interact with existing BMAD agents?"
|
||||
|
||||
### Task Design
|
||||
8. "Describe the '{task}' process step-by-step"
|
||||
9. "What information is needed to complete this task?"
|
||||
10. "What should the output look like?"
|
||||
|
||||
### Template Creation
|
||||
11. "What sections should the '{template}' document have?"
|
||||
12. "Are there any required formats or standards?"
|
||||
13. "Can you provide an example of a completed document?"
|
||||
|
||||
### Integration
|
||||
14. "Which existing teams should include these new agents?"
|
||||
15. "Are there any dependencies between components?"
|
||||
|
||||
## Important Considerations
|
||||
|
||||
- **Domain Expertise**: Ensure accuracy in specialized fields
|
||||
- **Compliance**: Include necessary regulatory requirements
|
||||
- **Compatibility**: Test with existing BMAD agents
|
||||
- **Documentation**: Provide clear usage instructions
|
||||
- **Examples**: Include real-world scenarios
|
||||
- **Maintenance**: Plan for updates as domain evolves
|
||||
|
||||
## Tips for Success
|
||||
|
||||
1. **Start Small**: Begin with 1-2 agents and expand
|
||||
2. **Get Examples**: Real documents make better templates
|
||||
3. **Test Thoroughly**: Run complete workflows
|
||||
4. **Document Well**: Others will need to understand the domain
|
||||
5. **Iterate**: Refine based on usage feedback
|
||||
139
bmad-core/utils/create-ide-agent.md
Normal file
139
bmad-core/utils/create-ide-agent.md
Normal file
@@ -0,0 +1,139 @@
|
||||
# Create IDE Agent Utility
|
||||
|
||||
This utility helps you create a new BMAD agent optimized for IDE environments (Cursor, Windsurf, etc.).
|
||||
|
||||
## Important Constraints
|
||||
|
||||
IDE agents must be **compact and efficient** (target: under 2000 characters) to work well as slash commands.
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Gather Essential Information
|
||||
|
||||
Ask the user for:
|
||||
|
||||
- **Agent ID**: Short, lowercase identifier (e.g., `api-expert`, `test-engineer`)
|
||||
- **Slash command**: The command to activate (e.g., `/api`, `/test`)
|
||||
- **Core purpose**: ONE primary function (IDE agents should be focused)
|
||||
|
||||
### 2. Define Minimal Personality
|
||||
|
||||
Keep it brief:
|
||||
|
||||
- **One-line personality**: A single trait or approach (e.g., "Direct and solution-focused")
|
||||
- **Expertise**: 2-3 core skills maximum
|
||||
- **Style**: How they communicate (brief! e.g., "Concise, code-first responses")
|
||||
|
||||
### 3. Identify Essential Capabilities
|
||||
|
||||
Be selective - IDE agents should be specialized:
|
||||
|
||||
- **1-2 primary tasks**: Only the most essential tasks
|
||||
- **1 template maximum**: Only if absolutely necessary
|
||||
- **Skip checklists**: Usually too large for IDE agents
|
||||
- **Reuse existing tasks**: Creating new tasks for IDE agents is rare
|
||||
|
||||
### 4. Create the Compact IDE Agent
|
||||
|
||||
Create `/bmad-core/ide-agents/{agent-id}.ide.md` with this structure:
|
||||
|
||||
```markdown
|
||||
# {Slash Command}
|
||||
|
||||
You are {Agent Name}, a {title/role}.
|
||||
|
||||
## Expertise
|
||||
- {Skill 1}
|
||||
- {Skill 2}
|
||||
- {Skill 3 if essential}
|
||||
|
||||
## Approach
|
||||
{One sentence about how you work}
|
||||
|
||||
## Focus
|
||||
{One sentence about what you prioritize}
|
||||
|
||||
---
|
||||
|
||||
When activated with {slash command}, immediately focus on {primary purpose}.
|
||||
```
|
||||
|
||||
### 5. Size Optimization Techniques
|
||||
|
||||
To keep agents small:
|
||||
|
||||
1. **Remove fluff**: No backstory, minimal personality
|
||||
2. **Use references**: Reference tasks rather than inline instructions
|
||||
3. **Be specific**: One job done well is better than many done poorly
|
||||
4. **Trim lists**: Maximum 3-5 bullet points for any list
|
||||
5. **Avoid examples**: Let referenced tasks handle examples
|
||||
|
||||
### 6. Test the Agent
|
||||
|
||||
1. Check character count: `wc -c {agent-file}`
|
||||
2. Ensure it's under 2000 characters
|
||||
3. Test in your IDE with the slash command
|
||||
4. Verify it can access referenced tasks
|
||||
|
||||
## Example Questions (Keep it Simple!)
|
||||
|
||||
1. "What's the slash command? (e.g., /api)"
|
||||
2. "What's the ONE thing this agent does best?"
|
||||
3. "In 5 words or less, describe their personality"
|
||||
4. "What 1-2 existing tasks do they need?"
|
||||
5. "Any special focus or constraints?"
|
||||
|
||||
## Example: Minimal API Expert
|
||||
|
||||
```markdown
|
||||
# /api
|
||||
|
||||
You are Alex, an API design expert.
|
||||
|
||||
## Expertise
|
||||
- RESTful API design
|
||||
- OpenAPI/Swagger specs
|
||||
- API security patterns
|
||||
|
||||
## Approach
|
||||
I provide immediate, practical API solutions with example code.
|
||||
|
||||
## Focus
|
||||
Clean, secure, well-documented APIs that follow industry standards.
|
||||
|
||||
---
|
||||
|
||||
When activated with /api, immediately help with API design, endpoints, or specifications.
|
||||
```
|
||||
|
||||
## Size Comparison
|
||||
|
||||
❌ **Too Large** (persona-style):
|
||||
|
||||
```markdown
|
||||
Alex is a seasoned API architect with over 10 years of experience
|
||||
building scalable systems. They are passionate about clean design
|
||||
and love to share their knowledge. Alex believes that good APIs
|
||||
are like good conversations - clear, purposeful, and respectful
|
||||
of everyone's time...
|
||||
```
|
||||
|
||||
(Too much personality, not focused)
|
||||
|
||||
✅ **Just Right** (IDE-style):
|
||||
|
||||
```markdown
|
||||
You are Alex, an API design expert.
|
||||
Focus: RESTful design, OpenAPI specs, security patterns.
|
||||
Style: Direct solutions with example code.
|
||||
```
|
||||
|
||||
(Minimal, focused, actionable)
|
||||
|
||||
## Important Notes
|
||||
|
||||
- **One agent, one job** - Don't try to do everything
|
||||
- **Reference, don't repeat** - Use task dependencies
|
||||
- **Test the size** - Must be under 2000 characters
|
||||
- **Skip the story** - No background needed for IDE agents
|
||||
- **Focus on action** - What they DO, not who they ARE
|
||||
174
bmad-core/utils/create-team.md
Normal file
174
bmad-core/utils/create-team.md
Normal file
@@ -0,0 +1,174 @@
|
||||
# Create Team Utility
|
||||
|
||||
This utility helps you create a new BMAD team bundle by combining existing agents.
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Define Team Basics
|
||||
|
||||
Ask the user for:
|
||||
|
||||
- **Team ID**: Filename without extension (e.g., `team-frontend`, `team-planning`)
|
||||
- **Team Name**: Display name (e.g., "Frontend Development Team")
|
||||
- **Team Description**: What this team is designed to accomplish
|
||||
- **Target Environment**: Usually "web" for team bundles
|
||||
|
||||
### 2. List Available Agents
|
||||
|
||||
Show all available agents from `/agents/`:
|
||||
|
||||
```
|
||||
Available agents:
|
||||
- analyst (Mary) - Project Analyst and Brainstorming Coach
|
||||
- architect (Fred) - System Architecture Expert
|
||||
- bmad (BMad) - BMAD Method Orchestrator
|
||||
- ui-architect (Jane) - UI/UX Architecture Expert
|
||||
- dev (James) - Full Stack Developer
|
||||
- devops (Alex) - Platform Engineer
|
||||
- fullstack-architect (Winston) - Holistic System Designer
|
||||
- pm (John) - Product Manager
|
||||
- po (Sarah) - Product Owner
|
||||
- qa (Quinn) - Test Architect
|
||||
- sm (Bob) - Scrum Master
|
||||
- ux-expert (Sally) - UX Design Expert
|
||||
```
|
||||
|
||||
### 3. Select Team Members
|
||||
|
||||
For each agent the user wants to include:
|
||||
|
||||
1. Confirm the agent ID
|
||||
2. Ask if they want to customize the persona for this team context
|
||||
3. Note any special team dynamics or relationships
|
||||
|
||||
### 4. Optimize Team Composition
|
||||
|
||||
Consider:
|
||||
|
||||
- **Role coverage**: Does the team have all necessary skills?
|
||||
- **Team size**: 3-7 agents is usually optimal
|
||||
- **Collaboration**: How will these agents work together?
|
||||
- **Use cases**: What problems will this team solve?
|
||||
|
||||
### 5. Create Team Configuration
|
||||
|
||||
Create `/agent-teams/{team-id}.yml`:
|
||||
|
||||
```yaml
|
||||
bundle:
|
||||
name: {Team Name}
|
||||
description: >-
|
||||
{Detailed description of the team's purpose and capabilities}
|
||||
target_environment: web
|
||||
|
||||
agents:
|
||||
- {agent-id-1}
|
||||
- {agent-id-2}
|
||||
- {agent-id-3}
|
||||
# ... more agents
|
||||
```
|
||||
|
||||
#### Using Wildcards
|
||||
|
||||
You can use `"*"` (quoted) to include all available agents:
|
||||
|
||||
```yaml
|
||||
agents:
|
||||
- bmad # Always include bmad first
|
||||
- "*" # Include all other agents
|
||||
```
|
||||
|
||||
Or mix specific agents with wildcard:
|
||||
|
||||
```yaml
|
||||
agents:
|
||||
- pm # Product Manager first
|
||||
- architect # Then Architect
|
||||
- "*" # Then all remaining agents
|
||||
```
|
||||
|
||||
### 6. Validate and Build
|
||||
|
||||
1. Run `npm run validate` to check configuration
|
||||
2. Run `npm run build` to generate the team bundle
|
||||
3. Review output in `/dist/teams/{team-filename}.txt`
|
||||
|
||||
## Example Teams
|
||||
|
||||
### Development Team
|
||||
```yaml
|
||||
bundle:
|
||||
name: Development Team Bundle
|
||||
description: >-
|
||||
Core development team for building features from story to deployment
|
||||
target_environment: web
|
||||
|
||||
agents:
|
||||
- sm # Sprint coordination
|
||||
- dev # Implementation
|
||||
- qa # Quality assurance
|
||||
- devops # Deployment
|
||||
```
|
||||
|
||||
### Planning Team
|
||||
```yaml
|
||||
bundle:
|
||||
name: Planning Team Bundle
|
||||
description: >-
|
||||
Strategic planning team for project inception and architecture
|
||||
target_environment: web
|
||||
|
||||
agents:
|
||||
- analyst # Requirements gathering
|
||||
- pm # Product planning
|
||||
- architect # System design
|
||||
- po # Validation
|
||||
```
|
||||
|
||||
### Full-Stack Team
|
||||
```yaml
|
||||
bundle:
|
||||
name: Full-Stack Team Bundle
|
||||
description: >-
|
||||
Complete team for full-stack application development
|
||||
target_environment: web
|
||||
|
||||
agents:
|
||||
- fullstack-architect # Holistic design
|
||||
- design-architect # Frontend architecture
|
||||
- dev # Implementation
|
||||
- qa # Testing
|
||||
- devops # Infrastructure
|
||||
```
|
||||
|
||||
## Questions to Ask
|
||||
|
||||
1. "What should this team be called? (e.g., 'team-mobile')"
|
||||
2. "What's the team's display name?"
|
||||
3. "Describe the team's primary purpose"
|
||||
4. "Which agents should be on this team? (list agent IDs)"
|
||||
5. "Any special dynamics between team members?"
|
||||
6. "What types of projects will this team handle?"
|
||||
|
||||
## Tips for Good Teams
|
||||
|
||||
- **Start small**: Begin with 3-4 core agents
|
||||
- **Clear purpose**: Each team should have a specific focus
|
||||
- **Complementary skills**: Agents should cover different aspects
|
||||
- **Avoid redundancy**: Don't include agents with overlapping roles
|
||||
- **Consider workflow**: Order agents by typical workflow sequence
|
||||
|
||||
## Common Team Patterns
|
||||
|
||||
1. **Scrum Team**: sm, dev, qa, po
|
||||
2. **Planning Team**: analyst, pm, architect, po
|
||||
3. **Design Team**: ux-expert, ui-architect, dev
|
||||
4. **Full Organization**: All agents (for complex projects)
|
||||
5. **Technical Team**: architect, dev, devops, qa
|
||||
|
||||
## Important Notes
|
||||
|
||||
- Teams reference existing agents - create agents first
|
||||
- Keep team descriptions clear and purpose-driven
|
||||
- Consider creating multiple focused teams rather than one large team
|
||||
- Test team dynamics by running sample scenarios
|
||||
@@ -15,6 +15,14 @@ When these commands are used, perform the listed action:
|
||||
- `/{agent} {query}`: Ever been talking to the PM and wanna ask the architect a question? Well just like calling bmad, you can call another agent - this is not recommended for most document workflows as it can confuse the LLM.
|
||||
- `/party-mode`: This enters group chat with all available agents. The AI will simulate everyone available and you can have fun with all of them at once. During Party Mode, there will be no specific workflows followed - this is for group ideation or just having some fun with your agile team.
|
||||
|
||||
## Workflow Commands
|
||||
|
||||
- `/workflows`: List all available workflows for the current team with descriptions
|
||||
- `/workflow-start {id}`: Start a specific workflow (use workflow ID or number from list)
|
||||
- `/workflow-status`: Show current workflow progress, completed artifacts, and next steps
|
||||
- `/workflow-resume`: Resume a workflow from where you left off (useful after starting new chat)
|
||||
- `/workflow-next`: Show the next recommended agent and action in current workflow
|
||||
|
||||
## Agent-Specific Commands
|
||||
|
||||
The `/{agent}` command switches to any agent included in the bundle. The command accepts either:
|
||||
|
||||
178
bmad-core/utils/workflow-management.md
Normal file
178
bmad-core/utils/workflow-management.md
Normal file
@@ -0,0 +1,178 @@
|
||||
# Workflow Management
|
||||
|
||||
This utility enables the BMAD orchestrator to manage and execute team workflows.
|
||||
|
||||
## Workflow Commands
|
||||
|
||||
### /workflows
|
||||
Lists all available workflows for the current team.
|
||||
|
||||
Example response:
|
||||
```
|
||||
Available workflows:
|
||||
1. greenfield-mvp - Complete workflow for building a new MVP from scratch
|
||||
2. fullstack-app - Comprehensive workflow for production-ready applications
|
||||
3. api-only - API-first development workflow
|
||||
4. brownfield-enhancement - Enhance existing applications
|
||||
5. frontend-only - Frontend application development
|
||||
|
||||
Use /workflow-start {number or id} to begin a workflow.
|
||||
```
|
||||
|
||||
### /workflow-start {workflow-id}
|
||||
Starts a specific workflow and transitions to the first agent.
|
||||
|
||||
Example: `/workflow-start greenfield-mvp`
|
||||
|
||||
### /workflow-status
|
||||
Shows current workflow progress, completed artifacts, and next steps.
|
||||
|
||||
Example response:
|
||||
```
|
||||
Current Workflow: Greenfield MVP Development
|
||||
Stage: Product Planning (2 of 6)
|
||||
Completed:
|
||||
✓ Discovery & Requirements
|
||||
- project-brief (completed by Mary)
|
||||
|
||||
In Progress:
|
||||
⚡ Product Planning
|
||||
- Create PRD (John) - awaiting input
|
||||
|
||||
Next: Technical Architecture
|
||||
```
|
||||
|
||||
### /workflow-resume
|
||||
Resumes a workflow from where it left off, useful when starting a new chat.
|
||||
|
||||
User can provide completed artifacts:
|
||||
```
|
||||
User: /workflow-resume greenfield-mvp
|
||||
I have completed: project-brief, PRD
|
||||
BMad: I see you've completed Discovery and part of Product Planning.
|
||||
Based on the greenfield-mvp workflow, the next step is:
|
||||
- UX Strategy with Sally (ux-expert)
|
||||
|
||||
Would you like me to load Sally to continue?
|
||||
```
|
||||
|
||||
### /workflow-next
|
||||
Shows the next recommended agent and action in the current workflow.
|
||||
|
||||
## Workflow Execution Flow
|
||||
|
||||
### 1. Starting a Workflow
|
||||
|
||||
When a workflow is started:
|
||||
1. Load the workflow definition
|
||||
2. Identify the first stage and step
|
||||
3. Transition to the required agent
|
||||
4. Provide context about expected inputs/outputs
|
||||
5. Guide artifact creation
|
||||
|
||||
### 2. Stage Transitions
|
||||
|
||||
After each artifact is completed:
|
||||
1. Mark the step as complete
|
||||
2. Check transition conditions
|
||||
3. If stage is complete, move to next stage
|
||||
4. Load the appropriate agent
|
||||
5. Pass relevant artifacts as context
|
||||
|
||||
### 3. Artifact Tracking
|
||||
|
||||
Track all created artifacts:
|
||||
```yaml
|
||||
workflow_state:
|
||||
current_workflow: greenfield-mvp
|
||||
current_stage: planning
|
||||
current_step: 2
|
||||
artifacts:
|
||||
project-brief:
|
||||
status: completed
|
||||
created_by: analyst
|
||||
timestamp: 2024-01-15T10:30:00Z
|
||||
prd:
|
||||
status: in-progress
|
||||
created_by: pm
|
||||
started: 2024-01-15T11:00:00Z
|
||||
```
|
||||
|
||||
### 4. Workflow Interruption Handling
|
||||
|
||||
When user returns after interruption:
|
||||
1. Ask if continuing previous workflow
|
||||
2. Request any completed artifacts
|
||||
3. Analyze provided artifacts
|
||||
4. Determine workflow position
|
||||
5. Suggest next appropriate step
|
||||
|
||||
Example:
|
||||
```
|
||||
User: I'm working on a new app. Here's my PRD and architecture doc.
|
||||
BMad: I see you have a PRD and architecture document. Based on these artifacts,
|
||||
it looks like you're following the greenfield-mvp workflow and have completed
|
||||
stages 1-3. The next recommended step would be:
|
||||
|
||||
Stage 4: Validation & Refinement
|
||||
- Load Sarah (Product Owner) to validate all artifacts
|
||||
|
||||
Would you like to continue with this workflow?
|
||||
```
|
||||
|
||||
## Workflow Context Passing
|
||||
|
||||
When transitioning between agents, pass:
|
||||
1. Previous artifacts created
|
||||
2. Current workflow stage
|
||||
3. Expected outputs
|
||||
4. Any decisions or constraints identified
|
||||
|
||||
Example transition:
|
||||
```
|
||||
BMad: Great! John has completed the PRD. According to the greenfield-mvp workflow,
|
||||
the next step is UX Strategy with Sally.
|
||||
|
||||
/ux-expert
|
||||
|
||||
Sally: I see we're in the Product Planning stage of the greenfield-mvp workflow.
|
||||
I have access to:
|
||||
- Project Brief from Mary
|
||||
- PRD from John
|
||||
|
||||
Let's create the UX strategy and UI specifications. First, let me review
|
||||
the PRD to understand the features we're designing for...
|
||||
```
|
||||
|
||||
## Multi-Path Workflows
|
||||
|
||||
Some workflows may have multiple paths:
|
||||
```yaml
|
||||
conditional_paths:
|
||||
- condition: "project_type == 'mobile'"
|
||||
next_stage: mobile-specific-design
|
||||
- condition: "project_type == 'web'"
|
||||
next_stage: web-architecture
|
||||
- default: fullstack-architecture
|
||||
```
|
||||
|
||||
Handle these by asking clarifying questions when needed.
|
||||
|
||||
## Workflow Best Practices
|
||||
|
||||
1. **Always show progress** - Users should know where they are
|
||||
2. **Explain transitions** - Why moving to next agent
|
||||
3. **Preserve context** - Pass relevant information forward
|
||||
4. **Allow flexibility** - Users can skip or modify steps
|
||||
5. **Track everything** - Maintain complete workflow state
|
||||
|
||||
## Integration with Agents
|
||||
|
||||
Each agent should be workflow-aware:
|
||||
- Know which workflow is active
|
||||
- Understand their role in the workflow
|
||||
- Access previous artifacts
|
||||
- Know expected outputs
|
||||
- Guide toward workflow goals
|
||||
|
||||
This creates a seamless experience where the entire team works together toward the workflow's objectives.
|
||||
@@ -74,7 +74,7 @@ dependencies:
|
||||
- pm-checklist
|
||||
```
|
||||
|
||||
Team bundles are defined in `team-*.yml` files:
|
||||
Team bundles are defined in the `/agent-teams/` directory as `team-*.yml` files:
|
||||
|
||||
```yaml
|
||||
bundle:
|
||||
@@ -98,7 +98,8 @@ The BMAD v4 system uses this structure:
|
||||
|
||||
```
|
||||
BMAD-METHOD/
|
||||
├── agents/ # Agent YAML configurations
|
||||
├── agents/ # Individual agent YAML configurations
|
||||
├── agent-teams/ # Team bundle YAML configurations
|
||||
├── bmad-core/ # Core resources
|
||||
│ ├── personas/ # Agent personality definitions
|
||||
│ ├── tasks/ # Reusable task instructions
|
||||
|
||||
@@ -39,7 +39,7 @@ Want to modify agents or create custom bundles?
|
||||
|
||||
1. **Copy bmad-core** to your project
|
||||
2. **Install dependencies**: `npm install`
|
||||
3. **Customize** agents in `/agents/` or resources in `/bmad-core/`
|
||||
3. **Customize** agents in `/agents/`, team bundles in `/agent-teams/`, or resources in `/bmad-core/`
|
||||
4. **Build**: `npm run build`
|
||||
|
||||
## When Do You Need npm install?
|
||||
|
||||
@@ -13,6 +13,7 @@ class WebBuilder {
|
||||
constructor(rootPath = process.cwd()) {
|
||||
this.rootPath = rootPath;
|
||||
this.agentsPath = path.join(rootPath, 'agents');
|
||||
this.teamsPath = path.join(rootPath, 'agent-teams');
|
||||
this.outputPath = path.join(rootPath, 'dist');
|
||||
this.sampleUpdatePath = path.join(rootPath, 'web-bundles');
|
||||
this.resolver = new DependencyResolver(rootPath);
|
||||
@@ -114,6 +115,49 @@ class WebBuilder {
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Expand agent wildcards in the list
|
||||
* If the list contains '*', it will be replaced with all available agents
|
||||
*/
|
||||
expandAgentWildcards(agentIds) {
|
||||
// Check if wildcard is present
|
||||
const wildcardIndex = agentIds.indexOf('*');
|
||||
if (wildcardIndex === -1) {
|
||||
return agentIds;
|
||||
}
|
||||
|
||||
// Get all available agents
|
||||
const allAgents = this.resolver.getAvailableAgents()
|
||||
.filter(agentId => {
|
||||
// Exclude team bundles
|
||||
if (agentId.startsWith('team-')) {
|
||||
return false;
|
||||
}
|
||||
|
||||
try {
|
||||
const config = this.resolver.loadAgentConfig(agentId);
|
||||
// Include all agents that don't explicitly disable web
|
||||
return config.environments?.web?.available !== false;
|
||||
} catch {
|
||||
return false;
|
||||
}
|
||||
});
|
||||
|
||||
// Create expanded list
|
||||
const expandedList = [...agentIds];
|
||||
|
||||
// Replace wildcard with all agents not already in the list
|
||||
const existingAgents = new Set(agentIds.filter(id => id !== '*'));
|
||||
const agentsToAdd = allAgents.filter(agent => !existingAgents.has(agent));
|
||||
|
||||
// Replace the wildcard with the missing agents
|
||||
expandedList.splice(wildcardIndex, 1, ...agentsToAdd);
|
||||
|
||||
console.log(` Expanded wildcard to include: ${agentsToAdd.join(', ')}`);
|
||||
|
||||
return expandedList;
|
||||
}
|
||||
|
||||
/**
|
||||
* Build a specific bundle
|
||||
*/
|
||||
@@ -124,7 +168,10 @@ class WebBuilder {
|
||||
console.log(`${emoji} Building ${bundleType}: ${bundleConfig.name}`);
|
||||
|
||||
// Ensure agents is an array of strings
|
||||
const agentIds = Array.isArray(bundleConfig.agents) ? bundleConfig.agents : [];
|
||||
let agentIds = Array.isArray(bundleConfig.agents) ? bundleConfig.agents : [];
|
||||
|
||||
// Expand wildcards
|
||||
agentIds = this.expandAgentWildcards(agentIds);
|
||||
|
||||
// Resolve dependencies
|
||||
const agentDependencies = this.resolver.resolveBundleDependencies(
|
||||
@@ -360,8 +407,33 @@ class WebBuilder {
|
||||
*/
|
||||
loadBundleConfigs() {
|
||||
const configs = [];
|
||||
|
||||
// Load team configurations from agent-teams directory
|
||||
const teamFiles = this.findAgentFiles(this.teamsPath);
|
||||
teamFiles.forEach(file => {
|
||||
try {
|
||||
const content = fs.readFileSync(file, 'utf8');
|
||||
const config = yaml.load(content);
|
||||
|
||||
// Check if this has bundle config
|
||||
if (config.bundle) {
|
||||
// Only include web bundles (exclude IDE-specific bundles)
|
||||
if (config.bundle.target_environment === 'web') {
|
||||
// Merge agents list from root level into bundle config
|
||||
const bundleConfig = { ...config.bundle };
|
||||
if (config.agents && !bundleConfig.agents) {
|
||||
bundleConfig.agents = config.agents;
|
||||
}
|
||||
configs.push(bundleConfig);
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
console.warn(`Warning: Failed to load config ${file}:`, error.message);
|
||||
}
|
||||
});
|
||||
|
||||
// For backward compatibility, also check agents directory for team-*.yml files
|
||||
const agentFiles = this.findAgentFiles(this.agentsPath);
|
||||
|
||||
agentFiles.forEach(file => {
|
||||
try {
|
||||
const content = fs.readFileSync(file, 'utf8');
|
||||
|
||||
@@ -106,8 +106,8 @@ program
|
||||
agents.forEach(agentId => {
|
||||
try {
|
||||
const config = resolver.loadAgentConfig(agentId);
|
||||
const webCompatible = config.environments.web?.available !== false;
|
||||
const ideOnly = config.environments.ide?.ide_only === true;
|
||||
const webCompatible = config.environments?.web?.available !== false;
|
||||
const ideOnly = config.environments?.ide?.ide_only === true;
|
||||
|
||||
console.log(` ${agentId}: ${config.name}`);
|
||||
console.log(` ${config.description}`);
|
||||
|
||||
@@ -109,7 +109,11 @@ async function installExpansionPack(packName) {
|
||||
log('\nUpdating team configurations...', 'yellow');
|
||||
|
||||
for (const update of manifest.team_updates) {
|
||||
const teamPath = path.join(projectRoot, 'agents', update.team);
|
||||
// Try new location first (agent-teams), then fallback to old location (agents)
|
||||
let teamPath = path.join(projectRoot, 'agent-teams', update.team);
|
||||
if (!fs.existsSync(teamPath)) {
|
||||
teamPath = path.join(projectRoot, 'agents', update.team);
|
||||
}
|
||||
|
||||
if (fs.existsSync(teamPath)) {
|
||||
try {
|
||||
|
||||
@@ -1,902 +0,0 @@
|
||||
# Jane
|
||||
|
||||
For UI/UX specifications, front-end architecture, and UI 1-shot prompting.
|
||||
|
||||
==================== START: personas#design-architect ====================
|
||||
# Role: Design Architect - UI/UX & Frontend Strategy Expert
|
||||
|
||||
## Persona
|
||||
|
||||
- **Role:** Expert Design Architect - UI/UX & Frontend Strategy Lead
|
||||
- **Style:** User-centric, strategic, and technically adept; combines empathetic design thinking with pragmatic frontend architecture. Visual thinker, pattern-oriented, precise, and communicative. Focuses on translating user needs and business goals into intuitive, feasible, and high-quality digital experiences and robust frontend solutions.
|
||||
- **Core Strength:** Excels at bridging the gap between product vision and technical frontend implementation, ensuring both exceptional user experience and sound architectural practices. Skilled in UI/UX specification, frontend architecture design, and optimizing prompts for AI-driven frontend development.
|
||||
|
||||
## Core Design Architect Principles (Always Active)
|
||||
|
||||
- **User-Centricity Above All:** Always champion the user's needs. Ensure usability, accessibility, and a delightful, intuitive experience are at the forefront of all design and architectural decisions.
|
||||
- **Holistic Design & System Thinking:** Approach UI/UX and frontend architecture as deeply interconnected. Ensure visual design, interaction patterns, information architecture, and frontend technical choices cohesively support the overall product vision, user journey, and main system architecture.
|
||||
- **Empathy & Deep Inquiry:** Actively seek to understand user pain points, motivations, and context. Ask clarifying questions to ensure a shared understanding before proposing or finalizing design solutions.
|
||||
- **Strategic & Pragmatic Solutions:** Balance innovative and aesthetically pleasing design with technical feasibility, project constraints (derived from PRD, main architecture document), performance considerations, and established frontend best practices.
|
||||
- **Pattern-Oriented & Consistent Design:** Leverage established UI/UX design patterns and frontend architectural patterns to ensure consistency, predictability, efficiency, and maintainability. Promote and adhere to design systems and component libraries where applicable.
|
||||
- **Clarity, Precision & Actionability in Specifications:** Produce clear, unambiguous, and detailed UI/UX specifications and frontend architecture documentation. Ensure these artifacts are directly usable and serve as reliable guides for development teams (especially AI developer agents).
|
||||
- **Iterative & Collaborative Approach:** Present designs and architectural ideas as drafts open to user feedback and discussion. Work collaboratively, incorporating input to achieve optimal outcomes.
|
||||
- **Accessibility & Inclusivity by Design:** Proactively integrate accessibility standards (e.g., WCAG) and inclusive design principles into every stage of the UI/UX and frontend architecture process.
|
||||
- **Performance-Aware Frontend:** Design and architect frontend solutions with performance (e.g., load times, responsiveness, resource efficiency) as a key consideration from the outset.
|
||||
- **Future-Awareness & Maintainability:** Create frontend systems and UI specifications that are scalable, maintainable, and adaptable to potential future user needs, feature enhancements, and evolving technologies.
|
||||
|
||||
## Critical Start Up Operating Instructions
|
||||
|
||||
- Let the User Know what Tasks you can perform and get the user's selection.
|
||||
- Execute the Full Tasks as Selected. If no task selected you will just stay in this persona and help the user as needed, guided by the Core Design Architect Principles.
|
||||
|
||||
==================== END: personas#design-architect ====================
|
||||
|
||||
==================== START: tasks#create-doc-from-template ====================
|
||||
# Create Document from Template Task
|
||||
|
||||
## Purpose
|
||||
|
||||
- Generate documents from any specified template following embedded instructions from the perspective of the selected agent persona
|
||||
|
||||
## Instructions
|
||||
|
||||
### 1. Identify Template and Context
|
||||
|
||||
- Determine which template to use (user-provided or list available for selection to user)
|
||||
|
||||
- Agent-specific templates are listed in the agent's dependencies under `templates`. For each template listed, consider it a document the agent can create. So if an agent has:
|
||||
|
||||
@{example}
|
||||
dependencies:
|
||||
templates: - prd-tmpl - architecture-tmpl
|
||||
@{/example}
|
||||
|
||||
You would offer to create "PRD" and "Architecture" documents when the user asks what you can help with.
|
||||
|
||||
- Gather all relevant inputs, or ask for them, or else rely on user providing necessary details to complete the document
|
||||
- Understand the document purpose and target audience
|
||||
|
||||
### 2. Determine Interaction Mode
|
||||
|
||||
Confirm with the user their preferred interaction style:
|
||||
|
||||
- **Incremental:** Work through chunks of the document.
|
||||
- **YOLO Mode:** Draft complete document making reasonable assumptions in one shot. (Can be entered also after starting incremental by just typing /yolo)
|
||||
|
||||
### 3. Execute Template
|
||||
|
||||
- Load specified template from `templates#*` or the /templates directory
|
||||
- Follow ALL embedded LLM instructions within the template
|
||||
- Process template markup according to `utils#template-format` conventions
|
||||
|
||||
### 4. Template Processing Rules
|
||||
|
||||
**CRITICAL: Never display template markup, LLM instructions, or examples to users**
|
||||
|
||||
- Replace all {{placeholders}} with actual content
|
||||
- Execute all [[LLM: instructions]] internally
|
||||
- Process <<REPEAT>> sections as needed
|
||||
- Evaluate ^^CONDITION^^ blocks and include only if applicable
|
||||
- Use @{examples} for guidance but never output them
|
||||
|
||||
### 5. Content Generation
|
||||
|
||||
- **Incremental Mode**: Present each major section for review before proceeding
|
||||
- **YOLO Mode**: Generate all sections, then review complete document with user
|
||||
- Apply any elicitation protocols specified in template
|
||||
- Incorporate user feedback and iterate as needed
|
||||
|
||||
### 6. Validation
|
||||
|
||||
If template specifies a checklist:
|
||||
|
||||
- Run the appropriate checklist against completed document
|
||||
- Document completion status for each item
|
||||
- Address any deficiencies found
|
||||
- Present validation summary to user
|
||||
|
||||
### 7. Final Presentation
|
||||
|
||||
- Present clean, formatted content only
|
||||
- Ensure all sections are complete
|
||||
- DO NOT truncate or summarize content
|
||||
- Begin directly with document content (no preamble)
|
||||
- Include any handoff prompts specified in template
|
||||
|
||||
## Important Notes
|
||||
|
||||
- Template markup is for AI processing only - never expose to users
|
||||
|
||||
==================== END: tasks#create-doc-from-template ====================
|
||||
|
||||
==================== START: tasks#generate-ai-frontend-prompt ====================
|
||||
# Create AI Frontend Prompt Task
|
||||
|
||||
## Purpose
|
||||
|
||||
To generate a masterful, comprehensive, and optimized prompt that can be used with AI-driven frontend development tools (e.g., Lovable, Vercel v0, or similar) to scaffold or generate significant portions of the frontend application.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Completed UI/UX Specification (`front-end-spec-tmpl`)
|
||||
- Completed Frontend Architecture Document (`front-end-architecture`)
|
||||
- Main System Architecture Document (`architecture` - for API contracts and tech stack)
|
||||
- Primary Design Files (Figma, Sketch, etc. - for visual context if the tool can accept it or if descriptions are needed)
|
||||
|
||||
## Key Activities & Instructions
|
||||
|
||||
1. **Confirm Target AI Generation Platform:**
|
||||
|
||||
- Ask the user to specify which AI frontend generation tool/platform they intend to use (e.g., "Lovable.ai", "Vercel v0", "GPT-4 with direct code generation instructions", etc.).
|
||||
- Explain that prompt optimization might differ slightly based on the platform's capabilities and preferred input format.
|
||||
|
||||
2. **Synthesize Inputs into a Structured Prompt:**
|
||||
|
||||
- **Overall Project Context:**
|
||||
- Briefly state the project's purpose (from brief/PRD).
|
||||
- Specify the chosen frontend framework, core libraries, and UI component library (from `front-end-architecture` and main `architecture`).
|
||||
- Mention the styling approach (e.g., Tailwind CSS, CSS Modules).
|
||||
- **Design System & Visuals:**
|
||||
- Reference the primary design files (e.g., Figma link).
|
||||
- If the tool doesn't directly ingest design files, describe the overall visual style, color palette, typography, and key branding elements (from `front-end-spec-tmpl`).
|
||||
- List any global UI components or design tokens that should be defined or adhered to.
|
||||
- **Application Structure & Routing:**
|
||||
- Describe the main pages/views and their routes (from `front-end-architecture` - Routing Strategy).
|
||||
- Outline the navigation structure (from `front-end-spec-tmpl`).
|
||||
- **Key User Flows & Page-Level Interactions:**
|
||||
- For a few critical user flows (from `front-end-spec-tmpl`):
|
||||
- Describe the sequence of user actions and expected UI changes on each relevant page.
|
||||
- Specify API calls to be made (referencing API endpoints from the main `architecture`) and how data should be displayed or used.
|
||||
- **Component Generation Instructions (Iterative or Key Components):**
|
||||
- Based on the chosen AI tool's capabilities, decide on a strategy:
|
||||
- **Option 1 (Scaffolding):** Prompt for the generation of main page structures, layouts, and placeholders for components.
|
||||
- **Option 2 (Key Component Generation):** Select a few critical or complex components from the `front-end-architecture` (Component Breakdown) and provide detailed specifications for them (props, state, basic behavior, key UI elements).
|
||||
- **Option 3 (Holistic, if tool supports):** Attempt to describe the entire application structure and key components more broadly.
|
||||
- <important_note>Advise the user that generating an entire complex application perfectly in one go is rare. Iterative prompting or focusing on sections/key components is often more effective.</important_note>
|
||||
- **State Management (High-Level Pointers):**
|
||||
- Mention the chosen state management solution (e.g., "Use Redux Toolkit").
|
||||
- For key pieces of data, indicate if they should be managed in global state.
|
||||
- **API Integration Points:**
|
||||
- For pages/components that fetch or submit data, clearly state the relevant API endpoints (from `architecture`) and the expected data shapes (can reference schemas in `data-models` or `api-reference` sections of the architecture doc).
|
||||
- **Critical "Don'ts" or Constraints:**
|
||||
- e.g., "Do not use deprecated libraries." "Ensure all forms have basic client-side validation."
|
||||
- **Platform-Specific Optimizations:**
|
||||
- If the chosen AI tool has known best practices for prompting (e.g., specific keywords, structure, level of detail), incorporate them. (This might require the agent to have some general knowledge or to ask the user if they know any such specific prompt modifiers for their chosen tool).
|
||||
|
||||
3. **Present and Refine the Master Prompt:**
|
||||
- Output the generated prompt in a clear, copy-pasteable format (e.g., a large code block).
|
||||
- Explain the structure of the prompt and why certain information was included.
|
||||
- Work with the user to refine the prompt based on their knowledge of the target AI tool and any specific nuances they want to emphasize.
|
||||
- <important_note>Remind the user that the generated code from the AI tool will likely require review, testing, and further refinement by developers.</important_note>
|
||||
|
||||
==================== END: tasks#generate-ai-frontend-prompt ====================
|
||||
|
||||
==================== START: templates#front-end-architecture-tmpl ====================
|
||||
# {{Project Name}} Frontend Architecture Document
|
||||
|
||||
[[LLM: Review provided documents including PRD, UX-UI Specification, and main Architecture Document. Focus on extracting technical implementation details needed for AI frontend tools and developer agents. Ask the user for any of these documents if you are unable to locate and were not provided.]]
|
||||
|
||||
## Template and Framework Selection
|
||||
|
||||
[[LLM: Before proceeding with frontend architecture design, check if the project is using a frontend starter template or existing codebase:
|
||||
|
||||
1. Review the PRD, main architecture document, and brainstorming brief for mentions of:
|
||||
|
||||
- Frontend starter templates (e.g., Create React App, Next.js, Vite, Vue CLI, Angular CLI, etc.)
|
||||
- UI kit or component library starters
|
||||
- Existing frontend projects being used as a foundation
|
||||
- Admin dashboard templates or other specialized starters
|
||||
- Design system implementations
|
||||
|
||||
2. If a frontend starter template or existing project is mentioned:
|
||||
|
||||
- Ask the user to provide access via one of these methods:
|
||||
- Link to the starter template documentation
|
||||
- Upload/attach the project files (for small projects)
|
||||
- Share a link to the project repository
|
||||
- Analyze the starter/existing project to understand:
|
||||
- Pre-installed dependencies and versions
|
||||
- Folder structure and file organization
|
||||
- Built-in components and utilities
|
||||
- Styling approach (CSS modules, styled-components, Tailwind, etc.)
|
||||
- State management setup (if any)
|
||||
- Routing configuration
|
||||
- Testing setup and patterns
|
||||
- Build and development scripts
|
||||
- Use this analysis to ensure your frontend architecture aligns with the starter's patterns
|
||||
|
||||
3. If no frontend starter is mentioned but this is a new UI, ensure we know what the ui language and framework is:
|
||||
|
||||
- Based on the framework choice, suggest appropriate starters:
|
||||
- React: Create React App, Next.js, Vite + React
|
||||
- Vue: Vue CLI, Nuxt.js, Vite + Vue
|
||||
- Angular: Angular CLI
|
||||
- Or suggest popular UI templates if applicable
|
||||
- Explain benefits specific to frontend development
|
||||
|
||||
4. If the user confirms no starter template will be used:
|
||||
- Note that all tooling, bundling, and configuration will need manual setup
|
||||
- Proceed with frontend architecture from scratch
|
||||
|
||||
Document the starter template decision and any constraints it imposes before proceeding.]]
|
||||
|
||||
## 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]]
|
||||
|
||||
### Technology Stack Table
|
||||
|
||||
| Category | Technology | Version | Purpose | Rationale |
|
||||
| :-------------------- | :------------------- | :---------- | :---------- | :------------- |
|
||||
| **Framework** | {{framework}} | {{version}} | {{purpose}} | {{why_chosen}} |
|
||||
| **UI Library** | {{ui_library}} | {{version}} | {{purpose}} | {{why_chosen}} |
|
||||
| **State Management** | {{state_management}} | {{version}} | {{purpose}} | {{why_chosen}} |
|
||||
| **Routing** | {{routing_library}} | {{version}} | {{purpose}} | {{why_chosen}} |
|
||||
| **Build Tool** | {{build_tool}} | {{version}} | {{purpose}} | {{why_chosen}} |
|
||||
| **Styling** | {{styling_solution}} | {{version}} | {{purpose}} | {{why_chosen}} |
|
||||
| **Testing** | {{test_framework}} | {{version}} | {{purpose}} | {{why_chosen}} |
|
||||
| **Component Library** | {{component_lib}} | {{version}} | {{purpose}} | {{why_chosen}} |
|
||||
| **Form Handling** | {{form_library}} | {{version}} | {{purpose}} | {{why_chosen}} |
|
||||
| **Animation** | {{animation_lib}} | {{version}} | {{purpose}} | {{why_chosen}} |
|
||||
| **Dev Tools** | {{dev_tools}} | {{version}} | {{purpose}} | {{why_chosen}} |
|
||||
|
||||
[[LLM: Fill in appropriate technology choices based on the selected framework and project requirements.]]
|
||||
|
||||
## Project Structure
|
||||
|
||||
[[LLM: Define exact directory structure for AI tools based on the chosen framework. Be specific about where each type of file goes. Generate a structure that follows the framework's best practices and conventions. After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
## Component Standards
|
||||
|
||||
[[LLM: Define exact patterns for component creation based on the chosen framework. After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Component Template
|
||||
|
||||
[[LLM: Generate a minimal but complete component template following the framework's best practices. Include TypeScript types, proper imports, and basic structure.]]
|
||||
|
||||
### Naming Conventions
|
||||
|
||||
[[LLM: Provide naming conventions specific to the chosen framework for components, files, services, state management, and other architectural elements.]]
|
||||
|
||||
## State Management
|
||||
|
||||
[[LLM: Define state management patterns based on the chosen framework. After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Store Structure
|
||||
|
||||
[[LLM: Generate the state management directory structure appropriate for the chosen framework and selected state management solution.]]
|
||||
|
||||
### State Management Template
|
||||
|
||||
[[LLM: Provide a basic state management template/example following the framework's recommended patterns. Include TypeScript types and common operations like setting, updating, and clearing state.]]
|
||||
|
||||
## API Integration
|
||||
|
||||
[[LLM: Define API service patterns based on the chosen framework. After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Service Template
|
||||
|
||||
[[LLM: Provide an API service template that follows the framework's conventions. Include proper TypeScript types, error handling, and async patterns.]]
|
||||
|
||||
### API Client Configuration
|
||||
|
||||
[[LLM: Show how to configure the HTTP client for the chosen framework, including authentication interceptors/middleware and error handling.]]
|
||||
|
||||
## Routing
|
||||
|
||||
[[LLM: Define routing structure and patterns based on the chosen framework. After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Route Configuration
|
||||
|
||||
[[LLM: Provide routing configuration appropriate for the chosen framework. Include protected route patterns, lazy loading where applicable, and authentication guards/middleware.]]
|
||||
|
||||
## Styling Guidelines
|
||||
|
||||
[[LLM: Define styling approach based on the chosen framework. After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Styling Approach
|
||||
|
||||
[[LLM: Describe the styling methodology appropriate for the chosen framework (CSS Modules, Styled Components, Tailwind, etc.) and provide basic patterns.]]
|
||||
|
||||
### Global Theme Variables
|
||||
|
||||
[[LLM: Provide a CSS custom properties (CSS variables) theme system that works across all frameworks. Include colors, spacing, typography, shadows, and dark mode support.]]
|
||||
|
||||
## Testing Requirements
|
||||
|
||||
[[LLM: Define minimal testing requirements based on the chosen framework. After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Component Test Template
|
||||
|
||||
[[LLM: Provide a basic component test template using the framework's recommended testing library. Include examples of rendering tests, user interaction tests, and mocking.]]
|
||||
|
||||
### Testing Best Practices
|
||||
|
||||
1. **Unit Tests**: Test individual components in isolation
|
||||
2. **Integration Tests**: Test component interactions
|
||||
3. **E2E Tests**: Test critical user flows (using Cypress/Playwright)
|
||||
4. **Coverage Goals**: Aim for 80% code coverage
|
||||
5. **Test Structure**: Arrange-Act-Assert pattern
|
||||
6. **Mock External Dependencies**: API calls, routing, state management
|
||||
|
||||
## Environment Configuration
|
||||
|
||||
[[LLM: List required environment variables based on the chosen framework. Show the appropriate format and naming conventions for the framework. After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
## Frontend Developer Standards
|
||||
|
||||
### Critical Coding Rules
|
||||
|
||||
[[LLM: List essential rules that prevent common AI mistakes, including both universal rules and framework-specific ones. After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Quick Reference
|
||||
|
||||
[[LLM: Create a framework-specific cheat sheet with:
|
||||
|
||||
- Common commands (dev server, build, test)
|
||||
- Key import patterns
|
||||
- File naming conventions
|
||||
- Project-specific patterns and utilities]]
|
||||
|
||||
==================== END: templates#front-end-architecture-tmpl ====================
|
||||
|
||||
==================== START: templates#front-end-spec-tmpl ====================
|
||||
# {{Project Name}} UI/UX Specification
|
||||
|
||||
[[LLM: Review provided documents including Project Brief, PRD, and any user research to gather context. Focus on understanding user needs, pain points, and desired outcomes before beginning the specification.]]
|
||||
|
||||
## Introduction
|
||||
|
||||
[[LLM: Establish the document's purpose and scope. Keep the content below but ensure project name is properly substituted.]]
|
||||
|
||||
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
|
||||
|
||||
[[LLM: Work with the user to establish and document the following. If not already defined, facilitate a discussion to determine:
|
||||
|
||||
1. Target User Personas - elicit details or confirm existing ones from PRD
|
||||
2. Key Usability Goals - understand what success looks like for users
|
||||
3. Core Design Principles - establish 3-5 guiding principles
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Target User Personas
|
||||
|
||||
{{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}
|
||||
|
||||
### 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}
|
||||
|
||||
### 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}
|
||||
|
||||
## Information Architecture (IA)
|
||||
|
||||
[[LLM: Collaborate with the user to create a comprehensive information architecture:
|
||||
|
||||
1. Build a Site Map or Screen Inventory showing all major areas
|
||||
2. Define the Navigation Structure (primary, secondary, breadcrumbs)
|
||||
3. Use Mermaid diagrams for visual representation
|
||||
4. Consider user mental models and expected groupings
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Site Map / Screen Inventory
|
||||
|
||||
```mermaid
|
||||
{{sitemap_diagram}}
|
||||
```
|
||||
|
||||
@{example: sitemap}
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Homepage] --> B[Dashboard]
|
||||
A --> C[Products]
|
||||
A --> D[Account]
|
||||
B --> B1[Analytics]
|
||||
B --> B2[Recent Activity]
|
||||
C --> C1[Browse]
|
||||
C --> C2[Search]
|
||||
C --> C3[Product Details]
|
||||
D --> D1[Profile]
|
||||
D --> D2[Settings]
|
||||
D --> D3[Billing]
|
||||
```
|
||||
@{/example}
|
||||
|
||||
### Navigation Structure
|
||||
|
||||
**Primary Navigation:** {{primary_nav_description}}
|
||||
|
||||
**Secondary Navigation:** {{secondary_nav_description}}
|
||||
|
||||
**Breadcrumb Strategy:** {{breadcrumb_strategy}}
|
||||
|
||||
## User Flows
|
||||
|
||||
[[LLM: For each critical user task identified in the PRD:
|
||||
|
||||
1. Define the user's goal clearly
|
||||
2. Map out all steps including decision points
|
||||
3. Consider edge cases and error states
|
||||
4. Use Mermaid flow diagrams for clarity
|
||||
5. Link to external tools (Figma/Miro) if detailed flows exist there
|
||||
|
||||
Create subsections for each major flow. After presenting all flows, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
<<REPEAT: user_flow>>
|
||||
### {{flow_name}}
|
||||
|
||||
**User Goal:** {{flow_goal}}
|
||||
|
||||
**Entry Points:** {{entry_points}}
|
||||
|
||||
**Success Criteria:** {{success_criteria}}
|
||||
|
||||
#### Flow Diagram
|
||||
|
||||
```mermaid
|
||||
{{flow_diagram}}
|
||||
```
|
||||
|
||||
**Edge Cases & Error Handling:**
|
||||
- {{edge_case_1}}
|
||||
- {{edge_case_2}}
|
||||
|
||||
**Notes:** {{flow_notes}}
|
||||
<</REPEAT>>
|
||||
|
||||
@{example: user_flow}
|
||||
### User Registration
|
||||
|
||||
**User Goal:** Create a new account to access the platform
|
||||
|
||||
**Entry Points:** Homepage CTA, Login page link, Marketing landing pages
|
||||
|
||||
**Success Criteria:** User successfully creates account and reaches dashboard
|
||||
|
||||
#### Flow Diagram
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
Start[Landing Page] --> Click[Click Sign Up]
|
||||
Click --> Form[Registration Form]
|
||||
Form --> Fill[Fill Required Fields]
|
||||
Fill --> Submit[Submit Form]
|
||||
Submit --> Validate{Valid?}
|
||||
Validate -->|No| Error[Show Errors]
|
||||
Error --> Form
|
||||
Validate -->|Yes| Verify[Email Verification]
|
||||
Verify --> Complete[Account Created]
|
||||
Complete --> Dashboard[Redirect to Dashboard]
|
||||
```
|
||||
|
||||
**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}
|
||||
|
||||
## Wireframes & Mockups
|
||||
|
||||
[[LLM: Clarify where detailed visual designs will be created (Figma, Sketch, etc.) and how to reference them. If low-fidelity wireframes are needed, offer to help conceptualize layouts for key screens.
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
**Primary Design Files:** {{design_tool_link}}
|
||||
|
||||
### Key Screen Layouts
|
||||
|
||||
<<REPEAT: screen_layout>>
|
||||
#### {{screen_name}}
|
||||
|
||||
**Purpose:** {{screen_purpose}}
|
||||
|
||||
**Key Elements:**
|
||||
- {{element_1}}
|
||||
- {{element_2}}
|
||||
- {{element_3}}
|
||||
|
||||
**Interaction Notes:** {{interaction_notes}}
|
||||
|
||||
**Design File Reference:** {{specific_frame_link}}
|
||||
<</REPEAT>>
|
||||
|
||||
## Component Library / Design System
|
||||
|
||||
[[LLM: Discuss whether to use an existing design system or create a new one. If creating new, identify foundational components and their key states. Note that detailed technical specs belong in front-end-architecture.
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
**Design System Approach:** {{design_system_approach}}
|
||||
|
||||
### Core Components
|
||||
|
||||
<<REPEAT: component>>
|
||||
#### {{component_name}}
|
||||
|
||||
**Purpose:** {{component_purpose}}
|
||||
|
||||
**Variants:** {{component_variants}}
|
||||
|
||||
**States:** {{component_states}}
|
||||
|
||||
**Usage Guidelines:** {{usage_guidelines}}
|
||||
<</REPEAT>>
|
||||
|
||||
@{example: component}
|
||||
#### Button
|
||||
|
||||
**Purpose:** Primary interaction element for user actions
|
||||
|
||||
**Variants:** Primary, Secondary, Tertiary, Destructive
|
||||
|
||||
**States:** Default, Hover, Active, Disabled, Loading
|
||||
|
||||
**Usage Guidelines:**
|
||||
- Use Primary for main CTAs (one per view)
|
||||
- Secondary for supporting actions
|
||||
- Destructive only for permanent deletions with confirmation
|
||||
@{/example}
|
||||
|
||||
## Branding & Style Guide
|
||||
|
||||
[[LLM: Link to existing style guide or define key brand elements. Ensure consistency with company brand guidelines if they exist.
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Visual Identity
|
||||
|
||||
**Brand Guidelines:** {{brand_guidelines_link}}
|
||||
|
||||
### 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 |
|
||||
|
||||
### Typography
|
||||
|
||||
**Font Families:**
|
||||
- **Primary:** {{primary_font}}
|
||||
- **Secondary:** {{secondary_font}}
|
||||
- **Monospace:** {{mono_font}}
|
||||
|
||||
**Type Scale:**
|
||||
| Element | Size | Weight | Line Height |
|
||||
|:--------|:-----|:-------|:------------|
|
||||
| H1 | {{h1_size}} | {{h1_weight}} | {{h1_line}} |
|
||||
| H2 | {{h2_size}} | {{h2_weight}} | {{h2_line}} |
|
||||
| H3 | {{h3_size}} | {{h3_weight}} | {{h3_line}} |
|
||||
| Body | {{body_size}} | {{body_weight}} | {{body_line}} |
|
||||
| Small | {{small_size}} | {{small_weight}} | {{small_line}} |
|
||||
|
||||
### Iconography
|
||||
|
||||
**Icon Library:** {{icon_library}}
|
||||
|
||||
**Usage Guidelines:** {{icon_guidelines}}
|
||||
|
||||
### Spacing & Layout
|
||||
|
||||
**Grid System:** {{grid_system}}
|
||||
|
||||
**Spacing Scale:** {{spacing_scale}}
|
||||
|
||||
## Accessibility Requirements
|
||||
|
||||
[[LLM: Define specific accessibility requirements based on target compliance level and user needs. Be comprehensive but practical.
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Compliance Target
|
||||
|
||||
**Standard:** {{compliance_standard}}
|
||||
|
||||
### 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}}
|
||||
|
||||
### Testing Strategy
|
||||
|
||||
{{accessibility_testing}}
|
||||
|
||||
## Responsiveness Strategy
|
||||
|
||||
[[LLM: Define breakpoints and adaptation strategies for different device sizes. Consider both technical constraints and user contexts.
|
||||
|
||||
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}} |
|
||||
|
||||
### Adaptation Patterns
|
||||
|
||||
**Layout Changes:** {{layout_adaptations}}
|
||||
|
||||
**Navigation Changes:** {{nav_adaptations}}
|
||||
|
||||
**Content Priority:** {{content_adaptations}}
|
||||
|
||||
**Interaction Changes:** {{interaction_adaptations}}
|
||||
|
||||
## Animation & Micro-interactions
|
||||
|
||||
[[LLM: Define motion design principles and key interactions. Keep performance and accessibility in mind.
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Motion Principles
|
||||
|
||||
{{motion_principles}}
|
||||
|
||||
### Key Animations
|
||||
|
||||
<<REPEAT: animation>>
|
||||
- **{{animation_name}}:** {{animation_description}} (Duration: {{duration}}, Easing: {{easing}})
|
||||
<</REPEAT>>
|
||||
|
||||
## Performance Considerations
|
||||
|
||||
[[LLM: Define performance goals and strategies that impact UX design decisions.]]
|
||||
|
||||
### Performance Goals
|
||||
|
||||
- **Page Load:** {{load_time_goal}}
|
||||
- **Interaction Response:** {{interaction_goal}}
|
||||
- **Animation FPS:** {{animation_goal}}
|
||||
|
||||
### Design Strategies
|
||||
|
||||
{{performance_strategies}}
|
||||
|
||||
## Next Steps
|
||||
|
||||
[[LLM: After completing the UI/UX specification:
|
||||
|
||||
1. Recommend review with stakeholders
|
||||
2. Suggest creating/updating visual designs in design tool
|
||||
3. Prepare for handoff to Design Architect for frontend architecture
|
||||
4. Note any open questions or decisions needed]]
|
||||
|
||||
### Immediate Actions
|
||||
|
||||
1. {{next_step_1}}
|
||||
2. {{next_step_2}}
|
||||
3. {{next_step_3}}
|
||||
|
||||
### Design Handoff Checklist
|
||||
|
||||
- [ ] All user flows documented
|
||||
- [ ] Component inventory complete
|
||||
- [ ] Accessibility requirements defined
|
||||
- [ ] Responsive strategy clear
|
||||
- [ ] 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.]]
|
||||
==================== END: templates#front-end-spec-tmpl ====================
|
||||
|
||||
==================== START: checklists#frontend-architecture-checklist ====================
|
||||
# Frontend Architecture Document Review Checklist
|
||||
|
||||
## Purpose
|
||||
|
||||
This checklist is for the Design Architect to use after completing the "Frontend Architecture Mode" and populating the `front-end-architecture-tmpl.txt` (or `.md`) document. It ensures all sections are comprehensively covered and meet quality standards before finalization.
|
||||
|
||||
---
|
||||
|
||||
## I. Introduction
|
||||
|
||||
- [ ] Is the `{Project Name}` correctly filled in throughout the Introduction?
|
||||
- [ ] Is the link to the Main Architecture Document present and correct?
|
||||
- [ ] Is the link to the UI/UX Specification present and correct?
|
||||
- [ ] Is the link to the Primary Design Files (Figma, Sketch, etc.) present and correct?
|
||||
- [ ] Is the link to a Deployed Storybook / Component Showcase included, if applicable and available?
|
||||
|
||||
## II. Overall Frontend Philosophy & Patterns
|
||||
|
||||
- [ ] Are the chosen Framework & Core Libraries clearly stated and aligned with the main architecture document?
|
||||
- [ ] Is the Component Architecture (e.g., Atomic Design, Presentational/Container) clearly described?
|
||||
- [ ] Is the State Management Strategy (e.g., Redux Toolkit, Zustand) clearly described at a high level?
|
||||
- [ ] Is the Data Flow (e.g., Unidirectional) clearly explained?
|
||||
- [ ] Is the Styling Approach (e.g., CSS Modules, Tailwind CSS) clearly defined?
|
||||
- [ ] Are Key Design Patterns to be employed (e.g., Provider, Hooks) listed?
|
||||
- [ ] Does this section align with "Definitive Tech Stack Selections" in the main architecture document?
|
||||
- [ ] Are implications from overall system architecture (monorepo/polyrepo, backend services) considered?
|
||||
|
||||
## III. Detailed Frontend Directory Structure
|
||||
|
||||
- [ ] Is an ASCII diagram representing the frontend application's folder structure provided?
|
||||
- [ ] Is the diagram clear, accurate, and reflective of the chosen framework/patterns?
|
||||
- [ ] Are conventions for organizing components, pages, services, state, styles, etc., highlighted?
|
||||
- [ ] Are notes explaining specific conventions or rationale for the structure present and clear?
|
||||
|
||||
## IV. Component Breakdown & Implementation Details
|
||||
|
||||
### Component Naming & Organization
|
||||
|
||||
- [ ] Are conventions for naming components (e.g., PascalCase) described?
|
||||
- [ ] Is the organization of components on the filesystem clearly explained (reiterating from directory structure if needed)?
|
||||
|
||||
### Template for Component Specification
|
||||
|
||||
- [ ] Is the "Template for Component Specification" itself complete and well-defined?
|
||||
- [ ] Does it include fields for: Purpose, Source File(s), Visual Reference?
|
||||
- [ ] Does it include a table structure for Props (Name, Type, Required, Default, Description)?
|
||||
- [ ] Does it include a table structure for Internal State (Variable, Type, Initial Value, Description)?
|
||||
- [ ] Does it include a section for Key UI Elements / Structure (textual or pseudo-HTML)?
|
||||
- [ ] Does it include a section for Events Handled / Emitted?
|
||||
- [ ] Does it include a section for Actions Triggered (State Management, API Calls)?
|
||||
- [ ] Does it include a section for Styling Notes?
|
||||
- [ ] Does it include a section for Accessibility Notes?
|
||||
- [ ] Is there a clear statement that this template should be used for most feature-specific components?
|
||||
|
||||
### Foundational/Shared Components (if any specified upfront)
|
||||
|
||||
- [ ] If any foundational/shared UI components are specified, do they follow the "Template for Component Specification"?
|
||||
- [ ] Is the rationale for specifying these components upfront clear?
|
||||
|
||||
## V. State Management In-Depth
|
||||
|
||||
- [ ] Is the chosen State Management Solution reiterated and rationale briefly provided (if not fully covered in main arch doc)?
|
||||
- [ ] Are conventions for Store Structure / Slices clearly defined (e.g., location, feature-based slices)?
|
||||
- [ ] If a Core Slice Example (e.g., `sessionSlice`) is provided:
|
||||
- [ ] Is its purpose clear?
|
||||
- [ ] Is its State Shape defined (e.g., using TypeScript interface)?
|
||||
- [ ] Are its Key Reducers/Actions listed?
|
||||
- [ ] Is a Feature Slice Template provided, outlining purpose, state shape, and key reducers/actions to be filled in?
|
||||
- [ ] Are conventions for Key Selectors noted (e.g., use `createSelector`)?
|
||||
- [ ] Are examples of Key Selectors for any core slices provided?
|
||||
- [ ] Are conventions for Key Actions / Reducers / Thunks (especially async) described?
|
||||
- [ ] Is an example of a Core Action/Thunk (e.g., `authenticateUser`) provided, detailing its purpose and dispatch flow?
|
||||
- [ ] Is a Feature Action/Thunk Template provided for feature-specific async operations?
|
||||
|
||||
## VI. API Interaction Layer
|
||||
|
||||
- [ ] Is the HTTP Client Setup detailed (e.g., Axios instance, Fetch wrapper, base URL, default headers, interceptors)?
|
||||
- [ ] Are Service Definitions conventions explained?
|
||||
- [ ] Is an example of a service (e.g., `userService.ts`) provided, including its purpose and example functions?
|
||||
- [ ] Is Global Error Handling for API calls described (e.g., toast notifications, global error state)?
|
||||
- [ ] Is guidance on Specific Error Handling within components provided?
|
||||
- [ ] Is any client-side Retry Logic for API calls detailed and configured?
|
||||
|
||||
## VII. Routing Strategy
|
||||
|
||||
- [ ] Is the chosen Routing Library stated?
|
||||
- [ ] Is a table of Route Definitions provided?
|
||||
- [ ] Does it include Path Pattern, Component/Page, Protection status, and Notes for each route?
|
||||
- [ ] Are all key application routes listed?
|
||||
- [ ] Is the Authentication Guard mechanism for protecting routes described?
|
||||
- [ ] Is the Authorization Guard mechanism (if applicable for roles/permissions) described?
|
||||
|
||||
## VIII. Build, Bundling, and Deployment
|
||||
|
||||
- [ ] Are Key Build Scripts (e.g., `npm run build`) listed and their purpose explained?
|
||||
- [ ] Is the handling of Environment Variables during the build process described for different environments?
|
||||
- [ ] Is Code Splitting strategy detailed (e.g., route-based, component-based)?
|
||||
- [ ] Is Tree Shaking confirmed or explained?
|
||||
- [ ] Is Lazy Loading strategy (for components, images, routes) outlined?
|
||||
- [ ] Is Minification & Compression by build tools mentioned?
|
||||
- [ ] Is the Target Deployment Platform (e.g., Vercel, Netlify) specified?
|
||||
- [ ] Is the Deployment Trigger (e.g., Git push via CI/CD) described, referencing the main CI/CD pipeline?
|
||||
- [ ] Is the Asset Caching Strategy (CDN/browser) for static assets outlined?
|
||||
|
||||
## IX. Frontend Testing Strategy
|
||||
|
||||
- [ ] Is there a link to the Main Testing Strategy document/section, and is it correct?
|
||||
- [ ] For Component Testing:
|
||||
- [ ] Is the Scope clearly defined?
|
||||
- [ ] Are the Tools listed?
|
||||
- [ ] Is the Focus of tests (rendering, props, interactions) clear?
|
||||
- [ ] Is the Location of test files specified?
|
||||
- [ ] For UI Integration/Flow Testing:
|
||||
- [ ] Is the Scope (interactions between multiple components) clear?
|
||||
- [ ] Are the Tools listed (can be same as component testing)?
|
||||
- [ ] Is the Focus of these tests clear?
|
||||
- [ ] For End-to-End UI Testing:
|
||||
- [ ] Are the Tools (e.g., Playwright, Cypress) reiterated from main strategy?
|
||||
- [ ] Is the Scope (key user journeys for frontend) defined?
|
||||
- [ ] Is Test Data Management for UI E2E tests addressed?
|
||||
|
||||
## X. Accessibility (AX) Implementation Details
|
||||
|
||||
- [ ] Is there an emphasis on using Semantic HTML?
|
||||
- [ ] Are guidelines for ARIA Implementation (roles, states, properties for custom components) provided?
|
||||
- [ ] Are requirements for Keyboard Navigation (all interactive elements focusable/operable) stated?
|
||||
- [ ] Is Focus Management (for modals, dynamic content) addressed?
|
||||
- [ ] Are Testing Tools for AX (e.g., Axe DevTools, Lighthouse) listed?
|
||||
- [ ] Does this section align with AX requirements from the UI/UX Specification?
|
||||
|
||||
## XI. Performance Considerations
|
||||
|
||||
- [ ] Is Image Optimization (formats, responsive images, lazy loading) discussed?
|
||||
- [ ] Is Code Splitting & Lazy Loading (impact on perceived performance) reiterated if necessary?
|
||||
- [ ] Are techniques for Minimizing Re-renders (e.g., `React.memo`) mentioned?
|
||||
- [ ] Is the use of Debouncing/Throttling for event handlers considered?
|
||||
- [ ] Is Virtualization for long lists/large data sets mentioned if applicable?
|
||||
- [ ] Are Client-Side Caching Strategies (browser cache, service workers) discussed if relevant?
|
||||
- [ ] Are Performance Monitoring Tools (e.g., Lighthouse, DevTools) listed?
|
||||
|
||||
## XII. Change Log
|
||||
|
||||
- [ ] Is the Change Log table present and initialized?
|
||||
- [ ] Is there a process for updating the change log as the document evolves?
|
||||
|
||||
---
|
||||
|
||||
## Final Review Sign-off
|
||||
|
||||
- [ ] Have all placeholders (e.g., `{Project Name}`, `{e.g., ...}`) been filled in or removed where appropriate?
|
||||
- [ ] Has the document been reviewed for clarity, consistency, and completeness by the Design Architect?
|
||||
- [ ] Are all linked documents (Main Architecture, UI/UX Spec) finalized or stable enough for this document to rely on?
|
||||
- [ ] Is the document ready to be shared with the development team?
|
||||
|
||||
==================== END: checklists#frontend-architecture-checklist ====================
|
||||
|
||||
==================== START: data#technical-preferences ====================
|
||||
# User-Defined Preferred Patterns and Preferences
|
||||
|
||||
None Listed
|
||||
|
||||
==================== END: data#technical-preferences ====================
|
||||
|
||||
Reference in New Issue
Block a user