bmad-method 4.27.3 → 4.27.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +14 -0
- package/CONTRIBUTING.md +2 -2
- package/bmad-core/agents/bmad-master.md +0 -2
- package/bmad-core/agents/bmad-orchestrator.md +0 -1
- package/bmad-core/data/bmad-kb.md +5 -12
- package/dist/agents/analyst.txt +2 -9
- package/dist/agents/architect.txt +3 -11
- package/dist/agents/bmad-master.txt +8 -53
- package/dist/agents/bmad-orchestrator.txt +2 -39
- package/dist/agents/pm.txt +3 -3
- package/dist/expansion-packs/bmad-2d-phaser-game-dev/teams/phaser-2d-nodejs-game-team.txt +0 -30
- package/dist/teams/team-all.txt +8 -53
- package/dist/teams/team-fullstack.txt +8 -53
- package/dist/teams/team-ide-minimal.txt +2 -39
- package/dist/teams/team-no-ui.txt +8 -53
- package/{GUIDING-PRINCIPLES.md → docs/GUIDING-PRINCIPLES.md} +19 -13
- package/docs/template-markup-references.md +86 -0
- package/expansion-packs/bmad-infrastructure-devops/data/bmad-kb.md +307 -2
- package/package.json +1 -1
- package/tools/installer/bin/bmad.js +83 -0
- package/tools/installer/lib/file-manager.js +28 -0
- package/tools/installer/lib/ide-setup.js +41 -33
- package/tools/installer/lib/installer.js +8 -1
- package/tools/installer/package.json +1 -1
- package/common/utils/template-format.md +0 -26
|
@@ -186,7 +186,6 @@ dependencies:
|
|
|
186
186
|
utils:
|
|
187
187
|
- plan-management.md
|
|
188
188
|
- workflow-management.md
|
|
189
|
-
- template-format.md
|
|
190
189
|
```
|
|
191
190
|
==================== END: .bmad-core/agents/bmad-orchestrator.md ====================
|
|
192
191
|
|
|
@@ -1623,17 +1622,10 @@ The BMad-Method is built around a modular architecture centered on the `bmad-cor
|
|
|
1623
1622
|
|
|
1624
1623
|
BMad employs a sophisticated template system with three key components:
|
|
1625
1624
|
|
|
1626
|
-
1. **Template Format** (`utils/template
|
|
1627
|
-
2. **Document Creation** (`tasks/create-doc.md`): Orchestrates template selection and user interaction
|
|
1625
|
+
1. **Template Format** (`utils/bmad-doc-template.md`): Defines markup language for variable substitution and AI processing directives from yaml templates
|
|
1626
|
+
2. **Document Creation** (`tasks/create-doc.md`): Orchestrates template selection and user interaction to transform yaml spec to final markdown output
|
|
1628
1627
|
3. **Advanced Elicitation** (`tasks/advanced-elicitation.md`): Provides interactive refinement through structured brainstorming
|
|
1629
1628
|
|
|
1630
|
-
**Template Features**:
|
|
1631
|
-
|
|
1632
|
-
- **Self-contained**: Templates embed both output structure and processing instructions
|
|
1633
|
-
- **Variable Substitution**: `{{placeholders}}` for dynamic content
|
|
1634
|
-
- **AI Processing Directives**: `[[LLM: instructions]]` for AI-only processing
|
|
1635
|
-
- **Interactive Refinement**: Built-in elicitation processes for quality improvement
|
|
1636
|
-
|
|
1637
1629
|
### Technical Preferences Integration
|
|
1638
1630
|
|
|
1639
1631
|
The `technical-preferences.md` file serves as a persistent technical profile that:
|
|
@@ -2461,35 +2453,6 @@ Handle conditional paths by asking clarifying questions when needed.
|
|
|
2461
2453
|
Agents should be workflow-aware: know active workflow, their role, access artifacts, understand expected outputs.
|
|
2462
2454
|
==================== END: .bmad-core/utils/workflow-management.md ====================
|
|
2463
2455
|
|
|
2464
|
-
==================== START: .bmad-core/utils/template-format.md ====================
|
|
2465
|
-
# Template Format Conventions
|
|
2466
|
-
|
|
2467
|
-
Templates in the BMad method use standardized markup for AI processing. These conventions ensure consistent document generation.
|
|
2468
|
-
|
|
2469
|
-
## Template Markup Elements
|
|
2470
|
-
|
|
2471
|
-
- **{{placeholders}}**: Variables to be replaced with actual content
|
|
2472
|
-
- **[[LLM: instructions]]**: Internal processing instructions for AI agents (never shown to users)
|
|
2473
|
-
- **REPEAT** sections: Content blocks that may be repeated as needed
|
|
2474
|
-
- **^^CONDITION^^** blocks: Conditional content included only if criteria are met
|
|
2475
|
-
- **@{examples}**: Example content for guidance (never output to users)
|
|
2476
|
-
|
|
2477
|
-
## Processing Rules
|
|
2478
|
-
|
|
2479
|
-
- Replace all {{placeholders}} with project-specific content
|
|
2480
|
-
- Execute all [[LLM: instructions]] internally without showing users
|
|
2481
|
-
- Process conditional and repeat blocks as specified
|
|
2482
|
-
- Use examples for guidance but never include them in final output
|
|
2483
|
-
- Present only clean, formatted content to users
|
|
2484
|
-
|
|
2485
|
-
## Critical Guidelines
|
|
2486
|
-
|
|
2487
|
-
- **NEVER display template markup, LLM instructions, or examples to users**
|
|
2488
|
-
- Template elements are for AI processing only
|
|
2489
|
-
- Focus on faithful template execution and clean output
|
|
2490
|
-
- All template-specific instructions are embedded within templates
|
|
2491
|
-
==================== END: .bmad-core/utils/template-format.md ====================
|
|
2492
|
-
|
|
2493
2456
|
==================== START: .bmad-core/tasks/execute-checklist.md ====================
|
|
2494
2457
|
# Checklist Validation Task
|
|
2495
2458
|
|
|
@@ -189,7 +189,6 @@ dependencies:
|
|
|
189
189
|
utils:
|
|
190
190
|
- plan-management.md
|
|
191
191
|
- workflow-management.md
|
|
192
|
-
- template-format.md
|
|
193
192
|
```
|
|
194
193
|
==================== END: .bmad-core/agents/bmad-orchestrator.md ====================
|
|
195
194
|
|
|
@@ -1666,17 +1665,10 @@ The BMad-Method is built around a modular architecture centered on the `bmad-cor
|
|
|
1666
1665
|
|
|
1667
1666
|
BMad employs a sophisticated template system with three key components:
|
|
1668
1667
|
|
|
1669
|
-
1. **Template Format** (`utils/template
|
|
1670
|
-
2. **Document Creation** (`tasks/create-doc.md`): Orchestrates template selection and user interaction
|
|
1668
|
+
1. **Template Format** (`utils/bmad-doc-template.md`): Defines markup language for variable substitution and AI processing directives from yaml templates
|
|
1669
|
+
2. **Document Creation** (`tasks/create-doc.md`): Orchestrates template selection and user interaction to transform yaml spec to final markdown output
|
|
1671
1670
|
3. **Advanced Elicitation** (`tasks/advanced-elicitation.md`): Provides interactive refinement through structured brainstorming
|
|
1672
1671
|
|
|
1673
|
-
**Template Features**:
|
|
1674
|
-
|
|
1675
|
-
- **Self-contained**: Templates embed both output structure and processing instructions
|
|
1676
|
-
- **Variable Substitution**: `{{placeholders}}` for dynamic content
|
|
1677
|
-
- **AI Processing Directives**: `[[LLM: instructions]]` for AI-only processing
|
|
1678
|
-
- **Interactive Refinement**: Built-in elicitation processes for quality improvement
|
|
1679
|
-
|
|
1680
1672
|
### Technical Preferences Integration
|
|
1681
1673
|
|
|
1682
1674
|
The `technical-preferences.md` file serves as a persistent technical profile that:
|
|
@@ -2504,35 +2496,6 @@ Handle conditional paths by asking clarifying questions when needed.
|
|
|
2504
2496
|
Agents should be workflow-aware: know active workflow, their role, access artifacts, understand expected outputs.
|
|
2505
2497
|
==================== END: .bmad-core/utils/workflow-management.md ====================
|
|
2506
2498
|
|
|
2507
|
-
==================== START: .bmad-core/utils/template-format.md ====================
|
|
2508
|
-
# Template Format Conventions
|
|
2509
|
-
|
|
2510
|
-
Templates in the BMad method use standardized markup for AI processing. These conventions ensure consistent document generation.
|
|
2511
|
-
|
|
2512
|
-
## Template Markup Elements
|
|
2513
|
-
|
|
2514
|
-
- **{{placeholders}}**: Variables to be replaced with actual content
|
|
2515
|
-
- **[[LLM: instructions]]**: Internal processing instructions for AI agents (never shown to users)
|
|
2516
|
-
- **REPEAT** sections: Content blocks that may be repeated as needed
|
|
2517
|
-
- **^^CONDITION^^** blocks: Conditional content included only if criteria are met
|
|
2518
|
-
- **@{examples}**: Example content for guidance (never output to users)
|
|
2519
|
-
|
|
2520
|
-
## Processing Rules
|
|
2521
|
-
|
|
2522
|
-
- Replace all {{placeholders}} with project-specific content
|
|
2523
|
-
- Execute all [[LLM: instructions]] internally without showing users
|
|
2524
|
-
- Process conditional and repeat blocks as specified
|
|
2525
|
-
- Use examples for guidance but never include them in final output
|
|
2526
|
-
- Present only clean, formatted content to users
|
|
2527
|
-
|
|
2528
|
-
## Critical Guidelines
|
|
2529
|
-
|
|
2530
|
-
- **NEVER display template markup, LLM instructions, or examples to users**
|
|
2531
|
-
- Template elements are for AI processing only
|
|
2532
|
-
- Focus on faithful template execution and clean output
|
|
2533
|
-
- All template-specific instructions are embedded within templates
|
|
2534
|
-
==================== END: .bmad-core/utils/template-format.md ====================
|
|
2535
|
-
|
|
2536
2499
|
==================== START: .bmad-core/tasks/facilitate-brainstorming-session.md ====================
|
|
2537
2500
|
---
|
|
2538
2501
|
docOutputLocation: docs/brainstorming-session-results.md
|
|
@@ -5145,9 +5108,9 @@ sections:
|
|
|
5145
5108
|
- id: next-steps
|
|
5146
5109
|
title: Next Steps
|
|
5147
5110
|
sections:
|
|
5148
|
-
- id:
|
|
5149
|
-
title:
|
|
5150
|
-
instruction: This section will contain the prompt for the
|
|
5111
|
+
- id: ux-expert-prompt
|
|
5112
|
+
title: UX Expert Prompt
|
|
5113
|
+
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.
|
|
5151
5114
|
- id: architect-prompt
|
|
5152
5115
|
title: Architect Prompt
|
|
5153
5116
|
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.
|
|
@@ -6637,7 +6600,6 @@ sections:
|
|
|
6637
6600
|
After completing the architecture:
|
|
6638
6601
|
|
|
6639
6602
|
1. If project has UI components:
|
|
6640
|
-
- Recommend engaging Design Architect agent
|
|
6641
6603
|
- Use "Frontend Architecture Mode"
|
|
6642
6604
|
- Provide this document as input
|
|
6643
6605
|
|
|
@@ -6648,22 +6610,15 @@ sections:
|
|
|
6648
6610
|
|
|
6649
6611
|
3. Include specific prompts for next agents if needed
|
|
6650
6612
|
sections:
|
|
6651
|
-
- id:
|
|
6652
|
-
title:
|
|
6613
|
+
- id: architect-prompt
|
|
6614
|
+
title: Architect Prompt
|
|
6653
6615
|
condition: Project has UI components
|
|
6654
6616
|
instruction: |
|
|
6655
|
-
Create a brief prompt to hand off to
|
|
6617
|
+
Create a brief prompt to hand off to Architect for Frontend Architecture creation. Include:
|
|
6656
6618
|
- Reference to this architecture document
|
|
6657
6619
|
- Key UI requirements from PRD
|
|
6658
6620
|
- Any frontend-specific decisions made here
|
|
6659
6621
|
- Request for detailed frontend architecture
|
|
6660
|
-
- id: developer-handoff
|
|
6661
|
-
title: Developer Handoff
|
|
6662
|
-
instruction: |
|
|
6663
|
-
Create a brief prompt for developers starting implementation. Include:
|
|
6664
|
-
- Reference to this architecture and coding standards
|
|
6665
|
-
- First epic/story to implement
|
|
6666
|
-
- Key technical decisions to follow
|
|
6667
6622
|
==================== END: .bmad-core/templates/architecture-tmpl.yaml ====================
|
|
6668
6623
|
|
|
6669
6624
|
==================== START: .bmad-core/templates/front-end-architecture-tmpl.yaml ====================
|
|
@@ -15,7 +15,7 @@ The BMad Method is a natural language framework for AI-assisted software develop
|
|
|
15
15
|
|
|
16
16
|
- **Everything is markdown**: Agents, tasks, templates - all written in plain English
|
|
17
17
|
- **No code in core**: The framework itself contains no programming code, only natural language instructions
|
|
18
|
-
- **Self-contained templates**: Templates include
|
|
18
|
+
- **Self-contained templates**: Templates are defined as YAML files with structured sections that include metadata, workflow configuration, and detailed instructions for content generation
|
|
19
19
|
|
|
20
20
|
### 3. Agent and Task Design
|
|
21
21
|
|
|
@@ -60,22 +60,28 @@ See [Expansion Packs Guide](../docs/expansion-packs.md) for detailed examples an
|
|
|
60
60
|
- This keeps context overhead minimal
|
|
61
61
|
6. **Reuse common tasks** - Don't create new document creation tasks
|
|
62
62
|
- Use the existing `create-doc` task
|
|
63
|
-
- Pass the appropriate template with
|
|
63
|
+
- Pass the appropriate YAML template with structured sections
|
|
64
64
|
- This maintains consistency and reduces duplication
|
|
65
65
|
|
|
66
66
|
### Template Rules
|
|
67
67
|
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
- `
|
|
75
|
-
-
|
|
76
|
-
-
|
|
77
|
-
|
|
78
|
-
|
|
68
|
+
Templates follow the [BMad Document Template](common/utils/bmad-doc-template.md) specification using YAML format:
|
|
69
|
+
|
|
70
|
+
1. **Structure**: Templates are defined in YAML with clear metadata, workflow configuration, and section hierarchy
|
|
71
|
+
2. **Separation of Concerns**: Instructions for LLMs are in `instruction` fields, separate from content
|
|
72
|
+
3. **Reusability**: Templates are agent-agnostic and can be used across different agents
|
|
73
|
+
4. **Key Components**:
|
|
74
|
+
- `template` block for metadata (id, name, version, output settings)
|
|
75
|
+
- `workflow` block for interaction mode configuration
|
|
76
|
+
- `sections` array defining document structure with nested subsections
|
|
77
|
+
- Each section has `id`, `title`, and `instruction` fields
|
|
78
|
+
5. **Advanced Features**:
|
|
79
|
+
- Variable substitution using `{{variable_name}}` syntax
|
|
80
|
+
- Conditional sections with `condition` field
|
|
81
|
+
- Repeatable sections with `repeatable: true`
|
|
82
|
+
- Agent permissions with `owner` and `editors` fields
|
|
83
|
+
- Examples arrays for guidance (never included in output)
|
|
84
|
+
6. **Clean Output**: YAML structure ensures all processing logic stays separate from generated content
|
|
79
85
|
|
|
80
86
|
## Remember
|
|
81
87
|
|
|
@@ -0,0 +1,86 @@
|
|
|
1
|
+
# Old Template Markup System References
|
|
2
|
+
|
|
3
|
+
This document catalogs all references to the old template markup system found in the BMAD-METHOD documentation and codebase.
|
|
4
|
+
|
|
5
|
+
## Summary of Old Markup Patterns
|
|
6
|
+
|
|
7
|
+
The old template markup system used the following patterns:
|
|
8
|
+
|
|
9
|
+
- `[[LLM: ...]]` - LLM-only processing directives
|
|
10
|
+
- `{{placeholders}}` - Variable substitution
|
|
11
|
+
- `<<REPEAT section="name">>` - Repeatable sections
|
|
12
|
+
- `^^CONDITION: condition_name^^` - Conditional blocks
|
|
13
|
+
- `@{examples}` - Example content markers
|
|
14
|
+
|
|
15
|
+
## Files Containing References
|
|
16
|
+
|
|
17
|
+
### 1. Primary Documentation Files
|
|
18
|
+
|
|
19
|
+
#### `/Users/brianmadison/dev-bmc/BMAD-METHOD/docs/user-guide.md`
|
|
20
|
+
|
|
21
|
+
- **Lines 149-155**: Describes template structure with placeholders and LLM instructions
|
|
22
|
+
- **Lines 229-230**: References advanced elicitation with embedded LLM instructions
|
|
23
|
+
- **Lines 527-549**: Shows custom template creation with LLM instructions and placeholders
|
|
24
|
+
- **Lines 590-632**: Detailed template patterns including variables, AI processing, and conditionals
|
|
25
|
+
- **Lines 619-623**: References to `@{example}` patterns and `[[LLM:]]` instructions
|
|
26
|
+
|
|
27
|
+
#### `/Users/brianmadison/dev-bmc/BMAD-METHOD/docs/core-architecture.md`
|
|
28
|
+
|
|
29
|
+
- **Lines 93-104**: Describes templates as self-contained with embedded LLM instructions
|
|
30
|
+
- **Lines 97-104**: Mentions template-format.md specification with placeholders and LLM directives
|
|
31
|
+
|
|
32
|
+
#### `/Users/brianmadison/dev-bmc/BMAD-METHOD/CLAUDE.md`
|
|
33
|
+
|
|
34
|
+
- **Lines 37, 262**: References to template instructions using `[[LLM: ...]]` markup
|
|
35
|
+
- **Line 38**: Mentions templates with embedded LLM instructions
|
|
36
|
+
|
|
37
|
+
### 2. Common Utilities
|
|
38
|
+
|
|
39
|
+
#### `/Users/brianmadison/dev-bmc/BMAD-METHOD/common/utils/bmad-doc-template.md`
|
|
40
|
+
|
|
41
|
+
- **Lines 296-324**: Migration section describes converting from legacy markdown+frontmatter templates
|
|
42
|
+
- **Lines 319-323**: Specific conversion instructions for old markup patterns
|
|
43
|
+
|
|
44
|
+
### 3. Task Files
|
|
45
|
+
|
|
46
|
+
#### `/Users/brianmadison/dev-bmc/BMAD-METHOD/bmad-core/tasks/shard-doc.md`
|
|
47
|
+
|
|
48
|
+
- **Lines 11-30**: Contains LLM instructions embedded in the task
|
|
49
|
+
- **Line 160**: References preserving template markup including `{{placeholders}}` and `[[LLM instructions]]`
|
|
50
|
+
|
|
51
|
+
#### `/Users/brianmadison/dev-bmc/BMAD-METHOD/expansion-packs/bmad-creator-tools/tasks/generate-expansion-pack.md`
|
|
52
|
+
|
|
53
|
+
- **Lines 10-14**: Describes template systems with LLM instruction embedding
|
|
54
|
+
- **Lines 107-118**: Template section planning with LLM instructions
|
|
55
|
+
- **Lines 229-245**: Detailed LLM instruction patterns for templates
|
|
56
|
+
- **Lines 569-593**: Advanced template design patterns
|
|
57
|
+
- **Lines 229, 573**: Specific examples of `[[LLM:]]` usage
|
|
58
|
+
- **Line 574**: References conditional content with `^^CONDITION:^^`
|
|
59
|
+
- **Line 576**: Mentions iteration controls with `<<REPEAT>>`
|
|
60
|
+
|
|
61
|
+
### 4. Agent and Template Files
|
|
62
|
+
|
|
63
|
+
Multiple agent and task files contain actual usage of the old markup system (22 files found with `[[LLM:]]` patterns), including:
|
|
64
|
+
|
|
65
|
+
- Story templates
|
|
66
|
+
- Checklists
|
|
67
|
+
- Task definitions
|
|
68
|
+
- Workflow plans
|
|
69
|
+
|
|
70
|
+
## Key Observations
|
|
71
|
+
|
|
72
|
+
1. **Documentation vs Implementation**: The documentation heavily references the old markup system, while the new YAML-based template system (`bmad-doc-template.md`) is already defined but not yet reflected in the main documentation.
|
|
73
|
+
|
|
74
|
+
2. **Migration Path**: The `bmad-doc-template.md` file includes a migration section (lines 316-324) that explicitly maps old patterns to new YAML structures.
|
|
75
|
+
|
|
76
|
+
3. **Active Usage**: Many core tasks and templates still actively use the old markup patterns, particularly `[[LLM:]]` instructions embedded within markdown files.
|
|
77
|
+
|
|
78
|
+
4. **Inconsistency**: Some files reference a `template-format.md` file that doesn't exist in the expected locations, suggesting incomplete migration or documentation updates.
|
|
79
|
+
|
|
80
|
+
## Recommendations
|
|
81
|
+
|
|
82
|
+
1. **Update User Guide**: The user guide needs significant updates to reflect the new YAML-based template system
|
|
83
|
+
2. **Update Core Architecture Docs**: Remove references to embedded LLM instructions in templates
|
|
84
|
+
3. **Create Template Migration Guide**: A comprehensive guide for converting existing templates
|
|
85
|
+
4. **Update Extension Pack Documentation**: The bmad-creator-tools expansion pack documentation needs updates
|
|
86
|
+
5. **Audit Active Templates**: Review and migrate templates that still use the old markup system
|
|
@@ -1,3 +1,308 @@
|
|
|
1
|
-
#
|
|
1
|
+
# BMad Infrastructure DevOps Expansion Pack Knowledge Base
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
## Overview
|
|
4
|
+
|
|
5
|
+
The BMad Infrastructure DevOps expansion pack extends the BMad Method framework with comprehensive infrastructure and DevOps capabilities. It enables teams to design, implement, validate, and maintain modern cloud-native infrastructure alongside their application development efforts.
|
|
6
|
+
|
|
7
|
+
**Version**: 1.7.0
|
|
8
|
+
**BMad Compatibility**: v4+
|
|
9
|
+
**Author**: Brian (BMad)
|
|
10
|
+
|
|
11
|
+
## Core Purpose
|
|
12
|
+
|
|
13
|
+
This expansion pack addresses the critical need for systematic infrastructure planning and implementation in modern software projects. It provides:
|
|
14
|
+
|
|
15
|
+
- Structured approach to infrastructure architecture design
|
|
16
|
+
- Platform engineering implementation guidance
|
|
17
|
+
- Comprehensive validation and review processes
|
|
18
|
+
- Integration with core BMad development workflows
|
|
19
|
+
- Support for cloud-native and traditional infrastructure patterns
|
|
20
|
+
|
|
21
|
+
## When to Use This Expansion Pack
|
|
22
|
+
|
|
23
|
+
Use the BMad Infrastructure DevOps expansion pack when your project involves:
|
|
24
|
+
|
|
25
|
+
- **Cloud Infrastructure Design**: AWS, Azure, GCP, or multi-cloud architectures
|
|
26
|
+
- **Kubernetes and Container Orchestration**: Container platform design and implementation
|
|
27
|
+
- **Infrastructure as Code**: Terraform, CloudFormation, Pulumi implementations
|
|
28
|
+
- **GitOps Workflows**: ArgoCD, Flux, or similar continuous deployment patterns
|
|
29
|
+
- **Platform Engineering**: Building internal developer platforms and self-service capabilities
|
|
30
|
+
- **Service Mesh Implementation**: Istio, Linkerd, or similar service mesh architectures
|
|
31
|
+
- **DevOps Transformation**: Establishing or improving DevOps practices and culture
|
|
32
|
+
|
|
33
|
+
## Key Components
|
|
34
|
+
|
|
35
|
+
### 1. DevOps Agent: Alex
|
|
36
|
+
|
|
37
|
+
**Role**: DevOps Infrastructure Specialist
|
|
38
|
+
**Experience**: 15+ years in infrastructure and platform engineering
|
|
39
|
+
|
|
40
|
+
**Core Principles**:
|
|
41
|
+
|
|
42
|
+
- Infrastructure as Code (IaC) First
|
|
43
|
+
- Automation and Repeatability
|
|
44
|
+
- Reliability and Scalability
|
|
45
|
+
- Security by Design
|
|
46
|
+
- Cost Optimization
|
|
47
|
+
- Developer Experience Focus
|
|
48
|
+
|
|
49
|
+
**Commands**:
|
|
50
|
+
|
|
51
|
+
- `*help` - Display available commands and capabilities
|
|
52
|
+
- `*chat-mode` - Interactive conversation mode for infrastructure discussions
|
|
53
|
+
- `*create-doc` - Generate infrastructure documentation from templates
|
|
54
|
+
- `*review-infrastructure` - Conduct systematic infrastructure review
|
|
55
|
+
- `*validate-infrastructure` - Validate infrastructure against comprehensive checklist
|
|
56
|
+
- `*checklist` - Access the 16-section infrastructure validation checklist
|
|
57
|
+
- `*exit` - Return to normal context
|
|
58
|
+
|
|
59
|
+
### 2. Infrastructure Templates
|
|
60
|
+
|
|
61
|
+
#### Infrastructure Architecture Template
|
|
62
|
+
|
|
63
|
+
**Purpose**: Design comprehensive infrastructure architecture
|
|
64
|
+
**Key Sections**:
|
|
65
|
+
|
|
66
|
+
- Infrastructure Overview (providers, regions, environments)
|
|
67
|
+
- Infrastructure as Code approach and tooling
|
|
68
|
+
- Network Architecture with visual diagrams
|
|
69
|
+
- Compute Resources planning
|
|
70
|
+
- Security Architecture design
|
|
71
|
+
- Monitoring and Observability strategy
|
|
72
|
+
- CI/CD Pipeline architecture
|
|
73
|
+
- Disaster Recovery planning
|
|
74
|
+
- BMad Integration points
|
|
75
|
+
|
|
76
|
+
#### Platform Implementation Template
|
|
77
|
+
|
|
78
|
+
**Purpose**: Implement platform infrastructure based on approved architecture
|
|
79
|
+
**Key Sections**:
|
|
80
|
+
|
|
81
|
+
- Foundation Infrastructure Layer
|
|
82
|
+
- Container Platform (Kubernetes) setup
|
|
83
|
+
- GitOps Workflow implementation
|
|
84
|
+
- Service Mesh configuration
|
|
85
|
+
- Developer Experience Platform
|
|
86
|
+
- Security hardening procedures
|
|
87
|
+
- Platform validation and testing
|
|
88
|
+
|
|
89
|
+
### 3. Tasks
|
|
90
|
+
|
|
91
|
+
#### Review Infrastructure Task
|
|
92
|
+
|
|
93
|
+
**Purpose**: Systematic infrastructure review process
|
|
94
|
+
**Features**:
|
|
95
|
+
|
|
96
|
+
- Incremental or rapid assessment modes
|
|
97
|
+
- Architectural escalation for complex issues
|
|
98
|
+
- Advanced elicitation for deep analysis
|
|
99
|
+
- Prioritized findings and recommendations
|
|
100
|
+
- Integration with BMad Architecture phase
|
|
101
|
+
|
|
102
|
+
#### Validate Infrastructure Task
|
|
103
|
+
|
|
104
|
+
**Purpose**: Comprehensive infrastructure validation
|
|
105
|
+
**Features**:
|
|
106
|
+
|
|
107
|
+
- 16-section validation checklist
|
|
108
|
+
- Architecture Design Review Gate
|
|
109
|
+
- Compliance percentage tracking
|
|
110
|
+
- Remediation planning
|
|
111
|
+
- BMad integration assessment
|
|
112
|
+
|
|
113
|
+
### 4. Infrastructure Validation Checklist
|
|
114
|
+
|
|
115
|
+
A comprehensive 16-section checklist covering:
|
|
116
|
+
|
|
117
|
+
**Foundation Infrastructure (Sections 1-12)**:
|
|
118
|
+
|
|
119
|
+
1. Security Foundation - IAM, encryption, compliance
|
|
120
|
+
2. Infrastructure as Code - Version control, testing, documentation
|
|
121
|
+
3. Resilience & High Availability - Multi-AZ, failover, SLAs
|
|
122
|
+
4. Backup & Disaster Recovery - Strategies, testing, RTO/RPO
|
|
123
|
+
5. Monitoring & Observability - Metrics, logging, alerting
|
|
124
|
+
6. Performance & Scalability - Auto-scaling, load testing
|
|
125
|
+
7. Infrastructure Operations - Patching, maintenance, runbooks
|
|
126
|
+
8. CI/CD Infrastructure - Pipelines, environments, deployments
|
|
127
|
+
9. Networking & Connectivity - Architecture, security, DNS
|
|
128
|
+
10. Compliance & Governance - Standards, auditing, policies
|
|
129
|
+
11. BMad Integration - Agent support, workflow alignment
|
|
130
|
+
12. Architecture Documentation - Diagrams, decisions, maintenance
|
|
131
|
+
|
|
132
|
+
**Platform Engineering (Sections 13-16)**: 13. Container Platform - Kubernetes setup, RBAC, networking 14. GitOps Workflows - Repository structure, deployment patterns 15. Service Mesh - Traffic management, security, observability 16. Developer Experience - Self-service, documentation, tooling
|
|
133
|
+
|
|
134
|
+
## Integration with BMad Flow
|
|
135
|
+
|
|
136
|
+
### Workflow Integration Points
|
|
137
|
+
|
|
138
|
+
1. **After Architecture Phase**: Infrastructure design begins after application architecture is defined
|
|
139
|
+
2. **Parallel to Development**: Infrastructure implementation runs alongside application development
|
|
140
|
+
3. **Before Production**: Infrastructure validation gates before production deployment
|
|
141
|
+
4. **Continuous Operation**: Ongoing infrastructure reviews and improvements
|
|
142
|
+
|
|
143
|
+
### Agent Collaboration
|
|
144
|
+
|
|
145
|
+
- **With Architect (Sage)**: Joint planning sessions, design reviews, architectural alignment
|
|
146
|
+
- **With Developer (Blake)**: Platform capabilities, development environment setup
|
|
147
|
+
- **With Product Manager (Finley)**: Infrastructure requirements, cost considerations
|
|
148
|
+
- **With Creator Agents**: Infrastructure for creative workflows and asset management
|
|
149
|
+
|
|
150
|
+
## Best Practices
|
|
151
|
+
|
|
152
|
+
### Infrastructure Design
|
|
153
|
+
|
|
154
|
+
1. **Start with Requirements**: Understand application needs before designing infrastructure
|
|
155
|
+
2. **Design for Scale**: Plan for 10x growth from day one
|
|
156
|
+
3. **Security First**: Implement defense in depth at every layer
|
|
157
|
+
4. **Cost Awareness**: Balance performance with budget constraints
|
|
158
|
+
5. **Document Everything**: Maintain comprehensive documentation
|
|
159
|
+
|
|
160
|
+
### Implementation Approach
|
|
161
|
+
|
|
162
|
+
1. **Incremental Rollout**: Deploy infrastructure in stages with validation gates
|
|
163
|
+
2. **Automation Focus**: Automate repetitive tasks and deployments
|
|
164
|
+
3. **Testing Strategy**: Include infrastructure testing in CI/CD pipelines
|
|
165
|
+
4. **Monitoring Setup**: Implement observability before production
|
|
166
|
+
5. **Team Training**: Ensure team understanding of infrastructure
|
|
167
|
+
|
|
168
|
+
### Validation Process
|
|
169
|
+
|
|
170
|
+
1. **Regular Reviews**: Schedule periodic infrastructure assessments
|
|
171
|
+
2. **Checklist Compliance**: Maintain high compliance with validation checklist
|
|
172
|
+
3. **Performance Baselines**: Establish and monitor performance metrics
|
|
173
|
+
4. **Security Audits**: Regular security assessments and penetration testing
|
|
174
|
+
5. **Cost Optimization**: Monthly cost reviews and optimization
|
|
175
|
+
|
|
176
|
+
## Common Use Cases
|
|
177
|
+
|
|
178
|
+
### 1. New Project Infrastructure
|
|
179
|
+
|
|
180
|
+
**Scenario**: Starting a new cloud-native application
|
|
181
|
+
**Process**:
|
|
182
|
+
|
|
183
|
+
1. Use Infrastructure Architecture template for design
|
|
184
|
+
2. Review with Architect agent
|
|
185
|
+
3. Implement using Platform Implementation template
|
|
186
|
+
4. Validate with comprehensive checklist
|
|
187
|
+
5. Deploy incrementally with monitoring
|
|
188
|
+
|
|
189
|
+
### 2. Infrastructure Modernization
|
|
190
|
+
|
|
191
|
+
**Scenario**: Migrating legacy infrastructure to cloud
|
|
192
|
+
**Process**:
|
|
193
|
+
|
|
194
|
+
1. Review existing infrastructure
|
|
195
|
+
2. Design target architecture
|
|
196
|
+
3. Plan migration phases
|
|
197
|
+
4. Implement with validation gates
|
|
198
|
+
5. Monitor and optimize
|
|
199
|
+
|
|
200
|
+
### 3. Platform Engineering Initiative
|
|
201
|
+
|
|
202
|
+
**Scenario**: Building internal developer platform
|
|
203
|
+
**Process**:
|
|
204
|
+
|
|
205
|
+
1. Assess developer needs
|
|
206
|
+
2. Design platform architecture
|
|
207
|
+
3. Implement Kubernetes/GitOps foundation
|
|
208
|
+
4. Build self-service capabilities
|
|
209
|
+
5. Enable developer adoption
|
|
210
|
+
|
|
211
|
+
### 4. Multi-Cloud Strategy
|
|
212
|
+
|
|
213
|
+
**Scenario**: Implementing multi-cloud architecture
|
|
214
|
+
**Process**:
|
|
215
|
+
|
|
216
|
+
1. Define cloud strategy and requirements
|
|
217
|
+
2. Design cloud-agnostic architecture
|
|
218
|
+
3. Implement with IaC abstraction
|
|
219
|
+
4. Validate cross-cloud functionality
|
|
220
|
+
5. Establish unified monitoring
|
|
221
|
+
|
|
222
|
+
## Advanced Features
|
|
223
|
+
|
|
224
|
+
### GitOps Workflows
|
|
225
|
+
|
|
226
|
+
- **Repository Structure**: Organized by environment and application
|
|
227
|
+
- **Deployment Patterns**: Progressive delivery, canary deployments
|
|
228
|
+
- **Secret Management**: External secrets operator integration
|
|
229
|
+
- **Policy Enforcement**: OPA/Gatekeeper for compliance
|
|
230
|
+
|
|
231
|
+
### Service Mesh Capabilities
|
|
232
|
+
|
|
233
|
+
- **Traffic Management**: Load balancing, circuit breaking, retries
|
|
234
|
+
- **Security**: mTLS, authorization policies
|
|
235
|
+
- **Observability**: Distributed tracing, service maps
|
|
236
|
+
- **Multi-Cluster**: Cross-cluster communication
|
|
237
|
+
|
|
238
|
+
### Developer Self-Service
|
|
239
|
+
|
|
240
|
+
- **Portal Features**: Resource provisioning, environment management
|
|
241
|
+
- **API Gateway**: Centralized API management
|
|
242
|
+
- **Documentation**: Automated API docs, runbooks
|
|
243
|
+
- **Tooling**: CLI tools, IDE integrations
|
|
244
|
+
|
|
245
|
+
## Troubleshooting Guide
|
|
246
|
+
|
|
247
|
+
### Common Issues
|
|
248
|
+
|
|
249
|
+
1. **Infrastructure Drift**
|
|
250
|
+
|
|
251
|
+
- Solution: Implement drift detection in IaC pipelines
|
|
252
|
+
- Prevention: Restrict manual changes, enforce GitOps
|
|
253
|
+
|
|
254
|
+
2. **Cost Overruns**
|
|
255
|
+
|
|
256
|
+
- Solution: Implement cost monitoring and alerts
|
|
257
|
+
- Prevention: Resource tagging, budget limits
|
|
258
|
+
|
|
259
|
+
3. **Performance Problems**
|
|
260
|
+
|
|
261
|
+
- Solution: Review monitoring data, scale resources
|
|
262
|
+
- Prevention: Load testing, capacity planning
|
|
263
|
+
|
|
264
|
+
4. **Security Vulnerabilities**
|
|
265
|
+
- Solution: Immediate patching, security reviews
|
|
266
|
+
- Prevention: Automated scanning, compliance checks
|
|
267
|
+
|
|
268
|
+
## Metrics and KPIs
|
|
269
|
+
|
|
270
|
+
### Infrastructure Metrics
|
|
271
|
+
|
|
272
|
+
- **Availability**: Target 99.9%+ uptime
|
|
273
|
+
- **Performance**: Response time < 100ms
|
|
274
|
+
- **Cost Efficiency**: Cost per transaction trending down
|
|
275
|
+
- **Security**: Zero critical vulnerabilities
|
|
276
|
+
- **Automation**: 90%+ automated deployments
|
|
277
|
+
|
|
278
|
+
### Platform Metrics
|
|
279
|
+
|
|
280
|
+
- **Developer Satisfaction**: NPS > 50
|
|
281
|
+
- **Self-Service Adoption**: 80%+ platform usage
|
|
282
|
+
- **Deployment Frequency**: Multiple per day
|
|
283
|
+
- **Lead Time**: < 1 hour from commit to production
|
|
284
|
+
- **MTTR**: < 30 minutes for incidents
|
|
285
|
+
|
|
286
|
+
## Future Enhancements
|
|
287
|
+
|
|
288
|
+
### Planned Features
|
|
289
|
+
|
|
290
|
+
1. **AI-Driven Optimization**: Automated infrastructure tuning
|
|
291
|
+
2. **Enhanced Security**: Zero-trust architecture templates
|
|
292
|
+
3. **Edge Computing**: Support for edge infrastructure patterns
|
|
293
|
+
4. **Sustainability**: Carbon footprint optimization
|
|
294
|
+
5. **Advanced Compliance**: Industry-specific compliance templates
|
|
295
|
+
|
|
296
|
+
### Integration Roadmap
|
|
297
|
+
|
|
298
|
+
1. **Cloud Provider APIs**: Direct integration with AWS, Azure, GCP
|
|
299
|
+
2. **IaC Tools**: Native support for Terraform, Pulumi
|
|
300
|
+
3. **Monitoring Platforms**: Integration with Datadog, New Relic
|
|
301
|
+
4. **Security Tools**: SIEM and vulnerability scanner integration
|
|
302
|
+
5. **Cost Management**: FinOps platform integration
|
|
303
|
+
|
|
304
|
+
## Conclusion
|
|
305
|
+
|
|
306
|
+
The BMad Infrastructure DevOps expansion pack provides a comprehensive framework for modern infrastructure and platform engineering. By following its structured approach and leveraging the provided tools and templates, teams can build reliable, scalable, and secure infrastructure that accelerates application delivery while maintaining operational excellence.
|
|
307
|
+
|
|
308
|
+
For support and updates, refer to the main BMad Method documentation or contact the BMad community.
|