bmad-method 1.0.1

package/docs/versioning-and-releases.md

@@ -0,0 +1,85 @@
+# How to Release a New Version
+
+## Automated Releases (Recommended)
+
+The easiest way to release new versions is through **automatic semantic releases**. Just commit with the right message format and push - everything else happens automatically!
+
+### Commit Message Format
+
+Use these prefixes to control what type of release happens:
+
+````bash
+fix: resolve CLI argument parsing bug      # → patch release (4.1.0 → 4.1.1)
+feat: add new agent orchestration mode     # → minor release (4.1.0 → 4.2.0)
+feat!: redesign CLI interface              # → major release (4.1.0 → 5.0.0)
+```text
+
+### What Happens Automatically
+
+When you push commits with `fix:` or `feat:`, GitHub Actions will:
+
+1. ✅ Analyze your commit messages
+2. ✅ Bump version in `package.json`
+3. ✅ Generate changelog
+4. ✅ Create git tag
+5. ✅ **Publish to NPM automatically**
+6. ✅ Create GitHub release with notes
+
+### Your Simple Workflow
+
+```bash
+# Make your changes
+git add .
+git commit -m "feat: add team collaboration mode"
+git push
+
+# That's it! Release happens automatically 🎉
+# Users can now run: npx bmad-method (and get the new version)
+````
+
+### Commits That DON'T Trigger Releases
+
+These commit types won't create releases (use them for maintenance):
+
+````bash
+chore: update dependencies     # No release
+docs: fix typo in readme      # No release
+style: format code            # No release
+test: add unit tests          # No release
+```text
+
+### Test Your Setup
+
+```bash
+npm run release:test    # Safe to run locally - tests the config
+````
+
+---
+
+## Manual Release Methods (Exceptions Only)
+
+**⚠️ Only use these methods if you need to bypass the automatic system**
+
+### Quick Manual Version Bump
+
+```bash
+npm run version:patch   # 4.1.0 → 4.1.1 (bug fixes)
+npm run version:minor   # 4.1.0 → 4.2.0 (new features)
+npm run version:major   # 4.1.0 → 5.0.0 (breaking changes)
+
+# Then manually publish:
+npm publish
+git push && git push --tags
+```
+
+### Manual GitHub Actions Trigger
+
+You can also trigger releases manually through GitHub Actions workflow dispatch if needed.
+
+---
+
+## Summary
+
+**For 99% of releases**: Just use `fix:` or `feat:` commit messages and push. Everything else is automatic!
+
+**Manual methods**: Only needed for special cases or if you want to bypass the automated system.

package/docs/versions.md

