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

chore: add code formatting config and pre-commit hooks (#450)

Browse Source
This commit is contained in:
manjaroblack
2025-08-16 19:08:39 -05:00
committed by GitHub
parent 51284d6ecf
commit ed539432fb
130 changed files with 11886 additions and 10939 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
bmad-core/agent-teams/team-all.yaml
View File

@@ -4,7 +4,7 @@ bundle:
description: Includes every core system agent.
agents:
- bmad-orchestrator
- '*'
- "*"
workflows:
- brownfield-fullstack.yaml
- brownfield-service.yaml

2
bmad-core/agents/bmad-orchestrator.md
View File

@@ -131,7 +131,7 @@ workflow-guidance:
- Understand each workflow's purpose, options, and decision points
- Ask clarifying questions based on the workflow's structure
- Guide users through workflow selection when multiple options exist
- When appropriate, suggest: "Would you like me to create a detailed workflow plan before starting?"
- When appropriate, suggest: 'Would you like me to create a detailed workflow plan before starting?'
- For workflows with divergent paths, help users choose the right path
- Adapt questions to the specific domain (e.g., game dev vs infrastructure vs web dev)
- Only recommend workflows that actually exist in the current bundle

8
bmad-core/agents/dev.md
View File

@@ -35,7 +35,7 @@ agent:
id: dev
title: Full Stack Developer
icon: 💻
whenToUse: "Use for code implementation, debugging, refactoring, and development best practices"
whenToUse: 'Use for code implementation, debugging, refactoring, and development best practices'
customization:
persona:
@@ -57,13 +57,13 @@ commands:
- explain: teach me what and why you did whatever you just did in detail so I can learn. Explain to me as if you were training a junior engineer.
- exit: Say goodbye as the Developer, and then abandon inhabiting this persona
- develop-story:
- order-of-execution: "Read (first or next) task→Implement Task and its subtasks→Write tests→Execute validations→Only if ALL pass, then update the task checkbox with [x]→Update story section File List to ensure it lists and new or modified or deleted source file→repeat order-of-execution until complete"
- order-of-execution: 'Read (first or next) task→Implement Task and its subtasks→Write tests→Execute validations→Only if ALL pass, then update the task checkbox with [x]→Update story section File List to ensure it lists and new or modified or deleted source file→repeat order-of-execution until complete'
- story-file-updates-ONLY:
- CRITICAL: ONLY UPDATE THE STORY FILE WITH UPDATES TO SECTIONS INDICATED BELOW. DO NOT MODIFY ANY OTHER SECTIONS.
- CRITICAL: You are ONLY authorized to edit these specific sections of story files - Tasks / Subtasks Checkboxes, Dev Agent Record section and all its subsections, Agent Model Used, Debug Log References, Completion Notes List, File List, Change Log, Status
- CRITICAL: DO NOT modify Status, Story, Acceptance Criteria, Dev Notes, Testing sections, or any other sections not listed above
- blocking: "HALT for: Unapproved deps needed, confirm with user | Ambiguous after story check | 3 failures attempting to implement or fix something repeatedly | Missing config | Failing regression"
- ready-for-review: "Code matches requirements + All validations pass + Follows standards + File List complete"
- blocking: 'HALT for: Unapproved deps needed, confirm with user | Ambiguous after story check | 3 failures attempting to implement or fix something repeatedly | Missing config | Failing regression'
- ready-for-review: 'Code matches requirements + All validations pass + Follows standards + File List complete'
- completion: "All Tasks and Subtasks marked [x] and have tests→Validations and full regression passes (DON'T BE LAZY, EXECUTE ALL TESTS and CONFIRM)→Ensure File List is Complete→run the task execute-checklist for the checklist story-dod-checklist→set story status: 'Ready for Review'→HALT"
dependencies:

2
bmad-core/data/bmad-kb.md
View File

@@ -298,7 +298,7 @@ You are the "Vibe CEO" - thinking like a CEO with unlimited resources and a sing
- **Claude Code**: `/agent-name` (e.g., `/bmad-master`)
- **Cursor**: `@agent-name` (e.g., `@bmad-master`)
- **Windsurf**: `@agent-name` (e.g., `@bmad-master`)
- **Windsurf**: `/agent-name` (e.g., `/bmad-master`)
- **Trae**: `@agent-name` (e.g., `@bmad-master`)
- **Roo Code**: Select mode from mode selector (e.g., `bmad-master`)
- **GitHub Copilot**: Open the Chat view (`⌃⌘I` on Mac, `Ctrl+Alt+I` on Windows/Linux) and select **Agent** from the chat mode selector.

24
bmad-core/data/test-levels-framework.md
View File

@@ -25,10 +25,10 @@ Comprehensive guide for determining appropriate test levels (unit, integration,
```yaml
unit_test:
component: "PriceCalculator"
scenario: "Calculate discount with multiple rules"
justification: "Complex business logic with multiple branches"
mock_requirements: "None - pure function"
component: 'PriceCalculator'
scenario: 'Calculate discount with multiple rules'
justification: 'Complex business logic with multiple branches'
mock_requirements: 'None - pure function'
```
### Integration Tests
@@ -52,10 +52,10 @@ unit_test:
```yaml
integration_test:
components: ["UserService", "AuthRepository"]
scenario: "Create user with role assignment"
justification: "Critical data flow between service and persistence"
test_environment: "In-memory database"
components: ['UserService', 'AuthRepository']
scenario: 'Create user with role assignment'
justification: 'Critical data flow between service and persistence'
test_environment: 'In-memory database'
```
### End-to-End Tests
@@ -79,10 +79,10 @@ integration_test:
```yaml
e2e_test:
journey: "Complete checkout process"
scenario: "User purchases with saved payment method"
justification: "Revenue-critical path requiring full validation"
environment: "Staging with test payment gateway"
journey: 'Complete checkout process'
scenario: 'User purchases with saved payment method'
justification: 'Revenue-critical path requiring full validation'
environment: 'Staging with test payment gateway'
```
## Test Level Selection Rules

2
bmad-core/tasks/facilitate-brainstorming-session.md
View File

@@ -1,6 +1,6 @@
---
docOutputLocation: docs/brainstorming-session-results.md
template: "{root}/templates/brainstorming-output-tmpl.yaml"
template: '{root}/templates/brainstorming-output-tmpl.yaml'
---
# Facilitate Brainstorming Session Task

60
bmad-core/tasks/nfr-assess.md
View File

@@ -6,18 +6,19 @@ Quick NFR validation focused on the core four: security, performance, reliabilit
```yaml
required:
- story_id: "{epic}.{story}" # e.g., "1.3"
- story_path: "docs/stories/{epic}.{story}.*.md"
- story_id: '{epic}.{story}' # e.g., "1.3"
- story_path: 'docs/stories/{epic}.{story}.*.md'
optional:
- architecture_refs: "docs/architecture/*.md"
- technical_preferences: "docs/technical-preferences.md"
- architecture_refs: 'docs/architecture/*.md'
- technical_preferences: 'docs/technical-preferences.md'
- acceptance_criteria: From story file
```
## Purpose
Assess non-functional requirements for a story and generate:
1. YAML block for the gate file's `nfr_validation` section
2. Brief markdown assessment saved to `docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md`
@@ -26,6 +27,7 @@ Assess non-functional requirements for a story and generate:
### 0. Fail-safe for Missing Inputs
If story_path or story file can't be found:
- Still create assessment file with note: "Source story not found"
- Set all selected NFRs to CONCERNS with notes: "Target unknown / evidence missing"
- Continue with assessment to provide value
@@ -38,7 +40,7 @@ If story_path or story file can't be found:
```text
Which NFRs should I assess? (Enter numbers or press Enter for default)
[1] Security (default)
[2] Performance (default)
[2] Performance (default)
[3] Reliability (default)
[4] Maintainability (default)
[5] Usability
@@ -52,6 +54,7 @@ Which NFRs should I assess? (Enter numbers or press Enter for default)
### 2. Check for Thresholds
Look for NFR requirements in:
- Story acceptance criteria
- `docs/architecture/*.md` files
- `docs/technical-preferences.md`
@@ -72,6 +75,7 @@ No security requirements found. Required auth method?
### 3. Quick Assessment
For each selected NFR, check:
- Is there evidence it's implemented?
- Can we validate it?
- Are there obvious gaps?
@@ -86,24 +90,24 @@ Generate ONLY for NFRs actually assessed (no placeholders):
# Gate YAML (copy/paste):
nfr_validation:
_assessed: [security, performance, reliability, maintainability]
security:
security:
status: CONCERNS
notes: "No rate limiting on auth endpoints"
notes: 'No rate limiting on auth endpoints'
performance:
status: PASS
notes: "Response times < 200ms verified"
notes: 'Response times < 200ms verified'
reliability:
status: PASS
notes: "Error handling and retries implemented"
notes: 'Error handling and retries implemented'
maintainability:
status: CONCERNS
notes: "Test coverage at 65%, target is 80%"
notes: 'Test coverage at 65%, target is 80%'
```
## Deterministic Status Rules
- **FAIL**: Any selected NFR has critical gap or target clearly not met
- **CONCERNS**: No FAILs, but any NFR is unknown/partial/missing evidence
- **CONCERNS**: No FAILs, but any NFR is unknown/partial/missing evidence
- **PASS**: All selected NFRs meet targets with evidence
## Quality Score Calculation
@@ -123,18 +127,21 @@ If `technical-preferences.md` defines custom weights, use those instead.
```markdown
# NFR Assessment: {epic}.{story}
Date: {date}
Reviewer: Quinn
<!-- Note: Source story not found (if applicable) -->
## Summary
- Security: CONCERNS - Missing rate limiting
- Performance: PASS - Meets <200ms requirement
- Reliability: PASS - Proper error handling
- Maintainability: CONCERNS - Test coverage below target
## Critical Issues
1. **No rate limiting** (Security)
- Risk: Brute force attacks possible
- Fix: Add rate limiting middleware to auth endpoints
@@ -144,6 +151,7 @@ Reviewer: Quinn
- Fix: Add tests for uncovered branches
## Quick Wins
- Add rate limiting: ~2 hours
- Increase test coverage: ~4 hours
- Add performance monitoring: ~1 hour
@@ -152,6 +160,7 @@ Reviewer: Quinn
## Output 3: Story Update Line
**End with this line for the review task to quote:**
```
NFR assessment: docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
```
@@ -159,6 +168,7 @@ NFR assessment: docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
## Output 4: Gate Integration Line
**Always print at the end:**
```
Gate NFR block ready → paste into docs/qa/gates/{epic}.{story}-{slug}.yml under nfr_validation
```
@@ -166,66 +176,82 @@ Gate NFR block ready → paste into docs/qa/gates/{epic}.{story}-{slug}.yml unde
## Assessment Criteria
### Security
**PASS if:**
- Authentication implemented
- Authorization enforced
- Input validation present
- No hardcoded secrets
**CONCERNS if:**
- Missing rate limiting
- Weak encryption
- Incomplete authorization
**FAIL if:**
- No authentication
- Hardcoded credentials
- SQL injection vulnerabilities
### Performance
**PASS if:**
- Meets response time targets
- No obvious bottlenecks
- Reasonable resource usage
**CONCERNS if:**
- Close to limits
- Missing indexes
- No caching strategy
**FAIL if:**
- Exceeds response time limits
- Memory leaks
- Unoptimized queries
### Reliability
**PASS if:**
- Error handling present
- Graceful degradation
- Retry logic where needed
**CONCERNS if:**
- Some error cases unhandled
- No circuit breakers
- Missing health checks
**FAIL if:**
- No error handling
- Crashes on errors
- No recovery mechanisms
### Maintainability
**PASS if:**
- Test coverage meets target
- Code well-structured
- Documentation present
**CONCERNS if:**
- Test coverage below target
- Some code duplication
- Missing documentation
**FAIL if:**
- No tests
- Highly coupled code
- No documentation
@@ -283,7 +309,7 @@ maintainability:
1. **Functional Suitability**: Completeness, correctness, appropriateness
2. **Performance Efficiency**: Time behavior, resource use, capacity
3. **Compatibility**: Co-existence, interoperability
3. **Compatibility**: Co-existence, interoperability
4. **Usability**: Learnability, operability, accessibility
5. **Reliability**: Maturity, availability, fault tolerance
6. **Security**: Confidentiality, integrity, authenticity
@@ -291,6 +317,7 @@ maintainability:
8. **Portability**: Adaptability, installability
Use these when assessing beyond the core four.
</details>
<details>
@@ -304,12 +331,13 @@ performance_deep_dive:
p99: 350ms
database:
slow_queries: 2
missing_indexes: ["users.email", "orders.user_id"]
missing_indexes: ['users.email', 'orders.user_id']
caching:
hit_rate: 0%
recommendation: "Add Redis for session data"
recommendation: 'Add Redis for session data'
load_test:
max_rps: 150
breaking_point: 200 rps
```
</details>
</details>

46
bmad-core/tasks/qa-gate.md
View File

@@ -27,11 +27,11 @@ Slug rules:
```yaml
schema: 1
story: "{epic}.{story}"
story: '{epic}.{story}'
gate: PASS|CONCERNS|FAIL|WAIVED
status_reason: "1-2 sentence explanation of gate decision"
reviewer: "Quinn"
updated: "{ISO-8601 timestamp}"
status_reason: '1-2 sentence explanation of gate decision'
reviewer: 'Quinn'
updated: '{ISO-8601 timestamp}'
top_issues: [] # Empty array if no issues
waiver: { active: false } # Only set active: true if WAIVED
```
@@ -40,20 +40,20 @@ waiver: { active: false } # Only set active: true if WAIVED
```yaml
schema: 1
story: "1.3"
story: '1.3'
gate: CONCERNS
status_reason: "Missing rate limiting on auth endpoints poses security risk."
reviewer: "Quinn"
updated: "2025-01-12T10:15:00Z"
status_reason: 'Missing rate limiting on auth endpoints poses security risk.'
reviewer: 'Quinn'
updated: '2025-01-12T10:15:00Z'
top_issues:
- id: "SEC-001"
- id: 'SEC-001'
severity: high # ONLY: low|medium|high
finding: "No rate limiting on login endpoint"
suggested_action: "Add rate limiting middleware before production"
- id: "TEST-001"
finding: 'No rate limiting on login endpoint'
suggested_action: 'Add rate limiting middleware before production'
- id: 'TEST-001'
severity: medium
finding: "No integration tests for auth flow"
suggested_action: "Add integration test coverage"
finding: 'No integration tests for auth flow'
suggested_action: 'Add integration test coverage'
waiver: { active: false }
```
@@ -61,20 +61,20 @@ waiver: { active: false }
```yaml
schema: 1
story: "1.3"
story: '1.3'
gate: WAIVED
status_reason: "Known issues accepted for MVP release."
reviewer: "Quinn"
updated: "2025-01-12T10:15:00Z"
status_reason: 'Known issues accepted for MVP release.'
reviewer: 'Quinn'
updated: '2025-01-12T10:15:00Z'
top_issues:
- id: "PERF-001"
- id: 'PERF-001'
severity: low
finding: "Dashboard loads slowly with 1000+ items"
suggested_action: "Implement pagination in next sprint"
finding: 'Dashboard loads slowly with 1000+ items'
suggested_action: 'Implement pagination in next sprint'
waiver:
active: true
reason: "MVP release - performance optimization deferred"
approved_by: "Product Owner"
reason: 'MVP release - performance optimization deferred'
approved_by: 'Product Owner'
```
## Gate Decision Criteria

36
bmad-core/tasks/review-story.md
View File

@@ -6,10 +6,10 @@ Perform a comprehensive test architecture review with quality gate decision. Thi
```yaml
required:
- story_id: "{epic}.{story}" # e.g., "1.3"
- story_path: "{devStoryLocation}/{epic}.{story}.*.md" # Path from core-config.yaml
- story_title: "{title}" # If missing, derive from story file H1
- story_slug: "{slug}" # If missing, derive from title (lowercase, hyphenated)
- story_id: '{epic}.{story}' # e.g., "1.3"
- story_path: '{devStoryLocation}/{epic}.{story}.*.md' # Path from core-config.yaml
- story_title: '{title}' # If missing, derive from story file H1
- story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
```
## Prerequisites
@@ -191,19 +191,19 @@ Gate file structure:
```yaml
schema: 1
story: "{epic}.{story}"
story_title: "{story title}"
story: '{epic}.{story}'
story_title: '{story title}'
gate: PASS|CONCERNS|FAIL|WAIVED
status_reason: "1-2 sentence explanation of gate decision"
reviewer: "Quinn (Test Architect)"
updated: "{ISO-8601 timestamp}"
status_reason: '1-2 sentence explanation of gate decision'
reviewer: 'Quinn (Test Architect)'
updated: '{ISO-8601 timestamp}'
top_issues: [] # Empty if no issues
waiver: { active: false } # Set active: true only if WAIVED
# Extended fields (optional but recommended):
quality_score: 0-100 # 100 - (20*FAILs) - (10*CONCERNS) or use technical-preferences.md weights
expires: "{ISO-8601 timestamp}" # Typically 2 weeks from review
expires: '{ISO-8601 timestamp}' # Typically 2 weeks from review
evidence:
tests_reviewed: { count }
@@ -215,24 +215,24 @@ evidence:
nfr_validation:
security:
status: PASS|CONCERNS|FAIL
notes: "Specific findings"
notes: 'Specific findings'
performance:
status: PASS|CONCERNS|FAIL
notes: "Specific findings"
notes: 'Specific findings'
reliability:
status: PASS|CONCERNS|FAIL
notes: "Specific findings"
notes: 'Specific findings'
maintainability:
status: PASS|CONCERNS|FAIL
notes: "Specific findings"
notes: 'Specific findings'
recommendations:
immediate: # Must fix before production
- action: "Add rate limiting"
refs: ["api/auth/login.ts"]
- action: 'Add rate limiting'
refs: ['api/auth/login.ts']
future: # Can be addressed later
- action: "Consider caching"
refs: ["services/data.ts"]
- action: 'Consider caching'
refs: ['services/data.ts']
```
### Gate Decision Criteria

50
bmad-core/tasks/risk-profile.md
View File

@@ -6,10 +6,10 @@ Generate a comprehensive risk assessment matrix for a story implementation using
```yaml
required:
- story_id: "{epic}.{story}" # e.g., "1.3"
- story_path: "docs/stories/{epic}.{story}.*.md"
- story_title: "{title}" # If missing, derive from story file H1
- story_slug: "{slug}" # If missing, derive from title (lowercase, hyphenated)
- story_id: '{epic}.{story}' # e.g., "1.3"
- story_path: 'docs/stories/{epic}.{story}.*.md'
- story_title: '{title}' # If missing, derive from story file H1
- story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
```
## Purpose
@@ -79,14 +79,14 @@ For each category, identify specific risks:
```yaml
risk:
id: "SEC-001" # Use prefixes: SEC, PERF, DATA, BUS, OPS, TECH
id: 'SEC-001' # Use prefixes: SEC, PERF, DATA, BUS, OPS, TECH
category: security
title: "Insufficient input validation on user forms"
description: "Form inputs not properly sanitized could lead to XSS attacks"
title: 'Insufficient input validation on user forms'
description: 'Form inputs not properly sanitized could lead to XSS attacks'
affected_components:
- "UserRegistrationForm"
- "ProfileUpdateForm"
detection_method: "Code review revealed missing validation"
- 'UserRegistrationForm'
- 'ProfileUpdateForm'
detection_method: 'Code review revealed missing validation'
```
### 2. Risk Assessment
@@ -133,20 +133,20 @@ For each identified risk, provide mitigation:
```yaml
mitigation:
risk_id: "SEC-001"
strategy: "preventive" # preventive|detective|corrective
risk_id: 'SEC-001'
strategy: 'preventive' # preventive|detective|corrective
actions:
- "Implement input validation library (e.g., validator.js)"
- "Add CSP headers to prevent XSS execution"
- "Sanitize all user inputs before storage"
- "Escape all outputs in templates"
- 'Implement input validation library (e.g., validator.js)'
- 'Add CSP headers to prevent XSS execution'
- 'Sanitize all user inputs before storage'
- 'Escape all outputs in templates'
testing_requirements:
- "Security testing with OWASP ZAP"
- "Manual penetration testing of forms"
- "Unit tests for validation functions"
residual_risk: "Low - Some zero-day vulnerabilities may remain"
owner: "dev"
timeline: "Before deployment"
- 'Security testing with OWASP ZAP'
- 'Manual penetration testing of forms'
- 'Unit tests for validation functions'
residual_risk: 'Low - Some zero-day vulnerabilities may remain'
owner: 'dev'
timeline: 'Before deployment'
```
## Outputs
@@ -172,12 +172,12 @@ risk_summary:
highest:
id: SEC-001
score: 9
title: "XSS on profile form"
title: 'XSS on profile form'
recommendations:
must_fix:
- "Add input sanitization & CSP"
- 'Add input sanitization & CSP'
monitor:
- "Add security alerts for auth endpoints"
- 'Add security alerts for auth endpoints'
```
### Output 2: Markdown Report

18
bmad-core/tasks/test-design.md
View File

@@ -6,10 +6,10 @@ Create comprehensive test scenarios with appropriate test level recommendations
```yaml
required:
- story_id: "{epic}.{story}" # e.g., "1.3"
- story_path: "{devStoryLocation}/{epic}.{story}.*.md" # Path from core-config.yaml
- story_title: "{title}" # If missing, derive from story file H1
- story_slug: "{slug}" # If missing, derive from title (lowercase, hyphenated)
- story_id: '{epic}.{story}' # e.g., "1.3"
- story_path: '{devStoryLocation}/{epic}.{story}.*.md' # Path from core-config.yaml
- story_title: '{title}' # If missing, derive from story file H1
- story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
```
## Purpose
@@ -62,13 +62,13 @@ For each identified test need, create:
```yaml
test_scenario:
id: "{epic}.{story}-{LEVEL}-{SEQ}"
requirement: "AC reference"
id: '{epic}.{story}-{LEVEL}-{SEQ}'
requirement: 'AC reference'
priority: P0|P1|P2|P3
level: unit|integration|e2e
description: "What is being tested"
justification: "Why this level was chosen"
mitigates_risks: ["RISK-001"] # If risk profile exists
description: 'What is being tested'
justification: 'Why this level was chosen'
mitigates_risks: ['RISK-001'] # If risk profile exists
```
### 5. Validate Coverage

42
bmad-core/tasks/trace-requirements.md
View File

@@ -31,21 +31,21 @@ Identify all testable requirements from:
For each requirement, document which tests validate it. Use Given-When-Then to describe what the test validates (not how it's written):
```yaml
requirement: "AC1: User can login with valid credentials"
requirement: 'AC1: User can login with valid credentials'
test_mappings:
- test_file: "auth/login.test.ts"
test_case: "should successfully login with valid email and password"
- test_file: 'auth/login.test.ts'
test_case: 'should successfully login with valid email and password'
# Given-When-Then describes WHAT the test validates, not HOW it's coded
given: "A registered user with valid credentials"
when: "They submit the login form"
then: "They are redirected to dashboard and session is created"
given: 'A registered user with valid credentials'
when: 'They submit the login form'
then: 'They are redirected to dashboard and session is created'
coverage: full
- test_file: "e2e/auth-flow.test.ts"
test_case: "complete login flow"
given: "User on login page"
when: "Entering valid credentials and submitting"
then: "Dashboard loads with user data"
- test_file: 'e2e/auth-flow.test.ts'
test_case: 'complete login flow'
given: 'User on login page'
when: 'Entering valid credentials and submitting'
then: 'Dashboard loads with user data'
coverage: integration
```
@@ -67,19 +67,19 @@ Document any gaps found:
```yaml
coverage_gaps:
- requirement: "AC3: Password reset email sent within 60 seconds"
gap: "No test for email delivery timing"
- requirement: 'AC3: Password reset email sent within 60 seconds'
gap: 'No test for email delivery timing'
severity: medium
suggested_test:
type: integration
description: "Test email service SLA compliance"
description: 'Test email service SLA compliance'
- requirement: "AC5: Support 1000 concurrent users"
gap: "No load testing implemented"
- requirement: 'AC5: Support 1000 concurrent users'
gap: 'No load testing implemented'
severity: high
suggested_test:
type: performance
description: "Load test with 1000 concurrent connections"
description: 'Load test with 1000 concurrent connections'
```
## Outputs
@@ -95,11 +95,11 @@ trace:
full: Y
partial: Z
none: W
planning_ref: "docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md"
planning_ref: 'docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md'
uncovered:
- ac: "AC3"
reason: "No test found for password reset timing"
notes: "See docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md"
- ac: 'AC3'
reason: 'No test found for password reset timing'
notes: 'See docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md'
```
### Output 2: Traceability Report

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

@@ -20,20 +20,20 @@ sections:
- id: intro-content
content: |
This document outlines the overall project architecture for {{project_name}}, including backend systems, shared services, and non-UI specific concerns. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development, ensuring consistency and adherence to chosen patterns and technologies.
**Relationship to Frontend Architecture:**
If the project includes a significant user interface, a separate Frontend Architecture Document will detail the frontend-specific design and MUST be used in conjunction with this document. Core technology stack choices documented herein (see "Tech Stack") are definitive for the entire project, including any frontend components.
- id: starter-template
title: Starter Template or Existing Project
instruction: |
Before proceeding further with architecture design, check if the project is based on a starter template or existing codebase:
1. Review the PRD and brainstorming brief for any mentions of:
- Starter templates (e.g., Create React App, Next.js, Vue CLI, Angular CLI, etc.)
- Existing projects or codebases being used as a foundation
- Boilerplate projects or scaffolding tools
- Previous projects to be cloned or adapted
2. If a starter template or existing project is mentioned:
- Ask the user to provide access via one of these methods:
- Link to the starter template documentation
@@ -46,16 +46,16 @@ sections:
- Existing architectural patterns and conventions
- Any limitations or constraints imposed by the starter
- Use this analysis to inform and align your architecture decisions
3. If no starter template is mentioned but this is a greenfield project:
- Suggest appropriate starter templates based on the tech stack preferences
- Explain the benefits (faster setup, best practices, community support)
- Let the user decide whether to use one
4. If the user confirms no starter template will be used:
- Proceed with architecture design from scratch
- Note that manual setup will be required for all tooling and configuration
Document the decision here before proceeding with the architecture design. If none, just say N/A
elicit: true
- id: changelog
@@ -83,7 +83,7 @@ sections:
title: High Level Overview
instruction: |
Based on the PRD's Technical Assumptions section, describe:
1. The main architectural style (e.g., Monolith, Microservices, Serverless, Event-Driven)
2. Repository structure decision from PRD (Monorepo/Polyrepo)
3. Service architecture decision from PRD
@@ -100,17 +100,17 @@ sections:
- Data flow directions
- External integrations
- User entry points
- id: architectural-patterns
title: Architectural and Design Patterns
instruction: |
List the key high-level patterns that will guide the architecture. For each pattern:
1. Present 2-3 viable options if multiple exist
2. Provide your recommendation with clear rationale
3. Get user confirmation before finalizing
4. These patterns should align with the PRD's technical assumptions and project goals
Common patterns to consider:
- Architectural style patterns (Serverless, Event-Driven, Microservices, CQRS, Hexagonal)
- Code organization patterns (Dependency Injection, Repository, Module, Factory)
@@ -126,23 +126,23 @@ sections:
title: Tech Stack
instruction: |
This is the DEFINITIVE technology selection section. Work with the user to make specific choices:
1. Review PRD technical assumptions and any preferences from {root}/data/technical-preferences.yaml or an attached technical-preferences
2. For each category, present 2-3 viable options with pros/cons
3. Make a clear recommendation based on project needs
4. Get explicit user approval for each selection
5. Document exact versions (avoid "latest" - pin specific versions)
6. This table is the single source of truth - all other docs must reference these choices
Key decisions to finalize - before displaying the table, ensure you are aware of or ask the user about - let the user know if they are not sure on any that you can also provide suggestions with rationale:
- Starter templates (if any)
- Languages and runtimes with exact versions
- Frameworks and libraries / packages
- Cloud provider and key services choices
- Database and storage solutions - if unclear suggest sql or nosql or other types depending on the project and depending on cloud provider offer a suggestion
- Development tools
Upon render of the table, ensure the user is aware of the importance of this sections choices, should also look for gaps or disagreements with anything, ask for any clarifications if something is unclear why its in the list, and also right away elicit feedback - this statement and the options should be rendered and then prompt right all before allowing user input.
elicit: true
sections:
@@ -166,13 +166,13 @@ sections:
title: Data Models
instruction: |
Define the core data models/entities:
1. Review PRD requirements and identify key business entities
2. For each model, explain its purpose and relationships
3. Include key attributes and data types
4. Show relationships between models
5. Discuss design decisions with user
Create a clear conceptual model before moving to database schema.
elicit: true
repeatable: true
@@ -181,11 +181,11 @@ sections:
title: "{{model_name}}"
template: |
**Purpose:** {{model_purpose}}
**Key Attributes:**
- {{attribute_1}}: {{type_1}} - {{description_1}}
- {{attribute_2}}: {{type_2}} - {{description_2}}
**Relationships:**
- {{relationship_1}}
- {{relationship_2}}
@@ -194,7 +194,7 @@ sections:
title: Components
instruction: |
Based on the architectural patterns, tech stack, and data models from above:
1. Identify major logical components/services and their responsibilities
2. Consider the repository structure (monorepo/polyrepo) from PRD
3. Define clear boundaries and interfaces between components
@@ -203,7 +203,7 @@ sections:
- Key interfaces/APIs exposed
- Dependencies on other components
- Technology specifics based on tech stack choices
5. Create component diagrams where helpful
elicit: true
sections:
@@ -212,13 +212,13 @@ sections:
title: "{{component_name}}"
template: |
**Responsibility:** {{component_description}}
**Key Interfaces:**
- {{interface_1}}
- {{interface_2}}
**Dependencies:** {{dependencies}}
**Technology Stack:** {{component_tech_details}}
- id: component-diagrams
title: Component Diagrams
@@ -235,13 +235,13 @@ sections:
condition: Project requires external API integrations
instruction: |
For each external service integration:
1. Identify APIs needed based on PRD requirements and component design
2. If documentation URLs are unknown, ask user for specifics
3. Document authentication methods and security considerations
4. List specific endpoints that will be used
5. Note any rate limits or usage constraints
If no external APIs are needed, state this explicitly and skip to next section.
elicit: true
repeatable: true
@@ -254,10 +254,10 @@ sections:
- **Base URL(s):** {{api_base_url}}
- **Authentication:** {{auth_method}}
- **Rate Limits:** {{rate_limits}}
**Key Endpoints Used:**
- `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
**Integration Notes:** {{integration_considerations}}
- id: core-workflows
@@ -266,13 +266,13 @@ sections:
mermaid_type: sequence
instruction: |
Illustrate key system workflows using sequence diagrams:
1. Identify critical user journeys from PRD
2. Show component interactions including external APIs
3. Include error handling paths
4. Document async operations
5. Create both high-level and detailed diagrams as needed
Focus on workflows that clarify architecture decisions or complex interactions.
elicit: true
@@ -283,13 +283,13 @@ sections:
language: yaml
instruction: |
If the project includes a REST API:
1. Create an OpenAPI 3.0 specification
2. Include all endpoints from epics/stories
3. Define request/response schemas based on data models
4. Document authentication requirements
5. Include example requests/responses
Use YAML format for better readability. If no REST API, skip this section.
elicit: true
template: |
@@ -306,13 +306,13 @@ sections:
title: Database Schema
instruction: |
Transform the conceptual data models into concrete database schemas:
1. Use the database type(s) selected in Tech Stack
2. Create schema definitions using appropriate notation
3. Include indexes, constraints, and relationships
4. Consider performance and scalability
5. For NoSQL, show document structures
Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.)
elicit: true
@@ -322,14 +322,14 @@ sections:
language: plaintext
instruction: |
Create a project folder structure that reflects:
1. The chosen repository structure (monorepo/polyrepo)
2. The service architecture (monolith/microservices/serverless)
3. The selected tech stack and languages
4. Component organization from above
5. Best practices for the chosen frameworks
6. Clear separation of concerns
Adapt the structure based on project needs. For monorepos, show service separation. For serverless, show function organization. Include language-specific conventions.
elicit: true
examples:
@@ -347,13 +347,13 @@ sections:
title: Infrastructure and Deployment
instruction: |
Define the deployment architecture and practices:
1. Use IaC tool selected in Tech Stack
2. Choose deployment strategy appropriate for the architecture
3. Define environments and promotion flow
4. Establish rollback procedures
5. Consider security, monitoring, and cost optimization
Get user input on deployment preferences and CI/CD tool choices.
elicit: true
sections:
@@ -389,13 +389,13 @@ sections:
title: Error Handling Strategy
instruction: |
Define comprehensive error handling approach:
1. Choose appropriate patterns for the language/framework from Tech Stack
2. Define logging standards and tools
3. Establish error categories and handling rules
4. Consider observability and debugging needs
5. Ensure security (no sensitive data in logs)
This section guides both AI and human developers in consistent error handling.
elicit: true
sections:
@@ -442,13 +442,13 @@ sections:
title: Coding Standards
instruction: |
These standards are MANDATORY for AI agents. Work with user to define ONLY the critical rules needed to prevent bad code. Explain that:
1. This section directly controls AI developer behavior
2. Keep it minimal - assume AI knows general best practices
3. Focus on project-specific conventions and gotchas
4. Overly detailed standards bloat context and slow development
5. Standards will be extracted to separate file for dev agent use
For each standard, get explicit user confirmation it's necessary.
elicit: true
sections:
@@ -470,7 +470,7 @@ sections:
- "Never use console.log in production code - use logger"
- "All API responses must use ApiResponse wrapper type"
- "Database queries must use repository pattern, never direct ORM"
Avoid obvious rules like "use SOLID principles" or "write clean code"
repeatable: true
template: "- **{{rule_name}}:** {{rule_description}}"
@@ -488,14 +488,14 @@ sections:
title: Test Strategy and Standards
instruction: |
Work with user to define comprehensive test strategy:
1. Use test frameworks from Tech Stack
2. Decide on TDD vs test-after approach
3. Define test organization and naming
4. Establish coverage goals
5. Determine integration test infrastructure
6. Plan for test data and external dependencies
Note: Basic info goes in Coding Standards for dev agent. This detailed section is for QA agent and team reference.
elicit: true
sections:
@@ -516,7 +516,7 @@ sections:
- **Location:** {{unit_test_location}}
- **Mocking Library:** {{mocking_library}}
- **Coverage Requirement:** {{unit_coverage}}
**AI Agent Requirements:**
- Generate tests for all public methods
- Cover edge cases and error conditions
@@ -558,7 +558,7 @@ sections:
title: Security
instruction: |
Define MANDATORY security requirements for AI and human developers:
1. Focus on implementation-specific rules
2. Reference security tools from Tech Stack
3. Define clear patterns for common scenarios
@@ -627,16 +627,16 @@ sections:
title: Next Steps
instruction: |
After completing the architecture:
1. If project has UI components:
- Use "Frontend Architecture Mode"
- Provide this document as input
2. For all projects:
- Review with Product Owner
- Begin story implementation with Dev agent
- Set up infrastructure with DevOps agent
3. Include specific prompts for next agents if needed
sections:
- id: architect-prompt

10
bmad-core/templates/brainstorming-output-tmpl.yaml
View File

@@ -23,11 +23,11 @@ sections:
- id: summary-details
template: |
**Topic:** {{session_topic}}
**Session Goals:** {{stated_goals}}
**Techniques Used:** {{techniques_list}}
**Total Ideas Generated:** {{total_ideas}}
- id: key-themes
title: "Key Themes Identified:"
@@ -152,5 +152,5 @@ sections:
- id: footer
content: |
---
*Session facilitated using the BMAD-METHOD brainstorming framework*
*Session facilitated using the BMAD-METHOD brainstorming framework*

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

@@ -16,40 +16,40 @@ sections:
title: Introduction
instruction: |
IMPORTANT - SCOPE AND ASSESSMENT REQUIRED:
This architecture document is for SIGNIFICANT enhancements to existing projects that require comprehensive architectural planning. Before proceeding:
1. **Verify Complexity**: Confirm this enhancement requires architectural planning. For simple additions, recommend: "For simpler changes that don't require architectural planning, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead."
2. **REQUIRED INPUTS**:
- Completed brownfield-prd.md
- Existing project technical documentation (from docs folder or user-provided)
- Access to existing project structure (IDE or uploaded files)
3. **DEEP ANALYSIS MANDATE**: You MUST conduct thorough analysis of the existing codebase, architecture patterns, and technical constraints before making ANY architectural recommendations. Every suggestion must be based on actual project analysis, not assumptions.
4. **CONTINUOUS VALIDATION**: Throughout this process, explicitly validate your understanding with the user. For every architectural decision, confirm: "Based on my analysis of your existing system, I recommend [decision] because [evidence from actual project]. Does this align with your system's reality?"
If any required inputs are missing, request them before proceeding.
elicit: true
sections:
- id: intro-content
content: |
This document outlines the architectural approach for enhancing {{project_name}} with {{enhancement_description}}. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development of new features while ensuring seamless integration with the existing system.
**Relationship to Existing Architecture:**
This document supplements existing project architecture by defining how new components will integrate with current systems. Where conflicts arise between new and existing patterns, this document provides guidance on maintaining consistency while implementing enhancements.
- id: existing-project-analysis
title: Existing Project Analysis
instruction: |
Analyze the existing project structure and architecture:
1. Review existing documentation in docs folder
2. Examine current technology stack and versions
3. Identify existing architectural patterns and conventions
4. Note current deployment and infrastructure setup
5. Document any constraints or limitations
CRITICAL: After your analysis, explicitly validate your findings: "Based on my analysis of your project, I've identified the following about your existing system: [key findings]. Please confirm these observations are accurate before I proceed with architectural recommendations."
elicit: true
sections:
@@ -78,12 +78,12 @@ sections:
title: Enhancement Scope and Integration Strategy
instruction: |
Define how the enhancement will integrate with the existing system:
1. Review the brownfield PRD enhancement scope
2. Identify integration points with existing code
3. Define boundaries between new and existing functionality
4. Establish compatibility requirements
VALIDATION CHECKPOINT: Before presenting the integration strategy, confirm: "Based on my analysis, the integration approach I'm proposing takes into account [specific existing system characteristics]. These integration points and boundaries respect your current architecture patterns. Is this assessment accurate?"
elicit: true
sections:
@@ -112,7 +112,7 @@ sections:
title: Tech Stack Alignment
instruction: |
Ensure new components align with existing technology choices:
1. Use existing technology stack as the foundation
2. Only introduce new technologies if absolutely necessary
3. Justify any new additions with clear rationale
@@ -135,7 +135,7 @@ sections:
title: Data Models and Schema Changes
instruction: |
Define new data models and how they integrate with existing schema:
1. Identify new entities required for the enhancement
2. Define relationships with existing data models
3. Plan database schema changes (additions, modifications)
@@ -151,11 +151,11 @@ sections:
template: |
**Purpose:** {{model_purpose}}
**Integration:** {{integration_with_existing}}
**Key Attributes:**
- {{attribute_1}}: {{type_1}} - {{description_1}}
- {{attribute_2}}: {{type_2}} - {{description_2}}
**Relationships:**
- **With Existing:** {{existing_relationships}}
- **With New:** {{new_relationships}}
@@ -167,7 +167,7 @@ sections:
- **Modified Tables:** {{modified_tables_list}}
- **New Indexes:** {{new_indexes_list}}
- **Migration Strategy:** {{migration_approach}}
**Backward Compatibility:**
- {{compatibility_measure_1}}
- {{compatibility_measure_2}}
@@ -176,12 +176,12 @@ sections:
title: Component Architecture
instruction: |
Define new components and their integration with existing architecture:
1. Identify new components required for the enhancement
2. Define interfaces with existing components
3. Establish clear boundaries and responsibilities
4. Plan integration points and data flow
MANDATORY VALIDATION: Before presenting component architecture, confirm: "The new components I'm proposing follow the existing architectural patterns I identified in your codebase: [specific patterns]. The integration interfaces respect your current component structure and communication patterns. Does this match your project's reality?"
elicit: true
sections:
@@ -194,15 +194,15 @@ sections:
template: |
**Responsibility:** {{component_description}}
**Integration Points:** {{integration_points}}
**Key Interfaces:**
- {{interface_1}}
- {{interface_2}}
**Dependencies:**
- **Existing Components:** {{existing_dependencies}}
- **New Components:** {{new_dependencies}}
**Technology Stack:** {{component_tech_details}}
- id: interaction-diagram
title: Component Interaction Diagram
@@ -215,7 +215,7 @@ sections:
condition: Enhancement requires API changes
instruction: |
Define new API endpoints and integration with existing APIs:
1. Plan new API endpoints required for the enhancement
2. Ensure consistency with existing API patterns
3. Define authentication and authorization integration
@@ -265,17 +265,17 @@ sections:
- **Base URL:** {{api_base_url}}
- **Authentication:** {{auth_method}}
- **Integration Method:** {{integration_approach}}
**Key Endpoints Used:**
- `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
**Error Handling:** {{error_handling_strategy}}
- id: source-tree-integration
title: Source Tree Integration
instruction: |
Define how new code will integrate with existing project structure:
1. Follow existing project organization patterns
2. Identify where new files/folders will be placed
3. Ensure consistency with existing naming conventions
@@ -314,7 +314,7 @@ sections:
title: Infrastructure and Deployment Integration
instruction: |
Define how the enhancement will be deployed alongside existing infrastructure:
1. Use existing deployment pipeline and infrastructure
2. Identify any infrastructure changes needed
3. Plan deployment strategy to minimize risk
@@ -344,7 +344,7 @@ sections:
title: Coding Standards and Conventions
instruction: |
Ensure new code follows existing project conventions:
1. Document existing coding standards from project analysis
2. Identify any enhancement-specific requirements
3. Ensure consistency with existing codebase patterns
@@ -375,7 +375,7 @@ sections:
title: Testing Strategy
instruction: |
Define testing approach for the enhancement:
1. Integrate with existing test suite
2. Ensure existing functionality remains intact
3. Plan for testing new features
@@ -415,7 +415,7 @@ sections:
title: Security Integration
instruction: |
Ensure security consistency with existing system:
1. Follow existing security patterns and tools
2. Ensure new features don't introduce vulnerabilities
3. Maintain existing security posture
@@ -450,7 +450,7 @@ sections:
title: Next Steps
instruction: |
After completing the brownfield architecture:
1. Review integration points with existing system
2. Begin story implementation with Dev agent
3. Set up deployment pipeline integration
@@ -473,4 +473,4 @@ sections:
- Integration requirements with existing codebase validated with user
- Key technical decisions based on real project constraints
- Existing system compatibility requirements with specific verification steps
- Clear sequencing of implementation to minimize risk to existing functionality
- Clear sequencing of implementation to minimize risk to existing functionality

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

@@ -16,19 +16,19 @@ sections:
title: Intro Project Analysis and Context
instruction: |
IMPORTANT - SCOPE ASSESSMENT REQUIRED:
This PRD is for SIGNIFICANT enhancements to existing projects that require comprehensive planning and multiple stories. Before proceeding:
1. **Assess Enhancement Complexity**: If this is a simple feature addition or bug fix that could be completed in 1-2 focused development sessions, STOP and recommend: "For simpler changes, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead. This full PRD process is designed for substantial enhancements that require architectural planning and multiple coordinated stories."
2. **Project Context**: Determine if we're working in an IDE with the project already loaded or if the user needs to provide project information. If project files are available, analyze existing documentation in the docs folder. If insufficient documentation exists, recommend running the document-project task first.
3. **Deep Assessment Requirement**: You MUST thoroughly analyze the existing project structure, patterns, and constraints before making ANY suggestions. Every recommendation must be grounded in actual project analysis, not assumptions.
Gather comprehensive information about the existing project. This section must be completed before proceeding with requirements.
CRITICAL: Throughout this analysis, explicitly confirm your understanding with the user. For every assumption you make about the existing project, ask: "Based on my analysis, I understand that [assumption]. Is this correct?"
Do not proceed with any recommendations until the user has validated your understanding of the existing system.
sections:
- id: existing-project-overview
@@ -54,7 +54,7 @@ sections:
- Note: "Document-project analysis available - using existing technical documentation"
- List key documents created by document-project
- Skip the missing documentation check below
Otherwise, check for existing documentation:
sections:
- id: available-docs
@@ -178,7 +178,7 @@ sections:
If document-project output available:
- Extract from "Actual Tech Stack" table in High Level Architecture section
- Include version numbers and any noted constraints
Otherwise, document the current technology stack:
template: |
**Languages**: {{languages}}
@@ -217,7 +217,7 @@ sections:
- Reference "Technical Debt and Known Issues" section
- Include "Workarounds and Gotchas" that might impact enhancement
- Note any identified constraints from "Critical Technical Debt"
Build risk assessment incorporating existing known issues:
template: |
**Technical Risks**: {{technical_risks}}
@@ -240,7 +240,7 @@ sections:
title: "Epic 1: {{enhancement_title}}"
instruction: |
Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality
CRITICAL STORY SEQUENCING FOR BROWNFIELD:
- Stories must ensure existing functionality remains intact
- Each story should include verification that existing features still work
@@ -253,7 +253,7 @@ sections:
- Each story must deliver value while maintaining system integrity
template: |
**Epic Goal**: {{epic_goal}}
**Integration Requirements**: {{integration_requirements}}
sections:
- id: story
@@ -277,4 +277,4 @@ sections:
items:
- template: "IV1: {{existing_functionality_verification}}"
- template: "IV2: {{integration_point_verification}}"
- template: "IV3: {{performance_impact_verification}}"
- template: "IV3: {{performance_impact_verification}}"

25
bmad-core/templates/competitor-analysis-tmpl.yaml
View File

@@ -76,7 +76,7 @@ sections:
title: Competitor Prioritization Matrix
instruction: |
Help categorize competitors by market share and strategic threat level
Create a 2x2 matrix:
- Priority 1 (Core Competitors): High Market Share + High Threat
- Priority 2 (Emerging Threats): Low Market Share + High Threat
@@ -141,7 +141,14 @@ sections:
title: Feature Comparison Matrix
instruction: Create a detailed comparison table of key features across competitors
type: table
columns: ["Feature Category", "{{your_company}}", "{{competitor_1}}", "{{competitor_2}}", "{{competitor_3}}"]
columns:
[
"Feature Category",
"{{your_company}}",
"{{competitor_1}}",
"{{competitor_2}}",
"{{competitor_3}}",
]
rows:
- category: "Core Functionality"
items:
@@ -153,7 +160,13 @@ sections:
- ["Onboarding Time", "{{time}}", "{{time}}", "{{time}}", "{{time}}"]
- category: "Integration & Ecosystem"
items:
- ["API Availability", "{{availability}}", "{{availability}}", "{{availability}}", "{{availability}}"]
- [
"API Availability",
"{{availability}}",
"{{availability}}",
"{{availability}}",
"{{availability}}",
]
- ["Third-party Integrations", "{{number}}", "{{number}}", "{{number}}", "{{number}}"]
- category: "Pricing & Plans"
items:
@@ -180,7 +193,7 @@ sections:
title: Positioning Map
instruction: |
Describe competitor positions on key dimensions
Create a positioning description using 2 key dimensions relevant to the market, such as:
- Price vs. Features
- Ease of Use vs. Power
@@ -215,7 +228,7 @@ sections:
title: Blue Ocean Opportunities
instruction: |
Identify uncontested market spaces
List opportunities to create new market space:
- Underserved segments
- Unaddressed use cases
@@ -290,4 +303,4 @@ sections:
Recommended review schedule:
- Weekly: {{weekly_items}}
- Monthly: {{monthly_items}}
- Quarterly: {{quarterly_analysis}}
- Quarterly: {{quarterly_analysis}}

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

@@ -16,16 +16,16 @@ sections:
title: Template and Framework Selection
instruction: |
Review provided documents including PRD, UX-UI Specification, and main Architecture Document. Focus on extracting technical implementation details needed for AI frontend tools and developer agents. Ask the user for any of these documents if you are unable to locate and were not provided.
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
@@ -41,7 +41,7 @@ sections:
- 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
@@ -49,11 +49,11 @@ sections:
- 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.
sections:
- id: changelog
@@ -75,12 +75,24 @@ sections:
rows:
- ["Framework", "{{framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["UI Library", "{{ui_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["State Management", "{{state_management}}", "{{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}}"]
- [
"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}}"]
@@ -203,4 +215,4 @@ sections:
- Common commands (dev server, build, test)
- Key import patterns
- File naming conventions
- Project-specific patterns and utilities
- Project-specific patterns and utilities

48
bmad-core/templates/front-end-spec-tmpl.yaml
View File

@@ -16,7 +16,7 @@ sections:
title: Introduction
instruction: |
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.
Establish the document's purpose and scope. Keep the content below but ensure project name is properly substituted.
content: |
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.
@@ -25,7 +25,7 @@ sections:
title: Overall UX Goals & Principles
instruction: |
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
@@ -66,7 +66,7 @@ sections:
title: Information Architecture (IA)
instruction: |
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
@@ -96,22 +96,22 @@ sections:
title: Navigation Structure
template: |
**Primary Navigation:** {{primary_nav_description}}
**Secondary Navigation:** {{secondary_nav_description}}
**Breadcrumb Strategy:** {{breadcrumb_strategy}}
- id: user-flows
title: User Flows
instruction: |
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.
elicit: true
repeatable: true
@@ -120,9 +120,9 @@ sections:
title: "{{flow_name}}"
template: |
**User Goal:** {{flow_goal}}
**Entry Points:** {{entry_points}}
**Success Criteria:** {{success_criteria}}
sections:
- id: flow-diagram
@@ -153,14 +153,14 @@ sections:
title: "{{screen_name}}"
template: |
**Purpose:** {{screen_purpose}}
**Key Elements:**
- {{element_1}}
- {{element_2}}
- {{element_3}}
**Interaction Notes:** {{interaction_notes}}
**Design File Reference:** {{specific_frame_link}}
- id: component-library
@@ -179,11 +179,11 @@ sections:
title: "{{component_name}}"
template: |
**Purpose:** {{component_purpose}}
**Variants:** {{component_variants}}
**States:** {{component_states}}
**Usage Guidelines:** {{usage_guidelines}}
- id: branding-style
@@ -229,13 +229,13 @@ sections:
title: Iconography
template: |
**Icon Library:** {{icon_library}}
**Usage Guidelines:** {{icon_guidelines}}
- id: spacing-layout
title: Spacing & Layout
template: |
**Grid System:** {{grid_system}}
**Spacing Scale:** {{spacing_scale}}
- id: accessibility
@@ -253,12 +253,12 @@ sections:
- 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}}
@@ -285,11 +285,11 @@ sections:
title: Adaptation Patterns
template: |
**Layout Changes:** {{layout_adaptations}}
**Navigation Changes:** {{nav_adaptations}}
**Content Priority:** {{content_adaptations}}
**Interaction Changes:** {{interaction_adaptations}}
- id: animation
@@ -323,7 +323,7 @@ sections:
title: Next Steps
instruction: |
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
@@ -346,4 +346,4 @@ sections:
- id: checklist-results
title: Checklist Results
instruction: If a UI/UX checklist exists, run it against this document and report results here.
instruction: If a UI/UX checklist exists, run it against this document and report results here.

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

@@ -19,33 +19,33 @@ sections:
elicit: true
content: |
This document outlines the complete fullstack architecture for {{project_name}}, including backend systems, frontend implementation, and their integration. It serves as the single source of truth for AI-driven development, ensuring consistency across the entire technology stack.
This unified approach combines what would traditionally be separate backend and frontend architecture documents, streamlining the development process for modern fullstack applications where these concerns are increasingly intertwined.
sections:
- id: starter-template
title: Starter Template or Existing Project
instruction: |
Before proceeding with architecture design, check if the project is based on any starter templates or existing codebases:
1. Review the PRD and other documents for mentions of:
- Fullstack starter templates (e.g., T3 Stack, MEAN/MERN starters, Django + React templates)
- Monorepo templates (e.g., Nx, Turborepo starters)
- Platform-specific starters (e.g., Vercel templates, AWS Amplify starters)
- Existing projects being extended or cloned
2. If starter templates or existing projects are mentioned:
- Ask the user to provide access (links, repos, or files)
- Analyze to understand pre-configured choices and constraints
- Note any architectural decisions already made
- Identify what can be modified vs what must be retained
3. If no starter is mentioned but this is greenfield:
- Suggest appropriate fullstack starters based on tech preferences
- Consider platform-specific options (Vercel, AWS, etc.)
- Let user decide whether to use one
4. Document the decision and any constraints it imposes
If none, state "N/A - Greenfield project"
- id: changelog
title: Change Log
@@ -71,17 +71,17 @@ sections:
title: Platform and Infrastructure Choice
instruction: |
Based on PRD requirements and technical assumptions, make a platform recommendation:
1. Consider common patterns (not an exhaustive list, use your own best judgement and search the web as needed for emerging trends):
- **Vercel + Supabase**: For rapid development with Next.js, built-in auth/storage
- **AWS Full Stack**: For enterprise scale with Lambda, API Gateway, S3, Cognito
- **Azure**: For .NET ecosystems or enterprise Microsoft environments
- **Google Cloud**: For ML/AI heavy applications or Google ecosystem integration
2. Present 2-3 viable options with clear pros/cons
3. Make a recommendation with rationale
4. Get explicit user confirmation
Document the choice and key services that will be used.
template: |
**Platform:** {{selected_platform}}
@@ -91,7 +91,7 @@ sections:
title: Repository Structure
instruction: |
Define the repository approach based on PRD requirements and platform choice, explain your rationale or ask questions to the user if unsure:
1. For modern fullstack apps, monorepo is often preferred
2. Consider tooling (Nx, Turborepo, Lerna, npm workspaces)
3. Define package/app boundaries
@@ -113,7 +113,7 @@ sections:
- Databases and storage
- External integrations
- CDN and caching layers
Use appropriate diagram type for clarity.
- id: architectural-patterns
title: Architectural Patterns
@@ -123,7 +123,7 @@ sections:
- Frontend patterns (e.g., Component-based, State management)
- Backend patterns (e.g., Repository, CQRS, Event-driven)
- Integration patterns (e.g., BFF, API Gateway)
For each pattern, provide recommendation and rationale.
repeatable: true
template: "- **{{pattern_name}}:** {{pattern_description}} - _Rationale:_ {{rationale}}"
@@ -137,7 +137,7 @@ sections:
title: Tech Stack
instruction: |
This is the DEFINITIVE technology selection for the entire project. Work with user to finalize all choices. This table is the single source of truth - all development must use these exact versions.
Key areas to cover:
- Frontend and backend languages/frameworks
- Databases and caching
@@ -146,7 +146,7 @@ sections:
- Testing tools for both frontend and backend
- Build and deployment tools
- Monitoring and logging
Upon render, elicit feedback immediately.
elicit: true
sections:
@@ -156,11 +156,29 @@ sections:
columns: [Category, Technology, Version, Purpose, Rationale]
rows:
- ["Frontend Language", "{{fe_language}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Frontend Framework", "{{fe_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["UI Component Library", "{{ui_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- [
"Frontend Framework",
"{{fe_framework}}",
"{{version}}",
"{{purpose}}",
"{{why_chosen}}",
]
- [
"UI Component Library",
"{{ui_library}}",
"{{version}}",
"{{purpose}}",
"{{why_chosen}}",
]
- ["State Management", "{{state_mgmt}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Backend Language", "{{be_language}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Backend Framework", "{{be_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- [
"Backend Framework",
"{{be_framework}}",
"{{version}}",
"{{purpose}}",
"{{why_chosen}}",
]
- ["API Style", "{{api_style}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Database", "{{database}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
- ["Cache", "{{cache}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
@@ -181,14 +199,14 @@ sections:
title: Data Models
instruction: |
Define the core data models/entities that will be shared between frontend and backend:
1. Review PRD requirements and identify key business entities
2. For each model, explain its purpose and relationships
3. Include key attributes and data types
4. Show relationships between models
5. Create TypeScript interfaces that can be shared
6. Discuss design decisions with user
Create a clear conceptual model before moving to database schema.
elicit: true
repeatable: true
@@ -197,7 +215,7 @@ sections:
title: "{{model_name}}"
template: |
**Purpose:** {{model_purpose}}
**Key Attributes:**
- {{attribute_1}}: {{type_1}} - {{description_1}}
- {{attribute_2}}: {{type_2}} - {{description_2}}
@@ -216,7 +234,7 @@ sections:
title: API Specification
instruction: |
Based on the chosen API style from Tech Stack:
1. If REST API, create an OpenAPI 3.0 specification
2. If GraphQL, provide the GraphQL schema
3. If tRPC, show router definitions
@@ -224,7 +242,7 @@ sections:
5. Define request/response schemas based on data models
6. Document authentication requirements
7. Include example requests/responses
Use appropriate format for the chosen API style. If no API (e.g., static site), skip this section.
elicit: true
sections:
@@ -259,7 +277,7 @@ sections:
title: Components
instruction: |
Based on the architectural patterns, tech stack, and data models from above:
1. Identify major logical components/services across the fullstack
2. Consider both frontend and backend components
3. Define clear boundaries and interfaces between components
@@ -268,7 +286,7 @@ sections:
- Key interfaces/APIs exposed
- Dependencies on other components
- Technology specifics based on tech stack choices
5. Create component diagrams where helpful
elicit: true
sections:
@@ -277,13 +295,13 @@ sections:
title: "{{component_name}}"
template: |
**Responsibility:** {{component_description}}
**Key Interfaces:**
- {{interface_1}}
- {{interface_2}}
**Dependencies:** {{dependencies}}
**Technology Stack:** {{component_tech_details}}
- id: component-diagrams
title: Component Diagrams
@@ -300,13 +318,13 @@ sections:
condition: Project requires external API integrations
instruction: |
For each external service integration:
1. Identify APIs needed based on PRD requirements and component design
2. If documentation URLs are unknown, ask user for specifics
3. Document authentication methods and security considerations
4. List specific endpoints that will be used
5. Note any rate limits or usage constraints
If no external APIs are needed, state this explicitly and skip to next section.
elicit: true
repeatable: true
@@ -319,10 +337,10 @@ sections:
- **Base URL(s):** {{api_base_url}}
- **Authentication:** {{auth_method}}
- **Rate Limits:** {{rate_limits}}
**Key Endpoints Used:**
- `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
**Integration Notes:** {{integration_considerations}}
- id: core-workflows
@@ -331,14 +349,14 @@ sections:
mermaid_type: sequence
instruction: |
Illustrate key system workflows using sequence diagrams:
1. Identify critical user journeys from PRD
2. Show component interactions including external APIs
3. Include both frontend and backend flows
4. Include error handling paths
5. Document async operations
6. Create both high-level and detailed diagrams as needed
Focus on workflows that clarify architecture decisions or complex interactions.
elicit: true
@@ -346,13 +364,13 @@ sections:
title: Database Schema
instruction: |
Transform the conceptual data models into concrete database schemas:
1. Use the database type(s) selected in Tech Stack
2. Create schema definitions using appropriate notation
3. Include indexes, constraints, and relationships
4. Consider performance and scalability
5. For NoSQL, show document structures
Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.)
elicit: true
@@ -488,60 +506,60 @@ sections:
type: code
language: plaintext
examples:
- |
{{project-name}}/
├── .github/ # CI/CD workflows
│ └── workflows/
│ ├── ci.yaml
│ └── deploy.yaml
├── apps/ # Application packages
│ ├── web/ # Frontend application
│ │ ├── src/
│ │ │ ├── components/ # UI components
│ │ │ ├── pages/ # Page components/routes
│ │ │ ├── hooks/ # Custom React hooks
│ │ │ ├── services/ # API client services
│ │ │ ├── stores/ # State management
│ │ │ ├── styles/ # Global styles/themes
│ │ │ └── utils/ # Frontend utilities
│ │ ├── public/ # Static assets
│ │ ├── tests/ # Frontend tests
│ │ └── package.json
│ └── api/ # Backend application
│ ├── src/
│ │ ├── routes/ # API routes/controllers
│ │ ├── services/ # Business logic
│ │ ├── models/ # Data models
│ │ ├── middleware/ # Express/API middleware
│ │ ├── utils/ # Backend utilities
│ │ └── {{serverless_or_server_entry}}
│ ├── tests/ # Backend tests
│ └── package.json
├── packages/ # Shared packages
│ ├── shared/ # Shared types/utilities
│ │ ├── src/
│ │ │ ├── types/ # TypeScript interfaces
│ │ │ ├── constants/ # Shared constants
│ │ │ └── utils/ # Shared utilities
│ │ └── package.json
│ ├── ui/ # Shared UI components
│ │ ├── src/
│ │ └── package.json
│ └── config/ # Shared configuration
│ ├── eslint/
│ ├── typescript/
│ └── jest/
├── infrastructure/ # IaC definitions
│ └── {{iac_structure}}
├── scripts/ # Build/deploy scripts
├── docs/ # Documentation
│ ├── prd.md
│ ├── front-end-spec.md
│ └── fullstack-architecture.md
├── .env.example # Environment template
├── package.json # Root package.json
├── {{monorepo_config}} # Monorepo configuration
└── README.md
- |
{{project-name}}/
├── .github/ # CI/CD workflows
│ └── workflows/
│ ├── ci.yaml
│ └── deploy.yaml
├── apps/ # Application packages
│ ├── web/ # Frontend application
│ │ ├── src/
│ │ │ ├── components/ # UI components
│ │ │ ├── pages/ # Page components/routes
│ │ │ ├── hooks/ # Custom React hooks
│ │ │ ├── services/ # API client services
│ │ │ ├── stores/ # State management
│ │ │ ├── styles/ # Global styles/themes
│ │ │ └── utils/ # Frontend utilities
│ │ ├── public/ # Static assets
│ │ ├── tests/ # Frontend tests
│ │ └── package.json
│ └── api/ # Backend application
│ ├── src/
│ │ ├── routes/ # API routes/controllers
│ │ ├── services/ # Business logic
│ │ ├── models/ # Data models
│ │ ├── middleware/ # Express/API middleware
│ │ ├── utils/ # Backend utilities
│ │ └── {{serverless_or_server_entry}}
│ ├── tests/ # Backend tests
│ └── package.json
├── packages/ # Shared packages
│ ├── shared/ # Shared types/utilities
│ │ ├── src/
│ │ │ ├── types/ # TypeScript interfaces
│ │ │ ├── constants/ # Shared constants
│ │ │ └── utils/ # Shared utilities
│ │ └── package.json
│ ├── ui/ # Shared UI components
│ │ ├── src/
│ │ └── package.json
│ └── config/ # Shared configuration
│ ├── eslint/
│ ├── typescript/
│ └── jest/
├── infrastructure/ # IaC definitions
│ └── {{iac_structure}}
├── scripts/ # Build/deploy scripts
├── docs/ # Documentation
│ ├── prd.md
│ ├── front-end-spec.md
│ └── fullstack-architecture.md
├── .env.example # Environment template
├── package.json # Root package.json
├── {{monorepo_config}} # Monorepo configuration
└── README.md
- id: development-workflow
title: Development Workflow
@@ -568,13 +586,13 @@ sections:
template: |
# Start all services
{{start_all_command}}
# Start frontend only
{{start_frontend_command}}
# Start backend only
{{start_backend_command}}
# Run tests
{{test_commands}}
- id: environment-config
@@ -587,10 +605,10 @@ sections:
template: |
# Frontend (.env.local)
{{frontend_env_vars}}
# Backend (.env)
{{backend_env_vars}}
# Shared
{{shared_env_vars}}
@@ -607,7 +625,7 @@ sections:
- **Build Command:** {{frontend_build_command}}
- **Output Directory:** {{frontend_output_dir}}
- **CDN/Edge:** {{cdn_strategy}}
**Backend Deployment:**
- **Platform:** {{backend_deploy_platform}}
- **Build Command:** {{backend_build_command}}
@@ -638,12 +656,12 @@ sections:
- CSP Headers: {{csp_policy}}
- XSS Prevention: {{xss_strategy}}
- Secure Storage: {{storage_strategy}}
**Backend Security:**
- Input Validation: {{validation_approach}}
- Rate Limiting: {{rate_limit_config}}
- CORS Policy: {{cors_config}}
**Authentication Security:**
- Token Storage: {{token_strategy}}
- Session Management: {{session_approach}}
@@ -655,7 +673,7 @@ sections:
- Bundle Size Target: {{bundle_size}}
- Loading Strategy: {{loading_approach}}
- Caching Strategy: {{fe_cache_strategy}}
**Backend Performance:**
- Response Time Target: {{response_target}}
- Database Optimization: {{db_optimization}}
@@ -671,10 +689,10 @@ sections:
type: code
language: text
template: |
E2E Tests
/ \
Integration Tests
/ \
E2E Tests
/ \
Integration Tests
/ \
Frontend Unit Backend Unit
- id: test-organization
title: Test Organization
@@ -793,7 +811,7 @@ sections:
- JavaScript errors
- API response times
- User interactions
**Backend Metrics:**
- Request rate
- Error rate
@@ -802,4 +820,4 @@ sections:
- id: checklist-results
title: Checklist Results Report
instruction: Before running the checklist, offer to output the full architecture document. Once user confirms, execute the architect-checklist and populate results here.
instruction: Before running the checklist, offer to output the full architecture document. Once user confirms, execute the architect-checklist and populate results here.

4
bmad-core/templates/market-research-tmpl.yaml
View File

@@ -130,7 +130,7 @@ sections:
instruction: Map the end-to-end customer experience for primary segments
template: |
For primary customer segment:
1. **Awareness:** {{discovery_process}}
2. **Consideration:** {{evaluation_criteria}}
3. **Purchase:** {{decision_triggers}}
@@ -249,4 +249,4 @@ sections:
instruction: Include any complex calculations or models
- id: additional-analysis
title: C. Additional Analysis
instruction: Any supplementary analysis not included in main body
instruction: Any supplementary analysis not included in main body

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

@@ -56,7 +56,7 @@ sections:
condition: PRD has UX/UI requirements
instruction: |
Capture high-level UI/UX vision to guide Design Architect and to inform story creation. Steps:
1. Pre-fill all subsections with educated guesses based on project context
2. Present the complete rendered section to user
3. Clearly let the user know where assumptions were made
@@ -98,7 +98,7 @@ sections:
title: Technical Assumptions
instruction: |
Gather technical decisions that will guide the Architect. Steps:
1. Check if {root}/data/technical-preferences.yaml or an attached technical-preferences file exists - use it to pre-populate choices
2. Ask user about: languages, frameworks, starter templates, libraries, APIs, deployment targets
3. For unknowns, offer guidance based on project goals and MVP scope
@@ -126,9 +126,9 @@ sections:
title: Epic List
instruction: |
Present a high-level list of all epics for user approval. Each epic should have a title and a short (1 sentence) goal statement. This allows the user to review the overall structure before diving into details.
CRITICAL: Epics MUST be logically sequential following agile best practices:
- Each epic should deliver a significant, end-to-end, fully deployable increment of testable functionality
- Epic 1 must establish foundational project infrastructure (app setup, Git, CI/CD, core services) unless we are adding new functionality to an existing app, while also delivering an initial piece of functionality, even as simple as a health-check route or display of a simple canary page - remember this when we produce the stories for the first epic!
- Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed
@@ -147,11 +147,11 @@ sections:
repeatable: true
instruction: |
After the epic list is approved, present each epic with all its stories and acceptance criteria as a complete review unit.
For each epic provide expanded goal (2-3 sentences describing the objective and value all the stories will achieve).
CRITICAL STORY SEQUENCING REQUIREMENTS:
- Stories within each epic MUST be logically sequential
- Each story should be a "vertical slice" delivering complete functionality aside from early enabler stories for project foundation
- No story should depend on work from a later story or epic
@@ -179,7 +179,7 @@ sections:
repeatable: true
instruction: |
Define clear, comprehensive, and testable acceptance criteria that:
- Precisely define what "done" means from a functional perspective
- Are unambiguous and serve as basis for verification
- Include any critical non-functional requirements from the PRD
@@ -199,4 +199,4 @@ sections:
instruction: This section will contain the prompt for the UX Expert, keep it short and to the point to initiate create architecture mode using this document as input.
- id: architect-prompt
title: Architect Prompt
instruction: This section will contain the prompt for the Architect, keep it short and to the point to initiate create architecture mode using this document as input.
instruction: This section will contain the prompt for the Architect, keep it short and to the point to initiate create architecture mode using this document as input.

8
bmad-core/templates/project-brief-tmpl.yaml
View File

@@ -28,12 +28,12 @@ sections:
- id: introduction
instruction: |
This template guides creation of a comprehensive Project Brief that serves as the foundational input for product development.
Start by asking the user which mode they prefer:
1. **Interactive Mode** - Work through each section collaboratively
2. **YOLO Mode** - Generate complete draft for review and refinement
Before beginning, understand what inputs are available (brainstorming results, market research, competitive analysis, initial ideas) and gather project context.
- id: executive-summary
@@ -218,4 +218,4 @@ sections:
- id: pm-handoff
title: PM Handoff
content: |
This Project Brief provides the full context for {{project_name}}. Please start in 'PRD Generation Mode', review the brief thoroughly to work with the user to create the PRD section by section as the template indicates, asking for any necessary clarification or suggesting improvements.
This Project Brief provides the full context for {{project_name}}. Please start in 'PRD Generation Mode', review the brief thoroughly to work with the user to create the PRD section by section as the template indicates, asking for any necessary clarification or suggesting improvements.

18
bmad-core/templates/qa-gate-tmpl.yaml
View File

@@ -11,8 +11,8 @@ template:
schema: 1
story: "{{epic_num}}.{{story_num}}"
story_title: "{{story_title}}"
gate: "{{gate_status}}" # PASS|CONCERNS|FAIL|WAIVED
status_reason: "{{status_reason}}" # 1-2 sentence summary of why this gate decision
gate: "{{gate_status}}" # PASS|CONCERNS|FAIL|WAIVED
status_reason: "{{status_reason}}" # 1-2 sentence summary of why this gate decision
reviewer: "Quinn (Test Architect)"
updated: "{{iso_timestamp}}"
@@ -41,7 +41,7 @@ examples:
severity: medium
finding: "Missing integration tests for auth flow"
suggested_action: "Add test coverage for critical paths"
when_waived: |
waiver:
active: true
@@ -55,7 +55,7 @@ optional_fields_examples:
quality_and_expiry: |
quality_score: 75 # 0-100 (optional scoring)
expires: "2025-01-26T00:00:00Z" # Optional gate freshness window
evidence: |
evidence:
tests_reviewed: 15
@@ -63,14 +63,14 @@ optional_fields_examples:
trace:
ac_covered: [1, 2, 3] # AC numbers with test coverage
ac_gaps: [4] # AC numbers lacking coverage
nfr_validation: |
nfr_validation:
security: { status: CONCERNS, notes: "Rate limiting missing" }
performance: { status: PASS, notes: "" }
reliability: { status: PASS, notes: "" }
maintainability: { status: PASS, notes: "" }
history: |
history: # Append-only audit trail
- at: "2025-01-12T10:00:00Z"
@@ -79,7 +79,7 @@ optional_fields_examples:
- at: "2025-01-12T15:00:00Z"
gate: CONCERNS
note: "Tests added but rate limiting still missing"
risk_summary: |
risk_summary: # From risk-profile task
totals:
@@ -91,7 +91,7 @@ optional_fields_examples:
recommendations:
must_fix: []
monitor: []
recommendations: |
recommendations:
immediate: # Must fix before production
@@ -99,4 +99,4 @@ optional_fields_examples:
refs: ["api/auth/login.ts:42-68"]
future: # Can be addressed later
- action: "Consider caching for better performance"
refs: ["services/data.service.ts"]
refs: ["services/data.service.ts"]

24
bmad-core/templates/story-tmpl.yaml
View File

@@ -12,7 +12,7 @@ workflow:
elicitation: advanced-elicitation
agent_config:
editable_sections:
editable_sections:
- Status
- Story
- Acceptance Criteria
@@ -29,7 +29,7 @@ sections:
instruction: Select the current status of the story
owner: scrum-master
editors: [scrum-master, dev-agent]
- id: story
title: Story
type: template-text
@@ -41,7 +41,7 @@ sections:
elicit: true
owner: scrum-master
editors: [scrum-master]
- id: acceptance-criteria
title: Acceptance Criteria
type: numbered-list
@@ -49,7 +49,7 @@ sections:
elicit: true
owner: scrum-master
editors: [scrum-master]
- id: tasks-subtasks
title: Tasks / Subtasks
type: bullet-list
@@ -66,7 +66,7 @@ sections:
elicit: true
owner: scrum-master
editors: [scrum-master, dev-agent]
- id: dev-notes
title: Dev Notes
instruction: |
@@ -90,7 +90,7 @@ sections:
elicit: true
owner: scrum-master
editors: [scrum-master]
- id: change-log
title: Change Log
type: table
@@ -98,7 +98,7 @@ sections:
instruction: Track changes made to this story document
owner: scrum-master
editors: [scrum-master, dev-agent, qa-agent]
- id: dev-agent-record
title: Dev Agent Record
instruction: This section is populated by the development agent during implementation
@@ -111,27 +111,27 @@ sections:
instruction: Record the specific AI agent model and version used for development
owner: dev-agent
editors: [dev-agent]
- id: debug-log-references
title: Debug Log References
instruction: Reference any debug logs or traces generated during development
owner: dev-agent
editors: [dev-agent]
- id: completion-notes
title: Completion Notes List
instruction: Notes about the completion of tasks and any issues encountered
owner: dev-agent
editors: [dev-agent]
- id: file-list
title: File List
instruction: List all files created, modified, or affected during story implementation
owner: dev-agent
editors: [dev-agent]
- id: qa-results
title: QA Results
instruction: Results from QA Agent QA review of the completed story implementation
owner: qa-agent
editors: [qa-agent]
editors: [qa-agent]

18
bmad-core/workflows/brownfield-fullstack.yaml
View File

@@ -20,7 +20,7 @@ workflow:
- Single story (< 4 hours) → Use brownfield-create-story task
- Small feature (1-3 stories) → Use brownfield-create-epic task
- Major enhancement (multiple epics) → Continue with full workflow
Ask user: "Can you describe the enhancement scope? Is this a small fix, a feature addition, or a major enhancement requiring architectural changes?"
- step: routing_decision
@@ -181,7 +181,7 @@ workflow:
notes: |
All stories implemented and reviewed!
Project development phase complete.
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
flow_diagram: |
@@ -265,33 +265,33 @@ workflow:
{{if single_story}}: Proceeding with brownfield-create-story task for immediate implementation.
{{if small_feature}}: Creating focused epic with brownfield-create-epic task.
{{if major_enhancement}}: Continuing with comprehensive planning workflow.
documentation_assessment: |
Documentation assessment complete:
{{if adequate}}: Existing documentation is sufficient. Proceeding directly to PRD creation.
{{if inadequate}}: Running document-project to capture current system state before PRD.
document_project_to_pm: |
Project analysis complete. Key findings documented in:
- {{document_list}}
Use these findings to inform PRD creation and avoid re-analyzing the same aspects.
pm_to_architect_decision: |
PRD complete and saved as docs/prd.md.
Architectural changes identified: {{yes/no}}
{{if yes}}: Proceeding to create architecture document for: {{specific_changes}}
{{if no}}: No architectural changes needed. Proceeding to validation.
architect_to_po: "Architecture complete. Save it as docs/architecture.md. Please validate all artifacts for integration safety."
po_to_sm: |
All artifacts validated.
Documentation type available: {{sharded_prd / brownfield_docs}}
{{if sharded}}: Use standard create-next-story task.
{{if brownfield}}: Use create-brownfield-story task to handle varied documentation formats.
sm_story_creation: |
Creating story from {{documentation_type}}.
{{if missing_context}}: May need to gather additional context from user during story creation.
complete: "All planning artifacts validated and development can begin. Stories will be created based on available documentation format."

2
bmad-core/workflows/brownfield-service.yaml
View File

@@ -127,7 +127,7 @@ workflow:
notes: |
All stories implemented and reviewed!
Project development phase complete.
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
flow_diagram: |

2
bmad-core/workflows/brownfield-ui.yaml
View File

@@ -134,7 +134,7 @@ workflow:
notes: |
All stories implemented and reviewed!
Project development phase complete.
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
flow_diagram: |

2
bmad-core/workflows/greenfield-fullstack.yaml
View File

@@ -159,7 +159,7 @@ workflow:
notes: |
All stories implemented and reviewed!
Project development phase complete.
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
flow_diagram: |

2
bmad-core/workflows/greenfield-service.yaml
View File

@@ -135,7 +135,7 @@ workflow:
notes: |
All stories implemented and reviewed!
Service development phase complete.
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
flow_diagram: |

2
bmad-core/workflows/greenfield-ui.yaml
View File

@@ -154,7 +154,7 @@ workflow:
notes: |
All stories implemented and reviewed!
Project development phase complete.
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
flow_diagram: |