bmad-method 1.0.1

package/expansion-packs/infrastructure-devops/tasks/validate-infrastructure.md

@@ -0,0 +1,154 @@
+# Infrastructure Validation Task
+
+## Purpose
+
+To comprehensively validate platform infrastructure changes against security, reliability, operational, and compliance requirements before deployment. This task ensures all platform infrastructure meets organizational standards, follows best practices, and properly integrates with the broader BMAD ecosystem.
+
+## Inputs
+
+- Infrastructure Change Request (`docs/infrastructure/{ticketNumber}.change.md`)
+- **Infrastructure Architecture Document** (`docs/infrastructure-architecture.md` - from Architect Agent)
+- Infrastructure Guidelines (`docs/infrastructure/guidelines.md`)
+- Technology Stack Document (`docs/tech-stack.md`)
+- `infrastructure-checklist.md` (primary validation framework - 16 comprehensive sections)
+
+## Key Activities & Instructions
+
+### 1. Confirm Interaction Mode
+
+- Ask the user: "How would you like to proceed with platform infrastructure validation? We can work:
+  A. **Incrementally (Default & Recommended):** We'll work through each section of the checklist step-by-step, documenting compliance or gaps for each item before moving to the next section. This is best for thorough validation and detailed documentation of the complete platform stack.
+  B. **"YOLO" Mode:** I can perform a rapid assessment of all checklist items and present a comprehensive validation report for review. This is faster but may miss nuanced details that would be caught in the incremental approach."
+- Request the user to select their preferred mode (e.g., "Please let me know if you'd prefer A or B.").
+- Once the user chooses, confirm the selected mode and proceed accordingly.
+
+### 2. Initialize Platform Validation
+
+- Review the infrastructure change documentation to understand platform implementation scope and purpose
+- Analyze the infrastructure architecture document for platform design patterns and compliance requirements
+- Examine infrastructure guidelines for organizational standards across all platform components
+- Prepare the validation environment and tools for comprehensive platform testing
+- <critical_rule>Verify the infrastructure change request is approved for validation. If not, HALT and inform the user.</critical_rule>
+
+### 3. Architecture Design Review Gate
+
+- **DevOps/Platform → Architect Design Review:**
+  - Conduct systematic review of infrastructure architecture document for implementability
+  - Evaluate architectural decisions against operational constraints and capabilities:
+    - **Implementation Complexity:** Assess if proposed architecture can be implemented with available tools and expertise
+    - **Operational Feasibility:** Validate that operational patterns are achievable within current organizational maturity
+    - **Resource Availability:** Confirm required infrastructure resources are available and within budget constraints
+    - **Technology Compatibility:** Verify selected technologies integrate properly with existing infrastructure
+    - **Security Implementation:** Validate that security patterns can be implemented with current security toolchain
+    - **Maintenance Overhead:** Assess ongoing operational burden and maintenance requirements
+  - Document design review findings and recommendations:
+    - **Approved Aspects:** Document architectural decisions that are implementable as designed
+    - **Implementation Concerns:** Identify architectural decisions that may face implementation challenges
+    - **Required Modifications:** Recommend specific changes needed to make architecture implementable
+    - **Alternative Approaches:** Suggest alternative implementation patterns where needed
+  - **Collaboration Decision Point:**
+    - If **critical implementation blockers** identified: HALT validation and escalate to Architect Agent for architectural revision
+    - If **minor concerns** identified: Document concerns and proceed with validation, noting required implementation adjustments
+    - If **architecture approved**: Proceed with comprehensive platform validation
+  - <critical_rule>All critical design review issues must be resolved before proceeding to detailed validation</critical_rule>
+
+### 4. Execute Comprehensive Platform Validation Process
+
+- **If "Incremental Mode" was selected:**
+
+  - For each section of the infrastructure checklist (Sections 1-16):
+    - **a. Present Section Purpose:** Explain what this section validates and why it's important for platform operations
+    - **b. Work Through Items:** Present each checklist item, guide the user through validation, and document compliance or gaps
+    - **c. Evidence Collection:** For each compliant item, document how compliance was verified
+    - **d. Gap Documentation:** For each non-compliant item, document specific issues and proposed remediation
+    - **e. Platform Integration Testing:** For platform engineering sections (13-16), validate integration between platform components
+    - **f. [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)**
+    - **g. Section Summary:** Provide a compliance percentage and highlight critical findings before moving to the next section
+
+- **If "YOLO Mode" was selected:**
+  - Work through all checklist sections rapidly (foundation infrastructure sections 1-12 + platform engineering sections 13-16)
+  - Document compliance status for each item across all platform components
+  - Identify and document critical non-compliance issues affecting platform operations
+  - Present a comprehensive validation report for all sections
+  - <important_note>After presenting the full validation report in YOLO mode, you MAY still offer the 'Advanced Reflective & Elicitation Options' menu for deeper investigation of specific sections with issues.</important_note>
+
+### 5. Generate Comprehensive Platform Validation Report
+
+- Summarize validation findings by section across all 16 checklist areas
+- Calculate and present overall compliance percentage for complete platform stack
+- Clearly document all non-compliant items with remediation plans prioritized by platform impact
+- Highlight critical security or operational risks affecting platform reliability
+- Include design review findings and architectural implementation recommendations
+- Provide validation signoff recommendation based on complete platform assessment
+- Document platform component integration validation results
+
+### 6. BMAD Integration Assessment
+
+- Review how platform infrastructure changes support other BMAD agents:
+  - **Development Agent Alignment:** Verify platform infrastructure supports Frontend Dev, Backend Dev, and Full Stack Dev requirements including:
+    - Container platform development environment provisioning
+    - GitOps workflows for application deployment
+    - Service mesh integration for development testing
+    - Developer experience platform self-service capabilities
+  - **Product Alignment:** Ensure platform infrastructure implements PRD requirements from Product Owner including:
+    - Scalability and performance requirements through container platform
+    - Deployment automation through GitOps workflows
+    - Service reliability through service mesh implementation
+  - **Architecture Alignment:** Validate that platform implementation aligns with architecture decisions including:
+    - Technology selections implemented correctly across all platform components
+    - Security architecture implemented in container platform, service mesh, and GitOps
+    - Integration patterns properly implemented between platform components
+  - Document all integration points and potential impacts on other agents' workflows
+
+### 7. Next Steps Recommendation
+
+- If validation successful:
+  - Prepare platform deployment recommendation with component dependencies
+  - Outline monitoring requirements for complete platform stack
+  - Suggest knowledge transfer activities for platform operations
+  - Document platform readiness certification
+- If validation failed:
+  - Prioritize remediation actions by platform component and integration impact
+  - Recommend blockers vs. non-blockers for platform deployment
+  - Schedule follow-up validation with focus on failed platform components
+  - Document platform risks and mitigation strategies
+- If design review identified architectural issues:
+  - **Escalate to Architect Agent** for architectural revision and re-design
+  - Document specific architectural changes required for implementability
+  - Schedule follow-up design review after architectural modifications
+- Update documentation with validation results across all platform components
+- <important_note>Always ensure the Infrastructure Change Request status is updated to reflect the platform validation outcome.</important_note>
+
+## Output
+
+A comprehensive platform validation report documenting:
+
+1. **Architecture Design Review Results** - Implementability assessment and architectural recommendations
+2. **Compliance percentage by checklist section** (all 16 sections including platform engineering)
+3. **Detailed findings for each non-compliant item** across foundation and platform components
+4. **Platform integration validation results** documenting component interoperability
+5. **Remediation recommendations with priority levels** based on platform impact
+6. **BMAD integration assessment results** for complete platform stack
+7. **Clear signoff recommendation** for platform deployment readiness or architectural revision requirements
+8. **Next steps for implementation or remediation** prioritized by platform dependencies
+
+## Offer Advanced Self-Refinement & Elicitation Options
+
+Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.
+
+"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):
+
+**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**
+
+1. **Critical Security Assessment & Risk Analysis**
+2. **Platform Integration & Component Compatibility Evaluation**
+3. **Cross-Environment Consistency Review**
+4. **Technical Debt & Maintainability Analysis**
+5. **Compliance & Regulatory Alignment Deep Dive**
+6. **Cost Optimization & Resource Efficiency Analysis**
+7. **Operational Resilience & Platform Failure Mode Testing (Theoretical)**
+8. **Finalize this Section and Proceed.**
+
+After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."
+
+REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNTIL the user indicates it is time to proceed to the next section (or selects #8)

package/expansion-packs/infrastructure-devops/templates/infrastructure-architecture-tmpl.md

@@ -0,0 +1,415 @@
+# {{Project Name}} Infrastructure Architecture
+
+[[LLM: Initial Setup
+
+1. Replace {{Project Name}} with the actual project name throughout the document
+2. Gather and review required inputs:
+   - Product Requirements Document (PRD) - Required for business needs and scale requirements
+   - Main System Architecture - Required for infrastructure dependencies
+   - Technical Preferences/Tech Stack Document - Required for technology choices
+   - PRD Technical Assumptions - Required for cross-referencing repository and service architecture
+
+If any required documents are missing, ask user: "I need the following documents to create a comprehensive infrastructure architecture: [list missing]. Would you like to proceed with available information or provide the missing documents first?"
+
+3. <critical_rule>Cross-reference with PRD Technical Assumptions to ensure infrastructure decisions align with repository and service architecture decisions made in the system architecture.</critical_rule>
+
+Output file location: `docs/infrastructure-architecture.md`]]
+
+## Infrastructure Overview
+
+[[LLM: Review the product requirements document to understand business needs and scale requirements. Analyze the main system architecture to identify infrastructure dependencies. Document non-functional requirements (performance, scalability, reliability, security). Cross-reference with PRD Technical Assumptions to ensure alignment with repository and service architecture decisions.]]
+
+- Cloud Provider(s)
+- Core Services & Resources
+- Regional Architecture
+- Multi-environment Strategy
+
+@{example: cloud_strategy}
+
+- **Cloud Provider:** AWS (primary), with multi-cloud capability for critical services
+- **Core Services:** EKS for container orchestration, RDS for databases, S3 for storage, CloudFront for CDN
+- **Regional Architecture:** Multi-region active-passive with primary in us-east-1, DR in us-west-2
+- **Multi-environment Strategy:** Development, Staging, UAT, Production with identical infrastructure patterns
+
+@{/example}
+
+[[LLM: Infrastructure Elicitation Options
+Present user with domain-specific elicitation options:
+"For the Infrastructure Overview section, I can explore:
+
+1. **Multi-Cloud Strategy Analysis** - Evaluate cloud provider options and vendor lock-in considerations
+2. **Regional Distribution Planning** - Analyze latency requirements and data residency needs
+3. **Environment Isolation Strategy** - Design security boundaries and resource segregation
+4. **Scalability Patterns Review** - Assess auto-scaling needs and traffic patterns
+5. **Compliance Requirements Analysis** - Review regulatory and security compliance needs
+6. **Cost-Benefit Analysis** - Compare infrastructure options and TCO
+7. **Proceed to next section**
+
+Select an option (1-7):"]]
+
+## Infrastructure as Code (IaC)
+
+[[LLM: Define IaC approach based on technical preferences and existing patterns. Consider team expertise, tooling ecosystem, and maintenance requirements.]]
+
+- Tools & Frameworks
+- Repository Structure
+- State Management
+- Dependency Management
+
+<critical_rule>All infrastructure must be defined as code. No manual resource creation in production environments.</critical_rule>
+
+## Environment Configuration
+
+[[LLM: Design environment strategy that supports the development workflow while maintaining security and cost efficiency. Reference the Environment Transition Strategy section for promotion details.]]
+
+- Environment Promotion Strategy
+- Configuration Management
+- Secret Management
+- Feature Flag Integration
+
+<<REPEAT: environment>>
+
+### {{environment_name}} Environment
+
+- **Purpose:** {{environment_purpose}}
+- **Resources:** {{environment_resources}}
+- **Access Control:** {{environment_access}}
+- **Data Classification:** {{environment_data_class}}
+
+<</REPEAT>>
+
+## Environment Transition Strategy
+
+[[LLM: Detail the complete lifecycle of code and configuration changes from development to production. Include governance, testing gates, and rollback procedures.]]
+
+- Development to Production Pipeline
+- Deployment Stages and Gates
+- Approval Workflows and Authorities
+- Rollback Procedures
+- Change Cadence and Release Windows
+- Environment-Specific Configuration Management
+
+## Network Architecture
+
+[[LLM: Design network topology considering security zones, traffic patterns, and compliance requirements. Reference main architecture for service communication patterns.
+
+Create Mermaid diagram showing:
+
+- VPC/Network structure
+- Security zones and boundaries
+- Traffic flow patterns
+- Load balancer placement
+- Service mesh topology (if applicable)]]
+
+- VPC/VNET Design
+- Subnet Strategy
+- Security Groups & NACLs
+- Load Balancers & API Gateways
+- Service Mesh (if applicable)
+
+```mermaid
+graph TB
+    subgraph "Production VPC"
+        subgraph "Public Subnets"
+            ALB[Application Load Balancer]
+        end
+        subgraph "Private Subnets"
+            EKS[EKS Cluster]
+            RDS[(RDS Database)]
+        end
+    end
+    Internet((Internet)) --> ALB
+    ALB --> EKS
+    EKS --> RDS
+```
+
+^^CONDITION: uses_service_mesh^^
+
+### Service Mesh Architecture
+
+- **Mesh Technology:** {{service_mesh_tech}}
+- **Traffic Management:** {{traffic_policies}}
+- **Security Policies:** {{mesh_security}}
+- **Observability Integration:** {{mesh_observability}}
+
+^^/CONDITION: uses_service_mesh^^
+
+## Compute Resources
+
+[[LLM: Select compute strategy based on application architecture (microservices, serverless, monolithic). Consider cost, scalability, and operational complexity.]]
+
+- Container Strategy
+- Serverless Architecture
+- VM/Instance Configuration
+- Auto-scaling Approach
+
+^^CONDITION: uses_kubernetes^^
+
+### Kubernetes Architecture
+
+- **Cluster Configuration:** {{k8s_cluster_config}}
+- **Node Groups:** {{k8s_node_groups}}
+- **Networking:** {{k8s_networking}}
+- **Storage Classes:** {{k8s_storage}}
+- **Security Policies:** {{k8s_security}}
+
+^^/CONDITION: uses_kubernetes^^
+
+## Data Resources
+
+[[LLM: Design data infrastructure based on data architecture from main system design. Consider data volumes, access patterns, compliance, and recovery requirements.
+
+Create data flow diagram showing:
+
+- Database topology
+- Replication patterns
+- Backup flows
+- Data migration paths]]
+
+- Database Deployment Strategy
+- Backup & Recovery
+- Replication & Failover
+- Data Migration Strategy
+
+## Security Architecture
+
+[[LLM: Implement defense-in-depth strategy. Reference security requirements from PRD and compliance needs. Consider zero-trust principles where applicable.]]
+
+- IAM & Authentication
+- Network Security
+- Data Encryption
+- Compliance Controls
+- Security Scanning & Monitoring
+
+<critical_rule>Apply principle of least privilege for all access controls. Document all security exceptions with business justification.</critical_rule>
+
+## Shared Responsibility Model
+
+[[LLM: Clearly define boundaries between cloud provider, platform team, development team, and security team responsibilities. This is critical for operational success.]]
+
+- Cloud Provider Responsibilities
+- Platform Team Responsibilities
+- Development Team Responsibilities
+- Security Team Responsibilities
+- Operational Monitoring Ownership
+- Incident Response Accountability Matrix
+
+@{example: responsibility_matrix}
+
+| Component            | Cloud Provider | Platform Team | Dev Team       | Security Team |
+| -------------------- | -------------- | ------------- | -------------- | ------------- |
+| Physical Security    | ✓              | -             | -              | Audit         |
+| Network Security     | Partial        | ✓             | Config         | Audit         |
+| Application Security | -              | Tools         | ✓              | Review        |
+| Data Encryption      | Engine         | Config        | Implementation | Standards     |
+
+@{/example}
+
+## Monitoring & Observability
+
+[[LLM: Design comprehensive observability strategy covering metrics, logs, traces, and business KPIs. Ensure alignment with SLA/SLO requirements.]]
+
+- Metrics Collection
+- Logging Strategy
+- Tracing Implementation
+- Alerting & Incident Response
+- Dashboards & Visualization
+
+## CI/CD Pipeline
+
+[[LLM: Design deployment pipeline that balances speed with safety. Include progressive deployment strategies and automated quality gates.
+
+Create pipeline diagram showing:
+
+- Build stages
+- Test gates
+- Deployment stages
+- Approval points
+- Rollback triggers]]
+
+- Pipeline Architecture
+- Build Process
+- Deployment Strategy
+- Rollback Procedures
+- Approval Gates
+
+^^CONDITION: uses_progressive_deployment^^
+
+### Progressive Deployment Strategy
+
+- **Canary Deployment:** {{canary_config}}
+- **Blue-Green Deployment:** {{blue_green_config}}
+- **Feature Flags:** {{feature_flag_integration}}
+- **Traffic Splitting:** {{traffic_split_rules}}
+
+^^/CONDITION: uses_progressive_deployment^^
+
+## Disaster Recovery
+
+[[LLM: Design DR strategy based on business continuity requirements. Define clear RTO/RPO targets and ensure they align with business needs.]]
+
+- Backup Strategy
+- Recovery Procedures
+- RTO & RPO Targets
+- DR Testing Approach
+
+<critical_rule>DR procedures must be tested at least quarterly. Document test results and improvement actions.</critical_rule>
+
+## Cost Optimization
+
+[[LLM: Balance cost efficiency with performance and reliability requirements. Include both immediate optimizations and long-term strategies.]]
+
+- Resource Sizing Strategy
+- Reserved Instances/Commitments
+- Cost Monitoring & Reporting
+- Optimization Recommendations
+
+## BMAD Integration Architecture
+
+[[LLM: Design infrastructure to specifically support other BMAD agents and their workflows. This ensures the infrastructure enables the entire BMAD methodology.]]
+
+### Development Agent Support
+
+- Container platform for development environments
+- GitOps workflows for application deployment
+- Service mesh integration for development testing
+- Developer self-service platform capabilities
+
+### Product & Architecture Alignment
+
+- Infrastructure implementing PRD scalability requirements
+- Deployment automation supporting product iteration speed
+- Service reliability meeting product SLAs
+- Architecture patterns properly implemented in infrastructure
+
+### Cross-Agent Integration Points
+
+- CI/CD pipelines supporting Frontend, Backend, and Full Stack development workflows
+- Monitoring and observability data accessible to QA and DevOps agents
+- Infrastructure enabling Design Architect's UI/UX performance requirements
+- Platform supporting Analyst's data collection and analysis needs
+
+## DevOps/Platform Feasibility Review
+
+[[LLM: CRITICAL STEP - Present architectural blueprint summary to DevOps/Platform Engineering Agent for feasibility review. Request specific feedback on:
+
+- **Operational Complexity:** Are the proposed patterns implementable with current tooling and expertise?
+- **Resource Constraints:** Do infrastructure requirements align with available resources and budgets?
+- **Security Implementation:** Are security patterns achievable with current security toolchain?
+- **Operational Overhead:** Will the proposed architecture create excessive operational burden?
+- **Technology Constraints:** Are selected technologies compatible with existing infrastructure?
+
+Document all feasibility feedback and concerns raised. Iterate on architectural decisions based on operational constraints and feedback.
+
+<critical_rule>Address all critical feasibility concerns before proceeding to final architecture documentation. If critical blockers identified, revise architecture before continuing.</critical_rule>]]
+
+### Feasibility Assessment Results
+
+- **Green Light Items:** {{feasible_items}}
+- **Yellow Light Items:** {{items_needing_adjustment}}
+- **Red Light Items:** {{items_requiring_redesign}}
+- **Mitigation Strategies:** {{mitigation_plans}}
+
+## Infrastructure Verification
+
+### Validation Framework
+
+This infrastructure architecture will be validated using the comprehensive `infrastructure-checklist.md`, with particular focus on Section 12: Architecture Documentation Validation. The checklist ensures:
+
+- Completeness of architecture documentation
+- Consistency with broader system architecture
+- Appropriate level of detail for different stakeholders
+- Clear implementation guidance
+- Future evolution considerations
+
+### Validation Process
+
+The architecture documentation validation should be performed:
+
+- After initial architecture development
+- After significant architecture changes
+- Before major implementation phases
+- During periodic architecture reviews
+
+The Platform Engineer should use the infrastructure checklist to systematically validate all aspects of this architecture document.
+
+## Implementation Handoff
+
+[[LLM: Create structured handoff documentation for implementation team. This ensures architecture decisions are properly communicated and implemented.]]
+
+### Architecture Decision Records (ADRs)
+
+Create ADRs for key infrastructure decisions:
+
+- Cloud provider selection rationale
+- Container orchestration platform choice
+- Networking architecture decisions
+- Security implementation choices
+- Cost optimization trade-offs
+
+### Implementation Validation Criteria
+
+Define specific criteria for validating correct implementation:
+
+- Infrastructure as Code quality gates
+- Security compliance checkpoints
+- Performance benchmarks
+- Cost targets
+- Operational readiness criteria
+
+### Knowledge Transfer Requirements
+
+- Technical documentation for operations team
+- Runbook creation requirements
+- Training needs for platform team
+- Handoff meeting agenda items
+
+## Infrastructure Evolution
+
+[[LLM: Document the long-term vision and evolution path for the infrastructure. Consider technology trends, anticipated growth, and technical debt management.]]
+
+- Technical Debt Inventory
+- Planned Upgrades and Migrations
+- Deprecation Schedule
+- Technology Roadmap
+- Capacity Planning
+- Scalability Considerations
+
+## Integration with Application Architecture
+
+[[LLM: Map infrastructure components to application services. Ensure infrastructure design supports application requirements and patterns defined in main architecture.]]
+
+- Service-to-Infrastructure Mapping
+- Application Dependency Matrix
+- Performance Requirements Implementation
+- Security Requirements Implementation
+- Data Flow to Infrastructure Correlation
+- API Gateway and Service Mesh Integration
+
+## Cross-Team Collaboration
+
+[[LLM: Define clear interfaces and communication patterns between teams. This section is critical for operational success and should include specific touchpoints and escalation paths.]]
+
+- Platform Engineer and Developer Touchpoints
+- Frontend/Backend Integration Requirements
+- Product Requirements to Infrastructure Mapping
+- Architecture Decision Impact Analysis
+- Design Architect UI/UX Infrastructure Requirements
+- Analyst Research Integration
+
+## Infrastructure Change Management
+
+[[LLM: Define structured process for infrastructure changes. Include risk assessment, testing requirements, and rollback procedures.]]
+
+- Change Request Process
+- Risk Assessment
+- Testing Strategy
+- Validation Procedures
+
+[[LLM: Final Review - Ensure all sections are complete and consistent. Verify feasibility review was conducted and all concerns addressed. Apply final validation against infrastructure checklist.]]
+
+---
+
+_Document Version: 1.0_
+_Last Updated: {{current_date}}_
+_Next Review: {{review_date}}_

package/package.json

@@ -0,0 +1,73 @@
+{
+  "name": "bmad-method",
+  "version": "1.0.1",
+  "description": "Breakthrough Method of Agile AI-driven Development",
+  "main": "tools/cli.js",
+  "bin": {
+    "bmad": "./tools/bmad-npx-wrapper.js",
+    "bmad-method": "./tools/bmad-npx-wrapper.js"
+  },
+  "scripts": {
+    "build": "node tools/cli.js build",
+    "build:agents": "node tools/cli.js build --agents-only",
+    "build:teams": "node tools/cli.js build --teams-only",
+    "list:agents": "node tools/cli.js list:agents",
+    "validate": "node tools/cli.js validate",
+    "install:bmad": "node tools/installer/bin/bmad.js install",
+    "format": "prettier --write \"**/*.md\" && node tools/yaml-format.js **/*.md **/*.yml **/*.yaml .roo/.roomodes",
+    "version:patch": "node tools/version-bump.js patch",
+    "version:minor": "node tools/version-bump.js minor",
+    "version:major": "node tools/version-bump.js major",
+    "release": "semantic-release",
+    "release:test": "semantic-release --dry-run --no-ci || echo 'Config test complete - authentication errors are expected locally'",
+    "prepare": "husky"
+  },
+  "dependencies": {
+    "@kayvan/markdown-tree-parser": "^1.4.2",
+    "chalk": "^4.1.2",
+    "commander": "^9.4.1",
+    "fs-extra": "^11.1.0",
+    "glob": "^8.0.3",
+    "inquirer": "^8.2.5",
+    "js-yaml": "^4.1.0",
+    "ora": "^5.4.1"
+  },
+  "keywords": [
+    "agile",
+    "ai",
+    "orchestrator",
+    "development",
+    "methodology",
+    "agents",
+    "bmad"
+  ],
+  "author": "Brian (BMad) Madison",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/bmadcode/BMAD-METHOD.git"
+  },
+  "engines": {
+    "node": ">=14.0.0"
+  },
+  "devDependencies": {
+    "husky": "^9.1.7",
+    "lint-staged": "^16.1.1",
+    "prettier": "^3.5.3",
+    "semantic-release": "^22.0.0",
+    "@semantic-release/changelog": "^6.0.3",
+    "@semantic-release/git": "^10.0.1",
+    "yaml-lint": "^1.7.0"
+  },
+  "lint-staged": {
+    "*.{yml,yaml}": [
+      "node tools/yaml-format.js"
+    ],
+    "*.md": [
+      "node tools/yaml-format.js"
+    ],
+    ".roomodes": [
+      "node tools/yaml-format.js"
+    ]
+  }
+}

package/tools/bmad-npx-wrapper.js

@@ -0,0 +1,41 @@
+#!/usr/bin/env node
+
+/**
+ * BMAD Method CLI - Direct execution wrapper for npx
+ * This file ensures proper execution when run via npx from GitHub
+ */
+
+const { execSync } = require('child_process');
+const path = require('path');
+const fs = require('fs');
+
+// Check if we're running in an npx temporary directory
+const isNpxExecution = __dirname.includes('_npx') || __dirname.includes('.npm');
+
+// If running via npx, we need to handle things differently
+if (isNpxExecution) {
+  // The actual bmad.js is in installer/bin/ (relative to tools directory)
+  const bmadScriptPath = path.join(__dirname, 'installer', 'bin', 'bmad.js');
+  
+  // Verify the file exists
+  if (!fs.existsSync(bmadScriptPath)) {
+    console.error('Error: Could not find bmad.js at', bmadScriptPath);
+    console.error('Current directory:', __dirname);
+    process.exit(1);
+  }
+  
+  // Execute with proper working directory
+  try {
+    execSync(`node "${bmadScriptPath}" ${process.argv.slice(2).join(' ')}`, {
+      stdio: 'inherit',
+      cwd: path.dirname(__dirname)
+    });
+  } catch (error) {
+    // execSync will throw if the command exits with non-zero
+    // But the stdio is inherited, so the error is already displayed
+    process.exit(error.status || 1);
+  }
+} else {
+  // Local execution - just require the installer directly
+  require('./installer/bin/bmad.js');
+}