Merge branch 'bmad-code-org:v6-alpha' into v6-alpha

README.md

@@ -253,8 +253,9 @@ What used to be tasks and create-doc templates are now all workflows! Simpler, y
 
 - [Workflow Creation Guide](src/modules/bmb/workflows/create-workflow/workflow-creation-guide.md)
 
-### Installer Changes
+### Installer & Bundler Documentation
 
+- **[CLI Tool Guide](tools/cli/README.md)** - Complete guide to how the installer, bundler, and agent compilation system works
 - [IDE Injections](docs/installers-bundlers/ide-injections)
 - [Installers Modules Platforms References](docs/installers-bundlers/installers-modules-platforms-reference)
 - [Web Bundler Usage](docs/installers-bundlers/web-bundler-usage)

bmad/_cfg/files-manifest.csv

@@ -2,7 +2,7 @@ type,name,module,path,hash
 "csv","agent-manifest","_cfg","bmad/_cfg/agent-manifest.csv","4d7fb4998ddad86011c22b5c579747d9247edeab75a92406c2b10e1bc40d3333"
 "csv","task-manifest","_cfg","bmad/_cfg/task-manifest.csv","46f98b1753914dc6193c9ca8b6427fadc9a6d71747cdc8f5159792576c004b60"
 "csv","workflow-manifest","_cfg","bmad/_cfg/workflow-manifest.csv","ad9ffffd019cbe86a43b1e1b9bec61ee08364060d81b507b219505397c62d1da"
-"yaml","manifest","_cfg","bmad/_cfg/manifest.yaml","30e2eb0b597c01b8ccb1bde550fc5d43dd98d660c81d408252e72e3e93ed916c"
+"yaml","manifest","_cfg","bmad/_cfg/manifest.yaml","fc21d1a017633c845a71e14e079d6da84b5aa096ddb9aacd10073f58c361efc6"
 "js","installer","bmb","bmad/bmb/workflows/create-module/installer-templates/installer.js","a539cd5266471dab9359bd3ed849d7b45c5de842a9d5869f8332a5a8bb81fad5"
 "md","agent-architecture","bmb","bmad/bmb/workflows/create-agent/agent-architecture.md","ea570cf9893c08d3b9519291c89848d550506a8d831a37eb87f60f1e09980e7f"
 "md","agent-command-patterns","bmb","bmad/bmb/workflows/create-agent/agent-command-patterns.md","1dbc414c0c6c9e6b54fb0553f65a28743a26e2a172c35b79fc3dc350d50a378d"
@@ -27,7 +27,7 @@ type,name,module,path,hash
 "md","instructions","bmb","bmad/bmb/workflows/create-module/instructions.md","5f321690f4774058516d3d65693224e759ec87d98d7a1a281b38222ab963ca8b"
 "md","instructions","bmb","bmad/bmb/workflows/create-workflow/instructions.md","d739389d9eb20e9297737a8cfca7a8bdc084c778b6512a2433442c651d0ea871"
 "md","instructions","bmb","bmad/bmb/workflows/create-workflow/workflow-template/instructions.md","daf3d312e5a60d7c4cbc308014e3c69eeeddd70bd41bd139d328318da1e3ecb2"
-"md","instructions","bmb","bmad/bmb/workflows/edit-workflow/instructions.md","d35f4b20fd8d22bff1374dfa1bee7aa037d5d097dd2e8763b3b2792fbef4a97d"
+"md","instructions","bmb","bmad/bmb/workflows/edit-workflow/instructions.md","a6f34e3117d086213b7b58eb4fa0d3c2d0af943e8d9299be4a9b91d4fd444f19"
 "md","instructions","bmb","bmad/bmb/workflows/module-brief/instructions.md","e2275373850ea0745f396ad0c3aa192f06081b52d98777650f6b645333b62926"
 "md","instructions","bmb","bmad/bmb/workflows/redoc/instructions.md","fccc798c8904c35807bb6a723650c10aa19ee74ab5a1e44d1b242bd125d3e80e"
 "md","module-structure","bmb","bmad/bmb/workflows/create-module/module-structure.md","9970768af75da79b4cdef78096c751e70a3a00194af58dca7ed58a79d324423f"
@@ -35,15 +35,15 @@ type,name,module,path,hash
 "md","README","bmb","bmad/bmb/workflows/convert-legacy/README.md","3391972c16b7234dae61b2d06daeb6310d1760117ece57abcca0c178c4c33eea"
 "md","README","bmb","bmad/bmb/workflows/create-agent/README.md","cc1d51e22c425e005ddbe285510ff5a6fc6cf1e40d0ffe5ff421c1efbcbe94c0"
 "md","README","bmb","bmad/bmb/workflows/create-module/README.md","cdacbe6c4896fd02714b598e709b785af38d41d7e42d39802d695617fe221b39"
-"md","README","bmb","bmad/bmb/workflows/create-workflow/README.md","56501b159b18e051ebcc78b4039ad614e44d172fe06dce679e9b24122a4929b5"
+"md","README","bmb","bmad/bmb/workflows/create-workflow/README.md","5b868030bf6fcb597bd3ff65bff30ccaf708b735ebb13bd0595fd8692258f425"
-"md","README","bmb","bmad/bmb/workflows/edit-workflow/README.md","2141d42d922701281d4d92e435d4690c462c53cf31e8307c87252f0cabec4987"
+"md","README","bmb","bmad/bmb/workflows/edit-workflow/README.md","a1c2da9b67d18ba9adc107be91e3d142ecb820b2054dd69d2538c9ceee9eb89a"
 "md","README","bmb","bmad/bmb/workflows/module-brief/README.md","05772db9095db7b4944e9fc47a049a3609c506be697537fd5fd9e409c10b92f4"
 "md","README","bmb","bmad/bmb/workflows/redoc/README.md","a1b7e02427cf252bca69a8a1ee0f554844a6a01b5d568d74f494c71542056173"
 "md","template","bmb","bmad/bmb/workflows/create-workflow/workflow-template/template.md","c98f65a122035b456f1cbb2df6ecaf06aa442746d93a29d1d0ed2fc9274a43ee"
 "md","template","bmb","bmad/bmb/workflows/module-brief/template.md","7d1ad5ec40b06510fcbb0a3da8ea32aefa493e5b04c3a2bba90ce5685b894275"
 "md","workflow-creation-guide","bmb","bmad/bmb/workflows/create-workflow/workflow-creation-guide.md","3233f2db6e0dec0250780840f95b38f7bfe9390b045a497d66f94f82d7ffb1af"
 "yaml","bmad-builder.agent","bmb","bmad/bmb/agents/bmad-builder.agent.yaml",""
-"yaml","config","bmb","bmad/bmb/config.yaml","7803b96af6ae20de1a3703424cd37365a2cb0f462a09f0b7e7b253143b234957"
+"yaml","config","bmb","bmad/bmb/config.yaml","3baf3d7fee63f22959be86f2c310f3a4cc5afa748cd707e939ce3ee83745999f"
 "yaml","install-module-config","bmb","bmad/bmb/workflows/create-module/installer-templates/install-module-config.yaml","69c03628b04600f76aa1aa136094d59514f8eb900529114f7233dc28f2d5302d"
 "yaml","workflow","bmb","bmad/bmb/workflows/audit-workflow/workflow.yaml","5b8d26675e30d006f57631be2f42b00575b0d00f87abea408bf0afd09d73826e"
 "yaml","workflow","bmb","bmad/bmb/workflows/convert-legacy/workflow.yaml","c31cee9cc0d457b25954554d7620c7455b3f1b5aa5b5d72fbc765ea7902c3c0c"
@@ -67,6 +67,6 @@ type,name,module,path,hash
 "xml","validate-workflow","core","bmad/core/tasks/validate-workflow.xml","1244874db38a55d957995ed224812ef868ff1451d8e1901cc5887dd0eb1c236e"
 "xml","workflow","core","bmad/core/tasks/workflow.xml","0b2b7bd184e099869174cc8d9125fce08bcd3fd64fad50ff835a42eccf6620e2"
 "yaml","bmad-master.agent","core","bmad/core/agents/bmad-master.agent.yaml",""
-"yaml","config","core","bmad/core/config.yaml","41e3bff96c4980261c2a17754a6ae17e5aa8ff2f05511b57431279e7a6ef5b4a"
+"yaml","config","core","bmad/core/config.yaml","c5267c6e72f5d79344464082c2c73ddec88b7433705d38002993fe745c3cbe23"
 "yaml","workflow","core","bmad/core/workflows/brainstorming/workflow.yaml","52db57678606b98ec47e603c253c40f98815c49417df3088412bbbd8aa7f34d3"
 "yaml","workflow","core","bmad/core/workflows/party-mode/workflow.yaml","979e986780ce919abbdae89b3bd264d34a1436036a7eb6f82f40e59c9ce7c2e8"

bmad/_cfg/manifest.yaml

@@ -1,9 +1,10 @@
 installation:
   version: 6.0.0-alpha.0
-  installDate: "2025-10-17T02:50:26.088Z"
+  installDate: "2025-10-18T03:30:57.841Z"
-  lastUpdated: "2025-10-17T02:50:26.088Z"
+  lastUpdated: "2025-10-18T03:30:57.841Z"
 modules:
   - core
   - bmb
 ides:
   - claude-code
+  - codex

bmad/bmb/config.yaml

@@ -1,7 +1,7 @@
 # BMB Module Configuration
 # Generated by BMAD installer
 # Version: 6.0.0-alpha.0
-# Date: 2025-10-17T02:50:26.084Z
+# Date: 2025-10-18T03:30:57.837Z
 
 custom_agent_location: "{project-root}/bmad/agents"
 custom_workflow_location: "{project-root}/bmad/workflows"

bmad/bmb/workflows/create-workflow/README.md

@@ -56,6 +56,67 @@ create-workflow/
     └── README.md
 ```
 
+## Understanding Instruction Styles
+
+One of the most important decisions when creating a workflow is choosing the **instruction style** - how the workflow guides the AI's interaction with users.
+
+### Intent-Based vs Prescriptive Instructions
+
+**Intent-Based (Recommended for most workflows)**
+
+Guides the LLM with goals and principles, allowing natural conversation adaptation.
+
+- **More flexible and conversational** - AI adapts questions to context
+- **Better for complex discovery** - Requirements gathering, creative exploration
+- **Quality over consistency** - Focus on deep understanding
+- **Example**: `<action>Guide user to define their target audience with specific demographics and needs</action>`
+
+**Best for:**
+
+- Complex discovery processes (user research, requirements)
+- Creative brainstorming and ideation
+- Iterative refinement workflows
+- When adaptation to context matters
+- Workflows requiring nuanced understanding
+
+**Prescriptive**
+
+Provides exact wording for questions and structured options.
+
+- **More controlled and predictable** - Same questions every time
+- **Better for simple data collection** - Platform choices, yes/no decisions
+- **Consistency over quality** - Standardized execution
+- **Example**: `<ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask>`
+
+**Best for:**
+
+- Simple data collection (platform, format, binary choices)
+- Compliance verification and standards
+- Configuration with finite options
+- Quick setup wizards
+- When consistency is critical
+
+### Best Practice: Mix Both Styles
+
+The most effective workflows use **both styles strategically**:
+
+```xml
+<!-- Intent-based workflow with prescriptive moments -->
+<step n="1" goal="Understand user vision">
+  <action>Explore the user's vision, uncovering creative intent and target experience</action>
+</step>
+
+<step n="2" goal="Capture basic metadata">
+  <ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask>
+</step>
+
+<step n="3" goal="Deep dive into details">
+  <action>Guide user to articulate their core approach and unique aspects</action>
+</step>
+```
+
+**During workflow creation**, you'll be asked to choose a **primary style preference** - this sets the default approach, but you can (and should) use the other style when it makes more sense for specific steps.
+
 ## Workflow Process
 
 ### Phase 0: Optional Brainstorming (Step -1)

bmad/bmb/workflows/edit-workflow/README.md

@@ -43,8 +43,64 @@ Or through a BMAD agent:
 2. **Prioritized Issues**: Identifies and ranks issues by importance
 3. **Guided Editing**: Step-by-step process with explanations
 4. **Best Practices**: Ensures all edits follow BMAD conventions
-5. **Validation**: Checks all changes for correctness
+5. **Instruction Style Optimization**: Convert between intent-based and prescriptive styles
-6. **Change Tracking**: Documents what was modified and why
+6. **Validation**: Checks all changes for correctness
+7. **Change Tracking**: Documents what was modified and why
+
+## Understanding Instruction Styles
+
+When editing workflows, one powerful option is **adjusting the instruction style** to better match the workflow's purpose.
+
+### Intent-Based vs Prescriptive Instructions
+
+**Intent-Based (Recommended for most workflows)**
+
+Guides the AI with goals and principles, allowing flexible conversation.
+
+- **More flexible and conversational** - AI adapts to user responses
+- **Better for complex discovery** - Requirements gathering, creative exploration
+- **Quality over consistency** - Deep understanding matters more
+- **Example**: `<action>Guide user to define their target audience with specific demographics and needs</action>`
+
+**When to use:**
+
+- Complex discovery processes (user research, requirements)
+- Creative brainstorming and ideation
+- Iterative refinement workflows
+- Workflows requiring nuanced understanding
+
+**Prescriptive**
+
+Provides exact questions with structured options.
+
+- **More controlled and predictable** - Consistent questions every time
+- **Better for simple data collection** - Platform, format, yes/no choices
+- **Consistency over quality** - Same execution every run
+- **Example**: `<ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask>`
+
+**When to use:**
+
+- Simple data collection (platform, format, binary choices)
+- Compliance verification and standards adherence
+- Configuration with finite options
+- Quick setup wizards
+
+### Edit Workflow's Style Adjustment Feature
+
+The **"Adjust instruction style"** editing option (menu option 11) helps you:
+
+1. **Analyze current style** - Identifies whether workflow is primarily intent-based or prescriptive
+2. **Convert between styles** - Transform prescriptive steps to intent-based (or vice versa)
+3. **Optimize the mix** - Intelligently recommend the best style for each step
+4. **Step-by-step control** - Review and decide on each step individually
+
+**Common scenarios:**
+
+- **Make workflow more conversational**: Convert rigid <ask> tags to flexible <action> tags for complex steps
+- **Make workflow more consistent**: Convert open-ended <action> tags to structured <ask> tags for simple data collection
+- **Balance both approaches**: Use intent-based for discovery, prescriptive for simple choices
+
+This feature is especially valuable when converting legacy workflows or adapting workflows for different use cases.
 
 ## Workflow Steps
 

bmad/bmb/workflows/edit-workflow/instructions.md

@@ -77,9 +77,10 @@ Present the editing menu to the user:
 8. **Configure web bundle** - Add/update web bundle for deployment
 9. **Remove bloat** - Delete unused yaml fields, duplicate values
 10. **Optimize for clarity** - Improve descriptions, add examples
-11. **Full review and update** - Comprehensive improvements across all files
+11. **Adjust instruction style** - Convert between intent-based and prescriptive styles
+12. **Full review and update** - Comprehensive improvements across all files
 
-<ask>Select an option (1-11) or describe a custom edit:</ask>
+<ask>Select an option (1-12) or describe a custom edit:</ask>
 </step>
 
 <step n="4" goal="Load relevant documentation">
@@ -127,7 +128,16 @@ date: system-generated
 <check>If fixing critical issues:</check>
 <action>Load the workflow execution engine documentation</action>
 <action>Verify all required elements are present</action>
-</step>
+
+<check>If adjusting instruction style (option 11):</check>
+<action>Analyze current instruction style in instructions.md:</action>
+
+- Count <action> tags vs <ask> tags
+- Identify goal-oriented language ("guide", "explore", "help") vs prescriptive ("choose", "select", "specify")
+- Assess whether steps are open-ended or structured with specific options
+  <action>Determine current dominant style: intent-based, prescriptive, or mixed</action>
+  <action>Load the instruction style guide section from create-workflow</action>
+  </step>
 
 <step n="5" goal="Perform edits" repeat="until-complete">
 Based on the selected focus area:
@@ -161,6 +171,127 @@ If updating existing web bundle:
 3. Remove any config dependencies
 4. Update file list with newly referenced files
 
+<check>If adjusting instruction style (option 11):</check>
+<action>Present current style analysis to user:</action>
+
+**Current Instruction Style Analysis:**
+
+- Current dominant style: {{detected_style}}
+- Intent-based elements: {{intent_count}}
+- Prescriptive elements: {{prescriptive_count}}
+
+**Understanding Intent-Based vs Prescriptive:**
+
+**1. Intent-Based (Recommended)** - Guide the LLM with goals and principles, let it adapt conversations naturally
+
+- More flexible and conversational
+- LLM chooses appropriate questions based on context
+- Better for complex discovery and iterative refinement
+- Example: `<action>Guide user to define their target audience with specific demographics and needs</action>`
+
+**2. Prescriptive** - Provide exact wording for questions and options
+
+- More controlled and predictable
+- Ensures consistency across runs
+- Better for simple data collection or specific compliance needs
+- Example: `<ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask>`
+
+**When to use Intent-Based:**
+
+- Complex discovery processes (user research, requirements gathering)
+- Creative brainstorming and ideation
+- Iterative refinement workflows
+- When user input quality matters more than consistency
+- Workflows requiring adaptation to context
+
+**When to use Prescriptive:**
+
+- Simple data collection (platform, format, yes/no choices)
+- Compliance verification and standards adherence
+- Configuration with finite options
+- When consistency is critical across all executions
+- Quick setup wizards
+
+**Best Practice: Mix Both Styles**
+
+Even workflows with a primary style should use the other when appropriate. For example:
+
+```xml
+<!-- Intent-based workflow with prescriptive moments -->
+<step n="1" goal="Understand user vision">
+  <action>Explore the user's vision, uncovering their creative intent and target experience</action>
+</step>
+
+<step n="2" goal="Capture basic metadata">
+  <ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask> <!-- Prescriptive for simple choice -->
+</step>
+
+<step n="3" goal="Deep dive into details">
+  <action>Guide user to articulate their approach, exploring mechanics and unique aspects</action> <!-- Back to intent-based -->
+</step>
+```
+
+<ask>What would you like to do?
+
+1. **Make more intent-based** - Convert prescriptive <ask> tags to goal-oriented <action> tags where appropriate
+2. **Make more prescriptive** - Convert open-ended <action> tags to specific <ask> tags with options
+3. **Optimize mix** - Use intent-based for complex steps, prescriptive for simple data collection
+4. **Review specific steps** - Show me each step and let me decide individually
+5. **Cancel** - Keep current style
+
+Select option (1-5):</ask>
+
+<action>Store user's style adjustment preference as {{style_adjustment_choice}}</action>
+
+<check>If choice is 1 (make more intent-based):</check>
+<action>Identify prescriptive <ask> tags that could be converted to intent-based <action> tags</action>
+<action>For each candidate conversion:
+
+- Show original prescriptive version
+- Suggest intent-based alternative focused on goals
+- Explain the benefit of the conversion
+- Ask for approval
+  </action>
+  <action>Apply approved conversions</action>
+
+<check>If choice is 2 (make more prescriptive):</check>
+<action>Identify open-ended <action> tags that could be converted to prescriptive <ask> tags</action>
+<action>For each candidate conversion:
+
+- Show original intent-based version
+- Suggest prescriptive alternative with specific options
+- Explain when prescriptive is better here
+- Ask for approval
+  </action>
+  <action>Apply approved conversions</action>
+
+<check>If choice is 3 (optimize mix):</check>
+<action>Analyze each step for complexity and purpose</action>
+<action>Recommend style for each step:
+
+- Simple data collection → Prescriptive
+- Complex discovery → Intent-based
+- Binary decisions → Prescriptive
+- Creative exploration → Intent-based
+- Standards/compliance → Prescriptive
+- Iterative refinement → Intent-based
+  </action>
+  <action>Show recommendations with reasoning</action>
+  <action>Apply approved optimizations</action>
+
+<check>If choice is 4 (review specific steps):</check>
+<action>Present each step one at a time</action>
+<action>For each step:
+
+- Show current instruction text
+- Identify current style (intent-based, prescriptive, or mixed)
+- Offer to keep, convert to intent-based, or convert to prescriptive
+- Apply user's choice before moving to next step
+  </action>
+
+<check>If choice is 5 (cancel):</check>
+<goto step="3">Return to editing menu</goto>
+
 <action>Show the current content that will be edited</action>
 <action>Explain the proposed changes and why they improve the workflow</action>
 <action>Generate the updated content following all conventions from the guide</action>

bmad/core/config.yaml

@@ -1,7 +1,7 @@
 # CORE Module Configuration
 # Generated by BMAD installer
 # Version: 6.0.0-alpha.0
-# Date: 2025-10-17T02:50:26.085Z
+# Date: 2025-10-18T03:30:57.838Z
 
 user_name: BMad
 communication_language: English

bmad/docs/codex-instructions.md

@@ -0,0 +1,21 @@
+# BMAD Method - Codex Instructions
+
+## Activating Agents
+
+BMAD agents, tasks and workflows are installed as custom prompts in
+`$CODEX_HOME/prompts/bmad-*.md` files. If `CODEX_HOME` is not set, it
+defaults to `$HOME/.codex/`.
+
+### Examples
+
+```
+/bmad-bmm-agents-dev - Activate development agent
+/bmad-bmm-agents-architect - Activate architect agent
+/bmad-bmm-workflows-dev-story - Execute dev-story workflow
+```
+
+### Notes
+
+Prompts are autocompleted when you type /
+Agent remains active for the conversation
+Start a new conversation to switch agents

src/core/_module-installer/install-menu-config.yaml

@@ -8,12 +8,17 @@ prompt:
 # This is injected into the custom agent activation rules
 user_name:
   prompt: "What is your name?"
-  default: "BMad User"
+  default: "BMad"
   result: "{value}"
 
-# This is injected into the custom agent activation rules
+# This is injected into the custom agent activation rules and most workflows
 communication_language:
-  prompt: "Preferred language?"
+  prompt: "Preferred Chat Language?"
+  default: "English"
+  result: "{value}"
+
+document_output_language:
+  prompt: "Preferred Document Output Language?"
   default: "English"
   result: "{value}"
 

src/modules/bmb/workflows/create-workflow/README.md

@@ -56,6 +56,67 @@ create-workflow/
     └── README.md
 ```
 
+## Understanding Instruction Styles
+
+One of the most important decisions when creating a workflow is choosing the **instruction style** - how the workflow guides the AI's interaction with users.
+
+### Intent-Based vs Prescriptive Instructions
+
+**Intent-Based (Recommended for most workflows)**
+
+Guides the LLM with goals and principles, allowing natural conversation adaptation.
+
+- **More flexible and conversational** - AI adapts questions to context
+- **Better for complex discovery** - Requirements gathering, creative exploration
+- **Quality over consistency** - Focus on deep understanding
+- **Example**: `<action>Guide user to define their target audience with specific demographics and needs</action>`
+
+**Best for:**
+
+- Complex discovery processes (user research, requirements)
+- Creative brainstorming and ideation
+- Iterative refinement workflows
+- When adaptation to context matters
+- Workflows requiring nuanced understanding
+
+**Prescriptive**
+
+Provides exact wording for questions and structured options.
+
+- **More controlled and predictable** - Same questions every time
+- **Better for simple data collection** - Platform choices, yes/no decisions
+- **Consistency over quality** - Standardized execution
+- **Example**: `<ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask>`
+
+**Best for:**
+
+- Simple data collection (platform, format, binary choices)
+- Compliance verification and standards
+- Configuration with finite options
+- Quick setup wizards
+- When consistency is critical
+
+### Best Practice: Mix Both Styles
+
+The most effective workflows use **both styles strategically**:
+
+```xml
+<!-- Intent-based workflow with prescriptive moments -->
+<step n="1" goal="Understand user vision">
+  <action>Explore the user's vision, uncovering creative intent and target experience</action>
+</step>
+
+<step n="2" goal="Capture basic metadata">
+  <ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask>
+</step>
+
+<step n="3" goal="Deep dive into details">
+  <action>Guide user to articulate their core approach and unique aspects</action>
+</step>
+```
+
+**During workflow creation**, you'll be asked to choose a **primary style preference** - this sets the default approach, but you can (and should) use the other style when it makes more sense for specific steps.
+
 ## Workflow Process
 
 ### Phase 0: Optional Brainstorming (Step -1)

src/modules/bmb/workflows/edit-workflow/README.md

@@ -43,8 +43,64 @@ Or through a BMAD agent:
 2. **Prioritized Issues**: Identifies and ranks issues by importance
 3. **Guided Editing**: Step-by-step process with explanations
 4. **Best Practices**: Ensures all edits follow BMAD conventions
-5. **Validation**: Checks all changes for correctness
+5. **Instruction Style Optimization**: Convert between intent-based and prescriptive styles
-6. **Change Tracking**: Documents what was modified and why
+6. **Validation**: Checks all changes for correctness
+7. **Change Tracking**: Documents what was modified and why
+
+## Understanding Instruction Styles
+
+When editing workflows, one powerful option is **adjusting the instruction style** to better match the workflow's purpose.
+
+### Intent-Based vs Prescriptive Instructions
+
+**Intent-Based (Recommended for most workflows)**
+
+Guides the AI with goals and principles, allowing flexible conversation.
+
+- **More flexible and conversational** - AI adapts to user responses
+- **Better for complex discovery** - Requirements gathering, creative exploration
+- **Quality over consistency** - Deep understanding matters more
+- **Example**: `<action>Guide user to define their target audience with specific demographics and needs</action>`
+
+**When to use:**
+
+- Complex discovery processes (user research, requirements)
+- Creative brainstorming and ideation
+- Iterative refinement workflows
+- Workflows requiring nuanced understanding
+
+**Prescriptive**
+
+Provides exact questions with structured options.
+
+- **More controlled and predictable** - Consistent questions every time
+- **Better for simple data collection** - Platform, format, yes/no choices
+- **Consistency over quality** - Same execution every run
+- **Example**: `<ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask>`
+
+**When to use:**
+
+- Simple data collection (platform, format, binary choices)
+- Compliance verification and standards adherence
+- Configuration with finite options
+- Quick setup wizards
+
+### Edit Workflow's Style Adjustment Feature
+
+The **"Adjust instruction style"** editing option (menu option 11) helps you:
+
+1. **Analyze current style** - Identifies whether workflow is primarily intent-based or prescriptive
+2. **Convert between styles** - Transform prescriptive steps to intent-based (or vice versa)
+3. **Optimize the mix** - Intelligently recommend the best style for each step
+4. **Step-by-step control** - Review and decide on each step individually
+
+**Common scenarios:**
+
+- **Make workflow more conversational**: Convert rigid <ask> tags to flexible <action> tags for complex steps
+- **Make workflow more consistent**: Convert open-ended <action> tags to structured <ask> tags for simple data collection
+- **Balance both approaches**: Use intent-based for discovery, prescriptive for simple choices
+
+This feature is especially valuable when converting legacy workflows or adapting workflows for different use cases.
 
 ## Workflow Steps
 

src/modules/bmb/workflows/edit-workflow/instructions.md

@@ -77,9 +77,10 @@ Present the editing menu to the user:
 8. **Configure web bundle** - Add/update web bundle for deployment
 9. **Remove bloat** - Delete unused yaml fields, duplicate values
 10. **Optimize for clarity** - Improve descriptions, add examples
-11. **Full review and update** - Comprehensive improvements across all files
+11. **Adjust instruction style** - Convert between intent-based and prescriptive styles
+12. **Full review and update** - Comprehensive improvements across all files
 
-<ask>Select an option (1-11) or describe a custom edit:</ask>
+<ask>Select an option (1-12) or describe a custom edit:</ask>
 </step>
 
 <step n="4" goal="Load relevant documentation">
@@ -127,7 +128,16 @@ date: system-generated
 <check>If fixing critical issues:</check>
 <action>Load the workflow execution engine documentation</action>
 <action>Verify all required elements are present</action>
-</step>
+
+<check>If adjusting instruction style (option 11):</check>
+<action>Analyze current instruction style in instructions.md:</action>
+
+- Count <action> tags vs <ask> tags
+- Identify goal-oriented language ("guide", "explore", "help") vs prescriptive ("choose", "select", "specify")
+- Assess whether steps are open-ended or structured with specific options
+  <action>Determine current dominant style: intent-based, prescriptive, or mixed</action>
+  <action>Load the instruction style guide section from create-workflow</action>
+  </step>
 
 <step n="5" goal="Perform edits" repeat="until-complete">
 Based on the selected focus area:
@@ -161,6 +171,127 @@ If updating existing web bundle:
 3. Remove any config dependencies
 4. Update file list with newly referenced files
 
+<check>If adjusting instruction style (option 11):</check>
+<action>Present current style analysis to user:</action>
+
+**Current Instruction Style Analysis:**
+
+- Current dominant style: {{detected_style}}
+- Intent-based elements: {{intent_count}}
+- Prescriptive elements: {{prescriptive_count}}
+
+**Understanding Intent-Based vs Prescriptive:**
+
+**1. Intent-Based (Recommended)** - Guide the LLM with goals and principles, let it adapt conversations naturally
+
+- More flexible and conversational
+- LLM chooses appropriate questions based on context
+- Better for complex discovery and iterative refinement
+- Example: `<action>Guide user to define their target audience with specific demographics and needs</action>`
+
+**2. Prescriptive** - Provide exact wording for questions and options
+
+- More controlled and predictable
+- Ensures consistency across runs
+- Better for simple data collection or specific compliance needs
+- Example: `<ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask>`
+
+**When to use Intent-Based:**
+
+- Complex discovery processes (user research, requirements gathering)
+- Creative brainstorming and ideation
+- Iterative refinement workflows
+- When user input quality matters more than consistency
+- Workflows requiring adaptation to context
+
+**When to use Prescriptive:**
+
+- Simple data collection (platform, format, yes/no choices)
+- Compliance verification and standards adherence
+- Configuration with finite options
+- When consistency is critical across all executions
+- Quick setup wizards
+
+**Best Practice: Mix Both Styles**
+
+Even workflows with a primary style should use the other when appropriate. For example:
+
+```xml
+<!-- Intent-based workflow with prescriptive moments -->
+<step n="1" goal="Understand user vision">
+  <action>Explore the user's vision, uncovering their creative intent and target experience</action>
+</step>
+
+<step n="2" goal="Capture basic metadata">
+  <ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask> <!-- Prescriptive for simple choice -->
+</step>
+
+<step n="3" goal="Deep dive into details">
+  <action>Guide user to articulate their approach, exploring mechanics and unique aspects</action> <!-- Back to intent-based -->
+</step>
+```
+
+<ask>What would you like to do?
+
+1. **Make more intent-based** - Convert prescriptive <ask> tags to goal-oriented <action> tags where appropriate
+2. **Make more prescriptive** - Convert open-ended <action> tags to specific <ask> tags with options
+3. **Optimize mix** - Use intent-based for complex steps, prescriptive for simple data collection
+4. **Review specific steps** - Show me each step and let me decide individually
+5. **Cancel** - Keep current style
+
+Select option (1-5):</ask>
+
+<action>Store user's style adjustment preference as {{style_adjustment_choice}}</action>
+
+<check>If choice is 1 (make more intent-based):</check>
+<action>Identify prescriptive <ask> tags that could be converted to intent-based <action> tags</action>
+<action>For each candidate conversion:
+
+- Show original prescriptive version
+- Suggest intent-based alternative focused on goals
+- Explain the benefit of the conversion
+- Ask for approval
+  </action>
+  <action>Apply approved conversions</action>
+
+<check>If choice is 2 (make more prescriptive):</check>
+<action>Identify open-ended <action> tags that could be converted to prescriptive <ask> tags</action>
+<action>For each candidate conversion:
+
+- Show original intent-based version
+- Suggest prescriptive alternative with specific options
+- Explain when prescriptive is better here
+- Ask for approval
+  </action>
+  <action>Apply approved conversions</action>
+
+<check>If choice is 3 (optimize mix):</check>
+<action>Analyze each step for complexity and purpose</action>
+<action>Recommend style for each step:
+
+- Simple data collection → Prescriptive
+- Complex discovery → Intent-based
+- Binary decisions → Prescriptive
+- Creative exploration → Intent-based
+- Standards/compliance → Prescriptive
+- Iterative refinement → Intent-based
+  </action>
+  <action>Show recommendations with reasoning</action>
+  <action>Apply approved optimizations</action>
+
+<check>If choice is 4 (review specific steps):</check>
+<action>Present each step one at a time</action>
+<action>For each step:
+
+- Show current instruction text
+- Identify current style (intent-based, prescriptive, or mixed)
+- Offer to keep, convert to intent-based, or convert to prescriptive
+- Apply user's choice before moving to next step
+  </action>
+
+<check>If choice is 5 (cancel):</check>
+<goto step="3">Return to editing menu</goto>
+
 <action>Show the current content that will be edited</action>
 <action>Explain the proposed changes and why they improve the workflow</action>
 <action>Generate the updated content following all conventions from the guide</action>

src/modules/bmm/_module-installer/install-menu-config.yaml

@@ -19,6 +19,21 @@ project_name:
   default: "{directory_name}"
   result: "{value}"
 
+user_skill_level:
+  prompt:
+    - "What is your technical experience level?"
+    - "This affects how agents explain concepts to you (NOT document content)."
+    - "Documents are always concise for LLM efficiency."
+  default: "intermediate"
+  result: "{value}"
+  single-select:
+    - value: "beginner"
+      label: "Beginner - New to development, explain concepts clearly"
+    - value: "intermediate"
+      label: "Intermediate - Familiar with development, balance explanation with efficiency"
+    - value: "expert"
+      label: "Expert - Deep technical knowledge, be direct and technical"
+
 tech_docs:
   prompt: "Where is Technical Documentation located within the project?"
   default: "docs"
@@ -28,22 +43,21 @@ dev_story_location:
   prompt: "Where should development stories be stored?"
   default: "docs/stories"
   result: "{project-root}/{value}"
+# kb_location:
+#   prompt: "Where should bmad knowledge base articles be stored?"
+#   default: "~/bmad/bmm/kb.md"
+#   result: "{value}"
 
-kb_location:
+# desired_mcp_tools:
-  prompt: "Where should bmad knowledge base articles be stored?"
+#   prompt:
-  default: "~/bmad/bmm/kb.md"
+#     - "Which MCP Tools will you be using? (Select all that apply)"
-  result: "{value}"
+#     - "Note: You will need to install these separately. Bindings will come post ALPHA along with other choices."
-
+#   result: "{value}"
-desired_mcp_tools:
+#   multi-select:
-  prompt:
+#     - "Chrome Official MCP"
-    - "Which MCP Tools will you be using? (Select all that apply)"
+#     - "Playwright"
-    - "Note: You will need to install these separately. Bindings will come post ALPHA along with other choices."
+#     - "Context 7"
-  result: "{value}"
+#     - "Tavily"
-  multi-select:
+#     - "Perplexity"
-    - "Chrome Official MCP"
+#     - "Jira"
-    - "Playwright"
+#     - "Trello"
-    - "Context 7"
-    - "Tavily"
-    - "Perplexity"
-    - "Jira"
-    - "Trello"

src/modules/bmm/agents/analyst.agent.yaml

@@ -18,8 +18,12 @@ agent:
       - I operate as an iterative thinking partner who explores wide solution spaces before converging on recommendations, ensuring that every requirement is articulated with absolute precision and every output delivers clear, actionable next steps.
 
   menu:
+    - trigger: workflow-init
+      workflow: "{project-root}/bmad/bmm/workflows/workflow-status/init/workflow.yaml"
+      description: Start a new sequenced workflow path
+
     - trigger: workflow-status
-      workflow: "{project-root}/bmad/bmm/workflows/1-analysis/workflow-status/workflow.yaml"
+      workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
       description: Check workflow status and get recommendations (START HERE!)
 
     - trigger: brainstorm-project

src/modules/bmm/agents/architect.agent.yaml

@@ -19,7 +19,7 @@ agent:
 
   menu:
     - trigger: workflow-status
-      workflow: "{project-root}/bmad/bmm/workflows/1-analysis/workflow-status/workflow.yaml"
+      workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
       description: Check workflow status and get recommendations
 
     - trigger: correct-course

src/modules/bmm/agents/dev.agent.yaml

@@ -27,7 +27,7 @@ agent:
 
   menu:
     - trigger: workflow-status
-      workflow: "{project-root}/bmad/bmm/workflows/1-analysis/workflow-status/workflow.yaml"
+      workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
       description: Check workflow status and get recommendations
 
     - trigger: develop

src/modules/bmm/agents/game-architect.agent.yaml

@@ -19,7 +19,7 @@ agent:
 
   menu:
     - trigger: workflow-status
-      workflow: "{project-root}/bmad/bmm/workflows/1-analysis/workflow-status/workflow.yaml"
+      workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
       description: Check workflow status and get recommendations
 
     - trigger: solutioning

src/modules/bmm/agents/game-designer.agent.yaml

@@ -18,8 +18,12 @@ agent:
       - Design is about making meaningful choices matter, creating moments of mastery, and respecting player time while delivering compelling challenge.
 
   menu:
+    - trigger: workflow-init
+      workflow: "{project-root}/bmad/bmm/workflows/workflow-status/init/workflow.yaml"
+      description: Start a new sequenced workflow path
+
     - trigger: workflow-status
-      workflow: "{project-root}/bmad/bmm/workflows/1-analysis/workflow-status/workflow.yaml"
+      workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
       description: Check workflow status and get recommendations (START HERE!)
 
     - trigger: brainstorm-game

src/modules/bmm/agents/game-dev.agent.yaml

@@ -19,7 +19,7 @@ agent:
 
   menu:
     - trigger: workflow-status
-      workflow: "{project-root}/bmad/bmm/workflows/1-analysis/workflow-status/workflow.yaml"
+      workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
       description: Check workflow status and get recommendations
 
     - trigger: create-story

src/modules/bmm/agents/pm.agent.yaml

@@ -23,8 +23,12 @@ agent:
   # Menu items - triggers will be prefixed with * at build time
   # help and exit are auto-injected, don't define them here
   menu:
+    - trigger: workflow-init
+      workflow: "{project-root}/bmad/bmm/workflows/workflow-status/init/workflow.yaml"
+      description: Start a new sequenced workflow path
+
     - trigger: workflow-status
-      workflow: "{project-root}/bmad/bmm/workflows/1-analysis/workflow-status/workflow.yaml"
+      workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
       description: Check workflow status and get recommendations (START HERE!)
 
     - trigger: prd

src/modules/bmm/agents/sm.agent.yaml

@@ -22,11 +22,11 @@ agent:
 
   menu:
     - trigger: workflow-status
-      workflow: "{project-root}/bmad/bmm/workflows/1-analysis/workflow-status/workflow.yaml"
+      workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
       description: Check workflow status and get recommendations
 
     - trigger: assess-project-ready
-      validate-workflow: "{project-root}/bmad/bmm/workflows/3-solutioning/workflow.yaml"
+      workflow: "{project-root}/bmad/bmm/workflows/3-solutioning/implementation-ready-check/workflow.yaml"
       description: Validate solutioning complete, ready for Phase 4 (Level 2-4 only)
 
     - trigger: create-story

src/modules/bmm/agents/tea.agent.yaml

@@ -23,7 +23,7 @@ agent:
 
   menu:
     - trigger: workflow-status
-      workflow: "{project-root}/bmad/bmm/workflows/1-analysis/workflow-status/workflow.yaml"
+      workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
       description: Check workflow status and get recommendations
 
     - trigger: framework

src/modules/bmm/agents/ux-expert.agent.yaml

@@ -19,7 +19,7 @@ agent:
 
   menu:
     - trigger: workflow-status
-      workflow: "{project-root}/bmad/bmm/workflows/1-analysis/workflow-status/workflow.yaml"
+      workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
       description: Check workflow status and get recommendations (START HERE!)
 
     - trigger: ux-spec

src/modules/bmm/workflows/1-analysis/brainstorm-game/instructions.md

@@ -5,33 +5,36 @@
 
 <workflow>
 
-  <step n="1" goal="Check and load workflow status file">
+  <step n="1" goal="Validate workflow readiness">
-    <action>Search {output_folder}/ for files matching pattern: bmm-workflow-status.md</action>
+    <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
-    <action>Find the most recent file (by date in filename: bmm-workflow-status.md)</action>
+      <param>mode: validate</param>
+      <param>calling_workflow: brainstorm-game</param>
+    </invoke-workflow>
 
-    <check if="exists">
+    <check if="status_exists == false">
-      <action>Load the status file</action>
+      <output>{{suggestion}}</output>
-      <action>Set status_file_found = true</action>
+      <output>Note: Game brainstorming is optional. Continuing without progress tracking.</output>
-      <action>Store status_file_path for later updates</action>
+      <action>Set standalone_mode = true</action>
     </check>
 
-    <check if="not exists">
+    <check if="status_exists == true">
-      <ask>**No workflow status file found.**
+      <action>Store {{status_file_path}} for later updates</action>
 
-This workflow generates brainstorming ideas for game ideation (optional Phase 1 workflow).
+      <check if="project_type != 'game'">
+        <output>Note: This is a {{project_type}} project. Game brainstorming is designed for game projects.</output>
+        <ask>Continue with game brainstorming anyway? (y/n)</ask>
+        <check if="n">
+          <action>Exit workflow</action>
+        </check>
+      </check>
 
-Options:
+      <check if="warning != ''">
+        <output>{{warning}}</output>
+        <output>Note: Game brainstorming can be valuable at any project stage.</output>
+      </check>
+    </check>
 
-1. Run workflow-status first to create the status file (recommended for progress tracking)
+  </step>
-2. Continue in standalone mode (no progress tracking)
-3. Exit
-
-What would you like to do?</ask>
-<action>If user chooses option 1 → HALT with message: "Please run workflow-status first, then return to brainstorm-game"</action>
-<action>If user chooses option 2 → Set standalone_mode = true and continue</action>
-<action>If user chooses option 3 → HALT</action>
-</check>
-</step>
 
   <step n="2" goal="Load game brainstorming context and techniques">
     <action>Read the game context document from: {game_context}</action>
@@ -63,38 +66,33 @@ What would you like to do?</ask>
     </invoke-workflow>
   </step>
 
-  <step n="4" goal="Update status file on completion">
+  <step n="4" goal="Update status and complete">
-    <action>Search {output_folder}/ for files matching pattern: bmm-workflow-status.md</action>
+    <check if="standalone_mode != true">
-    <action>Find the most recent file (by date in filename)</action>
+      <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+        <param>mode: update</param>
+        <param>action: complete_workflow</param>
+        <param>workflow_name: brainstorm-game</param>
+      </invoke-workflow>
 
-    <check if="status file exists">
+      <check if="success == true">
-      <action>Load the status file</action>
+        <output>Status updated! Next: {{next_workflow}}</output>
-
+      </check>
-      <template-output file="{{status_file_path}}">current_step</template-output>
+    </check>
-      <action>Set to: "brainstorm-game"</action>
-
-      <template-output file="{{status_file_path}}">current_workflow</template-output>
-      <action>Set to: "brainstorm-game - Complete"</action>
-
-      <template-output file="{{status_file_path}}">progress_percentage</template-output>
-      <action>Increment by: 5% (optional Phase 1 workflow)</action>
-
-      <template-output file="{{status_file_path}}">decisions_log</template-output>
-      <action>Add entry:</action>
-      ```
-      - **{{date}}**: Completed brainstorm-game workflow. Generated game brainstorming session results saved to {output_folder}/brainstorming-session-results-{{date}}.md. Next: Review game ideas and consider running research or game-brief workflows.
-      ```
 
     <output>**✅ Game Brainstorming Session Complete, {user_name}!**
 
 **Session Results:**
 
-- Game brainstorming results saved to: {output_folder}/brainstorming-session-results-{{date}}.md
+- Game brainstorming results saved to: {output_folder}/bmm-brainstorming-session-{{date}}.md
 
-**Status file updated:**
+{{#if standalone_mode != true}}
+**Status Updated:**
 
-- Current step: brainstorm-game ✓
+- Progress tracking updated
-- Progress: {{new_progress_percentage}}%
+  {{else}}
+  Note: Running in standalone mode (no status file).
+  To track progress across workflows, run `workflow-init` first.
+  {{/if}}
 
 **Next Steps:**
 
@@ -104,27 +102,10 @@ What would you like to do?</ask>
    - `game-brief` workflow to formalize game vision
    - Or proceed directly to `plan-project` if ready
 
+{{#if standalone_mode != true}}
 Check status anytime with: `workflow-status`
+{{/if}}
 </output>
-</check>
+</step>
-
-    <check if="status file not found">
-      <output>**✅ Game Brainstorming Session Complete, {user_name}!**
-
-**Session Results:**
-
-- Game brainstorming results saved to: {output_folder}/brainstorming-session-results-{{date}}.md
-
-Note: Running in standalone mode (no status file).
-
-To track progress across workflows, run `workflow-status` first.
-
-**Next Steps:**
-
-1. Review game brainstorming results
-2. Run research or game-brief workflows
-   </output>
-   </check>
-   </step>
 
 </workflow>

src/modules/bmm/workflows/1-analysis/brainstorm-game/workflow.yaml

@@ -8,6 +8,8 @@ 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

src/modules/bmm/workflows/1-analysis/brainstorm-project/instructions.md

@@ -1,6 +1,6 @@
 # Brainstorm Project - Workflow Instructions
 
-````xml
+```xml
 <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>Communicate all responses in {communication_language}</critical>
@@ -8,30 +8,25 @@
 
 <workflow>
 
-  <step n="1" goal="Check and load workflow status file">
+  <step n="1" goal="Validate workflow readiness">
-    <action>Search {output_folder}/ for files matching pattern: bmm-workflow-status.md</action>
+    <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
-    <action>Find the most recent file (by date in filename: bmm-workflow-status.md)</action>
+      <param>mode: validate</param>
+      <param>calling_workflow: brainstorm-project</param>
+    </invoke-workflow>
 
-    <check if="exists">
+    <check if="status_exists == false">
-      <action>Load the status file</action>
+      <output>{{suggestion}}</output>
-      <action>Set status_file_found = true</action>
+      <output>Note: Brainstorming is optional. Continuing without progress tracking.</output>
-      <action>Store status_file_path for later updates</action>
+      <action>Set standalone_mode = true</action>
     </check>
 
-    <check if="not exists">
+    <check if="status_exists == true">
-      <ask>**No workflow status file found.**
+      <action>Store {{status_file_path}} for later updates</action>
 
-This workflow generates brainstorming ideas for project ideation (optional Phase 1 workflow).
+      <check if="warning != ''">
-
+        <output>{{warning}}</output>
-Options:
+        <output>Note: Brainstorming can be valuable at any project stage.</output>
-1. Run workflow-status first to create the status file (recommended for progress tracking)
+      </check>
-2. Continue in standalone mode (no progress tracking)
-3. Exit
-
-What would you like to do?</ask>
-      <action>If user chooses option 1 → HALT with message: "Please run workflow-status first, then return to brainstorm-project"</action>
-      <action>If user chooses option 2 → Set standalone_mode = true and continue</action>
-      <action>If user chooses option 3 → HALT</action>
     </check>
   </step>
 
@@ -56,36 +51,28 @@ What would you like to do?</ask>
     </invoke-workflow>
   </step>
 
-  <step n="4" goal="Update status file on completion">
+  <step n="4" goal="Update status and complete">
-    <action>Search {output_folder}/ for files matching pattern: bmm-workflow-status.md</action>
+    <check if="standalone_mode != true">
-    <action>Find the most recent file (by date in filename)</action>
+      <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+        <param>mode: update</param>
+        <param>action: complete_workflow</param>
+        <param>workflow_name: brainstorm-project</param>
+      </invoke-workflow>
 
-    <check if="status file exists">
+      <check if="success == true">
-      <action>Load the status file</action>
+        <output>Status updated! Next: {{next_workflow}}</output>
-
+      </check>
-      <template-output file="{{status_file_path}}">current_step</template-output>
+    </check>
-      <action>Set to: "brainstorm-project"</action>
-
-      <template-output file="{{status_file_path}}">current_workflow</template-output>
-      <action>Set to: "brainstorm-project - Complete"</action>
-
-      <template-output file="{{status_file_path}}">progress_percentage</template-output>
-      <action>Increment by: 5% (optional Phase 1 workflow)</action>
-
-      <template-output file="{{status_file_path}}">decisions_log</template-output>
-      <action>Add entry:</action>
-      ```
-      - **{{date}}**: Completed brainstorm-project workflow. Generated brainstorming session results saved to {output_folder}/brainstorming-session-results-{{date}}.md. Next: Review ideas and consider running research or product-brief workflows.
-      ```
 
     <output>**✅ Brainstorming Session Complete, {user_name}!**
 
 **Session Results:**
-- Brainstorming results saved to: {output_folder}/brainstorming-session-results-{{date}}.md
+- Brainstorming results saved to: {output_folder}/bmm-brainstorming-session-{{date}}.md
 
-**Status file updated:**
+{{#if standalone_mode != true}}
-- Current step: brainstorm-project ✓
+**Status Updated:**
-- Progress: {{new_progress_percentage}}%
+- Progress tracking updated
+{{/if}}
 
 **Next Steps:**
 1. Review brainstorming results
@@ -94,26 +81,11 @@ What would you like to do?</ask>
    - `product-brief` workflow to formalize product vision
    - Or proceed directly to `plan-project` if ready
 
+{{#if standalone_mode != true}}
 Check status anytime with: `workflow-status`
+{{/if}}
     </output>
-    </check>
-
-    <check if="status file not found">
-      <output>**✅ Brainstorming Session Complete, {user_name}!**
-
-**Session Results:**
-- Brainstorming results saved to: {output_folder}/brainstorming-session-results-{{date}}.md
-
-Note: Running in standalone mode (no status file).
-
-To track progress across workflows, run `workflow-status` first.
-
-**Next Steps:**
-1. Review brainstorming results
-2. Run research or product-brief workflows
-      </output>
-    </check>
   </step>
 
 </workflow>
-````
+```

src/modules/bmm/workflows/1-analysis/brainstorm-project/workflow.yaml

@@ -8,6 +8,8 @@ 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

src/modules/bmm/workflows/1-analysis/document-project/instructions.md

@@ -8,86 +8,48 @@
 
 <critical>This router determines workflow mode and delegates to specialized sub-workflows</critical>
 
-<step n="1" goal="Check and load workflow status file">
+<step n="1" goal="Validate workflow and get project info">
 
-<action>Search {output_folder}/ for files matching pattern: bmm-workflow-status\*.md</action>
+<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
-<action>Find the most recent file (by date in filename: bmm-workflow-status.md)</action>
+  <param>mode: data</param>
+  <param>data_request: project_config</param>
+</invoke-workflow>
 
-<check if="exists">
+<check if="status_exists == false">
-  <action>Load the status file</action>
+  <output>{{suggestion}}</output>
-  <action>Extract key information:</action>
+  <output>Note: Documentation workflow can run standalone. Continuing without progress tracking.</output>
-
-- current_step: From "Current Step:" field
-- next_step: From "Next Step:" field
-- planned_workflow: From "Planned Workflow Journey" table
-- progress_percentage: From "Overall Progress:" field
-- current_phase: From "Current Phase:" field
-- field_type: From "Greenfield/Brownfield:" field
-
-<action>Validate this workflow is in the planned workflow</action>
-<action>Set status_file_path = file path</action>
-<action>Set status_file_found = true</action>
-
-  <check if='next_step != "document-project"'>
-    <ask>**⚠️ Workflow Sequence Note**
-
-According to your status file, your next planned step is: **{{next_step}}**
-
-But you're running: **document-project**
-
-This is expected if plan-project invoked this workflow automatically for brownfield documentation.
-
-Options:
-
-1. **Continue** - Run document-project (status will be updated)
-2. **Exit** - I'll follow the planned sequence instead
-
-Your choice (1-2):</ask>
-
-    <check if='choice == "2"'>
-      <output>**Recommended Next Step:**
-
-Run: {{next_step}}
-
-You can return to document-project later if needed.
-</output>
-<action>Exit workflow</action>
-</check>
-</check>
-</check>
-
-<check if="not exists">
-  <ask>**ℹ️ No Workflow Status File Found**
-
-This workflow works best with a workflow status file for progress tracking.
-
-Options:
-
-1. **Run workflow-status first** - Create status file and plan workflow (recommended)
-2. **Continue anyway** - Run document-project standalone
-3. **Exit** - I'll set up the workflow first
-
-Your choice (1-3):</ask>
-
-  <check if='choice == "1"'>
-    <output>**To create status file:**
-
-Load any agent and run: `workflow-status`
-
-After planning your workflow, you can return here or follow the planned sequence.
-</output>
-<action>Exit workflow</action>
-</check>
-
-  <check if='choice == "2"'>
-    <action>Set status_file_found = false</action>
   <action>Set standalone_mode = true</action>
-    <action>Continue without status file integration</action>
+  <action>Set status_file_found = false</action>
+</check>
+
+<check if="status_exists == true">
+  <action>Store {{status_file_path}} for later updates</action>
+  <action>Set status_file_found = true</action>
+
+  <!-- Extract brownfield/greenfield from status data -->
+  <check if="field_type == 'greenfield'">
+    <output>Note: This is a greenfield project. Documentation workflow is typically for brownfield projects.</output>
+    <ask>Continue anyway to document planning artifacts? (y/n)</ask>
+    <check if="n">
+      <action>Exit workflow</action>
+    </check>
   </check>
 
-  <check if='choice == "3"'>
+  <!-- Now validate sequencing -->
+  <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+    <param>mode: validate</param>
+    <param>calling_workflow: document-project</param>
+  </invoke-workflow>
+
+  <check if="warning != ''">
+    <output>{{warning}}</output>
+    <output>Note: This may be auto-invoked by plan-project for brownfield documentation.</output>
+    <ask>Continue with documentation? (y/n)</ask>
+    <check if="n">
+      <output>{{suggestion}}</output>
       <action>Exit workflow</action>
     </check>
+  </check>
 </check>
 
 </step>
@@ -214,34 +176,19 @@ Your choice [1/2/3]:
 
 </step>
 
-<step n="4" goal="Update status file on completion">
+<step n="4" goal="Update status and complete">
 
 <check if="status_file_found == true">
-  <action>Load the status file from {{status_file_path}}</action>
+  <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+    <param>mode: update</param>
+    <param>action: complete_workflow</param>
+    <param>workflow_name: document-project</param>
+  </invoke-workflow>
 
-<template-output file="{{status_file_path}}">planned_workflow</template-output>
+  <check if="success == true">
-<action>Find "document-project" in the planned_workflow table</action>
+    <output>Status updated! Next: {{next_workflow}}</output>
-<action>Update Status field from "Planned" or "In Progress" to "Complete"</action>
+  </check>
-
+</check>
-<template-output file="{{status_file_path}}">current_step</template-output>
-<action>Set to: "document-project"</action>
-
-<template-output file="{{status_file_path}}">next_step</template-output>
-<action>Find next item with Status != "Complete" in planned_workflow table</action>
-<action>Set to: "{{next_workflow_step}} ({{next_workflow_agent}} agent)"</action>
-
-<template-output file="{{status_file_path}}">progress_percentage</template-output>
-<action>Increment by: 10%</action>
-
-<template-output file="{{status_file_path}}">current_workflow</template-output>
-<action>Set to: "document-project - Complete"</action>
-
-<template-output file="{{status_file_path}}">decisions_log</template-output>
-<action>Add entry:</action>
-
-```
-- **{{date}}**: Completed document-project workflow ({{workflow_mode}} mode, {{scan_level}} scan). Generated brownfield documentation in {output_folder}/. Next: {{next_step}}.
-```
 
 <output>**✅ Document Project Workflow Complete, {user_name}!**
 
@@ -249,35 +196,18 @@ Your choice [1/2/3]:
 
 - Mode: {{workflow_mode}}
 - Scan Level: {{scan_level}}
-- Output: {output_folder}/index.md and related files
+- Output: {output_folder}/bmm-index.md and related files
 
-**Status file updated:**
+{{#if status_file_found}}
+**Status Updated:**
 
-- Current step: document-project ✓
+- Progress tracking updated
-- Next step: {{next_step}}
+  {{else}}
-- Progress: {{new_progress_percentage}}%
+  **Note:** Running in standalone mode
+  {{/if}}
 
-**To proceed:**
+Check status anytime with: `workflow-status`
-Load {{next_agent}} and run: `{{next_command}}`
-
-Or check status anytime with: `workflow-status`
 </output>
-</check>
-
-<check if="standalone_mode == true">
-  <output>**✅ Document Project Workflow Complete**
-
-**Documentation Generated:**
-
-- Mode: {{workflow_mode}}
-- Scan Level: {{scan_level}}
-- Output: {output_folder}/index.md and related files
-
-Note: Running in standalone mode (no status file).
-
-To track progress across workflows, run `workflow-status` first next time.
-</output>
-</check>
 
 </step>
 

src/modules/bmm/workflows/1-analysis/document-project/workflow.yaml

@@ -9,6 +9,8 @@ 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

src/modules/bmm/workflows/1-analysis/game-brief/instructions.md

@@ -2,35 +2,40 @@
 
 <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>Communicate all responses in {communication_language}</critical>
+<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
+<critical>Generate all documents in {document_output_language}</critical>
+
+<critical>DOCUMENT OUTPUT: Concise, professional, game-design focused. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
 
 <workflow>
 
-<step n="0" goal="Check and load workflow status file">
+<step n="0" goal="Validate workflow readiness">
-<action>Search {output_folder}/ for files matching pattern: bmm-workflow-status.md</action>
+<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
-<action>Find the most recent file (by date in filename: bmm-workflow-status.md)</action>
+  <param>mode: validate</param>
+  <param>calling_workflow: game-brief</param>
+</invoke-workflow>
 
-<check if="exists">
+<check if="status_exists == false">
-  <action>Load the status file</action>
+  <output>{{suggestion}}</output>
-  <action>Set status_file_found = true</action>
+  <output>Note: Game brief is optional. Continuing without progress tracking.</output>
-  <action>Store status_file_path for later updates</action>
+  <action>Set standalone_mode = true</action>
 </check>
 
-<check if="not exists">
+<check if="status_exists == true">
-  <ask>**No workflow status file found.**
+  <action>Store {{status_file_path}} for later updates</action>
 
-This workflow creates a Game Brief document (optional Phase 1 workflow).
+  <check if="project_type != 'game'">
+    <output>Note: This is a {{project_type}} project. Game brief is designed for game projects.</output>
+    <ask>Continue with game brief anyway? (y/n)</ask>
+    <check if="n">
+      <action>Exit workflow</action>
+    </check>
+  </check>
 
-Options:
+  <check if="warning != ''">
-
+    <output>{{warning}}</output>
-1. Run workflow-status first to create the status file (recommended for progress tracking)
+    <output>Note: Game brief can provide valuable vision clarity at any stage.</output>
-2. Continue in standalone mode (no progress tracking)
+  </check>
-3. Exit
-
-What would you like to do?</ask>
-<action>If user chooses option 1 → HALT with message: "Please run workflow-status first, then return to game-brief"</action>
-<action>If user chooses option 2 → Set standalone_mode = true and continue</action>
-<action>If user chooses option 3 → HALT</action>
 </check>
 </step>
 
@@ -303,39 +308,33 @@ This brief will serve as the primary input for creating the Game Design Document
 <template-output>executive_brief</template-output>
 </step>
 
-<step n="16" goal="Update status file on completion">
+<step n="16" goal="Update status and complete">
-<action>Search {output_folder}/ for files matching pattern: bmm-workflow-status.md</action>
+<check if="standalone_mode != true">
-<action>Find the most recent file (by date in filename)</action>
+  <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+    <param>mode: update</param>
+    <param>action: complete_workflow</param>
+    <param>workflow_name: game-brief</param>
+  </invoke-workflow>
 
-<check if="status file exists">
+  <check if="success == true">
-  <action>Load the status file</action>
+    <output>Status updated! Next: {{next_workflow}}</output>
-
+  </check>
-<template-output file="{{status_file_path}}">current_step</template-output>
+</check>
-<action>Set to: "game-brief"</action>
-
-<template-output file="{{status_file_path}}">current_workflow</template-output>
-<action>Set to: "game-brief - Complete"</action>
-
-<template-output file="{{status_file_path}}">progress_percentage</template-output>
-<action>Increment by: 10% (optional Phase 1 workflow)</action>
-
-<template-output file="{{status_file_path}}">decisions_log</template-output>
-<action>Add entry:</action>
-
-```
-- **{{date}}**: Completed game-brief workflow. Game brief document generated and saved. Next: Proceed to plan-project workflow to create Game Design Document (GDD).
-```
 
 <output>**✅ Game Brief Complete, {user_name}!**
 
 **Brief Document:**
 
-- Game brief saved to {output_folder}/game-brief-{{game_name}}-{{date}}.md
+- Game brief saved to {output_folder}/bmm-game-brief-{{game_name}}-{{date}}.md
 
-**Status file updated:**
+{{#if standalone_mode != true}}
+**Status Updated:**
 
-- Current step: game-brief ✓
+- Progress tracking updated
-- Progress: {{new_progress_percentage}}%
+  {{else}}
+  Note: Running in standalone mode (no status file).
+  To track progress across workflows, run `workflow-init` first.
+  {{/if}}
 
 **Next Steps:**
 
@@ -344,27 +343,10 @@ This brief will serve as the primary input for creating the Game Design Document
 3. Run `plan-project` workflow to create GDD from this brief
 4. Validate assumptions with target players
 
+{{#if standalone_mode != true}}
 Check status anytime with: `workflow-status`
+{{/if}}
 </output>
-</check>
+</step>
-
-<check if="status file not found">
-  <output>**✅ Game Brief Complete, {user_name}!**
-
-**Brief Document:**
-
-- Game brief saved to {output_folder}/game-brief-{{game_name}}-{{date}}.md
-
-Note: Running in standalone mode (no status file).
-
-To track progress across workflows, run `workflow-status` first.
-
-**Next Steps:**
-
-1. Review the game brief document
-2. Run `plan-project` workflow to create GDD
-   </output>
-   </check>
-   </step>
 
 </workflow>

src/modules/bmm/workflows/1-analysis/game-brief/workflow.yaml

@@ -8,6 +8,8 @@ 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
 
 # Optional input documents

src/modules/bmm/workflows/1-analysis/product-brief/instructions.md

@@ -2,35 +2,41 @@
 
 <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>Communicate all responses in {communication_language}</critical>
+<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
+<critical>Generate all documents in {document_output_language}</critical>
+
+<critical>DOCUMENT OUTPUT: Concise, professional, strategically focused. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
 
 <workflow>
 
-<step n="0" goal="Check and load workflow status file">
+<step n="0" goal="Validate workflow readiness">
-<action>Search {output_folder}/ for files matching pattern: bmm-workflow-status.md</action>
+<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
-<action>Find the most recent file (by date in filename: bmm-workflow-status.md)</action>
+  <param>mode: validate</param>
+  <param>calling_workflow: product-brief</param>
+</invoke-workflow>
 
-<check if="exists">
+<check if="status_exists == false">
-  <action>Load the status file</action>
+  <output>{{suggestion}}</output>
-  <action>Set status_file_found = true</action>
+  <output>Note: Product Brief is optional. You can continue without status tracking.</output>
-  <action>Store status_file_path for later updates</action>
+  <action>Set standalone_mode = true</action>
 </check>
 
-<check if="not exists">
+<check if="status_exists == true">
-  <ask>**No workflow status file found.**
+  <action>Store {{status_file_path}} for later updates</action>
 
-This workflow creates a Product Brief document (optional Phase 1 workflow).
+  <check if="project_level < 2">
+    <output>Note: Product Brief is most valuable for Level 2+ projects. Your project is Level {{project_level}}.</output>
+    <output>You may want to skip directly to technical planning instead.</output>
+  </check>
 
-Options:
+  <check if="warning != ''">
-
+    <output>{{warning}}</output>
-1. Run workflow-status first to create the status file (recommended for progress tracking)
+    <ask>Continue with Product Brief anyway? (y/n)</ask>
-2. Continue in standalone mode (no progress tracking)
+    <check if="n">
-3. Exit
+      <output>Exiting. {{suggestion}}</output>
-
+      <action>Exit workflow</action>
-What would you like to do?</ask>
+    </check>
-<action>If user chooses option 1 → HALT with message: "Please run workflow-status first, then return to product-brief"</action>
+  </check>
-<action>If user chooses option 2 → Set standalone_mode = true and continue</action>
-<action>If user chooses option 3 → HALT</action>
 </check>
 </step>
 
@@ -267,38 +273,32 @@ This brief will serve as the primary input for creating the Product Requirements
 </step>
 
 <step n="16" goal="Update status file on completion">
-<action>Search {output_folder}/ for files matching pattern: bmm-workflow-status.md</action>
+<check if="standalone_mode != true">
-<action>Find the most recent file (by date in filename)</action>
+  <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+    <param>mode: update</param>
+    <param>action: complete_workflow</param>
+    <param>workflow_name: product-brief</param>
+  </invoke-workflow>
 
-<check if="status file exists">
+  <check if="success == true">
-  <action>Load the status file</action>
+    <output>Status updated! Next: {{next_workflow}}</output>
-
+  </check>
-<template-output file="{{status_file_path}}">current_step</template-output>
+</check>
-<action>Set to: "product-brief"</action>
-
-<template-output file="{{status_file_path}}">current_workflow</template-output>
-<action>Set to: "product-brief - Complete"</action>
-
-<template-output file="{{status_file_path}}">progress_percentage</template-output>
-<action>Increment by: 10% (optional Phase 1 workflow)</action>
-
-<template-output file="{{status_file_path}}">decisions_log</template-output>
-<action>Add entry:</action>
-
-```
-- **{{date}}**: Completed product-brief workflow. Product brief document generated and saved. Next: Proceed to plan-project workflow to create Product Requirements Document (PRD).
-```
 
 <output>**✅ Product Brief Complete, {user_name}!**
 
 **Brief Document:**
 
-- Product brief saved to {output_folder}/product-brief-{{project_name}}-{{date}}.md
+- Product brief saved to {output_folder}/bmm-product-brief-{{project_name}}-{{date}}.md
 
-**Status file updated:**
+{{#if standalone_mode != true}}
+**Status Updated:**
 
-- Current step: product-brief ✓
+- Progress tracking updated
-- Progress: {{new_progress_percentage}}%
+- Current workflow marked complete
+  {{else}}
+  **Note:** Running in standalone mode (no progress tracking)
+  {{/if}}
 
 **Next Steps:**
 
@@ -306,27 +306,10 @@ This brief will serve as the primary input for creating the Product Requirements
 2. Gather any additional stakeholder input
 3. Run `plan-project` workflow to create PRD from this brief
 
+{{#if standalone_mode != true}}
 Check status anytime with: `workflow-status`
+{{/if}}
 </output>
-</check>
+</step>
-
-<check if="status file not found">
-  <output>**✅ Product Brief Complete**
-
-**Brief Document:**
-
-- Product brief saved and ready for handoff
-
-Note: Running in standalone mode (no status file).
-
-To track progress across workflows, run `workflow-status` first.
-
-**Next Steps:**
-
-1. Review the product brief document
-2. Run `plan-project` workflow to create PRD
-   </output>
-   </check>
-   </step>
 
 </workflow>

src/modules/bmm/workflows/1-analysis/product-brief/workflow.yaml

@@ -8,6 +8,8 @@ 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
 
 # Optional input documents

src/modules/bmm/workflows/1-analysis/research/instructions-deep-prompt.md

@@ -379,23 +379,15 @@ Select option (1-4):</ask>
 <action>Find the most recent file (by date in filename)</action>
 
 <check if="status file exists">
-  <action>Load the status file</action>
+  <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+    <param>mode: update</param>
+    <param>action: complete_workflow</param>
+    <param>workflow_name: research</param>
+  </invoke-workflow>
 
-<template-output file="{{status_file_path}}">current_step</template-output>
+  <check if="success == true">
-<action>Set to: "research (deep-prompt)"</action>
+    <output>Status updated! Next: {{next_workflow}}</output>
-
+  </check>
-<template-output file="{{status_file_path}}">current_workflow</template-output>
-<action>Set to: "research (deep-prompt) - Complete"</action>
-
-<template-output file="{{status_file_path}}">progress_percentage</template-output>
-<action>Increment by: 5% (optional Phase 1 workflow)</action>
-
-<template-output file="{{status_file_path}}">decisions_log</template-output>
-<action>Add entry:</action>
-
-```
-- **{{date}}**: Completed research workflow (deep-prompt mode). Research prompt generated and saved. Next: Execute prompt with AI platform or continue with plan-project workflow.
-```
 
 <output>**✅ Deep Research Prompt Generated**
 

src/modules/bmm/workflows/1-analysis/research/instructions-market.md

@@ -559,23 +559,16 @@ Create compelling executive summary with:
 <action>Find the most recent file (by date in filename)</action>
 
 <check if="status file exists">
-  <action>Load the status file</action>
+  <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+    <param>mode: update</param>
+    <param>action: complete_workflow</param>
+    <param>workflow_name: research</param>
+  </invoke-workflow>
 
-<template-output file="{{status_file_path}}">current_step</template-output>
+  <check if="success == true">
-<action>Set to: "research ({{research_mode}})"</action>
+    <output>Status updated! Next: {{next_workflow}}</output>
-
+  </check>
-<template-output file="{{status_file_path}}">current_workflow</template-output>
+</check>
-<action>Set to: "research ({{research_mode}}) - Complete"</action>
-
-<template-output file="{{status_file_path}}">progress_percentage</template-output>
-<action>Increment by: 5% (optional Phase 1 workflow)</action>
-
-<template-output file="{{status_file_path}}">decisions_log</template-output>
-<action>Add entry:</action>
-
-```
-- **{{date}}**: Completed research workflow ({{research_mode}} mode). Research report generated and saved. Next: Review findings and consider product-brief or plan-project workflows.
-```
 
 <output>**✅ Research Complete ({{research_mode}} mode)**
 

src/modules/bmm/workflows/1-analysis/research/instructions-router.md

@@ -10,31 +10,26 @@
 
 <critical>This is a ROUTER that directs to specialized research instruction sets</critical>
 
-<step n="1" goal="Check and load workflow status file">
+<step n="1" goal="Validate workflow readiness">
-<action>Search {output_folder}/ for files matching pattern: bmm-workflow-status.md</action>
+<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
-<action>Find the most recent file (by date in filename: bmm-workflow-status.md)</action>
+  <param>mode: validate</param>
+  <param>calling_workflow: research</param>
+</invoke-workflow>
 
-<check if="exists">
+<check if="status_exists == false">
-  <action>Load the status file</action>
+  <output>{{suggestion}}</output>
-  <action>Set status_file_found = true</action>
+  <output>Note: Research is optional. Continuing without progress tracking.</output>
-  <action>Store status_file_path for later updates</action>
+  <action>Set standalone_mode = true</action>
 </check>
 
-<check if="not exists">
+<check if="status_exists == true">
-  <ask>**No workflow status file found.**
+  <action>Store {{status_file_path}} for status updates in sub-workflows</action>
+  <action>Pass status_file_path to loaded instruction set</action>
 
-This workflow conducts research (optional Phase 1 workflow).
+  <check if="warning != ''">
-
+    <output>{{warning}}</output>
-Options:
+    <output>Note: Research can provide valuable insights at any project stage.</output>
-
+  </check>
-1. Run workflow-status first to create the status file (recommended for progress tracking)
-2. Continue in standalone mode (no progress tracking)
-3. Exit
-
-What would you like to do?</ask>
-<action>If user chooses option 1 → HALT with message: "Please run workflow-status first, then return to research"</action>
-<action>If user chooses option 2 → Set standalone_mode = true and continue</action>
-<action>If user chooses option 3 → HALT</action>
 </check>
 </step>
 

src/modules/bmm/workflows/1-analysis/research/instructions-technical.md

@@ -447,23 +447,16 @@ Select option (1-5):</ask>
 <action>Find the most recent file (by date in filename)</action>
 
 <check if="status file exists">
-  <action>Load the status file</action>
+  <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+    <param>mode: update</param>
+    <param>action: complete_workflow</param>
+    <param>workflow_name: research</param>
+  </invoke-workflow>
 
-<template-output file="{{status_file_path}}">current_step</template-output>
+  <check if="success == true">
-<action>Set to: "research (technical)"</action>
+    <output>Status updated! Next: {{next_workflow}}</output>
-
+  </check>
-<template-output file="{{status_file_path}}">current_workflow</template-output>
+</check>
-<action>Set to: "research (technical) - Complete"</action>
-
-<template-output file="{{status_file_path}}">progress_percentage</template-output>
-<action>Increment by: 5% (optional Phase 1 workflow)</action>
-
-<template-output file="{{status_file_path}}">decisions_log</template-output>
-<action>Add entry:</action>
-
-```
-- **{{date}}**: Completed research workflow (technical mode). Technical research report generated and saved. Next: Review findings and consider plan-project workflow.
-```
 
 <output>**✅ Technical Research Complete**
 

src/modules/bmm/workflows/1-analysis/research/workflow.yaml

@@ -8,6 +8,8 @@ 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
 
 # Workflow components - ROUTER PATTERN

src/modules/bmm/workflows/1-analysis/workflow-status/README.md

@@ -1,383 +0,0 @@
-# Workflow Status - Universal Entry Point
-
-## Overview
-
-The `workflow-status` workflow is the **universal entry point** for all BMad Method (BMM) workflows. It serves as both a status tracker and master router, helping users understand where they are in their project journey and what to do next.
-
-## Purpose
-
-**Primary Functions:**
-
-1. **Status Checking**: Read existing workflow status and display current state
-2. **Next Action Recommendation**: Suggest what the user should do next
-3. **Comprehensive Workflow Planning**: Map out ENTIRE workflow journey before executing anything
-4. **Planned Workflow Documentation**: Create status file with complete phase/step roadmap
-5. **Phase Navigation**: Guide users through the 4-phase methodology
-6. **Agent Coordination**: Can be invoked by any agent (bmad-master, analyst, pm)
-
-## When to Use
-
-### Automatic Invocation
-
-Agents should automatically check workflow status when loaded:
-
-- **bmad-master**: Checks status before displaying main menu
-- **analyst**: Checks status before displaying analysis options
-- **pm**: Checks status before displaying planning options
-
-### Manual Invocation
-
-Users can manually run this workflow anytime:
-
-```bash
-bmad analyst workflow-status
-# or
-bmad pm workflow-status
-# or just tell any agent: "check workflow status"
-```
-
-## Workflow Behavior
-
-### Scenario 1: No Status File Exists (New Project)
-
-**The workflow will map out your ENTIRE workflow journey:**
-
-**Step 1: Project Context**
-
-- Determine greenfield vs brownfield
-- Check if brownfield needs documentation
-- Note if `document-project` should be added to plan
-
-**Step 2: Scope Understanding**
-
-- Ask if user knows project level/scope
-- Options:
-  - **Yes**: Capture estimated level (0-4)
-  - **No**: Defer level determination to Phase 2 (plan-project)
-  - **Want analysis first**: Include Phase 1 in plan
-
-**Step 3: Choose Starting Point**
-
-- **Option A**: Full Analysis Phase (brainstorm → research → brief)
-- **Option B**: Skip to Planning (direct to PRD/GDD)
-- **Option C**: Just Show Menu (I'll decide manually)
-
-**Step 4: Build Complete Planned Workflow**
-The workflow builds a comprehensive plan including:
-
-- Phase 1 (if needed): document-project, brainstorm, research, brief
-- Phase 2 (always required): plan-project
-- Phase 3 (if Level 3-4): solution-architecture, tech-specs
-- Phase 4 (always): Full implementation workflow (create-story → story-ready → dev-story → story-approved)
-
-**Step 5: Create Status File**
-
-- Create `bmm-workflow-status.md`
-- Document complete planned workflow in "Planned Workflow Journey" table
-- Set current step: "Workflow Definition Phase"
-- Set next step: First item from planned workflow
-- Provide command to run next step
-
-**Brownfield Special Handling:**
-
-- Checks if codebase is documented
-- Adds `document-project` to planned workflow if needed
-- Does NOT immediately execute it - documents it in the plan first
-
-**Output:**
-
-- Complete workflow roadmap with phases, steps, agents, and descriptions
-- Status file with planned journey documented
-- Clear command to run first step
-- User can reference plan anytime via workflow-status
-
-### Scenario 2: Status File Exists (Project In Progress)
-
-**The workflow will:**
-
-1. Find most recent `bmm-workflow-status.md` file
-2. Read and parse current state:
-   - Current phase and progress %
-   - Project level and type
-   - Phase completion status
-   - Implementation progress (if Phase 4)
-   - Next recommended action
-3. Display comprehensive status summary
-4. Offer options:
-   - **Option 1**: Proceed with recommended action
-   - **Option 2**: View detailed status
-   - **Option 3**: Change workflow
-   - **Option 4**: Display agent menu
-   - **Option 5**: Exit
-
-**Phase 4 Special Display:**
-If in Implementation phase, shows:
-
-- BACKLOG story count
-- TODO story (ready for drafting)
-- IN PROGRESS story (being implemented)
-- DONE story count and points
-
-## Status File Detection
-
-**Search Pattern:**
-
-```
-{output_folder}/bmm-workflow-status.md
-```
-
-**Versioning:**
-
-- Files are named: `bmm-workflow-status.md`
-- Workflow finds most recent by date
-- Old files can be archived
-
-## Recommended Next Actions
-
-The workflow intelligently suggests next steps based on current state:
-
-**Phase 1 (Analysis):**
-
-- Continue with analysis workflows
-- Or move to `plan-project`
-
-**Phase 2 (Planning):**
-
-- If Level 0-1: Move to Phase 4 (`create-story`)
-- If Level 3-4: Move to Phase 3 (`solution-architecture`)
-
-**Phase 3 (Solutioning):**
-
-- Continue with tech-specs (JIT per epic)
-- Or move to Phase 4 (`create-story`)
-
-**Phase 4 (Implementation):**
-
-- Shows current TODO/IN PROGRESS story
-- Suggests exact next workflow (`story-ready`, `dev-story`, `story-approved`)
-
-## Integration with Agents
-
-### bmad-master
-
-```
-On load:
-1. Run workflow-status check
-2. If status found: Display summary + menu
-3. If no status: Offer to plan workflow
-4. Display master menu with context
-```
-
-### analyst
-
-```
-On load:
-1. Run workflow-status check
-2. If in Phase 1: Show analysis workflows
-3. If no status: Offer analysis planning
-4. Display analyst menu
-```
-
-### pm
-
-```
-On load:
-1. Run workflow-status check
-2. If no status: Offer to run plan-project
-3. If status found: Show current phase progress
-4. Display PM menu
-```
-
-## Example Outputs
-
-### No Status File (New User) - Planning Flow
-
-```
-🚀 Welcome to BMad Method Workflows!
-
-No workflow status file found. Let's plan your complete workflow journey.
-
-Step 1: Project Context
-
-Is this a new or existing codebase?
-   a. Greenfield - Starting from scratch
-   b. Brownfield - Adding to existing codebase
-
-Your choice (a/b): a
-
-Step 3: Understanding Your Workflow
-
-Before we plan your workflow, let's determine the scope and complexity of your project.
-
-The BMad Method uses 5 project levels (0-4) that determine which phases you'll need:
-- Level 0: Single atomic change (1 story) - Phases 2 → 4
-- Level 1: Small feature (2-3 stories, 1 epic) - Phases 2 → 4
-- Level 2: Medium project (multiple epics) - Phases 2 → 4
-- Level 3: Complex system (subsystems, integrations) - Phases 2 → 3 → 4
-- Level 4: Enterprise scale (multiple products) - Phases 2 → 3 → 4
-
-Do you already know your project's approximate size/scope?
-a. Yes - I can describe the general scope
-b. No - Not sure yet, need help determining it
-c. Want analysis first - Do brainstorming/research before deciding
-
-Your choice (a/b/c): a
-
-Based on the descriptions above, what level best describes your project?
-0. Single atomic change
-1. Small coherent feature
-2. Medium project
-3. Complex system
-4. Enterprise scale
-
-Your estimated level (0-4): 1
-
-Step 4: Choose Your Starting Point
-
-Option A: Full Analysis Phase First
-Option B: Skip to Planning
-Option C: Just Show Menu
-
-Your choice (A/B/C): B
-
-🗺️ Your Planned Workflow
-
-Based on your responses, here's your complete workflow journey:
-
-**2-Plan** - plan-project
-  - Agent: PM
-  - Description: Create PRD/GDD/Tech-Spec (determines final level)
-  - Status: Planned
-
-**3-Solutioning** - TBD - depends on level from Phase 2
-  - Agent: Architect
-  - Description: Required if Level 3-4, skipped if Level 0-2
-  - Status: Conditional
-
-**4-Implementation** - create-story (iterative)
-  - Agent: SM
-  - Description: Draft stories from backlog
-  - Status: Planned
-
-**4-Implementation** - story-ready
-  - Agent: SM
-  - Description: Approve story for dev
-  - Status: Planned
-
-**4-Implementation** - story-context
-  - Agent: SM
-  - Description: Generate context XML
-  - Status: Planned
-
-**4-Implementation** - dev-story (iterative)
-  - Agent: DEV
-  - Description: Implement stories
-  - Status: Planned
-
-**4-Implementation** - story-approved
-  - Agent: DEV
-  - Description: Mark complete, advance queue
-  - Status: Planned
-
----
-
-Current Step: Workflow Definition Phase (this workflow)
-Next Step: plan-project (PM agent)
-
-Ready to create your workflow status file?
-
-This will create: bmm-workflow-status.md
-
-The status file will document:
-- Your complete planned workflow (phases and steps)
-- Current phase: "Workflow Definition"
-- Next action: plan-project
-
-Create status file? (y/n): y
-
-✅ Status file created!
-
-File: bmm-workflow-status.md
-
-To proceed with your first step:
-
-Load PM: bmad pm plan-project
-
-You can always check your status with: workflow-status
-```
-
-### Status File Found (In Progress)
-
-```
-📊 Current Workflow Status
-
-Project: My Web App
-Started: 2025-10-10
-Last Updated: 2025-10-12
-
-Current Phase: 4-Implementation (65% complete)
-Current Workflow: Story implementation in progress
-
-Phase Completion:
-- [x] Phase 1: Analysis
-- [x] Phase 2: Planning
-- [ ] Phase 3: Solutioning (skipped for Level 1)
-- [ ] Phase 4: Implementation
-
-Planned Workflow Journey:
-Current Step: dev-story (DEV agent)
-Next Step: story-approved (DEV agent)
-
-Full planned workflow documented in status file - reference anytime!
-
-Project Details:
-- Level: 1 (Coherent feature, 1-10 stories)
-- Type: web
-- Context: greenfield
-
-Implementation Progress:
-- BACKLOG: 1 stories
-- TODO: (empty)
-- IN PROGRESS: auth-feature-2 (Ready)
-- DONE: 1 stories (5 points)
-
----
-
-🎯 Recommended Next Action:
-
-Implement story auth-feature-2
-
-Command: Run 'dev-story' workflow
-Agent: DEV
-
-Would you like to:
-1. Proceed with recommended action
-2. View detailed status (includes full planned workflow table)
-3. Change workflow
-4. Display agent menu
-5. Exit
-```
-
-## Benefits
-
-✅ **Complete Workflow Planning**: Maps out ENTIRE journey before executing anything
-✅ **No More Guessing**: Users always know current step AND what comes next
-✅ **Documented Roadmap**: Status file contains complete planned workflow table
-✅ **Context-Aware**: Recommendations adapt to project state and level
-✅ **Universal Entry Point**: Works with any agent
-✅ **New User Friendly**: Guides comprehensive workflow planning
-✅ **Status Visibility**: Clear progress tracking with current/next step indicators
-✅ **Phase Navigation**: Easy to jump between phases with planned path reference
-✅ **Level-Adaptive**: Plans adjust based on estimated project level (0-4)
-✅ **Brownfield Support**: Includes documentation needs in workflow plan
-
-## Future Enhancements
-
-- **Progress Dashboards**: Visual progress indicators
-- **Time Tracking**: Estimate time remaining
-- **Multi-Project**: Handle multiple projects
-- **Team Sync**: Show what teammates are working on
-
----
-
-**This workflow is the front door to BMad Method. Every user should start here or have it checked automatically by their agent.**

src/modules/bmm/workflows/1-analysis/workflow-status/bmm-workflow-status-template.md

@@ -1,338 +0,0 @@
-# Project Workflow Status
-
-**Project:** {{project_name}}
-**Created:** {{start_date}}
-**Last Updated:** {{last_updated}}
-**Status File:** `bmm-workflow-status.md`
-
----
-
-## Workflow Status Tracker
-
-**Current Phase:** {{current_phase}}
-**Current Workflow:** {{current_workflow}}
-**Current Agent:** {{current_agent}}
-**Overall Progress:** {{progress_percentage}}%
-
-### Phase Completion Status
-
-- [ ] **1-Analysis** - Research, brainstorm, brief (optional)
-- [ ] **2-Plan** - PRD/GDD/Tech-Spec + Stories/Epics
-- [ ] **3-Solutioning** - Architecture + Tech Specs (Level 2+ only)
-- [ ] **4-Implementation** - Story development and delivery
-
-### Planned Workflow Journey
-
-**This section documents your complete workflow plan from start to finish.**
-
-| Phase | Step | Agent | Description | Status |
-| ----- | ---- | ----- | ----------- | ------ |
-
-{{#planned_workflow}}
-| {{phase}} | {{step}} | {{agent}} | {{description}} | {{status}} |
-{{/planned_workflow}}
-
-**Current Step:** {{current_step}}
-**Next Step:** {{next_step}}
-
-**Instructions:**
-
-- This plan was created during initial workflow-status setup
-- Status values: Planned, Optional, Conditional, In Progress, Complete
-- Current/Next steps update as you progress through the workflow
-- Use this as your roadmap to know what comes after each phase
-
-### Implementation Progress (Phase 4 Only)
-
-**Story Tracking:** {{story_tracking_mode}}
-
-{{#if in_phase_4}}
-
-#### BACKLOG (Not Yet Drafted)
-
-**Ordered story sequence - populated at Phase 4 start:**
-
-| Epic | Story | ID  | Title | File |
-| ---- | ----- | --- | ----- | ---- |
-
-{{#backlog_stories}}
-| {{epic_num}} | {{story_num}} | {{story_id}} | {{story_title}} | {{story_file}} |
-{{/backlog_stories}}
-
-**Total in backlog:** {{backlog_count}} stories
-
-**Instructions:**
-
-- Stories move from BACKLOG → TODO when previous story is complete
-- SM agent uses story information from this table to draft new stories
-- Story order is sequential (Epic 1 stories first, then Epic 2, etc.)
-
-#### TODO (Needs Drafting)
-
-- **Story ID:** {{todo_story_id}}
-- **Story Title:** {{todo_story_title}}
-- **Story File:** `{{todo_story_file}}`
-- **Status:** Not created OR Draft (needs review)
-- **Action:** SM should run `create-story` workflow to draft this story
-
-**Instructions:**
-
-- Only ONE story in TODO at a time
-- Story stays in TODO until user marks it "ready for development"
-- SM reads this section to know which story to draft next
-- After SM creates/updates story, user reviews and approves via `story-ready` workflow
-
-#### IN PROGRESS (Approved for Development)
-
-- **Story ID:** {{current_story_id}}
-- **Story Title:** {{current_story_title}}
-- **Story File:** `{{current_story_file}}`
-- **Story Status:** Ready | In Review
-- **Context File:** `{{current_story_context_file}}`
-- **Action:** DEV should run `dev-story` workflow to implement this story
-
-**Instructions:**
-
-- Only ONE story in IN PROGRESS at a time
-- Story stays here until user marks it "approved" (DoD complete)
-- DEV reads this section to know which story to implement
-- After DEV completes story, user reviews and runs `story-approved` workflow
-
-#### DONE (Completed Stories)
-
-| Story ID | File | Completed Date | Points |
-| -------- | ---- | -------------- | ------ |
-
-{{#done_stories}}
-| {{story_id}} | {{story_file}} | {{completed_date}} | {{story_points}} |
-{{/done_stories}}
-
-**Total completed:** {{done_count}} stories
-**Total points completed:** {{done_points}} points
-
-**Instructions:**
-
-- Stories move here when user runs `story-approved` workflow (DEV agent)
-- Immutable record of completed work
-- Used for velocity tracking and progress reporting
-
-#### Epic/Story Summary
-
-**Total Epics:** {{total_epics}}
-**Total Stories:** {{total_stories}}
-**Stories in Backlog:** {{backlog_count}}
-**Stories in TODO:** {{todo_count}} (should always be 0 or 1)
-**Stories in IN PROGRESS:** {{in_progress_count}} (should always be 0 or 1)
-**Stories DONE:** {{done_count}}
-
-**Epic Breakdown:**
-{{#epics}}
-
-- Epic {{epic_number}}: {{epic_title}} ({{epic_done_stories}}/{{epic_total_stories}} stories complete)
-  {{/epics}}
-
-#### State Transition Logic
-
-**Story Lifecycle:**
-
-```
-BACKLOG → TODO → IN PROGRESS → DONE
-```
-
-**Transition Rules:**
-
-1. **BACKLOG → TODO**: Automatically when previous story moves TODO → IN PROGRESS
-2. **TODO → IN PROGRESS**: User runs SM agent `story-ready` workflow after reviewing drafted story
-3. **IN PROGRESS → DONE**: User runs DEV agent `story-approved` workflow after DoD complete
-
-**Important:**
-
-- SM agent NEVER searches for "next story" - always reads TODO section
-- DEV agent NEVER searches for "current story" - always reads IN PROGRESS section
-- Both agents update this status file after their workflows complete
-
-{{/if}}
-
-### Artifacts Generated
-
-| Artifact | Status | Location | Date |
-| -------- | ------ | -------- | ---- |
-
-{{#artifacts}}
-| {{name}} | {{status}} | {{path}} | {{date}} |
-{{/artifacts}}
-
-### Next Action Required
-
-**What to do next:** {{next_action}}
-
-**Command to run:** {{next_command}}
-
-**Agent to load:** {{next_agent}}
-
----
-
-## Assessment Results
-
-### Project Classification
-
-- **Project Type:** {{project_type}} ({{project_type_display_name}})
-- **Project Level:** {{project_level}}
-- **Instruction Set:** {{instruction_set}}
-- **Greenfield/Brownfield:** {{field_type}}
-
-### Scope Summary
-
-- **Brief Description:** {{scope_description}}
-- **Estimated Stories:** {{story_count}}
-- **Estimated Epics:** {{epic_count}}
-- **Timeline:** {{timeline}}
-
-### Context
-
-- **Existing Documentation:** {{existing_docs}}
-- **Team Size:** {{team_size}}
-- **Deployment Intent:** {{deployment_intent}}
-
-## Recommended Workflow Path
-
-### Primary Outputs
-
-{{expected_outputs}}
-
-### Workflow Sequence
-
-{{workflow_steps}}
-
-### Next Actions
-
-{{next_steps}}
-
-## Special Considerations
-
-{{special_notes}}
-
-## Technical Preferences Captured
-
-{{technical_preferences}}
-
-## Story Naming Convention
-
-### Level 0 (Single Atomic Change)
-
-- **Format:** `story-<short-title>.md`
-- **Example:** `story-icon-migration.md`, `story-login-fix.md`
-- **Location:** `{{dev_story_location}}/`
-- **Max Stories:** 1 (if more needed, consider Level 1)
-
-### Level 1 (Coherent Feature)
-
-- **Format:** `story-<title>-<n>.md`
-- **Example:** `story-oauth-integration-1.md`, `story-oauth-integration-2.md`
-- **Location:** `{{dev_story_location}}/`
-- **Max Stories:** 2-3 (prefer longer stories over more stories)
-
-### Level 2+ (Multiple Epics)
-
-- **Format:** `story-<epic>.<story>.md`
-- **Example:** `story-1.1.md`, `story-1.2.md`, `story-2.1.md`
-- **Location:** `{{dev_story_location}}/`
-- **Max Stories:** Per epic breakdown in epics.md
-
-## Decision Log
-
-### Planning Decisions Made
-
-{{#decisions}}
-
-- **{{decision_date}}**: {{decision_description}}
-  {{/decisions}}
-
----
-
-## Change History
-
-{{#changes}}
-
-### {{change_date}} - {{change_author}}
-
-- Phase: {{change_phase}}
-- Changes: {{change_description}}
-  {{/changes}}
-
----
-
-## Agent Usage Guide
-
-### For SM (Scrum Master) Agent
-
-**When to use this file:**
-
-- Running `create-story` workflow → Read "TODO (Needs Drafting)" section for exact story to draft
-- Running `story-ready` workflow → Update status file, move story from TODO → IN PROGRESS, move next story from BACKLOG → TODO
-- Checking epic/story progress → Read "Epic/Story Summary" section
-
-**Key fields to read:**
-
-- `todo_story_id` → The story ID to draft (e.g., "1.1", "auth-feature-1")
-- `todo_story_title` → The story title for drafting
-- `todo_story_file` → The exact file path to create
-
-**Key fields to update:**
-
-- Move completed TODO story → IN PROGRESS section
-- Move next BACKLOG story → TODO section
-- Update story counts
-
-**Workflows:**
-
-1. `create-story` - Drafts the story in TODO section (user reviews it)
-2. `story-ready` - After user approval, moves story TODO → IN PROGRESS
-
-### For DEV (Developer) Agent
-
-**When to use this file:**
-
-- Running `dev-story` workflow → Read "IN PROGRESS (Approved for Development)" section for current story
-- Running `story-approved` workflow → Update status file, move story from IN PROGRESS → DONE, move TODO story → IN PROGRESS, move BACKLOG story → TODO
-- Checking what to work on → Read "IN PROGRESS" section
-
-**Key fields to read:**
-
-- `current_story_file` → The story to implement
-- `current_story_context_file` → The context XML for this story
-- `current_story_status` → Current status (Ready | In Review)
-
-**Key fields to update:**
-
-- Move completed IN PROGRESS story → DONE section with completion date
-- Move TODO story → IN PROGRESS section
-- Move next BACKLOG story → TODO section
-- Update story counts and points
-
-**Workflows:**
-
-1. `dev-story` - Implements the story in IN PROGRESS section
-2. `story-approved` - After user approval (DoD complete), moves story IN PROGRESS → DONE
-
-### For PM (Product Manager) Agent
-
-**When to use this file:**
-
-- Checking overall progress → Read "Phase Completion Status"
-- Planning next phase → Read "Overall Progress" percentage
-- Course correction → Read "Decision Log" for context
-
-**Key fields:**
-
-- `progress_percentage` → Overall project progress
-- `current_phase` → What phase are we in
-- `artifacts` table → What's been generated
-
----
-
-_This file serves as the **single source of truth** for project workflow status, epic/story tracking, and next actions. All BMM agents and workflows reference this document for coordination._
-
-_Template Location: `bmad/bmm/workflows/_shared/bmm-workflow-status-template.md`_
-
-_File Created: {{start_date}}_

src/modules/bmm/workflows/1-analysis/workflow-status/instructions.md

@@ -1,755 +0,0 @@
-# Workflow Status - Master Router and Status Tracker
-
-<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
-<critical>You MUST have already loaded and processed: {project-root}/bmad/bmm/workflows/1-analysis/workflow-status/workflow.yaml</critical>
-<critical>Communicate all responses in {communication_language}</critical>
-
-<workflow>
-
-<critical>This is the UNIVERSAL ENTRY POINT for all BMM workflows</critical>
-<critical>Can be invoked by bmad-master, analyst, or pm agents</critical>
-<critical>Checks for existing workflow status and suggests next actions</critical>
-<critical>If no status exists, helps user plan their workflow approach</critical>
-
-<step n="1" goal="Check for existing workflow status file">
-
-<action>Search {output_folder}/ for files matching pattern: bmm-workflow-status\*.md</action>
-<action>Use glob or list_files to find all matching files</action>
-
-<check if="files found">
-  <action>Find the most recent file (by date in filename: bmm-workflow-status.md)</action>
-  <action>Set status_file_found = true</action>
-  <action>Set status_file_path = most recent file path</action>
-  <action>Go to Step 2 (Read existing status)</action>
-</check>
-
-<check if="no files found">
-  <action>Set status_file_found = false</action>
-  <action>Go to Step 3 (Initial workflow planning)</action>
-</check>
-
-</step>
-
-<step n="2" goal="Read and analyze existing workflow status" if="status_file_found == true">
-
-<action>Read {status_file_path}</action>
-
-<action>Extract key information:</action>
-
-**Project Context:**
-
-- project_name: From "Project:" field
-- start_date: From "Created:" field
-- last_updated: From "Last Updated:" field
-
-**Current State:**
-
-- current_phase: From "Current Phase:" field (1-Analysis, 2-Plan, 3-Solutioning, 4-Implementation)
-- current_workflow: From "Current Workflow:" field
-- progress_percentage: From "Overall Progress:" field
-- project_level: From "Project Level:" field (0, 1, 2, 3, or 4)
-- project_type: From "Project Type:" field
-- field_type: From "Greenfield/Brownfield:" field
-
-**Phase Completion:**
-
-- phase_1_complete: Check if "1-Analysis" checkbox is checked
-- phase_2_complete: Check if "2-Plan" checkbox is checked
-- phase_3_complete: Check if "3-Solutioning" checkbox is checked
-- phase_4_complete: Check if "4-Implementation" checkbox is checked
-
-**Implementation Progress (if Phase 4):**
-
-- Read "### Implementation Progress (Phase 4 Only)" section
-- Extract TODO story (if exists)
-- Extract IN PROGRESS story (if exists)
-- Extract BACKLOG count
-- Extract DONE count
-
-**Next Action:**
-
-- next_action: From "What to do next:" field
-- next_command: From "Command to run:" field
-- next_agent: From "Agent to load:" field
-
-<action>Analyze the current state to determine recommendation</action>
-
-</step>
-
-<step n="2.5" goal="Display current workflow status and suggest next action" if="status_file_found == true">
-
-<action>Display comprehensive status summary</action>
-
-**📊 Current Workflow Status**
-
-**Project:** {{project_name}}
-**Started:** {{start_date}}
-**Last Updated:** {{last_updated}}
-
-**Current Phase:** {{current_phase}} ({{progress_percentage}}% complete)
-**Current Workflow:** {{current_workflow}}
-
-**Phase Completion:**
-
-- [{{phase_1_complete ? 'x' : ' '}}] Phase 1: Analysis
-- [{{phase_2_complete ? 'x' : ' '}}] Phase 2: Planning
-- [{{phase_3_complete ? 'x' : ' '}}] Phase 3: Solutioning ({{project_level < 3 ? 'skipped for Level ' + project_level : 'required'}})
-- [{{phase_4_complete ? 'x' : ' '}}] Phase 4: Implementation
-
-**Project Details:**
-
-- **Level:** {{project_level}} ({{get_level_description(project_level)}})
-- **Type:** {{project_type}}
-- **Context:** {{field_type}}
-
-{{#if current_phase == '4-Implementation'}}
-**Implementation Progress:**
-
-- **BACKLOG:** {{backlog_count}} stories
-- **TODO:** {{todo_story_id}} ({{todo_story_status}})
-- **IN PROGRESS:** {{current_story_id}} ({{current_story_status}})
-- **DONE:** {{done_count}} stories ({{done_points}} points)
-  {{/if}}
-
----
-
-**🎯 Recommended Next Action:**
-
-{{next_action}}
-
-**Command:** {{next_command}}
-**Agent:** {{next_agent}}
-
-<ask>Would you like to:
-
-1. **Proceed with recommended action** ({{next_command}})
-2. **View detailed status** (show full status file)
-3. **Change workflow** (modify current workflow or start new phase)
-4. **Display agent menu** (see all available options)
-5. **Exit** (return to agent)
-
-Select option (1-5):</ask>
-
-<check if='option == "1"'>
-  <action>Suggest loading the recommended agent and running the command</action>
-  <output>**To proceed:**
-
-Load agent: `{{next_agent}}`
-Run command: `{{next_command}}`
-
-Or tell me: "load {{next_agent}} and {{next_command}}"
-</output>
-</check>
-
-<check if='option == "2"'>
-  <action>Display full status file contents</action>
-  <action>Return to menu</action>
-</check>
-
-<check if='option == "3"'>
-  <action>Go to Step 4 (Change workflow)</action>
-</check>
-
-<check if='option == "4"'>
-  <action>Go to Step 5 (Display agent menu)</action>
-</check>
-
-<check if='option == "5"'>
-  <action>Exit workflow</action>
-</check>
-
-</step>
-
-<step n="3" goal="Initial workflow planning - no status file exists" if="status_file_found == false">
-
-<action>Display welcome message in {communication_language}</action>
-
-**🚀 Welcome to BMad Method Workflows, {user_name}!**
-
-No workflow status file found. Let's plan your complete workflow journey.
-
-<critical>This step will map out your ENTIRE workflow before executing anything</critical>
-<critical>Goal: Document planned phases, current step, and next step in status file</critical>
-
-<ask>**Step 1: Project Context**
-
-**Is this a new or existing codebase?**
-a. **Greenfield** - Starting from scratch
-b. **Brownfield** - Adding to existing codebase
-
-Your choice (a/b):</ask>
-
-<action>Capture field_type = "greenfield" or "brownfield"</action>
-
-<check if='field_type == "brownfield"'>
-  <ask>**Step 2: Brownfield Documentation Status**
-
-Do you have:
-
-- Architecture documentation?
-- Code structure overview?
-- API documentation?
-- Clear understanding of existing patterns?
-
-Options:
-a. **Yes** - I have good documentation
-b. **No** - Codebase is undocumented or poorly documented
-c. **Partial** - Some docs exist but incomplete
-
-Your choice (a/b/c):</ask>
-
-<action>Capture brownfield_docs_status</action>
-
-  <check if='brownfield_docs_status == "b" OR brownfield_docs_status == "c"'>
-    <output>**⚠️ Documentation Needed**
-
-For accurate planning, brownfield projects benefit from codebase documentation.
-We'll add `document-project` to your planned workflow.
-</output>
-<action>Set needs_documentation = true</action>
-</check>
-
-  <check if='brownfield_docs_status == "a"'>
-    <action>Set needs_documentation = false</action>
-  </check>
-</check>
-
-<check if='field_type == "greenfield"'>
-  <action>Set needs_documentation = false</action>
-</check>
-
-<ask>**Step 3: Project Type**
-
-What type of project are you building?
-
-1. **Game** - Video games for PC, console, mobile, or web
-2. **Web Application** - Websites, web apps, SPAs
-3. **Mobile Application** - iOS, Android apps
-4. **Desktop Application** - Windows, macOS, Linux apps
-5. **Backend/API Service** - Backend services, APIs, microservices
-6. **Library/SDK** - Reusable libraries, packages, SDKs
-7. **CLI Tool** - Command-line tools and utilities
-8. **Embedded System** - IoT, firmware, embedded devices
-9. **Data/ML/Analytics** - Data pipelines, ML projects, analytics
-10. **Browser Extension** - Chrome, Firefox extensions
-11. **Infrastructure/DevOps** - Terraform, K8s operators, CI/CD
-12. **Other** - Describe your project type
-
-Your choice (1-12):</ask>
-
-<action>Capture project_type_choice</action>
-
-<action>Map choice to project_type_id using project-types.csv:</action>
-
-- 1 → game
-- 2 → web
-- 3 → mobile
-- 4 → desktop
-- 5 → backend
-- 6 → library
-- 7 → cli
-- 8 → embedded
-- 9 → data
-- 10 → extension
-- 11 → infra
-- 12 → custom (capture description)
-
-<action>Set project_type = mapped project_type_id</action>
-
-<ask>**Step 4: User Interface Components**
-
-Does your project involve user-facing UI components?
-
-a. **Yes** - Project has user interface elements (web pages, mobile screens, desktop UI, game UI)
-b. **No** - Backend-only, API, CLI, or no visual interface
-
-Your choice (a/b):</ask>
-
-<action>Capture has_ui_components</action>
-
-<check if='has_ui_components == "a"'>
-  <action>Set needs_ux_workflow = true</action>
-  <output>**✅ UX Workflow Detected**
-
-Since your project has UI components, we'll include the UX specification workflow in Phase 2.
-This ensures proper UX/UI design happens between PRD and architecture/implementation.
-</output>
-</check>
-
-<check if='has_ui_components == "b"'>
-  <action>Set needs_ux_workflow = false</action>
-</check>
-
-<output>**Step 5: Understanding Your Workflow**
-
-Before we plan your workflow, let's determine the scope and complexity of your project.
-
-The BMad Method uses 5 project levels (0-4) that determine which phases you'll need:
-
-- **Level 0:** Single atomic change (1 story) - Phases 2 → 4
-- **Level 1:** Small feature (2-3 stories, 1 epic) - Phases 2 → 4
-- **Level 2:** Medium project (multiple epics) - Phases 2 → 4
-- **Level 3:** Complex system (subsystems, integrations) - Phases 2 → 3 → 4
-- **Level 4:** Enterprise scale (multiple products) - Phases 2 → 3 → 4
-
-**Optional Phase 1 (Analysis):** Brainstorming, research, and brief creation can precede any level.
-</output>
-
-<ask>**Step 6: Project Scope Assessment**
-
-Do you already know your project's approximate size/scope?
-
-a. **Yes** - I can describe the general scope
-b. **No** - Not sure yet, need help determining it
-c. **Want analysis first** - Do brainstorming/research before deciding
-
-Your choice (a/b/c):</ask>
-
-<action>Capture scope_knowledge</action>
-
-<check if='scope_knowledge == "a"'>
-  <ask>**Based on the descriptions above, what level best describes your project?**
-
-0. Single atomic change (bug fix, tiny feature)
-1. Small coherent feature (2-3 stories)
-2. Medium project (multiple features/epics)
-3. Complex system (subsystems, architectural decisions)
-4. Enterprise scale (multiple products/systems)
-
-Your estimated level (0-4):</ask>
-
-<action>Capture estimated_level</action>
-<action>Set level_known = true</action>
-</check>
-
-<check if='scope_knowledge == "b" OR scope_knowledge == "c"'>
-  <output>**Level determination deferred**
-
-{{#if scope_knowledge == "b"}}
-No problem! The `plan-project` workflow will help you determine the project level through guided questions.
-{{/if}}
-
-{{#if scope_knowledge == "c"}}
-Great! Analysis workflows will help clarify scope before determining the level.
-{{/if}}
-
-We'll determine your project level during Phase 2 (Planning).
-</output>
-<action>Set level_known = false</action>
-<action>Set estimated_level = "TBD"</action>
-</check>
-
-<ask>**Step 7: Choose Your Starting Point**
-
-Now let's determine where you want to begin:
-
-**Option A: Full Analysis Phase First**
-
-- Brainstorming (explore ideas, validate concepts)
-- Research (market, technical, competitive analysis)
-- Product/Game Brief (strategic foundation)
-  → Best for: New ideas, uncertain requirements, need validation
-
-**Option B: Skip to Planning**
-
-- You know what to build
-- Jump to PRD/GDD/Tech-Spec generation
-  → Best for: Clear requirements, existing ideas
-
-**Option C: Just Show Menu**
-
-- Create status file with planned workflow
-- I'll manually choose which workflow to run first
-  → Best for: Experienced users, custom paths
-
-Your choice (A/B/C):</ask>
-
-<action>Capture starting_point</action>
-
-<check if='starting_point == "A"'>
-  <ask>**Full Analysis - Choose your first workflow:**
-
-1. **brainstorm-project** (Analyst) - Explore software solution ideas
-2. **brainstorm-game** (Game Designer) - Game concept ideation
-3. **research** (Analyst) - Market/technical research
-4. **product-brief** (Analyst) - Strategic product foundation
-5. **game-brief** (Game Designer) - Game design foundation
-
-Which workflow? (1-5):</ask>
-
-<action>Capture first_workflow</action>
-<action>Set include_analysis = true</action>
-</check>
-
-<check if='starting_point == "B"'>
-  <action>Set include_analysis = false</action>
-  <action>Set first_workflow = "plan-project"</action>
-</check>
-
-<check if='starting_point == "C"'>
-  <action>Set include_analysis = false</action>
-  <action>Set first_workflow = "user-choice"</action>
-</check>
-
-<action>Now build the complete planned workflow</action>
-
-<output>**🗺️ Your Planned Workflow**
-
-Based on your responses, here's your complete workflow journey:
-</output>
-
-<action>Build planned_workflow array with all phases in order:</action>
-
-<check if='needs_documentation == true'>
-  <action>Add to planned_workflow:</action>
-  - Phase: "1-Analysis"
-  - Step: "document-project"
-  - Agent: "Analyst"
-  - Description: "Generate brownfield codebase documentation"
-  - Status: "Planned"
-</check>
-
-<check if='include_analysis == true'>
-  <action>Add analysis workflows to planned_workflow based on first_workflow choice</action>
-
-{{#if first_workflow == "brainstorm-project"}} - Phase: "1-Analysis", Step: "brainstorm-project", Agent: "Analyst", Status: "Planned" - Phase: "1-Analysis", Step: "research (optional)", Agent: "Analyst", Status: "Optional" - Phase: "1-Analysis", Step: "product-brief", Agent: "Analyst", Status: "Planned"
-{{/if}}
-
-{{#if first_workflow == "brainstorm-game"}} - Phase: "1-Analysis", Step: "brainstorm-game", Agent: "Game Designer", Status: "Planned" - Phase: "1-Analysis", Step: "research (optional)", Agent: "Analyst", Status: "Optional" - Phase: "1-Analysis", Step: "game-brief", Agent: "Game Designer", Status: "Planned"
-{{/if}}
-
-{{#if first_workflow == "research"}} - Phase: "1-Analysis", Step: "research", Agent: "Analyst", Status: "Planned" - Phase: "1-Analysis", Step: "product-brief or game-brief", Agent: "Analyst/Game Designer", Status: "Planned"
-{{/if}}
-
-{{#if first_workflow == "product-brief"}} - Phase: "1-Analysis", Step: "product-brief", Agent: "Analyst", Status: "Planned"
-{{/if}}
-
-{{#if first_workflow == "game-brief"}} - Phase: "1-Analysis", Step: "game-brief", Agent: "Game Designer", Status: "Planned"
-{{/if}}
-</check>
-
-<action>Always add Phase 2 (required for all levels) - route based on project type and level</action>
-
-<check if='project_type == "game"'>
-  <action>Add game planning workflow</action>
-  - Phase: "2-Plan"
-  - Step: "gdd"
-  - Agent: "PM"
-  - Description: "Create Game Design Document"
-  - Status: "Planned"
-</check>
-
-<check if='project_type != "game"'>
-  <check if='level_known == true AND estimated_level <= 1'>
-    <action>Add tech-spec workflow (Levels 0-1)</action>
-    - Phase: "2-Plan"
-    - Step: "tech-spec"
-    - Agent: "Architect"
-    - Description: "Create technical specification and stories"
-    - Status: "Planned"
-  </check>
-
-  <check if='level_known == true AND estimated_level >= 2'>
-    <action>Add PRD workflow (Levels 2-4)</action>
-    - Phase: "2-Plan"
-    - Step: "prd"
-    - Agent: "PM"
-    - Description: "Create Product Requirements Document and epics"
-    - Status: "Planned"
-  </check>
-
-  <check if='level_known == false OR estimated_level == "TBD"'>
-    <action>Add conditional planning note</action>
-    - Phase: "2-Plan"
-    - Step: "TBD - Level 0-1 → tech-spec, Level 2-4 → prd"
-    - Agent: "PM or Architect"
-    - Description: "Workflow determined after level assessment"
-    - Status: "Conditional"
-  </check>
-</check>
-
-<check if='needs_ux_workflow == true'>
-  <action>Add UX workflow to Phase 2 planning (runs after PRD, before Phase 3)</action>
-  - Phase: "2-Plan"
-  - Step: "ux-spec"
-  - Agent: "PM"
-  - Description: "UX/UI specification (user flows, wireframes, components)"
-  - Status: "Planned"
-  - Note: "Required for projects with UI components"
-</check>
-
-<check if='level_known == true AND estimated_level >= 3'>
-  <action>Add Phase 3 (required for Level 3-4)</action>
-  - Phase: "3-Solutioning"
-  - Step: "solution-architecture"
-  - Agent: "Architect"
-  - Description: "Design overall architecture"
-  - Status: "Planned"
-
-- Phase: "3-Solutioning"
-- Step: "tech-spec (per epic, JIT)"
-- Agent: "Architect"
-- Description: "Epic-specific technical specs"
-- Status: "Planned"
-  </check>
-
-<check if='level_known == false OR estimated_level == "TBD"'>
-  <action>Add conditional Phase 3 note</action>
-  - Phase: "3-Solutioning"
-  - Step: "TBD - depends on level from Phase 2"
-  - Agent: "Architect"
-  - Description: "Required if Level 3-4, skipped if Level 0-2"
-  - Status: "Conditional"
-</check>
-
-<action>Always add Phase 4 (implementation)</action>
-
-- Phase: "4-Implementation"
-- Step: "create-story (iterative)"
-- Agent: "SM"
-- Description: "Draft stories from backlog"
-- Status: "Planned"
-
-- Phase: "4-Implementation"
-- Step: "story-ready"
-- Agent: "SM"
-- Description: "Approve story for dev"
-- Status: "Planned"
-
-- Phase: "4-Implementation"
-- Step: "story-context"
-- Agent: "SM"
-- Description: "Generate context XML"
-- Status: "Planned"
-
-- Phase: "4-Implementation"
-- Step: "dev-story (iterative)"
-- Agent: "DEV"
-- Description: "Implement stories"
-- Status: "Planned"
-
-- Phase: "4-Implementation"
-- Step: "story-approved"
-- Agent: "DEV"
-- Description: "Mark complete, advance queue"
-- Status: "Planned"
-
-<action>Display the complete planned workflow</action>
-
-<output>**📋 Your Complete Planned Workflow:**
-
-{{#each planned_workflow}}
-**{{phase}}** - {{step}}
-
-- Agent: {{agent}}
-- Description: {{description}}
-- Status: {{status}}
-
-{{/each}}
-
----
-
-**Current Step:** Workflow Definition Phase (this workflow)
-**Next Step:** {{planned_workflow[0].step}} ({{planned_workflow[0].agent}} agent)
-</output>
-
-<ask>**Ready to create your workflow status file?**
-
-This will create: `bmm-workflow-status.md`
-
-The status file will document:
-
-- Your complete planned workflow (phases and steps)
-- Current phase: "Workflow Definition"
-- Next action: {{planned_workflow[0].step}}
-
-Create status file? (y/n)</ask>
-
-<check if='confirm == "y"'>
-  <action>Create bmm-workflow-status.md file</action>
-  <action>Set current_phase = "Workflow Definition"</action>
-  <action>Set next_action = planned_workflow[0].step</action>
-  <action>Set next_agent = planned_workflow[0].agent</action>
-  <action>Include complete planned_workflow in status file</action>
-
-<output>**✅ Status file created, {user_name}!**
-
-File: `bmm-workflow-status.md`
-
-**To proceed with your first step:**
-
-{{#if needs_documentation == true AND planned_workflow[0].step == "document-project"}}
-Load Analyst: `bmad analyst document-project`
-
-After documentation is complete, return to check status: `bmad analyst workflow-status`
-{{/if}}
-
-{{#if planned_workflow[0].step != "document-project" AND planned_workflow[0].step != "user-choice"}}
-{{#if planned_workflow[0].step == "gdd"}}
-Load PM: `bmad pm gdd`
-{{else if planned_workflow[0].step == "tech-spec"}}
-Load Architect: `bmad architect tech-spec`
-{{else if planned_workflow[0].step == "prd"}}
-Load PM: `bmad pm prd`
-{{else}}
-Load {{planned_workflow[0].agent}}: `bmad {{lowercase planned_workflow[0].agent}} {{planned_workflow[0].step}}`
-{{/if}}
-{{/if}}
-
-{{#if planned_workflow[0].step == "user-choice"}}
-Your status file is ready! Run `workflow-status` anytime to see recommendations.
-
-Choose any workflow from the menu to begin.
-{{/if}}
-
-You can always check your status with: `workflow-status`
-</output>
-</check>
-
-<check if='confirm == "n"'>
-  <action>Go to Step 5 (Display agent menu)</action>
-</check>
-
-</step>
-
-<step n="4" goal="Change workflow or start new phase" optional="true">
-
-<ask>**Change Workflow Options:**
-
-1. **Start new workflow** (will archive current status, create new dated file)
-2. **Jump to different phase** (manual phase override)
-3. **Modify current workflow** (change current_workflow field)
-4. **View phase options** (see what's available for current level)
-5. **Cancel** (return to status display)
-
-Your choice (1-5):</ask>
-
-<action>Handle workflow change based on choice</action>
-
-<check if='choice == "1"'>
-  <ask>**Start New Workflow**
-
-This will:
-
-- Archive current status: `bmm-workflow-status.md` → `archive/`
-- Create new status: `bmm-workflow-status.md`
-- Start fresh assessment
-
-Continue? (y/n)</ask>
-
-  <check if="confirm == 'y'">
-    <output>**To start new workflow:**
-
-Run: `bmad analyst workflow-status`
-
-This will guide you through fresh workflow assessment and create a new status file.
-</output>
-</check>
-</check>
-
-<check if='choice == "2"'>
-  <ask>**Jump to Phase:**
-
-Current phase: {{current_phase}}
-
-Available phases:
-
-1. Phase 1: Analysis
-2. Phase 2: Planning
-3. Phase 3: Solutioning ({{project_level >= 3 ? 'required for your level' : 'skipped for Level ' + project_level}})
-4. Phase 4: Implementation
-
-Which phase? (1-4)</ask>
-
-<action>Provide guidance for jumping to selected phase</action>
-</check>
-
-</step>
-
-<step n="5" goal="Display agent menu">
-
-<action>Display comprehensive agent menu based on current context</action>
-
-**📋 BMad Method Agent Menu**
-
-{{#if status_file_found}}
-**Current Phase:** {{current_phase}}
-{{/if}}
-
-**Available Workflows by Phase:**
-
-**Phase 1: Analysis (Optional)**
-
-- `brainstorm-project` - Software solution exploration
-- `brainstorm-game` - Game concept ideation
-- `research` - Market/technical research
-- `product-brief` - Strategic product foundation
-- `game-brief` - Game design foundation
-
-**Phase 2: Planning (Required)**
-
-- `prd` - Product Requirements Document (Level 2-4 software projects)
-- `tech-spec` - Technical specification (Level 0-1 software projects)
-- `gdd` - Game Design Document (game projects)
-- `ux-spec` - UX/UI specification (for projects with UI components)
-
-**Phase 3: Solutioning (Level 3-4 Only)**
-
-- `solution-architecture` - Overall architecture design
-- `tech-spec` - Epic-specific technical specs (JIT)
-
-**Phase 4: Implementation (Iterative)**
-
-- `create-story` - Draft story from TODO
-- `story-ready` - Approve story for development
-- `story-context` - Generate context XML
-- `dev-story` - Implement story
-- `story-approved` - Mark story done
-- `review-story` - Quality validation
-- `correct-course` - Handle issues
-- `retrospective` - Epic learnings
-
-**Utility Workflows:**
-
-- `workflow-status` - Check status and get recommendations (you are here!)
-
-{{#if status_file_found}}
-
-**🎯 Recommended for Your Current Phase ({{current_phase}}):**
-
-{{#if current_phase == '1-Analysis'}}
-Continue analysis or move to Phase 2 Planning (prd/tech-spec/gdd based on your project)
-{{/if}}
-
-{{#if current_phase == '2-Plan'}}
-{{#if project_level < 2}}
-Ready for Phase 4! Run `create-story` (SM agent)
-{{else if project_level == 2}}
-Run `tech-spec` workflow for lightweight technical planning, then Phase 4
-{{else}}
-Ready for Phase 3! Run `solution-architecture` (Architect agent)
-{{/if}}
-{{/if}}
-
-{{#if current_phase == '3-Solutioning'}}
-Continue with tech-specs or move to Phase 4 `create-story`
-{{/if}}
-
-{{#if current_phase == '4-Implementation'}}
-**Current Story:** {{todo_story_id || current_story_id || 'Check status file'}}
-**Next Action:** {{next_command}}
-{{/if}}
-
-{{/if}}
-
-<ask>Would you like to:
-
-1. Run a specific workflow (tell me which one)
-2. Return to status display
-3. Exit
-
-Your choice:</ask>
-
-</step>
-
-</workflow>

src/modules/bmm/workflows/1-analysis/workflow-status/workflow.yaml

@@ -1,20 +0,0 @@
-# Workflow Status - Master Router and Status Tracker
-name: workflow-status
-description: "Universal entry point for BMM workflows. Checks for existing workflow status, displays current state, suggests next actions, or helps plan new workflow. Can be invoked by any agent (bmad-master, analyst, pm) to understand where the project is and what to do next."
-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"
-date: system-generated
-
-# Workflow components
-installed_path: "{project-root}/bmad/bmm/workflows/1-analysis/workflow-status"
-instructions: "{installed_path}/instructions.md"
-
-# Output configuration - no output file, reads existing status
-default_output_file: ""
-
-web_bundle: false

src/modules/bmm/workflows/2-plan-workflows/gdd/instructions-gdd.md

@@ -4,67 +4,85 @@
 
 <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>Communicate all responses in {communication_language}</critical>
+<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
+<critical>Generate all documents in {document_output_language}</critical>
 <critical>This is the GDD instruction set for GAME projects - replaces PRD with Game Design Document</critical>
 <critical>Project analysis already completed - proceeding with game-specific design</critical>
 <critical>Uses gdd_template for GDD output, game_types.csv for type-specific sections</critical>
 <critical>Routes to 3-solutioning for architecture (platform-specific decisions handled there)</critical>
 <critical>If users mention technical details, append to technical_preferences with timestamp</critical>
 
-<step n="0" goal="Check for workflow status file - REQUIRED">
+<critical>DOCUMENT OUTPUT: Concise, clear, actionable game design specs. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
 
-<action>Check if bmm-workflow-status.md exists in {output_folder}/</action>
+<step n="0" goal="Validate workflow and extract project configuration">
 
-<check if="not exists">
+<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+  <param>mode: data</param>
+  <param>data_request: project_config</param>
+</invoke-workflow>
+
+<check if="status_exists == false">
   <output>**⚠️ No Workflow Status File Found**
 
-The GDD workflow requires an existing workflow status file to understand your project context.
+The GDD workflow requires a status file to understand your project context.
 
-Please run `workflow-status` first to:
+Please run `workflow-init` first to:
 
-- Map out your complete workflow journey
+- Define your project type and level
-- Determine project type and level
+- Map out your workflow journey
-- Create the status file with your planned workflow
+- Create the status file
 
-**To proceed:**
+Run: `workflow-init`
 
-Run: `bmad analyst workflow-status`
+After setup, return here to create your GDD.
-
-After completing workflow planning, you'll be directed back to this workflow.
 </output>
 <action>Exit workflow - cannot proceed without status file</action>
 </check>
 
-<check if="exists">
+<check if="status_exists == true">
-  <action>Load status file and proceed to Step 1</action>
+  <action>Store {{status_file_path}} for later updates</action>
-</check>
 
+  <check if="project_type != 'game'">
+    <output>**Incorrect Workflow for Software Projects**
+
+Your project is type: {{project_type}}
+
+**Correct workflows for software projects:**
+
+- Level 0-1: `tech-spec` (Architect agent)
+- Level 2-4: `prd` (PM agent)
+
+{{#if project_level <= 1}}
+Use: `tech-spec`
+{{else}}
+Use: `prd`
+{{/if}}
+</output>
+<action>Exit and redirect to appropriate workflow</action>
+</check>
+</check>
+</step>
+
+<step n="0.5" goal="Validate workflow sequencing">
+
+<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+  <param>mode: validate</param>
+  <param>calling_workflow: gdd</param>
+</invoke-workflow>
+
+<check if="warning != ''">
+  <output>{{warning}}</output>
+  <ask>Continue with GDD anyway? (y/n)</ask>
+  <check if="n">
+    <output>{{suggestion}}</output>
+    <action>Exit workflow</action>
+  </check>
+</check>
 </step>
 
 <step n="1" goal="Load context and determine game type">
 
-<action>Load bmm-workflow-status.md</action>
+<action>Use {{project_type}} and {{project_level}} from status data</action>
-<action>Confirm project_type == "game"</action>
-
-<check if="project_type != game">
-  <error>This workflow is for game projects only. Software projects should use PRD or tech-spec workflows.</error>
-  <output>**Incorrect Workflow for Software Projects**
-
-Your status file indicates project_type: {{project_type}}
-
-**Correct workflows for software projects:**
-
-- Level 0-1: `tech-spec` (run with Architect agent)
-- Level 2-4: `prd` (run with PM agent)
-
-{{#if project_level <= 1}}
-Run: `bmad architect tech-spec`
-{{else}}
-Run: `bmad pm prd`
-{{/if}}
-</output>
-<action>Exit and redirect user to appropriate software workflow</action>
-</check>
 
 <check if="continuation_mode == true">
   <action>Load existing GDD.md and check completion status</action>
@@ -306,7 +324,23 @@ For each {{placeholder}} in the fragment, elicit and capture that information.
 
 </step>
 
-<step n="15" goal="Generate solutioning handoff and next steps">
+<step n="15" goal="Update status and populate story sequence">
+
+<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+  <param>mode: update</param>
+  <param>action: complete_workflow</param>
+  <param>workflow_name: gdd</param>
+  <param>populate_stories_from: {epics_output_file}</param>
+</invoke-workflow>
+
+<check if="success == true">
+  <output>Status updated! Next: {{next_workflow}} ({{next_agent}} agent)</output>
+  <output>Loaded {{total_stories}} stories from epics.</output>
+</check>
+
+</step>
+
+<step n="16" goal="Generate solutioning handoff and next steps">
 
 <action>Check if game-type fragment contained narrative tags indicating narrative importance</action>
 

src/modules/bmm/workflows/2-plan-workflows/gdd/workflow.yaml

@@ -8,6 +8,8 @@ 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
 
 # Workflow components

src/modules/bmm/workflows/2-plan-workflows/narrative/instructions-narrative.md

@@ -10,6 +10,23 @@
 <critical>If users mention gameplay mechanics, note them but keep focus on narrative</critical>
 <critical>Facilitate good brainstorming techniques throughout with the user, pushing them to come up with much of the narrative you will help weave together. The goal is for the user to feel that they crafted the narrative and story arc unless they push you to do it all or indicate YOLO</critical>
 
+<step n="0" goal="Check for workflow status">
+
+<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+  <param>mode: init-check</param>
+</invoke-workflow>
+
+<check if="status_exists == true">
+  <action>Store {{status_file_path}} for later updates</action>
+  <action>Set tracking_mode = true</action>
+</check>
+
+<check if="status_exists == false">
+  <action>Set tracking_mode = false</action>
+  <output>Note: Running without workflow tracking. Run `workflow-init` to enable progress tracking.</output>
+</check>
+</step>
+
 <step n="1" goal="Load GDD context and assess narrative complexity">
 
 <action>Load GDD.md from {output_folder}</action>
@@ -522,4 +539,19 @@ Which would you like?</ask>
 
 </step>
 
+<step n="17" goal="Update status if tracking enabled">
+
+<check if="tracking_mode == true">
+  <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+    <param>mode: update</param>
+    <param>action: complete_workflow</param>
+    <param>workflow_name: narrative</param>
+  </invoke-workflow>
+
+  <check if="success == true">
+    <output>✅ Status updated! Next: {{next_workflow}}</output>
+  </check>
+</check>
+</step>
+
 </workflow>

src/modules/bmm/workflows/2-plan-workflows/narrative/workflow.yaml

@@ -8,6 +8,8 @@ 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
 
 # Workflow components

src/modules/bmm/workflows/2-plan-workflows/prd/instructions.md

@@ -2,73 +2,86 @@
 
 <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>Communicate all responses in {communication_language}</critical>
+<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
+<critical>Generate all documents in {document_output_language}</critical>
 <critical>This workflow is for Level 2-4 projects. Level 0-1 use tech-spec workflow.</critical>
 <critical>Produces TWO outputs: PRD.md (strategic) and epics.md (tactical implementation)</critical>
 <critical>TECHNICAL NOTES: If ANY technical details, preferences, or constraints are mentioned during PRD discussions, append them to {technical_decisions_file}. If file doesn't exist, create it from {technical_decisions_template}</critical>
 
+<critical>DOCUMENT OUTPUT: Concise, clear, actionable requirements. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
+
 <workflow>
 
-<step n="0" goal="Check for workflow status file - REQUIRED">
+<step n="0" goal="Validate workflow and extract project configuration">
 
-<action>Check if bmm-workflow-status.md exists in {output_folder}/</action>
+<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+  <param>mode: data</param>
+  <param>data_request: project_config</param>
+</invoke-workflow>
 
-<check if="not exists">
+<check if="status_exists == false">
   <output>**⚠️ No Workflow Status File Found**
 
-The PRD workflow requires an existing workflow status file to understand your project context.
+The PRD workflow requires a status file to understand your project context.
 
-Please run `workflow-status` first to:
+Please run `workflow-init` first to:
 
-- Map out your complete workflow journey
+- Define your project type and level
-- Determine project type and level
+- Map out your workflow journey
-- Create the status file with your planned workflow
+- Create the status file
 
-**To proceed:**
+Run: `workflow-init`
 
-Run: `bmad analyst workflow-status`
+After setup, return here to create your PRD.
-
-After completing workflow planning, you'll be directed back to this workflow.
 </output>
 <action>Exit workflow - cannot proceed without status file</action>
 </check>
 
-<check if="exists">
+<check if="status_exists == true">
-  <action>Load status file: {status_file}</action>
+  <action>Store {{status_file_path}} for later updates</action>
-  <action>Proceed to Step 1</action>
-</check>
 
-</step>
+  <check if="project_level < 2">
+    <output>**Incorrect Workflow for Level {{project_level}}**
 
-<step n="1" goal="Initialize and load context">
+PRD is for Level 2-4 projects. Level 0-1 should use tech-spec directly.
 
-<action>Extract project context from status file</action>
+**Correct workflow:** `tech-spec` (Architect agent)
-<action>Verify project_level is 2, 3, or 4</action>
-
-<check if="project_level < 2">
-  <error>This workflow is for Level 2-4 only. Level 0-1 should use tech-spec workflow.</error>
-  <output>**Incorrect Workflow for Your Level**
-
-Your status file indicates Level {{project_level}}.
-
-**Correct workflow:** `tech-spec` (run with Architect agent)
-
-Run: `bmad architect tech-spec`
 </output>
-<action>Exit and redirect user to tech-spec workflow</action>
+<action>Exit and redirect to tech-spec</action>
 </check>
 
-<check if="project_type == game">
+  <check if="project_type == game">
-  <error>This workflow is for software projects. Game projects should use GDD workflow.</error>
     <output>**Incorrect Workflow for Game Projects**
 
-**Correct workflow:** `gdd` (run with PM agent)
+Game projects should use GDD workflow instead of PRD.
 
-Run: `bmad pm gdd`
+**Correct workflow:** `gdd` (PM agent)
 </output>
-<action>Exit and redirect user to gdd workflow</action>
+<action>Exit and redirect to gdd</action>
 </check>
+</check>
+</step>
 
+<step n="0.5" goal="Validate workflow sequencing">
+
+<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+  <param>mode: validate</param>
+  <param>calling_workflow: prd</param>
+</invoke-workflow>
+
+<check if="warning != ''">
+  <output>{{warning}}</output>
+  <ask>Continue with PRD anyway? (y/n)</ask>
+  <check if="n">
+    <output>{{suggestion}}</output>
+    <action>Exit workflow</action>
+  </check>
+</check>
+</step>
+
+<step n="1" goal="Initialize PRD context">
+
+<action>Use {{project_level}} from status data</action>
 <action>Check for existing PRD.md in {output_folder}</action>
 
 <check if="PRD.md exists">
@@ -392,39 +405,49 @@ For each epic from the epic list, expand with full story details:
 
 </step>
 
-<step n="10" goal="Update workflow status and complete">
+<step n="10" goal="Update status and complete">
 
-<action>Update {status_file} with completion status</action>
+<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+  <param>mode: update</param>
+  <param>action: complete_workflow</param>
+  <param>workflow_name: prd</param>
+  <param>populate_stories_from: {epics_output_file}</param>
+</invoke-workflow>
 
-<template-output file="bmm-workflow-status.md">prd_completion_update</template-output>
+<check if="success == true">
+  <output>Status updated! Next: {{next_workflow}} ({{next_agent}} agent)</output>
+  <output>Loaded {{total_stories}} stories from epics.</output>
+</check>
 
-**✅ PRD Workflow Complete, {user_name}!**
+<output>**✅ PRD Workflow Complete, {user_name}!**
 
 **Deliverables Created:**
 
-1. ✅ PRD.md - Strategic product requirements document
+1. ✅ bmm-PRD.md - Strategic product requirements document
-2. ✅ epics.md - Tactical implementation roadmap with story breakdown
+2. ✅ bmm-epics.md - Tactical implementation roadmap with story breakdown
 
 **Next Steps:**
 
-<check if="level == 2">
+{{#if project_level == 2}}
-  - Review PRD and epics with stakeholders
-  - **Next:** Run tech-spec workflow for lightweight technical planning
-  - Then proceed to implementation (create-story workflow)
-</check>
 
-<check if="level >= 3">
+- Review PRD and epics with stakeholders
-  - Review PRD and epics with stakeholders
+- **Next:** Run `tech-spec` for lightweight technical planning
-  - **Next:** Run solution-architecture workflow for full technical design
+- Then proceed to implementation
-  - Then proceed to implementation (create-story workflow)
+  {{/if}}
-</check>
 
-<ask>Would you like to:
+{{#if project_level >= 3}}
+
+- Review PRD and epics with stakeholders
+- **Next:** Run `solution-architecture` for full technical design
+- Then proceed to implementation
+  {{/if}}
+
+Would you like to:
 
 1. Review/refine any section
-2. Proceed to next phase (tech-spec for Level 2, solution-architecture for Level 3-4)
+2. Proceed to next phase
 3. Exit and review documents
-   </ask>
+   </output>
 
 </step>
 

src/modules/bmm/workflows/2-plan-workflows/prd/workflow.yaml

@@ -9,6 +9,8 @@ project_name: "{config_source}:project_name"
 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
 
 # Workflow components

src/modules/bmm/workflows/2-plan-workflows/tech-spec/instructions-level0-story.md

@@ -98,82 +98,27 @@
 
 </step>
 
-<step n="4" goal="Update bmm-workflow-status and initialize Phase 4">
+<step n="4" goal="Update status - Level 0 single story">
 
-<action>Open {output_folder}/bmm-workflow-status.md</action>
+<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+  <param>mode: update</param>
+  <param>action: complete_workflow</param>
+  <param>workflow_name: tech-spec</param>
+</invoke-workflow>
 
-<action>Update "Workflow Status Tracker" section:</action>
+<check if="success == true">
+  <output>✅ Tech-spec complete! Next: {{next_workflow}}</output>
+</check>
 
-- Set current_phase = "4-Implementation" (Level 0 skips Phase 3)
+<action>Load {{status_file_path}}</action>
-- Set current_workflow = "tech-spec (Level 0 - story generation complete, ready for implementation)"
+<action>Set STORIES_SEQUENCE: [{slug}]</action>
-- Check "2-Plan" checkbox in Phase Completion Status
+<action>Set TODO_STORY: {slug}</action>
-- Set progress_percentage = 40% (planning complete, skipping solutioning)
+<action>Set TODO_TITLE: {{story_title}}</action>
+<action>Set IN_PROGRESS_STORY: (empty)</action>
+<action>Set STORIES_DONE: []</action>
+<action>Save {{status_file_path}}</action>
 
-<action>Initialize Phase 4 Implementation Progress section:</action>
+<output>Story queue initialized with single story: {slug}</output>
-
-#### BACKLOG (Not Yet Drafted)
-
-**Ordered story sequence - populated at Phase 4 start:**
-
-| Epic                               | Story | ID  | Title | File |
-| ---------------------------------- | ----- | --- | ----- | ---- |
-| (empty - Level 0 has only 1 story) |       |     |       |      |
-
-**Total in backlog:** 0 stories
-
-**NOTE:** Level 0 has single story only. No additional stories in backlog.
-
-#### TODO (Needs Drafting)
-
-Initialize with the ONLY story (already drafted):
-
-- **Story ID:** {slug}
-- **Story Title:** {{story_title}}
-- **Story File:** `story-{slug}.md`
-- **Status:** Draft (needs review before development)
-- **Action:** User reviews drafted story, then runs SM agent `story-ready` workflow to approve
-
-#### IN PROGRESS (Approved for Development)
-
-Leave empty initially:
-
-(Story will be moved here by SM agent `story-ready` workflow after user approves story-{slug}.md)
-
-#### DONE (Completed Stories)
-
-Initialize empty table:
-
-| Story ID   | File | Completed Date | Points |
-| ---------- | ---- | -------------- | ------ |
-| (none yet) |      |                |        |
-
-**Total completed:** 0 stories
-**Total points completed:** 0 points
-
-<action>Add to Artifacts Generated table:</action>
-
-```
-| tech-spec.md | Complete | {output_folder}/tech-spec.md | {{date}} |
-| story-{slug}.md | Draft | {dev_story_location}/story-{slug}.md | {{date}} |
-```
-
-<action>Update "Next Action Required":</action>
-
-```
-**What to do next:** Review drafted story-{slug}.md, then mark it ready for development
-
-**Command to run:** Load SM agent and run 'story-ready' workflow (confirms story-{slug}.md is ready)
-
-**Agent to load:** bmad/bmm/agents/sm.md
-```
-
-<action>Add to Decision Log:</action>
-
-```
-- **{{date}}**: Level 0 tech-spec and story generation completed. Skipping Phase 3 (solutioning) - moving directly to Phase 4 (implementation). Single story (story-{slug}.md) drafted and ready for review.
-```
-
-<action>Save bmm-workflow-status.md</action>
 
 </step>
 

src/modules/bmm/workflows/2-plan-workflows/tech-spec/instructions-level1-stories.md

@@ -194,93 +194,23 @@ Epic: Icon Reliability
 
 </step>
 
-<step n="6" goal="Update bmm-workflow-status and populate backlog for Phase 4">
+<step n="6" goal="Update status and populate story backlog">
 
-<action>Open {output_folder}/bmm-workflow-status.md</action>
+<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+  <param>mode: update</param>
+  <param>action: complete_workflow</param>
+  <param>workflow_name: tech-spec</param>
+  <param>populate_stories_from: {epics_output_file}</param>
+</invoke-workflow>
 
-<action>Update "Workflow Status Tracker" section:</action>
+<check if="success == true">
+  <output>✅ Status updated! Loaded {{total_stories}} stories from epics.</output>
+  <output>Next: {{next_workflow}} ({{next_agent}} agent)</output>
+</check>
 
-- Set current_phase = "4-Implementation" (Level 1 skips Phase 3)
+<check if="success == false">
-- Set current_workflow = "tech-spec (Level 1 - epic and stories generation complete, ready for implementation)"
+  <output>⚠️ Status update failed: {{error}}</output>
-- Check "2-Plan" checkbox in Phase Completion Status
+</check>
-- Set progress_percentage = 40% (planning complete, skipping solutioning)
-
-<action>Populate story backlog in "### Implementation Progress (Phase 4 Only)" section:</action>
-
-#### BACKLOG (Not Yet Drafted)
-
-**Ordered story sequence - populated at Phase 4 start:**
-
-| Epic | Story | ID  | Title | File |
-| ---- | ----- | --- | ----- | ---- |
-
-{{#if story_2}}
-| 1 | 2 | {epic_slug}-2 | {{story_2_title}} | story-{epic_slug}-2.md |
-{{/if}}
-{{#if story_3}}
-| 1 | 3 | {epic_slug}-3 | {{story_3_title}} | story-{epic_slug}-3.md |
-{{/if}}
-
-**Total in backlog:** {{story_count - 1}} stories
-
-**NOTE:** Level 1 uses slug-based IDs like "{epic_slug}-1", "{epic_slug}-2" instead of numeric "1.1", "1.2"
-
-#### TODO (Needs Drafting)
-
-Initialize with FIRST story (already drafted):
-
-- **Story ID:** {epic_slug}-1
-- **Story Title:** {{story_1_title}}
-- **Story File:** `story-{epic_slug}-1.md`
-- **Status:** Draft (needs review before development)
-- **Action:** User reviews drafted story, then runs SM agent `story-ready` workflow to approve
-
-#### IN PROGRESS (Approved for Development)
-
-Leave empty initially:
-
-(Story will be moved here by SM agent `story-ready` workflow after user approves story-{epic_slug}-1.md)
-
-#### DONE (Completed Stories)
-
-Initialize empty table:
-
-| Story ID   | File | Completed Date | Points |
-| ---------- | ---- | -------------- | ------ |
-| (none yet) |      |                |        |
-
-**Total completed:** 0 stories
-**Total points completed:** 0 points
-
-<action>Add to Artifacts Generated table:</action>
-
-```
-| tech-spec.md | Complete | {output_folder}/tech-spec.md | {{date}} |
-| epics.md | Complete | {output_folder}/epics.md | {{date}} |
-| story-{epic_slug}-1.md | Draft | {dev_story_location}/story-{epic_slug}-1.md | {{date}} |
-| story-{epic_slug}-2.md | Draft | {dev_story_location}/story-{epic_slug}-2.md | {{date}} |
-{{#if story_3}}
-| story-{epic_slug}-3.md | Draft | {dev_story_location}/story-{epic_slug}-3.md | {{date}} |
-{{/if}}
-```
-
-<action>Update "Next Action Required":</action>
-
-```
-**What to do next:** Review drafted story-{epic_slug}-1.md, then mark it ready for development
-
-**Command to run:** Load SM agent and run 'story-ready' workflow (confirms story-{epic_slug}-1.md is ready)
-
-**Agent to load:** bmad/bmm/agents/sm.md
-```
-
-<action>Add to Decision Log:</action>
-
-```
-- **{{date}}**: Level 1 tech-spec and epic/stories generation completed. {{story_count}} stories created. Skipping Phase 3 (solutioning) - moving directly to Phase 4 (implementation). Story backlog populated. First story (story-{epic_slug}-1.md) drafted and ready for review.
-```
-
-<action>Save bmm-workflow-status.md</action>
 
 </step>
 

src/modules/bmm/workflows/2-plan-workflows/tech-spec/instructions.md

@@ -4,80 +4,99 @@
 
 <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>Communicate all responses in {communication_language}</critical>
+<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
+<critical>Generate all documents in {document_output_language}</critical>
 <critical>This is the SMALL instruction set for Level 0-1 projects - tech-spec with story generation</critical>
 <critical>Level 0: tech-spec + single user story | Level 1: tech-spec + epic/stories</critical>
 <critical>Project analysis already completed - proceeding directly to technical specification</critical>
 <critical>NO PRD generated - uses tech_spec_template + story templates</critical>
 
-<step n="0" goal="Check for workflow status file - REQUIRED">
+<critical>DOCUMENT OUTPUT: Technical, precise, definitive. Specific versions only. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
 
-<action>Check if bmm-workflow-status.md exists in {output_folder}/</action>
+<step n="0" goal="Validate workflow and extract project configuration">
 
-<check if="not exists">
+<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+  <param>mode: data</param>
+  <param>data_request: project_config</param>
+</invoke-workflow>
+
+<check if="status_exists == false">
   <output>**⚠️ No Workflow Status File Found**
 
-The tech-spec workflow requires an existing workflow status file to understand your project context.
+The tech-spec workflow requires a status file to understand your project context.
 
-Please run `workflow-status` first to:
+Please run `workflow-init` first to:
 
-- Map out your complete workflow journey
+- Define your project type and level
-- Determine project type and level
+- Map out your workflow journey
-- Create the status file with your planned workflow
+- Create the status file
 
-**To proceed:**
+Run: `workflow-init`
 
-Run: `bmad analyst workflow-status`
+After setup, return here to create your tech spec.
-
-After completing workflow planning, you'll be directed back to this workflow.
 </output>
 <action>Exit workflow - cannot proceed without status file</action>
 </check>
 
-<check if="exists">
+<check if="status_exists == true">
-  <action>Load status file and proceed to Step 1</action>
+  <action>Store {{status_file_path}} for later updates</action>
+
+  <check if="project_level >= 2">
+    <output>**Incorrect Workflow for Level {{project_level}}**
+
+Tech-spec is for Level 0-1 projects. Level 2-4 should use PRD workflow.
+
+**Correct workflow:** `prd` (PM agent)
+</output>
+<action>Exit and redirect to prd</action>
 </check>
 
+  <check if="project_type == game">
+    <output>**Incorrect Workflow for Game Projects**
+
+Game projects should use GDD workflow instead of tech-spec.
+
+**Correct workflow:** `gdd` (PM agent)
+</output>
+<action>Exit and redirect to gdd</action>
+</check>
+</check>
+</step>
+
+<step n="0.5" goal="Validate workflow sequencing">
+
+<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+  <param>mode: validate</param>
+  <param>calling_workflow: tech-spec</param>
+</invoke-workflow>
+
+<check if="warning != ''">
+  <output>{{warning}}</output>
+  <ask>Continue with tech-spec anyway? (y/n)</ask>
+  <check if="n">
+    <output>{{suggestion}}</output>
+    <action>Exit workflow</action>
+  </check>
+</check>
 </step>
 
 <step n="1" goal="Confirm project scope and update tracking">
 
-<action>Load bmm-workflow-status.md from {output_folder}/bmm-workflow-status.md</action>
+<action>Use {{project_level}} from status data</action>
-<action>Verify project_level is 0 or 1</action>
 
-<check if="project_level >= 2">
+<action>Update Workflow Status:</action>
-  <error>This workflow is for Level 0-1 only. Level 2-4 should use PRD workflow.</error>
+<template-output file="{{status_file_path}}">current_workflow</template-output>
-  <output>**Incorrect Workflow for Your Level**
-
-Your status file indicates Level {{project_level}}.
-
-**Correct workflow:** `prd` (run with PM agent)
-
-Run: `bmad pm prd`
-</output>
-<action>Exit and redirect user to prd workflow</action>
-</check>
-
-<check if="project_type == game">
-  <error>This workflow is for software projects. Game projects should use GDD workflow.</error>
-  <output>**Incorrect Workflow for Game Projects**
-
-**Correct workflow:** `gdd` (run with PM agent)
-
-Run: `bmad pm gdd`
-</output>
-<action>Exit and redirect user to gdd workflow</action>
-</check>
-
-<action>Update Workflow Status Tracker:</action>
 <check if="project_level == 0">
-<action>Set current_workflow = "tech-spec (Level 0 - generating tech spec)"</action>
+<action>Set to: "tech-spec (Level 0 - generating tech spec)"</action>
 </check>
 <check if="project_level == 1">
-<action>Set current_workflow = "tech-spec (Level 1 - generating tech spec)"</action>
+<action>Set to: "tech-spec (Level 1 - generating tech spec)"</action>
 </check>
-<action>Set progress_percentage = 20%</action>
+
-<action>Save bmm-workflow-status.md</action>
+<template-output file="{{status_file_path}}">progress_percentage</template-output>
+<action>Set to: 20%</action>
+
+<action>Save {{status_file_path}}</action>
 
 <check if="project_level == 0">
   <action>Confirm Level 0 - Single atomic change</action>
@@ -96,9 +115,10 @@ Run: `bmad pm gdd`
 <critical>Generate tech-spec.md - this is the TECHNICAL SOURCE OF TRUTH</critical>
 <critical>ALL TECHNICAL DECISIONS MUST BE DEFINITIVE - NO AMBIGUITY ALLOWED</critical>
 
-<action>Update progress in bmm-workflow-status.md:</action>
+<action>Update progress:</action>
-<action>Set progress_percentage = 40%</action>
+<template-output file="{{status_file_path}}">progress_percentage</template-output>
-<action>Save bmm-workflow-status.md</action>
+<action>Set to: 40%</action>
+<action>Save {{status_file_path}}</action>
 
 <action>Initialize and write out tech-spec.md using tech_spec_template</action>
 
@@ -164,7 +184,7 @@ Run cohesion validation? (y/n)</ask>
 
 <step n="4" goal="Generate user stories based on project level">
 
-<action>Load bmm-workflow-status.md to determine project_level</action>
+<action>Use {{project_level}} from status data</action>
 
 <check if="project_level == 0">
   <action>Invoke instructions-level0-story.md to generate single user story</action>

src/modules/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml

@@ -9,6 +9,8 @@ project_name: "{config_source}:project_name"
 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
 
 # Workflow components

src/modules/bmm/workflows/2-plan-workflows/ux/instructions-ux.md

@@ -4,11 +4,31 @@
 
 <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>Communicate all responses in {communication_language}</critical>
+<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
+<critical>Generate all documents in {document_output_language}</critical>
 <critical>This workflow creates comprehensive UX/UI specifications - can run standalone or as part of plan-project</critical>
 <critical>Uses ux-spec-template.md for structured output generation</critical>
 <critical>Can optionally generate AI Frontend Prompts for tools like Vercel v0, Lovable.ai</critical>
 
+<critical>DOCUMENT OUTPUT: Professional, precise, actionable UX specs. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
+
+<step n="0" goal="Check for workflow status">
+
+<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+  <param>mode: init-check</param>
+</invoke-workflow>
+
+<check if="status_exists == true">
+  <action>Store {{status_file_path}} for later updates</action>
+  <action>Set tracking_mode = true</action>
+</check>
+
+<check if="status_exists == false">
+  <action>Set tracking_mode = false</action>
+  <output>Note: Running without workflow tracking. Run `workflow-init` to enable progress tracking.</output>
+</check>
+</step>
+
 <step n="1" goal="Load context and analyze project requirements">
 
 <action>Determine workflow mode (standalone or integrated)</action>
@@ -367,4 +387,19 @@ Select option (1-3):</ask>
 
 </step>
 
+<step n="12" goal="Update status if tracking enabled">
+
+<check if="tracking_mode == true">
+  <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+    <param>mode: update</param>
+    <param>action: complete_workflow</param>
+    <param>workflow_name: ux</param>
+  </invoke-workflow>
+
+  <check if="success == true">
+    <output>✅ Status updated! Next: {{next_workflow}}</output>
+  </check>
+</check>
+</step>
+
 </workflow>

src/modules/bmm/workflows/2-plan-workflows/ux/workflow.yaml

@@ -8,6 +8,8 @@ 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
 
 # Workflow components

src/modules/bmm/workflows/3-solutioning/README.md

@@ -11,12 +11,12 @@ This workflow generates comprehensive, scale-adaptive solution architecture docu
 **Unique Features:**
 
 - ✅ **Scale-adaptive**: Level 0 = skip, Levels 1-4 = progressive depth
-- ✅ **Pattern-aware**: 171 technology combinations across 12 project types
+- ✅ **Intent-based**: LLM intelligence over prescriptive lists
-- ✅ **Template-driven**: 11 complete architecture document templates
+- ✅ **Template-driven**: 11 adaptive architecture document templates
-- ✅ **Engine-specific guidance**: Unity, Godot, Phaser, and more
+- ✅ **Game-aware**: Adapts heavily based on game type (RPG, Puzzle, Shooter, etc.)
 - ✅ **GDD/PRD aware**: Uses Game Design Doc for games, PRD for everything else
 - ✅ **ADR tracking**: Separate Architecture Decision Records document
-- ✅ **Specialist integration**: Pattern-specific specialist recommendations
+- ✅ **Simplified structure**: ~11 core project types with consistent naming
 
 ---
 
@@ -71,38 +71,37 @@ workflow solution-architecture
 
 ## Project Types and Templates
 
-### 12 Project Types Supported
+### Simplified Project Type System
 
-| Type          | Examples                     | Template                          | Guide Examples       |
+The workflow uses ~11 core project types that cover 99% of software projects:
-| ------------- | ---------------------------- | --------------------------------- | -------------------- |
-| **web**       | Next.js, Rails, Django       | web-fullstack-architecture.md     | (TBD)                |
-| **mobile**    | React Native, Flutter, Swift | mobile-app-architecture.md        | (TBD)                |
-| **game**      | Unity, Godot, Phaser         | game-engine-architecture.md       | Unity, Godot, Phaser |
-| **embedded**  | ESP32, STM32, Raspberry Pi   | embedded-firmware-architecture.md | (TBD)                |
-| **backend**   | Express, FastAPI, gRPC       | backend-service-architecture.md   | (TBD)                |
-| **data**      | Spark, Airflow, MLflow       | data-pipeline-architecture.md     | (TBD)                |
-| **cli**       | Commander, Click, Cobra      | cli-tool-architecture.md          | (TBD)                |
-| **desktop**   | Electron, Tauri, Qt          | desktop-app-architecture.md       | (TBD)                |
-| **library**   | npm, PyPI, cargo             | library-package-architecture.md   | (TBD)                |
-| **infra**     | Terraform, K8s Operator      | infrastructure-architecture.md    | (TBD)                |
-| **extension** | Chrome, VS Code plugins      | desktop-app-architecture.md       | (TBD)                |
 
-### 171 Technology Combinations
+| Type               | Name                     | Template                   | Instructions                   |
+| ------------------ | ------------------------ | -------------------------- | ------------------------------ |
+| **web**            | Web Application          | web-template.md            | web-instructions.md            |
+| **mobile**         | Mobile Application       | mobile-template.md         | mobile-instructions.md         |
+| **game**           | Game Development         | game-template.md           | game-instructions.md           |
+| **backend**        | Backend Service          | backend-template.md        | backend-instructions.md        |
+| **data**           | Data Pipeline            | data-template.md           | data-instructions.md           |
+| **cli**            | CLI Tool                 | cli-template.md            | cli-instructions.md            |
+| **library**        | Library/SDK              | library-template.md        | library-instructions.md        |
+| **desktop**        | Desktop Application      | desktop-template.md        | desktop-instructions.md        |
+| **embedded**       | Embedded System          | embedded-template.md       | embedded-instructions.md       |
+| **extension**      | Browser/Editor Extension | extension-template.md      | extension-instructions.md      |
+| **infrastructure** | Infrastructure           | infrastructure-template.md | infrastructure-instructions.md |
 
-The workflow maintains a registry (`templates/registry.csv`) with 171 pre-defined technology stack combinations:
+### Intent-Based Architecture
 
-**Examples:**
+Instead of maintaining 171 prescriptive technology combinations, the workflow now:
 
-- `web-nextjs-ssr-monorepo` → Next.js SSR, TypeScript, monorepo
+- **Leverages LLM intelligence** to understand project requirements
-- `game-unity-3d` → Unity 3D, C#, monorepo
+- **Adapts templates dynamically** based on actual needs
-- `mobile-react-native` → React Native, TypeScript, cross-platform
+- **Uses intent-based instructions** rather than prescriptive checklists
-- `backend-fastapi-rest` → FastAPI, Python, REST API
+- **Allows for emerging technologies** without constant updates
-- `data-ml-training` → PyTorch/TensorFlow, Python, ML pipeline
 
-Each row maps to:
+Each project type has:
 
-- **template_path**: Architecture document structure (11 templates)
+- **Instruction file**: Intent-based guidance for architecture decisions
-- **guide_path**: Engine/framework-specific guidance (optional)
+- **Template file**: Adaptive starting point for the architecture document
 
 ---
 
@@ -155,63 +154,56 @@ Analyze PRD epics:
 - Map domain capabilities
 - Determine service boundaries (if microservices)
 
-### Step 5: Project-Type Questions
+### Step 5: Intent-Based Technical Decisions
 
-Load: `project-types/{project_type}-questions.md`
+Load: `project-types/{project_type}-instructions.md`
 
-- Ask project-type-specific questions (not yet engine-specific)
+- Use intent-based guidance, not prescriptive lists
+- Allow LLM intelligence to identify relevant decisions
+- Consider emerging technologies naturally
 
-### Step 6: Load Template + Guide
+### Step 6: Adaptive Template Selection
 
-**6.1: Search Registry**
+**6.1: Simple Template Selection**
 
 ```
-Read: templates/registry.csv
+Based on project_type from analysis:
-Match WHERE:
+  web → web-template.md
-  - project_types = {determined_type}
+  mobile → mobile-template.md
-  - languages = {preferred_languages}
+  game → game-template.md (adapts heavily by game type)
-  - architecture_style = {determined_style}
+  backend → backend-template.md
-  - tags overlap with {requirements}
+  ... (consistent naming pattern)
-
-Get: template_path, guide_path
 ```
 
 **6.2: Load Template**
 
 ```
-Read: templates/{template_path}
+Read: project-types/{type}-template.md
-Example: templates/game-engine-architecture.md
+Example: project-types/game-template.md
 
-This is a COMPLETE document structure with:
+Templates are adaptive starting points:
 - Standard sections (exec summary, tech stack, data arch, etc.)
-- Pattern-specific sections (Gameplay Systems for games, SSR Strategy for web)
+- Pattern-specific sections conditionally included
-- All {{placeholders}} to fill
+- All {{placeholders}} to fill based on requirements
 ```
 
-**6.3: Load Guide (if available)**
+**6.3: Dynamic Adaptation**
 
-```
+Templates adapt based on:
-IF guide_path not empty:
-  Read: templates/{guide_path}
-  Example: templates/game-engine-unity-guide.md
 
-Guide contains:
+- Actual project requirements from PRD/GDD
-- Engine/framework-specific questions
+- User skill level (beginner/intermediate/expert)
-- Architecture patterns for this tech
+- Specific technology choices made
-- Common pitfalls
+- Game type for game projects (RPG, Puzzle, Shooter, etc.)
-- Specialist recommendations
-- ADR templates
-```
 
-**Example Flow for Unity Game:**
+**Example Flow for Unity RPG:**
 
-1. GDD says "Unity 2022 LTS"
+1. GDD says "Unity 2022 LTS" and "RPG"
-2. Registry match: `game-unity-3d` → `game-engine-architecture.md` + `game-engine-unity-guide.md`
+2. Load game-template.md and game-instructions.md
-3. Load complete game architecture template
+3. Template adapts to include RPG-specific sections (inventory, quests, dialogue)
-4. Load Unity-specific guide
+4. Instructions guide Unity-specific decisions (MonoBehaviour vs ECS, etc.)
-5. Ask Unity-specific questions (MonoBehaviour vs ECS, ScriptableObjects, etc.)
+5. LLM intelligence fills gaps not in any list
-6. Fill template placeholders
+6. Generate optimized `solution-architecture.md` + `architecture-decisions.md`
-7. Generate `solution-architecture.md` + `architecture-decisions.md`
 
 ### Step 7: Cohesion Check
 
@@ -234,28 +226,30 @@ Validate architecture quality:
 ├── instructions.md                  # Main workflow logic
 ├── checklist.md                     # Validation checklist
 ├── ADR-template.md                  # ADR document template
-├── templates/                       # Architecture templates and guides
+└── project-types/                   # All project type files in one folder
-│   ├── registry.csv                 # 171 tech combinations → templates
+    ├── project-types.csv            # Simple 2-column mapping (type, name)
-│   ├── game-engine-architecture.md  # Complete game architecture doc
+    ├── web-instructions.md          # Intent-based guidance for web projects
-│   ├── game-engine-unity-guide.md   # Unity-specific guidance
+    ├── web-template.md              # Adaptive web architecture template
-│   ├── game-engine-godot-guide.md   # Godot-specific guidance
+    ├── mobile-instructions.md       # Intent-based guidance for mobile
-│   ├── game-engine-web-guide.md     # Phaser/PixiJS/Three.js guidance
+    ├── mobile-template.md           # Adaptive mobile architecture template
-│   ├── web-fullstack-architecture.md
+    ├── game-instructions.md         # Intent-based guidance (adapts by game type)
-│   ├── web-api-architecture.md
+    ├── game-template.md             # Highly adaptive game architecture template
-│   ├── mobile-app-architecture.md
+    ├── backend-instructions.md      # Intent-based guidance for backend services
-│   ├── embedded-firmware-architecture.md
+    ├── backend-template.md          # Adaptive backend architecture template
-│   ├── backend-service-architecture.md
+    ├── data-instructions.md         # Intent-based guidance for data pipelines
-│   ├── data-pipeline-architecture.md
+    ├── data-template.md             # Adaptive data pipeline template
-│   ├── cli-tool-architecture.md
+    ├── cli-instructions.md          # Intent-based guidance for CLI tools
-│   ├── desktop-app-architecture.md
+    ├── cli-template.md              # Adaptive CLI architecture template
-│   ├── library-package-architecture.md
+    ├── library-instructions.md      # Intent-based guidance for libraries/SDKs
-│   └── infrastructure-architecture.md
+    ├── library-template.md          # Adaptive library architecture template
-└── project-types/                   # Project type detection and questions
+    ├── desktop-instructions.md      # Intent-based guidance for desktop apps
-    ├── project-types.csv            # 12 project types + detection keywords
+    ├── desktop-template.md          # Adaptive desktop architecture template
-    ├── game-questions.md
+    ├── embedded-instructions.md     # Intent-based guidance for embedded systems
-    ├── web-questions.md
+    ├── embedded-template.md         # Adaptive embedded architecture template
-    ├── mobile-questions.md
+    ├── extension-instructions.md    # Intent-based guidance for extensions
-    └── ... (12 question files)
+    ├── extension-template.md        # Adaptive extension architecture template
+    ├── infrastructure-instructions.md  # Intent-based guidance for infra
+    └── infrastructure-template.md   # Adaptive infrastructure template
 ```
 
 ---
@@ -313,60 +307,6 @@ Each template in `templates/` is a **complete** architecture document structure:
 
 ---
 
-## Guide System
-
-### Engine/Framework-Specific Guides
-
-Guides are **workflow instruction documents** that:
-
-- Ask engine-specific questions
-- Provide architecture pattern recommendations
-- Suggest what sections to emphasize
-- Define ADRs to create
-
-**Guides are NOT:**
-
-- ❌ Reference documentation (use official docs)
-- ❌ Tutorials (how to code)
-- ❌ API references
-
-**Guides ARE:**
-
-- ✅ Question flows for architecture decisions
-- ✅ Pattern recommendations specific to the tech
-- ✅ Common pitfalls to avoid
-- ✅ Specialist recommendations
-
-**Example: game-engine-unity-guide.md**
-
-```markdown
-## Unity Architecture Questions
-
-- MonoBehaviour or ECS?
-- ScriptableObjects for game data?
-- Addressables or Resources?
-
-## Unity Patterns
-
-- Singleton GameManager (when to use)
-- Event-driven communication
-- Object pooling strategy
-
-## Unity-Specific Sections to Include
-
-- Unity Project Configuration
-- Scene Architecture
-- Component Organization
-- Package Dependencies
-
-## Common Pitfalls
-
-- Caching GetComponent calls
-- Avoiding empty Update methods
-```
-
----
-
 ## ADR Tracking
 
 Architecture Decision Records are maintained separately in `architecture-decisions.md`.
@@ -531,25 +471,20 @@ Specialists are documented with:
 
 ## Extending the System
 
-### Adding a New Template
-
-1. Create `templates/new-pattern-architecture.md`
-2. Include all standard sections + pattern-specific sections
-3. Add rows to `templates/registry.csv` pointing to new template
-
-### Adding a New Guide
-
-1. Create `templates/new-tech-guide.md`
-2. Include: questions, patterns, pitfalls, specialist recommendations
-3. Update `templates/registry.csv` with `guide_path` column
-
 ### Adding a New Project Type
 
-1. Add row to `project-types/project-types.csv`
+1. Add row to `project-types/project-types.csv` (just type and name)
-2. Create `project-types/new-type-questions.md`
+2. Create `project-types/{type}-instructions.md` with intent-based guidance
-3. Ensure templates exist for this type
+3. Create `project-types/{type}-template.md` with adaptive template
 4. Update instructions.md if special handling needed (like GDD for games)
 
+### Key Principles
+
+- **Intent over prescription**: Guide decisions, don't list every option
+- **Leverage LLM intelligence**: Trust the model to know technologies
+- **Adaptive templates**: Templates should adapt to project needs
+- **Consistent naming**: Always use {type}-instructions.md and {type}-template.md
+
 ---
 
 ## Questions?
@@ -557,8 +492,8 @@ Specialists are documented with:
 - **Validation:** See `checklist.md`
 - **Workflow Logic:** See `instructions.md`
 - **Configuration:** See `workflow.yaml`
-- **Registry Format:** See `templates/registry.csv`
+- **Project Types:** See `project-types/project-types.csv`
-- **Example Guide:** See `templates/game-engine-unity-guide.md`
+- **Example Template:** See `project-types/game-template.md`
 
 ---
 

src/modules/bmm/workflows/3-solutioning/implementation-ready-check/README.md

@@ -0,0 +1,170 @@
+# Implementation Ready Check Workflow
+
+## Overview
+
+The Implementation Ready Check workflow provides a systematic validation of all planning and solutioning artifacts before transitioning from Phase 3 (Solutioning) to Phase 4 (Implementation) in the BMad Method. This workflow ensures that PRDs, architecture documents, and story breakdowns are properly aligned with no critical gaps or contradictions.
+
+## Purpose
+
+This workflow is designed to:
+
+- **Validate Completeness**: Ensure all required planning documents exist and are complete
+- **Verify Alignment**: Check that PRD, architecture, and stories are cohesive and aligned
+- **Identify Gaps**: Detect missing stories, unaddressed requirements, or sequencing issues
+- **Assess Risks**: Find contradictions, conflicts, or potential implementation blockers
+- **Provide Confidence**: Give teams confidence that planning is solid before starting development
+
+## When to Use
+
+This workflow should be invoked:
+
+- At the end of Phase 3 (Solutioning) for Level 2-4 projects
+- Before beginning Phase 4 (Implementation)
+- After significant planning updates or architectural changes
+- When validating readiness for Level 0-1 projects (simplified validation)
+
+## Project Level Adaptations
+
+The workflow adapts its validation based on project level:
+
+### Level 0-1 Projects
+
+- Validates tech spec and simple stories only
+- Checks internal consistency and basic coverage
+- Lighter validation appropriate for simple projects
+
+### Level 2 Projects
+
+- Validates PRD, tech spec (with embedded architecture), and stories
+- Ensures PRD requirements are fully covered
+- Verifies technical approach aligns with business goals
+
+### Level 3-4 Projects
+
+- Full validation of PRD, solution architecture, and comprehensive stories
+- Deep cross-reference checking across all artifacts
+- Validates architectural decisions don't introduce scope creep
+- Checks UX artifacts if applicable
+
+## How to Invoke
+
+### Via Scrum Master Agent
+
+```
+*assess-project-ready
+```
+
+### Direct Workflow Invocation
+
+```
+workflow implementation-ready-check
+```
+
+## Expected Inputs
+
+The workflow will automatically search your project's output folder for:
+
+- Product Requirements Documents (PRD)
+- Solution Architecture documents
+- Technical Specifications
+- Epic and Story breakdowns
+- UX artifacts (if applicable)
+
+No manual input file specification needed - the workflow discovers documents automatically.
+
+## Generated Output
+
+The workflow produces a comprehensive **Implementation Readiness Report** containing:
+
+1. **Executive Summary** - Overall readiness status
+2. **Document Inventory** - What was found and reviewed
+3. **Alignment Validation** - Cross-reference analysis results
+4. **Gap Analysis** - Missing items and risks identified
+5. **Findings by Severity** - Critical, High, Medium, Low issues
+6. **Recommendations** - Specific actions to address issues
+7. **Readiness Decision** - Ready, Ready with Conditions, or Not Ready
+
+Output Location: `{output_folder}/implementation-readiness-report-{date}.md`
+
+## Workflow Steps
+
+1. **Initialize** - Get current workflow status and project level
+2. **Document Discovery** - Find all planning artifacts
+3. **Deep Analysis** - Extract requirements, decisions, and stories
+4. **Cross-Reference Validation** - Check alignment between all documents
+5. **Gap and Risk Analysis** - Identify issues and conflicts
+6. **UX Validation** (optional) - Verify UX concerns are addressed
+7. **Generate Report** - Compile comprehensive readiness assessment
+8. **Status Update** (optional) - Offer to advance workflow to next phase
+
+## Validation Criteria
+
+The workflow uses systematic validation rules adapted to each project level:
+
+- **Document completeness and quality**
+- **Requirement to story traceability**
+- **Architecture to implementation alignment**
+- **Story sequencing and dependencies**
+- **Greenfield project setup coverage**
+- **Risk identification and mitigation**
+
+## Special Features
+
+### Intelligent Adaptation
+
+- Automatically adjusts validation based on project level
+- Recognizes when UX workflow is active
+- Handles greenfield vs. brownfield projects differently
+
+### Comprehensive Coverage
+
+- Validates not just presence but quality and alignment
+- Checks for both gaps and gold-plating
+- Ensures logical story sequencing
+
+### Actionable Output
+
+- Provides specific, actionable recommendations
+- Categorizes issues by severity
+- Includes positive findings and commendations
+
+## Integration with BMad Method
+
+This workflow integrates seamlessly with the BMad Method workflow system:
+
+- Uses workflow-status to understand project context
+- Can update workflow status to advance to next phase
+- Follows standard BMad document naming conventions
+- Searches standard output folders automatically
+
+## Troubleshooting
+
+### Documents Not Found
+
+- Ensure documents are in the configured output folder
+- Check that document names follow BMad conventions
+- Verify workflow-status is properly configured
+
+### Validation Too Strict
+
+- The workflow adapts to project level automatically
+- Level 0-1 projects get lighter validation
+- Consider if your project level is set correctly
+
+### Report Too Long
+
+- Focus on Critical and High priority issues first
+- Use the executive summary for quick decisions
+- Review detailed findings only for areas of concern
+
+## Support
+
+For issues or questions about this workflow:
+
+- Consult the BMad Method documentation
+- Check the SM agent for workflow guidance
+- Review validation-criteria.yaml for detailed rules
+
+---
+
+_This workflow is part of the BMad Method v6-alpha suite of planning and solutioning tools_

src/modules/bmm/workflows/3-solutioning/implementation-ready-check/checklist.md

@@ -0,0 +1,171 @@
+# Implementation Readiness Validation Checklist
+
+## Document Completeness
+
+### Core Planning Documents
+
+- [ ] PRD exists and is complete (Level 2-4 projects)
+- [ ] PRD contains measurable success criteria
+- [ ] PRD defines clear scope boundaries and exclusions
+- [ ] Solution Architecture document exists (Level 3-4 projects)
+- [ ] Technical Specification exists with implementation details
+- [ ] Epic and story breakdown document exists
+- [ ] All documents are dated and versioned
+
+### Document Quality
+
+- [ ] No placeholder sections remain in any document
+- [ ] All documents use consistent terminology
+- [ ] Technical decisions include rationale and trade-offs
+- [ ] Assumptions and risks are explicitly documented
+- [ ] Dependencies are clearly identified and documented
+
+## Alignment Verification
+
+### PRD to Architecture Alignment (Level 3-4)
+
+- [ ] Every functional requirement in PRD has architectural support documented
+- [ ] All non-functional requirements from PRD are addressed in architecture
+- [ ] Architecture doesn't introduce features beyond PRD scope
+- [ ] Performance requirements from PRD match architecture capabilities
+- [ ] Security requirements from PRD are fully addressed in architecture
+
+### PRD to Stories Coverage (Level 2-4)
+
+- [ ] Every PRD requirement maps to at least one story
+- [ ] All user journeys in PRD have complete story coverage
+- [ ] Story acceptance criteria align with PRD success criteria
+- [ ] Priority levels in stories match PRD feature priorities
+- [ ] No stories exist without PRD requirement traceability
+
+### Architecture to Stories Implementation
+
+- [ ] All architectural components have implementation stories
+- [ ] Infrastructure setup stories exist for each architectural layer
+- [ ] Integration points defined in architecture have corresponding stories
+- [ ] Data migration/setup stories exist if required by architecture
+- [ ] Security implementation stories cover all architecture security decisions
+
+## Story and Sequencing Quality
+
+### Story Completeness
+
+- [ ] All stories have clear acceptance criteria
+- [ ] Technical tasks are defined within relevant stories
+- [ ] Stories include error handling and edge cases
+- [ ] Each story has clear definition of done
+- [ ] Stories are appropriately sized (no epic-level stories remaining)
+
+### Sequencing and Dependencies
+
+- [ ] Stories are sequenced in logical implementation order
+- [ ] Dependencies between stories are explicitly documented
+- [ ] No circular dependencies exist
+- [ ] Prerequisite technical tasks precede dependent stories
+- [ ] Foundation/infrastructure stories come before feature stories
+
+### Greenfield Project Specifics
+
+- [ ] Initial project setup and configuration stories exist
+- [ ] Development environment setup is documented
+- [ ] CI/CD pipeline stories are included early in sequence
+- [ ] Database/storage initialization stories are properly placed
+- [ ] Authentication/authorization stories precede protected features
+
+## Risk and Gap Assessment
+
+### Critical Gaps
+
+- [ ] No core PRD requirements lack story coverage
+- [ ] No architectural decisions lack implementation stories
+- [ ] All integration points have implementation plans
+- [ ] Error handling strategy is defined and implemented
+- [ ] Security concerns are all addressed
+
+### Technical Risks
+
+- [ ] No conflicting technical approaches between stories
+- [ ] Technology choices are consistent across all documents
+- [ ] Performance requirements are achievable with chosen architecture
+- [ ] Scalability concerns are addressed if applicable
+- [ ] Third-party dependencies are identified with fallback plans
+
+## UX and Special Concerns (if applicable)
+
+### UX Coverage
+
+- [ ] UX requirements are documented in PRD
+- [ ] UX implementation tasks exist in relevant stories
+- [ ] Accessibility requirements have story coverage
+- [ ] Responsive design requirements are addressed
+- [ ] User flow continuity is maintained across stories
+
+### Special Considerations
+
+- [ ] Compliance requirements are fully addressed
+- [ ] Internationalization needs are covered if required
+- [ ] Performance benchmarks are defined and measurable
+- [ ] Monitoring and observability stories exist
+- [ ] Documentation stories are included where needed
+
+## Overall Readiness
+
+### Ready to Proceed Criteria
+
+- [ ] All critical issues have been resolved
+- [ ] High priority concerns have mitigation plans
+- [ ] Story sequencing supports iterative delivery
+- [ ] Team has necessary skills for implementation
+- [ ] No blocking dependencies remain unresolved
+
+### Quality Indicators
+
+- [ ] Documents demonstrate thorough analysis
+- [ ] Clear traceability exists across all artifacts
+- [ ] Consistent level of detail throughout documents
+- [ ] Risks are identified with mitigation strategies
+- [ ] Success criteria are measurable and achievable
+
+## Assessment Completion
+
+### Report Quality
+
+- [ ] All findings are supported by specific examples
+- [ ] Recommendations are actionable and specific
+- [ ] Severity levels are appropriately assigned
+- [ ] Positive findings are highlighted
+- [ ] Next steps are clearly defined
+
+### Process Validation
+
+- [ ] All expected documents were reviewed
+- [ ] Cross-references were systematically checked
+- [ ] Project level considerations were applied correctly
+- [ ] Workflow status was checked and considered
+- [ ] Output folder was thoroughly searched for artifacts
+
+---
+
+## Issue Log
+
+### Critical Issues Found
+
+- [ ] ***
+- [ ] ***
+- [ ] ***
+
+### High Priority Issues Found
+
+- [ ] ***
+- [ ] ***
+- [ ] ***
+
+### Medium Priority Issues Found
+
+- [ ] ***
+- [ ] ***
+- [ ] ***
+
+---
+
+_Use this checklist to ensure comprehensive validation of implementation readiness_

src/modules/bmm/workflows/3-solutioning/implementation-ready-check/instructions.md

@@ -0,0 +1,262 @@
+# Implementation Ready Check - Workflow Instructions
+
+<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
+<critical>You MUST have already loaded and processed: {project-root}/bmad/bmm/workflows/3-solutioning/implementation-ready-check/workflow.yaml</critical>
+<critical>Communicate all findings and analysis in {communication_language} throughout the assessment</critical>
+
+<workflow>
+
+<step n="0" goal="Initialize and understand project context">
+<invoke-workflow path="{workflow_status_workflow}">
+  <param>mode: data</param>
+  <param>data_request: project_config</param>
+</invoke-workflow>
+
+<check if="status_exists == false">
+  <output>**⚠️ No Workflow Status File Found**
+
+The Implementation Ready Check requires a status file to understand your project context.
+
+Please run `workflow-init` first to establish your project configuration.
+
+After setup, return here to validate implementation readiness.
+</output>
+<action>Exit workflow - cannot proceed without status file</action>
+</check>
+
+<check if="status_exists == true">
+  <action>Store {{status_file_path}} for later updates</action>
+  <action>Store {{project_level}}, {{active_path}}, and {{workflow_phase}} for validation context</action>
+
+<action>Based on the project_level, understand what artifacts should exist:
+
+- Level 0-1: Tech spec and simple stories only (no PRD, minimal solutioning)
+- Level 2: PRD, tech spec, epics/stories (no separate architecture doc)
+- Level 3-4: Full suite - PRD, solution architecture, epics/stories, possible UX artifacts
+  </action>
+
+<critical>The validation approach must adapt to the project level - don't look for documents that shouldn't exist at lower levels</critical>
+</check>
+
+<template-output>project_context</template-output>
+</step>
+
+<step n="1" goal="Discover and inventory project artifacts">
+<action>Search the {output_folder} for relevant planning and solutioning documents based on project level identified in Step 0</action>
+
+<action>For Level 0-1 projects, locate:
+
+- Technical specification document(s)
+- Story/task lists or simple epic breakdowns
+- Any API or interface definitions
+  </action>
+
+<action>For Level 2-4 projects, locate:
+
+- Product Requirements Document (PRD)
+- Solution Architecture document (Level 3-4 only)
+- Technical Specification (Level 2 includes architecture within)
+- Epic and story breakdowns
+- UX artifacts if the active path includes UX workflow
+- Any supplementary planning documents
+  </action>
+
+<action>Create an inventory of found documents with:
+
+- Document type and purpose
+- File path and last modified date
+- Brief description of what each contains
+- Any missing expected documents flagged as potential issues
+  </action>
+
+<template-output>document_inventory</template-output>
+</step>
+
+<step n="2" goal="Deep analysis of core planning documents">
+<action>Load and thoroughly analyze each discovered document to extract:
+- Core requirements and success criteria
+- Architectural decisions and constraints
+- Technical implementation approaches
+- User stories and acceptance criteria
+- Dependencies and sequencing requirements
+- Any assumptions or risks documented
+</action>
+
+<action>For PRD analysis (Level 2-4), focus on:
+
+- User requirements and use cases
+- Functional and non-functional requirements
+- Success metrics and acceptance criteria
+- Scope boundaries and explicitly excluded items
+- Priority levels for different features
+  </action>
+
+<action>For Architecture/Tech Spec analysis, focus on:
+
+- System design decisions and rationale
+- Technology stack and framework choices
+- Integration points and APIs
+- Data models and storage decisions
+- Security and performance considerations
+- Any architectural constraints that might affect story implementation
+  </action>
+
+<action>For Epic/Story analysis, focus on:
+
+- Coverage of PRD requirements
+- Story sequencing and dependencies
+- Acceptance criteria completeness
+- Technical tasks within stories
+- Estimated complexity and effort indicators
+  </action>
+
+<template-output>document_analysis</template-output>
+</step>
+
+<step n="3" goal="Cross-reference validation and alignment check">
+<action>Systematically validate alignment between all artifacts, adapting validation based on project level</action>
+
+<action>PRD ↔ Architecture Alignment (Level 3-4):
+
+- Verify every PRD requirement has corresponding architectural support
+- Check that architecture decisions don't contradict PRD constraints
+- Identify any architecture additions beyond PRD scope (potential gold-plating)
+- Ensure non-functional requirements from PRD are addressed in architecture
+  </action>
+
+<action>PRD ↔ Stories Coverage (Level 2-4):
+
+- Map each PRD requirement to implementing stories
+- Identify any PRD requirements without story coverage
+- Find stories that don't trace back to PRD requirements
+- Validate that story acceptance criteria align with PRD success criteria
+  </action>
+
+<action>Architecture ↔ Stories Implementation Check:
+
+- Verify architectural decisions are reflected in relevant stories
+- Check that story technical tasks align with architectural approach
+- Identify any stories that might violate architectural constraints
+- Ensure infrastructure and setup stories exist for architectural components
+  </action>
+
+<action>For Level 0-1 projects (Tech Spec only):
+
+- Validate internal consistency within tech spec
+- Check that all specified features have corresponding stories
+- Verify story sequencing matches technical dependencies
+  </action>
+
+<template-output>alignment_validation</template-output>
+</step>
+
+<step n="4" goal="Gap and risk analysis">
+<action>Identify and categorize all gaps, risks, and potential issues discovered during validation</action>
+
+<action>Check for Critical Gaps:
+
+- Missing stories for core requirements
+- Unaddressed architectural concerns
+- Absent infrastructure or setup stories for greenfield projects
+- Missing error handling or edge case coverage
+- Security or compliance requirements not addressed
+  </action>
+
+<action>Identify Sequencing Issues:
+
+- Dependencies not properly ordered
+- Stories that assume components not yet built
+- Parallel work that should be sequential
+- Missing prerequisite technical tasks
+  </action>
+
+<action>Detect Potential Contradictions:
+
+- Conflicts between PRD and architecture approaches
+- Stories with conflicting technical approaches
+- Acceptance criteria that contradict requirements
+- Resource or technology conflicts
+  </action>
+
+<action>Find Gold-Plating and Scope Creep:
+
+- Features in architecture not required by PRD
+- Stories implementing beyond requirements
+- Technical complexity beyond project needs
+- Over-engineering indicators
+  </action>
+
+<template-output>gap_risk_analysis</template-output>
+</step>
+
+<step n="5" goal="UX and special concerns validation" optional="true">
+<check if="UX artifacts exist or UX workflow in active path">
+<action>Review UX artifacts and validate integration:
+- Check that UX requirements are reflected in PRD
+- Verify stories include UX implementation tasks
+- Ensure architecture supports UX requirements (performance, responsiveness)
+- Identify any UX concerns not addressed in stories
+</action>
+
+<action>Validate accessibility and usability coverage:
+
+- Check for accessibility requirement coverage in stories
+- Verify responsive design considerations if applicable
+- Ensure user flow completeness across stories
+  </action>
+  </check>
+
+<template-output>ux_validation</template-output>
+</step>
+
+<step n="6" goal="Generate comprehensive readiness assessment">
+<action>Compile all findings into a structured readiness report with:
+- Executive summary of readiness status
+- Project context and validation scope
+- Document inventory and coverage assessment
+- Detailed findings organized by severity (Critical, High, Medium, Low)
+- Specific recommendations for each issue
+- Overall readiness recommendation (Ready, Ready with Conditions, Not Ready)
+</action>
+
+<action>Provide actionable next steps:
+
+- List any critical issues that must be resolved
+- Suggest specific document updates needed
+- Recommend additional stories or tasks required
+- Propose sequencing adjustments if needed
+  </action>
+
+<action>Include positive findings:
+
+- Highlight well-aligned areas
+- Note particularly thorough documentation
+- Recognize good architectural decisions
+- Commend comprehensive story coverage where found
+  </action>
+
+<template-output>readiness_assessment</template-output>
+</step>
+
+<step n="7" goal="Workflow status update offer" optional="true">
+<ask>The readiness assessment is complete. Would you like to update the workflow status to proceed to the next phase? [yes/no]
+
+Note: This will advance the project workflow to the next phase in your current path.</ask>
+
+<action if="user_response == 'yes'">
+Determine the next workflow phase based on current status:
+- If Level 0-1: Advance to implementation phase
+- If Level 2-4 in solutioning: Advance to Phase 4 (Implementation)
+- Update the workflow status configuration accordingly
+- Confirm the update with the user
+</action>
+
+<action if="user_response == 'no'">
+Acknowledge that the workflow status remains unchanged.
+Remind user they can manually update when ready.
+</action>
+
+<template-output>status_update_result</template-output>
+</step>
+
+</workflow>

src/modules/bmm/workflows/3-solutioning/implementation-ready-check/template.md

@@ -0,0 +1,146 @@
+# Implementation Readiness Assessment Report
+
+**Date:** {{date}}
+**Project:** {{project_name}}
+**Assessed By:** {{user_name}}
+**Assessment Type:** Phase 3 to Phase 4 Transition Validation
+
+---
+
+## Executive Summary
+
+{{readiness_assessment}}
+
+---
+
+## Project Context
+
+{{project_context}}
+
+---
+
+## Document Inventory
+
+### Documents Reviewed
+
+{{document_inventory}}
+
+### Document Analysis Summary
+
+{{document_analysis}}
+
+---
+
+## Alignment Validation Results
+
+### Cross-Reference Analysis
+
+{{alignment_validation}}
+
+---
+
+## Gap and Risk Analysis
+
+### Critical Findings
+
+{{gap_risk_analysis}}
+
+---
+
+## UX and Special Concerns
+
+{{ux_validation}}
+
+---
+
+## Detailed Findings
+
+### 🔴 Critical Issues
+
+_Must be resolved before proceeding to implementation_
+
+{{critical_issues}}
+
+### 🟠 High Priority Concerns
+
+_Should be addressed to reduce implementation risk_
+
+{{high_priority_concerns}}
+
+### 🟡 Medium Priority Observations
+
+_Consider addressing for smoother implementation_
+
+{{medium_priority_observations}}
+
+### 🟢 Low Priority Notes
+
+_Minor items for consideration_
+
+{{low_priority_notes}}
+
+---
+
+## Positive Findings
+
+### ✅ Well-Executed Areas
+
+{{positive_findings}}
+
+---
+
+## Recommendations
+
+### Immediate Actions Required
+
+{{immediate_actions}}
+
+### Suggested Improvements
+
+{{suggested_improvements}}
+
+### Sequencing Adjustments
+
+{{sequencing_adjustments}}
+
+---
+
+## Readiness Decision
+
+### Overall Assessment: {{overall_readiness_status}}
+
+{{readiness_rationale}}
+
+### Conditions for Proceeding (if applicable)
+
+{{conditions_for_proceeding}}
+
+---
+
+## Next Steps
+
+{{recommended_next_steps}}
+
+### Workflow Status Update
+
+{{status_update_result}}
+
+---
+
+## Appendices
+
+### A. Validation Criteria Applied
+
+{{validation_criteria_used}}
+
+### B. Traceability Matrix
+
+{{traceability_matrix}}
+
+### C. Risk Mitigation Strategies
+
+{{risk_mitigation_strategies}}
+
+---
+
+_This readiness assessment was generated using the BMad Method Implementation Ready Check workflow (v6-alpha)_

src/modules/bmm/workflows/3-solutioning/implementation-ready-check/validation-criteria.yaml

@@ -0,0 +1,184 @@
+# Implementation Readiness Validation Criteria
+# Defines systematic validation rules by project level
+
+validation_rules:
+  # Level 0-1 Projects (Simple, minimal planning)
+  level_0_1:
+    required_documents:
+      - tech_spec
+      - stories_or_tasks
+
+    validations:
+      - name: "Tech Spec Completeness"
+        checks:
+          - "All features defined with implementation approach"
+          - "Technical dependencies identified"
+          - "API contracts defined if applicable"
+          - "Data models specified"
+
+      - name: "Story Coverage"
+        checks:
+          - "All tech spec features have corresponding stories"
+          - "Stories are sequenced logically"
+          - "Technical tasks are defined"
+          - "No critical gaps in coverage"
+
+  # Level 2 Projects (PRD + Tech Spec, no separate architecture)
+  level_2:
+    required_documents:
+      - prd
+      - tech_spec # Includes architecture decisions
+      - epics_and_stories
+
+    validations:
+      - name: "PRD to Tech Spec Alignment"
+        checks:
+          - "All PRD requirements addressed in tech spec"
+          - "Architecture embedded in tech spec covers PRD needs"
+          - "Non-functional requirements are specified"
+          - "Technical approach supports business goals"
+
+      - name: "Story Coverage and Alignment"
+        checks:
+          - "Every PRD requirement has story coverage"
+          - "Stories align with tech spec approach"
+          - "Epic breakdown is complete"
+          - "Acceptance criteria match PRD success criteria"
+
+      - name: "Sequencing Validation"
+        checks:
+          - "Foundation stories come first"
+          - "Dependencies are properly ordered"
+          - "Iterative delivery is possible"
+          - "No circular dependencies"
+
+  # Level 3-4 Projects (Full planning with separate architecture)
+  level_3_4:
+    required_documents:
+      - prd
+      - solution_architecture
+      - epics_and_stories
+      - tech_spec # Optional at Level 4
+
+    validations:
+      - name: "PRD Completeness"
+        checks:
+          - "User requirements fully documented"
+          - "Success criteria are measurable"
+          - "Scope boundaries clearly defined"
+          - "Priorities are assigned"
+
+      - name: "Architecture Coverage"
+        checks:
+          - "All PRD requirements have architectural support"
+          - "System design is complete"
+          - "Integration points defined"
+          - "Security architecture specified"
+          - "Performance considerations addressed"
+
+      - name: "PRD-Architecture Alignment"
+        checks:
+          - "No architecture gold-plating beyond PRD"
+          - "NFRs from PRD reflected in architecture"
+          - "Technology choices support requirements"
+          - "Scalability matches expected growth"
+
+      - name: "Story Implementation Coverage"
+        checks:
+          - "All architectural components have stories"
+          - "Infrastructure setup stories exist"
+          - "Integration implementation planned"
+          - "Security implementation stories present"
+
+      - name: "Comprehensive Sequencing"
+        checks:
+          - "Infrastructure before features"
+          - "Authentication before protected resources"
+          - "Core features before enhancements"
+          - "Dependencies properly ordered"
+          - "Allows for iterative releases"
+
+# Special validation contexts
+special_contexts:
+  greenfield:
+    additional_checks:
+      - "Project initialization stories exist"
+      - "Development environment setup documented"
+      - "CI/CD pipeline stories included"
+      - "Initial data/schema setup planned"
+      - "Deployment infrastructure stories present"
+
+  ux_workflow_active:
+    additional_checks:
+      - "UX requirements in PRD"
+      - "UX implementation stories exist"
+      - "Accessibility requirements covered"
+      - "Responsive design addressed"
+      - "User flow continuity maintained"
+
+  api_heavy:
+    additional_checks:
+      - "API contracts fully defined"
+      - "Versioning strategy documented"
+      - "Authentication/authorization specified"
+      - "Rate limiting considered"
+      - "API documentation stories included"
+
+# Severity definitions
+severity_levels:
+  critical:
+    description: "Must be resolved before implementation"
+    examples:
+      - "Missing stories for core requirements"
+      - "Conflicting technical approaches"
+      - "No infrastructure setup for greenfield"
+      - "Security requirements not addressed"
+
+  high:
+    description: "Should be addressed to reduce risk"
+    examples:
+      - "Incomplete acceptance criteria"
+      - "Unclear story dependencies"
+      - "Missing error handling coverage"
+      - "Performance requirements not validated"
+
+  medium:
+    description: "Consider addressing for smoother implementation"
+    examples:
+      - "Documentation gaps"
+      - "Test strategy not defined"
+      - "Monitoring approach unclear"
+      - "Minor sequencing improvements possible"
+
+  low:
+    description: "Minor improvements for consideration"
+    examples:
+      - "Formatting inconsistencies"
+      - "Optional enhancements identified"
+      - "Style guide compliance"
+      - "Nice-to-have features noted"
+
+# Readiness decision criteria
+readiness_decisions:
+  ready:
+    criteria:
+      - "No critical issues found"
+      - "All required documents present"
+      - "Core alignments validated"
+      - "Story sequencing logical"
+      - "Team can begin implementation"
+
+  ready_with_conditions:
+    criteria:
+      - "Only high/medium issues found"
+      - "Mitigation plans identified"
+      - "Core path to MVP clear"
+      - "Issues won't block initial stories"
+
+  not_ready:
+    criteria:
+      - "Critical issues identified"
+      - "Major gaps in coverage"
+      - "Conflicting approaches found"
+      - "Required documents missing"
+      - "Blocking dependencies unresolved"

src/modules/bmm/workflows/3-solutioning/implementation-ready-check/workflow.yaml

@@ -0,0 +1,36 @@
+# Implementation Ready Check - Workflow Configuration
+name: implementation-ready-check
+description: "Systematically validate that all planning and solutioning phases are complete and properly aligned before transitioning to Phase 4 implementation. Ensures PRD, architecture, and stories are cohesive with no gaps or contradictions."
+author: "BMad Builder"
+
+# 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"
+date: system-generated
+
+# Workflow status integration
+workflow_status_workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
+workflow_paths_dir: "{project-root}/bmad/bmm/workflows/workflow-status/paths"
+
+# Module path and component files
+installed_path: "{project-root}/bmad/bmm/workflows/3-solutioning/implementation-ready-check"
+template: "{installed_path}/template.md"
+instructions: "{installed_path}/instructions.md"
+validation: "{installed_path}/checklist.md"
+
+# Output configuration
+default_output_file: "{output_folder}/implementation-readiness-report-{{date}}.md"
+
+# Expected input documents (varies by project level)
+recommended_inputs:
+  - prd: "{output_folder}/prd*.md"
+  - architecture: "{output_folder}/solution-architecture*.md"
+  - tech_spec: "{output_folder}/tech-spec*.md"
+  - epics_stories: "{output_folder}/epic*.md"
+  - ux_artifacts: "{output_folder}/ux*.md"
+
+# Validation criteria data
+validation_criteria: "{installed_path}/validation-criteria.yaml"

src/modules/bmm/workflows/3-solutioning/project-types/backend-instructions.md

@@ -0,0 +1,170 @@
+# Backend/API Service Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for backend/API architecture decisions.
+The LLM should:
+- Analyze the PRD to understand data flows, performance needs, and integrations
+- Guide decisions based on scale, team size, and operational complexity
+- Focus only on relevant architectural areas
+- Make intelligent recommendations that align with project requirements
+- Keep explanations concise and decision-focused
+</critical>
+
+## Service Architecture Pattern
+
+**Determine the Right Architecture**
+Based on the requirements, guide toward the appropriate pattern:
+
+- **Monolith**: For most projects starting out, single deployment, simple operations
+- **Microservices**: Only when there's clear domain separation, large teams, or specific scaling needs
+- **Serverless**: For event-driven workloads, variable traffic, or minimal operations
+- **Modular Monolith**: Best of both worlds for growing projects
+
+Don't default to microservices - most projects benefit from starting simple.
+
+## Language and Framework Selection
+
+**Choose Based on Context**
+Consider these factors intelligently:
+
+- Team expertise (use what the team knows unless there's a compelling reason)
+- Performance requirements (Go/Rust for high performance, Python/Node for rapid development)
+- Ecosystem needs (Python for ML/data, Node for full-stack JS, Java for enterprise)
+- Hiring pool and long-term maintenance
+
+For beginners: Suggest mainstream options with good documentation.
+For experts: Let them specify preferences, discuss specific trade-offs only if asked.
+
+## API Design Philosophy
+
+**Match API Style to Client Needs**
+
+- REST: Default for public APIs, simple CRUD, wide compatibility
+- GraphQL: Multiple clients with different data needs, complex relationships
+- gRPC: Service-to-service communication, high performance binary protocols
+- WebSocket/SSE: Real-time requirements
+
+Don't ask about API paradigm if it's obvious from requirements (e.g., real-time chat needs WebSocket).
+
+## Data Architecture
+
+**Database Decisions Based on Data Characteristics**
+Analyze the data requirements to suggest:
+
+- **Relational** (PostgreSQL/MySQL): Structured data, ACID requirements, complex queries
+- **Document** (MongoDB): Flexible schemas, hierarchical data, rapid prototyping
+- **Key-Value** (Redis/DynamoDB): Caching, sessions, simple lookups
+- **Time-series**: IoT, metrics, event data
+- **Graph**: Social networks, recommendation engines
+
+Consider polyglot persistence only for clear, distinct use cases.
+
+**Data Access Layer**
+
+- ORMs for developer productivity and type safety
+- Query builders for flexibility with some safety
+- Raw SQL only when performance is critical
+
+Match to team expertise and project complexity.
+
+## Security and Authentication
+
+**Security Appropriate to Risk**
+
+- Internal tools: Simple API keys might suffice
+- B2C applications: Managed auth services (Auth0, Firebase Auth)
+- B2B/Enterprise: SAML, SSO, advanced RBAC
+- Financial/Healthcare: Compliance-driven requirements
+
+Don't over-engineer security for prototypes, don't under-engineer for production.
+
+## Messaging and Events
+
+**Only If Required by the Architecture**
+Determine if async processing is actually needed:
+
+- Message queues for decoupling, reliability, buffering
+- Event streaming for event sourcing, real-time analytics
+- Pub/sub for fan-out scenarios
+
+Skip this entirely for simple request-response APIs.
+
+## Operational Considerations
+
+**Observability Based on Criticality**
+
+- Development: Basic logging might suffice
+- Production: Structured logging, metrics, tracing
+- Mission-critical: Full observability stack
+
+**Scaling Strategy**
+
+- Start with vertical scaling (simpler)
+- Plan for horizontal scaling if needed
+- Consider auto-scaling for variable loads
+
+## Performance Requirements
+
+**Right-Size Performance Decisions**
+
+- Don't optimize prematurely
+- Identify actual bottlenecks from requirements
+- Consider caching strategically, not everywhere
+- Database optimization before adding complexity
+
+## Integration Patterns
+
+**External Service Integration**
+Based on the PRD's integration requirements:
+
+- Circuit breakers for resilience
+- Rate limiting for API consumption
+- Webhook patterns for event reception
+- SDK vs. API direct calls
+
+## Deployment Strategy
+
+**Match Deployment to Team Capability**
+
+- Small teams: Managed platforms (Heroku, Railway, Fly.io)
+- DevOps teams: Kubernetes, cloud-native
+- Enterprise: Consider existing infrastructure
+
+**CI/CD Complexity**
+
+- Start simple: Platform auto-deploy
+- Add complexity as needed: testing stages, approvals, rollback
+
+## Adaptive Guidance Examples
+
+**For a REST API serving a mobile app:**
+Focus on response times, offline support, versioning, and push notifications.
+
+**For a data processing pipeline:**
+Emphasize batch vs. stream processing, data validation, error handling, and monitoring.
+
+**For a microservices migration:**
+Discuss service boundaries, data consistency, service discovery, and distributed tracing.
+
+**For an enterprise integration:**
+Focus on security, compliance, audit logging, and existing system compatibility.
+
+## Key Principles
+
+1. **Start simple, evolve as needed** - Don't build for imaginary scale
+2. **Use boring technology** - Proven solutions over cutting edge
+3. **Optimize for your constraint** - Development speed, performance, or operations
+4. **Make reversible decisions** - Avoid early lock-in
+5. **Document the "why"** - But keep it brief
+
+## Output Format
+
+Structure decisions as:
+
+- **Choice**: [Specific technology with version]
+- **Rationale**: [One sentence why this fits the requirements]
+- **Trade-off**: [What we're optimizing for vs. what we're accepting]
+
+Keep technical decisions definitive and version-specific for LLM consumption.

src/modules/bmm/workflows/3-solutioning/project-types/backend-questions.md

@@ -1,490 +0,0 @@
-# Backend/API Service Architecture Questions
-
-## Service Type and Architecture
-
-1. **Service architecture:**
-   - Monolithic API (single service)
-   - Microservices (multiple independent services)
-   - Modular monolith (single deployment, modular code)
-   - Serverless (AWS Lambda, Cloud Functions, etc.)
-   - Hybrid
-
-2. **API paradigm:**
-   - REST
-   - GraphQL
-   - gRPC
-   - WebSocket (real-time)
-   - Server-Sent Events (SSE)
-   - Message-based (event-driven)
-   - Multiple paradigms
-
-3. **Communication patterns:**
-   - Synchronous (request-response)
-   - Asynchronous (message queues)
-   - Event-driven (pub/sub)
-   - Webhooks
-   - Multiple patterns
-
-## Framework and Language
-
-4. **Backend language/framework:**
-   - Node.js (Express, Fastify, NestJS, Hono)
-   - Python (FastAPI, Django, Flask)
-   - Go (Gin, Echo, Chi, standard lib)
-   - Java/Kotlin (Spring Boot, Micronaut, Quarkus)
-   - C# (.NET Core, ASP.NET)
-   - Ruby (Rails, Sinatra)
-   - Rust (Axum, Actix, Rocket)
-   - PHP (Laravel, Symfony)
-   - Elixir (Phoenix)
-   - Other: **\_\_\_**
-
-5. **GraphQL implementation (if applicable):**
-   - Apollo Server
-   - GraphQL Yoga
-   - Hasura (auto-generated)
-   - Postgraphile
-   - Custom
-   - Not using GraphQL
-
-6. **gRPC implementation (if applicable):**
-   - Protocol Buffers
-   - Language-specific gRPC libraries
-   - Not using gRPC
-
-## Database and Data Layer
-
-7. **Primary database:**
-   - PostgreSQL
-   - MySQL/MariaDB
-   - MongoDB
-   - DynamoDB (AWS)
-   - Firestore (Google)
-   - CockroachDB
-   - Cassandra
-   - Redis (as primary)
-   - Multiple databases (polyglot persistence)
-   - Other: **\_\_\_**
-
-8. **Database access pattern:**
-   - ORM (Prisma, TypeORM, SQLAlchemy, Hibernate, etc.)
-   - Query builder (Knex, Kysely, jOOQ)
-   - Raw SQL
-   - Database SDK (Supabase, Firebase)
-   - Mix
-
-9. **Caching layer:**
-   - Redis
-   - Memcached
-   - In-memory (application cache)
-   - CDN caching (for static responses)
-   - Database query cache
-   - None needed
-
-10. **Read replicas:**
-    - Yes (separate read/write databases)
-    - No (single database)
-    - Planned for future
-
-11. **Database sharding:**
-    - Yes (horizontal partitioning)
-    - No (single database)
-    - Planned for scale
-
-## Authentication and Authorization
-
-12. **Authentication method:**
-    - JWT (stateless)
-    - Session-based (stateful)
-    - OAuth2 provider (Auth0, Okta, Keycloak)
-    - API keys
-    - Mutual TLS (mTLS)
-    - Multiple methods
-
-13. **Authorization pattern:**
-    - Role-Based Access Control (RBAC)
-    - Attribute-Based Access Control (ABAC)
-    - Access Control Lists (ACL)
-    - Custom logic
-    - None (open API)
-
-14. **Identity provider:**
-    - Self-managed (own user database)
-    - Auth0
-    - AWS Cognito
-    - Firebase Auth
-    - Keycloak
-    - Azure AD / Entra ID
-    - Okta
-    - Other: **\_\_\_**
-
-## Message Queue and Event Streaming
-
-15. **Message queue (if needed):**
-    - RabbitMQ
-    - Apache Kafka
-    - AWS SQS
-    - Google Pub/Sub
-    - Redis (pub/sub)
-    - NATS
-    - None needed
-    - Other: **\_\_\_**
-
-16. **Event streaming (if needed):**
-    - Apache Kafka
-    - AWS Kinesis
-    - Azure Event Hubs
-    - Redis Streams
-    - None needed
-
-17. **Background jobs:**
-    - Queue-based (Bull, Celery, Sidekiq)
-    - Cron-based (node-cron, APScheduler)
-    - Serverless functions (scheduled Lambda)
-    - None needed
-
-## Service Communication (Microservices)
-
-18. **Service mesh (if microservices):**
-    - Istio
-    - Linkerd
-    - Consul
-    - None (direct communication)
-    - Not applicable
-
-19. **Service discovery:**
-    - Kubernetes DNS
-    - Consul
-    - etcd
-    - AWS Cloud Map
-    - Hardcoded (for now)
-    - Not applicable
-
-20. **Inter-service communication:**
-    - HTTP/REST
-    - gRPC
-    - Message queue
-    - Event bus
-    - Not applicable
-
-## API Design and Documentation
-
-21. **API versioning:**
-    - URL versioning (/v1/, /v2/)
-    - Header versioning (Accept-Version)
-    - No versioning (single version)
-    - Semantic versioning
-
-22. **API documentation:**
-    - OpenAPI/Swagger
-    - GraphQL introspection/playground
-    - Postman collections
-    - Custom docs
-    - README only
-
-23. **API testing tools:**
-    - Postman
-    - Insomnia
-    - REST Client (VS Code)
-    - cURL examples
-    - Multiple tools
-
-## Rate Limiting and Throttling
-
-24. **Rate limiting:**
-    - Per-user/API key
-    - Per-IP
-    - Global rate limit
-    - Tiered (different limits per plan)
-    - None (internal API)
-
-25. **Rate limit implementation:**
-    - Application-level (middleware)
-    - API Gateway
-    - Redis-based
-    - None
-
-## Data Validation and Processing
-
-26. **Request validation:**
-    - Schema validation (Zod, Joi, Yup, Pydantic)
-    - Manual validation
-    - Framework built-in
-    - None
-
-27. **Data serialization:**
-    - JSON
-    - Protocol Buffers
-    - MessagePack
-    - XML
-    - Multiple formats
-
-28. **File uploads (if applicable):**
-    - Direct to server (local storage)
-    - S3/Cloud storage
-    - Presigned URLs (client direct upload)
-    - None needed
-
-## Error Handling and Resilience
-
-29. **Error handling strategy:**
-    - Standard HTTP status codes
-    - Custom error codes
-    - RFC 7807 (Problem Details)
-    - GraphQL errors
-    - Mix
-
-30. **Circuit breaker (for external services):**
-    - Yes (Hystrix, Resilience4j, Polly)
-    - No (direct calls)
-    - Not needed
-
-31. **Retry logic:**
-    - Exponential backoff
-    - Fixed retries
-    - No retries
-    - Library-based (axios-retry, etc.)
-
-32. **Graceful shutdown:**
-    - Yes (drain connections, finish requests)
-    - No (immediate shutdown)
-
-## Observability
-
-33. **Logging:**
-    - Structured logging (JSON)
-    - Plain text logs
-    - Library: (Winston, Pino, Logrus, Zap, etc.)
-
-34. **Log aggregation:**
-    - ELK Stack (Elasticsearch, Logstash, Kibana)
-    - Datadog
-    - Splunk
-    - CloudWatch Logs
-    - Loki + Grafana
-    - None (local logs)
-
-35. **Metrics and Monitoring:**
-    - Prometheus
-    - Datadog
-    - New Relic
-    - Application Insights
-    - CloudWatch
-    - Grafana
-    - None
-
-36. **Distributed tracing:**
-    - OpenTelemetry
-    - Jaeger
-    - Zipkin
-    - Datadog APM
-    - AWS X-Ray
-    - None
-
-37. **Health checks:**
-    - Liveness probe (is service up?)
-    - Readiness probe (can accept traffic?)
-    - Startup probe
-    - Dependency checks (database, cache, etc.)
-    - None
-
-38. **Alerting:**
-    - PagerDuty
-    - Opsgenie
-    - Slack/Discord webhooks
-    - Email
-    - Custom
-    - None
-
-## Security
-
-39. **HTTPS/TLS:**
-    - Required (HTTPS only)
-    - Optional (support both)
-    - Terminated at load balancer
-
-40. **CORS configuration:**
-    - Specific origins (whitelist)
-    - All origins (open)
-    - None needed (same-origin clients)
-
-41. **Security headers:**
-    - Helmet.js or equivalent
-    - Custom headers
-    - None (basic)
-
-42. **Input sanitization:**
-    - SQL injection prevention (parameterized queries)
-    - XSS prevention
-    - CSRF protection
-    - All of the above
-
-43. **Secrets management:**
-    - Environment variables
-    - AWS Secrets Manager
-    - HashiCorp Vault
-    - Azure Key Vault
-    - Kubernetes Secrets
-    - Doppler
-    - Other: **\_\_\_**
-
-44. **Compliance requirements:**
-    - GDPR
-    - HIPAA
-    - SOC 2
-    - PCI DSS
-    - None
-
-## Deployment and Infrastructure
-
-45. **Deployment platform:**
-    - AWS (ECS, EKS, Lambda, Elastic Beanstalk)
-    - Google Cloud (GKE, Cloud Run, App Engine)
-    - Azure (AKS, App Service, Container Instances)
-    - Kubernetes (self-hosted)
-    - Docker Swarm
-    - Heroku
-    - Railway
-    - Fly.io
-    - Vercel/Netlify (serverless)
-    - VPS (DigitalOcean, Linode)
-    - On-premise
-    - Other: **\_\_\_**
-
-46. **Containerization:**
-    - Docker
-    - Podman
-    - Not containerized (direct deployment)
-
-47. **Orchestration:**
-    - Kubernetes
-    - Docker Compose (dev/small scale)
-    - AWS ECS
-    - Nomad
-    - None (single server)
-
-48. **Infrastructure as Code:**
-    - Terraform
-    - CloudFormation
-    - Pulumi
-    - Bicep (Azure)
-    - CDK (AWS)
-    - Ansible
-    - Manual setup
-
-49. **Load balancing:**
-    - Application Load Balancer (AWS ALB, Azure App Gateway)
-    - Nginx
-    - HAProxy
-    - Kubernetes Ingress
-    - Traefik
-    - Platform-managed
-    - None (single instance)
-
-50. **Auto-scaling:**
-    - Horizontal (add more instances)
-    - Vertical (increase instance size)
-    - Serverless (automatic)
-    - None (fixed capacity)
-
-## CI/CD
-
-51. **CI/CD platform:**
-    - GitHub Actions
-    - GitLab CI
-    - CircleCI
-    - Jenkins
-    - AWS CodePipeline
-    - Azure DevOps
-    - Google Cloud Build
-    - Other: **\_\_\_**
-
-52. **Deployment strategy:**
-    - Rolling deployment
-    - Blue-green deployment
-    - Canary deployment
-    - Recreate (downtime)
-    - Serverless (automatic)
-
-53. **Testing in CI/CD:**
-    - Unit tests
-    - Integration tests
-    - E2E tests
-    - Load tests
-    - Security scans
-    - All of the above
-
-## Performance
-
-54. **Performance requirements:**
-    - High throughput (1000+ req/s)
-    - Moderate (100-1000 req/s)
-    - Low (< 100 req/s)
-
-55. **Latency requirements:**
-    - Ultra-low (< 10ms)
-    - Low (< 100ms)
-    - Moderate (< 500ms)
-    - No specific requirement
-
-56. **Connection pooling:**
-    - Database connection pool
-    - HTTP connection pool (for external APIs)
-    - None needed
-
-57. **CDN (for static assets):**
-    - CloudFront
-    - Cloudflare
-    - Fastly
-    - None (dynamic only)
-
-## Data and Storage
-
-58. **File storage (if needed):**
-    - AWS S3
-    - Google Cloud Storage
-    - Azure Blob Storage
-    - MinIO (self-hosted)
-    - Local filesystem
-    - None needed
-
-59. **Search functionality:**
-    - Elasticsearch
-    - Algolia
-    - Meilisearch
-    - Typesense
-    - Database full-text search
-    - None needed
-
-60. **Data backup:**
-    - Automated database backups
-    - Point-in-time recovery
-    - Manual backups
-    - Cloud-provider managed
-    - None (dev/test only)
-
-## Additional Features
-
-61. **Webhooks (outgoing):**
-    - Yes (notify external systems)
-    - No
-
-62. **Scheduled tasks/Cron jobs:**
-    - Yes (cleanup, reports, etc.)
-    - No
-
-63. **Multi-tenancy:**
-    - Single tenant
-    - Multi-tenant (shared database)
-    - Multi-tenant (separate databases)
-    - Not applicable
-
-64. **Internationalization (i18n):**
-    - Multiple languages/locales
-    - English only
-    - Not applicable
-
-65. **Audit logging:**
-    - Track all changes (who, what, when)
-    - Critical operations only
-    - None

src/modules/bmm/workflows/3-solutioning/project-types/cli-instructions.md

@@ -0,0 +1,149 @@
+# CLI Tool Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for CLI tool architecture decisions.
+The LLM should:
+- Understand the tool's purpose and target users from requirements
+- Guide framework choice based on distribution needs and complexity
+- Focus on CLI-specific UX patterns
+- Consider packaging and distribution strategy
+- Keep it simple unless complexity is justified
+</critical>
+
+## Language and Framework Selection
+
+**Choose Based on Distribution and Users**
+
+- **Node.js**: NPM distribution, JavaScript ecosystem, cross-platform
+- **Go**: Single binary distribution, excellent performance
+- **Python**: Data/science tools, rich ecosystem, pip distribution
+- **Rust**: Performance-critical, memory-safe, growing ecosystem
+- **Bash**: Simple scripts, Unix-only, no dependencies
+
+Consider your users: Developers might have Node/Python, but end users need standalone binaries.
+
+## CLI Framework Choice
+
+**Match Complexity to Needs**
+Based on the tool's requirements:
+
+- **Simple scripts**: Use built-in argument parsing
+- **Command-based**: Commander.js, Click, Cobra, Clap
+- **Interactive**: Inquirer, Prompt, Dialoguer
+- **Full TUI**: Blessed, Bubble Tea, Ratatui
+
+Don't use a heavy framework for a simple script, but don't parse args manually for complex CLIs.
+
+## Command Architecture
+
+**Command Structure Design**
+
+- Single command vs. sub-commands
+- Flag and argument patterns
+- Configuration file support
+- Environment variable integration
+
+Follow platform conventions (POSIX-style flags, standard exit codes).
+
+## User Experience Patterns
+
+**CLI UX Best Practices**
+
+- Help text and usage examples
+- Progress indicators for long operations
+- Colored output for clarity
+- Machine-readable output options (JSON, quiet mode)
+- Sensible defaults with override options
+
+## Configuration Management
+
+**Settings Strategy**
+Based on tool complexity:
+
+- Command-line flags for one-off changes
+- Config files for persistent settings
+- Environment variables for deployment config
+- Cascading configuration (defaults → config → env → flags)
+
+## Error Handling
+
+**User-Friendly Errors**
+
+- Clear error messages with actionable fixes
+- Exit codes following conventions
+- Verbose/debug modes for troubleshooting
+- Graceful handling of common issues
+
+## Installation and Distribution
+
+**Packaging Strategy**
+
+- **NPM/PyPI**: For developer tools
+- **Homebrew/Snap/Chocolatey**: For end-user tools
+- **Binary releases**: GitHub releases with multiple platforms
+- **Docker**: For complex dependencies
+- **Shell script**: For simple Unix tools
+
+## Testing Strategy
+
+**CLI Testing Approach**
+
+- Unit tests for core logic
+- Integration tests for commands
+- Snapshot testing for output
+- Cross-platform testing if targeting multiple OS
+
+## Performance Considerations
+
+**Optimization Where Needed**
+
+- Startup time for frequently-used commands
+- Streaming for large data processing
+- Parallel execution where applicable
+- Efficient file system operations
+
+## Plugin Architecture
+
+**Extensibility** (if needed)
+
+- Plugin system design
+- Hook mechanisms
+- API for extensions
+- Plugin discovery and loading
+
+Only if the PRD indicates extensibility requirements.
+
+## Adaptive Guidance Examples
+
+**For a Build Tool:**
+Focus on performance, watch mode, configuration management, and plugin system.
+
+**For a Dev Utility:**
+Emphasize developer experience, integration with existing tools, and clear output.
+
+**For a Data Processing Tool:**
+Focus on streaming, progress reporting, error recovery, and format conversion.
+
+**For a System Admin Tool:**
+Emphasize permission handling, logging, dry-run mode, and safety checks.
+
+## Key Principles
+
+1. **Follow platform conventions** - Users expect familiar patterns
+2. **Fail fast with clear errors** - Don't leave users guessing
+3. **Provide escape hatches** - Debug mode, verbose output, dry runs
+4. **Document through examples** - Show, don't just tell
+5. **Respect user time** - Fast startup, helpful defaults
+
+## Output Format
+
+Document as:
+
+- **Language**: [Choice with version]
+- **Framework**: [CLI framework if applicable]
+- **Distribution**: [How users will install]
+- **Key commands**: [Primary user interactions]
+
+Keep focus on user-facing behavior and implementation simplicity.

src/modules/bmm/workflows/3-solutioning/project-types/cli-questions.md

@@ -1,337 +0,0 @@
-# Command-Line Tool Architecture Questions
-
-## Language and Runtime
-
-1. **Primary language:**
-   - Go (compiled, single binary, great for CLIs)
-   - Rust (compiled, safe, performant)
-   - Python (interpreted, easy distribution via pip)
-   - Node.js/TypeScript (npm distribution)
-   - Bash/Shell script (lightweight, ubiquitous)
-   - Ruby (gem distribution)
-   - Java/Kotlin (JVM, jar)
-   - C/C++ (compiled, fastest)
-   - Other: **\_\_\_**
-
-2. **Target platforms:**
-   - Linux only
-   - macOS only
-   - Windows only
-   - Linux + macOS
-   - All three (Linux + macOS + Windows)
-   - Specific Unix variants: **\_\_\_**
-
-3. **Distribution method:**
-   - Single binary (compiled)
-   - Script (interpreted, needs runtime)
-   - Package manager (npm, pip, gem, cargo, etc.)
-   - Installer (brew, apt, yum, scoop, chocolatey)
-   - Container (Docker)
-   - Multiple methods
-
-## CLI Architecture
-
-4. **Command structure:**
-   - Single command (e.g., `grep pattern file`)
-   - Subcommands (e.g., `git commit`, `docker run`)
-   - Hybrid (main command + subcommands)
-   - Interactive shell (REPL)
-
-5. **Argument parsing library:**
-   - Go: cobra, cli, flag
-   - Rust: clap, structopt
-   - Python: argparse, click, typer
-   - Node: commander, yargs, oclif
-   - Bash: getopts, manual parsing
-   - Other: **\_\_\_**
-
-6. **Interactive mode:**
-   - Non-interactive only (runs and exits)
-   - Interactive prompts (inquirer, survey, etc.)
-   - REPL/shell mode
-   - Both modes supported
-
-7. **Long-running process:**
-   - Quick execution (completes immediately)
-   - Long-running (daemon/service)
-   - Can run in background
-   - Watch mode (monitors and reacts)
-
-## Input/Output
-
-8. **Input sources:**
-   - Command-line arguments
-   - Flags/options
-   - Environment variables
-   - Config file (JSON, YAML, TOML, INI)
-   - Interactive prompts
-   - Stdin (pipe input)
-   - Multiple sources
-
-9. **Output format:**
-   - Plain text (human-readable)
-   - JSON
-   - YAML
-   - XML
-   - CSV/TSV
-   - Table format
-   - User-selectable format
-   - Multiple formats
-
-10. **Output destination:**
-    - Stdout (standard output)
-    - Stderr (errors only)
-    - File output
-    - Multiple destinations
-    - Quiet mode (no output)
-
-11. **Colored output:**
-    - ANSI color codes
-    - Auto-detect TTY (color when terminal, plain when piped)
-    - User-configurable (--color flag)
-    - No colors (plain text only)
-
-12. **Progress indication:**
-    - Progress bars (for long operations)
-    - Spinners (for waiting)
-    - Step-by-step output
-    - Verbose/debug logging
-    - Silent mode option
-    - None needed (fast operations)
-
-## Configuration
-
-13. **Configuration file:**
-    - Required (must exist)
-    - Optional (defaults if missing)
-    - Not needed
-    - Generated on first run
-
-14. **Config file format:**
-    - JSON
-    - YAML
-    - TOML
-    - INI
-    - Custom format
-    - Multiple formats supported
-
-15. **Config file location:**
-    - Current directory (project-specific)
-    - User home directory (~/.config, ~/.myapp)
-    - System-wide (/etc/)
-    - User-specified path
-    - Multiple locations (cascade/merge)
-
-16. **Environment variables:**
-    - Used for configuration
-    - Used for secrets/credentials
-    - Used for runtime behavior
-    - Not used
-
-## Data and Storage
-
-17. **Persistent data:**
-    - Cache (temporary, can be deleted)
-    - State (must persist)
-    - User data (important)
-    - No persistent data needed
-
-18. **Data storage location:**
-    - Standard OS locations (XDG Base Directory, AppData, etc.)
-    - Current directory
-    - User-specified
-    - Temporary directory
-
-19. **Database/Data format:**
-    - SQLite
-    - JSON files
-    - Key-value store (BoltDB, etc.)
-    - CSV/plain files
-    - Remote database
-    - None needed
-
-## Execution Model
-
-20. **Execution pattern:**
-    - Run once and exit
-    - Watch mode (monitor changes)
-    - Server/daemon mode
-    - Cron-style (scheduled)
-    - Pipeline component (part of Unix pipeline)
-
-21. **Concurrency:**
-    - Single-threaded (sequential)
-    - Multi-threaded (parallel operations)
-    - Async I/O
-    - Not applicable
-
-22. **Signal handling:**
-    - Graceful shutdown (SIGTERM, SIGINT)
-    - Cleanup on exit
-    - Not needed (quick exit)
-
-## Networking (if applicable)
-
-23. **Network operations:**
-    - HTTP client (REST API calls)
-    - WebSocket client
-    - SSH client
-    - Database connections
-    - Other protocols: **\_\_\_**
-    - No networking
-
-24. **Authentication (if API calls):**
-    - API keys (env vars, config)
-    - OAuth2 flow
-    - Username/password
-    - Certificate-based
-    - None needed
-
-## Error Handling
-
-25. **Error reporting:**
-    - Stderr with error messages
-    - Exit codes (0 = success, non-zero = error)
-    - Detailed error messages
-    - Stack traces (debug mode)
-    - Simple messages (user-friendly)
-
-26. **Exit codes:**
-    - Standard (0 = success, 1 = error)
-    - Multiple exit codes (different error types)
-    - Documented exit codes
-
-27. **Logging:**
-    - Log levels (debug, info, warn, error)
-    - Log file output
-    - Stderr output
-    - Configurable verbosity (--verbose, --quiet)
-    - No logging (simple tool)
-
-## Piping and Integration
-
-28. **Stdin support:**
-    - Reads from stdin (pipe input)
-    - Optional stdin (file or stdin)
-    - No stdin support
-
-29. **Pipeline behavior:**
-    - Filter (reads stdin, writes stdout)
-    - Generator (no input, outputs data)
-    - Consumer (reads input, no stdout)
-    - Transformer (both input and output)
-
-30. **Shell completion:**
-    - Bash completion
-    - Zsh completion
-    - Fish completion
-    - PowerShell completion
-    - All shells
-    - None
-
-## Distribution and Installation
-
-31. **Package managers:**
-    - Homebrew (macOS/Linux)
-    - apt (Debian/Ubuntu)
-    - yum/dnf (RHEL/Fedora)
-    - Chocolatey/Scoop (Windows)
-    - npm/yarn (Node.js)
-    - pip (Python)
-    - cargo (Rust)
-    - Multiple managers
-    - Manual install only
-
-32. **Installation method:**
-    - Download binary (GitHub Releases)
-    - Install script (curl | bash)
-    - Package manager
-    - Build from source
-    - Container image
-    - Multiple methods
-
-33. **Binary distribution:**
-    - Single binary (statically linked)
-    - Multiple binaries (per platform)
-    - With dependencies (bundled)
-
-34. **Cross-compilation:**
-    - Yes (build for all platforms from one machine)
-    - No (need platform-specific builds)
-
-## Updates
-
-35. **Update mechanism:**
-    - Self-update command
-    - Package manager update
-    - Manual download
-    - No updates (stable tool)
-
-36. **Version checking:**
-    - Check for new versions on run
-    - --version flag
-    - No version tracking
-
-## Documentation
-
-37. **Help documentation:**
-    - --help flag (inline help)
-    - Man page
-    - Online docs
-    - README only
-    - All of the above
-
-38. **Examples/Tutorials:**
-    - Built-in examples (--examples)
-    - Online documentation
-    - README with examples
-    - None (self-explanatory)
-
-## Testing
-
-39. **Testing approach:**
-    - Unit tests
-    - Integration tests (full CLI execution)
-    - Snapshot testing (output comparison)
-    - Manual testing
-    - All of the above
-
-40. **CI/CD:**
-    - GitHub Actions
-    - GitLab CI
-    - Travis CI
-    - Cross-platform testing
-    - Manual builds
-
-## Performance
-
-41. **Performance requirements:**
-    - Must be fast (< 100ms)
-    - Moderate (< 1s)
-    - Can be slow (long-running tasks)
-
-42. **Memory usage:**
-    - Minimal (small files/data)
-    - Streaming (large files, low memory)
-    - Can use significant memory
-
-## Special Features
-
-43. **Watch mode:**
-    - Monitor files/directories for changes
-    - Auto-reload/re-run
-    - Not needed
-
-44. **Dry-run mode:**
-    - Preview changes without applying
-    - Not applicable
-
-45. **Verbose/Debug mode:**
-    - --verbose flag (detailed output)
-    - --debug flag (even more detail)
-    - Not needed
-
-46. **Plugins/Extensions:**
-    - Plugin system (user can extend)
-    - Monolithic (no plugins)
-    - Planned for future

src/modules/bmm/workflows/3-solutioning/project-types/data-instructions.md

@@ -0,0 +1,193 @@
+# Data Pipeline/Analytics Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for data pipeline and analytics architecture decisions.
+The LLM should:
+- Understand data volume, velocity, and variety from requirements
+- Guide tool selection based on scale and latency needs
+- Consider data governance and quality requirements
+- Balance batch vs. stream processing needs
+- Focus on maintainability and observability
+</critical>
+
+## Processing Architecture
+
+**Batch vs. Stream vs. Hybrid**
+Based on requirements:
+
+- **Batch**: For periodic processing, large volumes, complex transformations
+- **Stream**: For real-time requirements, event-driven, continuous processing
+- **Lambda Architecture**: Both batch and stream for different use cases
+- **Kappa Architecture**: Stream-only with replay capability
+
+Don't use streaming for daily reports, or batch for real-time alerts.
+
+## Technology Stack
+
+**Choose Based on Scale and Complexity**
+
+- **Small Scale**: Python scripts, Pandas, PostgreSQL
+- **Medium Scale**: Airflow, Spark, Redshift/BigQuery
+- **Large Scale**: Databricks, Snowflake, custom Kubernetes
+- **Real-time**: Kafka, Flink, ClickHouse, Druid
+
+Start simple and evolve - don't build for imaginary scale.
+
+## Orchestration Platform
+
+**Workflow Management**
+Based on complexity:
+
+- **Simple**: Cron jobs, Python scripts
+- **Medium**: Apache Airflow, Prefect, Dagster
+- **Complex**: Kubernetes Jobs, Argo Workflows
+- **Managed**: Cloud Composer, AWS Step Functions
+
+Consider team expertise and operational overhead.
+
+## Data Storage Architecture
+
+**Storage Layer Design**
+
+- **Data Lake**: Raw data in object storage (S3, GCS)
+- **Data Warehouse**: Structured, optimized for analytics
+- **Data Lakehouse**: Hybrid approach (Delta Lake, Iceberg)
+- **Operational Store**: For serving layer
+
+**File Formats**
+
+- Parquet for columnar analytics
+- Avro for row-based streaming
+- JSON for flexibility
+- CSV for simplicity
+
+## ETL/ELT Strategy
+
+**Transformation Approach**
+
+- **ETL**: Transform before loading (traditional)
+- **ELT**: Transform in warehouse (modern, scalable)
+- **Streaming ETL**: Continuous transformation
+
+Consider compute costs and transformation complexity.
+
+## Data Quality Framework
+
+**Quality Assurance**
+
+- Schema validation
+- Data profiling and anomaly detection
+- Completeness and freshness checks
+- Lineage tracking
+- Quality metrics and monitoring
+
+Build quality checks appropriate to data criticality.
+
+## Schema Management
+
+**Schema Evolution**
+
+- Schema registry for streaming
+- Version control for schemas
+- Backward compatibility strategy
+- Schema inference vs. strict schemas
+
+## Processing Frameworks
+
+**Computation Engines**
+
+- **Spark**: General-purpose, batch and stream
+- **Flink**: Low-latency streaming
+- **Beam**: Portable, multi-runtime
+- **Pandas/Polars**: Small-scale, in-memory
+- **DuckDB**: Local analytical processing
+
+Match framework to processing patterns.
+
+## Data Modeling
+
+**Analytical Modeling**
+
+- Star schema for BI tools
+- Data vault for flexibility
+- Wide tables for performance
+- Time-series modeling for metrics
+
+Consider query patterns and tool requirements.
+
+## Monitoring and Observability
+
+**Pipeline Monitoring**
+
+- Job success/failure tracking
+- Data quality metrics
+- Processing time and throughput
+- Cost monitoring
+- Alerting strategy
+
+## Security and Governance
+
+**Data Governance**
+
+- Access control and permissions
+- Data encryption at rest and transit
+- PII handling and masking
+- Audit logging
+- Compliance requirements (GDPR, HIPAA)
+
+Scale governance to regulatory requirements.
+
+## Development Practices
+
+**DataOps Approach**
+
+- Version control for code and configs
+- Testing strategy (unit, integration, data)
+- CI/CD for pipelines
+- Environment management
+- Documentation standards
+
+## Serving Layer
+
+**Data Consumption**
+
+- BI tool integration
+- API for programmatic access
+- Export capabilities
+- Caching strategy
+- Query optimization
+
+## Adaptive Guidance Examples
+
+**For Real-time Analytics:**
+Focus on streaming infrastructure, low-latency storage, and real-time dashboards.
+
+**For ML Feature Store:**
+Emphasize feature computation, versioning, serving latency, and training/serving skew.
+
+**For Business Intelligence:**
+Focus on dimensional modeling, semantic layer, and self-service analytics.
+
+**For Log Analytics:**
+Emphasize ingestion scale, retention policies, and search capabilities.
+
+## Key Principles
+
+1. **Start with the end in mind** - Know how data will be consumed
+2. **Design for failure** - Pipelines will break, plan recovery
+3. **Monitor everything** - You can't fix what you can't see
+4. **Version and test** - Data pipelines are code
+5. **Keep it simple** - Complexity kills maintainability
+
+## Output Format
+
+Document as:
+
+- **Processing**: [Batch/Stream/Hybrid approach]
+- **Stack**: [Core technologies with versions]
+- **Storage**: [Lake/Warehouse strategy]
+- **Orchestration**: [Workflow platform]
+
+Focus on data flow and transformation logic.

src/modules/bmm/workflows/3-solutioning/project-types/data-questions.md

@@ -1,472 +0,0 @@
-# Data/Analytics/ML Project Architecture Questions
-
-## Project Type and Scope
-
-1. **Primary project focus:**
-   - ETL/Data Pipeline (move and transform data)
-   - Data Analytics (BI, dashboards, reports)
-   - Machine Learning Training (build models)
-   - Machine Learning Inference (serve predictions)
-   - Data Warehouse/Lake (centralized data storage)
-   - Real-time Stream Processing
-   - Data Science Research/Exploration
-   - Multiple focuses
-
-2. **Scale of data:**
-   - Small (< 1GB, single machine)
-   - Medium (1GB - 1TB, can fit in memory with careful handling)
-   - Large (1TB - 100TB, distributed processing needed)
-   - Very Large (> 100TB, big data infrastructure)
-
-3. **Data velocity:**
-   - Batch (hourly, daily, weekly)
-   - Micro-batch (every few minutes)
-   - Near real-time (seconds)
-   - Real-time streaming (milliseconds)
-   - Mix
-
-## Programming Language and Environment
-
-4. **Primary language:**
-   - Python (pandas, numpy, sklearn, pytorch, tensorflow)
-   - R (tidyverse, caret)
-   - Scala (Spark)
-   - SQL (analytics, transformations)
-   - Java (enterprise data pipelines)
-   - Julia
-   - Multiple languages
-
-5. **Development environment:**
-   - Jupyter Notebooks (exploration)
-   - Production code (scripts/applications)
-   - Both (notebooks for exploration, code for production)
-   - Cloud notebooks (SageMaker, Vertex AI, Databricks)
-
-6. **Transition from notebooks to production:**
-   - Convert notebooks to scripts
-   - Use notebooks in production (Papermill, nbconvert)
-   - Keep separate (research vs production)
-
-## Data Sources
-
-7. **Data source types:**
-   - Relational databases (PostgreSQL, MySQL, SQL Server)
-   - NoSQL databases (MongoDB, Cassandra)
-   - Data warehouses (Snowflake, BigQuery, Redshift)
-   - APIs (REST, GraphQL)
-   - Files (CSV, JSON, Parquet, Avro)
-   - Streaming sources (Kafka, Kinesis, Pub/Sub)
-   - Cloud storage (S3, GCS, Azure Blob)
-   - SaaS platforms (Salesforce, HubSpot, etc.)
-   - Multiple sources
-
-8. **Data ingestion frequency:**
-   - One-time load
-   - Scheduled batch (daily, hourly)
-   - Real-time/streaming
-   - On-demand
-   - Mix
-
-9. **Data ingestion tools:**
-   - Custom scripts (Python, SQL)
-   - Airbyte
-   - Fivetran
-   - Stitch
-   - Apache NiFi
-   - Kafka Connect
-   - Cloud-native (AWS DMS, Google Datastream)
-   - Multiple tools
-
-## Data Storage
-
-10. **Primary data storage:**
-    - Data Warehouse (Snowflake, BigQuery, Redshift, Synapse)
-    - Data Lake (S3, GCS, ADLS with Parquet/Avro)
-    - Lakehouse (Databricks, Delta Lake, Iceberg, Hudi)
-    - Relational database
-    - NoSQL database
-    - File system
-    - Multiple storage layers
-
-11. **Storage format (for files):**
-    - Parquet (columnar, optimized)
-    - Avro (row-based, schema evolution)
-    - ORC (columnar, Hive)
-    - CSV (simple, human-readable)
-    - JSON/JSONL
-    - Delta Lake format
-    - Iceberg format
-
-12. **Data partitioning strategy:**
-    - By date (year/month/day)
-    - By category/dimension
-    - By hash
-    - No partitioning (small data)
-
-13. **Data retention policy:**
-    - Keep all data forever
-    - Archive old data (move to cold storage)
-    - Delete after X months/years
-    - Compliance-driven retention
-
-## Data Processing and Transformation
-
-14. **Data processing framework:**
-    - pandas (single machine)
-    - Dask (parallel pandas)
-    - Apache Spark (distributed)
-    - Polars (fast, modern dataframes)
-    - SQL (warehouse-native)
-    - Apache Flink (streaming)
-    - dbt (SQL transformations)
-    - Custom code
-    - Multiple frameworks
-
-15. **Compute platform:**
-    - Local machine (development)
-    - Cloud VMs (EC2, Compute Engine)
-    - Serverless (AWS Lambda, Cloud Functions)
-    - Managed Spark (EMR, Dataproc, Synapse)
-    - Databricks
-    - Snowflake (warehouse compute)
-    - Kubernetes (custom containers)
-    - Multiple platforms
-
-16. **ETL tool (if applicable):**
-    - dbt (SQL transformations)
-    - Apache Airflow (orchestration + code)
-    - Dagster (data orchestration)
-    - Prefect (workflow orchestration)
-    - AWS Glue
-    - Azure Data Factory
-    - Google Dataflow
-    - Custom scripts
-    - None needed
-
-17. **Data quality checks:**
-    - Great Expectations
-    - dbt tests
-    - Custom validation scripts
-    - Soda
-    - Monte Carlo
-    - None (trust source data)
-
-18. **Schema management:**
-    - Schema registry (Confluent, AWS Glue)
-    - Version-controlled schema files
-    - Database schema versioning
-    - Ad-hoc (no formal schema)
-
-## Machine Learning (if applicable)
-
-19. **ML framework:**
-    - scikit-learn (classical ML)
-    - PyTorch (deep learning)
-    - TensorFlow/Keras (deep learning)
-    - XGBoost/LightGBM/CatBoost (gradient boosting)
-    - Hugging Face Transformers (NLP)
-    - spaCy (NLP)
-    - Other: **\_\_\_**
-    - Not applicable
-
-20. **ML use case:**
-    - Classification
-    - Regression
-    - Clustering
-    - Recommendation
-    - NLP (text analysis, generation)
-    - Computer Vision
-    - Time Series Forecasting
-    - Anomaly Detection
-    - Other: **\_\_\_**
-
-21. **Model training infrastructure:**
-    - Local machine (GPU/CPU)
-    - Cloud VMs with GPU (EC2 P/G instances, GCE A2)
-    - SageMaker
-    - Vertex AI
-    - Azure ML
-    - Databricks ML
-    - Lambda Labs / Paperspace
-    - On-premise cluster
-
-22. **Experiment tracking:**
-    - MLflow
-    - Weights and Biases
-    - Neptune.ai
-    - Comet
-    - TensorBoard
-    - SageMaker Experiments
-    - Custom logging
-    - None
-
-23. **Model registry:**
-    - MLflow Model Registry
-    - SageMaker Model Registry
-    - Vertex AI Model Registry
-    - Custom (S3/GCS with metadata)
-    - None
-
-24. **Feature store:**
-    - Feast
-    - Tecton
-    - SageMaker Feature Store
-    - Databricks Feature Store
-    - Vertex AI Feature Store
-    - Custom (database + cache)
-    - Not needed
-
-25. **Hyperparameter tuning:**
-    - Manual tuning
-    - Grid search
-    - Random search
-    - Optuna / Hyperopt (Bayesian optimization)
-    - SageMaker/Vertex AI tuning jobs
-    - Ray Tune
-    - Not needed
-
-26. **Model serving (inference):**
-    - Batch inference (process large datasets)
-    - Real-time API (REST/gRPC)
-    - Streaming inference (Kafka, Kinesis)
-    - Edge deployment (mobile, IoT)
-    - Not applicable (training only)
-
-27. **Model serving platform (if real-time):**
-    - FastAPI + container (self-hosted)
-    - SageMaker Endpoints
-    - Vertex AI Predictions
-    - Azure ML Endpoints
-    - Seldon Core
-    - KServe
-    - TensorFlow Serving
-    - TorchServe
-    - BentoML
-    - Other: **\_\_\_**
-
-28. **Model monitoring (in production):**
-    - Data drift detection
-    - Model performance monitoring
-    - Prediction logging
-    - A/B testing infrastructure
-    - None (not in production yet)
-
-29. **AutoML tools:**
-    - H2O AutoML
-    - Auto-sklearn
-    - TPOT
-    - SageMaker Autopilot
-    - Vertex AI AutoML
-    - Azure AutoML
-    - Not using AutoML
-
-## Orchestration and Workflow
-
-30. **Workflow orchestration:**
-    - Apache Airflow
-    - Prefect
-    - Dagster
-    - Argo Workflows
-    - Kubeflow Pipelines
-    - AWS Step Functions
-    - Azure Data Factory
-    - Google Cloud Composer
-    - dbt Cloud
-    - Cron jobs (simple)
-    - None (manual runs)
-
-31. **Orchestration platform:**
-    - Self-hosted (VMs, K8s)
-    - Managed service (MWAA, Cloud Composer, Prefect Cloud)
-    - Serverless
-    - Multiple platforms
-
-32. **Job scheduling:**
-    - Time-based (daily, hourly)
-    - Event-driven (S3 upload, database change)
-    - Manual trigger
-    - Continuous (always running)
-
-33. **Dependency management:**
-    - DAG-based (upstream/downstream tasks)
-    - Data-driven (task runs when data available)
-    - Simple sequential
-    - None (independent tasks)
-
-## Data Analytics and Visualization
-
-34. **BI/Visualization tool:**
-    - Tableau
-    - Power BI
-    - Looker / Looker Studio
-    - Metabase
-    - Superset
-    - Redash
-    - Grafana
-    - Custom dashboards (Plotly Dash, Streamlit)
-    - Jupyter notebooks
-    - None needed
-
-35. **Reporting frequency:**
-    - Real-time dashboards
-    - Daily reports
-    - Weekly/Monthly reports
-    - Ad-hoc queries
-    - Multiple frequencies
-
-36. **Query interface:**
-    - SQL (direct database queries)
-    - BI tool interface
-    - API (programmatic access)
-    - Notebooks
-    - Multiple interfaces
-
-## Data Governance and Security
-
-37. **Data catalog:**
-    - Amundsen
-    - DataHub
-    - AWS Glue Data Catalog
-    - Azure Purview
-    - Alation
-    - Collibra
-    - None (small team)
-
-38. **Data lineage tracking:**
-    - Automated (DataHub, Amundsen)
-    - Manual documentation
-    - Not tracked
-
-39. **Access control:**
-    - Row-level security (RLS)
-    - Column-level security
-    - Database/warehouse roles
-    - IAM policies (cloud)
-    - None (internal team only)
-
-40. **PII/Sensitive data handling:**
-    - Encryption at rest
-    - Encryption in transit
-    - Data masking
-    - Tokenization
-    - Compliance requirements (GDPR, HIPAA)
-    - None (no sensitive data)
-
-41. **Data versioning:**
-    - DVC (Data Version Control)
-    - LakeFS
-    - Delta Lake time travel
-    - Git LFS (for small data)
-    - Manual snapshots
-    - None
-
-## Testing and Validation
-
-42. **Data testing:**
-    - Unit tests (transformation logic)
-    - Integration tests (end-to-end pipeline)
-    - Data quality tests
-    - Schema validation
-    - Manual validation
-    - None
-
-43. **ML model testing (if applicable):**
-    - Unit tests (code)
-    - Model validation (held-out test set)
-    - Performance benchmarks
-    - Fairness/bias testing
-    - A/B testing in production
-    - None
-
-## Deployment and CI/CD
-
-44. **Deployment strategy:**
-    - GitOps (version-controlled config)
-    - Manual deployment
-    - CI/CD pipeline (GitHub Actions, GitLab CI)
-    - Platform-specific (SageMaker, Vertex AI)
-    - Terraform/IaC
-
-45. **Environment separation:**
-    - Dev / Staging / Production
-    - Dev / Production only
-    - Single environment
-
-46. **Containerization:**
-    - Docker
-    - Not containerized (native environments)
-
-## Monitoring and Observability
-
-47. **Pipeline monitoring:**
-    - Orchestrator built-in (Airflow UI, Prefect)
-    - Custom dashboards
-    - Alerts on failures
-    - Data quality monitoring
-    - None
-
-48. **Performance monitoring:**
-    - Query performance (slow queries)
-    - Job duration tracking
-    - Cost monitoring (cloud spend)
-    - Resource utilization
-    - None
-
-49. **Alerting:**
-    - Email
-    - Slack/Discord
-    - PagerDuty
-    - Built-in orchestrator alerts
-    - None
-
-## Cost Optimization
-
-50. **Cost considerations:**
-    - Optimize warehouse queries
-    - Auto-scaling clusters
-    - Spot/preemptible instances
-    - Storage tiering (hot/cold)
-    - Cost monitoring dashboards
-    - Not a priority
-
-## Collaboration and Documentation
-
-51. **Team collaboration:**
-    - Git for code
-    - Shared notebooks (JupyterHub, Databricks)
-    - Documentation wiki
-    - Slack/communication tools
-    - Pair programming
-
-52. **Documentation approach:**
-    - README files
-    - Docstrings in code
-    - Notebooks with markdown
-    - Confluence/Notion
-    - Data catalog (self-documenting)
-    - Minimal
-
-53. **Code review process:**
-    - Pull requests (required)
-    - Peer review (optional)
-    - No formal review
-
-## Performance and Scale
-
-54. **Performance requirements:**
-    - Near real-time (< 1 minute latency)
-    - Batch (hours acceptable)
-    - Interactive queries (< 10 seconds)
-    - No specific requirements
-
-55. **Scalability needs:**
-    - Must scale to 10x data volume
-    - Current scale sufficient
-    - Unknown (future growth)
-
-56. **Query optimization:**
-    - Indexing
-    - Partitioning
-    - Materialized views
-    - Query caching
-    - Not needed (fast enough)

src/modules/bmm/workflows/3-solutioning/project-types/desktop-instructions.md

@@ -0,0 +1,182 @@
+# Desktop Application Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for desktop application architecture decisions.
+The LLM should:
+- Understand the application's purpose and target OS from requirements
+- Balance native performance with development efficiency
+- Consider distribution and update mechanisms
+- Focus on desktop-specific UX patterns
+- Plan for OS-specific integrations
+</critical>
+
+## Framework Selection
+
+**Choose Based on Requirements and Team**
+
+- **Electron**: Web technologies, cross-platform, rapid development
+- **Tauri**: Rust + Web frontend, smaller binaries, better performance
+- **Qt**: C++/Python, native performance, extensive widgets
+- **.NET MAUI/WPF**: Windows-focused, C# teams
+- **SwiftUI/AppKit**: Mac-only, native experience
+- **JavaFX/Swing**: Java teams, enterprise apps
+- **Flutter Desktop**: Dart, consistent cross-platform UI
+
+Don't use Electron for performance-critical apps, or Qt for simple utilities.
+
+## Architecture Pattern
+
+**Application Structure**
+Based on complexity:
+
+- **MVC/MVVM**: For data-driven applications
+- **Component-Based**: For complex UIs
+- **Plugin Architecture**: For extensible apps
+- **Document-Based**: For editors/creators
+
+Match pattern to application type and team experience.
+
+## Native Integration
+
+**OS-Specific Features**
+Based on requirements:
+
+- System tray/menu bar integration
+- File associations and protocol handlers
+- Native notifications
+- OS-specific shortcuts and gestures
+- Dark mode and theme detection
+- Native menus and dialogs
+
+Plan for platform differences in UX expectations.
+
+## Data Management
+
+**Local Data Strategy**
+
+- **SQLite**: For structured data
+- **LevelDB/RocksDB**: For key-value storage
+- **JSON/XML files**: For simple configuration
+- **OS-specific stores**: Windows Registry, macOS Defaults
+
+**Settings and Preferences**
+
+- User vs. application settings
+- Portable vs. installed mode
+- Settings sync across devices
+
+## Window Management
+
+**Multi-Window Strategy**
+
+- Single vs. multi-window architecture
+- Window state persistence
+- Multi-monitor support
+- Workspace/session management
+
+## Performance Optimization
+
+**Desktop Performance**
+
+- Startup time optimization
+- Memory usage monitoring
+- Background task management
+- GPU acceleration usage
+- Native vs. web rendering trade-offs
+
+## Update Mechanism
+
+**Application Updates**
+
+- **Auto-update**: Electron-updater, Sparkle, Squirrel
+- **Store-based**: Mac App Store, Microsoft Store
+- **Manual**: Download from website
+- **Package manager**: Homebrew, Chocolatey, APT/YUM
+
+Consider code signing and notarization requirements.
+
+## Security Considerations
+
+**Desktop Security**
+
+- Code signing certificates
+- Secure storage for credentials
+- Process isolation
+- Network security
+- Input validation
+- Automatic security updates
+
+## Distribution Strategy
+
+**Packaging and Installation**
+
+- **Installers**: MSI, DMG, DEB/RPM
+- **Portable**: Single executable
+- **App stores**: Platform stores
+- **Package managers**: OS-specific
+
+Consider installation permissions and user experience.
+
+## IPC and Extensions
+
+**Inter-Process Communication**
+
+- Main/renderer process communication (Electron)
+- Plugin/extension system
+- CLI integration
+- Automation/scripting support
+
+## Accessibility
+
+**Desktop Accessibility**
+
+- Screen reader support
+- Keyboard navigation
+- High contrast themes
+- Zoom/scaling support
+- OS accessibility APIs
+
+## Testing Strategy
+
+**Desktop Testing**
+
+- Unit tests for business logic
+- Integration tests for OS interactions
+- UI automation testing
+- Multi-OS testing matrix
+- Performance profiling
+
+## Adaptive Guidance Examples
+
+**For a Development IDE:**
+Focus on performance, plugin system, workspace management, and syntax highlighting.
+
+**For a Media Player:**
+Emphasize codec support, hardware acceleration, media keys, and playlist management.
+
+**For a Business Application:**
+Focus on data grids, reporting, printing, and enterprise integration.
+
+**For a Creative Tool:**
+Emphasize canvas rendering, tool palettes, undo/redo, and file format support.
+
+## Key Principles
+
+1. **Respect platform conventions** - Mac != Windows != Linux
+2. **Optimize startup time** - Desktop users expect instant launch
+3. **Handle offline gracefully** - Desktop != always online
+4. **Integrate with OS** - Use native features appropriately
+5. **Plan distribution early** - Signing/notarization takes time
+
+## Output Format
+
+Document as:
+
+- **Framework**: [Specific framework and version]
+- **Target OS**: [Primary and secondary platforms]
+- **Distribution**: [How users will install]
+- **Update strategy**: [How updates are delivered]
+
+Focus on desktop-specific architectural decisions.

src/modules/bmm/workflows/3-solutioning/project-types/desktop-questions.md

@@ -1,299 +0,0 @@
-# Desktop Application Architecture Questions
-
-## Framework and Platform
-
-1. **Primary framework:**
-   - Electron (JavaScript/TypeScript, web tech, cross-platform)
-   - Tauri (Rust backend, web frontend, lightweight)
-   - .NET MAUI (C#, cross-platform, native UI)
-   - Qt (C++/Python, cross-platform, native)
-   - Flutter Desktop (Dart, cross-platform)
-   - JavaFX (Java, cross-platform)
-   - Swift/SwiftUI (macOS only)
-   - WPF/WinUI 3 (Windows only, C#)
-   - GTK (C/Python, Linux-focused)
-   - Other: **\_\_\_**
-
-2. **Target platforms:**
-   - Windows only
-   - macOS only
-   - Linux only
-   - Windows + macOS
-   - Windows + macOS + Linux (full cross-platform)
-   - Specific Linux distros: **\_\_\_**
-
-3. **UI approach:**
-   - Native UI (platform-specific controls)
-   - Web-based UI (HTML/CSS/JS in Electron/Tauri)
-   - Custom-drawn UI (Canvas/OpenGL)
-   - Hybrid (native shell + web content)
-
-4. **Frontend framework (if web-based UI):**
-   - React
-   - Vue
-   - Svelte
-   - Angular
-   - Vanilla JS
-   - Other: **\_\_\_**
-
-## Architecture
-
-5. **Application architecture:**
-   - Single-process (all in one)
-   - Multi-process (main + renderer processes like Electron)
-   - Multi-threaded (background workers)
-   - Plugin-based (extensible architecture)
-
-6. **Backend/Business logic:**
-   - Embedded in app (monolithic)
-   - Separate local service
-   - Connects to remote API
-   - Hybrid (local + remote)
-
-7. **Database/Data storage:**
-   - SQLite (local embedded database)
-   - IndexedDB (if web-based)
-   - File-based storage (JSON, custom)
-   - LevelDB/RocksDB
-   - Remote database only
-   - No persistence needed
-   - Other: **\_\_\_**
-
-## System Integration
-
-8. **Operating system integration needs:**
-   - File system access (read/write user files)
-   - System tray/menu bar icon
-   - Native notifications
-   - Keyboard shortcuts (global hotkeys)
-   - Clipboard integration
-   - Drag-and-drop support
-   - Context menu integration
-   - File type associations
-   - URL scheme handling (deep linking)
-   - System dialogs (file picker, alerts)
-   - None needed (basic app)
-
-9. **Hardware access:**
-   - Camera/Microphone
-   - USB devices
-   - Bluetooth
-   - Printers
-   - Scanners
-   - Serial ports
-   - GPU (for rendering/compute)
-   - None needed
-
-10. **System permissions required:**
-    - Accessibility API (screen reading, input simulation)
-    - Location services
-    - Calendar/Contacts access
-    - Network monitoring
-    - Screen recording
-    - Full disk access
-    - None (sandboxed app)
-
-## Updates and Distribution
-
-11. **Auto-update mechanism:**
-    - Electron's autoUpdater
-    - Squirrel (Windows/Mac)
-    - Sparkle (macOS)
-    - Custom update server
-    - App store updates only
-    - Manual download/install
-    - No updates (fixed version)
-
-12. **Distribution method:**
-    - Microsoft Store (Windows)
-    - Mac App Store
-    - Snap Store (Linux)
-    - Flatpak (Linux)
-    - Homebrew (macOS/Linux)
-    - Direct download from website
-    - Enterprise deployment (MSI, PKG)
-    - Multiple channels
-
-13. **Code signing:**
-    - Yes - Windows (Authenticode)
-    - Yes - macOS (Apple Developer)
-    - Yes - both
-    - No (development/internal only)
-
-14. **Notarization (macOS):**
-    - Required (public distribution)
-    - Not needed (internal only)
-
-## Packaging and Installation
-
-15. **Windows installer:**
-    - NSIS
-    - Inno Setup
-    - WiX Toolset (MSI)
-    - Squirrel.Windows
-    - MSIX (Windows 10+)
-    - Portable (no installer)
-    - Other: **\_\_\_**
-
-16. **macOS installer:**
-    - DMG (drag-to-install)
-    - PKG installer
-    - Mac App Store
-    - Homebrew Cask
-    - Other: **\_\_\_**
-
-17. **Linux packaging:**
-    - AppImage (portable)
-    - Snap
-    - Flatpak
-    - .deb (Debian/Ubuntu)
-    - .rpm (Fedora/RHEL)
-    - Tarball
-    - AUR (Arch)
-    - Multiple formats
-
-## Configuration and Settings
-
-18. **Settings storage:**
-    - OS-specific (Registry on Windows, plist on macOS, config files on Linux)
-    - JSON/YAML config file
-    - SQLite database
-    - Remote/cloud sync
-    - Electron Store
-    - Other: **\_\_\_**
-
-19. **User data location:**
-    - Application Support folder (standard OS location)
-    - User documents folder
-    - Custom location (user selectable)
-    - Cloud storage integration
-
-## Networking
-
-20. **Network connectivity:**
-    - Online-only (requires internet)
-    - Offline-first (works without internet)
-    - Hybrid (enhanced with internet)
-    - No network needed
-
-21. **Backend communication (if applicable):**
-    - REST API
-    - GraphQL
-    - WebSocket
-    - gRPC
-    - Custom protocol
-    - None
-
-## Authentication and Security
-
-22. **Authentication (if applicable):**
-    - OAuth2 (Google, Microsoft, etc.)
-    - Username/password with backend
-    - SSO (enterprise)
-    - OS-level authentication (biometric, Windows Hello)
-    - No authentication needed
-
-23. **Data security:**
-    - Encrypt sensitive data at rest
-    - OS keychain/credential manager
-    - Custom encryption
-    - No sensitive data
-
-24. **Sandboxing:**
-    - Fully sandboxed (Mac App Store requirement)
-    - Partially sandboxed
-    - Not sandboxed (legacy/compatibility)
-
-## Performance and Resources
-
-25. **Performance requirements:**
-    - Lightweight (minimal resource usage)
-    - Moderate (typical desktop app)
-    - Resource-intensive (video editing, 3D, etc.)
-
-26. **Background operation:**
-    - Runs in background/system tray
-    - Active window only
-    - Can minimize to tray
-
-27. **Multi-instance handling:**
-    - Allow multiple instances
-    - Single instance only
-    - Single instance with IPC (communicate between instances)
-
-## Development and Build
-
-28. **Build tooling:**
-    - electron-builder
-    - electron-forge
-    - Tauri CLI
-    - .NET CLI
-    - CMake (for C++/Qt)
-    - Gradle (for Java)
-    - Xcode (for macOS)
-    - Visual Studio (for Windows)
-    - Other: **\_\_\_**
-
-29. **Development environment:**
-    - Cross-platform dev (can build on any OS)
-    - Platform-specific (need macOS for Mac builds, etc.)
-
-30. **CI/CD for builds:**
-    - GitHub Actions
-    - GitLab CI
-    - CircleCI
-    - Azure Pipelines
-    - Custom
-    - Manual builds
-
-## Testing
-
-31. **UI testing approach:**
-    - Spectron (Electron)
-    - Playwright
-    - Selenium
-    - Native UI testing (XCTest, UI Automation)
-    - Manual testing only
-
-32. **End-to-end testing:**
-    - Yes (automated E2E tests)
-    - Limited (smoke tests only)
-    - Manual only
-
-## Additional Features
-
-33. **Internationalization (i18n):**
-    - Multiple languages supported
-    - English only
-    - User-selectable language
-    - OS language detection
-
-34. **Accessibility:**
-    - Full accessibility support (screen readers, keyboard nav)
-    - Basic accessibility
-    - Not a priority
-
-35. **Crash reporting:**
-    - Sentry
-    - BugSnag
-    - Crashpad (for native crashes)
-    - Custom reporting
-    - None
-
-36. **Analytics/Telemetry:**
-    - Google Analytics
-    - Mixpanel
-    - PostHog
-    - Custom telemetry
-    - No telemetry (privacy-focused)
-
-37. **Licensing/DRM (if commercial):**
-    - License key validation
-    - Hardware-locked licenses
-    - Subscription validation
-    - None (free/open-source)
-
-38. **Plugin/Extension system:**
-    - Yes (user can install plugins)
-    - No (monolithic app)
-    - Planned for future

src/modules/bmm/workflows/3-solutioning/project-types/embedded-instructions.md

@@ -0,0 +1,191 @@
+# Embedded/IoT System Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for embedded/IoT architecture decisions.
+The LLM should:
+- Understand hardware constraints and real-time requirements
+- Guide platform and RTOS selection based on use case
+- Consider power consumption and resource limitations
+- Balance features with memory/processing constraints
+- Focus on reliability and update mechanisms
+</critical>
+
+## Hardware Platform Selection
+
+**Choose Based on Requirements**
+
+- **Microcontroller**: For simple, low-power, real-time tasks
+- **SoC/SBC**: For complex processing, Linux-capable
+- **FPGA**: For parallel processing, custom logic
+- **Hybrid**: MCU + application processor
+
+Consider power budget, processing needs, and peripheral requirements.
+
+## Operating System/RTOS
+
+**OS Selection**
+Based on complexity:
+
+- **Bare Metal**: Simple control loops, minimal overhead
+- **RTOS**: FreeRTOS, Zephyr for real-time requirements
+- **Embedded Linux**: Complex applications, networking
+- **Android Things/Windows IoT**: For specific ecosystems
+
+Don't use Linux for battery-powered sensors, or bare metal for complex networking.
+
+## Development Framework
+
+**Language and Tools**
+
+- **C/C++**: Maximum control, minimal overhead
+- **Rust**: Memory safety, modern tooling
+- **MicroPython/CircuitPython**: Rapid prototyping
+- **Arduino**: Beginner-friendly, large community
+- **Platform-specific SDKs**: ESP-IDF, STM32Cube
+
+Match to team expertise and performance requirements.
+
+## Communication Protocols
+
+**Connectivity Strategy**
+Based on use case:
+
+- **Local**: I2C, SPI, UART for sensor communication
+- **Wireless**: WiFi, Bluetooth, LoRa, Zigbee, cellular
+- **Industrial**: Modbus, CAN bus, MQTT
+- **Cloud**: HTTPS, MQTT, CoAP
+
+Consider range, power consumption, and data rates.
+
+## Power Management
+
+**Power Optimization**
+
+- Sleep modes and wake triggers
+- Dynamic frequency scaling
+- Peripheral power management
+- Battery monitoring and management
+- Energy harvesting considerations
+
+Critical for battery-powered devices.
+
+## Memory Architecture
+
+**Memory Management**
+
+- Static vs. dynamic allocation
+- Flash wear leveling
+- RAM optimization techniques
+- External storage options
+- Bootloader and OTA partitioning
+
+Plan memory layout early - hard to change later.
+
+## Firmware Architecture
+
+**Code Organization**
+
+- HAL (Hardware Abstraction Layer)
+- Modular driver architecture
+- Task/thread design
+- Interrupt handling strategy
+- State machine implementation
+
+## Update Mechanism
+
+**OTA Updates**
+
+- Update delivery method
+- Rollback capability
+- Differential updates
+- Security and signing
+- Factory reset capability
+
+Plan for field updates from day one.
+
+## Security Architecture
+
+**Embedded Security**
+
+- Secure boot
+- Encrypted storage
+- Secure communication (TLS)
+- Hardware security modules
+- Attack surface minimization
+
+Security is harder to add later.
+
+## Data Management
+
+**Local and Cloud Data**
+
+- Edge processing vs. cloud processing
+- Local storage and buffering
+- Data compression
+- Time synchronization
+- Offline operation handling
+
+## Testing Strategy
+
+**Embedded Testing**
+
+- Unit testing on host
+- Hardware-in-the-loop testing
+- Integration testing
+- Environmental testing
+- Certification requirements
+
+## Debugging and Monitoring
+
+**Development Tools**
+
+- Debug interfaces (JTAG, SWD)
+- Serial console
+- Logic analyzers
+- Remote debugging
+- Field diagnostics
+
+## Production Considerations
+
+**Manufacturing and Deployment**
+
+- Provisioning process
+- Calibration requirements
+- Production testing
+- Device identification
+- Configuration management
+
+## Adaptive Guidance Examples
+
+**For a Smart Sensor:**
+Focus on ultra-low power, wireless communication, and edge processing.
+
+**For an Industrial Controller:**
+Emphasize real-time performance, reliability, safety systems, and industrial protocols.
+
+**For a Consumer IoT Device:**
+Focus on user experience, cloud integration, OTA updates, and cost optimization.
+
+**For a Wearable:**
+Emphasize power efficiency, small form factor, BLE, and sensor fusion.
+
+## Key Principles
+
+1. **Design for constraints** - Memory, power, and processing are limited
+2. **Plan for failure** - Hardware fails, design for recovery
+3. **Security from the start** - Retrofitting is difficult
+4. **Test on real hardware** - Simulation has limits
+5. **Design for production** - Prototype != product
+
+## Output Format
+
+Document as:
+
+- **Platform**: [MCU/SoC selection with part numbers]
+- **OS/RTOS**: [Operating system choice]
+- **Connectivity**: [Communication protocols and interfaces]
+- **Power**: [Power budget and management strategy]
+
+Focus on hardware/software co-design decisions.

src/modules/bmm/workflows/3-solutioning/project-types/embedded-questions.md

@@ -1,118 +0,0 @@
-# Embedded System Architecture Questions
-
-## Hardware Platform
-
-1. **Microcontroller/SoC:**
-   - ESP32 (WiFi/BLE, popular)
-   - ESP8266 (WiFi, budget)
-   - STM32 (ARM Cortex-M, powerful)
-   - Arduino (AVR, beginner-friendly)
-   - Raspberry Pi Pico (RP2040)
-   - Other: **\_\_\_**
-
-2. **RTOS or Bare Metal:**
-   - FreeRTOS (popular, tasks/queues)
-   - Zephyr RTOS
-   - Bare metal (no OS, full control)
-   - Arduino framework
-   - ESP-IDF
-   - Other: **\_\_\_**
-
-3. **Programming language:**
-   - C
-   - C++
-   - MicroPython
-   - Arduino (C++)
-   - Rust
-
-## Communication
-
-4. **Primary communication protocol:**
-   - MQTT (IoT messaging)
-   - HTTP/HTTPS (REST APIs)
-   - WebSockets
-   - CoAP
-   - Custom binary protocol
-
-5. **Local communication (peripherals):**
-   - UART (serial)
-   - I2C (sensors)
-   - SPI (high-speed devices)
-   - GPIO (simple digital)
-   - Analog (ADC)
-
-6. **Wireless connectivity:**
-   - WiFi
-   - Bluetooth Classic
-   - BLE (Bluetooth Low Energy)
-   - LoRa/LoRaWAN
-   - Zigbee
-   - None (wired only)
-
-## Cloud/Backend
-
-7. **Cloud platform:** (if IoT project)
-   - AWS IoT Core
-   - Azure IoT Hub
-   - Google Cloud IoT
-   - Custom MQTT broker
-   - ThingsBoard
-   - None (local only)
-
-## Power
-
-8. **Power source:**
-   - USB powered (5V constant)
-   - Battery (need power management)
-   - AC adapter
-   - Solar
-   - Other: **\_\_\_**
-
-9. **Low power mode needed:**
-   - Yes (battery-powered, deep sleep)
-   - No (always powered)
-
-## Storage
-
-10. **Data persistence:**
-    - EEPROM (small config)
-    - Flash (larger data)
-    - SD card
-    - None needed
-    - Cloud only
-
-## Updates
-
-11. **Firmware update strategy:**
-    - OTA (Over-The-Air via WiFi)
-    - USB/Serial upload
-    - SD card
-    - No updates (fixed firmware)
-
-## Sensors/Actuators
-
-12. **Sensors used:** (list)
-    - Temperature (DHT22, DS18B20, etc.)
-    - Humidity
-    - Motion (PIR, accelerometer)
-    - Light (LDR, photodiode)
-    - Other: **\_\_\_**
-
-13. **Actuators used:** (list)
-    - LEDs
-    - Motors (DC, servo, stepper)
-    - Relays
-    - Display (LCD, OLED)
-    - Other: **\_\_\_**
-
-## Real-Time Constraints
-
-14. **Hard real-time requirements:**
-    - Yes (must respond within X ms, critical)
-    - Soft real-time (best effort)
-    - No timing constraints
-
-15. **Interrupt-driven or polling:**
-    - Interrupts (responsive)
-    - Polling (simpler)
-    - Mix

src/modules/bmm/workflows/3-solutioning/project-types/extension-instructions.md

@@ -0,0 +1,193 @@
+# Browser/Editor Extension Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for extension architecture decisions.
+The LLM should:
+- Understand the host platform (browser, VS Code, IDE, etc.)
+- Focus on extension-specific constraints and APIs
+- Consider distribution through official stores
+- Balance functionality with performance impact
+- Plan for permission models and security
+</critical>
+
+## Extension Type and Platform
+
+**Identify Target Platform**
+
+- **Browser**: Chrome, Firefox, Safari, Edge
+- **VS Code**: Most popular code editor
+- **JetBrains IDEs**: IntelliJ, WebStorm, etc.
+- **Other Editors**: Sublime, Atom, Vim, Emacs
+- **Application-specific**: Figma, Sketch, Adobe
+
+Each platform has unique APIs and constraints.
+
+## Architecture Pattern
+
+**Extension Architecture**
+Based on platform:
+
+- **Browser**: Content scripts, background workers, popup UI
+- **VS Code**: Extension host, language server, webview
+- **IDE**: Plugin architecture, service providers
+- **Application**: Native API, JavaScript bridge
+
+Follow platform-specific patterns and guidelines.
+
+## Manifest and Configuration
+
+**Extension Declaration**
+
+- Manifest version and compatibility
+- Permission requirements
+- Activation events
+- Command registration
+- Context menu integration
+
+Request minimum necessary permissions for user trust.
+
+## Communication Architecture
+
+**Inter-Component Communication**
+
+- Message passing between components
+- Storage sync across instances
+- Native messaging (if needed)
+- WebSocket for external services
+
+Design for async communication patterns.
+
+## UI Integration
+
+**User Interface Approach**
+
+- **Popup/Panel**: For quick interactions
+- **Sidebar**: For persistent tools
+- **Content Injection**: Modify existing UI
+- **Custom Pages**: Full page experiences
+- **Statusbar**: For ambient information
+
+Match UI to user workflow and platform conventions.
+
+## State Management
+
+**Data Persistence**
+
+- Local storage for user preferences
+- Sync storage for cross-device
+- IndexedDB for large data
+- File system access (if permitted)
+
+Consider storage limits and sync conflicts.
+
+## Performance Optimization
+
+**Extension Performance**
+
+- Lazy loading of features
+- Minimal impact on host performance
+- Efficient DOM manipulation
+- Memory leak prevention
+- Background task optimization
+
+Extensions must not degrade host application performance.
+
+## Security Considerations
+
+**Extension Security**
+
+- Content Security Policy
+- Input sanitization
+- Secure communication
+- API key management
+- User data protection
+
+Follow platform security best practices.
+
+## Development Workflow
+
+**Development Tools**
+
+- Hot reload during development
+- Debugging setup
+- Testing framework
+- Build pipeline
+- Version management
+
+## Distribution Strategy
+
+**Publishing and Updates**
+
+- Official store submission
+- Review process requirements
+- Update mechanism
+- Beta testing channel
+- Self-hosting options
+
+Plan for store review times and policies.
+
+## API Integration
+
+**External Service Communication**
+
+- Authentication methods
+- CORS handling
+- Rate limiting
+- Offline functionality
+- Error handling
+
+## Monetization
+
+**Revenue Model** (if applicable)
+
+- Free with premium features
+- Subscription model
+- One-time purchase
+- Enterprise licensing
+
+Consider platform policies on monetization.
+
+## Testing Strategy
+
+**Extension Testing**
+
+- Unit tests for logic
+- Integration tests with host API
+- Cross-browser/platform testing
+- Performance testing
+- User acceptance testing
+
+## Adaptive Guidance Examples
+
+**For a Password Manager Extension:**
+Focus on security, autofill integration, secure storage, and cross-browser sync.
+
+**For a Developer Tool Extension:**
+Emphasize debugging capabilities, performance profiling, and workspace integration.
+
+**For a Content Blocker:**
+Focus on performance, rule management, whitelist handling, and minimal overhead.
+
+**For a Productivity Extension:**
+Emphasize keyboard shortcuts, quick access, sync, and workflow integration.
+
+## Key Principles
+
+1. **Respect the host** - Don't break or slow down the host application
+2. **Request minimal permissions** - Users are permission-aware
+3. **Fast activation** - Extensions should load instantly
+4. **Fail gracefully** - Handle API changes and errors
+5. **Follow guidelines** - Store policies are strictly enforced
+
+## Output Format
+
+Document as:
+
+- **Platform**: [Specific platform and version support]
+- **Architecture**: [Component structure]
+- **Permissions**: [Required permissions and justification]
+- **Distribution**: [Store and update strategy]
+
+Focus on platform-specific requirements and constraints.

src/modules/bmm/workflows/3-solutioning/project-types/extension-questions.md

@@ -1,374 +0,0 @@
-# Browser Extension Architecture Questions
-
-## Target Browsers
-
-1. **Target browser(s):**
-   - Chrome (most common)
-   - Firefox
-   - Edge (Chromium-based)
-   - Safari
-   - Opera
-   - Brave
-   - Multiple browsers (cross-browser)
-
-2. **Manifest version:**
-   - Manifest V3 (current standard, required for Chrome Web Store)
-   - Manifest V2 (legacy, being phased out)
-   - Both (transition period)
-
-3. **Cross-browser compatibility:**
-   - Chrome/Edge only (same codebase)
-   - Chrome + Firefox (minor differences)
-   - All major browsers (requires polyfills/adapters)
-
-## Extension Type and Architecture
-
-4. **Primary extension type:**
-   - Browser Action (icon in toolbar)
-   - Page Action (icon in address bar, page-specific)
-   - Content Script (runs on web pages)
-   - DevTools Extension (adds features to browser DevTools)
-   - New Tab Override
-   - Bookmarks/History extension
-   - Multiple components
-
-5. **Extension components needed:**
-   - Background script/Service Worker (always running logic)
-   - Content scripts (inject into web pages)
-   - Popup UI (click toolbar icon)
-   - Options page (settings/configuration)
-   - Side panel (persistent panel, MV3)
-   - DevTools page
-   - New Tab page
-
-6. **Content script injection:**
-   - All pages (matches: <all_urls>)
-   - Specific domains (matches: \*.example.com)
-   - User-activated (inject on demand)
-   - Not needed
-
-## UI and Framework
-
-7. **UI framework:**
-   - Vanilla JS (no framework)
-   - React
-   - Vue
-   - Svelte
-   - Preact (lightweight React)
-   - Web Components
-   - Other: **\_\_\_**
-
-8. **Build tooling:**
-   - Webpack
-   - Vite
-   - Rollup
-   - Parcel
-   - esbuild
-   - WXT (extension-specific)
-   - Plasmo (extension framework)
-   - None (plain JS)
-
-9. **CSS framework:**
-   - Tailwind CSS
-   - CSS Modules
-   - Styled Components
-   - Plain CSS
-   - Sass/SCSS
-   - None (minimal styling)
-
-10. **Popup UI:**
-    - Simple (HTML + CSS)
-    - Interactive (full app)
-    - None (no popup)
-
-11. **Options page:**
-    - Simple form (HTML)
-    - Full settings UI (framework-based)
-    - Embedded in popup
-    - None (no settings)
-
-## Permissions
-
-12. **Storage permissions:**
-    - chrome.storage.local (local storage)
-    - chrome.storage.sync (sync across devices)
-    - IndexedDB
-    - None (no data persistence)
-
-13. **Host permissions (access to websites):**
-    - Specific domains only
-    - All URLs (<all_urls>)
-    - ActiveTab only (current tab when clicked)
-    - Optional permissions (user grants on demand)
-
-14. **API permissions needed:**
-    - tabs (query/manipulate tabs)
-    - webRequest (intercept network requests)
-    - cookies
-    - history
-    - bookmarks
-    - downloads
-    - notifications
-    - contextMenus (right-click menu)
-    - clipboardWrite/Read
-    - identity (OAuth)
-    - Other: **\_\_\_**
-
-15. **Sensitive permissions:**
-    - webRequestBlocking (modify requests, requires justification)
-    - declarativeNetRequest (MV3 alternative)
-    - None
-
-## Data and Storage
-
-16. **Data storage:**
-    - chrome.storage.local
-    - chrome.storage.sync (synced across devices)
-    - IndexedDB
-    - localStorage (limited, not recommended)
-    - Remote storage (own backend)
-    - Multiple storage types
-
-17. **Storage size:**
-    - Small (< 100KB)
-    - Medium (100KB - 5MB, storage.sync limit)
-    - Large (> 5MB, need storage.local or IndexedDB)
-
-18. **Data sync:**
-    - Sync across user's devices (chrome.storage.sync)
-    - Local only (storage.local)
-    - Custom backend sync
-
-## Communication
-
-19. **Message passing (internal):**
-    - Content script <-> Background script
-    - Popup <-> Background script
-    - Content script <-> Content script
-    - Not needed
-
-20. **Messaging library:**
-    - Native chrome.runtime.sendMessage
-    - Wrapper library (webext-bridge, etc.)
-    - Custom messaging layer
-
-21. **Backend communication:**
-    - REST API
-    - WebSocket
-    - GraphQL
-    - Firebase/Supabase
-    - None (client-only extension)
-
-## Web Integration
-
-22. **DOM manipulation:**
-    - Read DOM (observe, analyze)
-    - Modify DOM (inject, hide, change elements)
-    - Both
-    - None (no content scripts)
-
-23. **Page interaction method:**
-    - Content scripts (extension context)
-    - Injected scripts (page context, access page variables)
-    - Both (communicate via postMessage)
-
-24. **CSS injection:**
-    - Inject custom styles
-    - Override site styles
-    - None
-
-25. **Network request interception:**
-    - Read requests (webRequest)
-    - Block/modify requests (declarativeNetRequest in MV3)
-    - Not needed
-
-## Background Processing
-
-26. **Background script type (MV3):**
-    - Service Worker (MV3, event-driven, terminates when idle)
-    - Background page (MV2, persistent)
-
-27. **Background tasks:**
-    - Event listeners (tabs, webRequest, etc.)
-    - Periodic tasks (alarms)
-    - Message routing (popup <-> content scripts)
-    - API calls
-    - None
-
-28. **Persistent state (MV3 challenge):**
-    - Store in chrome.storage (service worker can terminate)
-    - Use alarms for periodic tasks
-    - Not applicable (MV2 or stateless)
-
-## Authentication
-
-29. **User authentication:**
-    - OAuth (chrome.identity API)
-    - Custom login (username/password with backend)
-    - API key
-    - No authentication needed
-
-30. **OAuth provider:**
-    - Google
-    - GitHub
-    - Custom OAuth server
-    - Not using OAuth
-
-## Distribution
-
-31. **Distribution method:**
-    - Chrome Web Store (public)
-    - Chrome Web Store (unlisted)
-    - Firefox Add-ons (AMO)
-    - Edge Add-ons Store
-    - Self-hosted (enterprise, sideload)
-    - Multiple stores
-
-32. **Pricing model:**
-    - Free
-    - Freemium (basic free, premium paid)
-    - Paid (one-time purchase)
-    - Subscription
-    - Enterprise licensing
-
-33. **In-extension purchases:**
-    - Via web (redirect to website)
-    - Stripe integration
-    - No purchases
-
-## Privacy and Security
-
-34. **User privacy:**
-    - No data collection
-    - Anonymous analytics
-    - User data collected (with consent)
-    - Data sent to server
-
-35. **Content Security Policy (CSP):**
-    - Default CSP (secure)
-    - Custom CSP (if needed for external scripts)
-
-36. **External scripts:**
-    - None (all code bundled)
-    - CDN scripts (requires CSP relaxation)
-    - Inline scripts (avoid in MV3)
-
-37. **Sensitive data handling:**
-    - Encrypt stored data
-    - Use native credential storage
-    - No sensitive data
-
-## Testing
-
-38. **Testing approach:**
-    - Manual testing (load unpacked)
-    - Unit tests (Jest, Vitest)
-    - E2E tests (Puppeteer, Playwright)
-    - Cross-browser testing
-    - Minimal testing
-
-39. **Test automation:**
-    - Automated tests in CI
-    - Manual testing only
-
-## Updates and Deployment
-
-40. **Update strategy:**
-    - Auto-update (store handles)
-    - Manual updates (enterprise)
-
-41. **Versioning:**
-    - Semantic versioning (1.2.3)
-    - Chrome Web Store version requirements
-
-42. **CI/CD:**
-    - GitHub Actions
-    - GitLab CI
-    - Manual builds/uploads
-    - Web Store API (automated publishing)
-
-## Features
-
-43. **Context menu integration:**
-    - Right-click menu items
-    - Not needed
-
-44. **Omnibox integration:**
-    - Custom omnibox keyword
-    - Not needed
-
-45. **Browser notifications:**
-    - Chrome notifications API
-    - Not needed
-
-46. **Keyboard shortcuts:**
-    - chrome.commands API
-    - Not needed
-
-47. **Clipboard access:**
-    - Read clipboard
-    - Write to clipboard
-    - Not needed
-
-48. **Side panel (MV3):**
-    - Persistent side panel UI
-    - Not needed
-
-49. **DevTools integration:**
-    - Add DevTools panel
-    - Not needed
-
-50. **Internationalization (i18n):**
-    - Multiple languages
-    - English only
-
-## Analytics and Monitoring
-
-51. **Analytics:**
-    - Google Analytics (with privacy considerations)
-    - PostHog
-    - Mixpanel
-    - Custom analytics
-    - None
-
-52. **Error tracking:**
-    - Sentry
-    - Bugsnag
-    - Custom error logging
-    - None
-
-53. **User feedback:**
-    - In-extension feedback form
-    - External form (website)
-    - Email/support
-    - None
-
-## Performance
-
-54. **Performance considerations:**
-    - Minimal memory footprint
-    - Lazy loading
-    - Efficient DOM queries
-    - Not a priority
-
-55. **Bundle size:**
-    - Keep small (< 1MB)
-    - Moderate (1-5MB)
-    - Large (> 5MB, media/assets)
-
-## Compliance and Review
-
-56. **Chrome Web Store review:**
-    - Standard review (automated + manual)
-    - Sensitive permissions (extra scrutiny)
-    - Not yet submitted
-
-57. **Privacy policy:**
-    - Required (collecting data)
-    - Not required (no data collection)
-    - Already prepared
-
-58. **Code obfuscation:**
-    - Minified only
-    - Not allowed (stores require readable code)
-    - Using source maps

src/modules/bmm/workflows/3-solutioning/project-types/extension-template.md

@@ -0,0 +1,67 @@
+# Extension Architecture Document
+
+**Project:** {{project_name}}
+**Platform:** {{target_platform}}
+**Date:** {{date}}
+**Author:** {{user_name}}
+
+## Executive Summary
+
+{{executive_summary}}
+
+## Technology Stack
+
+| Category   | Technology     | Version              | Justification              |
+| ---------- | -------------- | -------------------- | -------------------------- |
+| Platform   | {{platform}}   | {{platform_version}} | {{platform_justification}} |
+| Language   | {{language}}   | {{language_version}} | {{language_justification}} |
+| Build Tool | {{build_tool}} | {{build_version}}    | {{build_justification}}    |
+
+## Extension Architecture
+
+### Manifest Configuration
+
+{{manifest_config}}
+
+### Permission Model
+
+{{permissions_required}}
+
+### Component Architecture
+
+{{component_structure}}
+
+## Communication Architecture
+
+{{communication_patterns}}
+
+## State Management
+
+{{state_management}}
+
+## User Interface
+
+{{ui_architecture}}
+
+## API Integration
+
+{{api_integration}}
+
+## Development Guidelines
+
+{{development_guidelines}}
+
+## Distribution Strategy
+
+{{distribution_strategy}}
+
+## Source Tree
+
+```
+{{source_tree}}
+```
+
+---
+
+_Architecture optimized for {{target_platform}} extension_
+_Generated using BMad Method Solution Architecture workflow_

src/modules/bmm/workflows/3-solutioning/project-types/game-instructions.md

@@ -0,0 +1,225 @@
+# Game Development Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for game project architecture decisions.
+The LLM should:
+- FIRST understand the game type from the GDD (RPG, puzzle, shooter, etc.)
+- Check if engine preference is already mentioned in GDD or by user
+- Adapt architecture heavily based on game type and complexity
+- Consider that each game type has VASTLY different needs
+- Keep beginner-friendly suggestions for those without preferences
+</critical>
+
+## Engine Selection Strategy
+
+**Intelligent Engine Guidance**
+
+First, check if the user has already indicated an engine preference in the GDD or conversation.
+
+If no engine specified, ask directly:
+"Do you have a game engine preference? If you're unsure, I can suggest options based on your [game type] and team experience."
+
+**For Beginners Without Preference:**
+Based on game type, suggest the most approachable option:
+
+- **2D Games**: Godot (free, beginner-friendly) or GameMaker (visual scripting)
+- **3D Games**: Unity (huge community, learning resources)
+- **Web Games**: Phaser (JavaScript) or Godot (exports to web)
+- **Visual Novels**: Ren'Py (purpose-built) or Twine (for text-based)
+- **Mobile Focus**: Unity or Godot (both export well to mobile)
+
+Always explain: "I'm suggesting [Engine] because it's beginner-friendly for [game type] and has [specific advantages]. Other viable options include [alternatives]."
+
+**For Experienced Teams:**
+Let them state their preference, then ensure architecture aligns with engine capabilities.
+
+## Game Type Adaptive Architecture
+
+<critical>
+The architecture MUST adapt to the game type identified in the GDD.
+Load the specific game type considerations and merge with general guidance.
+</critical>
+
+### Architecture by Game Type Examples
+
+**Visual Novel / Text-Based:**
+
+- Focus on narrative data structures, save systems, branching logic
+- Minimal physics/rendering considerations
+- Emphasis on dialogue systems and choice tracking
+- Simple scene management
+
+**RPG:**
+
+- Complex data architecture for stats, items, quests
+- Save system with extensive state
+- Character progression systems
+- Inventory and equipment management
+- World state persistence
+
+**Multiplayer Shooter:**
+
+- Network architecture is PRIMARY concern
+- Client prediction and server reconciliation
+- Anti-cheat considerations
+- Matchmaking and lobby systems
+- Weapon ballistics and hit registration
+
+**Puzzle Game:**
+
+- Level data structures and progression
+- Hint/solution validation systems
+- Minimal networking (unless multiplayer)
+- Focus on content pipeline for level creation
+
+**Roguelike:**
+
+- Procedural generation architecture
+- Run persistence vs. meta progression
+- Seed-based reproducibility
+- Death and restart systems
+
+**MMO/MOBA:**
+
+- Massive multiplayer architecture
+- Database design for persistence
+- Server cluster architecture
+- Real-time synchronization
+- Economy and balance systems
+
+## Core Architecture Decisions
+
+**Determine Based on Game Requirements:**
+
+### Data Architecture
+
+Adapt to game type:
+
+- **Simple Puzzle**: Level data in JSON/XML files
+- **RPG**: Complex relational data, possibly SQLite
+- **Multiplayer**: Server authoritative state
+- **Procedural**: Seed and generation systems
+
+### Multiplayer Architecture (if applicable)
+
+Only discuss if game has multiplayer:
+
+- **Casual Party Game**: P2P might suffice
+- **Competitive**: Dedicated servers required
+- **Turn-Based**: Simple request/response
+- **Real-Time Action**: Complex netcode, interpolation
+
+Skip entirely for single-player games.
+
+### Content Pipeline
+
+Based on team structure and game scope:
+
+- **Solo Dev**: Simple, file-based
+- **Small Team**: Version controlled assets, clear naming
+- **Large Team**: Asset database, automated builds
+
+### Performance Strategy
+
+Varies WILDLY by game type:
+
+- **Mobile Puzzle**: Battery life > raw performance
+- **VR Game**: Consistent 90+ FPS critical
+- **Strategy Game**: CPU optimization for AI/simulation
+- **MMO**: Server scalability primary concern
+
+## Platform-Specific Considerations
+
+**Adapt to Target Platform from GDD:**
+
+- **Mobile**: Touch input, performance constraints, monetization
+- **Console**: Certification requirements, controller input, achievements
+- **PC**: Wide hardware range, modding support potential
+- **Web**: Download size, browser limitations, instant play
+
+## System-Specific Architecture
+
+### For Games with Heavy Systems
+
+**Only include systems relevant to the game type:**
+
+**Physics System** (for physics-based games)
+
+- 2D vs 3D physics engine
+- Deterministic requirements
+- Custom vs. built-in
+
+**AI System** (for games with NPCs/enemies)
+
+- Behavior trees vs. state machines
+- Pathfinding requirements
+- Group behaviors
+
+**Procedural Generation** (for roguelikes, infinite runners)
+
+- Generation algorithms
+- Seed management
+- Content validation
+
+**Inventory System** (for RPGs, survival)
+
+- Item database design
+- Stack management
+- Equipment slots
+
+**Dialogue System** (for narrative games)
+
+- Dialogue tree structure
+- Localization support
+- Voice acting integration
+
+**Combat System** (for action games)
+
+- Damage calculation
+- Hitbox/hurtbox system
+- Combo system
+
+## Development Workflow Optimization
+
+**Based on Team and Scope:**
+
+- **Rapid Prototyping**: Focus on quick iteration
+- **Long Development**: Emphasize maintainability
+- **Live Service**: Built-in analytics and update systems
+- **Jam Game**: Absolute minimum viable architecture
+
+## Adaptive Guidance Framework
+
+When processing game requirements:
+
+1. **Identify Game Type** from GDD
+2. **Determine Complexity Level**:
+   - Simple (jam game, prototype)
+   - Medium (indie release)
+   - Complex (commercial, multiplayer)
+3. **Check Engine Preference** or guide selection
+4. **Load Game-Type Specific Needs**
+5. **Merge with Platform Requirements**
+6. **Output Focused Architecture**
+
+## Key Principles
+
+1. **Game type drives architecture** - RPG != Puzzle != Shooter
+2. **Don't over-engineer** - Match complexity to scope
+3. **Prototype the core loop first** - Architecture serves gameplay
+4. **Engine choice affects everything** - Align architecture with engine
+5. **Performance requirements vary** - Mobile puzzle != PC MMO
+
+## Output Format
+
+Structure decisions as:
+
+- **Engine**: [Specific engine and version, with rationale for beginners]
+- **Core Systems**: [Only systems needed for this game type]
+- **Architecture Pattern**: [Appropriate for game complexity]
+- **Platform Optimizations**: [Specific to target platforms]
+- **Development Pipeline**: [Scaled to team size]
+
+IMPORTANT: Focus on architecture that enables the specific game type's core mechanics and requirements. Don't include systems the game doesn't need.

src/modules/bmm/workflows/3-solutioning/project-types/game-questions.md

@@ -1,133 +0,0 @@
-# Game Architecture Questions
-
-## Engine and Platform
-
-1. **Game engine:**
-   - Unity (C#, versatile, large ecosystem)
-   - Unreal Engine (C++, AAA graphics)
-   - Godot (GDScript/C#, open-source)
-   - Custom engine
-   - Other: **\_\_\_**
-
-2. **Target platforms:**
-   - PC (Windows, Mac, Linux)
-   - Mobile (iOS, Android)
-   - Console (Xbox, PlayStation, Switch)
-   - Web (WebGL)
-   - Mix: **\_\_\_**
-
-3. **2D or 3D:**
-   - 2D
-   - 3D
-   - 2.5D (3D with 2D gameplay)
-
-## Architecture Pattern
-
-4. **Core architecture:**
-   - ECS (Entity Component System) - Unity DOTS, Bevy
-   - OOP (Object-Oriented) - Unity MonoBehaviours, Unreal Actors
-   - Data-Oriented Design
-   - Mix
-
-5. **Scene structure:**
-   - Single scene (load/unload prefabs)
-   - Multi-scene (additive loading)
-   - Scene per level
-
-## Multiplayer (if applicable)
-
-6. **Multiplayer type:**
-   - Single-player only
-   - Local multiplayer (same device/splitscreen)
-   - Online multiplayer
-   - Both local + online
-
-7. **If online multiplayer - networking:**
-   - Photon (popular, managed)
-   - Mirror (Unity, open-source)
-   - Netcode for GameObjects (Unity, official)
-   - Unreal Replication
-   - Custom netcode
-   - Other: **\_\_\_**
-
-8. **Multiplayer architecture:**
-   - Client-Server (authoritative server)
-   - Peer-to-Peer
-   - Dedicated servers
-   - Listen server (player hosts)
-
-9. **Backend for multiplayer:**
-   - PlayFab (Microsoft, game backend)
-   - Nakama (open-source game server)
-   - GameSparks (AWS)
-   - Firebase
-   - Custom backend
-
-## Save System
-
-10. **Save/persistence:**
-    - Local only (PlayerPrefs, file)
-    - Cloud save (Steam Cloud, PlayFab)
-    - Both local + cloud sync
-    - No saves needed
-
-## Monetization (if applicable)
-
-11. **Monetization model:**
-    - Paid (one-time purchase)
-    - Free-to-play + IAP
-    - Free-to-play + Ads
-    - Subscription
-    - None (hobby/portfolio)
-
-12. **If IAP - platform:**
-    - Unity IAP (cross-platform)
-    - Steam microtransactions
-    - Mobile stores (App Store, Google Play)
-    - Custom (virtual currency)
-
-13. **If Ads:**
-    - Unity Ads
-    - AdMob (Google)
-    - IronSource
-    - Other: **\_\_\_**
-
-## Assets
-
-14. **Asset pipeline:**
-    - Unity Asset Bundles
-    - Unreal Pak files
-    - Addressables (Unity)
-    - Streaming from CDN
-    - All assets in build
-
-15. **Art creation tools:**
-    - Blender (3D modeling)
-    - Maya/3DS Max
-    - Photoshop (textures)
-    - Substance (materials)
-    - Aseprite (pixel art)
-    - Other: **\_\_\_**
-
-## Analytics and LiveOps
-
-16. **Analytics:**
-    - Unity Analytics
-    - GameAnalytics
-    - Firebase Analytics
-    - PlayFab Analytics
-    - None
-
-17. **LiveOps/Events:**
-    - Remote config (Unity, Firebase)
-    - In-game events
-    - Season passes
-    - None (fixed content)
-
-## Audio
-
-18. **Audio middleware:**
-    - Unity Audio (built-in)
-    - FMOD
-    - Wwise
-    - Simple (no middleware)

src/modules/bmm/workflows/3-solutioning/project-types/game-template.md

@@ -0,0 +1,283 @@
+# Game Architecture Document
+
+**Project:** {{project_name}}
+**Game Type:** {{game_type}}
+**Platform(s):** {{target_platforms}}
+**Date:** {{date}}
+**Author:** {{user_name}}
+
+## Executive Summary
+
+{{executive_summary}}
+
+<critical>
+This architecture adapts to {{game_type}} requirements.
+Sections are included/excluded based on game needs.
+</critical>
+
+## 1. Core Technology Decisions
+
+### 1.1 Essential Technology Stack
+
+| Category    | Technology      | Version              | Justification              |
+| ----------- | --------------- | -------------------- | -------------------------- |
+| Game Engine | {{game_engine}} | {{engine_version}}   | {{engine_justification}}   |
+| Language    | {{language}}    | {{language_version}} | {{language_justification}} |
+| Platform(s) | {{platforms}}   | -                    | {{platform_justification}} |
+
+### 1.2 Game-Specific Technologies
+
+<intent>
+Only include rows relevant to this game type:
+- Physics: Only for physics-based games
+- Networking: Only for multiplayer games
+- AI: Only for games with NPCs/enemies
+- Procedural: Only for roguelikes/procedural games
+</intent>
+
+{{game_specific_tech_table}}
+
+## 2. Architecture Pattern
+
+### 2.1 High-Level Architecture
+
+{{architecture_pattern}}
+
+**Pattern Justification for {{game_type}}:**
+{{pattern_justification}}
+
+### 2.2 Code Organization Strategy
+
+{{code_organization}}
+
+## 3. Core Game Systems
+
+<intent>
+This section should be COMPLETELY different based on game type:
+- Visual Novel: Dialogue system, save states, branching
+- RPG: Stats, inventory, quests, progression
+- Puzzle: Level data, hint system, solution validation
+- Shooter: Weapons, damage, physics
+- Racing: Vehicle physics, track system, lap timing
+- Strategy: Unit management, resource system, AI
+</intent>
+
+### 3.1 Core Game Loop
+
+{{core_game_loop}}
+
+### 3.2 Primary Game Systems
+
+{{#for_game_type}}
+Include ONLY systems this game needs
+{{/for_game_type}}
+
+{{primary_game_systems}}
+
+## 4. Data Architecture
+
+### 4.1 Data Management Strategy
+
+<intent>
+Adapt to game data needs:
+- Simple puzzle: JSON level files
+- RPG: Complex relational data
+- Multiplayer: Server-authoritative state
+- Roguelike: Seed-based generation
+</intent>
+
+{{data_management}}
+
+### 4.2 Save System
+
+{{save_system}}
+
+### 4.3 Content Pipeline
+
+{{content_pipeline}}
+
+## 5. Scene/Level Architecture
+
+<intent>
+Structure varies by game type:
+- Linear: Sequential level loading
+- Open World: Streaming and chunks
+- Stage-based: Level selection and unlocking
+- Procedural: Generation pipeline
+</intent>
+
+{{scene_architecture}}
+
+## 6. Gameplay Implementation
+
+<intent>
+ONLY include subsections relevant to the game.
+A racing game doesn't need an inventory system.
+A puzzle game doesn't need combat mechanics.
+</intent>
+
+{{gameplay_systems}}
+
+## 7. Presentation Layer
+
+<intent>
+Adapt to visual style:
+- 3D: Rendering pipeline, lighting, LOD
+- 2D: Sprite management, layers
+- Text: Minimal visual architecture
+- Hybrid: Both 2D and 3D considerations
+</intent>
+
+### 7.1 Visual Architecture
+
+{{visual_architecture}}
+
+### 7.2 Audio Architecture
+
+{{audio_architecture}}
+
+### 7.3 UI/UX Architecture
+
+{{ui_architecture}}
+
+## 8. Input and Controls
+
+{{input_controls}}
+
+{{#if_multiplayer}}
+
+## 9. Multiplayer Architecture
+
+<critical>
+Only for games with multiplayer features
+</critical>
+
+### 9.1 Network Architecture
+
+{{network_architecture}}
+
+### 9.2 State Synchronization
+
+{{state_synchronization}}
+
+### 9.3 Matchmaking and Lobbies
+
+{{matchmaking}}
+
+### 9.4 Anti-Cheat Strategy
+
+{{anticheat}}
+{{/if_multiplayer}}
+
+## 10. Platform Optimizations
+
+<intent>
+Platform-specific considerations:
+- Mobile: Touch controls, battery, performance
+- Console: Achievements, controllers, certification
+- PC: Wide hardware range, settings
+- Web: Download size, browser compatibility
+</intent>
+
+{{platform_optimizations}}
+
+## 11. Performance Strategy
+
+### 11.1 Performance Targets
+
+{{performance_targets}}
+
+### 11.2 Optimization Approach
+
+{{optimization_approach}}
+
+## 12. Asset Pipeline
+
+### 12.1 Asset Workflow
+
+{{asset_workflow}}
+
+### 12.2 Asset Budget
+
+<intent>
+Adapt to platform and game type:
+- Mobile: Strict size limits
+- Web: Download optimization
+- Console: Memory constraints
+- PC: Balance quality vs. performance
+</intent>
+
+{{asset_budget}}
+
+## 13. Source Tree
+
+```
+{{source_tree}}
+```
+
+**Key Directories:**
+{{key_directories}}
+
+## 14. Development Guidelines
+
+### 14.1 Coding Standards
+
+{{coding_standards}}
+
+### 14.2 Engine-Specific Best Practices
+
+{{engine_best_practices}}
+
+## 15. Build and Deployment
+
+### 15.1 Build Configuration
+
+{{build_configuration}}
+
+### 15.2 Distribution Strategy
+
+{{distribution_strategy}}
+
+## 16. Testing Strategy
+
+<intent>
+Testing needs vary by game:
+- Multiplayer: Network testing, load testing
+- Procedural: Seed testing, generation validation
+- Physics: Determinism testing
+- Narrative: Story branch testing
+</intent>
+
+{{testing_strategy}}
+
+## 17. Key Architecture Decisions
+
+### Decision Records
+
+{{architecture_decisions}}
+
+### Risk Mitigation
+
+{{risk_mitigation}}
+
+{{#if_complex_project}}
+
+## 18. Specialist Considerations
+
+<intent>
+Only for complex projects needing specialist input
+</intent>
+
+{{specialist_notes}}
+{{/if_complex_project}}
+
+---
+
+## Implementation Roadmap
+
+{{implementation_roadmap}}
+
+---
+
+_Architecture optimized for {{game_type}} game on {{platforms}}_
+_Generated using BMad Method Solution Architecture workflow_

src/modules/bmm/workflows/3-solutioning/project-types/infra-questions.md

@@ -1,484 +0,0 @@
-# Infrastructure/DevOps Tool Architecture Questions
-
-## Tool Type
-
-1. **Primary tool category:**
-   - Infrastructure as Code (IaC) module/provider
-   - Kubernetes Operator
-   - CI/CD plugin/action
-   - Monitoring/Observability tool
-   - Configuration management tool
-   - Deployment automation tool
-   - GitOps tool
-   - Security/Compliance scanner
-   - Cost optimization tool
-   - Multi-tool platform
-
-## Infrastructure as Code (IaC)
-
-2. **IaC platform (if applicable):**
-   - Terraform
-   - Pulumi
-   - CloudFormation (AWS)
-   - Bicep (Azure)
-   - CDK (AWS, TypeScript/Python)
-   - CDKTF (Terraform with CDK)
-   - Ansible
-   - Chef
-   - Puppet
-   - Not applicable
-
-3. **IaC language:**
-   - HCL (Terraform)
-   - TypeScript (Pulumi, CDK)
-   - Python (Pulumi, CDK)
-   - Go (Pulumi)
-   - YAML (CloudFormation, Ansible)
-   - JSON
-   - Domain-specific language
-   - Other: **\_\_\_**
-
-4. **Terraform specifics (if applicable):**
-   - Terraform module (reusable component)
-   - Terraform provider (new resource types)
-   - Terraform backend (state storage)
-   - Not using Terraform
-
-5. **Target cloud platforms:**
-   - AWS
-   - Azure
-   - Google Cloud
-   - Multi-cloud
-   - On-premise (VMware, OpenStack)
-   - Hybrid cloud
-   - Kubernetes (cloud-agnostic)
-
-## Kubernetes Operator (if applicable)
-
-6. **Operator framework:**
-   - Operator SDK (Go)
-   - Kubebuilder (Go)
-   - KUDO
-   - Kopf (Python)
-   - Java Operator SDK
-   - Metacontroller
-   - Custom (raw client-go)
-   - Not applicable
-
-7. **Operator type:**
-   - Application operator (manage app lifecycle)
-   - Infrastructure operator (manage resources)
-   - Data operator (databases, queues)
-   - Security operator
-   - Other: **\_\_\_**
-
-8. **Custom Resource Definitions (CRDs):**
-   - Define new CRDs
-   - Use existing CRDs
-   - Multiple CRDs
-
-9. **Operator scope:**
-   - Namespace-scoped
-   - Cluster-scoped
-   - Both
-
-10. **Reconciliation pattern:**
-    - Level-based (check desired vs actual state)
-    - Edge-triggered (react to changes)
-    - Hybrid
-
-## CI/CD Integration
-
-11. **CI/CD platform (if plugin/action):**
-    - GitHub Actions
-    - GitLab CI
-    - Jenkins
-    - CircleCI
-    - Azure DevOps
-    - Bitbucket Pipelines
-    - Drone CI
-    - Tekton
-    - Argo Workflows
-    - Not applicable
-
-12. **Plugin type (if CI/CD plugin):**
-    - Build step
-    - Test step
-    - Deployment step
-    - Security scan
-    - Notification
-    - Custom action
-    - Not applicable
-
-13. **GitHub Action specifics (if applicable):**
-    - JavaScript action
-    - Docker container action
-    - Composite action (reusable workflow)
-    - Not using GitHub Actions
-
-## Configuration and State Management
-
-14. **Configuration approach:**
-    - Configuration files (YAML, JSON, HCL)
-
-- Environment variables
-- Command-line flags
-- API-based configuration
-- Multiple methods
-
-15. **State management:**
-    - Stateless (idempotent operations)
-    - Local state file
-    - Remote state (S3, Consul, Terraform Cloud)
-    - Database state
-    - Kubernetes ConfigMaps/Secrets
-    - Not applicable
-
-16. **Secrets management:**
-    - Vault (HashiCorp)
-    - AWS Secrets Manager
-    - Azure Key Vault
-    - Google Secret Manager
-    - Kubernetes Secrets
-    - SOPS (encrypted files)
-    - Sealed Secrets
-    - External Secrets Operator
-    - Environment variables
-    - Not applicable
-
-## Execution Model
-
-17. **Execution pattern:**
-    - CLI tool (run locally or in CI)
-    - Kubernetes controller (runs in cluster)
-    - Daemon/agent (runs on nodes/VMs)
-    - Web service (API-driven)
-    - Scheduled job (cron, K8s CronJob)
-    - Event-driven (webhook, queue)
-
-18. **Deployment model:**
-    - Single binary (Go, Rust)
-    - Container image
-    - Script (Python, Bash)
-    - Helm chart
-    - Kustomize
-    - Installed via package manager
-    - Multiple deployment methods
-
-19. **Concurrency:**
-    - Single-threaded (sequential)
-    - Multi-threaded (parallel operations)
-    - Async I/O
-    - Not applicable
-
-## Resource Management
-
-20. **Resources managed:**
-    - Compute (VMs, containers, functions)
-    - Networking (VPC, load balancers, DNS)
-    - Storage (disks, buckets, databases)
-    - Identity (IAM, service accounts)
-    - Security (firewall, policies)
-    - Kubernetes resources (pods, services, etc.)
-    - Multiple resource types
-
-21. **Resource lifecycle:**
-    - Create/provision
-    - Update/modify
-    - Delete/destroy
-    - Import existing resources
-    - All of the above
-
-22. **Dependency management:**
-    - Explicit dependencies (depends_on)
-    - Implicit dependencies (reference outputs)
-    - DAG-based (topological sort)
-    - None (independent resources)
-
-## Language and Framework
-
-23. **Implementation language:**
-    - Go (common for K8s, CLI tools)
-    - Python (scripting, automation)
-    - TypeScript/JavaScript (Pulumi, CDK)
-    - Rust (performance-critical tools)
-    - Bash/Shell (simple scripts)
-    - Java (enterprise tools)
-    - Ruby (Chef, legacy tools)
-    - Other: **\_\_\_**
-
-24. **Key libraries/SDKs:**
-    - AWS SDK
-    - Azure SDK
-    - Google Cloud SDK
-    - Kubernetes client-go
-    - Terraform Plugin SDK
-    - Ansible modules
-    - Custom libraries
-    - Other: **\_\_\_**
-
-## API and Integration
-
-25. **API exposure:**
-    - REST API
-    - gRPC API
-    - CLI only (no API)
-    - Kubernetes API (CRDs)
-    - Webhook receiver
-    - Multiple interfaces
-
-26. **External integrations:**
-    - Cloud provider APIs (AWS, Azure, GCP)
-    - Kubernetes API
-    - Monitoring systems (Prometheus, Datadog)
-    - Notification services (Slack, PagerDuty)
-    - Version control (Git)
-    - Other: **\_\_\_**
-
-## Idempotency and Safety
-
-27. **Idempotency:**
-    - Fully idempotent (safe to run multiple times)
-    - Conditionally idempotent (with flags)
-    - Not idempotent (manual cleanup needed)
-
-28. **Dry-run/Plan mode:**
-    - Yes (preview changes before applying)
-    - No (immediate execution)
-
-29. **Rollback capability:**
-    - Automatic rollback on failure
-    - Manual rollback (previous state)
-    - No rollback (manual cleanup)
-
-30. **Destructive operations:**
-    - Confirmation required (--force flag)
-    - Automatic (with safeguards)
-    - Not applicable (read-only tool)
-
-## Observability
-
-31. **Logging:**
-    - Structured logging (JSON)
-    - Plain text logs
-    - Library: (logrus, zap, winston, etc.)
-    - Multiple log levels (debug, info, warn, error)
-
-32. **Metrics:**
-    - Prometheus metrics
-    - CloudWatch metrics
-    - Datadog metrics
-    - Custom metrics
-    - None
-
-33. **Tracing:**
-    - OpenTelemetry
-    - Jaeger
-    - Not applicable
-
-34. **Health checks:**
-    - Kubernetes liveness/readiness probes
-    - HTTP health endpoint
-    - Not applicable (CLI tool)
-
-## Testing
-
-35. **Testing approach:**
-    - Unit tests (mock external APIs)
-    - Integration tests (real cloud resources)
-    - E2E tests (full workflow)
-    - Contract tests (API compatibility)
-    - Manual testing
-    - All of the above
-
-36. **Test environment:**
-    - Local (mocked)
-    - Dev/staging cloud account
-    - Kind/minikube (for K8s)
-    - Multiple environments
-
-37. **Terraform testing (if applicable):**
-    - Terratest (Go-based testing)
-    - terraform validate
-    - terraform plan (in CI)
-    - Not applicable
-
-38. **Kubernetes testing (if operator):**
-    - Unit tests (Go testing)
-    - envtest (fake API server)
-    - Kind cluster (real cluster)
-    - Not applicable
-
-## Documentation
-
-39. **Documentation format:**
-    - README (basic)
-    - Detailed docs (Markdown files)
-    - Generated docs (godoc, Sphinx, etc.)
-    - Doc website (MkDocs, Docusaurus)
-    - Interactive examples
-    - All of the above
-
-40. **Usage examples:**
-    - Code examples
-    - Tutorial walkthroughs
-    - Video demos
-    - Sample configurations
-    - Minimal (README only)
-
-## Distribution
-
-41. **Distribution method:**
-    - GitHub Releases (binaries)
-    - Package manager (homebrew, apt, yum)
-    - Container registry (Docker Hub, ghcr.io)
-    - Terraform Registry
-    - Helm chart repository
-    - Language package manager (npm, pip, gem)
-    - Multiple methods
-
-42. **Installation:**
-    - Download binary
-    - Package manager install
-    - Helm install (for K8s)
-    - Container image pull
-    - Build from source
-    - Multiple methods
-
-43. **Versioning:**
-    - Semantic versioning (semver)
-    - Calendar versioning
-    - API version compatibility
-
-## Updates and Lifecycle
-
-44. **Update mechanism:**
-    - Manual download/install
-    - Package manager update
-    - Auto-update (self-update command)
-    - Helm upgrade
-    - Not applicable
-
-45. **Backward compatibility:**
-    - Fully backward compatible
-    - Breaking changes documented
-    - Migration guides provided
-
-46. **Deprecation policy:**
-    - Formal deprecation warnings
-    - Support for N-1 versions
-    - No formal policy
-
-## Security
-
-47. **Credentials handling:**
-    - Environment variables
-    - Config file (encrypted)
-    - Cloud provider IAM (instance roles, IRSA)
-    - Kubernetes ServiceAccount
-    - Vault integration
-    - Multiple methods
-
-48. **Least privilege:**
-    - Minimal permissions documented
-    - Permission templates provided (IAM policies)
-    - No specific guidance
-
-49. **Code signing:**
-    - Signed binaries
-    - Container image signing (cosign)
-    - Not signed
-
-50. **Supply chain security:**
-    - SBOM (Software Bill of Materials)
-    - Provenance attestation
-    - Dependency scanning
-    - None
-
-## Compliance and Governance
-
-51. **Compliance focus:**
-    - Policy enforcement (OPA, Kyverno)
-    - Audit logging
-    - Cost tagging
-    - Security posture
-    - Not applicable
-
-52. **Policy as Code:**
-    - OPA (Open Policy Agent)
-    - Sentinel (Terraform)
-    - Kyverno (Kubernetes)
-    - Custom policies
-    - Not applicable
-
-53. **Audit trail:**
-    - Change tracking
-    - GitOps audit (Git history)
-    - CloudTrail/Activity logs
-    - Not applicable
-
-## Performance and Scale
-
-54. **Performance requirements:**
-    - Fast execution (seconds)
-    - Moderate (minutes)
-    - Long-running (hours acceptable)
-    - Background reconciliation (continuous)
-
-55. **Scale considerations:**
-    - Small scale (< 10 resources)
-    - Medium (10-100 resources)
-    - Large (100-1000 resources)
-    - Very large (1000+ resources)
-
-56. **Rate limiting:**
-    - Respect cloud API limits
-    - Configurable rate limits
-    - Not applicable
-
-## CI/CD and Automation
-
-57. **CI/CD for the tool itself:**
-    - GitHub Actions
-    - GitLab CI
-    - CircleCI
-    - Custom
-    - Manual builds
-
-58. **Release automation:**
-    - Automated releases (tags trigger build)
-    - Manual releases
-    - GoReleaser (for Go projects)
-    - Semantic release
-
-59. **Pre-commit hooks:**
-    - Linting
-    - Formatting
-    - Security scans
-    - None
-
-## Community and Ecosystem
-
-60. **Open source:**
-    - Fully open source
-    - Proprietary
-    - Open core (free + paid features)
-
-61. **License:**
-    - MIT
-    - Apache 2.0
-    - GPL
-    - Proprietary
-    - Other: **\_\_\_**
-
-62. **Community support:**
-    - GitHub issues
-    - Slack/Discord community
-    - Forum
-    - Commercial support
-    - Minimal (internal tool)
-
-63. **Plugin/Extension system:**
-    - Extensible (plugins supported)
-    - Monolithic
-    - Planned for future

src/modules/bmm/workflows/3-solutioning/project-types/infrastructure-instructions.md

@@ -0,0 +1,198 @@
+# Infrastructure/DevOps Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for infrastructure and DevOps architecture decisions.
+The LLM should:
+- Understand scale, reliability, and compliance requirements
+- Guide cloud vs. on-premise vs. hybrid decisions
+- Focus on automation and infrastructure as code
+- Consider team size and DevOps maturity
+- Balance complexity with operational overhead
+</critical>
+
+## Cloud Strategy
+
+**Platform Selection**
+Based on requirements and constraints:
+
+- **Public Cloud**: AWS, GCP, Azure for scalability
+- **Private Cloud**: OpenStack, VMware for control
+- **Hybrid**: Mix of public and on-premise
+- **Multi-cloud**: Avoid vendor lock-in
+- **On-premise**: Regulatory or latency requirements
+
+Consider existing contracts, team expertise, and geographic needs.
+
+## Infrastructure as Code
+
+**IaC Approach**
+Based on team and complexity:
+
+- **Terraform**: Cloud-agnostic, declarative
+- **CloudFormation/ARM/GCP Deployment Manager**: Cloud-native
+- **Pulumi/CDK**: Programmatic infrastructure
+- **Ansible/Chef/Puppet**: Configuration management
+- **GitOps**: Flux, ArgoCD for Kubernetes
+
+Start with declarative approaches unless programmatic benefits are clear.
+
+## Container Strategy
+
+**Containerization Approach**
+
+- **Docker**: Standard for containerization
+- **Kubernetes**: For complex orchestration needs
+- **ECS/Cloud Run**: Managed container services
+- **Docker Compose/Swarm**: Simple orchestration
+- **Serverless**: Skip containers entirely
+
+Don't use Kubernetes for simple applications - complexity has a cost.
+
+## CI/CD Architecture
+
+**Pipeline Design**
+
+- Source control strategy (GitFlow, GitHub Flow, trunk-based)
+- Build automation and artifact management
+- Testing stages (unit, integration, e2e)
+- Deployment strategies (blue-green, canary, rolling)
+- Environment promotion process
+
+Match complexity to release frequency and risk tolerance.
+
+## Monitoring and Observability
+
+**Observability Stack**
+Based on scale and requirements:
+
+- **Metrics**: Prometheus, CloudWatch, Datadog
+- **Logging**: ELK, Loki, CloudWatch Logs
+- **Tracing**: Jaeger, X-Ray, Datadog APM
+- **Synthetic Monitoring**: Pingdom, New Relic
+- **Incident Management**: PagerDuty, Opsgenie
+
+Build observability appropriate to SLA requirements.
+
+## Security Architecture
+
+**Security Layers**
+
+- Network security (VPC, security groups, NACLs)
+- Identity and access management
+- Secrets management (Vault, AWS Secrets Manager)
+- Vulnerability scanning
+- Compliance automation
+
+Security must be automated and auditable.
+
+## Backup and Disaster Recovery
+
+**Resilience Strategy**
+
+- Backup frequency and retention
+- RTO/RPO requirements
+- Multi-region/multi-AZ design
+- Disaster recovery testing
+- Data replication strategy
+
+Design for your actual recovery requirements, not theoretical disasters.
+
+## Network Architecture
+
+**Network Design**
+
+- VPC/network topology
+- Load balancing strategy
+- CDN implementation
+- Service mesh (if microservices)
+- Zero trust networking
+
+Keep networking as simple as possible while meeting requirements.
+
+## Cost Optimization
+
+**Cost Management**
+
+- Resource right-sizing
+- Reserved instances/savings plans
+- Spot instances for appropriate workloads
+- Auto-scaling policies
+- Cost monitoring and alerts
+
+Build cost awareness into the architecture.
+
+## Database Operations
+
+**Data Layer Management**
+
+- Managed vs. self-hosted databases
+- Backup and restore procedures
+- Read replica configuration
+- Connection pooling
+- Performance monitoring
+
+## Service Mesh and API Gateway
+
+**API Management** (if applicable)
+
+- API Gateway for external APIs
+- Service mesh for internal communication
+- Rate limiting and throttling
+- Authentication and authorization
+- API versioning strategy
+
+## Development Environments
+
+**Environment Strategy**
+
+- Local development setup
+- Development/staging/production parity
+- Environment provisioning automation
+- Data anonymization for non-production
+
+## Compliance and Governance
+
+**Regulatory Requirements**
+
+- Compliance frameworks (SOC 2, HIPAA, PCI DSS)
+- Audit logging and retention
+- Change management process
+- Access control and segregation of duties
+
+Build compliance in, don't bolt it on.
+
+## Adaptive Guidance Examples
+
+**For a Startup MVP:**
+Focus on managed services, simple CI/CD, and basic monitoring.
+
+**For Enterprise Migration:**
+Emphasize hybrid cloud, phased migration, and compliance requirements.
+
+**For High-Traffic Service:**
+Focus on auto-scaling, CDN, caching layers, and performance monitoring.
+
+**For Regulated Industry:**
+Emphasize compliance automation, audit trails, and data residency.
+
+## Key Principles
+
+1. **Automate everything** - Manual processes don't scale
+2. **Design for failure** - Everything fails eventually
+3. **Secure by default** - Security is not optional
+4. **Monitor proactively** - Don't wait for users to report issues
+5. **Document as code** - Infrastructure documentation gets stale
+
+## Output Format
+
+Document as:
+
+- **Platform**: [Cloud/on-premise choice]
+- **IaC Tool**: [Primary infrastructure tool]
+- **Container/Orchestration**: [If applicable]
+- **CI/CD**: [Pipeline tools and strategy]
+- **Monitoring**: [Observability stack]
+
+Focus on automation and operational excellence.

src/modules/bmm/workflows/3-solutioning/project-types/library-instructions.md

@@ -0,0 +1,185 @@
+# Library/SDK Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for library/SDK architecture decisions.
+The LLM should:
+- Understand the library's purpose and target developers
+- Consider API design and developer experience heavily
+- Focus on versioning, compatibility, and distribution
+- Balance flexibility with ease of use
+- Document decisions that affect consumers
+</critical>
+
+## Language and Ecosystem
+
+**Choose Based on Target Users**
+
+- Consider what language your users are already using
+- Factor in cross-language needs (FFI, bindings, REST wrapper)
+- Think about ecosystem conventions and expectations
+- Performance vs. ease of integration trade-offs
+
+Don't create a Rust library for JavaScript developers unless performance is critical.
+
+## API Design Philosophy
+
+**Developer Experience First**
+Based on library complexity:
+
+- **Simple**: Minimal API surface, sensible defaults
+- **Flexible**: Builder pattern, configuration objects
+- **Powerful**: Layered API (simple + advanced)
+- **Framework**: Inversion of control, plugin architecture
+
+Follow language idioms - Pythonic for Python, functional for FP languages.
+
+## Architecture Patterns
+
+**Internal Structure**
+
+- **Facade Pattern**: Hide complexity behind simple interface
+- **Strategy Pattern**: For pluggable implementations
+- **Factory Pattern**: For object creation flexibility
+- **Dependency Injection**: For testability and flexibility
+
+Don't over-engineer simple utility libraries.
+
+## Versioning Strategy
+
+**Semantic Versioning and Compatibility**
+
+- Breaking change policy
+- Deprecation strategy
+- Migration path planning
+- Backward compatibility approach
+
+Consider the maintenance burden of supporting multiple versions.
+
+## Distribution and Packaging
+
+**Package Management**
+
+- **NPM**: For JavaScript/TypeScript
+- **PyPI**: For Python
+- **Maven/Gradle**: For Java/Kotlin
+- **NuGet**: For .NET
+- **Cargo**: For Rust
+- Multiple registries for cross-language
+
+Include CDN distribution for web libraries.
+
+## Testing Strategy
+
+**Library Testing Approach**
+
+- Unit tests for all public APIs
+- Integration tests with common use cases
+- Property-based testing for complex logic
+- Example projects as tests
+- Cross-version compatibility tests
+
+## Documentation Strategy
+
+**Developer Documentation**
+
+- API reference (generated from code)
+- Getting started guide
+- Common use cases and examples
+- Migration guides for major versions
+- Troubleshooting section
+
+Good documentation is critical for library adoption.
+
+## Error Handling
+
+**Developer-Friendly Errors**
+
+- Clear error messages with context
+- Error codes for programmatic handling
+- Stack traces that point to user code
+- Validation with helpful messages
+
+## Performance Considerations
+
+**Library Performance**
+
+- Lazy loading where appropriate
+- Tree-shaking support for web
+- Minimal dependencies
+- Memory efficiency
+- Benchmark suite for performance regression
+
+## Type Safety
+
+**Type Definitions**
+
+- TypeScript definitions for JavaScript libraries
+- Generic types where appropriate
+- Type inference optimization
+- Runtime type checking options
+
+## Dependency Management
+
+**External Dependencies**
+
+- Minimize external dependencies
+- Pin vs. range versioning
+- Security audit process
+- License compatibility
+
+Zero dependencies is ideal for utility libraries.
+
+## Extension Points
+
+**Extensibility Design** (if needed)
+
+- Plugin architecture
+- Middleware pattern
+- Hook system
+- Custom implementations
+
+Balance flexibility with complexity.
+
+## Platform Support
+
+**Cross-Platform Considerations**
+
+- Browser vs. Node.js for JavaScript
+- OS-specific functionality
+- Mobile platform support
+- WebAssembly compilation
+
+## Adaptive Guidance Examples
+
+**For a UI Component Library:**
+Focus on theming, accessibility, tree-shaking, and framework integration.
+
+**For a Data Processing Library:**
+Emphasize streaming APIs, memory efficiency, and format support.
+
+**For an API Client SDK:**
+Focus on authentication, retry logic, rate limiting, and code generation.
+
+**For a Testing Framework:**
+Emphasize assertion APIs, runner architecture, and reporting.
+
+## Key Principles
+
+1. **Make simple things simple** - Common cases should be easy
+2. **Make complex things possible** - Don't limit advanced users
+3. **Fail fast and clearly** - Help developers debug quickly
+4. **Version thoughtfully** - Breaking changes hurt adoption
+5. **Document by example** - Show real-world usage
+
+## Output Format
+
+Structure as:
+
+- **Language**: [Primary language and version]
+- **API Style**: [Design pattern and approach]
+- **Distribution**: [Package registries and methods]
+- **Versioning**: [Strategy and compatibility policy]
+
+Focus on decisions that affect library consumers.

src/modules/bmm/workflows/3-solutioning/project-types/library-questions.md

@@ -1,146 +0,0 @@
-# Library/SDK Architecture Questions
-
-## Language and Platform
-
-1. **Primary language:**
-   - TypeScript/JavaScript
-   - Python
-   - Rust
-   - Go
-   - Java/Kotlin
-   - C#
-   - Other: **\_\_\_**
-
-2. **Target runtime:**
-   - Node.js
-   - Browser (frontend)
-   - Both Node.js + Browser (isomorphic)
-   - Deno
-   - Bun
-   - Python runtime
-   - Other: **\_\_\_**
-
-3. **Package registry:**
-   - npm (JavaScript)
-   - PyPI (Python)
-   - crates.io (Rust)
-   - Maven Central (Java)
-   - NuGet (.NET)
-   - Go modules
-   - Other: **\_\_\_**
-
-## API Design
-
-4. **Public API style:**
-   - Functional (pure functions)
-   - OOP (classes/instances)
-   - Fluent/Builder pattern
-   - Mix
-
-5. **API surface size:**
-   - Minimal (focused, single purpose)
-   - Comprehensive (many features)
-
-6. **Async handling:**
-   - Promises (async/await)
-   - Callbacks
-   - Observables (RxJS)
-   - Synchronous only
-   - Mix
-
-## Type Safety
-
-7. **Type system:**
-   - TypeScript (JavaScript)
-   - Type hints (Python)
-   - Strongly typed (Rust, Go, Java)
-   - Runtime validation (Zod, Yup)
-   - None (JavaScript)
-
-8. **Type definitions:**
-   - Bundled with package
-   - @types package (DefinitelyTyped)
-   - Not applicable
-
-## Build and Distribution
-
-9. **Build tool:**
-   - tsup (TypeScript, simple)
-   - esbuild (fast)
-   - Rollup
-   - Webpack
-   - Vite
-   - tsc (TypeScript compiler only)
-   - Not needed (pure JS)
-
-10. **Output format:**
-    - ESM (modern)
-    - CommonJS (Node.js)
-    - UMD (universal)
-    - Multiple formats
-
-11. **Minification:**
-    - Yes (production bundle)
-    - No (source code)
-    - Source + minified both
-
-## Dependencies
-
-12. **Dependency strategy:**
-    - Zero dependencies (standalone)
-    - Minimal dependencies
-    - Standard dependencies OK
-
-13. **Peer dependencies:**
-    - Yes (e.g., React library requires React)
-    - No
-
-## Documentation
-
-14. **Documentation approach:**
-    - README only
-    - API docs (JSDoc, TypeDoc)
-    - Full docs site (VitePress, Docusaurus)
-    - Examples repo
-    - All of the above
-
-## Testing
-
-15. **Test framework:**
-    - Jest (JavaScript)
-    - Vitest (Vite-compatible)
-    - Pytest (Python)
-    - Cargo test (Rust)
-    - Go test
-    - Other: **\_\_\_**
-
-16. **Test coverage goal:**
-    - High (80%+)
-    - Moderate (50-80%)
-    - Critical paths only
-
-## Versioning and Releases
-
-17. **Versioning:**
-    - Semantic versioning (semver)
-    - Calendar versioning (calver)
-    - Other
-
-18. **Release automation:**
-    - Changesets
-    - Semantic Release
-    - Manual
-    - GitHub Releases
-    - Other: **\_\_\_**
-
-## Additional
-
-19. **CLI included:** (if applicable)
-    - Yes (command-line tool)
-    - No (library only)
-
-20. **Configuration:**
-    - Config file (JSON, YAML)
-    - Programmatic only
-    - Both
-    - None needed

src/modules/bmm/workflows/3-solutioning/project-types/mobile-instructions.md

@@ -0,0 +1,181 @@
+# Mobile Application Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for mobile app architecture decisions.
+The LLM should:
+- Understand platform requirements from the PRD (iOS, Android, or both)
+- Guide framework choice based on team expertise and project needs
+- Focus on mobile-specific concerns (offline, performance, battery)
+- Adapt complexity to project scale and team size
+- Keep decisions concrete and implementation-focused
+</critical>
+
+## Platform Strategy
+
+**Determine the Right Approach**
+Analyze requirements to recommend:
+
+- **Native** (Swift/Kotlin): When platform-specific features and performance are critical
+- **Cross-platform** (React Native/Flutter): For faster development across platforms
+- **Hybrid** (Ionic/Capacitor): When web expertise exists and native features are minimal
+- **PWA**: For simple apps with basic device access needs
+
+Consider team expertise heavily - don't suggest Flutter to an iOS team unless there's strong justification.
+
+## Framework and Technology Selection
+
+**Match Framework to Project Needs**
+Based on the requirements and team:
+
+- **React Native**: JavaScript teams, code sharing with web, large ecosystem
+- **Flutter**: Consistent UI across platforms, high performance animations
+- **Native**: Platform-specific UX, maximum performance, full API access
+- **.NET MAUI**: C# teams, enterprise environments
+
+For beginners: Recommend based on existing web experience.
+For experts: Focus on specific trade-offs relevant to their use case.
+
+## Application Architecture
+
+**Architectural Pattern**
+Guide toward appropriate patterns:
+
+- **MVVM/MVP**: For testability and separation of concerns
+- **Redux/MobX**: For complex state management
+- **Clean Architecture**: For larger teams and long-term maintenance
+
+Don't over-architect simple apps - a basic MVC might suffice for simple utilities.
+
+## Data Management
+
+**Local Storage Strategy**
+Based on data requirements:
+
+- **SQLite**: Structured data, complex queries, offline-first apps
+- **Realm**: Object database for simpler data models
+- **AsyncStorage/SharedPreferences**: Simple key-value storage
+- **Core Data**: iOS-specific with iCloud sync
+
+**Sync and Offline Strategy**
+Only if offline capability is required:
+
+- Conflict resolution approach
+- Sync triggers and frequency
+- Data compression and optimization
+
+## API Communication
+
+**Network Layer Design**
+
+- RESTful APIs for simple CRUD operations
+- GraphQL for complex data requirements
+- WebSocket for real-time features
+- Consider bandwidth optimization for mobile networks
+
+**Security Considerations**
+
+- Certificate pinning for sensitive apps
+- Token storage in secure keychain
+- Biometric authentication integration
+
+## UI/UX Architecture
+
+**Design System Approach**
+
+- Platform-specific (Material Design, Human Interface Guidelines)
+- Custom design system for brand consistency
+- Component library selection
+
+**Navigation Pattern**
+Based on app complexity:
+
+- Tab-based for simple apps with clear sections
+- Drawer navigation for many features
+- Stack navigation for linear flows
+- Hybrid for complex apps
+
+## Performance Optimization
+
+**Mobile-Specific Performance**
+Focus on what matters for mobile:
+
+- App size (consider app thinning, dynamic delivery)
+- Startup time optimization
+- Memory management
+- Battery efficiency
+- Network optimization
+
+Only dive deep into performance if the PRD indicates performance-critical requirements.
+
+## Native Features Integration
+
+**Device Capabilities**
+Based on PRD requirements, plan for:
+
+- Camera/Gallery access patterns
+- Location services and geofencing
+- Push notifications architecture
+- Biometric authentication
+- Payment integration (Apple Pay, Google Pay)
+
+Don't list all possible features - focus on what's actually needed.
+
+## Testing Strategy
+
+**Mobile Testing Approach**
+
+- Unit testing for business logic
+- UI testing for critical flows
+- Device testing matrix (OS versions, screen sizes)
+- Beta testing distribution (TestFlight, Play Console)
+
+Scale testing complexity to project risk and team size.
+
+## Distribution and Updates
+
+**App Store Strategy**
+
+- Release cadence and versioning
+- Update mechanisms (CodePush for React Native, OTA updates)
+- A/B testing and feature flags
+- Crash reporting and analytics
+
+**Compliance and Guidelines**
+
+- App Store/Play Store guidelines
+- Privacy requirements (ATT, data collection)
+- Content ratings and age restrictions
+
+## Adaptive Guidance Examples
+
+**For a Social Media App:**
+Focus on real-time updates, media handling, offline caching, and push notification strategy.
+
+**For an Enterprise App:**
+Emphasize security, MDM integration, SSO, and offline data sync.
+
+**For a Gaming App:**
+Focus on performance, graphics framework, monetization, and social features.
+
+**For a Utility App:**
+Keep it simple - basic UI, minimal backend, focus on core functionality.
+
+## Key Principles
+
+1. **Platform conventions matter** - Don't fight the platform
+2. **Performance is felt immediately** - Mobile users are sensitive to lag
+3. **Offline-first when appropriate** - But don't over-engineer
+4. **Test on real devices** - Simulators hide real issues
+5. **Plan for app store review** - Build in buffer time
+
+## Output Format
+
+Document decisions as:
+
+- **Technology**: [Specific framework/library with version]
+- **Justification**: [Why this fits the requirements]
+- **Platform-specific notes**: [iOS/Android differences if applicable]
+
+Keep mobile-specific considerations prominent in the architecture document.

src/modules/bmm/workflows/3-solutioning/project-types/mobile-questions.md

@@ -1,110 +0,0 @@
-# Mobile Project Architecture Questions
-
-## Platform
-
-1. **Target platforms:**
-   - iOS only
-   - Android only
-   - Both iOS + Android
-
-2. **Framework choice:**
-   - React Native (JavaScript/TypeScript, large ecosystem)
-   - Flutter (Dart, high performance, beautiful UI)
-   - Native (Swift for iOS, Kotlin for Android)
-   - Expo (React Native with managed workflow)
-   - Other: **\_\_\_**
-
-3. **If React Native - workflow:**
-   - Expo (managed, easier, some limitations)
-   - React Native CLI (bare workflow, full control)
-
-## Backend and Data
-
-4. **Backend approach:**
-   - Firebase (BaaS, real-time, easy)
-   - Supabase (BaaS, PostgreSQL, open-source)
-   - Custom API (REST/GraphQL)
-   - AWS Amplify
-   - Other BaaS: **\_\_\_**
-
-5. **Local data persistence:**
-   - AsyncStorage (simple key-value)
-   - SQLite (relational, offline-first)
-   - Realm (NoSQL, sync)
-   - WatermelonDB (reactive, performance)
-   - MMKV (fast key-value)
-
-6. **State management:**
-   - Redux Toolkit
-   - Zustand
-   - MobX
-   - Context API + useReducer
-   - Jotai/Recoil
-   - React Query (server state)
-
-## Navigation
-
-7. **Navigation library:**
-   - React Navigation (standard for RN)
-   - Expo Router (file-based)
-   - React Native Navigation (native navigation)
-
-## Authentication
-
-8. **Auth approach:**
-   - Firebase Auth
-   - Supabase Auth
-   - Auth0
-   - Social auth (Google, Apple, Facebook)
-   - Custom
-   - None
-
-## Push Notifications
-
-9. **Push notifications:** (if needed)
-   - Firebase Cloud Messaging
-   - Expo Notifications
-   - OneSignal
-   - AWS SNS
-   - None needed
-
-## Payments (if applicable)
-
-10. **In-app purchases:**
-    - RevenueCat (cross-platform, subscriptions)
-    - expo-in-app-purchases
-    - react-native-iap
-    - Stripe (external payments)
-    - None needed
-
-## Additional
-
-11. **Maps integration:** (if needed)
-    - Google Maps
-    - Apple Maps
-    - Mapbox
-    - None needed
-
-12. **Analytics:**
-    - Firebase Analytics
-    - Amplitude
-    - Mixpanel
-    - PostHog
-    - None needed
-
-13. **Crash reporting:**
-    - Sentry
-    - Firebase Crashlytics
-    - Bugsnag
-    - None needed
-
-14. **Offline-first requirement:**
-    - Yes (sync when online)
-    - No (online-only)
-    - Partial (some features offline)
-
-15. **App distribution:**
-    - App Store + Google Play (public)
-    - TestFlight + Internal Testing (beta)
-    - Enterprise distribution
-    - Expo EAS Build

src/modules/bmm/workflows/3-solutioning/project-types/project-types.csv

@@ -1,12 +1,12 @@
-project_type_id,display_name,question_file,description,characteristics,typical_stacks,detection_keywords
+type,name
-web,Web Application,web-questions.md,"Web applications with frontend and/or backend components","has_ui,server_side,browser_based","Next.js+Supabase, React+Django, Vue+Rails","website,web app,frontend,backend,browser,responsive,SPA,SSR,API"
+web,Web Application
-mobile,Mobile Application,mobile-questions.md,"Native or cross-platform mobile applications for iOS/Android","has_ui,native_app,mobile_platform","React Native+Firebase, Flutter+Supabase","mobile,iOS,Android,app store,react native,flutter,smartphone,tablet"
+mobile,Mobile Application
-embedded,Embedded System,embedded-questions.md,"Embedded systems, IoT devices, and firmware","hardware,firmware,microcontroller,iot","ESP32+FreeRTOS+MQTT, STM32+Bare Metal","embedded,IoT,microcontroller,firmware,sensor,ESP32,Arduino,hardware,MQTT,real-time"
+game,Game Development
-game,Game,game-questions.md,"Video games for PC, console, mobile, or web","has_ui,real_time,game_engine,interactive","Unity+Photon+PlayFab, Godot+Nakama","game,unity,unreal,godot,multiplayer,gameplay,3D,2D,player,level"
+backend,Backend Service
-library,Library/SDK,library-questions.md,"Reusable libraries, SDKs, and packages","no_ui,package,reusable,developer_tool","TypeScript+tsup+npm, Python+pip","library,SDK,package,npm,pip,gem,cargo,reusable,API wrapper,utility"
+data,Data Pipeline
-desktop,Desktop Application,desktop-questions.md,"Native desktop applications for Windows/Mac/Linux","has_ui,native_app,cross_platform,installable","Electron+React, Tauri+Svelte, .NET MAUI","desktop,Electron,Tauri,Windows,macOS,Linux,installer,native app,system tray"
+cli,CLI Tool
-cli,Command-Line Tool,cli-questions.md,"Command-line tools and terminal applications","no_ui,terminal,executable,developer_tool","Go+cobra, Rust+clap, Python+click","CLI,command line,terminal,bash,shell,tool,utility,script,console"
+library,Library/SDK
-backend,Backend/API Service,backend-questions.md,"Backend services and APIs (no frontend)","no_ui,server_side,api,microservices","Node.js+Express+PostgreSQL, FastAPI+Redis","API,backend,microservice,REST,GraphQL,gRPC,server,service,endpoint,database"
+desktop,Desktop Application
-data,Data/Analytics/ML,data-questions.md,"Data pipelines, analytics, machine learning projects","data_pipeline,analytics,ml,batch_processing","Airflow+Spark+Snowflake, PyTorch+MLflow","ETL,data pipeline,analytics,machine learning,ML,AI,Spark,Airflow,model,dataset,training"
+embedded,Embedded System
-extension,Browser Extension,extension-questions.md,"Browser extensions for Chrome, Firefox, Safari, etc.","has_ui,browser_specific,client_side","React+Manifest V3, Plasmo+TypeScript","browser extension,Chrome extension,Firefox addon,manifest,content script,popup"
+extension,Browser/Editor Extension
-infra,Infrastructure/DevOps,infra-questions.md,"Infrastructure as Code, K8s operators, CI/CD plugins","automation,infrastructure,devops,tooling","Terraform+AWS, Kubernetes Operator (Go), GitHub Actions","Terraform,Kubernetes,operator,IaC,infrastructure,CI/CD,DevOps,automation,deployment"
+infrastructure,Infrastructure

src/modules/bmm/workflows/3-solutioning/project-types/web-instructions.md

@@ -0,0 +1,158 @@
+# Web Project Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for web project architecture decisions.
+The LLM should:
+- Understand the project requirements deeply before making suggestions
+- Adapt questions based on user skill level
+- Skip irrelevant areas based on project scope
+- Add project-specific decisions not covered here
+- Make intelligent recommendations users can correct
+</critical>
+
+## Frontend Architecture
+
+**Framework Selection**
+Guide the user to choose a frontend framework based on their project needs. Consider factors like:
+
+- Server-side rendering requirements (SEO, initial load performance)
+- Team expertise and learning curve
+- Project complexity and timeline
+- Community support and ecosystem maturity
+
+For beginners: Suggest mainstream options like Next.js or plain React based on their needs.
+For experts: Discuss trade-offs between frameworks briefly, let them specify preferences.
+
+**Styling Strategy**
+Determine the CSS approach that aligns with their team and project:
+
+- Consider maintainability, performance, and developer experience
+- Factor in design system requirements and component reusability
+- Think about build complexity and tooling
+
+Adapt based on skill level - beginners may benefit from utility-first CSS, while teams with strong CSS expertise might prefer CSS Modules or styled-components.
+
+**State Management**
+Only explore if the project has complex client-side state requirements:
+
+- For simple apps, Context API or server state might suffice
+- For complex apps, discuss lightweight vs. comprehensive solutions
+- Consider data flow patterns and debugging needs
+
+## Backend Strategy
+
+**Backend Architecture**
+Intelligently determine backend needs:
+
+- If it's a static site, skip backend entirely
+- For full-stack apps, consider integrated vs. separate backend
+- Factor in team structure (full-stack vs. specialized teams)
+- Consider deployment and operational complexity
+
+Make smart defaults based on frontend choice (e.g., Next.js API routes for Next.js apps).
+
+**API Design**
+Based on client needs and team expertise:
+
+- REST for simplicity and wide compatibility
+- GraphQL for complex data requirements with multiple clients
+- tRPC for type-safe full-stack TypeScript projects
+- Consider hybrid approaches when appropriate
+
+## Data Layer
+
+**Database Selection**
+Guide based on data characteristics and requirements:
+
+- Relational for structured data with relationships
+- Document stores for flexible schemas
+- Consider managed services vs. self-hosted based on team capacity
+- Factor in existing infrastructure and expertise
+
+For beginners: Suggest managed solutions like Supabase or Firebase.
+For experts: Discuss specific database trade-offs if relevant.
+
+**Data Access Patterns**
+Determine ORM/query builder needs based on:
+
+- Type safety requirements
+- Team SQL expertise
+- Performance requirements
+- Migration and schema management needs
+
+## Authentication & Authorization
+
+**Auth Strategy**
+Assess security requirements and implementation complexity:
+
+- For MVPs: Suggest managed auth services
+- For enterprise: Discuss compliance and customization needs
+- Consider user experience requirements (SSO, social login, etc.)
+
+Skip detailed auth discussion if it's an internal tool or public site without user accounts.
+
+## Deployment & Operations
+
+**Hosting Platform**
+Make intelligent suggestions based on:
+
+- Framework choice (Vercel for Next.js, Netlify for static sites)
+- Budget and scale requirements
+- DevOps expertise
+- Geographic distribution needs
+
+**CI/CD Pipeline**
+Adapt to team maturity:
+
+- For small teams: Platform-provided CI/CD
+- For larger teams: Discuss comprehensive pipelines
+- Consider existing tooling and workflows
+
+## Additional Services
+
+<intent>
+Only discuss these if relevant to the project requirements:
+- Email service (for transactional emails)
+- Payment processing (for e-commerce)
+- File storage (for user uploads)
+- Search (for content-heavy sites)
+- Caching (for performance-critical apps)
+- Monitoring (based on uptime requirements)
+
+Don't present these as a checklist - intelligently determine what's needed based on the PRD/requirements.
+</intent>
+
+## Adaptive Guidance Examples
+
+**For a marketing website:**
+Focus on static site generation, CDN, SEO, and analytics. Skip complex backend discussions.
+
+**For a SaaS application:**
+Emphasize authentication, subscription management, multi-tenancy, and monitoring.
+
+**For an internal tool:**
+Prioritize rapid development, simple deployment, and integration with existing systems.
+
+**For an e-commerce platform:**
+Focus on payment processing, inventory management, performance, and security.
+
+## Key Principles
+
+1. **Start with requirements**, not technology choices
+2. **Adapt to user expertise** - don't overwhelm beginners or bore experts
+3. **Make intelligent defaults** the user can override
+4. **Focus on decisions that matter** for this specific project
+5. **Document definitive choices** with specific versions
+6. **Keep rationale concise** unless explanation is needed
+
+## Output Format
+
+Generate architecture decisions as:
+
+- **Decision**: [Specific technology with version]
+- **Brief Rationale**: [One sentence if needed]
+- **Configuration**: [Key settings if non-standard]
+
+Avoid lengthy explanations unless the user is a beginner or asks for clarification.

src/modules/bmm/workflows/3-solutioning/project-types/web-questions.md

@@ -1,136 +0,0 @@
-# Web Project Architecture Questions
-
-## Frontend
-
-1. **Framework choice:**
-   - Next.js (React, App Router, SSR)
-   - React (SPA, client-only)
-   - Vue 3 + Nuxt
-   - Svelte + SvelteKit
-   - Other: **\_\_\_**
-
-2. **Styling approach:**
-   - Tailwind CSS (utility-first)
-   - CSS Modules
-   - Styled Components (CSS-in-JS)
-   - Sass/SCSS
-   - Other: **\_\_\_**
-
-3. **State management:** (if complex client state)
-   - Zustand (lightweight)
-   - Redux Toolkit
-   - Jotai/Recoil (atomic)
-   - Context API only
-   - Server state only (React Query/SWR)
-
-## Backend
-
-4. **Backend approach:**
-   - Next.js API Routes (integrated)
-   - Express.js (Node.js)
-   - Nest.js (Node.js, structured)
-   - FastAPI (Python)
-   - Django (Python)
-   - Rails (Ruby)
-   - Other: **\_\_\_**
-
-5. **API paradigm:**
-   - REST
-   - GraphQL (Apollo, Relay)
-   - tRPC (type-safe)
-   - gRPC
-   - Mix: **\_\_\_**
-
-## Database
-
-6. **Primary database:**
-   - PostgreSQL (relational, ACID)
-   - MySQL
-   - MongoDB (document)
-   - Supabase (PostgreSQL + backend services)
-   - Firebase Firestore
-   - Other: **\_\_\_**
-
-7. **ORM/Query builder:**
-   - Prisma (type-safe, modern)
-   - Drizzle ORM
-   - TypeORM
-   - Sequelize
-   - Mongoose (for MongoDB)
-   - Raw SQL
-   - Database client directly (Supabase SDK)
-
-## Authentication
-
-8. **Auth approach:**
-   - Supabase Auth (managed, built-in)
-   - Auth0 (managed, enterprise)
-   - Clerk (managed, developer-friendly)
-   - NextAuth.js (self-hosted)
-   - Firebase Auth
-   - Custom JWT implementation
-   - Passport.js
-
-## Deployment
-
-9. **Hosting platform:**
-   - Vercel (optimal for Next.js)
-   - Netlify
-   - AWS (EC2, ECS, Lambda)
-   - Google Cloud
-   - Heroku
-   - Railway
-   - Self-hosted
-
-10. **CI/CD:**
-    - GitHub Actions
-    - GitLab CI
-    - CircleCI
-    - Vercel/Netlify auto-deploy
-    - Other: **\_\_\_**
-
-## Additional Services (if applicable)
-
-11. **Email service:** (if transactional emails needed)
-    - Resend (developer-friendly, modern)
-    - SendGrid
-    - AWS SES
-    - Postmark
-    - None needed
-
-12. **Payment processing:** (if e-commerce/subscriptions)
-    - Stripe (comprehensive)
-    - Lemon Squeezy (SaaS-focused)
-    - PayPal
-    - Square
-    - None needed
-
-13. **File storage:** (if user uploads)
-    - Supabase Storage
-    - AWS S3
-    - Cloudflare R2
-    - Vercel Blob
-    - Uploadthing
-    - None needed
-
-14. **Search:** (if full-text search beyond database)
-    - Elasticsearch
-    - Algolia
-    - Meilisearch
-    - Typesense
-    - Database full-text (PostgreSQL)
-    - None needed
-
-15. **Caching:** (if performance critical)
-    - Redis (external cache)
-    - In-memory (Node.js cache)
-    - CDN caching (Cloudflare/Vercel)
-    - None needed
-
-16. **Monitoring/Error Tracking:**
-    - Sentry (error tracking)
-    - PostHog (product analytics)
-    - Datadog
-    - LogRocket
-    - Vercel Analytics
-    - None needed

src/modules/bmm/workflows/3-solutioning/tech-spec/instructions.md

@@ -1,6 +1,6 @@
 <!-- BMAD BMM Tech Spec Workflow Instructions (v6) -->
 
-````xml
+```xml
 <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>Communicate all responses in {communication_language}</critical>
@@ -130,25 +130,15 @@ What would you like to do?</ask>
     <action>Find the most recent file (by date in filename)</action>
 
     <check if="status file exists">
-      <action>Load the status file</action>
+      <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
+        <param>mode: update</param>
+        <param>action: complete_workflow</param>
+        <param>workflow_name: tech-spec</param>
+      </invoke-workflow>
 
-      <template-output file="{{status_file_path}}">current_step</template-output>
+      <check if="success == true">
-      <action>Set to: "tech-spec (Epic {{epic_id}})"</action>
+        <output>✅ Status updated for Epic {{epic_id}} tech-spec</output>
-
+      </check>
-      <template-output file="{{status_file_path}}">current_workflow</template-output>
-      <action>Set to: "tech-spec (Epic {{epic_id}}: {{epic_title}}) - Complete"</action>
-
-      <template-output file="{{status_file_path}}">progress_percentage</template-output>
-      <action>Increment by: 5% (tech-spec generates one epic spec)</action>
-
-      <template-output file="{{status_file_path}}">decisions_log</template-output>
-      <action>Add entry:</action>
-      ```
-      - **{{date}}**: Completed tech-spec for Epic {{epic_id}} ({{epic_title}}). Tech spec file: {{default_output_file}}. This is a JIT workflow that can be run multiple times for different epics. Next: Continue with remaining epics or proceed to Phase 4 implementation.
-      ```
-
-      <template-output file="{{status_file_path}}">planned_workflow</template-output>
-      <action>Mark "tech-spec (Epic {{epic_id}})" as complete in the planned workflow table</action>
 
       <output>**✅ Tech Spec Generated Successfully, {user_name}!**
 
@@ -190,4 +180,4 @@ To track progress across workflows, run `workflow-status` first.
   </step>
 
 </workflow>
-````
+```

src/modules/bmm/workflows/3-solutioning/tech-spec/workflow.yaml

@@ -7,6 +7,8 @@ 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
 
 # Inputs expected (ask user if missing)

src/modules/bmm/workflows/3-solutioning/templates/game-engine-architecture.md

@@ -1,244 +0,0 @@
-# Game Architecture Document
-
-**Project:** {{project_name}}
-**Date:** {{date}}
-**Author:** {{user_name}}
-
-## Executive Summary
-
-{{executive_summary}}
-
-## 1. Technology Stack and Decisions
-
-### 1.1 Technology and Library Decision Table
-
-| Category           | Technology             | Version                | Justification                |
-| ------------------ | ---------------------- | ---------------------- | ---------------------------- |
-| Game Engine        | {{game_engine}}        | {{engine_version}}     | {{engine_justification}}     |
-| Language           | {{language}}           | {{language_version}}   | {{language_justification}}   |
-| Rendering Pipeline | {{rendering_pipeline}} | {{rendering_version}}  | {{rendering_justification}}  |
-| Physics Engine     | {{physics}}            | {{physics_version}}    | {{physics_justification}}    |
-| Audio Middleware   | {{audio}}              | {{audio_version}}      | {{audio_justification}}      |
-| Networking         | {{networking}}         | {{networking_version}} | {{networking_justification}} |
-| Backend Services   | {{backend}}            | {{backend_version}}    | {{backend_justification}}    |
-| Analytics          | {{analytics}}          | {{analytics_version}}  | {{analytics_justification}}  |
-
-{{additional_tech_stack_rows}}
-
-## 2. Engine and Platform
-
-### 2.1 Game Engine Choice
-
-{{engine_choice}}
-
-### 2.2 Target Platforms
-
-{{target_platforms}}
-
-### 2.3 Rendering Pipeline
-
-{{rendering_pipeline_details}}
-
-## 3. Game Architecture
-
-### 3.1 Architecture Pattern
-
-{{architecture_pattern}}
-
-### 3.2 Scene Structure
-
-{{scene_structure}}
-
-### 3.3 Game Loop
-
-{{game_loop}}
-
-### 3.4 State Machine
-
-{{state_machine}}
-
-## 4. Scene and Level Architecture
-
-### 4.1 Scene Organization
-
-{{scene_organization}}
-
-### 4.2 Level Streaming
-
-{{level_streaming}}
-
-### 4.3 Additive Loading
-
-{{additive_loading}}
-
-### 4.4 Memory Management
-
-{{memory_management}}
-
-## 5. Gameplay Systems
-
-### 5.1 Player Controller
-
-{{player_controller}}
-
-### 5.2 Game State Management
-
-{{game_state}}
-
-### 5.3 Inventory System
-
-{{inventory}}
-
-### 5.4 Progression System
-
-{{progression}}
-
-### 5.5 Combat/Core Mechanics
-
-{{core_mechanics}}
-
-## 6. Rendering Architecture
-
-### 6.1 Rendering Pipeline
-
-{{rendering_pipeline_architecture}}
-
-### 6.2 Shaders
-
-{{shaders}}
-
-### 6.3 Post-Processing
-
-{{post_processing}}
-
-### 6.4 LOD System
-
-{{lod_system}}
-
-### 6.5 Occlusion Culling
-
-{{occlusion}}
-
-## 7. Asset Pipeline
-
-### 7.1 Model Import
-
-{{model_import}}
-
-### 7.2 Textures and Materials
-
-{{textures_materials}}
-
-### 7.3 Asset Bundles/Addressables
-
-{{asset_bundles}}
-
-### 7.4 Asset Optimization
-
-{{asset_optimization}}
-
-## 8. Animation System
-
-{{animation_system}}
-
-## 9. Physics and Collision
-
-{{physics_collision}}
-
-## 10. Multiplayer Architecture
-
-{{multiplayer_section}}
-
-**Note:** {{multiplayer_note}}
-
-## 11. Backend Services
-
-{{backend_services}}
-
-**Note:** {{backend_note}}
-
-## 12. Save System
-
-{{save_system}}
-
-## 13. UI/UX Architecture
-
-{{ui_architecture}}
-
-## 14. Audio Architecture
-
-{{audio_architecture}}
-
-{{audio_specialist_section}}
-
-## 15. Component and Integration Overview
-
-{{component_overview}}
-
-## 16. Architecture Decision Records
-
-{{architecture_decisions}}
-
-**Key decisions:**
-
-- Why this engine? {{engine_decision}}
-- ECS vs OOP? {{ecs_vs_oop_decision}}
-- Multiplayer approach? {{multiplayer_decision}}
-- Asset streaming? {{asset_streaming_decision}}
-
-## 17. Implementation Guidance
-
-### 17.1 Prefab/Blueprint Conventions
-
-{{prefab_conventions}}
-
-### 17.2 Coding Patterns
-
-{{coding_patterns}}
-
-### 17.3 Performance Guidelines
-
-{{performance_guidelines}}
-
-## 18. Proposed Source Tree
-
-```
-{{source_tree}}
-```
-
-**Critical folders:**
-
-- {{critical_folder_1}}: {{critical_folder_1_description}}
-- {{critical_folder_2}}: {{critical_folder_2_description}}
-- {{critical_folder_3}}: {{critical_folder_3_description}}
-
-## 19. Performance and Optimization
-
-{{performance_optimization}}
-
-{{performance_specialist_section}}
-
-## 20. Testing Strategy
-
-{{testing_strategy}}
-
-## 21. Build and Distribution
-
-{{build_distribution}}
-
----
-
-## Specialist Sections
-
-{{specialist_sections_summary}}
-
-### Recommended Specialists:
-
-- {{audio_specialist_recommendation}}
-- {{performance_specialist_recommendation}}
-- {{multiplayer_specialist_recommendation}}
-- {{monetization_specialist_recommendation}}
-
----
-
-_Generated using BMad Method Solution Architecture workflow_