bmad-method 6.0.0-alpha.8 → 6.0.1

package/.bmad/bmm/workflows/1-analysis/brainstorm-project/workflow.yaml

@@ -1,26 +0,0 @@
-# Brainstorm Project Workflow Configuration
-name: "brainstorm-project"
-description: "Facilitate project brainstorming sessions by orchestrating the CIS brainstorming workflow with project-specific context and guidance."
-author: "BMad"
-
-# Critical variables from config
-config_source: "{project-root}/.bmad/bmm/config.yaml"
-output_folder: "{config_source}:output_folder"
-user_name: "{config_source}:user_name"
-communication_language: "{config_source}:communication_language"
-document_output_language: "{config_source}:document_output_language"
-user_skill_level: "{config_source}:user_skill_level"
-date: system-generated
-
-# Module path and component files
-installed_path: "{project-root}/.bmad/bmm/workflows/1-analysis/brainstorm-project"
-template: false
-instructions: "{installed_path}/instructions.md"
-
-# Context document for project brainstorming
-project_context: "{installed_path}/project-context.md"
-
-# CORE brainstorming workflow to invoke
-core_brainstorming: "{project-root}/.bmad/core/workflows/brainstorming/workflow.yaml"
-
-standalone: true

package/.bmad/bmm/workflows/1-analysis/domain-research/instructions.md