@@ -0,0 +1,49 @@
+# Version History
+
+## Previous Versions
+
+- [Version 3](https://github.com/bmadcode/BMAD-METHOD/tree/V3)
+- [Version 2](https://github.com/bmadcode/BMAD-METHOD/tree/V2)
+- [Version 1](https://github.com/bmadcode/BMAD-METHOD/tree/V1)
+
+## Current Version: V4 - Alpha
+
+Guiding Principles of V4:
+
+- Simple to understand, install and start using
+- Support Greenfield and Brownfield Scenarios
+- Greater configurability and more scenarios for usage - but kept out of the main package to maintain simplicity
+- Helpers for installers and web builders that will work with any OS and IDE easily
+- Align all agents to be the same for IDE and Web, without losing the power of the web versions, or the leanness of the files in the IDE to reduce context
+- Further improvements to the two most important agents - the SM and DEV
+- Expansion Packs - Coming soon...
+
+## V3
+
+With the customizability of V2, there were still some issues. A PM could only easily do one thing, create a PRD. And maintaining the consistency between Web and IDE agents was a pain.
+
+V3 didn't fix the disconnect, but it did make it easier to maintain them all in a single folder, but there were only two official ide agents - all the rest were really made and optimized for the web.
+
+V3's biggest impact was a full explosion of customizability. Tasks, Personas, Agent Configurations, Doc Templates, data payloads.
+
+BUT - the BIGGEST change was the realization that we were barely scratching the surface of what could be loaded into Gemini Gems and still have very long chats. The BMAD AGENT arose, and with a single V3 release - the future of the BMad Method was changed forever.
+
+Now, instead of configuring 4+ web agents, all needing many files uploaded to create them, a single Agent called BMad, with a whole team, and the ability to switch and maintain personas evolved. Now you could in the same chat thread, talk to the whole team, or anyone on the team. No more exporting and reimporting docs to different chats - all of the sudden, you could finish the PRD, and ask Josh to pass it off to the Architect, and that was it, the architect just had it and we moved on! And all of that with just 7 total files to upload, delivering all power.
+
+But V3 had a major flaw - with massive configuration comes massive complexity - and in some ways, V3 started to get away from core principles - power through simplicity. The core system needs to do one thing well and be solid, and not stretch too thing with every possible thing.
+
+Also - while the dev is amazing and better in V3 than all the past, along with the SM - the dev started over documenting every step and really started to bloat stories with their own notes. And the SM was forgetting to add details to stories, or embellishing information. This was fixed somewhat in V3.1 - but the dev is still over explaining everything it does, instead of just capturing the changes to the story.
+
+## V2
+
+After V1 proved that the BMad method was solid and repeatable, 2 key ideas emerged. Separation of concerns, and building for the web made easier. By separating out templates - it was now much easier for the PRD fields to be customized, or the architecture.
+
+And the introduction that really supercharged everything in my opinion, the web versions! There were 4 hard coded web variants hand crafted - and we saw that we could, dirt cheap, work with agents for hours in the massive context of Gemini - from a PRD generating PM, through to an architect and even an analyst that could help us do extensive market research and brain storming.
+
+What I never expected is the names would stick, and people would keep the sample names I made that I thought people would configure. But now 4 version is, people refer to Mary, and John, and Bob! And when I randomly changed the names, I got A LOT of feedback! These have become trusted allies people are relying on, including for me!
+
+## V1
+
+Believe it or not (well you can view the link), V1 was a simple 7 file system! 7 Core agents working in harmony to help build a pretty specific type of application. But it showed its power and adaptability.
+
+Meant to be a simple Tech Demo showing how custom agents with agile personas can help streamline your project, and create rails for your dev agents that to that point had gone unmatched - while also putting a focus on the planning phases - the project sparked the imagination of many, and a seed of a potential was realized.

package/expansion-packs/README.md

@@ -0,0 +1,113 @@
+# BMAD Method Expansion Packs
+
+## Overview
+
+Expansion packs extend BMAD Method with specialized capabilities for specific use cases. They allow teams to add functionality without cluttering the core workflow.
+
+## Core BMAD Flow
+
+The original BMAD Method follows a simple, proven flow:
+
+````text
+Analyst → PM → Architect → SM → Dev
+(Brief) → (PRD) → (Architecture) → (Stories) → (Implementation)
+```text
+
+This core flow remains clean and focused on getting from business requirements to working software.
+
+## Why Expansion Packs?
+
+As BMAD has evolved, we've identified specialized needs that don't fit every project:
+
+- Infrastructure and DevOps workflows
+- UX/UI design processes
+- Data engineering pipelines
+- Security and compliance workflows
+- Mobile development patterns
+- Real World assistance and workflows without AI Agents development in mind
+
+Rather than complicate the core method, expansion packs let you "opt-in" to additional capabilities.
+
+## Available Expansion Packs
+
+### 1. Infrastructure & DevOps
+
+- **Purpose**: Cloud infrastructure design and platform engineering
+- **Adds**: DevOps agent, infrastructure templates, validation checklists
+- **Use When**: You need to design and implement cloud infrastructure
+
+### 2. UX/Design (Coming Soon)
+
+- **Purpose**: User experience and interface design workflows
+- **Adds**: Design Architect agent, UI component templates
+- **Use When**: You need detailed UI/UX design processes
+
+### 3. Data Engineering (Planned)
+
+- **Purpose**: Data pipeline and analytics infrastructure
+- **Adds**: Data Engineer agent, ETL templates, data architecture patterns
+- **Use When**: You're building data-intensive applications
+
+## Structure of an Expansion Pack
+
+Each expansion pack contains:
+
+```text
+expansion-pack-name/
+├── README.md           # Overview and usage instructions
+├── manifest.yml        # Installation configuration
+├── agents/            # Agent configurations (.yml)
+├── personas/          # Persona definitions (.md)
+├── ide-agents/        # IDE-specific agents (.ide.md)
+├── templates/         # Document templates (.md)
+├── tasks/            # Specialized tasks (.md)
+└── checklists/       # Validation checklists (.md)
+````
+
+## Installing an Expansion Pack
+
+### Method 1: NPM Script
+
+````bash
+npm run install:expansion <pack-name>
+```text
+
+### Method 2: Direct Script
+
+```bash
+node tools/install-expansion-pack.js <pack-name>
+````
+
+### Method 3: Manual
+
+1. Copy files according to manifest.yml
+2. Update team configurations as needed
+3. Rebuild bundles with `npm run build`
+
+## Creating Your Own Expansion Pack
+
+1. Create a new folder under `expansion-packs/`
+2. Add your specialized agents, templates, and tasks
+3. Create a manifest.yml defining installation mappings
+4. Write a README explaining purpose and usage
+5. Test installation process
+
+## Best Practices
+
+1. **Keep Core Simple**: Don't add to core what could be an expansion
+2. **Clear Purpose**: Each pack should solve a specific need
+3. **Self-Contained**: Packs should work independently when possible
+4. **Document Well**: Clear README and usage examples
+5. **Version Compatibility**: Note which BMAD version the pack requires
+
+## Future Vision
+
+We envision a library of expansion packs for various industries and use cases:
+
+- Healthcare compliance workflows
+- Financial services security patterns
+- E-commerce optimization flows
+- Gaming development pipelines
+- IoT device management
+
+The goal is to keep BMAD's core simple while allowing infinite extensibility through modular expansion packs.

package/expansion-packs/infrastructure-devops/README.md

@@ -0,0 +1,147 @@
+# Infrastructure & DevOps Expansion Pack
+
+## Overview
+
+This expansion pack extends BMAD Method with comprehensive infrastructure and DevOps capabilities. It's designed for teams that need to define, implement, and manage cloud infrastructure alongside their application development.
+
+## Purpose
+
+While the core BMAD flow focuses on getting from business requirements to development (Analyst → PM → Architect → SM → Dev), many projects require sophisticated infrastructure planning and implementation. This expansion pack adds:
+
+- Infrastructure architecture design capabilities
+- Platform engineering implementation workflows
+- DevOps automation and CI/CD pipeline design
+- Cloud resource management and optimization
+- Security and compliance validation
+
+## When to Use This Pack
+
+Install this expansion pack when your project requires:
+
+- Cloud infrastructure design and implementation
+- Kubernetes/container platform setup
+- Service mesh and GitOps workflows
+- Infrastructure as Code (IaC) development
+- Platform engineering and DevOps practices
+
+## What's Included
+
+### Agents
+
+- `devops.yml` - DevOps and Platform Engineering agent configuration
+
+### Personas
+
+- `devops.md` - DevOps Engineer persona (Alex)
+
+### IDE Agents
+
+- `devops.ide.md` - IDE-specific DevOps agent configuration
+
+### Templates
+
+- `infrastructure-architecture-tmpl.md` - Infrastructure architecture design template
+- `infrastructure-platform-from-arch-tmpl.md` - Platform implementation from architecture template
+
+### Tasks
+
+- `infra/validate-infrastructure.md` - Infrastructure validation workflow
+- `infra/review-infrastructure.md` - Infrastructure review process
+
+### Checklists
+
+- `infrastructure-checklist.md` - Comprehensive 16-section infrastructure validation checklist
+
+## Integration with Core BMAD
+
+This expansion pack integrates with the core BMAD flow at these points:
+
+1. **After Architecture Phase**: The Architect can trigger infrastructure architecture design
+2. **Parallel to Development**: Infrastructure implementation can proceed alongside application development
+3. **Before Deployment**: Infrastructure must be validated before application deployment
+
+## Installation
+
+To install this expansion pack, run:
+
+```bash
+npm run install:expansion infrastructure
+```
+
+Or manually:
+
+```bash
+node tools/install-expansion-pack.js infrastructure
+```
+
+This will:
+
+1. Copy all files to their appropriate locations in `.bmad-core/`
+2. Update any necessary configurations
+3. Make the DevOps agent available in teams
+
+## Usage Examples
+
+### 1. Infrastructure Architecture Design
+
+After the main architecture is complete:
+
+```bash
+# Using the Architect agent
+*create-infrastructure
+
+# Or directly with DevOps agent
+npm run agent devops
+```
+
+### 2. Platform Implementation
+
+With an approved infrastructure architecture:
+
+```bash
+# DevOps agent implements the platform
+*implement-platform
+```
+
+### 3. Infrastructure Validation
+
+Before deployment:
+
+```bash
+# Validate infrastructure against checklist
+*validate-infra
+```
+
+## Team Integration
+
+The DevOps agent can be added to team configurations:
+
+- `team-technical.yml` - For technical implementation teams
+- `team-full-org.yml` - For complete organizational teams
+
+## Dependencies
+
+This expansion pack works best when used with:
+
+- Core BMAD agents (especially Architect)
+- Technical preferences documentation
+- Approved PRD and system architecture
+
+## Customization
+
+You can customize this expansion pack by:
+
+1. Modifying the infrastructure templates for your cloud provider
+2. Adjusting the checklist items for your compliance needs
+3. Adding custom tasks for your specific workflows
+
+## Notes
+
+- Infrastructure work requires real-world cloud credentials and configurations
+- The templates use placeholders ({{variable}}) that need actual values
+- Always validate infrastructure changes before production deployment
+
+---
+
+_Version: 1.0_
+_Compatible with: BMAD Method v4_

package/expansion-packs/infrastructure-devops/agents/infra-devops-platform.md

@@ -0,0 +1,59 @@
+# infra-devops-platform
+
+CRITICAL: Read the full YML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:
+
+```yml
+activation-instructions:
+  - Follow all instructions in this file -> this defines you, your persona and more importantly what you can do. STAY IN CHARACTER!
+  - Only read the files/tasks listed here when user selects them for execution to minimize context usage
+  - The customization field ALWAYS takes precedence over any conflicting instructions
+  - When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
+agent:
+  name: Alex
+  id: infra-devops-platform
+  title: DevOps Infrastructure Specialist Platform Engineer
+  customization: Specialized in cloud-native system architectures and tools, like Kubernetes, Docker, GitHub Actions, CI/CD pipelines, and infrastructure-as-code practices (e.g., Terraform, CloudFormation, Bicep, etc.).
+persona:
+  role: DevOps Engineer & Platform Reliability Expert
+  style: Systematic, automation-focused, reliability-driven, proactive. Focuses on building and maintaining robust infrastructure, CI/CD pipelines, and operational excellence.
+  identity: Master Expert Senior Platform Engineer with 15+ years of experience in DevSecOps, Cloud Engineering, and Platform Engineering with deep SRE knowledge
+  focus: Production environment resilience, reliability, security, and performance for optimal customer experience
+  core_principles:
+    - Infrastructure as Code - Treat all infrastructure configuration as code. Use declarative approaches, version control everything, ensure reproducibility
+    - Automation First - Automate repetitive tasks, deployments, and operational procedures. Build self-healing and self-scaling systems
+    - Reliability & Resilience - Design for failure. Build fault-tolerant, highly available systems with graceful degradation
+    - Security & Compliance - Embed security in every layer. Implement least privilege, encryption, and maintain compliance standards
+    - Performance Optimization - Continuously monitor and optimize. Implement caching, load balancing, and resource scaling for SLAs
+    - Cost Efficiency - Balance technical requirements with cost. Optimize resource usage and implement auto-scaling
+    - Observability & Monitoring - Implement comprehensive logging, monitoring, and tracing for quick issue diagnosis
+    - CI/CD Excellence - Build robust pipelines for fast, safe, reliable software delivery through automation and testing
+    - Disaster Recovery - Plan for worst-case scenarios with backup strategies and regularly tested recovery procedures
+    - Collaborative Operations - Work closely with development teams fostering shared responsibility for system reliability
+startup:
+  - Announce: Hey! I'm Alex, your DevOps Infrastructure Specialist. I love when things run secure, stable, reliable and performant. I can help with infrastructure architecture, platform engineering, CI/CD pipelines, and operational excellence. What infrastructure challenge can I help you with today?
+  - "List available tasks: review-infrastructure, validate-infrastructure, create infrastructure documentation"
+  - "List available templates: infrastructure-architecture, infrastructure-platform-from-arch"
+  - Execute selected task or stay in persona to help guided by Core DevOps Principles
+commands:
+  - '*help" - Show: numbered list of the following commands to allow selection'
+  - '*chat-mode" - (Default) Conversational mode for infrastructure and DevOps guidance'
+  - '*create-doc {template}" - Create doc (no template = show available templates)'
+  - '*review-infrastructure" - Review existing infrastructure for best practices'
+  - '*validate-infrastructure" - Validate infrastructure against security and reliability standards'
+  - '*checklist" - Run infrastructure checklist for comprehensive review'
+  - '*exit" - Say goodbye as Alex, the DevOps Infrastructure Specialist, and then abandon inhabiting this persona'
+dependencies:
+  tasks:
+    - create-doc
+    - review-infrastructure
+    - validate-infrastructure
+  templates:
+    - infrastructure-architecture-tmpl
+    - infrastructure-platform-from-arch-tmpl
+  checklists:
+    - infrastructure-checklist
+  data:
+    - technical-preferences
+  utils:
+    - template-format
+```