@@ -1,423 +0,0 @@
-# Domain Research - Collaborative Domain Exploration
-
-<critical>The workflow execution engine is governed by: {project-root}/.bmad/core/tasks/workflow.xml</critical>
-<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
-<critical>This is COLLABORATIVE RESEARCH - engage the user as a partner, not just a data source</critical>
-<critical>The goal is PRACTICAL UNDERSTANDING that directly informs requirements and architecture</critical>
-<critical>Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}</critical>
-<critical>Generate all documents in {document_output_language}</critical>
-<critical>LIVING DOCUMENT: Write to domain-brief.md continuously as you discover - never wait until the end</critical>
-
-<workflow>
-
-<step n="0" goal="Set research context">
-<action>Welcome {user_name} to collaborative domain research
-
-Check for context:
-
-- Was this triggered from PRD workflow?
-- Is there a workflow-status.yaml with project context?
-- Did user provide initial domain/project description?
-
-If context exists, reflect it back:
-"I understand you're building [description]. Let's explore the [domain] aspects together to ensure we capture all critical requirements."
-
-If no context:
-"Let's explore your project's domain together. Tell me about what you're building and what makes it unique or complex."</action>
-</step>
-
-<step n="1" goal="Domain detection and scoping">
-<action>Through conversation, identify the domain and its complexity
-
-Listen for domain signals and explore:
-
-- "Is this in a regulated industry?"
-- "Are there safety or compliance concerns?"
-- "What could go wrong if this fails?"
-- "Who are the stakeholders beyond direct users?"
-- "Are there industry standards we need to follow?"
-
-Based on responses, identify primary domain(s):
-
-- Healthcare/Medical
-- Financial Services
-- Government/Public Sector
-- Education
-- Aerospace/Defense
-- Automotive
-- Energy/Utilities
-- Legal
-- Insurance
-- Scientific/Research
-- Other specialized domain
-
-Share your understanding:
-"Based on our discussion, this appears to be a [domain] project with [key characteristics]. The main areas we should research are:
-
-- [Area 1]
-- [Area 2]
-- [Area 3]
-
-What concerns you most about building in this space?"</action>
-
-<template-output>domain_overview</template-output>
-</step>
-
-<step n="2" goal="Collaborative concern mapping">
-<action>Work WITH the user to identify critical concerns
-
-"Let's map out the important considerations together. I'll share what I typically see in [domain], and you tell me what applies to your case."
-
-For detected domain, explore relevant areas:
-
-HEALTHCARE:
-"In healthcare software, teams often worry about:
-
-- FDA approval pathways (510k, De Novo, PMA)
-- HIPAA compliance for patient data
-- Clinical validation requirements
-- Integration with hospital systems (HL7, FHIR, DICOM)
-- Patient safety and liability
-
-Which of these apply to you? What else concerns you?"
-
-FINTECH:
-"Financial software typically deals with:
-
-- KYC/AML requirements
-- Payment processing regulations (PCI DSS)
-- Regional compliance (US, EU, specific countries?)
-- Fraud prevention
-- Audit trails and reporting
-
-What's your situation with these? Any specific regions?"
-
-AEROSPACE:
-"Aerospace software often requires:
-
-- DO-178C certification levels
-- Safety analysis (FMEA, FTA)
-- Simulation validation
-- Real-time performance guarantees
-- Export control (ITAR)
-
-Which are relevant for your project?"
-
-[Continue for other domains...]
-
-Document concerns as the user shares them
-Ask follow-up questions to understand depth:
-
-- "How critical is this requirement?"
-- "Is this a must-have for launch or can it come later?"
-- "Do you have expertise here or need guidance?"</action>
-
-<template-output>concern_mapping</template-output>
-</step>
-
-<step n="3" goal="Research key requirements together">
-<action>Conduct research WITH the user watching and contributing
-
-"Let me research the current requirements for [specific concern]. You can guide me toward what's most relevant."
-
-<WebSearch>{specific_requirement} requirements {date}</WebSearch>
-
-Share findings immediately:
-"Here's what I found about [requirement]:
-
-- [Key point 1]
-- [Key point 2]
-- [Key point 3]
-
-Does this match your understanding? Anything surprising or concerning?"
-
-For each major concern:
-
-1. Research current standards/regulations
-2. Share findings with user
-3. Get their interpretation
-4. Note practical implications
-
-If user has expertise:
-"You seem knowledgeable about [area]. What should I know that might not be in public documentation?"
-
-If user is learning:
-"This might be new territory. Let me explain what this means practically for your development..."</action>
-
-<template-output>regulatory_requirements</template-output>
-<template-output>industry_standards</template-output>
-</step>
-
-<step n="4" goal="Identify practical implications">
-<action>Translate research into practical development impacts
-
-"Based on what we've learned, here's what this means for your project:
-
-ARCHITECTURE IMPLICATIONS:
-
-- [How this affects system design]
-- [Required components or patterns]
-- [Performance or security needs]
-
-DEVELOPMENT IMPLICATIONS:
-
-- [Additional development effort]
-- [Special expertise needed]
-- [Testing requirements]
-
-TIMELINE IMPLICATIONS:
-
-- [Certification/approval timelines]
-- [Validation requirements]
-- [Documentation needs]
-
-COST IMPLICATIONS:
-
-- [Compliance costs]
-- [Required tools or services]
-- [Ongoing maintenance]
-
-Does this align with your expectations? Any surprises we should dig into?"</action>
-
-<template-output>practical_implications</template-output>
-</step>
-
-<step n="5" goal="Discover domain-specific patterns">
-<action>Explore how others solve similar problems
-
-"Let's look at how successful [domain] products handle these challenges."
-
-<WebSearch>best {domain} software architecture patterns {date}</WebSearch>
-<WebSearch>{domain} software case studies {date}</WebSearch>
-
-Discuss patterns:
-"I found these common approaches in [domain]:
-
-Pattern 1: [Description]
-
-- Pros: [Benefits]
-- Cons: [Tradeoffs]
-- When to use: [Conditions]
-
-Pattern 2: [Description]
-
-- Pros: [Benefits]
-- Cons: [Tradeoffs]
-- When to use: [Conditions]
-
-Which resonates with your vision? Or are you thinking something different?"
-
-If user proposes novel approach:
-"That's interesting and different from the standard patterns. Let's explore:
-
-- What makes your approach unique?
-- What problem does it solve that existing patterns don't?
-- What are the risks?
-- How do we validate it?"</action>
-
-<template-output>domain_patterns</template-output>
-<template-output if="novel approach">innovation_notes</template-output>
-</step>
-
-<step n="6" goal="Risk assessment and mitigation">
-<action>Collaboratively identify and address risks
-
-"Every [domain] project has risks. Let's think through yours:
-
-REGULATORY RISKS:
-
-- What if regulations change during development?
-- What if approval/certification takes longer?
-- What if we misinterpret requirements?
-
-TECHNICAL RISKS:
-
-- What if the domain requirements conflict with user experience?
-- What if performance requirements are harder than expected?
-- What if integrations are more complex?
-
-MARKET RISKS:
-
-- What if competitors move faster?
-- What if domain experts are hard to find?
-- What if users resist domain-mandated workflows?
-
-For each risk you're concerned about, let's identify:
-
-1. How likely is it?
-2. What's the impact if it happens?
-3. How can we mitigate it?
-4. What's our plan B?"</action>
-
-<template-output>risk_assessment</template-output>
-</step>
-
-<step n="7" goal="Create validation strategy">
-<action>Plan how to ensure domain requirements are met
-
-"Let's plan how to validate that we're meeting [domain] requirements:
-
-COMPLIANCE VALIDATION:
-
-- How do we verify regulatory compliance?
-- Who needs to review/approve?
-- What documentation is required?
-
-TECHNICAL VALIDATION:
-
-- How do we prove the system works correctly?
-- What metrics matter?
-- What testing is required?
-
-DOMAIN EXPERT VALIDATION:
-
-- Who are the domain experts to involve?
-- When should they review?
-- What are their success criteria?
-
-USER VALIDATION:
-
-- How do we ensure it's still usable despite constraints?
-- What user testing is needed?
-- How do we balance domain requirements with UX?
-
-What validation is most critical for your confidence?"</action>
-
-<template-output>validation_strategy</template-output>
-</step>
-
-<step n="8" goal="Document decision points">
-<action>Capture key decisions and rationale
-
-"Let's document the important decisions we've made:
-
-DOMAIN APPROACH:
-
-- We're choosing [approach] because [rationale]
-- We're prioritizing [requirement] over [requirement] because [reason]
-- We're deferring [requirement] to Phase 2 because [justification]
-
-COMPLIANCE STRATEGY:
-
-- We'll pursue [pathway] for regulatory approval
-- We'll implement [standard] for industry compliance
-- We'll handle [requirement] by [approach]
-
-RISK DECISIONS:
-
-- We accept [risk] because [reason]
-- We'll mitigate [risk] through [approach]
-- We'll monitor [risk] by [method]
-
-Any decisions you want to revisit or rationale to add?"</action>
-
-<template-output>key_decisions</template-output>
-</step>
-
-<step n="9" goal="Create actionable recommendations">
-<action>Synthesize research into specific recommendations
-
-"Based on our research, here are my recommendations for your PRD and development:
-
-MUST HAVE (Domain Critical):
-
-1. [Specific requirement with why it's critical]
-2. [Specific requirement with why it's critical]
-3. [Specific requirement with why it's critical]
-
-SHOULD HAVE (Domain Important):
-
-1. [Requirement that's important but not blocking]
-2. [Requirement that's important but not blocking]
-
-CONSIDER (Domain Nice-to-Have):
-
-1. [Enhancement that would differentiate]
-2. [Enhancement that would differentiate]
-
-DEVELOPMENT SEQUENCE:
-
-1. First: [What to build first and why]
-2. Then: [What comes next and why]
-3. Later: [What can wait and why]
-
-EXPERTISE NEEDED:
-
-- [Domain expert role]: For [specific areas]
-- [Technical expert role]: For [specific requirements]
-
-TIMELINE CONSIDERATIONS:
-
-- Allow [time] for [process/approval]
-- Start [requirement] early because [reason]
-- [Requirement] can be parallel with development
-
-Do these recommendations feel right? What would you adjust?"</action>
-
-<template-output>recommendations</template-output>
-</step>
-
-<step n="10" goal="Package for PRD integration">
-<action>Create clear handoff to PRD workflow
-
-"I've captured everything in domain-brief.md. Here's the summary for your PRD:
-
-DOMAIN: {identified_domain}
-COMPLEXITY: {high|medium}
-
-KEY REQUIREMENTS TO INCORPORATE:
-
-- [Requirement 1 - critical for domain]
-- [Requirement 2 - critical for domain]
-- [Requirement 3 - important consideration]
-
-IMPACTS ON:
-
-- Functional Requirements: [How domain affects features]
-- Non-Functional Requirements: [Performance, security, etc.]
-- Architecture: [System design considerations]
-- Development: [Process and timeline impacts]
-
-REFERENCE DOCS:
-
-- Full domain analysis: domain-brief.md
-- Regulations researched: [List with links]
-- Standards referenced: [List with links]
-
-When you return to PRD, reference this brief for domain context.
-
-Any final questions before we wrap up the domain research?"</action>
-
-<template-output>summary_for_prd</template-output>
-</step>
-
-<step n="11" goal="Close with next steps">
-<output>**✅ Domain Research Complete, {user_name}!**
-
-We've explored the {domain} aspects of your project together and documented critical requirements.
-
-**Created:**
-
-- **domain-brief.md** - Complete domain analysis with requirements and recommendations
-
-**Key Findings:**
-
-- Primary domain: {domain}
-- Complexity level: {complexity}
-- Critical requirements: {count} identified
-- Risks identified: {count} with mitigation strategies
-
-**Next Steps:**
-
-1. Return to PRD workflow with this domain context
-2. Domain requirements will shape your functional requirements
-3. Reference domain-brief.md for detailed requirements
-
-**Remember:**
-{most_important_finding}
-
-The domain research will ensure your PRD captures not just what to build, but HOW to build it correctly for {domain}.
-</output>
-</step>
-
-</workflow>

package/.bmad/bmm/workflows/1-analysis/domain-research/template.md

@@ -1,180 +0,0 @@
-# Domain Brief - {project_name}
-
-Generated: {date}
-Domain: {primary_domain}
-Complexity: {complexity_level}
-
-## Executive Summary
-
-{brief_overview_of_domain_research_findings}
-
-## Domain Overview
-
-### Industry Context
-
-{domain_overview}
-
-### Regulatory Landscape
-
-{regulatory_environment}
-
-### Key Stakeholders
-
-{stakeholder_analysis}
-
-## Critical Concerns
-
-### Compliance Requirements
-
-{concern_mapping}
-
-### Technical Constraints
-
-{technical_limitations_from_domain}
-
-### Safety/Risk Considerations
-
-{safety_risk_factors}
-
-## Regulatory Requirements
-
-{regulatory_requirements}
-
-## Industry Standards
-
-{industry_standards}
-
-## Practical Implications
-
-### Architecture Impact
-
-{architecture_implications}
-
-### Development Impact
-
-{development_implications}
-
-### Timeline Impact
-
-{timeline_implications}
-
-### Cost Impact
-
-{cost_implications}
-
-## Domain Patterns
-
-### Established Patterns
-
-{domain_patterns}
-
-### Innovation Opportunities
-
-{innovation_notes}
-
-## Risk Assessment
-
-### Identified Risks
-
-{risk_assessment}
-
-### Mitigation Strategies
-
-{mitigation_approaches}
-
-## Validation Strategy
-
-### Compliance Validation
-
-{compliance_validation_approach}
-
-### Technical Validation
-
-{technical_validation_approach}
-
-### Domain Expert Validation
-
-{expert_validation_approach}
-
-## Key Decisions
-
-{key_decisions}
-
-## Recommendations
-
-### Must Have (Critical)
-
-{critical_requirements}
-
-### Should Have (Important)
-
-{important_requirements}
-
-### Consider (Nice-to-Have)
-
-{optional_enhancements}
-
-### Development Sequence
-
-{recommended_sequence}
-
-### Required Expertise
-
-{expertise_needed}
-
-## PRD Integration Guide
-
-### Summary for PRD
-
-{summary_for_prd}
-
-### Requirements to Incorporate
-
-- {requirement_1}
-- {requirement_2}
-- {requirement_3}
-
-### Architecture Considerations
-
-- {architecture_consideration_1}
-- {architecture_consideration_2}
-
-### Development Considerations
-
-- {development_consideration_1}
-- {development_consideration_2}
-
-## References
-
-### Regulations Researched
-
-- {regulation_1_with_link}
-- {regulation_2_with_link}
-
-### Standards Referenced
-
-- {standard_1_with_link}
-- {standard_2_with_link}
-
-### Additional Resources
-
-- {resource_1}
-- {resource_2}
-
-## Appendix
-
-### Research Notes
-
-{detailed_research_notes}
-
-### Conversation Highlights
-
-{key_discussion_points_with_user}
-
-### Open Questions
-
-{questions_requiring_further_research}
-
----
-
-_This domain brief was created through collaborative research between {user_name} and the AI facilitator. It should be referenced during PRD creation and updated as new domain insights emerge._

package/.bmad/bmm/workflows/1-analysis/domain-research/workflow.yaml

@@ -1,40 +0,0 @@
-# Domain Research Workflow Configuration
-name: domain-research
-description: "Collaborative exploration of domain-specific requirements, regulations, and patterns for complex projects"
-author: "BMad"
-
-# Critical variables from config
-config_source: "{project-root}/.bmad/bmm/config.yaml"
-output_folder: "{config_source}:output_folder"
-user_name: "{config_source}:user_name"
-communication_language: "{config_source}:communication_language"
-document_output_language: "{config_source}:document_output_language"
-user_skill_level: "{config_source}:user_skill_level"
-date: system-generated
-
-# Module path and component files
-installed_path: "{project-root}/.bmad/bmm/workflows/1-analysis/domain-research"
-instructions: "{installed_path}/instructions.md"
-template: "{installed_path}/template.md"
-
-# Optional knowledge base (if exists)
-domain_knowledge_base: "{installed_path}/domain-knowledge-base.md"
-
-# Output configuration
-default_output_file: "{output_folder}/domain-brief.md"
-
-# Workflow metadata
-version: "6.0.0-alpha"
-category: "analysis"
-complexity: "medium"
-execution_time: "30-45 minutes"
-prerequisites:
-  - "Basic project understanding"
-when_to_use:
-  - "Complex regulated domains (healthcare, finance, aerospace)"
-  - "Novel technical domains requiring deep understanding"
-  - "Before PRD when domain expertise needed"
-  - "When compliance and regulations matter"
-
-standalone: true
-# Web bundle configuration for standalone deployment