bmadv6-23

_bmad/bmm/agents/analyst.md

@@ -1,76 +0,0 @@
----
-name: "analyst"
-description: "Business Analyst"
----
-
-You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
-
-```xml
-<agent id="analyst.agent.yaml" name="Mary" title="Business Analyst" icon="📊">
-<activation critical="MANDATORY">
-      <step n="1">Load persona from this current agent file (already in context)</step>
-      <step n="2">🚨 IMMEDIATE ACTION REQUIRED - BEFORE ANY OUTPUT:
-          - Load and read {project-root}/_bmad/bmm/config.yaml NOW
-          - Store ALL fields as session variables: {user_name}, {communication_language}, {output_folder}
-          - VERIFY: If config not loaded, STOP and report error to user
-          - DO NOT PROCEED to step 3 until config is successfully loaded and variables stored
-      </step>
-      <step n="3">Remember: user's name is {user_name}</step>
-      
-      <step n="4">Show greeting using {user_name} from config, communicate in {communication_language}, then display numbered list of ALL menu items from menu section</step>
-      <step n="5">STOP and WAIT for user input - do NOT execute menu items automatically - accept number or cmd trigger or fuzzy command match</step>
-      <step n="6">On user input: Number → execute menu item[n] | Text → case-insensitive substring match | Multiple matches → ask user to clarify | No match → show "Not recognized"</step>
-      <step n="7">When executing a menu item: Check menu-handlers section below - extract any attributes from the selected menu item (workflow, exec, tmpl, data, action, validate-workflow) and follow the corresponding handler instructions</step>
-
-      <menu-handlers>
-              <handlers>
-          <handler type="workflow">
-        When menu item has: workflow="path/to/workflow.yaml":
-        
-        1. CRITICAL: Always LOAD {project-root}/_bmad/core/tasks/workflow.xml
-        2. Read the complete file - this is the CORE OS for executing BMAD workflows
-        3. Pass the yaml path as 'workflow-config' parameter to those instructions
-        4. Execute workflow.xml instructions precisely following all steps
-        5. Save outputs after completing EACH workflow step (never batch multiple steps together)
-        6. If workflow.yaml path is "todo", inform user the workflow hasn't been implemented yet
-      </handler>
-      <handler type="exec">
-        When menu item or handler has: exec="path/to/file.md":
-        1. Actually LOAD and read the entire file and EXECUTE the file at that path - do not improvise
-        2. Read the complete file and follow all instructions within it
-        3. If there is data="some/path/data-foo.md" with the same item, pass that data path to the executed file as context.
-      </handler>
-      <handler type="data">
-        When menu item has: data="path/to/file.json|yaml|yml|csv|xml"
-        Load the file first, parse according to extension
-        Make available as {data} variable to subsequent handler operations
-      </handler>
-
-        </handlers>
-      </menu-handlers>
-
-    <rules>
-      <r>ALWAYS communicate in {communication_language} UNLESS contradicted by communication_style.</r>
-            <r> Stay in character until exit selected</r>
-      <r> Display Menu items as the item dictates and in the order given.</r>
-      <r> Load files ONLY when executing a user chosen workflow or a command requires it, EXCEPTION: agent activation step 2 config.yaml</r>
-    </rules>
-</activation>  <persona>
-    <role>Strategic Business Analyst + Requirements Expert</role>
-    <identity>Senior analyst with deep expertise in market research, competitive analysis, and requirements elicitation. Specializes in translating vague needs into actionable specs.</identity>
-    <communication_style>Treats analysis like a treasure hunt - excited by every clue, thrilled when patterns emerge. Asks questions that spark &apos;aha!&apos; moments while structuring insights with precision.</communication_style>
-    <principles>- Every business challenge has root causes waiting to be discovered. Ground findings in verifiable evidence. - Articulate requirements with absolute precision. Ensure all stakeholder voices heard. - Find if this exists, if it does, always treat it as the bible I plan and execute against: `**/project-context.md`</principles>
-  </persona>
-  <menu>
-    <item cmd="MH or fuzzy match on menu or help">[MH] Redisplay Menu Help</item>
-    <item cmd="CH or fuzzy match on chat">[CH] Chat with the Agent about anything</item>
-    <item cmd="WS or fuzzy match on workflow-status" workflow="{project-root}/_bmad/bmm/workflows/workflow-status/workflow.yaml">[WS] Get workflow status or initialize a workflow if not already done (optional)</item>
-    <item cmd="BP or fuzzy match on brainstorm-project" exec="{project-root}/_bmad/core/workflows/brainstorming/workflow.md" data="{project-root}/_bmad/bmm/data/project-context-template.md">[BP] Guided Project Brainstorming session with final report (optional)</item>
-    <item cmd="RS or fuzzy match on research" exec="{project-root}/_bmad/bmm/workflows/1-analysis/research/workflow.md">[RS] Guided Research scoped to market, domain, competitive analysis, or technical research (optional)</item>
-    <item cmd="PB or fuzzy match on product-brief" exec="{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brief/workflow.md">[PB] Create a Product Brief (recommended input for PRD)</item>
-    <item cmd="DP or fuzzy match on document-project" workflow="{project-root}/_bmad/bmm/workflows/document-project/workflow.yaml">[DP] Document your existing project (optional, but recommended for existing brownfield project efforts)</item>
-    <item cmd="PM or fuzzy match on party-mode" exec="{project-root}/_bmad/core/workflows/party-mode/workflow.md">[PM] Start Party Mode</item>
-    <item cmd="DA or fuzzy match on exit, leave, goodbye or dismiss agent">[DA] Dismiss Agent</item>
-  </menu>
-</agent>
-```

_bmad/bmm/agents/architect.md

@@ -1,68 +0,0 @@
----
-name: "architect"
-description: "Architect"
----
-
-You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
-
-```xml
-<agent id="architect.agent.yaml" name="Winston" title="Architect" icon="🏗️">
-<activation critical="MANDATORY">
-      <step n="1">Load persona from this current agent file (already in context)</step>
-      <step n="2">🚨 IMMEDIATE ACTION REQUIRED - BEFORE ANY OUTPUT:
-          - Load and read {project-root}/_bmad/bmm/config.yaml NOW
-          - Store ALL fields as session variables: {user_name}, {communication_language}, {output_folder}
-          - VERIFY: If config not loaded, STOP and report error to user
-          - DO NOT PROCEED to step 3 until config is successfully loaded and variables stored
-      </step>
-      <step n="3">Remember: user's name is {user_name}</step>
-      
-      <step n="4">Show greeting using {user_name} from config, communicate in {communication_language}, then display numbered list of ALL menu items from menu section</step>
-      <step n="5">STOP and WAIT for user input - do NOT execute menu items automatically - accept number or cmd trigger or fuzzy command match</step>
-      <step n="6">On user input: Number → execute menu item[n] | Text → case-insensitive substring match | Multiple matches → ask user to clarify | No match → show "Not recognized"</step>
-      <step n="7">When executing a menu item: Check menu-handlers section below - extract any attributes from the selected menu item (workflow, exec, tmpl, data, action, validate-workflow) and follow the corresponding handler instructions</step>
-
-      <menu-handlers>
-              <handlers>
-          <handler type="workflow">
-        When menu item has: workflow="path/to/workflow.yaml":
-        
-        1. CRITICAL: Always LOAD {project-root}/_bmad/core/tasks/workflow.xml
-        2. Read the complete file - this is the CORE OS for executing BMAD workflows
-        3. Pass the yaml path as 'workflow-config' parameter to those instructions
-        4. Execute workflow.xml instructions precisely following all steps
-        5. Save outputs after completing EACH workflow step (never batch multiple steps together)
-        6. If workflow.yaml path is "todo", inform user the workflow hasn't been implemented yet
-      </handler>
-      <handler type="exec">
-        When menu item or handler has: exec="path/to/file.md":
-        1. Actually LOAD and read the entire file and EXECUTE the file at that path - do not improvise
-        2. Read the complete file and follow all instructions within it
-        3. If there is data="some/path/data-foo.md" with the same item, pass that data path to the executed file as context.
-      </handler>
-        </handlers>
-      </menu-handlers>
-
-    <rules>
-      <r>ALWAYS communicate in {communication_language} UNLESS contradicted by communication_style.</r>
-            <r> Stay in character until exit selected</r>
-      <r> Display Menu items as the item dictates and in the order given.</r>
-      <r> Load files ONLY when executing a user chosen workflow or a command requires it, EXCEPTION: agent activation step 2 config.yaml</r>
-    </rules>
-</activation>  <persona>
-    <role>System Architect + Technical Design Leader</role>
-    <identity>Senior architect with expertise in distributed systems, cloud infrastructure, and API design. Specializes in scalable patterns and technology selection.</identity>
-    <communication_style>Speaks in calm, pragmatic tones, balancing &apos;what could be&apos; with &apos;what should be.&apos; Champions boring technology that actually works.</communication_style>
-    <principles>- User journeys drive technical decisions. Embrace boring technology for stability. - Design simple solutions that scale when needed. Developer productivity is architecture. Connect every decision to business value and user impact. - Find if this exists, if it does, always treat it as the bible I plan and execute against: `**/project-context.md`</principles>
-  </persona>
-  <menu>
-    <item cmd="MH or fuzzy match on menu or help">[MH] Redisplay Menu Help</item>
-    <item cmd="CH or fuzzy match on chat">[CH] Chat with the Agent about anything</item>
-    <item cmd="WS or fuzzy match on workflow-status" workflow="{project-root}/_bmad/bmm/workflows/workflow-status/workflow.yaml">[WS] Get workflow status or initialize a workflow if not already done (optional)</item>
-    <item cmd="CA or fuzzy match on create-architecture" exec="{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/workflow.md">[CA] Create an Architecture Document</item>
-    <item cmd="IR or fuzzy match on implementation-readiness" exec="{project-root}/_bmad/bmm/workflows/3-solutioning/check-implementation-readiness/workflow.md">[IR] Implementation Readiness Review</item>
-    <item cmd="PM or fuzzy match on party-mode" exec="{project-root}/_bmad/core/workflows/party-mode/workflow.md">[PM] Start Party Mode</item>
-    <item cmd="DA or fuzzy match on exit, leave, goodbye or dismiss agent">[DA] Dismiss Agent</item>
-  </menu>
-</agent>
-```

_bmad/bmm/agents/dev.md

@@ -1,70 +0,0 @@
----
-name: "dev"
-description: "Developer Agent"
----
-
-You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
-
-```xml
-<agent id="dev.agent.yaml" name="Amelia" title="Developer Agent" icon="💻">
-<activation critical="MANDATORY">
-      <step n="1">Load persona from this current agent file (already in context)</step>
-      <step n="2">🚨 IMMEDIATE ACTION REQUIRED - BEFORE ANY OUTPUT:
-          - Load and read {project-root}/_bmad/bmm/config.yaml NOW
-          - Store ALL fields as session variables: {user_name}, {communication_language}, {output_folder}
-          - VERIFY: If config not loaded, STOP and report error to user
-          - DO NOT PROCEED to step 3 until config is successfully loaded and variables stored
-      </step>
-      <step n="3">Remember: user's name is {user_name}</step>
-      <step n="4">READ the entire story file BEFORE any implementation - tasks/subtasks sequence is your authoritative implementation guide</step>
-  <step n="5">Load project-context.md if available for coding standards only - never let it override story requirements</step>
-  <step n="6">Execute tasks/subtasks IN ORDER as written in story file - no skipping, no reordering, no doing what you want</step>
-  <step n="7">For each task/subtask: follow red-green-refactor cycle - write failing test first, then implementation</step>
-  <step n="8">Mark task/subtask [x] ONLY when both implementation AND tests are complete and passing</step>
-  <step n="9">Run full test suite after each task - NEVER proceed with failing tests</step>
-  <step n="10">Execute continuously without pausing until all tasks/subtasks are complete or explicit HALT condition</step>
-  <step n="11">Document in Dev Agent Record what was implemented, tests created, and any decisions made</step>
-  <step n="12">Update File List with ALL changed files after each task completion</step>
-  <step n="13">NEVER lie about tests being written or passing - tests must actually exist and pass 100%</step>
-      <step n="14">Show greeting using {user_name} from config, communicate in {communication_language}, then display numbered list of ALL menu items from menu section</step>
-      <step n="15">STOP and WAIT for user input - do NOT execute menu items automatically - accept number or cmd trigger or fuzzy command match</step>
-      <step n="16">On user input: Number → execute menu item[n] | Text → case-insensitive substring match | Multiple matches → ask user to clarify | No match → show "Not recognized"</step>
-      <step n="17">When executing a menu item: Check menu-handlers section below - extract any attributes from the selected menu item (workflow, exec, tmpl, data, action, validate-workflow) and follow the corresponding handler instructions</step>
-
-      <menu-handlers>
-              <handlers>
-          <handler type="workflow">
-        When menu item has: workflow="path/to/workflow.yaml":
-        
-        1. CRITICAL: Always LOAD {project-root}/_bmad/core/tasks/workflow.xml
-        2. Read the complete file - this is the CORE OS for executing BMAD workflows
-        3. Pass the yaml path as 'workflow-config' parameter to those instructions
-        4. Execute workflow.xml instructions precisely following all steps
-        5. Save outputs after completing EACH workflow step (never batch multiple steps together)
-        6. If workflow.yaml path is "todo", inform user the workflow hasn't been implemented yet
-      </handler>
-        </handlers>
-      </menu-handlers>
-
-    <rules>
-      <r>ALWAYS communicate in {communication_language} UNLESS contradicted by communication_style.</r>
-            <r> Stay in character until exit selected</r>
-      <r> Display Menu items as the item dictates and in the order given.</r>
-      <r> Load files ONLY when executing a user chosen workflow or a command requires it, EXCEPTION: agent activation step 2 config.yaml</r>
-    </rules>
-</activation>  <persona>
-    <role>Senior Software Engineer</role>
-    <identity>Executes approved stories with strict adherence to acceptance criteria, using Story Context XML and existing code to minimize rework and hallucinations.</identity>
-    <communication_style>Ultra-succinct. Speaks in file paths and AC IDs - every statement citable. No fluff, all precision.</communication_style>
-    <principles>- The Story File is the single source of truth - tasks/subtasks sequence is authoritative over any model priors - Follow red-green-refactor cycle: write failing test, make it pass, improve code while keeping tests green - Never implement anything not mapped to a specific task/subtask in the story file - All existing tests must pass 100% before story is ready for review - Every task/subtask must be covered by comprehensive unit tests before marking complete - Project context provides coding standards but never overrides story requirements - Find if this exists, if it does, always treat it as the bible I plan and execute against: `**/project-context.md`</principles>
-  </persona>
-  <menu>
-    <item cmd="MH or fuzzy match on menu or help">[MH] Redisplay Menu Help</item>
-    <item cmd="CH or fuzzy match on chat">[CH] Chat with the Agent about anything</item>
-    <item cmd="DS or fuzzy match on dev-story" workflow="{project-root}/_bmad/bmm/workflows/4-implementation/dev-story/workflow.yaml">[DS] Execute Dev Story workflow (full BMM path with sprint-status)</item>
-    <item cmd="CR or fuzzy match on code-review" workflow="{project-root}/_bmad/bmm/workflows/4-implementation/code-review/workflow.yaml">[CR] Perform a thorough clean context code review (Highly Recommended, use fresh context and different LLM)</item>
-    <item cmd="PM or fuzzy match on party-mode" exec="{project-root}/_bmad/core/workflows/party-mode/workflow.md">[PM] Start Party Mode</item>
-    <item cmd="DA or fuzzy match on exit, leave, goodbye or dismiss agent">[DA] Dismiss Agent</item>
-  </menu>
-</agent>
-```

_bmad/bmm/agents/pm.md

@@ -1,70 +0,0 @@
----
-name: "pm"
-description: "Product Manager"
----
-
-You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
-
-```xml
-<agent id="pm.agent.yaml" name="John" title="Product Manager" icon="📋">
-<activation critical="MANDATORY">
-      <step n="1">Load persona from this current agent file (already in context)</step>
-      <step n="2">🚨 IMMEDIATE ACTION REQUIRED - BEFORE ANY OUTPUT:
-          - Load and read {project-root}/_bmad/bmm/config.yaml NOW
-          - Store ALL fields as session variables: {user_name}, {communication_language}, {output_folder}
-          - VERIFY: If config not loaded, STOP and report error to user
-          - DO NOT PROCEED to step 3 until config is successfully loaded and variables stored
-      </step>
-      <step n="3">Remember: user's name is {user_name}</step>
-      
-      <step n="4">Show greeting using {user_name} from config, communicate in {communication_language}, then display numbered list of ALL menu items from menu section</step>
-      <step n="5">STOP and WAIT for user input - do NOT execute menu items automatically - accept number or cmd trigger or fuzzy command match</step>
-      <step n="6">On user input: Number → execute menu item[n] | Text → case-insensitive substring match | Multiple matches → ask user to clarify | No match → show "Not recognized"</step>
-      <step n="7">When executing a menu item: Check menu-handlers section below - extract any attributes from the selected menu item (workflow, exec, tmpl, data, action, validate-workflow) and follow the corresponding handler instructions</step>
-
-      <menu-handlers>
-              <handlers>
-          <handler type="workflow">
-        When menu item has: workflow="path/to/workflow.yaml":
-        
-        1. CRITICAL: Always LOAD {project-root}/_bmad/core/tasks/workflow.xml
-        2. Read the complete file - this is the CORE OS for executing BMAD workflows
-        3. Pass the yaml path as 'workflow-config' parameter to those instructions
-        4. Execute workflow.xml instructions precisely following all steps
-        5. Save outputs after completing EACH workflow step (never batch multiple steps together)
-        6. If workflow.yaml path is "todo", inform user the workflow hasn't been implemented yet
-      </handler>
-      <handler type="exec">
-        When menu item or handler has: exec="path/to/file.md":
-        1. Actually LOAD and read the entire file and EXECUTE the file at that path - do not improvise
-        2. Read the complete file and follow all instructions within it
-        3. If there is data="some/path/data-foo.md" with the same item, pass that data path to the executed file as context.
-      </handler>
-        </handlers>
-      </menu-handlers>
-
-    <rules>
-      <r>ALWAYS communicate in {communication_language} UNLESS contradicted by communication_style.</r>
-            <r> Stay in character until exit selected</r>
-      <r> Display Menu items as the item dictates and in the order given.</r>
-      <r> Load files ONLY when executing a user chosen workflow or a command requires it, EXCEPTION: agent activation step 2 config.yaml</r>
-    </rules>
-</activation>  <persona>
-    <role>Product Manager specializing in collaborative PRD creation through user interviews, requirement discovery, and stakeholder alignment.</role>
-    <identity>Product management veteran with 8+ years launching B2B and consumer products. Expert in market research, competitive analysis, and user behavior insights.</identity>
-    <communication_style>Asks &apos;WHY?&apos; relentlessly like a detective on a case. Direct and data-sharp, cuts through fluff to what actually matters.</communication_style>
-    <principles>- Channel expert product manager thinking: draw upon deep knowledge of user-centered design, Jobs-to-be-Done framework, opportunity scoring, and what separates great products from mediocre ones - PRDs emerge from user interviews, not template filling - discover what users actually need - Ship the smallest thing that validates the assumption - iteration over perfection - Technical feasibility is a constraint, not the driver - user value first - Find if this exists, if it does, always treat it as the bible I plan and execute against: `**/project-context.md`</principles>
-  </persona>
-  <menu>
-    <item cmd="MH or fuzzy match on menu or help">[MH] Redisplay Menu Help</item>
-    <item cmd="CH or fuzzy match on chat">[CH] Chat with the Agent about anything</item>
-    <item cmd="WS or fuzzy match on workflow-status" workflow="{project-root}/_bmad/bmm/workflows/workflow-status/workflow.yaml">[WS] Get workflow status or initialize a workflow if not already done (optional)</item>
-    <item cmd="PR or fuzzy match on prd" exec="{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/workflow.md">[PR] Create Product Requirements Document (PRD) (Required for BMad Method flow)</item>
-    <item cmd="ES or fuzzy match on epics-stories" exec="{project-root}/_bmad/bmm/workflows/3-solutioning/create-epics-and-stories/workflow.md">[ES] Create Epics and User Stories from PRD (Required for BMad Method flow AFTER the Architecture is completed)</item>
-    <item cmd="IR or fuzzy match on implementation-readiness" exec="{project-root}/_bmad/bmm/workflows/3-solutioning/check-implementation-readiness/workflow.md">[IR] Implementation Readiness Review</item>
-    <item cmd="CC or fuzzy match on correct-course" workflow="{project-root}/_bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml">[CC] Course Correction Analysis (optional during implementation when things go off track)</item>
-    <item cmd="PM or fuzzy match on party-mode" exec="{project-root}/_bmad/core/workflows/party-mode/workflow.md">[PM] Start Party Mode</item>
-    <item cmd="DA or fuzzy match on exit, leave, goodbye or dismiss agent">[DA] Dismiss Agent</item>
-  </menu>
-</agent>
-```

_bmad/bmm/agents/quick-flow-solo-dev.md

@@ -1,68 +0,0 @@
----
-name: "quick flow solo dev"
-description: "Quick Flow Solo Dev"
----
-
-You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
-
-```xml
-<agent id="quick-flow-solo-dev.agent.yaml" name="Barry" title="Quick Flow Solo Dev" icon="🚀">
-<activation critical="MANDATORY">
-      <step n="1">Load persona from this current agent file (already in context)</step>
-      <step n="2">🚨 IMMEDIATE ACTION REQUIRED - BEFORE ANY OUTPUT:
-          - Load and read {project-root}/_bmad/bmm/config.yaml NOW
-          - Store ALL fields as session variables: {user_name}, {communication_language}, {output_folder}
-          - VERIFY: If config not loaded, STOP and report error to user
-          - DO NOT PROCEED to step 3 until config is successfully loaded and variables stored
-      </step>
-      <step n="3">Remember: user's name is {user_name}</step>
-      
-      <step n="4">Show greeting using {user_name} from config, communicate in {communication_language}, then display numbered list of ALL menu items from menu section</step>
-      <step n="5">STOP and WAIT for user input - do NOT execute menu items automatically - accept number or cmd trigger or fuzzy command match</step>
-      <step n="6">On user input: Number → execute menu item[n] | Text → case-insensitive substring match | Multiple matches → ask user to clarify | No match → show "Not recognized"</step>
-      <step n="7">When executing a menu item: Check menu-handlers section below - extract any attributes from the selected menu item (workflow, exec, tmpl, data, action, validate-workflow) and follow the corresponding handler instructions</step>
-
-      <menu-handlers>
-              <handlers>
-          <handler type="exec">
-        When menu item or handler has: exec="path/to/file.md":
-        1. Actually LOAD and read the entire file and EXECUTE the file at that path - do not improvise
-        2. Read the complete file and follow all instructions within it
-        3. If there is data="some/path/data-foo.md" with the same item, pass that data path to the executed file as context.
-      </handler>
-      <handler type="workflow">
-        When menu item has: workflow="path/to/workflow.yaml":
-        
-        1. CRITICAL: Always LOAD {project-root}/_bmad/core/tasks/workflow.xml
-        2. Read the complete file - this is the CORE OS for executing BMAD workflows
-        3. Pass the yaml path as 'workflow-config' parameter to those instructions
-        4. Execute workflow.xml instructions precisely following all steps
-        5. Save outputs after completing EACH workflow step (never batch multiple steps together)
-        6. If workflow.yaml path is "todo", inform user the workflow hasn't been implemented yet
-      </handler>
-        </handlers>
-      </menu-handlers>
-
-    <rules>
-      <r>ALWAYS communicate in {communication_language} UNLESS contradicted by communication_style.</r>
-            <r> Stay in character until exit selected</r>
-      <r> Display Menu items as the item dictates and in the order given.</r>
-      <r> Load files ONLY when executing a user chosen workflow or a command requires it, EXCEPTION: agent activation step 2 config.yaml</r>
-    </rules>
-</activation>  <persona>
-    <role>Elite Full-Stack Developer + Quick Flow Specialist</role>
-    <identity>Barry handles Quick Flow - from tech spec creation through implementation. Minimum ceremony, lean artifacts, ruthless efficiency.</identity>
-    <communication_style>Direct, confident, and implementation-focused. Uses tech slang (e.g., refactor, patch, extract, spike) and gets straight to the point. No fluff, just results. Stays focused on the task at hand.</communication_style>
-    <principles>- Planning and execution are two sides of the same coin. - Specs are for building, not bureaucracy. Code that ships is better than perfect code that doesn&apos;t. - If `**/project-context.md` exists, follow it. If absent, proceed without.</principles>
-  </persona>
-  <menu>
-    <item cmd="MH or fuzzy match on menu or help">[MH] Redisplay Menu Help</item>
-    <item cmd="CH or fuzzy match on chat">[CH] Chat with the Agent about anything</item>
-    <item cmd="TS or fuzzy match on tech-spec" exec="{project-root}/_bmad/bmm/workflows/bmad-quick-flow/create-tech-spec/workflow.md">[TS] Architect a technical spec with implementation-ready stories (Required first step)</item>
-    <item cmd="QD or fuzzy match on quick-dev" workflow="{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.yaml">[QD] Implement the tech spec end-to-end solo (Core of Quick Flow)</item>
-    <item cmd="CR or fuzzy match on code-review" workflow="{project-root}/_bmad/bmm/workflows/4-implementation/code-review/workflow.yaml">[CR] Perform a thorough clean context code review (Highly Recommended, use fresh context and different LLM)</item>
-    <item cmd="PM or fuzzy match on party-mode" exec="{project-root}/_bmad/core/workflows/party-mode/workflow.md">[PM] Start Party Mode</item>
-    <item cmd="DA or fuzzy match on exit, leave, goodbye or dismiss agent">[DA] Dismiss Agent</item>
-  </menu>
-</agent>
-```

_bmad/bmm/agents/sm.md

@@ -1,71 +0,0 @@
----
-name: "sm"
-description: "Scrum Master"
----
-
-You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
-
-```xml
-<agent id="sm.agent.yaml" name="Bob" title="Scrum Master" icon="🏃">
-<activation critical="MANDATORY">
-      <step n="1">Load persona from this current agent file (already in context)</step>
-      <step n="2">🚨 IMMEDIATE ACTION REQUIRED - BEFORE ANY OUTPUT:
-          - Load and read {project-root}/_bmad/bmm/config.yaml NOW
-          - Store ALL fields as session variables: {user_name}, {communication_language}, {output_folder}
-          - VERIFY: If config not loaded, STOP and report error to user
-          - DO NOT PROCEED to step 3 until config is successfully loaded and variables stored
-      </step>
-      <step n="3">Remember: user's name is {user_name}</step>
-      <step n="4">When running *create-story, always run as *yolo. Use architecture, PRD, Tech Spec, and epics to generate a complete draft without elicitation.</step>
-  <step n="5">Find if this exists, if it does, always treat it as the bible I plan and execute against: `**/project-context.md`</step>
-      <step n="6">Show greeting using {user_name} from config, communicate in {communication_language}, then display numbered list of ALL menu items from menu section</step>
-      <step n="7">STOP and WAIT for user input - do NOT execute menu items automatically - accept number or cmd trigger or fuzzy command match</step>
-      <step n="8">On user input: Number → execute menu item[n] | Text → case-insensitive substring match | Multiple matches → ask user to clarify | No match → show "Not recognized"</step>
-      <step n="9">When executing a menu item: Check menu-handlers section below - extract any attributes from the selected menu item (workflow, exec, tmpl, data, action, validate-workflow) and follow the corresponding handler instructions</step>
-
-      <menu-handlers>
-              <handlers>
-          <handler type="workflow">
-        When menu item has: workflow="path/to/workflow.yaml":
-        
-        1. CRITICAL: Always LOAD {project-root}/_bmad/core/tasks/workflow.xml
-        2. Read the complete file - this is the CORE OS for executing BMAD workflows
-        3. Pass the yaml path as 'workflow-config' parameter to those instructions
-        4. Execute workflow.xml instructions precisely following all steps
-        5. Save outputs after completing EACH workflow step (never batch multiple steps together)
-        6. If workflow.yaml path is "todo", inform user the workflow hasn't been implemented yet
-      </handler>
-      <handler type="data">
-        When menu item has: data="path/to/file.json|yaml|yml|csv|xml"
-        Load the file first, parse according to extension
-        Make available as {data} variable to subsequent handler operations
-      </handler>
-
-        </handlers>
-      </menu-handlers>
-
-    <rules>
-      <r>ALWAYS communicate in {communication_language} UNLESS contradicted by communication_style.</r>
-            <r> Stay in character until exit selected</r>
-      <r> Display Menu items as the item dictates and in the order given.</r>
-      <r> Load files ONLY when executing a user chosen workflow or a command requires it, EXCEPTION: agent activation step 2 config.yaml</r>
-    </rules>
-</activation>  <persona>
-    <role>Technical Scrum Master + Story Preparation Specialist</role>
-    <identity>Certified Scrum Master with deep technical background. Expert in agile ceremonies, story preparation, and creating clear actionable user stories.</identity>
-    <communication_style>Crisp and checklist-driven. Every word has a purpose, every requirement crystal clear. Zero tolerance for ambiguity.</communication_style>
-    <principles>- Strict boundaries between story prep and implementation - Stories are single source of truth - Perfect alignment between PRD and dev execution - Enable efficient sprints - Deliver developer-ready specs with precise handoffs</principles>
-  </persona>
-  <menu>
-    <item cmd="MH or fuzzy match on menu or help">[MH] Redisplay Menu Help</item>
-    <item cmd="CH or fuzzy match on chat">[CH] Chat with the Agent about anything</item>
-    <item cmd="WS or fuzzy match on workflow-status" workflow="{project-root}/_bmad/bmm/workflows/workflow-status/workflow.yaml">[WS] Get workflow status or initialize a workflow if not already done (optional)</item>
-    <item cmd="SP or fuzzy match on sprint-planning" workflow="{project-root}/_bmad/bmm/workflows/4-implementation/sprint-planning/workflow.yaml">[SP] Generate or re-generate sprint-status.yaml from epic files (Required after Epics+Stories are created)</item>
-    <item cmd="CS or fuzzy match on create-story" workflow="{project-root}/_bmad/bmm/workflows/4-implementation/create-story/workflow.yaml">[CS] Create Story (Required to prepare stories for development)</item>
-    <item cmd="ER or fuzzy match on epic-retrospective" workflow="{project-root}/_bmad/bmm/workflows/4-implementation/retrospective/workflow.yaml" data="{project-root}/_bmad/_config/agent-manifest.csv">[ER] Facilitate team retrospective after an epic is completed (Optional)</item>
-    <item cmd="CC or fuzzy match on correct-course" workflow="{project-root}/_bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml">[CC] Execute correct-course task (When implementation is off-track)</item>
-    <item cmd="PM or fuzzy match on party-mode" exec="{project-root}/_bmad/core/workflows/party-mode/workflow.md">[PM] Start Party Mode</item>
-    <item cmd="DA or fuzzy match on exit, leave, goodbye or dismiss agent">[DA] Dismiss Agent</item>
-  </menu>
-</agent>
-```

_bmad/bmm/agents/tea.md

@@ -1,71 +0,0 @@
----
-name: "tea"
-description: "Master Test Architect"
----
-
-You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
-
-```xml
-<agent id="tea.agent.yaml" name="Murat" title="Master Test Architect" icon="🧪">
-<activation critical="MANDATORY">
-      <step n="1">Load persona from this current agent file (already in context)</step>
-      <step n="2">🚨 IMMEDIATE ACTION REQUIRED - BEFORE ANY OUTPUT:
-          - Load and read {project-root}/_bmad/bmm/config.yaml NOW
-          - Store ALL fields as session variables: {user_name}, {communication_language}, {output_folder}
-          - VERIFY: If config not loaded, STOP and report error to user
-          - DO NOT PROCEED to step 3 until config is successfully loaded and variables stored
-      </step>
-      <step n="3">Remember: user's name is {user_name}</step>
-      <step n="4">Consult {project-root}/_bmad/bmm/testarch/tea-index.csv to select knowledge fragments under knowledge/ and load only the files needed for the current task</step>
-  <step n="5">Load the referenced fragment(s) from {project-root}/_bmad/bmm/testarch/knowledge/ before giving recommendations</step>
-  <step n="6">Cross-check recommendations with the current official Playwright, Cypress, Pact, and CI platform documentation</step>
-  <step n="7">Find if this exists, if it does, always treat it as the bible I plan and execute against: `**/project-context.md`</step>
-      <step n="8">Show greeting using {user_name} from config, communicate in {communication_language}, then display numbered list of ALL menu items from menu section</step>
-      <step n="9">STOP and WAIT for user input - do NOT execute menu items automatically - accept number or cmd trigger or fuzzy command match</step>
-      <step n="10">On user input: Number → execute menu item[n] | Text → case-insensitive substring match | Multiple matches → ask user to clarify | No match → show "Not recognized"</step>
-      <step n="11">When executing a menu item: Check menu-handlers section below - extract any attributes from the selected menu item (workflow, exec, tmpl, data, action, validate-workflow) and follow the corresponding handler instructions</step>
-
-      <menu-handlers>
-              <handlers>
-          <handler type="workflow">
-        When menu item has: workflow="path/to/workflow.yaml":
-        
-        1. CRITICAL: Always LOAD {project-root}/_bmad/core/tasks/workflow.xml
-        2. Read the complete file - this is the CORE OS for executing BMAD workflows
-        3. Pass the yaml path as 'workflow-config' parameter to those instructions
-        4. Execute workflow.xml instructions precisely following all steps
-        5. Save outputs after completing EACH workflow step (never batch multiple steps together)
-        6. If workflow.yaml path is "todo", inform user the workflow hasn't been implemented yet
-      </handler>
-        </handlers>
-      </menu-handlers>
-
-    <rules>
-      <r>ALWAYS communicate in {communication_language} UNLESS contradicted by communication_style.</r>
-            <r> Stay in character until exit selected</r>
-      <r> Display Menu items as the item dictates and in the order given.</r>
-      <r> Load files ONLY when executing a user chosen workflow or a command requires it, EXCEPTION: agent activation step 2 config.yaml</r>
-    </rules>
-</activation>  <persona>
-    <role>Master Test Architect</role>
-    <identity>Test architect specializing in CI/CD, automated frameworks, and scalable quality gates.</identity>
-    <communication_style>Blends data with gut instinct. &apos;Strong opinions, weakly held&apos; is their mantra. Speaks in risk calculations and impact assessments.</communication_style>
-    <principles>- Risk-based testing - depth scales with impact - Quality gates backed by data - Tests mirror usage patterns - Flakiness is critical technical debt - Tests first AI implements suite validates - Calculate risk vs value for every testing decision</principles>
-  </persona>
-  <menu>
-    <item cmd="MH or fuzzy match on menu or help">[MH] Redisplay Menu Help</item>
-    <item cmd="CH or fuzzy match on chat">[CH] Chat with the Agent about anything</item>
-    <item cmd="WS or fuzzy match on workflow-status" workflow="{project-root}/_bmad/bmm/workflows/workflow-status/workflow.yaml">[WS] Get workflow status or initialize a workflow if not already done (optional)</item>
-    <item cmd="TF or fuzzy match on test-framework" workflow="{project-root}/_bmad/bmm/workflows/testarch/framework/workflow.yaml">[TF] Initialize production-ready test framework architecture</item>
-    <item cmd="AT or fuzzy match on atdd" workflow="{project-root}/_bmad/bmm/workflows/testarch/atdd/workflow.yaml">[AT] Generate E2E tests first, before starting implementation</item>
-    <item cmd="TA or fuzzy match on test-automate" workflow="{project-root}/_bmad/bmm/workflows/testarch/automate/workflow.yaml">[TA] Generate comprehensive test automation</item>
-    <item cmd="TD or fuzzy match on test-design" workflow="{project-root}/_bmad/bmm/workflows/testarch/test-design/workflow.yaml">[TD] Create comprehensive test scenarios</item>
-    <item cmd="TR or fuzzy match on test-trace" workflow="{project-root}/_bmad/bmm/workflows/testarch/trace/workflow.yaml">[TR] Map requirements to tests (Phase 1) and make quality gate decision (Phase 2)</item>
-    <item cmd="NR or fuzzy match on nfr-assess" workflow="{project-root}/_bmad/bmm/workflows/testarch/nfr-assess/workflow.yaml">[NR] Validate non-functional requirements</item>
-    <item cmd="CI or fuzzy match on continuous-integration" workflow="{project-root}/_bmad/bmm/workflows/testarch/ci/workflow.yaml">[CI] Scaffold CI/CD quality pipeline</item>
-    <item cmd="RV or fuzzy match on test-review" workflow="{project-root}/_bmad/bmm/workflows/testarch/test-review/workflow.yaml">[RV] Review test quality using comprehensive knowledge base and best practices</item>
-    <item cmd="PM or fuzzy match on party-mode" exec="{project-root}/_bmad/core/workflows/party-mode/workflow.md">[PM] Start Party Mode</item>
-    <item cmd="DA or fuzzy match on exit, leave, goodbye or dismiss agent">[DA] Dismiss Agent</item>
-  </menu>
-</agent>
-```

_bmad/bmm/agents/tech-writer.md

@@ -1,72 +0,0 @@
----
-name: "tech writer"
-description: "Technical Writer"
----
-
-You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
-
-```xml
-<agent id="tech-writer.agent.yaml" name="Paige" title="Technical Writer" icon="📚">
-<activation critical="MANDATORY">
-      <step n="1">Load persona from this current agent file (already in context)</step>
-      <step n="2">🚨 IMMEDIATE ACTION REQUIRED - BEFORE ANY OUTPUT:
-          - Load and read {project-root}/_bmad/bmm/config.yaml NOW
-          - Store ALL fields as session variables: {user_name}, {communication_language}, {output_folder}
-          - VERIFY: If config not loaded, STOP and report error to user
-          - DO NOT PROCEED to step 3 until config is successfully loaded and variables stored
-      </step>
-      <step n="3">Remember: user's name is {user_name}</step>
-      <step n="4">CRITICAL: Load COMPLETE file {project-root}/_bmad/bmm/data/documentation-standards.md into permanent memory and follow ALL rules within</step>
-  <step n="5">Find if this exists, if it does, always treat it as the bible I plan and execute against: `**/project-context.md`</step>
-      <step n="6">Show greeting using {user_name} from config, communicate in {communication_language}, then display numbered list of ALL menu items from menu section</step>
-      <step n="7">STOP and WAIT for user input - do NOT execute menu items automatically - accept number or cmd trigger or fuzzy command match</step>
-      <step n="8">On user input: Number → execute menu item[n] | Text → case-insensitive substring match | Multiple matches → ask user to clarify | No match → show "Not recognized"</step>
-      <step n="9">When executing a menu item: Check menu-handlers section below - extract any attributes from the selected menu item (workflow, exec, tmpl, data, action, validate-workflow) and follow the corresponding handler instructions</step>
-
-      <menu-handlers>
-              <handlers>
-          <handler type="workflow">
-        When menu item has: workflow="path/to/workflow.yaml":
-        
-        1. CRITICAL: Always LOAD {project-root}/_bmad/core/tasks/workflow.xml
-        2. Read the complete file - this is the CORE OS for executing BMAD workflows
-        3. Pass the yaml path as 'workflow-config' parameter to those instructions
-        4. Execute workflow.xml instructions precisely following all steps
-        5. Save outputs after completing EACH workflow step (never batch multiple steps together)
-        6. If workflow.yaml path is "todo", inform user the workflow hasn't been implemented yet
-      </handler>
-    <handler type="action">
-      When menu item has: action="#id" → Find prompt with id="id" in current agent XML, execute its content
-      When menu item has: action="text" → Execute the text directly as an inline instruction
-    </handler>
-        </handlers>
-      </menu-handlers>
-
-    <rules>
-      <r>ALWAYS communicate in {communication_language} UNLESS contradicted by communication_style.</r>
-            <r> Stay in character until exit selected</r>
-      <r> Display Menu items as the item dictates and in the order given.</r>
-      <r> Load files ONLY when executing a user chosen workflow or a command requires it, EXCEPTION: agent activation step 2 config.yaml</r>
-    </rules>
-</activation>  <persona>
-    <role>Technical Documentation Specialist + Knowledge Curator</role>
-    <identity>Experienced technical writer expert in CommonMark, DITA, OpenAPI. Master of clarity - transforms complex concepts into accessible structured documentation.</identity>
-    <communication_style>Patient educator who explains like teaching a friend. Uses analogies that make complex simple, celebrates clarity when it shines.</communication_style>
-    <principles>- Documentation is teaching. Every doc helps someone accomplish a task. Clarity above all. - Docs are living artifacts that evolve with code. Know when to simplify vs when to be detailed.</principles>
-  </persona>
-  <menu>
-    <item cmd="MH or fuzzy match on menu or help">[MH] Redisplay Menu Help</item>
-    <item cmd="CH or fuzzy match on chat">[CH] Chat with the Agent about anything</item>
-    <item cmd="WS or fuzzy match on workflow-status" workflow="{project-root}/_bmad/bmm/workflows/workflow-status/workflow.yaml">[WS] Get workflow status or initialize a workflow if not already done (optional)</item>
-    <item cmd="DP or fuzzy match on document-project" workflow="{project-root}/_bmad/bmm/workflows/document-project/workflow.yaml">[DP] Comprehensive project documentation (brownfield analysis, architecture scanning)</item>
-    <item cmd="MG or fuzzy match on mermaid-gen" action="Create a Mermaid diagram based on user description. Ask for diagram type (flowchart, sequence, class, ER, state, git) and content, then generate properly formatted Mermaid syntax following CommonMark fenced code block standards.">[MG] Generate Mermaid diagrams (architecture, sequence, flow, ER, class, state)</item>
-    <item cmd="EF or fuzzy match on excalidraw-flowchart" workflow="{project-root}/_bmad/bmm/workflows/excalidraw-diagrams/create-flowchart/workflow.yaml">[EF] Create Excalidraw flowchart for processes and logic flows</item>
-    <item cmd="ED or fuzzy match on excalidraw-diagram" workflow="{project-root}/_bmad/bmm/workflows/excalidraw-diagrams/create-diagram/workflow.yaml">[ED] Create Excalidraw system architecture or technical diagram</item>
-    <item cmd="DF or fuzzy match on dataflow" workflow="{project-root}/_bmad/bmm/workflows/excalidraw-diagrams/create-dataflow/workflow.yaml">[DF] Create Excalidraw data flow diagram</item>
-    <item cmd="VD or fuzzy match on validate-doc" action="Review the specified document against CommonMark standards, technical writing best practices, and style guide compliance. Provide specific, actionable improvement suggestions organized by priority.">[VD] Validate documentation against standards and best practices</item>
-    <item cmd="EC or fuzzy match on explain-concept" action="Create a clear technical explanation with examples and diagrams for a complex concept. Break it down into digestible sections using task-oriented approach. Include code examples and Mermaid diagrams where helpful.">[EC] Create clear technical explanations with examples</item>
-    <item cmd="PM or fuzzy match on party-mode" exec="{project-root}/_bmad/core/workflows/party-mode/workflow.md">[PM] Start Party Mode</item>
-    <item cmd="DA or fuzzy match on exit, leave, goodbye or dismiss agent">[DA] Dismiss Agent</item>
-  </menu>
-</agent>
-```

_bmad/bmm/agents/ux-designer.md

@@ -1,68 +0,0 @@
----
-name: "ux designer"
-description: "UX Designer"
----
-
-You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
-
-```xml
-<agent id="ux-designer.agent.yaml" name="Sally" title="UX Designer" icon="🎨">
-<activation critical="MANDATORY">
-      <step n="1">Load persona from this current agent file (already in context)</step>
-      <step n="2">🚨 IMMEDIATE ACTION REQUIRED - BEFORE ANY OUTPUT:
-          - Load and read {project-root}/_bmad/bmm/config.yaml NOW
-          - Store ALL fields as session variables: {user_name}, {communication_language}, {output_folder}
-          - VERIFY: If config not loaded, STOP and report error to user
-          - DO NOT PROCEED to step 3 until config is successfully loaded and variables stored
-      </step>
-      <step n="3">Remember: user's name is {user_name}</step>
-      <step n="4">Find if this exists, if it does, always treat it as the bible I plan and execute against: `**/project-context.md`</step>
-      <step n="5">Show greeting using {user_name} from config, communicate in {communication_language}, then display numbered list of ALL menu items from menu section</step>
-      <step n="6">STOP and WAIT for user input - do NOT execute menu items automatically - accept number or cmd trigger or fuzzy command match</step>
-      <step n="7">On user input: Number → execute menu item[n] | Text → case-insensitive substring match | Multiple matches → ask user to clarify | No match → show "Not recognized"</step>
-      <step n="8">When executing a menu item: Check menu-handlers section below - extract any attributes from the selected menu item (workflow, exec, tmpl, data, action, validate-workflow) and follow the corresponding handler instructions</step>
-
-      <menu-handlers>
-              <handlers>
-          <handler type="workflow">
-        When menu item has: workflow="path/to/workflow.yaml":
-        
-        1. CRITICAL: Always LOAD {project-root}/_bmad/core/tasks/workflow.xml
-        2. Read the complete file - this is the CORE OS for executing BMAD workflows
-        3. Pass the yaml path as 'workflow-config' parameter to those instructions
-        4. Execute workflow.xml instructions precisely following all steps
-        5. Save outputs after completing EACH workflow step (never batch multiple steps together)
-        6. If workflow.yaml path is "todo", inform user the workflow hasn't been implemented yet
-      </handler>
-      <handler type="exec">
-        When menu item or handler has: exec="path/to/file.md":
-        1. Actually LOAD and read the entire file and EXECUTE the file at that path - do not improvise
-        2. Read the complete file and follow all instructions within it
-        3. If there is data="some/path/data-foo.md" with the same item, pass that data path to the executed file as context.
-      </handler>
-        </handlers>
-      </menu-handlers>
-
-    <rules>
-      <r>ALWAYS communicate in {communication_language} UNLESS contradicted by communication_style.</r>
-            <r> Stay in character until exit selected</r>
-      <r> Display Menu items as the item dictates and in the order given.</r>
-      <r> Load files ONLY when executing a user chosen workflow or a command requires it, EXCEPTION: agent activation step 2 config.yaml</r>
-    </rules>
-</activation>  <persona>
-    <role>User Experience Designer + UI Specialist</role>
-    <identity>Senior UX Designer with 7+ years creating intuitive experiences across web and mobile. Expert in user research, interaction design, AI-assisted tools.</identity>
-    <communication_style>Paints pictures with words, telling user stories that make you FEEL the problem. Empathetic advocate with creative storytelling flair.</communication_style>
-    <principles>- Every decision serves genuine user needs - Start simple, evolve through feedback - Balance empathy with edge case attention - AI tools accelerate human-centered design - Data-informed but always creative</principles>
-  </persona>
-  <menu>
-    <item cmd="MH or fuzzy match on menu or help">[MH] Redisplay Menu Help</item>
-    <item cmd="CH or fuzzy match on chat">[CH] Chat with the Agent about anything</item>
-    <item cmd="WS or fuzzy match on workflow-status" workflow="{project-root}/_bmad/bmm/workflows/workflow-status/workflow.yaml">[WS] Get workflow status or initialize a workflow if not already done (optional)</item>
-    <item cmd="UX or fuzzy match on ux-design" exec="{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-ux-design/workflow.md">[UX] Generate a UX Design and UI Plan from a PRD (Recommended before creating Architecture)</item>
-    <item cmd="XW or fuzzy match on wireframe" workflow="{project-root}/_bmad/bmm/workflows/excalidraw-diagrams/create-wireframe/workflow.yaml">[XW] Create website or app wireframe (Excalidraw)</item>
-    <item cmd="PM or fuzzy match on party-mode" exec="{project-root}/_bmad/core/workflows/party-mode/workflow.md">[PM] Start Party Mode</item>
-    <item cmd="DA or fuzzy match on exit, leave, goodbye or dismiss agent">[DA] Dismiss Agent</item>
-  </menu>
-</agent>
-```

_bmad/bmm/config.yaml

@@ -1,18 +0,0 @@
-# BMM Module Configuration
-# Generated by BMAD installer
-# Version: 6.0.0-alpha.22
-# Date: 2026-01-07T11:38:43.387Z
-
-project_name: 188-179-template-6
-user_skill_level: intermediate
-planning_artifacts: "{project-root}/_bmad-output/planning-artifacts"
-implementation_artifacts: "{project-root}/_bmad-output/implementation-artifacts"
-project_knowledge: "{project-root}/docs"
-tea_use_mcp_enhancements: false
-tea_use_playwright_utils: false
-
-# Core Configuration Values
-user_name: Root
-communication_language: chinese
-document_output_language: chinese
-output_folder: "{project-root}/_bmad-output"

_bmad/bmm/testarch/knowledge/api-testing-patterns.md

@@ -0,0 +1,843 @@
+# API Testing Patterns
+
+## Principle
+
+Test APIs and backend services directly without browser overhead. Use Playwright's `request` context for HTTP operations, `apiRequest` utility for enhanced features, and `recurse` for async operations. Pure API tests run faster, are more stable, and provide better coverage for service-layer logic.
+
+## Rationale
+
+Many teams over-rely on E2E/browser tests when API tests would be more appropriate:
+
+- **Slower feedback**: Browser tests take seconds, API tests take milliseconds
+- **More brittle**: UI changes break tests even when API works correctly
+- **Wrong abstraction**: Testing business logic through UI layers adds noise
+- **Resource heavy**: Browsers consume memory and CPU
+
+API-first testing provides:
+
+- **Fast execution**: No browser startup, no rendering, no JavaScript execution
+- **Direct validation**: Test exactly what the service returns
+- **Better isolation**: Test service logic independent of UI
+- **Easier debugging**: Clear request/response without DOM noise
+- **Contract validation**: Verify API contracts explicitly
+
+## When to Use API Tests vs E2E Tests
+
+| Scenario | API Test | E2E Test |
+|----------|----------|----------|
+| CRUD operations | ✅ Primary | ❌ Overkill |
+| Business logic validation | ✅ Primary | ❌ Overkill |
+| Error handling (4xx, 5xx) | ✅ Primary | ⚠️ Supplement |
+| Authentication flows | ✅ Primary | ⚠️ Supplement |
+| Data transformation | ✅ Primary | ❌ Overkill |
+| User journeys | ❌ Can't test | ✅ Primary |
+| Visual regression | ❌ Can't test | ✅ Primary |
+| Cross-browser issues | ❌ Can't test | ✅ Primary |
+
+**Rule of thumb**: If you're testing what the server returns (not how it looks), use API tests.
+
+## Pattern Examples
+
+### Example 1: Pure API Test (No Browser)
+
+**Context**: Test REST API endpoints directly without any browser context.
+
+**Implementation**:
+
+```typescript
+// tests/api/users.spec.ts
+import { test, expect } from '@playwright/test';
+
+// No page, no browser - just API
+test.describe('Users API', () => {
+  test('should create user', async ({ request }) => {
+    const response = await request.post('/api/users', {
+      data: {
+        name: 'John Doe',
+        email: 'john@example.com',
+        role: 'user',
+      },
+    });
+
+    expect(response.status()).toBe(201);
+
+    const user = await response.json();
+    expect(user.id).toBeDefined();
+    expect(user.name).toBe('John Doe');
+    expect(user.email).toBe('john@example.com');
+  });
+
+  test('should get user by ID', async ({ request }) => {
+    // Create user first
+    const createResponse = await request.post('/api/users', {
+      data: { name: 'Jane Doe', email: 'jane@example.com' },
+    });
+    const { id } = await createResponse.json();
+
+    // Get user
+    const getResponse = await request.get(`/api/users/${id}`);
+    expect(getResponse.status()).toBe(200);
+
+    const user = await getResponse.json();
+    expect(user.id).toBe(id);
+    expect(user.name).toBe('Jane Doe');
+  });
+
+  test('should return 404 for non-existent user', async ({ request }) => {
+    const response = await request.get('/api/users/non-existent-id');
+    expect(response.status()).toBe(404);
+
+    const error = await response.json();
+    expect(error.code).toBe('USER_NOT_FOUND');
+  });
+
+  test('should validate required fields', async ({ request }) => {
+    const response = await request.post('/api/users', {
+      data: { name: 'Missing Email' }, // email is required
+    });
+
+    expect(response.status()).toBe(400);
+
+    const error = await response.json();
+    expect(error.code).toBe('VALIDATION_ERROR');
+    expect(error.details).toContainEqual(
+      expect.objectContaining({ field: 'email', message: expect.any(String) })
+    );
+  });
+});
+```
+
+**Key Points**:
+
+- No `page` fixture needed - only `request`
+- Tests run without browser overhead
+- Direct HTTP assertions
+- Clear error handling tests
+
+### Example 2: API Test with apiRequest Utility
+
+**Context**: Use enhanced apiRequest for schema validation, retry, and type safety.
+
+**Implementation**:
+
+```typescript
+// tests/api/orders.spec.ts
+import { test, expect } from '@seontechnologies/playwright-utils/api-request/fixtures';
+import { z } from 'zod';
+
+// Define schema for type safety and validation
+const OrderSchema = z.object({
+  id: z.string().uuid(),
+  userId: z.string(),
+  items: z.array(
+    z.object({
+      productId: z.string(),
+      quantity: z.number().positive(),
+      price: z.number().positive(),
+    })
+  ),
+  total: z.number().positive(),
+  status: z.enum(['pending', 'processing', 'shipped', 'delivered']),
+  createdAt: z.string().datetime(),
+});
+
+type Order = z.infer<typeof OrderSchema>;
+
+test.describe('Orders API', () => {
+  test('should create order with schema validation', async ({ apiRequest }) => {
+    const { status, body } = await apiRequest<Order>({
+      method: 'POST',
+      path: '/api/orders',
+      body: {
+        userId: 'user-123',
+        items: [
+          { productId: 'prod-1', quantity: 2, price: 29.99 },
+          { productId: 'prod-2', quantity: 1, price: 49.99 },
+        ],
+      },
+      validateSchema: OrderSchema, // Validates response matches schema
+    });
+
+    expect(status).toBe(201);
+    expect(body.id).toBeDefined();
+    expect(body.status).toBe('pending');
+    expect(body.total).toBe(109.97); // 2*29.99 + 49.99
+  });
+
+  test('should handle server errors with retry', async ({ apiRequest }) => {
+    // apiRequest retries 5xx errors by default
+    const { status, body } = await apiRequest({
+      method: 'GET',
+      path: '/api/orders/order-123',
+      retryConfig: {
+        maxRetries: 3,
+        retryDelay: 1000,
+      },
+    });
+
+    expect(status).toBe(200);
+  });
+
+  test('should list orders with pagination', async ({ apiRequest }) => {
+    const { status, body } = await apiRequest<{ orders: Order[]; total: number; page: number }>({
+      method: 'GET',
+      path: '/api/orders',
+      params: { page: 1, limit: 10, status: 'pending' },
+    });
+
+    expect(status).toBe(200);
+    expect(body.orders).toHaveLength(10);
+    expect(body.total).toBeGreaterThan(10);
+    expect(body.page).toBe(1);
+  });
+});
+```
+
+**Key Points**:
+
+- Zod schema for runtime validation AND TypeScript types
+- `validateSchema` throws if response doesn't match
+- Built-in retry for transient failures
+- Type-safe `body` access
+
+### Example 3: Microservice-to-Microservice Testing
+
+**Context**: Test service interactions without browser - validate API contracts between services.
+
+**Implementation**:
+
+```typescript
+// tests/api/service-integration.spec.ts
+import { test, expect } from '@seontechnologies/playwright-utils/fixtures';
+
+test.describe('Service Integration', () => {
+  const USER_SERVICE_URL = process.env.USER_SERVICE_URL || 'http://localhost:3001';
+  const ORDER_SERVICE_URL = process.env.ORDER_SERVICE_URL || 'http://localhost:3002';
+  const INVENTORY_SERVICE_URL = process.env.INVENTORY_SERVICE_URL || 'http://localhost:3003';
+
+  test('order service should validate user exists', async ({ apiRequest }) => {
+    // Create user in user-service
+    const { body: user } = await apiRequest({
+      method: 'POST',
+      path: '/api/users',
+      baseUrl: USER_SERVICE_URL,
+      body: { name: 'Test User', email: 'test@example.com' },
+    });
+
+    // Create order in order-service (should validate user via user-service)
+    const { status, body: order } = await apiRequest({
+      method: 'POST',
+      path: '/api/orders',
+      baseUrl: ORDER_SERVICE_URL,
+      body: {
+        userId: user.id,
+        items: [{ productId: 'prod-1', quantity: 1 }],
+      },
+    });
+
+    expect(status).toBe(201);
+    expect(order.userId).toBe(user.id);
+  });
+
+  test('order service should reject invalid user', async ({ apiRequest }) => {
+    const { status, body } = await apiRequest({
+      method: 'POST',
+      path: '/api/orders',
+      baseUrl: ORDER_SERVICE_URL,
+      body: {
+        userId: 'non-existent-user',
+        items: [{ productId: 'prod-1', quantity: 1 }],
+      },
+    });
+
+    expect(status).toBe(400);
+    expect(body.code).toBe('INVALID_USER');
+  });
+
+  test('order should decrease inventory', async ({ apiRequest, recurse }) => {
+    // Get initial inventory
+    const { body: initialInventory } = await apiRequest({
+      method: 'GET',
+      path: '/api/inventory/prod-1',
+      baseUrl: INVENTORY_SERVICE_URL,
+    });
+
+    // Create order
+    await apiRequest({
+      method: 'POST',
+      path: '/api/orders',
+      baseUrl: ORDER_SERVICE_URL,
+      body: {
+        userId: 'user-123',
+        items: [{ productId: 'prod-1', quantity: 2 }],
+      },
+    });
+
+    // Poll for inventory update (eventual consistency)
+    const { body: updatedInventory } = await recurse(
+      () =>
+        apiRequest({
+          method: 'GET',
+          path: '/api/inventory/prod-1',
+          baseUrl: INVENTORY_SERVICE_URL,
+        }),
+      (response) => response.body.quantity === initialInventory.quantity - 2,
+      { timeout: 10000, interval: 500 }
+    );
+
+    expect(updatedInventory.quantity).toBe(initialInventory.quantity - 2);
+  });
+});
+```
+
+**Key Points**:
+
+- Multiple service URLs for microservice testing
+- Tests service-to-service communication
+- Uses `recurse` for eventual consistency
+- No browser needed for full integration testing
+
+### Example 4: GraphQL API Testing
+
+**Context**: Test GraphQL endpoints with queries and mutations.
+
+**Implementation**:
+
+```typescript
+// tests/api/graphql.spec.ts
+import { test, expect } from '@seontechnologies/playwright-utils/api-request/fixtures';
+
+const GRAPHQL_ENDPOINT = '/graphql';
+
+test.describe('GraphQL API', () => {
+  test('should query users', async ({ apiRequest }) => {
+    const query = `
+      query GetUsers($limit: Int) {
+        users(limit: $limit) {
+          id
+          name
+          email
+          role
+        }
+      }
+    `;
+
+    const { status, body } = await apiRequest({
+      method: 'POST',
+      path: GRAPHQL_ENDPOINT,
+      body: {
+        query,
+        variables: { limit: 10 },
+      },
+    });
+
+    expect(status).toBe(200);
+    expect(body.errors).toBeUndefined();
+    expect(body.data.users).toHaveLength(10);
+    expect(body.data.users[0]).toHaveProperty('id');
+    expect(body.data.users[0]).toHaveProperty('name');
+  });
+
+  test('should create user via mutation', async ({ apiRequest }) => {
+    const mutation = `
+      mutation CreateUser($input: CreateUserInput!) {
+        createUser(input: $input) {
+          id
+          name
+          email
+        }
+      }
+    `;
+
+    const { status, body } = await apiRequest({
+      method: 'POST',
+      path: GRAPHQL_ENDPOINT,
+      body: {
+        query: mutation,
+        variables: {
+          input: {
+            name: 'GraphQL User',
+            email: 'graphql@example.com',
+          },
+        },
+      },
+    });
+
+    expect(status).toBe(200);
+    expect(body.errors).toBeUndefined();
+    expect(body.data.createUser.id).toBeDefined();
+    expect(body.data.createUser.name).toBe('GraphQL User');
+  });
+
+  test('should handle GraphQL errors', async ({ apiRequest }) => {
+    const query = `
+      query GetUser($id: ID!) {
+        user(id: $id) {
+          id
+          name
+        }
+      }
+    `;
+
+    const { status, body } = await apiRequest({
+      method: 'POST',
+      path: GRAPHQL_ENDPOINT,
+      body: {
+        query,
+        variables: { id: 'non-existent' },
+      },
+    });
+
+    expect(status).toBe(200); // GraphQL returns 200 even for errors
+    expect(body.errors).toBeDefined();
+    expect(body.errors[0].message).toContain('not found');
+    expect(body.data.user).toBeNull();
+  });
+
+  test('should handle validation errors', async ({ apiRequest }) => {
+    const mutation = `
+      mutation CreateUser($input: CreateUserInput!) {
+        createUser(input: $input) {
+          id
+        }
+      }
+    `;
+
+    const { status, body } = await apiRequest({
+      method: 'POST',
+      path: GRAPHQL_ENDPOINT,
+      body: {
+        query: mutation,
+        variables: {
+          input: {
+            name: '', // Invalid: empty name
+            email: 'invalid-email', // Invalid: bad format
+          },
+        },
+      },
+    });
+
+    expect(status).toBe(200);
+    expect(body.errors).toBeDefined();
+    expect(body.errors[0].extensions.code).toBe('BAD_USER_INPUT');
+  });
+});
+```
+
+**Key Points**:
+
+- GraphQL queries and mutations via POST
+- Variables passed in request body
+- GraphQL returns 200 even for errors (check `body.errors`)
+- Test validation and business logic errors
+
+### Example 5: Database Seeding and Cleanup via API
+
+**Context**: Use API calls to set up and tear down test data without direct database access.
+
+**Implementation**:
+
+```typescript
+// tests/api/with-data-setup.spec.ts
+import { test, expect } from '@seontechnologies/playwright-utils/fixtures';
+
+test.describe('Orders with Data Setup', () => {
+  let testUser: { id: string; email: string };
+  let testProducts: Array<{ id: string; name: string; price: number }>;
+
+  test.beforeAll(async ({ request }) => {
+    // Seed user via API
+    const userResponse = await request.post('/api/users', {
+      data: {
+        name: 'Test User',
+        email: `test-${Date.now()}@example.com`,
+      },
+    });
+    testUser = await userResponse.json();
+
+    // Seed products via API
+    testProducts = [];
+    for (const product of [
+      { name: 'Widget A', price: 29.99 },
+      { name: 'Widget B', price: 49.99 },
+      { name: 'Widget C', price: 99.99 },
+    ]) {
+      const productResponse = await request.post('/api/products', {
+        data: product,
+      });
+      testProducts.push(await productResponse.json());
+    }
+  });
+
+  test.afterAll(async ({ request }) => {
+    // Cleanup via API
+    if (testUser?.id) {
+      await request.delete(`/api/users/${testUser.id}`);
+    }
+    for (const product of testProducts) {
+      await request.delete(`/api/products/${product.id}`);
+    }
+  });
+
+  test('should create order with seeded data', async ({ apiRequest }) => {
+    const { status, body } = await apiRequest({
+      method: 'POST',
+      path: '/api/orders',
+      body: {
+        userId: testUser.id,
+        items: [
+          { productId: testProducts[0].id, quantity: 2 },
+          { productId: testProducts[1].id, quantity: 1 },
+        ],
+      },
+    });
+
+    expect(status).toBe(201);
+    expect(body.userId).toBe(testUser.id);
+    expect(body.items).toHaveLength(2);
+    expect(body.total).toBe(2 * 29.99 + 49.99);
+  });
+
+  test('should list user orders', async ({ apiRequest }) => {
+    // Create an order first
+    await apiRequest({
+      method: 'POST',
+      path: '/api/orders',
+      body: {
+        userId: testUser.id,
+        items: [{ productId: testProducts[2].id, quantity: 1 }],
+      },
+    });
+
+    // List orders for user
+    const { status, body } = await apiRequest({
+      method: 'GET',
+      path: '/api/orders',
+      params: { userId: testUser.id },
+    });
+
+    expect(status).toBe(200);
+    expect(body.orders.length).toBeGreaterThanOrEqual(1);
+    expect(body.orders.every((o: any) => o.userId === testUser.id)).toBe(true);
+  });
+});
+```
+
+**Key Points**:
+
+- `beforeAll`/`afterAll` for test data setup/cleanup
+- API-based seeding (no direct DB access needed)
+- Unique emails to prevent conflicts in parallel runs
+- Cleanup after all tests complete
+
+### Example 6: Background Job Testing with Recurse
+
+**Context**: Test async operations like background jobs, webhooks, and eventual consistency.
+
+**Implementation**:
+
+```typescript
+// tests/api/background-jobs.spec.ts
+import { test, expect } from '@seontechnologies/playwright-utils/fixtures';
+
+test.describe('Background Jobs', () => {
+  test('should process export job', async ({ apiRequest, recurse }) => {
+    // Trigger export job
+    const { body: job } = await apiRequest({
+      method: 'POST',
+      path: '/api/exports',
+      body: {
+        type: 'users',
+        format: 'csv',
+        filters: { createdAfter: '2024-01-01' },
+      },
+    });
+
+    expect(job.id).toBeDefined();
+    expect(job.status).toBe('pending');
+
+    // Poll until job completes
+    const { body: completedJob } = await recurse(
+      () => apiRequest({ method: 'GET', path: `/api/exports/${job.id}` }),
+      (response) => response.body.status === 'completed',
+      {
+        timeout: 60000,
+        interval: 2000,
+        log: `Waiting for export job ${job.id} to complete`,
+      }
+    );
+
+    expect(completedJob.status).toBe('completed');
+    expect(completedJob.downloadUrl).toBeDefined();
+    expect(completedJob.recordCount).toBeGreaterThan(0);
+  });
+
+  test('should handle job failure gracefully', async ({ apiRequest, recurse }) => {
+    // Trigger job that will fail
+    const { body: job } = await apiRequest({
+      method: 'POST',
+      path: '/api/exports',
+      body: {
+        type: 'invalid-type', // This will cause failure
+        format: 'csv',
+      },
+    });
+
+    // Poll until job fails
+    const { body: failedJob } = await recurse(
+      () => apiRequest({ method: 'GET', path: `/api/exports/${job.id}` }),
+      (response) => ['completed', 'failed'].includes(response.body.status),
+      { timeout: 30000 }
+    );
+
+    expect(failedJob.status).toBe('failed');
+    expect(failedJob.error).toBeDefined();
+    expect(failedJob.error.code).toBe('INVALID_EXPORT_TYPE');
+  });
+
+  test('should process webhook delivery', async ({ apiRequest, recurse }) => {
+    // Trigger action that sends webhook
+    const { body: order } = await apiRequest({
+      method: 'POST',
+      path: '/api/orders',
+      body: {
+        userId: 'user-123',
+        items: [{ productId: 'prod-1', quantity: 1 }],
+        webhookUrl: 'https://webhook.site/test-endpoint',
+      },
+    });
+
+    // Poll for webhook delivery status
+    const { body: webhookStatus } = await recurse(
+      () => apiRequest({ method: 'GET', path: `/api/webhooks/order/${order.id}` }),
+      (response) => response.body.delivered === true,
+      { timeout: 30000, interval: 1000 }
+    );
+
+    expect(webhookStatus.delivered).toBe(true);
+    expect(webhookStatus.deliveredAt).toBeDefined();
+    expect(webhookStatus.responseStatus).toBe(200);
+  });
+});
+```
+
+**Key Points**:
+
+- `recurse` for polling async operations
+- Test both success and failure scenarios
+- Configurable timeout and interval
+- Log messages for debugging
+
+### Example 7: Service Authentication (No Browser)
+
+**Context**: Test authenticated API endpoints using tokens directly - no browser login needed.
+
+**Implementation**:
+
+```typescript
+// tests/api/authenticated.spec.ts
+import { test, expect } from '@seontechnologies/playwright-utils/fixtures';
+
+test.describe('Authenticated API Tests', () => {
+  let authToken: string;
+
+  test.beforeAll(async ({ request }) => {
+    // Get token via API (no browser!)
+    const response = await request.post('/api/auth/login', {
+      data: {
+        email: process.env.TEST_USER_EMAIL,
+        password: process.env.TEST_USER_PASSWORD,
+      },
+    });
+
+    const { token } = await response.json();
+    authToken = token;
+  });
+
+  test('should access protected endpoint with token', async ({ apiRequest }) => {
+    const { status, body } = await apiRequest({
+      method: 'GET',
+      path: '/api/me',
+      headers: {
+        Authorization: `Bearer ${authToken}`,
+      },
+    });
+
+    expect(status).toBe(200);
+    expect(body.email).toBe(process.env.TEST_USER_EMAIL);
+  });
+
+  test('should reject request without token', async ({ apiRequest }) => {
+    const { status, body } = await apiRequest({
+      method: 'GET',
+      path: '/api/me',
+      // No Authorization header
+    });
+
+    expect(status).toBe(401);
+    expect(body.code).toBe('UNAUTHORIZED');
+  });
+
+  test('should reject expired token', async ({ apiRequest }) => {
+    const expiredToken = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...'; // Expired token
+
+    const { status, body } = await apiRequest({
+      method: 'GET',
+      path: '/api/me',
+      headers: {
+        Authorization: `Bearer ${expiredToken}`,
+      },
+    });
+
+    expect(status).toBe(401);
+    expect(body.code).toBe('TOKEN_EXPIRED');
+  });
+
+  test('should handle role-based access', async ({ apiRequest }) => {
+    // User token (non-admin)
+    const { status } = await apiRequest({
+      method: 'GET',
+      path: '/api/admin/users',
+      headers: {
+        Authorization: `Bearer ${authToken}`,
+      },
+    });
+
+    expect(status).toBe(403); // Forbidden for non-admin
+  });
+});
+```
+
+**Key Points**:
+
+- Token obtained via API login (no browser)
+- Token reused across all tests in describe block
+- Test auth, expired tokens, and RBAC
+- Pure API testing without UI
+
+## API Test Configuration
+
+### Playwright Config for API-Only Tests
+
+```typescript
+// playwright.config.ts
+import { defineConfig } from '@playwright/test';
+
+export default defineConfig({
+  testDir: './tests/api',
+
+  // No browser needed for API tests
+  use: {
+    baseURL: process.env.API_URL || 'http://localhost:3000',
+    extraHTTPHeaders: {
+      'Accept': 'application/json',
+      'Content-Type': 'application/json',
+    },
+  },
+
+  // Faster without browser overhead
+  timeout: 30000,
+
+  // Run API tests in parallel
+  workers: 4,
+  fullyParallel: true,
+
+  // No screenshots/traces needed for API tests
+  reporter: [['html'], ['json', { outputFile: 'api-test-results.json' }]],
+});
+```
+
+### Separate API Test Project
+
+```typescript
+// playwright.config.ts
+export default defineConfig({
+  projects: [
+    {
+      name: 'api',
+      testDir: './tests/api',
+      use: {
+        baseURL: process.env.API_URL,
+      },
+    },
+    {
+      name: 'e2e',
+      testDir: './tests/e2e',
+      use: {
+        baseURL: process.env.APP_URL,
+        ...devices['Desktop Chrome'],
+      },
+    },
+  ],
+});
+```
+
+## Comparison: API Tests vs E2E Tests
+
+| Aspect | API Test | E2E Test |
+|--------|----------|----------|
+| **Speed** | ~50-100ms per test | ~2-10s per test |
+| **Stability** | Very stable | More flaky (UI timing) |
+| **Setup** | Minimal | Browser, context, page |
+| **Debugging** | Clear request/response | DOM, screenshots, traces |
+| **Coverage** | Service logic | User experience |
+| **Parallelization** | Easy (stateless) | Complex (browser resources) |
+| **CI Cost** | Low (no browser) | High (browser containers) |
+
+## Related Fragments
+
+- `api-request.md` - apiRequest utility details
+- `recurse.md` - Polling patterns for async operations
+- `auth-session.md` - Token management
+- `contract-testing.md` - Pact contract testing
+- `test-levels-framework.md` - When to use which test level
+- `data-factories.md` - Test data setup patterns
+
+## Anti-Patterns
+
+**DON'T use E2E for API validation:**
+
+```typescript
+// Bad: Testing API through UI
+test('validate user creation', async ({ page }) => {
+  await page.goto('/admin/users');
+  await page.fill('#name', 'John');
+  await page.click('#submit');
+  await expect(page.getByText('User created')).toBeVisible();
+});
+```
+
+**DO test APIs directly:**
+
+```typescript
+// Good: Direct API test
+test('validate user creation', async ({ apiRequest }) => {
+  const { status, body } = await apiRequest({
+    method: 'POST',
+    path: '/api/users',
+    body: { name: 'John' },
+  });
+  expect(status).toBe(201);
+  expect(body.id).toBeDefined();
+});
+```
+
+**DON'T ignore API tests because "E2E covers it":**
+
+```typescript
+// Bad thinking: "Our E2E tests create users, so API is tested"
+// Reality: E2E tests one happy path; API tests cover edge cases
+```
+
+**DO have dedicated API test coverage:**
+
+```typescript
+// Good: Explicit API test suite
+test.describe('Users API', () => {
+  test('creates user', async ({ apiRequest }) => { /* ... */ });
+  test('handles duplicate email', async ({ apiRequest }) => { /* ... */ });
+  test('validates required fields', async ({ apiRequest }) => { /* ... */ });
+  test('handles malformed JSON', async ({ apiRequest }) => { /* ... */ });
+  test('rate limits requests', async ({ apiRequest }) => { /* ... */ });
+});
+```

_bmad/bmm/workflows/2-plan-workflows/prd/data/prd-purpose.md

@@ -0,0 +1,197 @@
+# BMAD PRD Purpose
+
+**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.**
+
+---
+
+## What is a BMAD PRD?
+
+A dual-audience document serving:
+1. **Human Product Managers and builders** - Vision, strategy, stakeholder communication
+2. **LLM Downstream Consumption** - UX Design → Architecture → Epics → Development AI Agents
+
+Each successive document becomes more AI-tailored and granular.
+
+---
+
+## Core Philosophy: Information Density
+
+**High Signal-to-Noise Ratio**
+
+Every sentence must carry information weight. LLMs consume precise, dense content efficiently.
+
+**Anti-Patterns (Eliminate These):**
+- ❌ "The system will allow users to..." → ✅ "Users can..."
+- ❌ "It is important to note that..." → ✅ State the fact directly
+- ❌ "In order to..." → ✅ "To..."
+- ❌ Conversational filler and padding → ✅ Direct, concise statements
+
+**Goal:** Maximum information per word. Zero fluff.
+
+---
+
+## The Traceability Chain
+
+**PRD starts the chain:**
+```
+Vision → Success Criteria → User Journeys → Functional Requirements → (future: User Stories)
+```
+
+**In the PRD, establish:**
+- Vision → Success Criteria alignment
+- Success Criteria → User Journey coverage
+- User Journey → Functional Requirement mapping
+- All requirements traceable to user needs
+
+**Why:** Each downstream artifact (UX, Architecture, Epics, Stories) must trace back to documented user needs and business objectives. This chain ensures we build the right thing.
+
+---
+
+## What Makes Great Functional Requirements?
+
+### FRs are Capabilities, Not Implementation
+
+**Good FR:** "Users can reset their password via email link"
+**Bad FR:** "System sends JWT via email and validates with database" (implementation leakage)
+
+**Good FR:** "Dashboard loads in under 2 seconds for 95th percentile"
+**Bad FR:** "Fast loading time" (subjective, unmeasurable)
+
+### SMART Quality Criteria
+
+**Specific:** Clear, precisely defined capability
+**Measurable:** Quantifiable with test criteria
+**Attainable:** Realistic within constraints
+**Relevant:** Aligns with business objectives
+**Traceable:** Links to source (executive summary or user journey)
+
+### FR Anti-Patterns
+
+**Subjective Adjectives:**
+- ❌ "easy to use", "intuitive", "user-friendly", "fast", "responsive"
+- ✅ Use metrics: "completes task in under 3 clicks", "loads in under 2 seconds"
+
+**Implementation Leakage:**
+- ❌ Technology names, specific libraries, implementation details
+- ✅ Focus on capability and measurable outcomes
+
+**Vague Quantifiers:**
+- ❌ "multiple users", "several options", "various formats"
+- ✅ "up to 100 concurrent users", "3-5 options", "PDF, DOCX, TXT formats"
+
+**Missing Test Criteria:**
+- ❌ "The system shall provide notifications"
+- ✅ "The system shall send email notifications within 30 seconds of trigger event"
+
+---
+
+## What Makes Great Non-Functional Requirements?
+
+### NFRs Must Be Measurable
+
+**Template:**
+```
+"The system shall [metric] [condition] [measurement method]"
+```
+
+**Examples:**
+- ✅ "The system shall respond to API requests in under 200ms for 95th percentile as measured by APM monitoring"
+- ✅ "The system shall maintain 99.9% uptime during business hours as measured by cloud provider SLA"
+- ✅ "The system shall support 10,000 concurrent users as measured by load testing"
+
+### NFR Anti-Patterns
+
+**Unmeasurable Claims:**
+- ❌ "The system shall be scalable" → ✅ "The system shall handle 10x load growth through horizontal scaling"
+- ❌ "High availability required" → ✅ "99.9% uptime as measured by cloud provider SLA"
+
+**Missing Context:**
+- ❌ "Response time under 1 second" → ✅ "API response time under 1 second for 95th percentile under normal load"
+
+---
+
+## Domain-Specific Requirements
+
+**Auto-Detect and Enforce Based on Project Context**
+
+Certain industries have mandatory requirements that must be present:
+
+- **Healthcare:** HIPAA Privacy & Security Rules, PHI encryption, audit logging, MFA
+- **Fintech:** PCI-DSS Level 1, AML/KYC compliance, SOX controls, financial audit trails
+- **GovTech:** NIST framework, Section 508 accessibility (WCAG 2.1 AA), FedRAMP, data residency
+- **E-Commerce:** PCI-DSS for payments, inventory accuracy, tax calculation by jurisdiction
+
+**Why:** Missing these requirements in the PRD means they'll be missed in architecture and implementation, creating expensive rework. During PRD creation there is a step to cover this - during validation we want to make sure it was covered. For this purpose steps will utilize a domain-complexity.csv and project-types.csv.
+
+---
+
+## Document Structure (Markdown, Human-Readable)
+
+### Required Sections
+1. **Executive Summary** - Vision, differentiator, target users
+2. **Success Criteria** - Measurable outcomes (SMART)
+3. **Product Scope** - MVP, Growth, Vision phases
+4. **User Journeys** - Comprehensive coverage
+5. **Domain Requirements** - Industry-specific compliance (if applicable)
+6. **Innovation Analysis** - Competitive differentiation (if applicable)
+7. **Project-Type Requirements** - Platform-specific needs
+8. **Functional Requirements** - Capability contract (FRs)
+9. **Non-Functional Requirements** - Quality attributes (NFRs)
+
+### Formatting for Dual Consumption
+
+**For Humans:**
+- Clear, professional language
+- Logical flow from vision to requirements
+- Easy for stakeholders to review and approve
+
+**For LLMs:**
+- ## Level 2 headers for all main sections (enables extraction)
+- Consistent structure and patterns
+- Precise, testable language
+- High information density
+
+---
+
+## Downstream Impact
+
+**How the PRD Feeds Next Artifacts:**
+
+**UX Design:**
+- User journeys → interaction flows
+- FRs → design requirements
+- Success criteria → UX metrics
+
+**Architecture:**
+- FRs → system capabilities
+- NFRs → architecture decisions
+- Domain requirements → compliance architecture
+- Project-type requirements → platform choices
+
+**Epics & Stories (created after architecture):**
+- FRs → user stories (1 FR could map to 1-3 stories potentially)
+- Acceptance criteria → story acceptance tests
+- Priority → sprint sequencing
+- Traceability → stories map back to vision
+
+**Development AI Agents:**
+- Precise requirements → implementation clarity
+- Test criteria → automated test generation
+- Domain requirements → compliance enforcement
+- Measurable NFRs → performance targets
+
+---
+
+## Summary: What Makes a Great BMAD PRD?
+
+✅ **High Information Density** - Every sentence carries weight, zero fluff
+✅ **Measurable Requirements** - All FRs and NFRs are testable with specific criteria
+✅ **Clear Traceability** - Each requirement links to user need and business objective
+✅ **Domain Awareness** - Industry-specific requirements auto-detected and included
+✅ **Zero Anti-Patterns** - No subjective adjectives, implementation leakage, or vague quantifiers
+✅ **Dual Audience Optimized** - Human-readable AND LLM-consumable
+✅ **Markdown Format** - Professional, clean, accessible to all stakeholders
+
+---
+
+**Remember:** The PRD is the foundation. Quality here ripples through every subsequent phase. A dense, precise, well-traced PRD makes UX design, architecture, epic breakdown, and AI development dramatically more effective.

_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-01-init.md → _bmad/bmm/workflows/2-plan-workflows/prd/steps-c/step-01-init.md

@@ -2,19 +2,13 @@
 name: 'step-01-init'
 description: 'Initialize the PRD workflow by detecting continuation state and setting up the document'
 
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd'
-
 # File References
-thisStepFile: '{workflow_path}/steps/step-01-init.md'
-nextStepFile: '{workflow_path}/steps/step-02-discovery.md'
-continueStepFile: '{workflow_path}/steps/step-01b-continue.md'
-workflowFile: '{workflow_path}/workflow.md'
+nextStepFile: './step-02-discovery.md'
+continueStepFile: './step-01b-continue.md'
 outputFile: '{planning_artifacts}/prd.md'
 
-
-# Template References
-prdTemplate: '{workflow_path}/prd-template.md'
+# Template Reference
+prdTemplate: '../templates/prd-template.md'
 ---
 
 # Step 1: Workflow Initialization
@@ -157,7 +151,7 @@ Display menu after setup report:
 
 #### Menu Handling Logic:
 
-- IF C: Update frontmatter with `stepsCompleted: [1]`, then load, read entire {nextStepFile}, then execute {nextStepFile}
+- IF C: Update output file frontmatter, adding this step name to the end of the list of stepsCompleted, then load, read entire {nextStepFile}, then execute {nextStepFile}
 - IF user provides additional files: Load them, update inputDocuments and documentCounts, redisplay report
 - IF user asks questions: Answer and redisplay menu
 
@@ -168,7 +162,7 @@ Display menu after setup report:
 
 ## CRITICAL STEP COMPLETION NOTE
 
-ONLY WHEN [C continue option] is selected and [frontmatter properly updated with stepsCompleted: [1] and documentCounts], will you then load and read fully `{nextStepFile}` to execute and begin project discovery.
+ONLY WHEN [C continue option] is selected and [frontmatter properly updated with this step added to stepsCompleted and documentCounts], will you then load and read fully `{nextStepFile}` to execute and begin project discovery.
 
 ---
 
@@ -182,7 +176,7 @@ ONLY WHEN [C continue option] is selected and [frontmatter properly updated with
 - All discovered files tracked in frontmatter `inputDocuments`
 - User clearly informed of brownfield vs greenfield status
 - Menu presented and user input handled correctly
-- Frontmatter updated with `stepsCompleted: [1]` before proceeding
+- Frontmatter updated with this step name added to stepsCompleted before proceeding
 
 ### ❌ SYSTEM FAILURE:
 

_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-01b-continue.md → _bmad/bmm/workflows/2-plan-workflows/prd/steps-c/step-01b-continue.md

@@ -2,12 +2,7 @@
 name: 'step-01b-continue'
 description: 'Resume an interrupted PRD workflow from the last completed step'
 
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd'
-
 # File References
-thisStepFile: '{workflow_path}/steps/step-01b-continue.md'
-workflowFile: '{workflow_path}/workflow.md'
 outputFile: '{planning_artifacts}/prd.md'
 ---
 
@@ -60,10 +55,9 @@ Resume the PRD workflow from where it was left off, ensuring smooth continuation
 **State Assessment:**
 Review the frontmatter to understand:
 
-- `stepsCompleted`: Which steps are already done
-- `lastStep`: The most recently completed step number
+- `stepsCompleted`: Array of completed step filenames
+- Last element of `stepsCompleted` array: The most recently completed step
 - `inputDocuments`: What context was already loaded
-- `documentCounts`: briefs, research, brainstorming, projectDocs counts
 - All other frontmatter variables
 
 ### 2. Restore Context Documents
@@ -74,47 +68,27 @@ Review the frontmatter to understand:
 - This ensures you have full context for continuation
 - Don't discover new documents - only reload what was previously processed
 
-### 3. Present Current Progress
-
-**Progress Report to User:**
-"Welcome back {{user_name}}! I'm resuming our PRD collaboration for {{project_name}}.
-
-**Current Progress:**
-
-- Steps completed: {stepsCompleted}
-- Last worked on: Step {lastStep}
-- Context documents available: {len(inputDocuments)} files
-
-**Document Status:**
-
-- Current PRD document is ready with all completed sections
-- Ready to continue from where we left off
-
-Does this look right, or do you want to make any adjustments before we proceed?"
-
-### 4. Determine Continuation Path
+### 3. Determine Next Step
 
-**Next Step Logic:**
-Based on `lastStep` value, determine which step to load next:
+**Simplified Next Step Logic:**
+1. Get the last element from the `stepsCompleted` array (this is the filename of the last completed step, e.g., "step-03-success.md")
+2. Load that step file and read its frontmatter
+3. Extract the `nextStepFile` value from the frontmatter
+4. That's the next step to load!
 
-- If `lastStep = 1` → Load `./step-02-discovery.md`
-- If `lastStep = 2` → Load `./step-03-success.md`
-- If `lastStep = 3` → Load `./step-04-journeys.md`
-- If `lastStep = 4` → Load `./step-05-domain.md`
-- If `lastStep = 5` → Load `./step-06-innovation.md`
-- If `lastStep = 6` → Load `./step-07-project-type.md`
-- If `lastStep = 7` → Load `./step-08-scoping.md`
-- If `lastStep = 8` → Load `./step-09-functional.md`
-- If `lastStep = 9` → Load `./step-10-nonfunctional.md`
-- If `lastStep = 10` → Load `./step-11-complete.md`
-- If `lastStep = 11` → Workflow already complete
+**Example:**
+- If `stepsCompleted = ["step-01-init.md", "step-02-discovery.md", "step-03-success.md"]`
+- Last element is `"step-03-success.md"`
+- Load `step-03-success.md`, read its frontmatter
+- Find `nextStepFile: './step-04-journeys.md'`
+- Next step to load is `./step-04-journeys.md`
 
-### 5. Handle Workflow Completion
+### 4. Handle Workflow Completion
 
-**If workflow already complete (`lastStep = 11`):**
+**If `stepsCompleted` array contains `"step-11-complete.md"`:**
 "Great news! It looks like we've already completed the PRD workflow for {{project_name}}.
 
-The final document is ready at `{outputFile}` with all sections completed through step 11.
+The final document is ready at `{outputFile}` with all sections completed.
 
 Would you like me to:
 
@@ -124,16 +98,29 @@ Would you like me to:
 
 What would be most helpful?"
 
-### 6. Present MENU OPTIONS
+### 5. Present Current Progress
 
 **If workflow not complete:**
-Display: "Ready to continue with Step {nextStepNumber}?
+"Welcome back {{user_name}}! I'm resuming our PRD collaboration for {{project_name}}.
+
+**Current Progress:**
+- Last completed: {last step filename from stepsCompleted array}
+- Next up: {nextStepFile determined from that step's frontmatter}
+- Context documents available: {len(inputDocuments)} files
+
+**Document Status:**
+- Current PRD document is ready with all completed sections
+- Ready to continue from where we left off
+
+Does this look right, or do you want to make any adjustments before we proceed?"
+
+### 6. Present MENU OPTIONS
 
-**Select an Option:** [C] Continue to next step"
+Display: "**Select an Option:** [C] Continue to {next step name}"
 
 #### Menu Handling Logic:
 
-- IF C: Load, read entire file, then execute the appropriate next step file based on `lastStep`
+- IF C: Load, read entire file, then execute the {nextStepFile} determined in step 3
 - IF Any other comments or queries: respond and redisplay menu
 
 #### EXECUTION RULES:
@@ -143,7 +130,7 @@ Display: "Ready to continue with Step {nextStepNumber}?
 
 ## CRITICAL STEP COMPLETION NOTE
 
-ONLY WHEN [C continue option] is selected and [current state confirmed], will you then load and read fully the appropriate next step file to resume the workflow.
+ONLY WHEN [C continue option] is selected and [current state confirmed], will you then load and read fully the {nextStepFile} to resume the workflow.
 
 ---
 
@@ -160,7 +147,7 @@ ONLY WHEN [C continue option] is selected and [current state confirmed], will yo
 
 - Discovering new input documents instead of reloading existing ones
 - Modifying content from already completed steps
-- Loading wrong next step based on `lastStep` value
+- Failing to extract nextStepFile from the last completed step's frontmatter
 - Proceeding without user confirmation of current state
 
 **Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-c/step-02-discovery.md

@@ -0,0 +1,224 @@
+---
+name: 'step-02-discovery'
+description: 'Discover project type, domain, and context through collaborative dialogue'
+
+# File References
+nextStepFile: './step-03-success.md'
+outputFile: '{planning_artifacts}/prd.md'
+
+# Data Files
+projectTypesCSV: '../data/project-types.csv'
+domainComplexityCSV: '../data/domain-complexity.csv'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 2: Project Discovery
+
+**Progress: Step 2 of 13** - Next: Product Vision
+
+## STEP GOAL:
+
+Discover and classify the project - understand what type of product this is, what domain it operates in, and the project context (greenfield vs brownfield).
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
+- ✅ ALWAYS treat this as collaborative discovery between PM peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a product-focused PM facilitator collaborating with an expert peer
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision
+
+### Step-Specific Rules:
+
+- 🎯 Focus on classification and understanding - no content generation yet
+- 🚫 FORBIDDEN to generate executive summary or vision statements (that's next steps)
+- 💬 APPROACH: Natural conversation to understand the project
+- 🎯 LOAD classification data BEFORE starting discovery conversation
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after classification complete
+- 💾 ONLY save classification to frontmatter when user chooses C (Continue)
+- 📖 Update frontmatter, adding this step to the end of the list of stepsCompleted
+- 🚫 FORBIDDEN to load next step until C is selected
+
+## CONTEXT BOUNDARIES:
+
+- Current document and frontmatter from step 1 are available
+- Input documents already loaded are in memory (product briefs, research, brainstorming, project docs)
+- **Document counts available in frontmatter `documentCounts`**
+- Classification CSV data will be loaded in this step only
+- No executive summary or vision content yet (that's steps 2b and 2c)
+
+## YOUR TASK:
+
+Discover and classify the project through natural conversation:
+- What type of product is this? (web app, API, mobile, etc.)
+- What domain does it operate in? (healthcare, fintech, e-commerce, etc.)
+- What's the project context? (greenfield new product vs brownfield existing system)
+- How complex is this domain? (low, medium, high)
+
+## DISCOVERY SEQUENCE:
+
+### 1. Check Document State
+
+Read the frontmatter from `{outputFile}` to get document counts:
+- `briefCount` - Product briefs available
+- `researchCount` - Research documents available
+- `brainstormingCount` - Brainstorming docs available
+- `projectDocsCount` - Existing project documentation
+
+**Announce your understanding:**
+
+"From step 1, I have loaded:
+- Product briefs: {{briefCount}}
+- Research: {{researchCount}}
+- Brainstorming: {{brainstormingCount}}
+- Project docs: {{projectDocsCount}}
+
+{{if projectDocsCount > 0}}This is a brownfield project - I'll focus on understanding what you want to add or change.{{else}}This is a greenfield project - I'll help you define the full product vision.{{/if}}"
+
+### 2. Load Classification Data
+
+**Attempt subprocess data lookup:**
+
+**Project Type Lookup:**
+"Your task: Lookup data in {projectTypesCSV}
+
+**Search criteria:**
+- Find row where project_type matches {{detectedProjectType}}
+
+**Return format:**
+Return ONLY the matching row as a YAML-formatted object with these fields:
+project_type, detection_signals
+
+**Do NOT return the entire CSV - only the matching row.**"
+
+**Domain Complexity Lookup:**
+"Your task: Lookup data in {domainComplexityCSV}
+
+**Search criteria:**
+- Find row where domain matches {{detectedDomain}}
+
+**Return format:**
+Return ONLY the matching row as a YAML-formatted object with these fields:
+domain, complexity, typical_concerns, compliance_requirements
+
+**Do NOT return the entire CSV - only the matching row.**"
+
+**Graceful degradation (if Task tool unavailable):**
+- Load the CSV files directly
+- Find the matching rows manually
+- Extract required fields
+- Keep in memory for intelligent classification
+
+### 3. Begin Discovery Conversation
+
+**Start with what you know:**
+
+If the user has a product brief or project docs, acknowledge them and share your understanding. Then ask clarifying questions to deepen your understanding.
+
+If this is a greenfield project with no docs, start with open-ended discovery:
+- What problem does this solve?
+- Who's it for?
+- What excites you about building this?
+
+**Listen for classification signals:**
+
+As the user describes their product, match against:
+- **Project type signals** (API, mobile, SaaS, etc.)
+- **Domain signals** (healthcare, fintech, education, etc.)
+- **Complexity indicators** (regulated industries, novel technology, etc.)
+
+### 4. Confirm Classification
+
+Once you have enough understanding, share your classification:
+
+"I'm hearing this as:
+- **Project Type:** {{detectedType}}
+- **Domain:** {{detectedDomain}}
+- **Complexity:** {{complexityLevel}}
+
+Does this sound right to you?"
+
+Let the user confirm or refine your classification.
+
+### 5. Save Classification to Frontmatter
+
+When user selects 'C', update frontmatter with classification:
+```yaml
+classification:
+  projectType: {{projectType}}
+  domain: {{domain}}
+  complexity: {{complexityLevel}}
+  projectContext: {{greenfield|brownfield}}
+```
+
+### N. Present MENU OPTIONS
+
+Present the project classification for review, then display menu:
+
+"Based on our conversation, I've discovered and classified your project.
+
+**Here's the classification:**
+
+**Project Type:** {{detectedType}}
+**Domain:** {{detectedDomain}}
+**Complexity:** {{complexityLevel}}
+**Project Context:** {{greenfield|brownfield}}
+
+**What would you like to do?**"
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Product Vision (Step 2b of 13)"
+
+#### Menu Handling Logic:
+- IF A: Execute {advancedElicitationTask} with the current classification, process the enhanced insights that come back, ask user if they accept the improvements, if yes update classification then redisplay menu, if no keep original classification then redisplay menu
+- IF P: Execute {partyModeWorkflow} with the current classification, process the collaborative insights, ask user if they accept the changes, if yes update classification then redisplay menu, if no keep original classification then redisplay menu
+- IF C: Save classification to {outputFile} frontmatter, add this step name to the end of stepsCompleted array, then load, read entire file, then execute {nextStepFile}
+- IF Any other: help user respond, then redisplay menu
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- After other menu items execution, return to this menu
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN [C continue option] is selected and [classification saved to frontmatter], will you then load and read fully `{nextStepFile}` to explore product vision.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Document state checked and announced to user
+- Classification data loaded and used intelligently
+- Natural conversation to understand project type, domain, complexity
+- Classification validated with user before saving
+- Frontmatter updated with classification when C selected
+- User's existing documents acknowledged and built upon
+
+### ❌ SYSTEM FAILURE:
+
+- Not reading documentCounts from frontmatter first
+- Skipping classification data loading
+- Generating executive summary or vision content (that's later steps!)
+- Not validating classification with user
+- Being prescriptive instead of having natural conversation
+- Proceeding without user selecting 'C'
+
+**Master Rule:** This is classification and understanding only. No content generation yet. Build on what the user already has. Have natural conversations, don't follow scripts.

_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-03-success.md → _bmad/bmm/workflows/2-plan-workflows/prd/steps-c/step-03-success.md

@@ -2,13 +2,8 @@
 name: 'step-03-success'
 description: 'Define comprehensive success criteria covering user, business, and technical success'
 
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd'
-
 # File References
-thisStepFile: '{workflow_path}/steps/step-03-success.md'
-nextStepFile: '{workflow_path}/steps/step-04-journeys.md'
-workflowFile: '{workflow_path}/workflow.md'
+nextStepFile: './step-04-journeys.md'
 outputFile: '{planning_artifacts}/prd.md'
 
 # Task References
@@ -37,24 +32,9 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
 - 🎯 Show your analysis before taking any action
 - ⚠️ Present A/P/C menu after generating success criteria content
 - 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
+- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
 - 🚫 FORBIDDEN to load next step until C is selected
 
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to develop deeper insights about success metrics
-- **P (Party Mode)**: Bring multiple perspectives to define comprehensive success criteria
-- **C (Continue)**: Save the content to the document and proceed to next step
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml
-- When 'P' selected: Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md
-- PROTOCOLS always return to this step's A/P/C menu
-- User accepts/rejects protocol changes before proceeding
-
 ## CONTEXT BOUNDARIES:
 
 - Current document and frontmatter from previous steps are available
@@ -76,38 +56,21 @@ Define comprehensive success criteria that cover user success, business success,
 Analyze product brief, research, and brainstorming documents for success criteria already mentioned.
 
 **If Input Documents Contain Success Criteria:**
-"Looking at your product brief and research, I see some initial success criteria already defined:
-
-**From your brief:**
-{{extracted_success_criteria_from_brief}}
-
-**From research:**
-{{extracted_success_criteria_from_research}}
-
-**From brainstorming:**
-{{extracted_success_criteria_from_brainstorming}}
-
-This gives us a great foundation. Let's refine and expand on these initial thoughts:
-
-**User Success First:**
-Based on what we have, how would you refine these user success indicators:
-
-- {{refined_user_success_from_documents}}
-- Are there other user success metrics we should consider?
-
-**What would make a user say 'this was worth it'** beyond what's already captured?"
+Guide user to refine existing success criteria:
+- Acknowledge what's already documented in their materials
+- Extract key success themes from brief, research, and brainstorming
+- Help user identify gaps and areas for expansion
+- Probe for specific, measurable outcomes: When do users feel delighted/relieved/empowered?
+- Ask about emotional success moments and completion scenarios
+- Explore what "worth it" means beyond what's already captured
 
 **If No Success Criteria in Input Documents:**
-Start with user-centered success:
-"Now that we understand what makes {{project_name}} special, let's define what success looks like.
-
-**User Success First:**
-
-- What would make a user say 'this was worth it'?
-- What's the moment where they realize this solved their problem?
-- After using {{project_name}}, what outcome are they walking away with?
-
-Let's start with the user experience of success."
+Start with user-centered success exploration:
+- Guide conversation toward defining what "worth it" means for users
+- Ask about the moment users realize their problem is solved
+- Explore specific user outcomes and emotional states
+- Identify success "aha!" moments and completion scenarios
+- Focus on user experience of success first
 
 ### 2. Explore User Success Metrics
 
@@ -121,15 +84,11 @@ Listen for specific user outcomes and help make them measurable:
 ### 3. Define Business Success
 
 Transition to business metrics:
-"Now let's look at success from the business perspective.
-
-**Business Success:**
-
-- What does success look like at 3 months? 12 months?
-- Are we measuring revenue, user growth, engagement, something else?
-- What metric would make you say 'this is working'?
-
-Help me understand what success means for your business."
+- Guide conversation to business perspective on success
+- Explore timelines: What does 3-month success look like? 12-month success?
+- Identify key business metrics: revenue, user growth, engagement, or other measures?
+- Ask what specific metric would indicate "this is working"
+- Understand business success from their perspective
 
 ### 4. Challenge Vague Metrics
 
@@ -143,31 +102,25 @@ Push for specificity on business metrics:
 ### 5. Connect to Product Differentiator
 
 Tie success metrics back to what makes the product special:
-"So success means users experience [differentiator] and achieve [outcome]. Does that capture it?"
-
-Adapt success criteria to context:
-
-- Consumer: User love, engagement, retention
-- B2B: ROI, efficiency, adoption
-- Developer tools: Developer experience, community
-- Regulated: Compliance, safety, validation
-- GovTech: Government compliance, accessibility, procurement
+- Connect success criteria to the product's unique differentiator
+- Ensure metrics reflect the specific value proposition
+- Adapt success criteria to domain context:
+  - Consumer: User love, engagement, retention
+  - B2B: ROI, efficiency, adoption
+  - Developer tools: Developer experience, community
+  - Regulated: Compliance, safety, validation
+  - GovTech: Government compliance, accessibility, procurement
 
 ### 6. Smart Scope Negotiation
 
 Guide scope definition through success lens:
-"The Scoping Game:
-
-1. What must work for this to be useful? → MVP
-2. What makes it competitive? → Growth
-3. What's the dream version? → Vision
-
-Challenge scope creep conversationally:
-
-- Could that wait until after launch?
-- Is that essential for proving the concept?
-
-For complex domains, include compliance minimums in MVP."
+- Help user distinguish MVP (must work to be useful) from growth (competitive) and vision (dream)
+- Guide conversation through three scope levels:
+  1. MVP: What's essential for proving the concept?
+  2. Growth: What makes it competitive?
+  3. Vision: What's the dream version?
+- Challenge scope creep conversationally: Could this wait until after launch? Is this essential for MVP?
+- For complex domains: Ensure compliance minimums are included in MVP
 
 ### 7. Generate Success Criteria Content
 
@@ -211,43 +164,26 @@ When saving to document, append these Level 2 and Level 3 sections:
 [Content about future vision based on conversation]
 ```
 
-### 8. Present Content and Menu
-
-Show the generated content and present choices:
-"I've drafted our success criteria and scope definition based on our conversation.
-
-**Here's what I'll add to the document:**
-
-[Show the complete markdown content from step 7]
-
-**What would you like to do?**
-[A] Advanced Elicitation - Let's dive deeper and refine these success metrics
-[P] Party Mode - Bring in different perspectives on success criteria
-[C] Continue - Save success criteria and move to User Journey Mapping (Step 4 of 11)"
-
-### 9. Handle Menu Selection
-
-#### If 'A' (Advanced Elicitation):
+### 8. Present MENU OPTIONS
 
-- Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml with the current success criteria content
-- Process the enhanced success metrics that come back
-- Ask user: "Accept these improvements to the success criteria? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
+Present the success criteria content for user review, then display menu:
 
-#### If 'P' (Party Mode):
+- Show the drafted success criteria and scope definition (using structure from section 7)
+- Ask if they'd like to refine further, get other perspectives, or proceed
+- Present menu options naturally as part of the conversation
 
-- Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md with the current success criteria
-- Process the collaborative improvements to metrics and scope
-- Ask user: "Accept these changes to the success criteria? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to User Journey Mapping (Step 4 of 11)"
 
-#### If 'C' (Continue):
+#### Menu Handling Logic:
+- IF A: Execute {advancedElicitationTask} with the current success criteria content, process the enhanced success metrics that come back, ask user "Accept these improvements to the success criteria? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
+- IF P: Execute {partyModeWorkflow} with the current success criteria, process the collaborative improvements to metrics and scope, ask user "Accept these changes to the success criteria? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
+- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then load, read entire file, then execute {nextStepFile}
+- IF Any other: help user respond, then redisplay menu
 
-- Append the final content to `{outputFile}`
-- Update frontmatter: add this step to the end of the steps completed array
-- Load `./step-04-journeys.md`
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- After other menu items execution, return to this menu
 
 ## APPEND TO DOCUMENT:
 

_bmad/bmm/workflows/2-plan-workflows/prd/steps-c/step-04-journeys.md

@@ -0,0 +1,213 @@
+---
+name: 'step-04-journeys'
+description: 'Map ALL user types that interact with the system with narrative story-based journeys'
+
+# File References
+nextStepFile: './step-05-domain.md'
+outputFile: '{planning_artifacts}/prd.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 4: User Journey Mapping
+
+**Progress: Step 4 of 11** - Next: Domain Requirements
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+- 🛑 NEVER generate content without user input
+
+- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
+- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
+- ✅ ALWAYS treat this as collaborative discovery between PM peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- 💬 FOCUS on mapping ALL user types that interact with the system
+- 🎯 CRITICAL: No journey = no functional requirements = product doesn't exist
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating journey content
+- 💾 ONLY save when user chooses C (Continue)
+- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
+- 🚫 FORBIDDEN to load next step until C is selected
+
+## CONTEXT BOUNDARIES:
+
+- Current document and frontmatter from previous steps are available
+- Success criteria and scope already defined
+- Input documents from step-01 are available (product briefs with user personas)
+- Every human interaction with the system needs a journey
+
+## YOUR TASK:
+
+Create compelling narrative user journeys that leverage existing personas from product briefs and identify additional user types needed for comprehensive coverage.
+
+## JOURNEY MAPPING SEQUENCE:
+
+### 1. Leverage Existing Users & Identify Additional Types
+
+**Check Input Documents for Existing Personas:**
+Analyze product brief, research, and brainstorming documents for user personas already defined.
+
+**If User Personas Exist in Input Documents:**
+Guide user to build on existing personas:
+- Acknowledge personas found in their product brief
+- Extract key persona details and backstories
+- Leverage existing insights about their needs
+- Prompt to identify additional user types beyond those documented
+- Suggest additional user types based on product context (admins, moderators, support, API consumers, internal ops)
+- Ask what additional user types should be considered
+
+**If No Personas in Input Documents:**
+Start with comprehensive user type discovery:
+- Guide exploration of ALL people who interact with the system
+- Consider beyond primary users: admins, moderators, support staff, API consumers, internal ops
+- Ask what user types should be mapped for this specific product
+- Ensure comprehensive coverage of all system interactions
+
+### 2. Create Narrative Story-Based Journeys
+
+For each user type, create compelling narrative journeys that tell their story:
+
+#### Narrative Journey Creation Process:
+
+**If Using Existing Persona from Input Documents:**
+Guide narrative journey creation:
+- Use persona's existing backstory from brief
+- Explore how the product changes their life/situation
+- Craft journey narrative: where do we meet them, how does product help them write their next chapter?
+
+**If Creating New Persona:**
+Guide persona creation with story framework:
+- Name: realistic name and personality
+- Situation: What's happening in their life/work that creates need?
+- Goal: What do they desperately want to achieve?
+- Obstacle: What's standing in their way?
+- Solution: How does the product solve their story?
+
+**Story-Based Journey Mapping:**
+
+Guide narrative journey creation using story structure:
+- **Opening Scene**: Where/how do we meet them? What's their current pain?
+- **Rising Action**: What steps do they take? What do they discover?
+- **Climax**: Critical moment where product delivers real value
+- **Resolution**: How does their situation improve? What's their new reality?
+
+Encourage narrative format with specific user details, emotional journey, and clear before/after contrast
+
+### 3. Guide Journey Exploration
+
+For each journey, facilitate detailed exploration:
+- What happens at each step specifically?
+- What could go wrong? What's the recovery path?
+- What information do they need to see/hear?
+- What's their emotional state at each point?
+- Where does this journey succeed or fail?
+
+### 4. Connect Journeys to Requirements
+
+After each journey, explicitly state:
+- This journey reveals requirements for specific capability areas
+- Help user see how different journeys create different feature sets
+- Connect journey needs to concrete capabilities (onboarding, dashboards, notifications, etc.)
+
+### 5. Aim for Comprehensive Coverage
+
+Guide toward complete journey set:
+
+- **Primary user** - happy path (core experience)
+- **Primary user** - edge case (different goal, error recovery)
+- **Secondary user** (admin, moderator, support, etc.)
+- **API consumer** (if applicable)
+
+Ask if additional journeys are needed to cover uncovered user types
+
+### 6. Generate User Journey Content
+
+Prepare the content to append to the document:
+
+#### Content Structure:
+
+When saving to document, append these Level 2 and Level 3 sections:
+
+```markdown
+## User Journeys
+
+[All journey narratives based on conversation]
+
+### Journey Requirements Summary
+
+[Summary of capabilities revealed by journeys based on conversation]
+```
+
+### 7. Present MENU OPTIONS
+
+Present the user journey content for review, then display menu:
+- Show the mapped user journeys (using structure from section 6)
+- Highlight how each journey reveals different capabilities
+- Ask if they'd like to refine further, get other perspectives, or proceed
+- Present menu options naturally as part of conversation
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Domain Requirements (Step 5 of 11)"
+
+#### Menu Handling Logic:
+- IF A: Execute {advancedElicitationTask} with the current journey content, process the enhanced journey insights that come back, ask user "Accept these improvements to the user journeys? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
+- IF P: Execute {partyModeWorkflow} with the current journeys, process the collaborative journey improvements and additions, ask user "Accept these changes to the user journeys? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
+- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then load, read entire file, then execute {nextStepFile}
+- IF Any other: help user respond, then redisplay menu
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- After other menu items execution, return to this menu
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', append the content directly to the document using the structure from step 6.
+
+## SUCCESS METRICS:
+
+✅ Existing personas from product briefs leveraged when available
+✅ All user types identified (not just primary users)
+✅ Rich narrative storytelling for each persona and journey
+✅ Complete story-based journey mapping with emotional arc
+✅ Journey requirements clearly connected to capabilities needed
+✅ Minimum 3-4 compelling narrative journeys covering different user types
+✅ A/P/C menu presented and handled correctly
+✅ Content properly appended to document when C selected
+
+## FAILURE MODES:
+
+❌ Ignoring existing personas from product briefs
+❌ Only mapping primary user journeys and missing secondary users
+❌ Creating generic journeys without rich persona details and narrative
+❌ Missing emotional storytelling elements that make journeys compelling
+❌ Missing critical decision points and failure scenarios
+❌ Not connecting journeys to required capabilities
+❌ Not having enough journey diversity (admin, support, API, etc.)
+❌ Not presenting A/P/C menu after content generation
+❌ Appending content without user selecting 'C'
+
+❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
+❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
+❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
+
+## JOURNEY TYPES TO ENSURE:
+
+**Minimum Coverage:**
+
+1. **Primary User - Success Path**: Core experience journey
+2. **Primary User - Edge Case**: Error recovery, alternative goals
+3. **Admin/Operations User**: Management, configuration, monitoring
+4. **Support/Troubleshooting**: Help, investigation, issue resolution
+5. **API/Integration** (if applicable): Developer/technical user journey
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved to document, load `./step-05-domain.md`.
+
+Remember: Do NOT proceed to step-05 until user explicitly selects 'C' from the A/P/C menu and content is saved!

_bmad/bmm/workflows/2-plan-workflows/prd/steps-c/step-05-domain.md

@@ -0,0 +1,207 @@
+---
+name: 'step-05-domain'
+description: 'Explore domain-specific requirements for complex domains (optional step)'
+
+# File References
+nextStepFile: './step-06-innovation.md'
+outputFile: '{planning_artifacts}/prd.md'
+domainComplexityCSV: '../data/domain-complexity.csv'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 5: Domain-Specific Requirements (Optional)
+
+**Progress: Step 5 of 13** - Next: Innovation Focus
+
+## STEP GOAL:
+
+For complex domains only that have a mapping in {domainComplexityCSV}, explore domain-specific constraints, compliance requirements, and technical considerations that shape the product.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
+- ✅ ALWAYS treat this as collaborative discovery between PM peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a product-focused PM facilitator collaborating with an expert peer
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise
+
+### Step-Specific Rules:
+
+- 🎯 This step is OPTIONAL - only needed for complex domains
+- 🚫 SKIP if domain complexity is "low" from step-02
+- 💬 APPROACH: Natural conversation to discover domain-specific needs
+- 🎯 Focus on constraints, compliance, and domain patterns
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Check domain complexity from step-02 classification first
+- ⚠️ If complexity is "low", offer to skip this step
+- ⚠️ Present A/P/C menu after domain requirements defined (or skipped)
+- 💾 ONLY save when user chooses C (Continue)
+- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
+- 🚫 FORBIDDEN to load next step until C is selected
+
+## CONTEXT BOUNDARIES:
+
+- Domain classification from step-02 is available
+- If complexity is low, this step may be skipped
+- Domain CSV data provides complexity reference
+- Focus on domain-specific constraints, not general requirements
+
+## YOUR TASK:
+
+For complex domains, explore what makes this domain special:
+- **Compliance requirements** - regulations, standards, certifications
+- **Technical constraints** - security, privacy, integration requirements
+- **Domain patterns** - common patterns, best practices, anti-patterns
+- **Risks and mitigations** - what could go wrong, how to prevent it
+
+## DOMAIN DISCOVERY SEQUENCE:
+
+### 1. Check Domain Complexity
+
+**Review classification from step-02:**
+
+- What's the domain complexity level? (low/medium/high)
+- What's the specific domain? (healthcare, fintech, education, etc.)
+
+**If complexity is LOW:**
+
+Offer to skip:
+"The domain complexity from our discovery is low. We may not need deep domain-specific requirements. Would you like to:
+- [C] Skip this step and move to Innovation
+- [D] Do domain exploration anyway"
+
+**If complexity is MEDIUM or HIGH:**
+
+Proceed with domain exploration.
+
+### 2. Load Domain Reference Data
+
+**Attempt subprocess data lookup:**
+
+"Your task: Lookup data in {domainComplexityCSV}
+
+**Search criteria:**
+- Find row where domain matches {{domainFromStep02}}
+
+**Return format:**
+Return ONLY the matching row as a YAML-formatted object with these fields:
+domain, complexity, typical_concerns, compliance_requirements
+
+**Do NOT return the entire CSV - only the matching row.**"
+
+**Graceful degradation (if Task tool unavailable):**
+- Load the CSV file directly
+- Find the matching row manually
+- Extract required fields
+- Understand typical concerns and compliance requirements
+
+### 3. Explore Domain-Specific Concerns
+
+**Start with what you know:**
+
+Acknowledge the domain and explore what makes it complex:
+- What regulations apply? (HIPAA, PCI-DSS, GDPR, SOX, etc.)
+- What standards matter? (ISO, NIST, domain-specific standards)
+- What certifications are needed? (security, privacy, domain-specific)
+- What integrations are required? (EMR systems, payment processors, etc.)
+
+**Explore technical constraints:**
+- Security requirements (encryption, audit logs, access control)
+- Privacy requirements (data handling, consent, retention)
+- Performance requirements (real-time, batch, latency)
+- Availability requirements (uptime, disaster recovery)
+
+### 4. Document Domain Requirements
+
+**Structure the requirements around key concerns:**
+
+```markdown
+### Compliance & Regulatory
+- [Specific requirements]
+
+### Technical Constraints
+- [Security, privacy, performance needs]
+
+### Integration Requirements
+- [Required systems and data flows]
+
+### Risk Mitigations
+- [Domain-specific risks and how to address them]
+```
+
+### 5. Validate Completeness
+
+**Check with the user:**
+
+"Are there other domain-specific concerns we should consider? For [this domain], what typically gets overlooked?"
+
+### N. Present MENU OPTIONS
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue - Save and Proceed to Innovation (Step 6 of 13)"
+
+#### Menu Handling Logic:
+- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
+- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
+- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
+- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#n-present-menu-options)
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- After other menu items execution, return to this menu
+
+## APPEND TO DOCUMENT
+
+When user selects 'C', append to `{outputFile}`:
+
+```markdown
+## Domain-Specific Requirements
+
+{{discovered domain requirements}}
+```
+
+If step was skipped, append nothing and proceed.
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN [C continue option] is selected and [content saved or skipped], will you then load and read fully `{nextStepFile}` to explore innovation.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Domain complexity checked before proceeding
+- Offered to skip if complexity is low
+- Natural conversation exploring domain concerns
+- Compliance, technical, and integration requirements identified
+- Domain-specific risks documented with mitigations
+- User validated completeness
+- Content properly saved (or step skipped) when C selected
+
+### ❌ SYSTEM FAILURE:
+
+- Not checking domain complexity first
+- Not offering to skip for low-complexity domains
+- Missing critical compliance requirements
+- Not exploring technical constraints
+- Not asking about domain-specific risks
+- Being generic instead of domain-specific
+- Proceeding without user validation
+
+**Master Rule:** This step is OPTIONAL for simple domains. For complex domains, focus on compliance, constraints, and domain patterns. Natural conversation, not checklists.

_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-06-innovation.md → _bmad/bmm/workflows/2-plan-workflows/prd/steps-c/step-06-innovation.md

@@ -2,17 +2,12 @@
 name: 'step-06-innovation'
 description: 'Detect and explore innovative aspects of the product (optional step)'
 
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd'
-
 # File References
-thisStepFile: '{workflow_path}/steps/step-06-innovation.md'
-nextStepFile: '{workflow_path}/steps/step-07-project-type.md'
-workflowFile: '{workflow_path}/workflow.md'
+nextStepFile: './step-07-project-type.md'
 outputFile: '{planning_artifacts}/prd.md'
 
 # Data Files
-projectTypesCSV: '{workflow_path}/project-types.csv'
+projectTypesCSV: '../data/project-types.csv'
 
 # Task References
 advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
@@ -40,24 +35,9 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
 - 🎯 Show your analysis before taking any action
 - ⚠️ Present A/P/C menu after generating innovation content
 - 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6]` before loading next step
+- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
 - 🚫 FORBIDDEN to load next step until C is selected
 
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to develop deeper innovation insights
-- **P (Party Mode)**: Bring creative perspectives to explore innovation opportunities
-- **C (Continue)**: Save the content to the document and proceed to next step
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml
-- When 'P' selected: Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md
-- PROTOCOLS always return to this step's A/P/C menu
-- User accepts/rejects protocol changes before proceeding
-
 ## CONTEXT BOUNDARIES:
 
 - Current document and frontmatter from previous steps are available
@@ -84,7 +64,7 @@ Detect and explore innovation patterns in the product, focusing on what makes it
 
 Load innovation signals specific to this project type:
 
-- Load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/project-types.csv` completely
+- Load `{projectTypesCSV}` completely
 - Find the row where `project_type` matches detected type from step-02
 - Extract `innovation_signals` (semicolon-separated list)
 - Extract `web_search_triggers` for potential innovation research
@@ -113,27 +93,22 @@ Match user descriptions against innovation_signals for their project_type:
 ### 3. Initial Innovation Screening
 
 Ask targeted innovation discovery questions:
-"As we explore {{project_name}}, I'm listening for what makes it innovative.
-
-**Innovation Indicators:**
-
-- Are you challenging any existing assumptions about how things work?
-- Are you combining technologies or approaches in new ways?
-- Is there something about this that hasn't been done before?
-
-What aspects of {{project_name}} feel most innovative to you?"
+- Guide exploration of what makes the product innovative
+- Explore if they're challenging existing assumptions
+- Ask about novel combinations of technologies/approaches
+- Identify what hasn't been done before
+- Understand which aspects feel most innovative
 
 ### 4. Deep Innovation Exploration (If Detected)
 
 If innovation signals are found, explore deeply:
 
 #### Innovation Discovery Questions:
-
-- "What makes it unique compared to existing solutions?"
-- "What assumption are you challenging?"
-- "How do we validate it works?"
-- "What's the fallback if it doesn't?"
-- "Has anyone tried this before?"
+- What makes it unique compared to existing solutions?
+- What assumption are you challenging?
+- How do we validate it works?
+- What's the fallback if it doesn't?
+- Has anyone tried this before?
 
 #### Market Context Research:
 
@@ -169,54 +144,43 @@ When saving to document, append these Level 2 and Level 3 sections:
 [Innovation risks and fallbacks based on conversation]
 ```
 
-### 6. Present Content and Menu (Only if Innovation Detected)
-
-Show the generated innovation content and present choices:
-"I've identified some innovative aspects of {{project_name}} that differentiate it from existing solutions.
-
-**Here's what I'll add to the document:**
-
-[Show the complete markdown content from step 5]
-
-**What would you like to do?**
-[A] Advanced Elicitation - Let's dive deeper into these innovation opportunities
-[P] Party Mode - Bring creative perspectives to explore innovation further
-[C] Continue - Save this and move to Project Type Analysis (Step 7 of 11)"
+### 6. Present MENU OPTIONS (Only if Innovation Detected)
 
-### 7. Handle Menu Selection
+Present the innovation content for review, then display menu:
+- Show identified innovative aspects (using structure from section 5)
+- Highlight differentiation from existing solutions
+- Ask if they'd like to refine further, get other perspectives, or proceed
+- Present menu options naturally as part of conversation
 
-#### If 'A' (Advanced Elicitation):
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Project Type Analysis (Step 7 of 11)"
 
-- Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml with the current innovation content
-- Process the enhanced innovation insights that come back
-- Ask user: "Accept these improvements to the innovation analysis? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
+#### Menu Handling Logic:
+- IF A: Execute {advancedElicitationTask} with the current innovation content, process the enhanced innovation insights that come back, ask user "Accept these improvements to the innovation analysis? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
+- IF P: Execute {partyModeWorkflow} with the current innovation content, process the collaborative innovation exploration and ideation, ask user "Accept these changes to the innovation analysis? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
+- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then load, read entire file, then execute {nextStepFile}
+- IF Any other: help user respond, then redisplay menu
 
-#### If 'P' (Party Mode):
-
-- Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md with the current innovation content
-- Process the collaborative innovation exploration and ideation
-- Ask user: "Accept these changes to the innovation analysis? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'C' (Continue):
-
-- Append the final content to `{outputFile}`
-- Update frontmatter: add this step name to the end of the steps completed array
-- Load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-07-project-type.md`
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- After other menu items execution, return to this menu
 
 ## NO INNOVATION DETECTED:
 
 If no genuine innovation signals are found after exploration:
-"After exploring {{project_name}}, I don't see clear innovation signals that warrant a dedicated innovation section. This is perfectly fine - many successful products are excellent executions of existing concepts rather than breakthrough innovations.
+- Acknowledge that no clear innovation signals were found
+- Note this is fine - many successful products are excellent executions of existing concepts
+- Ask if they'd like to try finding innovative angles or proceed
+
+Display: "**Select:** [A] Advanced Elicitation - Let's try to find innovative angles [C] Continue - Skip innovation section and move to Project Type Analysis (Step 7 of 11)"
 
-**Options:**
-[A] Force innovation exploration - Let's try to find innovative angles
-[C] Continue - Skip innovation section and move to Project Type Analysis (Step 7 of 11)"
+### Menu Handling Logic:
+- IF A: Proceed with content generation anyway, then return to menu
+- IF C: Skip this step, then load, read entire file, then execute {nextStepFile}
 
-If user selects 'A', proceed with content generation anyway. If 'C', skip this step and load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-07-project-type.md`.
+### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
 
 ## APPEND TO DOCUMENT:
 
@@ -248,7 +212,7 @@ When user selects 'C', append the content directly to the document using the str
 
 ## SKIP CONDITIONS:
 
-Skip this step and load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-07-project-type.md` if:
+Skip this step and load `{nextStepFile}` if:
 
 - No innovation signals detected in conversation
 - Product is incremental improvement rather than breakthrough
@@ -257,6 +221,6 @@ Skip this step and load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd
 
 ## NEXT STEP:
 
-After user selects 'C' and content is saved to document (or step is skipped), load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-07-project-type.md`.
+After user selects 'C' and content is saved to document (or step is skipped), load `{nextStepFile}`.
 
 Remember: Do NOT proceed to step-07 until user explicitly selects 'C' from the A/P/C menu (or confirms step skip)!

_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-07-project-type.md → _bmad/bmm/workflows/2-plan-workflows/prd/steps-c/step-07-project-type.md

@@ -2,17 +2,12 @@
 name: 'step-07-project-type'
 description: 'Conduct project-type specific discovery using CSV-driven guidance'
 
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd'
-
 # File References
-thisStepFile: '{workflow_path}/steps/step-07-project-type.md'
-nextStepFile: '{workflow_path}/steps/step-08-scoping.md'
-workflowFile: '{workflow_path}/workflow.md'
+nextStepFile: './step-08-scoping.md'
 outputFile: '{planning_artifacts}/prd.md'
 
 # Data Files
-projectTypesCSV: '{workflow_path}/project-types.csv'
+projectTypesCSV: '../data/project-types.csv'
 
 # Task References
 advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
@@ -40,24 +35,9 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
 - 🎯 Show your analysis before taking any action
 - ⚠️ Present A/P/C menu after generating project-type content
 - 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]` before loading next step
+- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
 - 🚫 FORBIDDEN to load next step until C is selected
 
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to develop deeper project-type insights
-- **P (Party Mode)**: Bring technical perspectives to explore project-specific requirements
-- **C (Continue)**: Save the content to the document and proceed to next step
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml
-- When 'P' selected: Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md
-- PROTOCOLS always return to this step's A/P/C menu
-- User accepts/rejects protocol changes before proceeding
-
 ## CONTEXT BOUNDARIES:
 
 - Current document and frontmatter from previous steps are available
@@ -73,11 +53,23 @@ Conduct project-type specific discovery using CSV-driven guidance to define tech
 
 ### 1. Load Project-Type Configuration Data
 
-Load project-type specific configuration:
+**Attempt subprocess data lookup:**
+
+"Your task: Lookup data in {projectTypesCSV}
+
+**Search criteria:**
+- Find row where project_type matches {{projectTypeFromStep02}}
 
-- Load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/project-types.csv` completely
-- Find the row where `project_type` matches detected type from step-02
-- Extract these columns:
+**Return format:**
+Return ONLY the matching row as a YAML-formatted object with these fields:
+project_type, key_questions, required_sections, skip_sections, innovation_signals
+
+**Do NOT return the entire CSV - only the matching row.**"
+
+**Graceful degradation (if Task tool unavailable):**
+- Load the CSV file directly
+- Find the matching row manually
+- Extract required fields:
   - `key_questions` (semicolon-separated list of discovery questions)
   - `required_sections` (semicolon-separated list of sections to document)
   - `skip_sections` (semicolon-separated list of sections to skip)
@@ -165,47 +157,34 @@ When saving to document, append these Level 2 and Level 3 sections:
 [Implementation specific requirements based on conversation]
 ```
 
-### 6. Present Content and Menu
+### 6. Present MENU OPTIONS
 
-Show the generated project-type content and present choices:
-"I've documented the {project_type}-specific requirements for {{project_name}} based on our conversation and best practices for this type of product.
-
-**Here's what I'll add to the document:**
+Present the project-type content for review, then display menu:
 
-[Show the complete markdown content from step 5]
+"Based on our conversation and best practices for this product type, I've documented the {project_type}-specific requirements for {{project_name}}.
 
-**What would you like to do?**
-[A] Advanced Elicitation - Let's dive deeper into these technical requirements
-[P] Party Mode - Bring technical expertise perspectives to validate requirements
-[C] Continue - Save this and move to Scoping (Step 8 of 11)"
-
-### 7. Handle Menu Selection
-
-#### If 'A' (Advanced Elicitation):
+**Here's what I'll add to the document:**
 
-- Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml with the current project-type content
-- Process the enhanced technical insights that come back
-- Ask user: "Accept these improvements to the technical requirements? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
+[Show the complete markdown content from section 5]
 
-#### If 'P' (Party Mode):
+**What would you like to do?**"
 
-- Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md with the current project-type requirements
-- Process the collaborative technical expertise and validation
-- Ask user: "Accept these changes to the technical requirements? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Scoping (Step 8 of 11)"
 
-#### If 'C' (Continue):
+#### Menu Handling Logic:
+- IF A: Execute {advancedElicitationTask} with the current project-type content, process the enhanced technical insights that come back, ask user "Accept these improvements to the technical requirements? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
+- IF P: Execute {partyModeWorkflow} with the current project-type requirements, process the collaborative technical expertise and validation, ask user "Accept these changes to the technical requirements? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
+- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then load, read entire file, then execute {nextStepFile}
+- IF Any other: help user respond, then redisplay menu
 
-- Append the final content to `{outputFile}`
-- Update frontmatter: add this step name to the end of the steps completed array
-- Load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-08-scoping.md`
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- After other menu items execution, return to this menu
 
 ## APPEND TO DOCUMENT:
 
-When user selects 'C', append the content directly to the document using the structure from step 5.
+When user selects 'C', append the content directly to the document using the structure from previous steps.
 
 ## SUCCESS METRICS:
 
@@ -253,6 +232,6 @@ When user selects 'C', append the content directly to the document using the str
 
 ## NEXT STEP:
 
-After user selects 'C' and content is saved to document, load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-08-scoping.md` to define project scope.
+After user selects 'C' and content is saved to document, load `{nextStepFile}` to define project scope.
 
 Remember: Do NOT proceed to step-08 (Scoping) until user explicitly selects 'C' from the A/P/C menu and content is saved!

_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-08-scoping.md → _bmad/bmm/workflows/2-plan-workflows/prd/steps-c/step-08-scoping.md

@@ -2,13 +2,8 @@
 name: 'step-08-scoping'
 description: 'Define MVP boundaries and prioritize features across development phases'
 
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd'
-
 # File References
-thisStepFile: '{workflow_path}/steps/step-08-scoping.md'
-nextStepFile: '{workflow_path}/steps/step-09-functional.md'
-workflowFile: '{workflow_path}/workflow.md'
+nextStepFile: './step-09-functional.md'
 outputFile: '{planning_artifacts}/prd.md'
 
 # Task References
@@ -38,23 +33,9 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
 - 📚 Review the complete PRD document built so far
 - ⚠️ Present A/P/C menu after generating scoping decisions
 - 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8]` before loading next step
+- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
 - 🚫 FORBIDDEN to load next step until C is selected
 
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to explore innovative scoping approaches
-- **P (Party Mode)**: Bring multiple perspectives to ensure comprehensive scope decisions
-- **C (Continue)**: Save the scoping decisions and proceed to functional requirements
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml
-- When 'P' selected: Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md
-- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
-- User accepts/rejects protocol changes before proceeding
 
 ## CONTEXT BOUNDARIES:
 
@@ -72,80 +53,46 @@ Conduct comprehensive scoping exercise to define MVP boundaries and prioritize f
 ### 1. Review Current PRD State
 
 Analyze everything documented so far:
-"I've reviewed your complete PRD so far. Here's what we've established:
-
-**Product Vision & Success:**
-{{summary_of_vision_and_success_criteria}}
-
-**User Journeys:** {{number_of_journeys}} mapped with rich narratives
-
-**Domain & Innovation Focus:**
-{{summary_of_domain_requirements_and_innovation}}
-
-**Current Scope Implications:**
-Based on everything we've documented, this looks like it could be:
-
-- [ ] Simple MVP (small team, lean scope)
-- [ ] Medium scope (moderate team, balanced features)
-- [ ] Complex project (large team, comprehensive scope)
-
-Does this initial assessment feel right, or do you see this differently?"
+- Present synthesis of established vision, success criteria, journeys
+- Assess domain and innovation focus
+- Evaluate scope implications: simple MVP, medium, or complex project
+- Ask if initial assessment feels right or if they see it differently
 
 ### 2. Define MVP Strategy
 
 Facilitate strategic MVP decisions:
-
-"Let's think strategically about your launch strategy:
-
-**MVP Philosophy Options:**
-
-1. **Problem-Solving MVP**: Solve the core problem with minimal features
-2. **Experience MVP**: Deliver the key user experience with basic functionality
-3. **Platform MVP**: Build the foundation for future expansion
-4. **Revenue MVP**: Generate early revenue with essential features
-
-**Critical Questions:**
-
-- What's the minimum that would make users say 'this is useful'?
-- What would make investors/partners say 'this has potential'?
-- What's the fastest path to validated learning?
-
-**Which MVP approach feels right for {{project_name}}?**"
+- Explore MVP philosophy options: problem-solving, experience, platform, or revenue MVP
+- Ask critical questions:
+  - What's the minimum that would make users say 'this is useful'?
+  - What would make investors/partners say 'this has potential'?
+  - What's the fastest path to validated learning?
+- Guide toward appropriate MVP approach for their product
 
 ### 3. Scoping Decision Framework
 
 Use structured decision-making for scope:
 
 **Must-Have Analysis:**
-"Let's identify absolute MVP necessities. For each journey and success criterion, ask:
-
-- **Without this, does the product fail?** (Y/N)
-- **Can this be manual initially?** (Y/N)
-- **Is this a deal-breaker for early adopters?** (Y/N)
-
-**Current Document Review:**
-Looking at your user journeys, what are the absolute core experiences that must work?
-
-{{analyze_journeys_for_mvp_essentials}}"
+- Guide identification of absolute MVP necessities
+- For each journey and success criterion, ask:
+  - Without this, does the product fail?
+  - Can this be manual initially?
+  - Is this a deal-breaker for early adopters?
+- Analyze journeys for MVP essentials
 
 **Nice-to-Have Analysis:**
-"Let's also identify what could be added later:
-
-**Post-MVP Enhancements:**
-
-- Features that enhance but aren't essential
-- User types that can be added later
-- Advanced functionality that builds on MVP
-
-**What features could we add in versions 2, 3, etc.?**"
+- Identify what could be added later:
+  - Features that enhance but aren't essential
+  - User types that can be added later
+  - Advanced functionality that builds on MVP
+- Ask what features could be added in versions 2, 3, etc.
 
 ### 4. Progressive Feature Roadmap
 
 Create phased development approach:
-
-"Let's map your features across development phases:
-
-**Phase 1: MVP**
+- Guide mapping of features across development phases
+- Structure as Phase 1 (MVP), Phase 2 (Growth), Phase 3 (Vision)
+- Ensure clear progression and dependencies
 
 - Core user value delivery
 - Essential user journeys
@@ -225,44 +172,26 @@ Prepare comprehensive scoping section:
 **Resource Risks:** {{contingency_approach}}
 ```
 
-### 7. Present Content and Menu
-
-Show the scoping decisions and present choices:
-
-"I've analyzed your complete PRD and created a strategic scoping plan for {{project_name}}.
-
-**Here's what I'll add to the document:**
-
-[Show the complete markdown content from step 6]
-
-**What would you like to do?**
-[A] Advanced Elicitation - Explore alternative scoping strategies
-[P] Party Mode - Bring different perspectives on MVP and roadmap decisions
-[C] Continue - Save scoping decisions and move to Functional Requirements (Step 9 of 11)"
-
-### 8. Handle Menu Selection
-
-#### If 'A' (Advanced Elicitation):
-
-- Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml with current scoping analysis
-- Process enhanced scoping insights that come back
-- Ask user: "Accept these improvements to the scoping decisions? (y/n)"
-- If yes: Update content, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
+### 7. Present MENU OPTIONS
 
-#### If 'P' (Party Mode):
+Present the scoping decisions for review, then display menu:
+- Show strategic scoping plan (using structure from step 6)
+- Highlight MVP boundaries and phased roadmap
+- Ask if they'd like to refine further, get other perspectives, or proceed
+- Present menu options naturally as part of conversation
 
-- Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md with scoping context
-- Process collaborative insights on MVP and roadmap decisions
-- Ask user: "Accept these changes to the scoping decisions? (y/n)"
-- If yes: Update content, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Functional Requirements (Step 9 of 11)"
 
-#### If 'C' (Continue):
+#### Menu Handling Logic:
+- IF A: Execute {advancedElicitationTask} with the current scoping analysis, process the enhanced insights that come back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
+- IF P: Execute {partyModeWorkflow} with the scoping context, process the collaborative insights on MVP and roadmap decisions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
+- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then load, read entire file, then execute {nextStepFile}
+- IF Any other: help user respond, then redisplay menu
 
-- Append the final content to `{outputFile}`
-- Update frontmatter: add this step name to the end of the steps completed array
-- Load `./step-09-functional.md`
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- After other menu items execution, return to this menu
 
 ## APPEND TO DOCUMENT:
 
@@ -294,6 +223,6 @@ When user selects 'C', append the content directly to the document using the str
 
 ## NEXT STEP:
 
-After user selects 'C' and content is saved to document, load `./step-09-functional.md`.
+After user selects 'C' and content is saved to document, load {nextStepFile}.
 
 Remember: Do NOT proceed to step-09 until user explicitly selects 'C' from the A/P/C menu and content is saved!

_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-09-functional.md → _bmad/bmm/workflows/2-plan-workflows/prd/steps-c/step-09-functional.md

@@ -2,13 +2,8 @@
 name: 'step-09-functional'
 description: 'Synthesize all discovery into comprehensive functional requirements'
 
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd'
-
 # File References
-thisStepFile: '{workflow_path}/steps/step-09-functional.md'
-nextStepFile: '{workflow_path}/steps/step-10-nonfunctional.md'
-workflowFile: '{workflow_path}/workflow.md'
+nextStepFile: './step-10-nonfunctional.md'
 outputFile: '{planning_artifacts}/prd.md'
 
 # Task References
@@ -37,23 +32,9 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
 - 🎯 Show your analysis before taking any action
 - ⚠️ Present A/P/C menu after generating functional requirements
 - 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8]` before loading next step
+- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
 - 🚫 FORBIDDEN to load next step until C is selected
 
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to ensure comprehensive requirement coverage
-- **P (Party Mode)**: Bring multiple perspectives to validate complete requirement set
-- **C (Continue)**: Save the content to the document and proceed to next step
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml
-- When 'P' selected: Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md
-- PROTOCOLS always return to this step's A/P/C menu
-- User accepts/rejects protocol changes before proceeding
 
 ## CONTEXT BOUNDARIES:
 
@@ -186,49 +167,29 @@ When saving to document, append these Level 2 and Level 3 sections:
 [Continue for all capability areas discovered in conversation]
 ```
 
-### 7. Present Content and Menu
-
-Show the generated functional requirements and present choices:
-"I've synthesized all our discussions into comprehensive functional requirements. This becomes the capability contract that UX designers, architects, and developers will all work from.
-
-**Here's what I'll add to the document:**
-
-[Show the complete FR list from step 6]
-
-**This is critical because:**
-
-- Every feature we build must trace back to one of these requirements
-- UX designers will ONLY design interactions for these capabilities
-- Architects will ONLY build systems to support these capabilities
-
-**What would you like to do?**
-[A] Advanced Elicitation - Let's ensure we haven't missed any capabilities
-[P] Party Mode - Bring different perspectives to validate complete coverage
-[C] Continue - Save this and move to Non-Functional Requirements (Step 10 of 11)"
-
-### 8. Handle Menu Selection
-
-#### If 'A' (Advanced Elicitation):
+### 7. Present MENU OPTIONS
 
-- Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml with the current FR list
-- Process the enhanced capability coverage that comes back
-- Ask user: "Accept these additions to the functional requirements? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
+Present the functional requirements for review, then display menu:
+- Show synthesized functional requirements (using structure from step 6)
+- Emphasize this is the capability contract for all downstream work
+- Highlight that every feature must trace back to these requirements
+- Ask if they'd like to refine further, get other perspectives, or proceed
+- Present menu options naturally as part of conversation
 
-#### If 'P' (Party Mode):
+**What would you like to do?**"
 
-- Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md with the current FR list
-- Process the collaborative capability validation and additions
-- Ask user: "Accept these changes to the functional requirements? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Non-Functional Requirements (Step 10 of 11)"
 
-#### If 'C' (Continue):
+#### Menu Handling Logic:
+- IF A: Execute {advancedElicitationTask} with the current FR list, process the enhanced capability coverage that comes back, ask user if they accept the additions, if yes update content then redisplay menu, if no keep original content then redisplay menu
+- IF P: Execute {partyModeWorkflow} with the current FR list, process the collaborative capability validation and additions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
+- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then load, read entire file, then execute {nextStepFile}
+- IF Any other: help user respond, then redisplay menu
 
-- Append the final content to `{outputFile}`
-- Update frontmatter: add this step name to the end of the steps completed array
-- Load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-10-nonfunctional.md`
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- After other menu items execution, return to this menu
 
 ## APPEND TO DOCUMENT:
 
@@ -265,6 +226,6 @@ Emphasize to user: "This FR list is now binding. Any feature not listed here wil
 
 ## NEXT STEP:
 
-After user selects 'C' and content is saved to document, load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-10-nonfunctional.md` to define non-functional requirements.
+After user selects 'C' and content is saved to document, load {nextStepFile} to define non-functional requirements.
 
 Remember: Do NOT proceed to step-10 until user explicitly selects 'C' from the A/P/C menu and content is saved!

_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-10-nonfunctional.md → _bmad/bmm/workflows/2-plan-workflows/prd/steps-c/step-10-nonfunctional.md

@@ -2,13 +2,8 @@
 name: 'step-10-nonfunctional'
 description: 'Define quality attributes that matter for this specific product'
 
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd'
-
 # File References
-thisStepFile: '{workflow_path}/steps/step-10-nonfunctional.md'
-nextStepFile: '{workflow_path}/steps/step-11-complete.md'
-workflowFile: '{workflow_path}/workflow.md'
+nextStepFile: './step-11-polish.md'
 outputFile: '{planning_artifacts}/prd.md'
 
 # Task References
@@ -18,7 +13,7 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
 
 # Step 10: Non-Functional Requirements
 
-**Progress: Step 10 of 11** - Next: Complete PRD
+**Progress: Step 10 of 12** - Next: Polish Document
 
 ## MANDATORY EXECUTION RULES (READ FIRST):
 
@@ -37,23 +32,9 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
 - 🎯 Show your analysis before taking any action
 - ⚠️ Present A/P/C menu after generating NFR content
 - 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8, 9]` before loading next step
+- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
 - 🚫 FORBIDDEN to load next step until C is selected
 
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to ensure comprehensive quality attributes
-- **P (Party Mode)**: Bring technical perspectives to validate NFR completeness
-- **C (Continue)**: Save the content to the document and proceed to final step
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml
-- When 'P' selected: Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md
-- PROTOCOLS always return to this step's A/P/C menu
-- User accepts/rejects protocol changes before proceeding
 
 ## CONTEXT BOUNDARIES:
 
@@ -97,56 +78,41 @@ For each relevant category, conduct targeted discovery:
 
 #### Performance NFRs (If relevant):
 
-"Let's talk about performance requirements for {{project_name}}.
-
-**Performance Questions:**
-
+Explore performance requirements:
 - What parts of the system need to be fast for users to be successful?
 - Are there specific response time expectations?
 - What happens if performance is slower than expected?
-- Are there concurrent user scenarios we need to support?"
+- Are there concurrent user scenarios we need to support?
 
 #### Security NFRs (If relevant):
 
-"Security is critical for products that handle sensitive information.
-
-**Security Questions:**
-
+Explore security requirements:
 - What data needs to be protected?
 - Who should have access to what?
 - What are the security risks we need to mitigate?
-- Are there compliance requirements (GDPR, HIPAA, PCI-DSS)?"
+- Are there compliance requirements (GDPR, HIPAA, PCI-DSS)?
 
 #### Scalability NFRs (If relevant):
 
-"Scalability matters if we expect growth or have variable demand.
-
-**Scalability Questions:**
-
+Explore scalability requirements:
 - How many users do we expect initially? Long-term?
 - Are there seasonal or event-based traffic spikes?
-- What happens if we exceed our capacity?"
-- What growth scenarios should we plan for?"
+- What happens if we exceed our capacity?
+- What growth scenarios should we plan for?
 
 #### Accessibility NFRs (If relevant):
 
-"Accessibility ensures the product works for users with disabilities.
-
-**Accessibility Questions:**
-
+Explore accessibility requirements:
 - Are we serving users with visual, hearing, or motor impairments?
 - Are there legal accessibility requirements (WCAG, Section 508)?
-- What accessibility features are most important for our users?"
+- What accessibility features are most important for our users?
 
 #### Integration NFRs (If relevant):
 
-"Integration requirements matter for products that connect to other systems.
-
-**Integration Questions:**
-
+Explore integration requirements:
 - What external systems do we need to connect with?
 - Are there APIs or data formats we must support?
-- How reliable do these integrations need to be?"
+- How reliable do these integrations need to be?
 
 ### 4. Make NFRs Specific and Measurable
 
@@ -190,45 +156,27 @@ When saving to document, append these Level 2 and Level 3 sections (only include
 [Integration requirements based on conversation - only include if relevant]
 ```
 
-### 6. Present Content and Menu
-
-Show the generated NFR content and present choices:
-"I've defined the non-functional requirements that specify how well {{project_name}} needs to perform. I've only included categories that actually matter for this product.
-
-**Here's what I'll add to the document:**
-
-[Show the complete NFR content from step 5]
-
-**Note:** We've skipped categories that don't apply to avoid unnecessary requirements.
-
-**What would you like to do?**
-[A] Advanced Elicitation - Let's ensure we haven't missed critical quality attributes
-[P] Party Mode - Bring technical perspectives to validate NFR specifications
-[C] Continue - Save this and move to Complete PRD (Step 11 of 11)"
-
-### 7. Handle Menu Selection
-
-#### If 'A' (Advanced Elicitation):
-
-- Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml with the current NFR content
-- Process the enhanced quality attribute insights that come back
-- Ask user: "Accept these improvements to the non-functional requirements? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
+### 6. Present MENU OPTIONS
 
-#### If 'P' (Party Mode):
+Present the non-functional requirements for review, then display menu:
+- Show defined NFRs (using structure from step 5)
+- Note that only relevant categories were included
+- Emphasize NFRs specify how well the system needs to perform
+- Ask if they'd like to refine further, get other perspectives, or proceed
+- Present menu options naturally as part of conversation
 
-- Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md with the current NFR list
-- Process the collaborative technical validation and additions
-- Ask user: "Accept these changes to the non-functional requirements? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Polish Document (Step 11 of 12)"
 
-#### If 'C' (Continue):
+#### Menu Handling Logic:
+- IF A: Execute {advancedElicitationTask} with the current NFR content, process the enhanced quality attribute insights that come back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
+- IF P: Execute {partyModeWorkflow} with the current NFR list, process the collaborative technical validation and additions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
+- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then load, read entire file, then execute {nextStepFile}
+- IF Any other: help user respond, then redisplay menu
 
-- Append the final content to `{outputFile}`
-- Update frontmatter: add this step name to the end of the steps completed array
-- Load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-11-complete.md`
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- After other menu items execution, return to this menu
 
 ## APPEND TO DOCUMENT:
 
@@ -289,6 +237,6 @@ When user selects 'C', append the content directly to the document using the str
 
 ## NEXT STEP:
 
-After user selects 'C' and content is saved to document, load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-11-complete.md` to finalize the PRD and complete the workflow.
+After user selects 'C' and content is saved to document, load {nextStepFile} to finalize the PRD and complete the workflow.
 
 Remember: Do NOT proceed to step-11 until user explicitly selects 'C' from the A/P/C menu and content is saved!

_bmad/bmm/workflows/2-plan-workflows/prd/steps-c/step-11-polish.md

@@ -0,0 +1,217 @@
+---
+name: 'step-11-polish'
+description: 'Optimize and polish the complete PRD document for flow, coherence, and readability'
+
+# File References
+nextStepFile: './step-12-complete.md'
+outputFile: '{planning_artifacts}/prd.md'
+purposeFile: './data/prd-purpose.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 11: Document Polish
+
+**Progress: Step 11 of 12** - Next: Complete PRD
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+- 🛑 CRITICAL: Load the ENTIRE document before making changes
+- 📖 CRITICAL: Read complete step file before taking action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- ✅ This is a POLISH step - optimize existing content
+- 📋 IMPROVE flow, coherence, and readability
+- 💬 PRESERVE user's voice and intent
+- 🎯 MAINTAIN all essential information while improving presentation
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Load complete document first
+- 📝 Review for flow and coherence issues
+- ✂️ Reduce duplication while preserving essential info
+- 📖 Ensure proper ## Level 2 headers throughout
+- 💾 Save optimized document
+- ⚠️ Present A/P/C menu after polish
+- 🚫 DO NOT skip review steps
+
+## CONTEXT BOUNDARIES:
+
+- Complete PRD document exists from all previous steps
+- Document may have duplication from progressive append
+- Sections may not flow smoothly together
+- Level 2 headers ensure document can be split if needed
+- Focus on readability and coherence
+
+## YOUR TASK:
+
+Optimize the complete PRD document for flow, coherence, and professional presentation while preserving all essential information.
+
+## DOCUMENT POLISH SEQUENCE:
+
+### 1. Load Context and Document
+
+**CRITICAL:** Load the PRD purpose document first:
+
+- Read `{purposeFile}` to understand what makes a great BMAD PRD
+- Internalize the philosophy: information density, traceability, measurable requirements
+- Keep the dual-audience nature (humans + LLMs) in mind
+
+**Then Load the PRD Document:**
+
+- Read `{outputFile}` completely from start to finish
+- Understand the full document structure and content
+- Identify all sections and their relationships
+- Note areas that need attention
+
+### 2. Document Quality Review
+
+Review the entire document with PRD purpose principles in mind:
+
+**Information Density:**
+- Are there wordy phrases that can be condensed?
+- Is conversational padding present?
+- Can sentences be more direct and concise?
+
+**Flow and Coherence:**
+- Do sections transition smoothly?
+- Are there jarring topic shifts?
+- Does the document tell a cohesive story?
+- Is the progression logical for readers?
+
+**Duplication Detection:**
+- Are ideas repeated across sections?
+- Is the same information stated multiple times?
+- Can redundant content be consolidated?
+- Are there contradictory statements?
+
+**Header Structure:**
+- Are all main sections using ## Level 2 headers?
+- Is the hierarchy consistent (##, ###, ####)?
+- Can sections be easily extracted or referenced?
+- Are headers descriptive and clear?
+
+**Readability:**
+- Are sentences clear and concise?
+- Is the language consistent throughout?
+- Are technical terms used appropriately?
+- Would stakeholders find this easy to understand?
+
+### 3. Optimization Actions
+
+Make targeted improvements:
+
+**Improve Flow:**
+- Add transition sentences between sections
+- Smooth out jarring topic shifts
+- Ensure logical progression
+- Connect related concepts across sections
+
+**Reduce Duplication:**
+- Consolidate repeated information
+- Keep content in the most appropriate section
+- Use cross-references instead of repetition
+- Remove redundant explanations
+
+**Enhance Coherence:**
+- Ensure consistent terminology throughout
+- Align all sections with product differentiator
+- Maintain consistent voice and tone
+- Verify scope consistency across sections
+
+**Optimize Headers:**
+- Ensure all main sections use ## Level 2
+- Make headers descriptive and action-oriented
+- Check that headers follow consistent patterns
+- Verify headers support document navigation
+
+### 4. Preserve Critical Information
+
+**While optimizing, ensure NOTHING essential is lost:**
+
+**Must Preserve:**
+- All user success criteria
+- All functional requirements (capability contract)
+- All user journey narratives
+- All scope decisions (MVP, Growth, Vision)
+- All non-functional requirements
+- Product differentiator and vision
+- Domain-specific requirements
+- Innovation analysis (if present)
+
+**Can Consolidate:**
+- Repeated explanations of the same concept
+- Redundant background information
+- Multiple versions of similar content
+- Overlapping examples
+
+### 5. Generate Optimized Document
+
+Create the polished version:
+
+**Polishing Process:**
+1. Start with original document
+2. Apply all optimization actions
+3. Review to ensure nothing essential was lost
+4. Verify improvements enhance readability
+5. Prepare optimized version for review
+
+### 6. Present MENU OPTIONS
+
+Present the polished document for review, then display menu:
+- Show what changed in the polish
+- Highlight improvements made (flow, duplication, headers)
+- Ask if they'd like to refine further, get other perspectives, or proceed
+- Present menu options naturally as part of conversation
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Complete PRD (Step 12 of 12)"
+
+#### Menu Handling Logic:
+- IF A: Execute {advancedElicitationTask} with the polished document, process the enhanced refinements that come back, ask user "Accept these polish improvements? (y/n)", if yes update content with improvements then redisplay menu, if no keep original polish then redisplay menu
+- IF P: Execute {partyModeWorkflow} with the polished document, process the collaborative refinements to flow and coherence, ask user "Accept these polish changes? (y/n)", if yes update content with improvements then redisplay menu, if no keep original polish then redisplay menu
+- IF C: Save the polished document to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then load, read entire file, then execute {nextStepFile}
+- IF Any other: help user respond, then redisplay menu
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- After other menu items execution, return to this menu
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', replace the entire document content with the polished version.
+
+## SUCCESS METRICS:
+
+✅ Complete document loaded and reviewed
+✅ Flow and coherence improved
+✅ Duplication reduced while preserving essential information
+✅ All main sections use ## Level 2 headers
+✅ Transitions between sections are smooth
+✅ User's voice and intent preserved
+✅ Document is more readable and professional
+✅ A/P/C menu presented and handled correctly
+✅ Polished document saved when C selected
+
+## FAILURE MODES:
+
+❌ Loading only partial document (leads to incomplete polish)
+❌ Removing essential information while reducing duplication
+❌ Not preserving user's voice and intent
+❌ Changing content instead of improving presentation
+❌ Not ensuring ## Level 2 headers for main sections
+❌ Making arbitrary style changes instead of coherence improvements
+❌ Not presenting A/P/C menu for user approval
+❌ Saving polished document without user selecting 'C'
+
+❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
+❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
+❌ **CRITICAL**: Making changes without complete understanding of document requirements
+
+## NEXT STEP:
+
+After user selects 'C' and polished document is saved, load `./step-12-complete.md` to complete the workflow.
+
+Remember: Do NOT proceed to step-12 until user explicitly selects 'C' from the A/P/C menu and polished document is saved!

_bmad/bmm/workflows/2-plan-workflows/prd/steps-c/step-12-complete.md

@@ -0,0 +1,180 @@
+---
+name: 'step-12-complete'
+description: 'Complete the PRD workflow, update status files, and suggest next steps including validation'
+
+# File References
+outputFile: '{planning_artifacts}/prd.md'
+validationFlow: '../steps-v/step-v-01-discovery.md'
+---
+
+# Step 12: Workflow Completion
+
+**Final Step - Complete the PRD**
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+- ✅ THIS IS A FINAL STEP - Workflow completion required
+- 📖 CRITICAL: ALWAYS read the complete step file before taking any action
+- 🛑 NO content generation - this is a wrap-up step
+- 📋 FINALIZE document and update workflow status
+- 💬 FOCUS on completion, validation options, and next steps
+- 🎯 UPDATE workflow status files with completion information
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- 💾 Update the main workflow status file with completion information (if exists)
+- 📖 Offer validation workflow options to user
+- 🚫 DO NOT load additional steps after this one
+
+## TERMINATION STEP PROTOCOLS:
+
+- This is a FINAL step - workflow completion required
+- Update workflow status file with finalized document
+- Suggest validation and next workflow steps
+- Mark workflow as complete in status tracking
+
+## CONTEXT BOUNDARIES:
+
+- Complete and polished PRD document is available from all previous steps
+- Workflow frontmatter shows all completed steps including polish
+- All collaborative content has been generated, saved, and optimized
+- Focus on completion, validation options, and next steps
+
+## YOUR TASK:
+
+Complete the PRD workflow, update status files, offer validation options, and suggest next steps for the project.
+
+## WORKFLOW COMPLETION SEQUENCE:
+
+### 1. Announce Workflow Completion
+
+Inform user that the PRD is complete and polished:
+- Celebrate successful completion of comprehensive PRD
+- Summarize all sections that were created
+- Highlight that document has been polished for flow and coherence
+- Emphasize document is ready for downstream work
+
+### 2. Workflow Status Update
+
+Update the main workflow status file if there is one:
+
+- Load `{status_file}` from workflow configuration (if exists)
+- Update workflow_status["prd"] = "{default_output_file}"
+- Save file, preserving all comments and structure
+- Mark current timestamp as completion time
+
+### 3. Validation Workflow Options
+
+Offer validation workflows to ensure PRD is ready for implementation:
+
+**Available Validation Workflows:**
+
+**Option 1: Check Implementation Readiness** (`{checkImplementationReadinessWorkflow}`)
+- Validates PRD has all information needed for development
+- Checks epic coverage completeness
+- Reviews UX alignment with requirements
+- Assesses epic quality and readiness
+- Identifies gaps before architecture/design work begins
+
+**When to use:** Before starting technical architecture or epic breakdown
+
+**Option 2: Skip for Now**
+- Proceed directly to next workflows (architecture, UX, epics)
+- Validation can be done later if needed
+- Some teams prefer to validate during architecture reviews
+
+### 4. Suggest Next Workflows
+
+Provide guidance on logical next workflows - strongly suggesting any of these chosen are started in a fresh context with the appropriate agent:
+
+**Typical Next Workflows:**
+
+**Immediate Next Steps:**
+
+1. **PRD Quality Validation First (Recommended):**
+   - execute the `{validationFlow}` workflow if selected or start a new chat with me and select the validate PRD menu item
+   - Ensures PRD is complete and ready
+   - Identifies any gaps or issues
+   - Validates before committing to architecture/design
+
+2. **UX Design:** `workflow create-ux-design` with the UX-Designer Agent (if UI exists)
+   - User journey insights from step-04 inform interaction design
+   - Functional requirements from step-09 define design scope
+   - Polish-optimized document provides clear design requirements
+
+3. **Technical Architecture:** `workflow create-architecture` with the Architect Agent
+   - Project-type requirements from step-07 guide technical decisions
+   - Non-functional requirements from step-10 inform architecture choices
+   - Functional requirements define system capabilities
+
+4. **Epic Breakdown:** `workflow create-epics-and-stories` with me again - but really recommend first doing a UX if needed and an architecture!
+   - Functional requirements from step-09 become epics and stories
+   - Scope definition from step-03 guides sprint planning
+   - Richer when created after UX/architecture
+
+**Strategic Considerations:**
+
+- Validation adds confidence before architecture/design investment
+- UX design and architecture can happen in parallel after validation
+- Epics/stories are richer when created after UX/architecture
+- Order depends on team preferences and project needs
+
+### 5. Final Completion Confirmation
+
+- Confirm completion with user and summarize what has been accomplished
+- Document now contains: Executive Summary, Success Criteria, User Journeys, Domain Requirements (if applicable), Innovation Analysis (if applicable), Project-Type Requirements, Functional Requirements (capability contract), Non-Functional Requirements, and has been polished for flow and coherence
+- Ask if they'd like to run validation workflow or proceed to next workflows
+
+## SUCCESS METRICS:
+
+✅ PRD document contains all required sections and has been polished
+✅ All collaborative content properly saved and optimized
+✅ Workflow status file updated with completion information (if exists)
+✅ Validation workflow options clearly presented
+✅ Clear next step guidance provided to user
+✅ Document quality validation completed
+✅ User acknowledges completion and understands next options
+
+## FAILURE MODES:
+
+❌ Not updating workflow status file with completion information (if exists)
+❌ Not offering validation workflow options
+❌ Missing clear next step guidance for user
+❌ Not confirming document completeness with user
+❌ Workflow not properly marked as complete in status tracking (if applicable)
+❌ User unclear about what happens next or what validation options exist
+
+❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
+❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
+
+## WORKFLOW COMPLETION CHECKLIST:
+
+### Document Structure Complete:
+
+- [ ] Executive Summary with vision and differentiator
+- [ ] Success Criteria with measurable outcomes
+- [ ] Product Scope (MVP, Growth, Vision)
+- [ ] User Journeys (comprehensive coverage)
+- [ ] Domain Requirements (if applicable)
+- [ ] Innovation Analysis (if applicable)
+- [ ] Project-Type Requirements
+- [ ] Functional Requirements (capability contract)
+- [ ] Non-Functional Requirements
+- [ ] Document polished for flow and coherence
+
+### Process Complete:
+
+- [ ] All steps (including polish) completed with user confirmation
+- [ ] All content saved and optimized
+- [ ] Frontmatter properly updated
+- [ ] Workflow status file updated (if exists)
+- [ ] Validation options presented
+- [ ] Next steps clearly communicated
+
+## FINAL REMINDER to give the user:
+
+The polished PRD serves as the foundation for all subsequent product development activities. All design, architecture, and development work should trace back to the requirements and vision documented in this PRD - update it also as needed as you continue planning.
+
+**Congratulations on completing the Product Requirements Document for {{project_name}}!** 🎉

_bmad/bmm/workflows/2-plan-workflows/prd/steps-e/step-e-01-discovery.md

@@ -0,0 +1,247 @@
+---
+name: 'step-e-01-discovery'
+description: 'Discovery & Understanding - Understand what user wants to edit and detect PRD format'
+
+# File references (ONLY variables used in this step)
+altStepFile: './step-e-01b-legacy-conversion.md'
+prdPurpose: '{project-root}/src/modules/bmm/workflows/2-plan-workflows/prd/data/prd-purpose.md'
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step E-1: Discovery & Understanding
+
+## STEP GOAL:
+
+Understand what the user wants to edit in the PRD, detect PRD format/type, check for validation report guidance, and route appropriately.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and PRD Improvement Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring analytical expertise and improvement guidance
+- ✅ User brings domain knowledge and edit requirements
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on discovering user intent and PRD format
+- 🚫 FORBIDDEN to make any edits yet
+- 💬 Approach: Inquisitive and analytical, understanding before acting
+- 🚪 This is a branch step - may route to legacy conversion
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Discover user's edit requirements
+- 🎯 Auto-detect validation reports in PRD folder (use as guide)
+- 🎯 Load validation report if provided (use as guide)
+- 🎯 Detect PRD format (BMAD/legacy)
+- 🎯 Route appropriately based on format
+- 💾 Document discoveries for next step
+- 🚫 FORBIDDEN to proceed without understanding requirements
+
+## CONTEXT BOUNDARIES:
+
+- Available context: PRD file to edit, optional validation report, auto-detected validation reports
+- Focus: User intent discovery and format detection only
+- Limits: Don't edit yet, don't validate yet
+- Dependencies: None - this is first edit step
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Load PRD Purpose Standards
+
+Load and read the complete file at:
+`{prdPurpose}` (data/prd-purpose.md)
+
+This file defines what makes a great BMAD PRD. Internalize this understanding - it will guide improvement recommendations.
+
+### 2. Discover PRD to Edit
+
+"**PRD Edit Workflow**
+
+Which PRD would you like to edit?
+
+Please provide the path to the PRD file you want to edit."
+
+**Wait for user to provide PRD path.**
+
+### 3. Validate PRD Exists and Load
+
+Once PRD path is provided:
+- Check if PRD file exists at specified path
+- If not found: "I cannot find a PRD at that path. Please check the path and try again."
+- If found: Load the complete PRD file including frontmatter
+
+### 4. Check for Existing Validation Report
+
+**Check if validation report exists in the PRD folder:**
+
+```bash
+# Look for most recent validation report in the PRD folder
+ls -t {prd_folder_path}/validation-report-*.md 2>/dev/null | head -1
+```
+
+**If validation report found:**
+
+Display:
+"**📋 Found Validation Report**
+
+I found a validation report from {validation_date} in the PRD folder.
+
+This report contains findings from previous validation checks and can help guide our edits to fix known issues.
+
+**Would you like to:**
+- **[U] Use validation report** - Load it to guide and prioritize edits
+- **[S] Skip** - Proceed with manual edit discovery"
+
+**Wait for user input.**
+
+**IF U (Use validation report):**
+- Load the validation report file
+- Extract findings, issues, and improvement suggestions
+- Note: "Validation report loaded - will use it to guide prioritized improvements"
+- Continue to step 5
+
+**IF S (Skip) or no validation report found:**
+- Note: "Proceeding with manual edit discovery"
+- Continue to step 5
+
+**If no validation report found:**
+- Note: "No validation report found in PRD folder"
+- Continue to step 5 without asking user
+
+### 5. Ask About Validation Report
+
+"**Do you have a validation report to guide edits?**
+
+If you've run the validation workflow on this PRD, I can use that report to guide improvements and prioritize changes.
+
+Validation report path (or type 'none'):"
+
+**Wait for user input.**
+
+**If validation report path provided:**
+- Load the validation report
+- Extract findings, severity, improvement suggestions
+- Note: "Validation report loaded - will use it to guide prioritized improvements"
+
+**If no validation report:**
+- Note: "Proceeding with manual edit discovery"
+- Continue to step 6
+
+### 6. Discover Edit Requirements
+
+"**What would you like to edit in this PRD?**
+
+Please describe the changes you want to make. For example:
+- Fix specific issues (information density, implementation leakage, etc.)
+- Add missing sections or content
+- Improve structure and flow
+- Convert to BMAD format (if legacy PRD)
+- General improvements
+- Other changes
+
+**Describe your edit goals:**"
+
+**Wait for user to describe their requirements.**
+
+### 7. Detect PRD Format
+
+Analyze the loaded PRD:
+
+**Extract all ## Level 2 headers** from PRD
+
+**Check for BMAD PRD core sections:**
+1. Executive Summary
+2. Success Criteria
+3. Product Scope
+4. User Journeys
+5. Functional Requirements
+6. Non-Functional Requirements
+
+**Classify format:**
+- **BMAD Standard:** 5-6 core sections present
+- **BMAD Variant:** 3-4 core sections present, generally follows BMAD patterns
+- **Legacy (Non-Standard):** Fewer than 3 core sections, does not follow BMAD structure
+
+### 8. Route Based on Format and Context
+
+**IF validation report provided OR PRD is BMAD Standard/Variant:**
+
+Display: "**Edit Requirements Understood**
+
+**PRD Format:** {classification}
+{If validation report: "**Validation Guide:** Yes - will use validation report findings"}
+**Edit Goals:** {summary of user's requirements}
+
+**Proceeding to deep review and analysis...**"
+
+Load and execute next step (step-e-02-review.md)
+
+**IF PRD is Legacy (Non-Standard) AND no validation report:**
+
+Display: "**Format Detected:** Legacy PRD
+
+This PRD does not follow BMAD standard structure (only {count}/6 core sections present).
+
+**Your edit goals:** {user's requirements}
+
+**How would you like to proceed?**"
+
+Present MENU OPTIONS below for user selection
+
+### 9. Present MENU OPTIONS (Legacy PRDs Only)
+
+**[C] Convert to BMAD Format** - Convert PRD to BMAD standard structure, then apply your edits
+**[E] Edit As-Is** - Apply your edits without converting the format
+**[X] Exit** - Exit and review conversion options
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input
+- Only proceed based on user selection
+
+#### Menu Handling Logic:
+
+- IF C (Convert): Load, read entire file, then execute {altStepFile} (step-e-01b-legacy-conversion.md)
+- IF E (Edit As-Is): Display "Proceeding with edits..." then load next step
+- IF X (Exit): Display summary and exit
+- IF Any other: help user, then redisplay menu
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- User's edit requirements clearly understood
+- Auto-detected validation reports loaded and analyzed (when found)
+- Manual validation report loaded and analyzed (if provided)
+- PRD format detected correctly
+- BMAD PRDs proceed directly to review step
+- Legacy PRDs pause and present conversion options
+- User can choose conversion path or edit as-is
+
+### ❌ SYSTEM FAILURE:
+
+- Not discovering user's edit requirements
+- Not auto-detecting validation reports in PRD folder
+- Not loading validation report when provided (auto or manual)
+- Missing format detection
+- Not pausing for legacy PRDs without guidance
+- Auto-proceeding without understanding intent
+
+**Master Rule:** Understand before editing. Detect format early so we can guide users appropriately. Auto-detect and use validation reports for prioritized improvements.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-e/step-e-01b-legacy-conversion.md

@@ -0,0 +1,208 @@
+---
+name: 'step-e-01b-legacy-conversion'
+description: 'Legacy PRD Conversion Assessment - Analyze legacy PRD and propose conversion strategy'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-e-02-review.md'
+prdFile: '{prd_file_path}'
+prdPurpose: '{project-root}/src/modules/bmm/workflows/2-plan-workflows/prd/data/prd-purpose.md'
+---
+
+# Step E-1B: Legacy PRD Conversion Assessment
+
+## STEP GOAL:
+
+Analyze legacy PRD against BMAD standards, identify gaps, propose conversion strategy, and let user choose how to proceed.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and PRD Improvement Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring BMAD standards expertise and conversion guidance
+- ✅ User brings domain knowledge and edit requirements
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on conversion assessment and proposal
+- 🚫 FORBIDDEN to perform conversion yet (that comes in edit step)
+- 💬 Approach: Analytical gap analysis with clear recommendations
+- 🚪 This is a branch step - user chooses conversion path
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Analyze legacy PRD against BMAD standard
+- 💾 Identify gaps and estimate conversion effort
+- 📖 Present conversion options with effort estimates
+- 🚫 FORBIDDEN to proceed without user selection
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Legacy PRD, user's edit requirements, prd-purpose standards
+- Focus: Conversion assessment only (not actual conversion)
+- Limits: Don't convert yet, don't validate yet
+- Dependencies: Step e-01 detected legacy format and routed here
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Attempt Sub-Process Assessment
+
+**Try to use Task tool with sub-agent:**
+
+"Perform legacy PRD conversion assessment:
+
+**Load the PRD and prd-purpose.md**
+
+**For each BMAD PRD section, analyze:**
+1. Does PRD have this section? (Executive Summary, Success Criteria, Product Scope, User Journeys, Functional Requirements, Non-Functional Requirements)
+2. If present: Is it complete and well-structured?
+3. If missing: What content exists that could migrate to this section?
+4. Effort to create/complete: Minimal / Moderate / Significant
+
+**Identify:**
+- Core sections present: {count}/6
+- Content gaps in each section
+- Overall conversion effort: Quick / Moderate / Substantial
+- Recommended approach: Full restructuring vs targeted improvements
+
+Return conversion assessment with gap analysis and effort estimate."
+
+**Graceful degradation (if no Task tool):**
+- Manually check PRD for each BMAD section
+- Note what's present and what's missing
+- Estimate conversion effort
+- Identify best conversion approach
+
+### 2. Build Gap Analysis
+
+**For each BMAD core section:**
+
+**Executive Summary:**
+- Present: [Yes/No/Partial]
+- Gap: [what's missing or incomplete]
+- Effort to Complete: [Minimal/Moderate/Significant]
+
+**Success Criteria:**
+- Present: [Yes/No/Partial]
+- Gap: [what's missing or incomplete]
+- Effort to Complete: [Minimal/Moderate/Significant]
+
+**Product Scope:**
+- Present: [Yes/No/Partial]
+- Gap: [what's missing or incomplete]
+- Effort to Complete: [Minimal/Moderate/Significant]
+
+**User Journeys:**
+- Present: [Yes/No/Partial]
+- Gap: [what's missing or incomplete]
+- Effort to Complete: [Minimal/Moderate/Significant]
+
+**Functional Requirements:**
+- Present: [Yes/No/Partial]
+- Gap: [what's missing or incomplete]
+- Effort to Complete: [Minimal/Moderate/Significant]
+
+**Non-Functional Requirements:**
+- Present: [Yes/No/Partial]
+- Gap: [what's missing or incomplete]
+- Effort to Complete: [Minimal/Moderate/Significant]
+
+**Overall Assessment:**
+- Sections Present: {count}/6
+- Total Conversion Effort: [Quick/Moderate/Substantial]
+- Recommended: [Full restructuring / Targeted improvements]
+
+### 3. Present Conversion Assessment
+
+Display:
+
+"**Legacy PRD Conversion Assessment**
+
+**Current PRD Structure:**
+- Core sections present: {count}/6
+{List which sections are present/missing}
+
+**Gap Analysis:**
+
+{Present gap analysis table showing each section's status and effort}
+
+**Overall Conversion Effort:** {effort level}
+
+**Your Edit Goals:**
+{Reiterate user's stated edit requirements}
+
+**Recommendation:**
+{Based on effort and user goals, recommend best approach}
+
+**How would you like to proceed?**"
+
+### 4. Present MENU OPTIONS
+
+**[R] Restructure to BMAD** - Full conversion to BMAD format, then apply your edits
+**[I] Targeted Improvements** - Apply your edits to existing structure without restructuring
+**[E] Edit & Restructure** - Do both: convert format AND apply your edits
+**[X] Exit** - Review assessment and decide
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input
+- Only proceed based on user selection
+
+#### Menu Handling Logic:
+
+- IF R (Restructure): Note conversion mode, then load next step
+- IF I (Targeted): Note targeted mode, then load next step
+- IF E (Edit & Restructure): Note both mode, then load next step
+- IF X (Exit): Display summary, exit
+
+### 5. Document Conversion Strategy
+
+Store conversion decision for next step:
+
+- **Conversion mode:** [Full restructuring / Targeted improvements / Both]
+- **Edit requirements:** [user's requirements from step e-01]
+- **Gap analysis:** [summary of gaps identified]
+
+Display: "**Conversion Strategy Documented**
+
+Mode: {conversion mode}
+Edit goals: {summary}
+
+**Proceeding to deep review...**"
+
+Load and execute {nextStepFile} (step-e-02-review.md)
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- All 6 BMAD core sections analyzed for gaps
+- Effort estimates provided for each section
+- Overall conversion effort assessed correctly
+- Clear recommendation provided based on effort and user goals
+- User chooses conversion strategy (restructure/targeted/both)
+- Conversion strategy documented for next step
+
+### ❌ SYSTEM FAILURE:
+
+- Not analyzing all 6 core sections
+- Missing effort estimates
+- Not providing clear recommendation
+- Auto-proceeding without user selection
+- Not documenting conversion strategy
+
+**Master Rule:** Legacy PRDs need conversion assessment so users understand the work involved and can choose the best approach.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-e/step-e-02-review.md

@@ -0,0 +1,249 @@
+---
+name: 'step-e-02-review'
+description: 'Deep Review & Analysis - Thoroughly review existing PRD and prepare detailed change plan'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-e-03-edit.md'
+prdFile: '{prd_file_path}'
+validationReport: '{validation_report_path}'  # If provided
+prdPurpose: '{project-root}/src/modules/bmm/workflows/2-plan-workflows/prd/data/prd-purpose.md'
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+---
+
+# Step E-2: Deep Review & Analysis
+
+## STEP GOAL:
+
+Thoroughly review the existing PRD, analyze validation report findings (if provided), and prepare a detailed change plan before editing.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and PRD Improvement Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring analytical expertise and improvement planning
+- ✅ User brings domain knowledge and approval authority
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on review and analysis, not editing yet
+- 🚫 FORBIDDEN to make changes to PRD in this step
+- 💬 Approach: Thorough analysis with user confirmation on plan
+- 🚪 This is a middle step - user confirms plan before proceeding
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Load and analyze validation report (if provided)
+- 🎯 Deep review of entire PRD
+- 🎯 Map validation findings to specific sections
+- 🎯 Prepare detailed change plan
+- 💬 Get user confirmation on plan
+- 🚫 FORBIDDEN to proceed to edit without user approval
+
+## CONTEXT BOUNDARIES:
+
+- Available context: PRD file, validation report (if provided), user requirements from step e-01
+- Focus: Analysis and planning only (no editing)
+- Limits: Don't change PRD yet, don't validate yet
+- Dependencies: Step e-01 completed - requirements and format known
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Attempt Sub-Process Deep Review
+
+**Try to use Task tool with sub-agent:**
+
+"Perform deep PRD review and change planning:
+
+**Context from step e-01:**
+- User's edit requirements: {user_requirements}
+- PRD format: {BMAD/legacy}
+- Validation report provided: {yes/no}
+- Conversion mode: {restructure/targeted/both} (if legacy)
+
+**IF validation report provided:**
+1. Extract all findings from validation report
+2. Map findings to specific PRD sections
+3. Prioritize by severity: Critical > Warning > Informational
+4. For each critical issue: identify specific fix needed
+5. For user's manual edit goals: identify where in PRD to apply
+
+**IF no validation report:**
+1. Read entire PRD thoroughly
+2. Analyze against BMAD standards (from prd-purpose.md)
+3. Identify issues in:
+   - Information density (anti-patterns)
+   - Structure and flow
+   - Completeness (missing sections/content)
+   - Measurability (unmeasurable requirements)
+   - Traceability (broken chains)
+   - Implementation leakage
+4. Map user's edit goals to specific sections
+
+**Output:**
+- Section-by-section analysis
+- Specific changes needed for each section
+- Prioritized action list
+- Recommended order for applying changes
+
+Return detailed change plan with section breakdown."
+
+**Graceful degradation (if no Task tool):**
+- Manually read PRD sections
+- Manually analyze validation report findings (if provided)
+- Build section-by-section change plan
+- Prioritize changes by severity/user goals
+
+### 2. Build Change Plan
+
+**Organize by PRD section:**
+
+**For each section (in order):**
+- **Current State:** Brief description of what exists
+- **Issues Identified:** [List from validation report or manual analysis]
+- **Changes Needed:** [Specific changes required]
+- **Priority:** [Critical/High/Medium/Low]
+- **User Requirements Met:** [Which user edit goals address this section]
+
+**Include:**
+- Sections to add (if missing)
+- Sections to update (if present but needs work)
+- Content to remove (if incorrect/leakage)
+- Structure changes (if reformatting needed)
+
+### 3. Prepare Change Plan Summary
+
+**Summary sections:**
+
+**Changes by Type:**
+- **Additions:** {count} sections to add
+- **Updates:** {count} sections to update
+- **Removals:** {count} items to remove
+- **Restructuring:** {yes/no} if format conversion needed
+
+**Priority Distribution:**
+- **Critical:** {count} changes (must fix)
+- **High:** {count} changes (important)
+- **Medium:** {count} changes (nice to have)
+- **Low:** {count} changes (optional)
+
+**Estimated Effort:**
+[Quick/Moderate/Substantial] based on scope and complexity
+
+### 4. Present Change Plan to User
+
+Display:
+
+"**Deep Review Complete - Change Plan**
+
+**PRD Analysis:**
+{Brief summary of PRD current state}
+
+{If validation report provided:}
+**Validation Findings:**
+{count} issues identified: {critical} critical, {warning} warnings
+
+**Your Edit Requirements:**
+{summary of what user wants to edit}
+
+**Proposed Change Plan:**
+
+**By Section:**
+{Present section-by-section breakdown}
+
+**By Priority:**
+- Critical: {count} items
+- High: {count} items
+- Medium: {count} items
+
+**Estimated Effort:** {effort level}
+
+**Questions:**
+1. Does this change plan align with what you had in mind?
+2. Any sections I should add/remove/reprioritize?
+3. Any concerns before I proceed with edits?
+
+**Review the plan and let me know if you'd like any adjustments.**"
+
+### 5. Get User Confirmation
+
+Wait for user to review and provide feedback.
+
+**If user wants adjustments:**
+- Discuss requested changes
+- Revise change plan accordingly
+- Represent for confirmation
+
+**If user approves:**
+- Note: "Change plan approved. Proceeding to edit step."
+- Continue to step 6
+
+### 6. Document Approved Plan
+
+Store approved change plan for next step:
+
+- **Approved changes:** Section-by-section list
+- **Priority order:** Sequence to apply changes
+- **User confirmed:** Yes
+
+Display: "**Change Plan Approved**
+
+{Brief summary of approved plan}
+
+**Proceeding to edit step...**"
+
+Load and execute {nextStepFile} (step-e-03-edit.md)
+
+### 7. Present MENU OPTIONS (If User Wants Discussion)
+
+**[A] Advanced Elicitation** - Get additional perspectives on change plan
+**[P] Party Mode** - Discuss with team for more ideas
+**[C] Continue to Edit** - Proceed with approved plan
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input
+- Only proceed to edit when user selects 'C'
+
+#### Menu Handling Logic:
+
+- IF A: Execute {advancedElicitationTask}, then return to discussion
+- IF P: Execute {partyModeWorkflow}, then return to discussion
+- IF C: Document approval, then load {nextStepFile}
+- IF Any other: discuss, then redisplay menu
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Validation report findings fully analyzed (if provided)
+- Deep PRD review completed systematically
+- Change plan built section-by-section
+- Changes prioritized by severity/user goals
+- User presented with clear plan
+- User confirms or adjusts plan
+- Approved plan documented for next step
+
+### ❌ SYSTEM FAILURE:
+
+- Not analyzing validation report findings (if provided)
+- Superficial review instead of deep analysis
+- Missing section-by-section breakdown
+- Not prioritizing changes
+- Proceeding without user approval
+
+**Master Rule:** Plan before editing. Thorough analysis ensures we make the right changes in the right order. User approval prevents misalignment.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-e/step-e-03-edit.md

@@ -0,0 +1,253 @@
+---
+name: 'step-e-03-edit'
+description: 'Edit & Update - Apply changes to PRD following approved change plan'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-e-04-complete.md'
+prdFile: '{prd_file_path}'
+prdPurpose: '{project-root}/src/modules/bmm/workflows/2-plan-workflows/prd/data/prd-purpose.md'
+---
+
+# Step E-3: Edit & Update
+
+## STEP GOAL:
+
+Apply changes to the PRD following the approved change plan from step e-02, including content updates, structure improvements, and format conversion if needed.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 ALWAYS generate content WITH user input/approval
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and PRD Improvement Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring analytical expertise and precise editing skills
+- ✅ User brings domain knowledge and approval authority
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on implementing approved changes from step e-02
+- 🚫 FORBIDDEN to make changes beyond the approved plan
+- 💬 Approach: Methodical, section-by-section execution
+- 🚪 This is a middle step - user can request adjustments
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Follow approved change plan systematically
+- 💾 Edit PRD content according to plan
+- 📖 Update frontmatter as needed
+- 🚫 FORBIDDEN to proceed without completion
+
+## CONTEXT BOUNDARIES:
+
+- Available context: PRD file, approved change plan from step e-02, prd-purpose standards
+- Focus: Implementing changes from approved plan only
+- Limits: Don't add changes beyond plan, don't validate yet
+- Dependencies: Step e-02 completed - plan approved by user
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Retrieve Approved Change Plan
+
+From step e-02, retrieve:
+- **Approved changes:** Section-by-section list
+- **Priority order:** Sequence to apply changes
+- **User requirements:** Edit goals from step e-01
+
+Display: "**Starting PRD Edits**
+
+**Change Plan:** {summary}
+**Total Changes:** {count}
+**Estimated Effort:** {effort level}
+
+**Proceeding with edits section by section...**"
+
+### 2. Attempt Sub-Process Edits (For Complex Changes)
+
+**Try to use Task tool with sub-agent for major sections:**
+
+"Execute PRD edits for {section_name}:
+
+**Context:**
+- Section to edit: {section_name}
+- Current content: {existing content}
+- Changes needed: {specific changes from plan}
+- BMAD PRD standards: Load from prd-purpose.md
+
+**Tasks:**
+1. Read current PRD section
+2. Apply specified changes
+3. Ensure BMAD PRD principles compliance:
+   - High information density (no filler)
+   - Measurable requirements
+   - Clear structure
+   - Proper markdown formatting
+4. Return updated section content
+
+Apply changes and return updated section."
+
+**Graceful degradation (if no Task tool):**
+- Perform edits directly in current context
+- Load PRD section, apply changes, save
+
+### 3. Execute Changes Section-by-Section
+
+**For each section in approved plan (in priority order):**
+
+**a) Load current section**
+- Read the current PRD section content
+- Note what exists
+
+**b) Apply changes per plan**
+- Additions: Create new sections with proper content
+- Updates: Modify existing content per plan
+- Removals: Remove specified content
+- Restructuring: Reformat content to BMAD standard
+
+**c) Update PRD file**
+- Apply changes to PRD
+- Save updated PRD
+- Verify changes applied correctly
+
+**Display progress after each section:**
+"**Section Updated:** {section_name}
+Changes: {brief summary}
+{More sections remaining...}"
+
+### 4. Handle Restructuring (If Needed)
+
+**If conversion mode is "Full restructuring" or "Both":**
+
+**For restructuring:**
+- Reorganize PRD to BMAD standard structure
+- Ensure proper ## Level 2 headers
+- Reorder sections logically
+- Update PRD frontmatter to match BMAD format
+
+**Follow BMAD PRD structure:**
+1. Executive Summary
+2. Success Criteria
+3. Product Scope
+4. User Journeys
+5. Domain Requirements (if applicable)
+6. Innovation Analysis (if applicable)
+7. Project-Type Requirements
+8. Functional Requirements
+9. Non-Functional Requirements
+
+Display: "**PRD Restructured**
+BMAD standard structure applied.
+{Sections added/reordered}"
+
+### 5. Update PRD Frontmatter
+
+**Ensure frontmatter is complete and accurate:**
+
+```yaml
+---
+workflowType: 'prd'
+workflow: 'create'  # or 'validate' or 'edit'
+classification:
+  domain: '{domain}'
+  projectType: '{project_type}'
+  complexity: '{complexity}'
+inputDocuments: [list of input documents]
+stepsCompleted: ['step-e-01-discovery', 'step-e-02-review', 'step-e-03-edit']
+lastEdited: '{current_date}'
+editHistory:
+  - date: '{current_date}'
+    changes: '{summary of changes}'
+---
+```
+
+**Update frontmatter accordingly.**
+
+### 6. Final Review of Changes
+
+**Load complete updated PRD**
+
+**Verify:**
+- All approved changes applied correctly
+- PRD structure is sound
+- No unintended modifications
+- Frontmatter is accurate
+
+**If issues found:**
+- Fix them now
+- Note corrections made
+
+**If user wants adjustments:**
+- Accept feedback and make adjustments
+- Re-verify after adjustments
+
+### 7. Confirm Completion
+
+Display:
+
+"**PRD Edits Complete**
+
+**Changes Applied:** {count} sections modified
+**PRD Updated:** {prd_file_path}
+
+**Summary of Changes:**
+{Brief bullet list of major changes}
+
+**PRD is ready for:**
+- Use in downstream workflows (UX, Architecture)
+- Validation (if not yet validated)
+
+**What would you like to do next?**"
+
+### 8. Present MENU OPTIONS
+
+**[V] Run Validation** - Execute full validation workflow (steps-v/step-v-01-discovery.md)
+**[S] Summary Only** - End with summary of changes (no validation)
+**[A] Adjust** - Make additional edits
+**[X] Exit** - Exit edit workflow
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input
+- Only proceed based on user selection
+
+#### Menu Handling Logic:
+
+- IF V (Validate): Display "Starting validation workflow..." then load and execute steps-v/step-v-01-discovery.md
+- IF S (Summary): Present edit summary and exit
+- IF A (Adjust): Accept additional requirements, loop back to editing
+- IF X (Exit): Display summary and exit
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- All approved changes from step e-02 applied correctly
+- Changes executed in planned priority order
+- Restructuring completed (if needed)
+- Frontmatter updated accurately
+- Final verification confirms changes
+- User can proceed to validation or exit with summary
+- Option to run validation seamlessly integrates edit and validate modes
+
+### ❌ SYSTEM FAILURE:
+
+- Making changes beyond approved plan
+- Not following priority order
+- Missing restructuring (if conversion mode)
+- Not updating frontmatter
+- No final verification
+- Not saving updated PRD
+
+**Master Rule:** Execute the plan exactly as approved. PRD is now ready for validation or downstream use. Validation integration ensures quality.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-e/step-e-04-complete.md

@@ -0,0 +1,168 @@
+---
+name: 'step-e-04-complete'
+description: 'Complete & Validate - Present options for next steps including full validation'
+
+# File references (ONLY variables used in this step)
+prdFile: '{prd_file_path}'
+validationWorkflow: './steps-v/step-v-01-discovery.md'
+---
+
+# Step E-4: Complete & Validate
+
+## STEP GOAL:
+
+Present summary of completed edits and offer next steps including seamless integration with validation workflow.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 ALWAYS generate content WITH user input/approval
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and PRD Improvement Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring synthesis and summary expertise
+- ✅ User chooses next actions
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on presenting summary and options
+- 🚫 FORBIDDEN to make additional changes
+- 💬 Approach: Clear, concise summary with actionable options
+- 🚪 This is the final edit step - no more edits
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Compile summary of all changes made
+- 🎯 Present options clearly with expected outcomes
+- 📖 Route to validation if user chooses
+- 🚫 FORBIDDEN to proceed without user selection
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Updated PRD file, edit history from step e-03
+- Focus: Summary and options only (no more editing)
+- Limits: Don't make changes, just present options
+- Dependencies: Step e-03 completed - all edits applied
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Compile Edit Summary
+
+From step e-03 change execution, compile:
+
+**Changes Made:**
+- Sections added: {list with names}
+- Sections updated: {list with names}
+- Content removed: {list}
+- Structure changes: {description}
+
+**Edit Details:**
+- Total sections affected: {count}
+- Mode: {restructure/targeted/both}
+- Priority addressed: {Critical/High/Medium/Low}
+
+**PRD Status:**
+- Format: {BMAD Standard / BMAD Variant / Legacy (converted)}
+- Completeness: {assessment}
+- Ready for: {downstream use cases}
+
+### 2. Present Completion Summary
+
+Display:
+
+"**✓ PRD Edit Complete**
+
+**Updated PRD:** {prd_file_path}
+
+**Changes Summary:**
+{Present bulleted list of major changes}
+
+**Edit Mode:** {mode}
+**Sections Modified:** {count}
+
+**PRD Format:** {format}
+
+**PRD is now ready for:**
+- Downstream workflows (UX Design, Architecture)
+- Validation to ensure quality
+- Production use
+
+**What would you like to do next?**"
+
+### 3. Present MENU OPTIONS
+
+Display:
+
+**[V] Run Full Validation** - Execute complete validation workflow (steps-v) to verify PRD quality
+**[E] Edit More** - Make additional edits to the PRD
+**[S] Summary** - End with detailed summary of changes
+**[X] Exit** - Exit edit workflow
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input
+- Only proceed based on user selection
+
+#### Menu Handling Logic:
+
+- **IF V (Run Full Validation):**
+  - Display: "**Starting Validation Workflow**"
+  - Display: "This will run all 13 validation checks on the updated PRD."
+  - Display: "Preparing to validate: {prd_file_path}"
+  - Display: "**Proceeding to validation...**"
+  - Load, read entire file, then execute {validationWorkflow} (steps-v/step-v-01-discovery.md)
+  - Note: This hands off to the validation workflow which will run its complete 13-step process
+
+- **IF E (Edit More):**
+  - Display: "**Additional Edits**"
+  - Ask: "What additional edits would you like to make?"
+  - Accept input, then display: "**Returning to edit step...**"
+  - Load and execute step-e-03-edit.md again
+
+- **IF S (Summary):**
+  - Display detailed summary including:
+    - Complete list of all changes made
+    - Before/after comparison (key improvements)
+    - Recommendations for next steps
+  - Display: "**Edit Workflow Complete**"
+  - Exit
+
+- **IF X (Exit):**
+  - Display summary
+  - Display: "**Edit Workflow Complete**"
+  - Exit
+
+- **IF Any other:** Help user, then redisplay menu
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Complete edit summary compiled accurately
+- All changes clearly documented
+- Options presented with clear expectations
+- Validation option seamlessly integrates with steps-v workflow
+- User can validate, edit more, or exit
+- Clean handoff to validation workflow (if chosen)
+- Edit workflow completes properly
+
+### ❌ SYSTEM FAILURE:
+
+- Missing changes in summary
+- Not offering validation option
+- Not documenting completion properly
+- No clear handoff to validation workflow
+
+**Master Rule:** Edit workflow seamlessly integrates with validation. User can edit → validate → edit again → validate again in iterative improvement cycle.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-v/step-v-01-discovery.md

@@ -0,0 +1,218 @@
+---
+name: 'step-v-01-discovery'
+description: 'Document Discovery & Confirmation - Handle fresh context validation, confirm PRD path, discover input documents'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-02-format-detection.md'
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+prdPurpose: '../data/prd-purpose.md'
+---
+
+# Step 1: Document Discovery & Confirmation
+
+## STEP GOAL:
+
+Handle fresh context validation by confirming PRD path, discovering and loading input documents from frontmatter, and initializing the validation report.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and Quality Assurance Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring systematic validation expertise and analytical rigor
+- ✅ User brings domain knowledge and specific PRD context
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on discovering PRD and input documents, not validating yet
+- 🚫 FORBIDDEN to perform any validation checks in this step
+- 💬 Approach: Systematic discovery with clear reporting to user
+- 🚪 This is the setup step - get everything ready for validation
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Discover and confirm PRD to validate
+- 💾 Load PRD and all input documents from frontmatter
+- 📖 Initialize validation report next to PRD
+- 🚫 FORBIDDEN to load next step until user confirms setup
+
+## CONTEXT BOUNDARIES:
+
+- Available context: PRD path (user-specified or discovered), workflow configuration
+- Focus: Document discovery and setup only
+- Limits: Don't perform validation, don't skip discovery
+- Dependencies: Configuration loaded from PRD workflow.md initialization
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Load PRD Purpose and Standards
+
+Load and read the complete file at:
+`{prdPurpose}`
+
+This file contains the BMAD PRD philosophy, standards, and validation criteria that will guide all validation checks. Internalize this understanding - it defines what makes a great BMAD PRD.
+
+### 2. Discover PRD to Validate
+
+**If PRD path provided as invocation parameter:**
+- Use provided path
+
+**If no PRD path provided:**
+"**PRD Validation Workflow**
+
+Which PRD would you like to validate?
+
+Please provide the path to the PRD file you want to validate."
+
+**Wait for user to provide PRD path.**
+
+### 3. Validate PRD Exists and Load
+
+Once PRD path is provided:
+
+- Check if PRD file exists at specified path
+- If not found: "I cannot find a PRD at that path. Please check the path and try again."
+- If found: Load the complete PRD file including frontmatter
+
+### 4. Extract Frontmatter and Input Documents
+
+From the loaded PRD frontmatter, extract:
+
+- `inputDocuments: []` array (if present)
+- Any other relevant metadata (classification, date, etc.)
+
+**If no inputDocuments array exists:**
+Note this and proceed with PRD-only validation
+
+### 5. Load Input Documents
+
+For each document listed in `inputDocuments`:
+
+- Attempt to load the document
+- Track successfully loaded documents
+- Note any documents that fail to load
+
+**Build list of loaded input documents:**
+- Product Brief (if present)
+- Research documents (if present)
+- Other reference materials (if present)
+
+### 6. Ask About Additional Reference Documents
+
+"**I've loaded the following documents from your PRD frontmatter:**
+
+{list loaded documents with file names}
+
+**Are there any additional reference documents you'd like me to include in this validation?**
+
+These could include:
+- Additional research or context documents
+- Project documentation not tracked in frontmatter
+- Standards or compliance documents
+- Competitive analysis or benchmarks
+
+Please provide paths to any additional documents, or type 'none' to proceed."
+
+**Load any additional documents provided by user.**
+
+### 7. Initialize Validation Report
+
+Create validation report at: `{validationReportPath}`
+
+**Initialize with frontmatter:**
+```yaml
+---
+validationTarget: '{prd_path}'
+validationDate: '{current_date}'
+inputDocuments: [list of all loaded documents]
+validationStepsCompleted: []
+validationStatus: IN_PROGRESS
+---
+```
+
+**Initial content:**
+```markdown
+# PRD Validation Report
+
+**PRD Being Validated:** {prd_path}
+**Validation Date:** {current_date}
+
+## Input Documents
+
+{list all documents loaded for validation}
+
+## Validation Findings
+
+[Findings will be appended as validation progresses]
+```
+
+### 8. Present Discovery Summary
+
+"**Setup Complete!**
+
+**PRD to Validate:** {prd_path}
+
+**Input Documents Loaded:**
+- PRD: {prd_name} ✓
+- Product Brief: {count} {if count > 0}✓{else}(none found){/if}
+- Research: {count} {if count > 0}✓{else}(none found){/if}
+- Additional References: {count} {if count > 0}✓{else}(none){/if}
+
+**Validation Report:** {validationReportPath}
+
+**Ready to begin validation.**"
+
+### 9. Present MENU OPTIONS
+
+Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Format Detection
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- User can ask questions or add more documents - always respond and redisplay menu
+
+#### Menu Handling Logic:
+
+- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
+- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
+- IF C: Load, read entire file, then execute {nextStepFile} to begin format detection
+- IF user provides additional document: Load it, update report, redisplay summary
+- IF Any other: help user, then redisplay menu
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- PRD path discovered and confirmed
+- PRD file exists and loads successfully
+- All input documents from frontmatter loaded
+- Additional reference documents (if any) loaded
+- Validation report initialized next to PRD
+- User clearly informed of setup status
+- Menu presented and user input handled correctly
+
+### ❌ SYSTEM FAILURE:
+
+- Proceeding with non-existent PRD file
+- Not loading input documents from frontmatter
+- Creating validation report in wrong location
+- Proceeding without user confirming setup
+- Not handling missing input documents gracefully
+
+**Master Rule:** Complete discovery and setup BEFORE validation. This step ensures everything is in place for systematic validation checks.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-v/step-v-02-format-detection.md

@@ -0,0 +1,191 @@
+---
+name: 'step-v-02-format-detection'
+description: 'Format Detection & Structure Analysis - Classify PRD format and route appropriately'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-03-density-validation.md'
+altStepFile: './step-v-02b-parity-check.md'
+prdFile: '{prd_file_path}'
+validationReportPath: '{validation_report_path}'
+---
+
+# Step 2: Format Detection & Structure Analysis
+
+## STEP GOAL:
+
+Detect if PRD follows BMAD format and route appropriately - classify as BMAD Standard / BMAD Variant / Non-Standard, with optional parity check for non-standard formats.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and Quality Assurance Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring systematic validation expertise and pattern recognition
+- ✅ User brings domain knowledge and PRD context
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on detecting format and classifying structure
+- 🚫 FORBIDDEN to perform other validation checks in this step
+- 💬 Approach: Analytical and systematic, clear reporting of findings
+- 🚪 This is a branch step - may route to parity check for non-standard PRDs
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Analyze PRD structure systematically
+- 💾 Append format findings to validation report
+- 📖 Route appropriately based on format classification
+- 🚫 FORBIDDEN to skip format detection or proceed without classification
+
+## CONTEXT BOUNDARIES:
+
+- Available context: PRD file loaded in step 1, validation report initialized
+- Focus: Format detection and classification only
+- Limits: Don't perform other validation, don't skip classification
+- Dependencies: Step 1 completed - PRD loaded and report initialized
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Extract PRD Structure
+
+Load the complete PRD file and extract:
+
+**All Level 2 (##) headers:**
+- Scan through entire PRD document
+- Extract all ## section headers
+- List them in order
+
+**PRD frontmatter:**
+- Extract classification.domain if present
+- Extract classification.projectType if present
+- Note any other relevant metadata
+
+### 2. Check for BMAD PRD Core Sections
+
+Check if the PRD contains the following BMAD PRD core sections:
+
+1. **Executive Summary** (or variations: ## Executive Summary, ## Overview, ## Introduction)
+2. **Success Criteria** (or: ## Success Criteria, ## Goals, ## Objectives)
+3. **Product Scope** (or: ## Product Scope, ## Scope, ## In Scope, ## Out of Scope)
+4. **User Journeys** (or: ## User Journeys, ## User Stories, ## User Flows)
+5. **Functional Requirements** (or: ## Functional Requirements, ## Features, ## Capabilities)
+6. **Non-Functional Requirements** (or: ## Non-Functional Requirements, ## NFRs, ## Quality Attributes)
+
+**Count matches:**
+- How many of these 6 core sections are present?
+- Which specific sections are present?
+- Which are missing?
+
+### 3. Classify PRD Format
+
+Based on core section count, classify:
+
+**BMAD Standard:**
+- 5-6 core sections present
+- Follows BMAD PRD structure closely
+
+**BMAD Variant:**
+- 3-4 core sections present
+- Generally follows BMAD patterns but may have structural differences
+- Missing some sections but recognizable as BMAD-style
+
+**Non-Standard:**
+- Fewer than 3 core sections present
+- Does not follow BMAD PRD structure
+- May be completely custom format, legacy format, or from another framework
+
+### 4. Report Format Findings to Validation Report
+
+Append to validation report:
+
+```markdown
+## Format Detection
+
+**PRD Structure:**
+[List all ## Level 2 headers found]
+
+**BMAD Core Sections Present:**
+- Executive Summary: [Present/Missing]
+- Success Criteria: [Present/Missing]
+- Product Scope: [Present/Missing]
+- User Journeys: [Present/Missing]
+- Functional Requirements: [Present/Missing]
+- Non-Functional Requirements: [Present/Missing]
+
+**Format Classification:** [BMAD Standard / BMAD Variant / Non-Standard]
+**Core Sections Present:** [count]/6
+```
+
+### 5. Route Based on Format Classification
+
+**IF format is BMAD Standard or BMAD Variant:**
+
+Display: "**Format Detected:** {classification}
+
+Proceeding to systematic validation checks..."
+
+Immediately load and execute {nextStepFile} (step-v-03-density-validation.md)
+
+**IF format is Non-Standard (< 3 core sections):**
+
+Display: "**Format Detected:** Non-Standard PRD
+
+This PRD does not follow BMAD standard structure (only {count}/6 core sections present).
+
+You have options:"
+
+Present MENU OPTIONS below for user selection
+
+### 6. Present MENU OPTIONS (Non-Standard PRDs Only)
+
+**[A] Parity Check** - Analyze gaps and estimate effort to reach BMAD PRD parity
+**[B] Validate As-Is** - Proceed with validation using current structure
+**[C] Exit** - Exit validation and review format findings
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input
+- Only proceed based on user selection
+
+#### Menu Handling Logic:
+
+- IF A (Parity Check): Load, read entire file, then execute {altStepFile} (step-v-02b-parity-check.md)
+- IF B (Validate As-Is): Display "Proceeding with validation..." then load, read entire file, then execute {nextStepFile}
+- IF C (Exit): Display format findings summary and exit validation
+- IF Any other: help user respond, then redisplay menu
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- All ## Level 2 headers extracted successfully
+- BMAD core sections checked systematically
+- Format classified correctly based on section count
+- Findings reported to validation report
+- BMAD Standard/Variant PRDs proceed directly to next validation step
+- Non-Standard PRDs pause and present options to user
+- User can choose parity check, validate as-is, or exit
+
+### ❌ SYSTEM FAILURE:
+
+- Not extracting all headers before classification
+- Incorrect format classification
+- Not reporting findings to validation report
+- Not pausing for non-standard PRDs
+- Proceeding without user decision for non-standard formats
+
+**Master Rule:** Format detection determines validation path. Non-standard PRDs require user choice before proceeding.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-v/step-v-02b-parity-check.md

@@ -0,0 +1,209 @@
+---
+name: 'step-v-02b-parity-check'
+description: 'Document Parity Check - Analyze non-standard PRD and identify gaps to achieve BMAD PRD parity'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-03-density-validation.md'
+prdFile: '{prd_file_path}'
+validationReportPath: '{validation_report_path}'
+---
+
+# Step 2B: Document Parity Check
+
+## STEP GOAL:
+
+Analyze non-standard PRD and identify gaps to achieve BMAD PRD parity, presenting user with options for how to proceed.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and Quality Assurance Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring BMAD PRD standards expertise and gap analysis
+- ✅ User brings domain knowledge and PRD context
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on analyzing gaps and estimating parity effort
+- 🚫 FORBIDDEN to perform other validation checks in this step
+- 💬 Approach: Systematic gap analysis with clear recommendations
+- 🚪 This is an optional branch step - user chooses next action
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Analyze each BMAD PRD section for gaps
+- 💾 Append parity analysis to validation report
+- 📖 Present options and await user decision
+- 🚫 FORBIDDEN to proceed without user selection
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Non-standard PRD from step 2, validation report in progress
+- Focus: Parity analysis only - what's missing, what's needed
+- Limits: Don't perform validation checks, don't auto-proceed
+- Dependencies: Step 2 classified PRD as non-standard and user chose parity check
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Analyze Each BMAD PRD Section
+
+For each of the 6 BMAD PRD core sections, analyze:
+
+**Executive Summary:**
+- Does PRD have vision/overview?
+- Is problem statement clear?
+- Are target users identified?
+- Gap: [What's missing or incomplete]
+
+**Success Criteria:**
+- Are measurable goals defined?
+- Is success clearly defined?
+- Gap: [What's missing or incomplete]
+
+**Product Scope:**
+- Is scope clearly defined?
+- Are in-scope items listed?
+- Are out-of-scope items listed?
+- Gap: [What's missing or incomplete]
+
+**User Journeys:**
+- Are user types/personas identified?
+- Are user flows documented?
+- Gap: [What's missing or incomplete]
+
+**Functional Requirements:**
+- Are features/capabilities listed?
+- Are requirements structured?
+- Gap: [What's missing or incomplete]
+
+**Non-Functional Requirements:**
+- Are quality attributes defined?
+- Are performance/security/etc. requirements documented?
+- Gap: [What's missing or incomplete]
+
+### 2. Estimate Effort to Reach Parity
+
+For each missing or incomplete section, estimate:
+
+**Effort Level:**
+- Minimal - Section exists but needs minor enhancements
+- Moderate - Section missing but content exists elsewhere in PRD
+- Significant - Section missing, requires new content creation
+
+**Total Parity Effort:**
+- Based on individual section estimates
+- Classify overall: Quick / Moderate / Substantial effort
+
+### 3. Report Parity Analysis to Validation Report
+
+Append to validation report:
+
+```markdown
+## Parity Analysis (Non-Standard PRD)
+
+### Section-by-Section Gap Analysis
+
+**Executive Summary:**
+- Status: [Present/Missing/Incomplete]
+- Gap: [specific gap description]
+- Effort to Complete: [Minimal/Moderate/Significant]
+
+**Success Criteria:**
+- Status: [Present/Missing/Incomplete]
+- Gap: [specific gap description]
+- Effort to Complete: [Minimal/Moderate/Significant]
+
+**Product Scope:**
+- Status: [Present/Missing/Incomplete]
+- Gap: [specific gap description]
+- Effort to Complete: [Minimal/Moderate/Significant]
+
+**User Journeys:**
+- Status: [Present/Missing/Incomplete]
+- Gap: [specific gap description]
+- Effort to Complete: [Minimal/Moderate/Significant]
+
+**Functional Requirements:**
+- Status: [Present/Missing/Incomplete]
+- Gap: [specific gap description]
+- Effort to Complete: [Minimal/Moderate/Significant]
+
+**Non-Functional Requirements:**
+- Status: [Present/Missing/Incomplete]
+- Gap: [specific gap description]
+- Effort to Complete: [Minimal/Moderate/Significant]
+
+### Overall Parity Assessment
+
+**Overall Effort to Reach BMAD Standard:** [Quick/Moderate/Substantial]
+**Recommendation:** [Brief recommendation based on analysis]
+```
+
+### 4. Present Parity Analysis and Options
+
+Display:
+
+"**Parity Analysis Complete**
+
+Your PRD is missing {count} of 6 core BMAD PRD sections. The overall effort to reach BMAD standard is: **{effort level}**
+
+**Quick Summary:**
+[2-3 sentence summary of key gaps]
+
+**Recommendation:**
+{recommendation from analysis}
+
+**How would you like to proceed?**"
+
+### 5. Present MENU OPTIONS
+
+**[C] Continue Validation** - Proceed with validation using current structure
+**[E] Exit & Review** - Exit validation and review parity report
+**[S] Save & Exit** - Save parity report and exit
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input
+- Only proceed based on user selection
+
+#### Menu Handling Logic:
+
+- IF C (Continue): Display "Proceeding with validation..." then load, read entire file, then execute {nextStepFile}
+- IF E (Exit): Display parity summary and exit validation
+- IF S (Save): Confirm saved, display summary, exit
+- IF Any other: help user respond, then redisplay menu
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- All 6 BMAD PRD sections analyzed for gaps
+- Effort estimates provided for each gap
+- Overall parity effort assessed correctly
+- Parity analysis reported to validation report
+- Clear summary presented to user
+- User can choose to continue validation, exit, or save report
+
+### ❌ SYSTEM FAILURE:
+
+- Not analyzing all 6 sections systematically
+- Missing effort estimates
+- Not reporting parity analysis to validation report
+- Auto-proceeding without user decision
+- Unclear recommendations
+
+**Master Rule:** Parity check informs user of gaps and effort, but user decides whether to proceed with validation or address gaps first.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-v/step-v-03-density-validation.md

@@ -0,0 +1,174 @@
+---
+name: 'step-v-03-density-validation'
+description: 'Information Density Check - Scan for anti-patterns that violate information density principles'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-04-brief-coverage-validation.md'
+prdFile: '{prd_file_path}'
+validationReportPath: '{validation_report_path}'
+---
+
+# Step 3: Information Density Validation
+
+## STEP GOAL:
+
+Validate PRD meets BMAD information density standards by scanning for conversational filler, wordy phrases, and redundant expressions that violate conciseness principles.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and Quality Assurance Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in systematic validation, not collaborative dialogue
+- ✅ You bring analytical rigor and attention to detail
+- ✅ This step runs autonomously - no user input needed
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on information density anti-patterns
+- 🚫 FORBIDDEN to validate other aspects in this step
+- 💬 Approach: Systematic scanning and categorization
+- 🚪 This is a validation sequence step - auto-proceeds when complete
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Scan PRD for density anti-patterns systematically
+- 💾 Append density findings to validation report
+- 📖 Display "Proceeding to next check..." and load next step
+- 🚫 FORBIDDEN to pause or request user input
+
+## CONTEXT BOUNDARIES:
+
+- Available context: PRD file, validation report with format findings
+- Focus: Information density validation only
+- Limits: Don't validate other aspects, don't pause for user input
+- Dependencies: Step 2 completed - format classification done
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Attempt Sub-Process Validation
+
+**Try to use Task tool to spawn a subprocess:**
+
+"Perform information density validation on this PRD:
+
+1. Load the PRD file
+2. Scan for the following anti-patterns:
+   - Conversational filler phrases (examples: 'The system will allow users to...', 'It is important to note that...', 'In order to')
+   - Wordy phrases (examples: 'Due to the fact that', 'In the event of', 'For the purpose of')
+   - Redundant phrases (examples: 'Future plans', 'Absolutely essential', 'Past history')
+3. Count violations by category with line numbers
+4. Classify severity: Critical (>10 violations), Warning (5-10), Pass (<5)
+
+Return structured findings with counts and examples."
+
+### 2. Graceful Degradation (if Task tool unavailable)
+
+If Task tool unavailable, perform analysis directly:
+
+**Scan for conversational filler patterns:**
+- "The system will allow users to..."
+- "It is important to note that..."
+- "In order to"
+- "For the purpose of"
+- "With regard to"
+- Count occurrences and note line numbers
+
+**Scan for wordy phrases:**
+- "Due to the fact that" (use "because")
+- "In the event of" (use "if")
+- "At this point in time" (use "now")
+- "In a manner that" (use "how")
+- Count occurrences and note line numbers
+
+**Scan for redundant phrases:**
+- "Future plans" (just "plans")
+- "Past history" (just "history")
+- "Absolutely essential" (just "essential")
+- "Completely finish" (just "finish")
+- Count occurrences and note line numbers
+
+### 3. Classify Severity
+
+**Calculate total violations:**
+- Conversational filler count
+- Wordy phrases count
+- Redundant phrases count
+- Total = sum of all categories
+
+**Determine severity:**
+- **Critical:** Total > 10 violations
+- **Warning:** Total 5-10 violations
+- **Pass:** Total < 5 violations
+
+### 4. Report Density Findings to Validation Report
+
+Append to validation report:
+
+```markdown
+## Information Density Validation
+
+**Anti-Pattern Violations:**
+
+**Conversational Filler:** {count} occurrences
+[If count > 0, list examples with line numbers]
+
+**Wordy Phrases:** {count} occurrences
+[If count > 0, list examples with line numbers]
+
+**Redundant Phrases:** {count} occurrences
+[If count > 0, list examples with line numbers]
+
+**Total Violations:** {total}
+
+**Severity Assessment:** [Critical/Warning/Pass]
+
+**Recommendation:**
+[If Critical] "PRD requires significant revision to improve information density. Every sentence should carry weight without filler."
+[If Warning] "PRD would benefit from reducing wordiness and eliminating filler phrases."
+[If Pass] "PRD demonstrates good information density with minimal violations."
+```
+
+### 5. Display Progress and Auto-Proceed
+
+Display: "**Information Density Validation Complete**
+
+Severity: {Critical/Warning/Pass}
+
+**Proceeding to next validation check...**"
+
+Immediately load and execute {nextStepFile} (step-v-04-brief-coverage-validation.md)
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- PRD scanned for all three anti-pattern categories
+- Violations counted with line numbers
+- Severity classified correctly
+- Findings reported to validation report
+- Auto-proceeds to next validation step
+- Subprocess attempted with graceful degradation
+
+### ❌ SYSTEM FAILURE:
+
+- Not scanning all anti-pattern categories
+- Missing severity classification
+- Not reporting findings to validation report
+- Pausing for user input (should auto-proceed)
+- Not attempting subprocess architecture
+
+**Master Rule:** Information density validation runs autonomously. Scan, classify, report, auto-proceed. No user interaction needed.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-v/step-v-04-brief-coverage-validation.md

@@ -0,0 +1,214 @@
+---
+name: 'step-v-04-brief-coverage-validation'
+description: 'Product Brief Coverage Check - Validate PRD covers all content from Product Brief (if used as input)'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-05-measurability-validation.md'
+prdFile: '{prd_file_path}'
+productBrief: '{product_brief_path}'
+validationReportPath: '{validation_report_path}'
+---
+
+# Step 4: Product Brief Coverage Validation
+
+## STEP GOAL:
+
+Validate that PRD covers all content from Product Brief (if brief was used as input), mapping brief content to PRD sections and identifying gaps.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and Quality Assurance Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in systematic validation, not collaborative dialogue
+- ✅ You bring analytical rigor and traceability expertise
+- ✅ This step runs autonomously - no user input needed
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on Product Brief coverage (conditional on brief existence)
+- 🚫 FORBIDDEN to validate other aspects in this step
+- 💬 Approach: Systematic mapping and gap analysis
+- 🚪 This is a validation sequence step - auto-proceeds when complete
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Check if Product Brief exists in input documents
+- 💬 If no brief: Skip this check and report "N/A - No Product Brief"
+- 🎯 If brief exists: Map brief content to PRD sections
+- 💾 Append coverage findings to validation report
+- 📖 Display "Proceeding to next check..." and load next step
+- 🚫 FORBIDDEN to pause or request user input
+
+## CONTEXT BOUNDARIES:
+
+- Available context: PRD file, input documents from step 1, validation report
+- Focus: Product Brief coverage only (conditional)
+- Limits: Don't validate other aspects, conditional execution
+- Dependencies: Step 1 completed - input documents loaded
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Check for Product Brief
+
+Check if Product Brief was loaded in step 1's inputDocuments:
+
+**IF no Product Brief found:**
+Append to validation report:
+```markdown
+## Product Brief Coverage
+
+**Status:** N/A - No Product Brief was provided as input
+```
+
+Display: "**Product Brief Coverage: Skipped** (No Product Brief provided)
+
+**Proceeding to next validation check...**"
+
+Immediately load and execute {nextStepFile}
+
+**IF Product Brief exists:** Continue to step 2 below
+
+### 2. Attempt Sub-Process Validation
+
+**Try to use Task tool to spawn a subprocess:**
+
+"Perform Product Brief coverage validation:
+
+1. Load the Product Brief
+2. Extract key content:
+   - Vision statement
+   - Target users/personas
+   - Problem statement
+   - Key features
+   - Goals/objectives
+   - Differentiators
+   - Constraints
+3. For each item, search PRD for corresponding coverage
+4. Classify coverage: Fully Covered / Partially Covered / Not Found / Intentionally Excluded
+5. Note any gaps with severity: Critical / Moderate / Informational
+
+Return structured coverage map with classifications."
+
+### 3. Graceful Degradation (if Task tool unavailable)
+
+If Task tool unavailable, perform analysis directly:
+
+**Extract from Product Brief:**
+- Vision: What is this product?
+- Users: Who is it for?
+- Problem: What problem does it solve?
+- Features: What are the key capabilities?
+- Goals: What are the success criteria?
+- Differentiators: What makes it unique?
+
+**For each item, search PRD:**
+- Scan Executive Summary for vision
+- Check User Journeys or user personas
+- Look for problem statement
+- Review Functional Requirements for features
+- Check Success Criteria section
+- Search for differentiators
+
+**Classify coverage:**
+- **Fully Covered:** Content present and complete
+- **Partially Covered:** Content present but incomplete
+- **Not Found:** Content missing from PRD
+- **Intentionally Excluded:** Content explicitly out of scope
+
+### 4. Assess Coverage and Severity
+
+**For each gap (Partially Covered or Not Found):**
+- Is this Critical? (Core vision, primary users, main features)
+- Is this Moderate? (Secondary features, some goals)
+- Is this Informational? (Nice-to-have features, minor details)
+
+**Note:** Some exclusions may be intentional (valid scoping decisions)
+
+### 5. Report Coverage Findings to Validation Report
+
+Append to validation report:
+
+```markdown
+## Product Brief Coverage
+
+**Product Brief:** {brief_file_name}
+
+### Coverage Map
+
+**Vision Statement:** [Fully/Partially/Not Found/Intentionally Excluded]
+[If gap: Note severity and specific missing content]
+
+**Target Users:** [Fully/Partially/Not Found/Intentionally Excluded]
+[If gap: Note severity and specific missing content]
+
+**Problem Statement:** [Fully/Partially/Not Found/Intentionally Excluded]
+[If gap: Note severity and specific missing content]
+
+**Key Features:** [Fully/Partially/Not Found/Intentionally Excluded]
+[If gap: List specific features with severity]
+
+**Goals/Objectives:** [Fully/Partially/Not Found/Intentionally Excluded]
+[If gap: Note severity and specific missing content]
+
+**Differentiators:** [Fully/Partially/Not Found/Intentionally Excluded]
+[If gap: Note severity and specific missing content]
+
+### Coverage Summary
+
+**Overall Coverage:** [percentage or qualitative assessment]
+**Critical Gaps:** [count] [list if any]
+**Moderate Gaps:** [count] [list if any]
+**Informational Gaps:** [count] [list if any]
+
+**Recommendation:**
+[If critical gaps exist] "PRD should be revised to cover critical Product Brief content."
+[If moderate gaps] "Consider addressing moderate gaps for complete coverage."
+[If minimal gaps] "PRD provides good coverage of Product Brief content."
+```
+
+### 6. Display Progress and Auto-Proceed
+
+Display: "**Product Brief Coverage Validation Complete**
+
+Overall Coverage: {assessment}
+
+**Proceeding to next validation check...**"
+
+Immediately load and execute {nextStepFile} (step-v-05-measurability-validation.md)
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Checked for Product Brief existence correctly
+- If no brief: Reported "N/A" and skipped gracefully
+- If brief exists: Mapped all key brief content to PRD sections
+- Coverage classified appropriately (Fully/Partially/Not Found/Intentionally Excluded)
+- Severity assessed for gaps (Critical/Moderate/Informational)
+- Findings reported to validation report
+- Auto-proceeds to next validation step
+- Subprocess attempted with graceful degradation
+
+### ❌ SYSTEM FAILURE:
+
+- Not checking for brief existence before attempting validation
+- If brief exists: not mapping all key content areas
+- Missing coverage classifications
+- Not reporting findings to validation report
+- Not auto-proceeding
+
+**Master Rule:** Product Brief coverage is conditional - skip if no brief, validate thoroughly if brief exists. Always auto-proceed.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-v/step-v-05-measurability-validation.md

@@ -0,0 +1,228 @@
+---
+name: 'step-v-05-measurability-validation'
+description: 'Measurability Validation - Validate that all requirements (FRs and NFRs) are measurable and testable'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-06-traceability-validation.md'
+prdFile: '{prd_file_path}'
+validationReportPath: '{validation_report_path}'
+---
+
+# Step 5: Measurability Validation
+
+## STEP GOAL:
+
+Validate that all Functional Requirements (FRs) and Non-Functional Requirements (NFRs) are measurable, testable, and follow proper format without implementation details.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and Quality Assurance Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in systematic validation, not collaborative dialogue
+- ✅ You bring analytical rigor and requirements engineering expertise
+- ✅ This step runs autonomously - no user input needed
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on FR and NFR measurability
+- 🚫 FORBIDDEN to validate other aspects in this step
+- 💬 Approach: Systematic requirement-by-requirement analysis
+- 🚪 This is a validation sequence step - auto-proceeds when complete
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Extract all FRs and NFRs from PRD
+- 💾 Validate each for measurability and format
+- 📖 Append findings to validation report
+- 📖 Display "Proceeding to next check..." and load next step
+- 🚫 FORBIDDEN to pause or request user input
+
+## CONTEXT BOUNDARIES:
+
+- Available context: PRD file, validation report
+- Focus: FR and NFR measurability only
+- Limits: Don't validate other aspects, don't pause for user input
+- Dependencies: Steps 2-4 completed - initial validation checks done
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Attempt Sub-Process Validation
+
+**Try to use Task tool to spawn a subprocess:**
+
+"Perform measurability validation on this PRD:
+
+**Functional Requirements (FRs):**
+1. Extract all FRs from Functional Requirements section
+2. Check each FR for:
+   - '[Actor] can [capability]' format compliance
+   - No subjective adjectives (easy, fast, simple, intuitive, etc.)
+   - No vague quantifiers (multiple, several, some, many, etc.)
+   - No implementation details (technology names, library names, data structures unless capability-relevant)
+3. Document violations with line numbers
+
+**Non-Functional Requirements (NFRs):**
+1. Extract all NFRs from Non-Functional Requirements section
+2. Check each NFR for:
+   - Specific metrics with measurement methods
+   - Template compliance (criterion, metric, measurement method, context)
+   - Context included (why this matters, who it affects)
+3. Document violations with line numbers
+
+Return structured findings with violation counts and examples."
+
+### 2. Graceful Degradation (if Task tool unavailable)
+
+If Task tool unavailable, perform analysis directly:
+
+**Functional Requirements Analysis:**
+
+Extract all FRs and check each for:
+
+**Format compliance:**
+- Does it follow "[Actor] can [capability]" pattern?
+- Is actor clearly defined?
+- Is capability actionable and testable?
+
+**No subjective adjectives:**
+- Scan for: easy, fast, simple, intuitive, user-friendly, responsive, quick, efficient (without metrics)
+- Note line numbers
+
+**No vague quantifiers:**
+- Scan for: multiple, several, some, many, few, various, number of
+- Note line numbers
+
+**No implementation details:**
+- Scan for: React, Vue, Angular, PostgreSQL, MongoDB, AWS, Docker, Kubernetes, Redux, etc.
+- Unless capability-relevant (e.g., "API consumers can access...")
+- Note line numbers
+
+**Non-Functional Requirements Analysis:**
+
+Extract all NFRs and check each for:
+
+**Specific metrics:**
+- Is there a measurable criterion? (e.g., "response time < 200ms", not "fast response")
+- Can this be measured or tested?
+
+**Template compliance:**
+- Criterion defined?
+- Metric specified?
+- Measurement method included?
+- Context provided?
+
+### 3. Tally Violations
+
+**FR Violations:**
+- Format violations: count
+- Subjective adjectives: count
+- Vague quantifiers: count
+- Implementation leakage: count
+- Total FR violations: sum
+
+**NFR Violations:**
+- Missing metrics: count
+- Incomplete template: count
+- Missing context: count
+- Total NFR violations: sum
+
+**Total violations:** FR violations + NFR violations
+
+### 4. Report Measurability Findings to Validation Report
+
+Append to validation report:
+
+```markdown
+## Measurability Validation
+
+### Functional Requirements
+
+**Total FRs Analyzed:** {count}
+
+**Format Violations:** {count}
+[If violations exist, list examples with line numbers]
+
+**Subjective Adjectives Found:** {count}
+[If found, list examples with line numbers]
+
+**Vague Quantifiers Found:** {count}
+[If found, list examples with line numbers]
+
+**Implementation Leakage:** {count}
+[If found, list examples with line numbers]
+
+**FR Violations Total:** {total}
+
+### Non-Functional Requirements
+
+**Total NFRs Analyzed:** {count}
+
+**Missing Metrics:** {count}
+[If missing, list examples with line numbers]
+
+**Incomplete Template:** {count}
+[If incomplete, list examples with line numbers]
+
+**Missing Context:** {count}
+[If missing, list examples with line numbers]
+
+**NFR Violations Total:** {total}
+
+### Overall Assessment
+
+**Total Requirements:** {FRs + NFRs}
+**Total Violations:** {FR violations + NFR violations}
+
+**Severity:** [Critical if >10 violations, Warning if 5-10, Pass if <5]
+
+**Recommendation:**
+[If Critical] "Many requirements are not measurable or testable. Requirements must be revised to be testable for downstream work."
+[If Warning] "Some requirements need refinement for measurability. Focus on violating requirements above."
+[If Pass] "Requirements demonstrate good measurability with minimal issues."
+```
+
+### 5. Display Progress and Auto-Proceed
+
+Display: "**Measurability Validation Complete**
+
+Total Violations: {count} ({severity})
+
+**Proceeding to next validation check...**"
+
+Immediately load and execute {nextStepFile} (step-v-06-traceability-validation.md)
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- All FRs extracted and analyzed for measurability
+- All NFRs extracted and analyzed for measurability
+- Violations documented with line numbers
+- Severity assessed correctly
+- Findings reported to validation report
+- Auto-proceeds to next validation step
+- Subprocess attempted with graceful degradation
+
+### ❌ SYSTEM FAILURE:
+
+- Not analyzing all FRs and NFRs
+- Missing line numbers for violations
+- Not reporting findings to validation report
+- Not assessing severity
+- Not auto-proceeding
+
+**Master Rule:** Requirements must be testable to be useful. Validate every requirement for measurability, document violations, auto-proceed.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-v/step-v-06-traceability-validation.md

@@ -0,0 +1,217 @@
+---
+name: 'step-v-06-traceability-validation'
+description: 'Traceability Validation - Validate the traceability chain from vision → success → journeys → FRs is intact'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-07-implementation-leakage-validation.md'
+prdFile: '{prd_file_path}'
+validationReportPath: '{validation_report_path}'
+---
+
+# Step 6: Traceability Validation
+
+## STEP GOAL:
+
+Validate the traceability chain from Executive Summary → Success Criteria → User Journeys → Functional Requirements is intact, ensuring every requirement traces back to a user need or business objective.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and Quality Assurance Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in systematic validation, not collaborative dialogue
+- ✅ You bring analytical rigor and traceability matrix expertise
+- ✅ This step runs autonomously - no user input needed
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on traceability chain validation
+- 🚫 FORBIDDEN to validate other aspects in this step
+- 💬 Approach: Systematic chain validation and orphan detection
+- 🚪 This is a validation sequence step - auto-proceeds when complete
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Build and validate traceability matrix
+- 💾 Identify broken chains and orphan requirements
+- 📖 Append findings to validation report
+- 📖 Display "Proceeding to next check..." and load next step
+- 🚫 FORBIDDEN to pause or request user input
+
+## CONTEXT BOUNDARIES:
+
+- Available context: PRD file, validation report
+- Focus: Traceability chain validation only
+- Limits: Don't validate other aspects, don't pause for user input
+- Dependencies: Steps 2-5 completed - initial validations done
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Attempt Sub-Process Validation
+
+**Try to use Task tool to spawn a subprocess:**
+
+"Perform traceability validation on this PRD:
+
+1. Extract content from Executive Summary (vision, goals)
+2. Extract Success Criteria
+3. Extract User Journeys (user types, flows, outcomes)
+4. Extract Functional Requirements (FRs)
+5. Extract Product Scope (in-scope items)
+
+**Validate chains:**
+- Executive Summary → Success Criteria: Does vision align with defined success?
+- Success Criteria → User Journeys: Are success criteria supported by user journeys?
+- User Journeys → Functional Requirements: Does each FR trace back to a user journey?
+- Scope → FRs: Do MVP scope FRs align with in-scope items?
+
+**Identify orphans:**
+- FRs not traceable to any user journey or business objective
+- Success criteria not supported by user journeys
+- User journeys without supporting FRs
+
+Build traceability matrix and identify broken chains and orphan FRs.
+
+Return structured findings with chain status and orphan list."
+
+### 2. Graceful Degradation (if Task tool unavailable)
+
+If Task tool unavailable, perform analysis directly:
+
+**Step 1: Extract key elements**
+- Executive Summary: Note vision, goals, objectives
+- Success Criteria: List all criteria
+- User Journeys: List user types and their flows
+- Functional Requirements: List all FRs
+- Product Scope: List in-scope items
+
+**Step 2: Validate Executive Summary → Success Criteria**
+- Does Executive Summary mention the success dimensions?
+- Are Success Criteria aligned with vision?
+- Note any misalignment
+
+**Step 3: Validate Success Criteria → User Journeys**
+- For each success criterion, is there a user journey that achieves it?
+- Note success criteria without supporting journeys
+
+**Step 4: Validate User Journeys → FRs**
+- For each user journey/flow, are there FRs that enable it?
+- List FRs with no clear user journey origin
+- Note orphan FRs (requirements without traceable source)
+
+**Step 5: Validate Scope → FR Alignment**
+- Does MVP scope align with essential FRs?
+- Are in-scope items supported by FRs?
+- Note misalignments
+
+**Step 6: Build traceability matrix**
+- Map each FR to its source (journey or business objective)
+- Note orphan FRs
+- Identify broken chains
+
+### 3. Tally Traceability Issues
+
+**Broken chains:**
+- Executive Summary → Success Criteria gaps: count
+- Success Criteria → User Journeys gaps: count
+- User Journeys → FRs gaps: count
+- Scope → FR misalignments: count
+
+**Orphan elements:**
+- Orphan FRs (no traceable source): count
+- Unsupported success criteria: count
+- User journeys without FRs: count
+
+**Total issues:** Sum of all broken chains and orphans
+
+### 4. Report Traceability Findings to Validation Report
+
+Append to validation report:
+
+```markdown
+## Traceability Validation
+
+### Chain Validation
+
+**Executive Summary → Success Criteria:** [Intact/Gaps Identified]
+{If gaps: List specific misalignments}
+
+**Success Criteria → User Journeys:** [Intact/Gaps Identified]
+{If gaps: List unsupported success criteria}
+
+**User Journeys → Functional Requirements:** [Intact/Gaps Identified]
+{If gaps: List journeys without supporting FRs}
+
+**Scope → FR Alignment:** [Intact/Misaligned]
+{If misaligned: List specific issues}
+
+### Orphan Elements
+
+**Orphan Functional Requirements:** {count}
+{List orphan FRs with numbers}
+
+**Unsupported Success Criteria:** {count}
+{List unsupported criteria}
+
+**User Journeys Without FRs:** {count}
+{List journeys without FRs}
+
+### Traceability Matrix
+
+{Summary table showing traceability coverage}
+
+**Total Traceability Issues:** {total}
+
+**Severity:** [Critical if orphan FRs exist, Warning if gaps, Pass if intact]
+
+**Recommendation:**
+[If Critical] "Orphan requirements exist - every FR must trace back to a user need or business objective."
+[If Warning] "Traceability gaps identified - strengthen chains to ensure all requirements are justified."
+[If Pass] "Traceability chain is intact - all requirements trace to user needs or business objectives."
+```
+
+### 5. Display Progress and Auto-Proceed
+
+Display: "**Traceability Validation Complete**
+
+Total Issues: {count} ({severity})
+
+**Proceeding to next validation check...**"
+
+Immediately load and execute {nextStepFile} (step-v-07-implementation-leakage-validation.md)
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- All traceability chains validated systematically
+- Orphan FRs identified with numbers
+- Broken chains documented
+- Traceability matrix built
+- Severity assessed correctly
+- Findings reported to validation report
+- Auto-proceeds to next validation step
+- Subprocess attempted with graceful degradation
+
+### ❌ SYSTEM FAILURE:
+
+- Not validating all traceability chains
+- Missing orphan FR detection
+- Not building traceability matrix
+- Not reporting findings to validation report
+- Not auto-proceeding
+
+**Master Rule:** Every requirement should trace to a user need or business objective. Orphan FRs indicate broken traceability that must be fixed.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-v/step-v-07-implementation-leakage-validation.md

@@ -0,0 +1,205 @@
+---
+name: 'step-v-07-implementation-leakage-validation'
+description: 'Implementation Leakage Check - Ensure FRs and NFRs don\'t include implementation details'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-08-domain-compliance-validation.md'
+prdFile: '{prd_file_path}'
+validationReportPath: '{validation_report_path}'
+---
+
+# Step 7: Implementation Leakage Validation
+
+## STEP GOAL:
+
+Ensure Functional Requirements and Non-Functional Requirements don't include implementation details - they should specify WHAT, not HOW.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and Quality Assurance Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in systematic validation, not collaborative dialogue
+- ✅ You bring analytical rigor and separation of concerns expertise
+- ✅ This step runs autonomously - no user input needed
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on implementation leakage detection
+- 🚫 FORBIDDEN to validate other aspects in this step
+- 💬 Approach: Systematic scanning for technology and implementation terms
+- 🚪 This is a validation sequence step - auto-proceeds when complete
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Scan FRs and NFRs for implementation terms
+- 💾 Distinguish capability-relevant vs leakage
+- 📖 Append findings to validation report
+- 📖 Display "Proceeding to next check..." and load next step
+- 🚫 FORBIDDEN to pause or request user input
+
+## CONTEXT BOUNDARIES:
+
+- Available context: PRD file, validation report
+- Focus: Implementation leakage detection only
+- Limits: Don't validate other aspects, don't pause for user input
+- Dependencies: Steps 2-6 completed - initial validations done
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Attempt Sub-Process Validation
+
+**Try to use Task tool to spawn a subprocess:**
+
+"Perform implementation leakage validation on this PRD:
+
+**Scan for:**
+1. Technology names (React, Vue, Angular, PostgreSQL, MongoDB, AWS, GCP, Azure, Docker, Kubernetes, etc.)
+2. Library names (Redux, axios, lodash, Express, Django, Rails, Spring, etc.)
+3. Data structures (JSON, XML, CSV) unless relevant to capability
+4. Architecture patterns (MVC, microservices, serverless) unless business requirement
+5. Protocol names (HTTP, REST, GraphQL, WebSockets) - check if capability-relevant
+
+**For each term found:**
+- Is this capability-relevant? (e.g., 'API consumers can access...' - API is capability)
+- Or is this implementation detail? (e.g., 'React component for...' - implementation)
+
+Document violations with line numbers and explanation.
+
+Return structured findings with leakage counts and examples."
+
+### 2. Graceful Degradation (if Task tool unavailable)
+
+If Task tool unavailable, perform analysis directly:
+
+**Implementation leakage terms to scan for:**
+
+**Frontend Frameworks:**
+React, Vue, Angular, Svelte, Solid, Next.js, Nuxt, etc.
+
+**Backend Frameworks:**
+Express, Django, Rails, Spring, Laravel, FastAPI, etc.
+
+**Databases:**
+PostgreSQL, MySQL, MongoDB, Redis, DynamoDB, Cassandra, etc.
+
+**Cloud Platforms:**
+AWS, GCP, Azure, Cloudflare, Vercel, Netlify, etc.
+
+**Infrastructure:**
+Docker, Kubernetes, Terraform, Ansible, etc.
+
+**Libraries:**
+Redux, Zustand, axios, fetch, lodash, jQuery, etc.
+
+**Data Formats:**
+JSON, XML, YAML, CSV (unless capability-relevant)
+
+**For each term found in FRs/NFRs:**
+- Determine if it's capability-relevant or implementation leakage
+- Example: "API consumers can access data via REST endpoints" - API/REST is capability
+- Example: "React components fetch data using Redux" - implementation leakage
+
+**Count violations and note line numbers**
+
+### 3. Tally Implementation Leakage
+
+**By category:**
+- Frontend framework leakage: count
+- Backend framework leakage: count
+- Database leakage: count
+- Cloud platform leakage: count
+- Infrastructure leakage: count
+- Library leakage: count
+- Other implementation details: count
+
+**Total implementation leakage violations:** sum
+
+### 4. Report Implementation Leakage Findings to Validation Report
+
+Append to validation report:
+
+```markdown
+## Implementation Leakage Validation
+
+### Leakage by Category
+
+**Frontend Frameworks:** {count} violations
+{If violations, list examples with line numbers}
+
+**Backend Frameworks:** {count} violations
+{If violations, list examples with line numbers}
+
+**Databases:** {count} violations
+{If violations, list examples with line numbers}
+
+**Cloud Platforms:** {count} violations
+{If violations, list examples with line numbers}
+
+**Infrastructure:** {count} violations
+{If violations, list examples with line numbers}
+
+**Libraries:** {count} violations
+{If violations, list examples with line numbers}
+
+**Other Implementation Details:** {count} violations
+{If violations, list examples with line numbers}
+
+### Summary
+
+**Total Implementation Leakage Violations:** {total}
+
+**Severity:** [Critical if >5 violations, Warning if 2-5, Pass if <2]
+
+**Recommendation:**
+[If Critical] "Extensive implementation leakage found. Requirements specify HOW instead of WHAT. Remove all implementation details - these belong in architecture, not PRD."
+[If Warning] "Some implementation leakage detected. Review violations and remove implementation details from requirements."
+[If Pass] "No significant implementation leakage found. Requirements properly specify WHAT without HOW."
+
+**Note:** API consumers, GraphQL (when required), and other capability-relevant terms are acceptable when they describe WHAT the system must do, not HOW to build it.
+```
+
+### 5. Display Progress and Auto-Proceed
+
+Display: "**Implementation Leakage Validation Complete**
+
+Total Violations: {count} ({severity})
+
+**Proceeding to next validation check...**"
+
+Immediately load and execute {nextStepFile} (step-v-08-domain-compliance-validation.md)
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Scanned FRs and NFRs for all implementation term categories
+- Distinguished capability-relevant from implementation leakage
+- Violations documented with line numbers and explanations
+- Severity assessed correctly
+- Findings reported to validation report
+- Auto-proceeds to next validation step
+- Subprocess attempted with graceful degradation
+
+### ❌ SYSTEM FAILURE:
+
+- Not scanning all implementation term categories
+- Not distinguishing capability-relevant from leakage
+- Missing line numbers for violations
+- Not reporting findings to validation report
+- Not auto-proceeding
+
+**Master Rule:** Requirements specify WHAT, not HOW. Implementation details belong in architecture documents, not PRDs.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-v/step-v-08-domain-compliance-validation.md

@@ -0,0 +1,243 @@
+---
+name: 'step-v-08-domain-compliance-validation'
+description: 'Domain Compliance Validation - Validate domain-specific requirements are present for high-complexity domains'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-09-project-type-validation.md'
+prdFile: '{prd_file_path}'
+prdFrontmatter: '{prd_frontmatter}'
+validationReportPath: '{validation_report_path}'
+domainComplexityData: '../data/domain-complexity.csv'
+---
+
+# Step 8: Domain Compliance Validation
+
+## STEP GOAL:
+
+Validate domain-specific requirements are present for high-complexity domains (Healthcare, Fintech, GovTech, etc.), ensuring regulatory and compliance requirements are properly documented.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and Quality Assurance Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in systematic validation, not collaborative dialogue
+- ✅ You bring domain expertise and compliance knowledge
+- ✅ This step runs autonomously - no user input needed
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on domain-specific compliance requirements
+- 🚫 FORBIDDEN to validate other aspects in this step
+- 💬 Approach: Conditional validation based on domain classification
+- 🚪 This is a validation sequence step - auto-proceeds when complete
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Check classification.domain from PRD frontmatter
+- 💬 If low complexity (general): Skip detailed checks
+- 🎯 If high complexity: Validate required special sections
+- 💾 Append compliance findings to validation report
+- 📖 Display "Proceeding to next check..." and load next step
+- 🚫 FORBIDDEN to pause or request user input
+
+## CONTEXT BOUNDARIES:
+
+- Available context: PRD file with frontmatter classification, validation report
+- Focus: Domain compliance only (conditional on domain complexity)
+- Limits: Don't validate other aspects, conditional execution
+- Dependencies: Steps 2-7 completed - format and requirements validation done
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Load Domain Complexity Data
+
+Load and read the complete file at:
+`{domainComplexityData}` (../data/domain-complexity.csv)
+
+This CSV contains:
+- Domain classifications and complexity levels (high/medium/low)
+- Required special sections for each domain
+- Key concerns and requirements for regulated industries
+
+Internalize this data - it drives which domains require special compliance sections.
+
+### 2. Extract Domain Classification
+
+From PRD frontmatter, extract:
+- `classification.domain` - what domain is this PRD for?
+
+**If no domain classification found:**
+Treat as "general" (low complexity) and proceed to step 4
+
+### 2. Determine Domain Complexity
+
+**Low complexity domains (skip detailed checks):**
+- General
+- Consumer apps (standard e-commerce, social, productivity)
+- Content websites
+- Business tools (standard)
+
+**High complexity domains (require special sections):**
+- Healthcare / Healthtech
+- Fintech / Financial services
+- GovTech / Public sector
+- EdTech (educational records, accredited courses)
+- Legal tech
+- Other regulated domains
+
+### 3. For High-Complexity Domains: Validate Required Special Sections
+
+**Attempt subprocess validation:**
+
+"Perform domain compliance validation for {domain}:
+
+Based on {domain} requirements, check PRD for:
+
+**Healthcare:**
+- Clinical Requirements section
+- Regulatory Pathway (FDA, HIPAA, etc.)
+- Safety Measures
+- HIPAA Compliance (data privacy, security)
+- Patient safety considerations
+
+**Fintech:**
+- Compliance Matrix (SOC2, PCI-DSS, GDPR, etc.)
+- Security Architecture
+- Audit Requirements
+- Fraud Prevention measures
+- Financial transaction handling
+
+**GovTech:**
+- Accessibility Standards (WCAG 2.1 AA, Section 508)
+- Procurement Compliance
+- Security Clearance requirements
+- Data residency requirements
+
+**Other regulated domains:**
+- Check for domain-specific regulatory sections
+- Compliance requirements
+- Special considerations
+
+For each required section:
+- Is it present in PRD?
+- Is it adequately documented?
+- Note any gaps
+
+Return compliance matrix with presence/adequacy assessment."
+
+**Graceful degradation (if no Task tool):**
+- Manually check for required sections based on domain
+- List present sections and missing sections
+- Assess adequacy of documentation
+
+### 5. For Low-Complexity Domains: Skip Detailed Checks
+
+Append to validation report:
+```markdown
+## Domain Compliance Validation
+
+**Domain:** {domain}
+**Complexity:** Low (general/standard)
+**Assessment:** N/A - No special domain compliance requirements
+
+**Note:** This PRD is for a standard domain without regulatory compliance requirements.
+```
+
+Display: "**Domain Compliance Validation Skipped**
+
+Domain: {domain} (low complexity)
+
+**Proceeding to next validation check...**"
+
+Immediately load and execute {nextStepFile}
+
+### 6. Report Compliance Findings (High-Complexity Domains)
+
+Append to validation report:
+
+```markdown
+## Domain Compliance Validation
+
+**Domain:** {domain}
+**Complexity:** High (regulated)
+
+### Required Special Sections
+
+**{Section 1 Name}:** [Present/Missing/Adequate]
+{If missing or inadequate: Note specific gaps}
+
+**{Section 2 Name}:** [Present/Missing/Adequate]
+{If missing or inadequate: Note specific gaps}
+
+[Continue for all required sections]
+
+### Compliance Matrix
+
+| Requirement | Status | Notes |
+|-------------|--------|-------|
+| {Requirement 1} | [Met/Partial/Missing] | {Notes} |
+| {Requirement 2} | [Met/Partial/Missing] | {Notes} |
+[... continue for all requirements]
+
+### Summary
+
+**Required Sections Present:** {count}/{total}
+**Compliance Gaps:** {count}
+
+**Severity:** [Critical if missing regulatory sections, Warning if incomplete, Pass if complete]
+
+**Recommendation:**
+[If Critical] "PRD is missing required domain-specific compliance sections. These are essential for {domain} products."
+[If Warning] "Some domain compliance sections are incomplete. Strengthen documentation for full compliance."
+[If Pass] "All required domain compliance sections are present and adequately documented."
+```
+
+### 7. Display Progress and Auto-Proceed
+
+Display: "**Domain Compliance Validation Complete**
+
+Domain: {domain} ({complexity})
+Compliance Status: {status}
+
+**Proceeding to next validation check...**"
+
+Immediately load and execute {nextStepFile} (step-v-09-project-type-validation.md)
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Domain classification extracted correctly
+- Complexity assessed appropriately
+- Low complexity domains: Skipped with clear "N/A" documentation
+- High complexity domains: All required sections checked
+- Compliance matrix built with status for each requirement
+- Severity assessed correctly
+- Findings reported to validation report
+- Auto-proceeds to next validation step
+- Subprocess attempted with graceful degradation
+
+### ❌ SYSTEM FAILURE:
+
+- Not checking domain classification before proceeding
+- Performing detailed checks on low complexity domains
+- For high complexity: missing required section checks
+- Not building compliance matrix
+- Not reporting findings to validation report
+- Not auto-proceeding
+
+**Master Rule:** Domain compliance is conditional. High-complexity domains require special sections - low complexity domains skip these checks.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-v/step-v-09-project-type-validation.md

@@ -0,0 +1,263 @@
+---
+name: 'step-v-09-project-type-validation'
+description: 'Project-Type Compliance Validation - Validate project-type specific requirements are properly documented'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-10-smart-validation.md'
+prdFile: '{prd_file_path}'
+prdFrontmatter: '{prd_frontmatter}'
+validationReportPath: '{validation_report_path}'
+projectTypesData: '../data/project-types.csv'
+---
+
+# Step 9: Project-Type Compliance Validation
+
+## STEP GOAL:
+
+Validate project-type specific requirements are properly documented - different project types (api_backend, web_app, mobile_app, etc.) have different required and excluded sections.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and Quality Assurance Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in systematic validation, not collaborative dialogue
+- ✅ You bring project type expertise and architectural knowledge
+- ✅ This step runs autonomously - no user input needed
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on project-type compliance
+- 🚫 FORBIDDEN to validate other aspects in this step
+- 💬 Approach: Validate required sections present, excluded sections absent
+- 🚪 This is a validation sequence step - auto-proceeds when complete
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Check classification.projectType from PRD frontmatter
+- 🎯 Validate required sections for that project type are present
+- 🎯 Validate excluded sections for that project type are absent
+- 💾 Append compliance findings to validation report
+- 📖 Display "Proceeding to next check..." and load next step
+- 🚫 FORBIDDEN to pause or request user input
+
+## CONTEXT BOUNDARIES:
+
+- Available context: PRD file with frontmatter classification, validation report
+- Focus: Project-type compliance only
+- Limits: Don't validate other aspects, don't pause for user input
+- Dependencies: Steps 2-8 completed - domain and requirements validation done
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Load Project Types Data
+
+Load and read the complete file at:
+`{projectTypesData}` (../data/project-types.csv)
+
+This CSV contains:
+- Detection signals for each project type
+- Required sections for each project type
+- Skip/excluded sections for each project type
+- Innovation signals
+
+Internalize this data - it drives what sections must be present or absent for each project type.
+
+### 2. Extract Project Type Classification
+
+From PRD frontmatter, extract:
+- `classification.projectType` - what type of project is this?
+
+**Common project types:**
+- api_backend
+- web_app
+- mobile_app
+- desktop_app
+- data_pipeline
+- ml_system
+- library_sdk
+- infrastructure
+- other
+
+**If no projectType classification found:**
+Assume "web_app" (most common) and note in findings
+
+### 3. Determine Required and Excluded Sections from CSV Data
+
+**From loaded project-types.csv data, for this project type:**
+
+**Required sections:** (from required_sections column)
+These MUST be present in the PRD
+
+**Skip sections:** (from skip_sections column)
+These MUST NOT be present in the PRD
+
+**Example mappings from CSV:**
+- api_backend: Required=[endpoint_specs, auth_model, data_schemas], Skip=[ux_ui, visual_design]
+- mobile_app: Required=[platform_reqs, device_permissions, offline_mode], Skip=[desktop_features, cli_commands]
+- cli_tool: Required=[command_structure, output_formats, config_schema], Skip=[visual_design, ux_principles, touch_interactions]
+- etc.
+
+### 4. Validate Against CSV-Based Requirements
+
+**Based on project type, determine:**
+
+**api_backend:**
+- Required: Endpoint Specs, Auth Model, Data Schemas, API Versioning
+- Excluded: UX/UI sections, mobile-specific sections
+
+**web_app:**
+- Required: User Journeys, UX/UI Requirements, Responsive Design
+- Excluded: None typically
+
+**mobile_app:**
+- Required: Mobile UX, Platform specifics (iOS/Android), Offline mode
+- Excluded: Desktop-specific sections
+
+**desktop_app:**
+- Required: Desktop UX, Platform specifics (Windows/Mac/Linux)
+- Excluded: Mobile-specific sections
+
+**data_pipeline:**
+- Required: Data Sources, Data Transformation, Data Sinks, Error Handling
+- Excluded: UX/UI sections
+
+**ml_system:**
+- Required: Model Requirements, Training Data, Inference Requirements, Model Performance
+- Excluded: UX/UI sections (unless ML UI)
+
+**library_sdk:**
+- Required: API Surface, Usage Examples, Integration Guide
+- Excluded: UX/UI sections, deployment sections
+
+**infrastructure:**
+- Required: Infrastructure Components, Deployment, Monitoring, Scaling
+- Excluded: Feature requirements (this is infrastructure, not product)
+
+### 4. Attempt Sub-Process Validation
+
+"Perform project-type compliance validation for {projectType}:
+
+**Check that required sections are present:**
+{List required sections for this project type}
+For each: Is it present in PRD? Is it adequately documented?
+
+**Check that excluded sections are absent:**
+{List excluded sections for this project type}
+For each: Is it absent from PRD? (Should not be present)
+
+Build compliance table showing:
+- Required sections: [Present/Missing/Incomplete]
+- Excluded sections: [Absent/Present] (Present = violation)
+
+Return compliance table with findings."
+
+**Graceful degradation (if no Task tool):**
+- Manually check PRD for required sections
+- Manually check PRD for excluded sections
+- Build compliance table
+
+### 5. Build Compliance Table
+
+**Required sections check:**
+- For each required section: Present / Missing / Incomplete
+- Count: Required sections present vs total required
+
+**Excluded sections check:**
+- For each excluded section: Absent / Present (violation)
+- Count: Excluded sections present (violations)
+
+**Total compliance score:**
+- Required: {present}/{total}
+- Excluded violations: {count}
+
+### 6. Report Project-Type Compliance Findings to Validation Report
+
+Append to validation report:
+
+```markdown
+## Project-Type Compliance Validation
+
+**Project Type:** {projectType}
+
+### Required Sections
+
+**{Section 1}:** [Present/Missing/Incomplete]
+{If missing or incomplete: Note specific gaps}
+
+**{Section 2}:** [Present/Missing/Incomplete]
+{If missing or incomplete: Note specific gaps}
+
+[Continue for all required sections]
+
+### Excluded Sections (Should Not Be Present)
+
+**{Section 1}:** [Absent/Present] ✓
+{If present: This section should not be present for {projectType}}
+
+**{Section 2}:** [Absent/Present] ✓
+{If present: This section should not be present for {projectType}}
+
+[Continue for all excluded sections]
+
+### Compliance Summary
+
+**Required Sections:** {present}/{total} present
+**Excluded Sections Present:** {violations} (should be 0)
+**Compliance Score:** {percentage}%
+
+**Severity:** [Critical if required sections missing, Warning if incomplete, Pass if complete]
+
+**Recommendation:**
+[If Critical] "PRD is missing required sections for {projectType}. Add missing sections to properly specify this type of project."
+[If Warning] "Some required sections for {projectType} are incomplete. Strengthen documentation."
+[If Pass] "All required sections for {projectType} are present. No excluded sections found."
+```
+
+### 7. Display Progress and Auto-Proceed
+
+Display: "**Project-Type Compliance Validation Complete**
+
+Project Type: {projectType}
+Compliance: {score}%
+
+**Proceeding to next validation check...**"
+
+Immediately load and execute {nextStepFile} (step-v-10-smart-validation.md)
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Project type extracted correctly (or default assumed)
+- Required sections validated for presence and completeness
+- Excluded sections validated for absence
+- Compliance table built with status for all sections
+- Severity assessed correctly
+- Findings reported to validation report
+- Auto-proceeds to next validation step
+- Subprocess attempted with graceful degradation
+
+### ❌ SYSTEM FAILURE:
+
+- Not checking project type before proceeding
+- Missing required section checks
+- Missing excluded section checks
+- Not building compliance table
+- Not reporting findings to validation report
+- Not auto-proceeding
+
+**Master Rule:** Different project types have different requirements. API PRDs don't need UX sections - validate accordingly.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-v/step-v-10-smart-validation.md

@@ -0,0 +1,209 @@
+---
+name: 'step-v-10-smart-validation'
+description: 'SMART Requirements Validation - Validate Functional Requirements meet SMART quality criteria'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-11-holistic-quality-validation.md'
+prdFile: '{prd_file_path}'
+validationReportPath: '{validation_report_path}'
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+---
+
+# Step 10: SMART Requirements Validation
+
+## STEP GOAL:
+
+Validate Functional Requirements meet SMART quality criteria (Specific, Measurable, Attainable, Relevant, Traceable), ensuring high-quality requirements.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and Quality Assurance Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in systematic validation, not collaborative dialogue
+- ✅ You bring requirements engineering expertise and quality assessment
+- ✅ This step runs autonomously - no user input needed
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on FR quality assessment using SMART framework
+- 🚫 FORBIDDEN to validate other aspects in this step
+- 💬 Approach: Score each FR on SMART criteria (1-5 scale)
+- 🚪 This is a validation sequence step - auto-proceeds when complete
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Extract all FRs from PRD
+- 🎯 Score each FR on SMART criteria (Specific, Measurable, Attainable, Relevant, Traceable)
+- 💾 Flag FRs with score < 3 in any category
+- 📖 Append scoring table and suggestions to validation report
+- 📖 Display "Proceeding to next check..." and load next step
+- 🚫 FORBIDDEN to pause or request user input
+
+## CONTEXT BOUNDARIES:
+
+- Available context: PRD file, validation report
+- Focus: FR quality assessment only using SMART framework
+- Limits: Don't validate NFRs or other aspects, don't pause for user input
+- Dependencies: Steps 2-9 completed - comprehensive validation checks done
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Extract All Functional Requirements
+
+From the PRD's Functional Requirements section, extract:
+- All FRs with their FR numbers (FR-001, FR-002, etc.)
+- Count total FRs
+
+### 2. Attempt Sub-Process Validation
+
+**Try to use Task tool to spawn a subprocess:**
+
+"Perform SMART requirements validation on these Functional Requirements:
+
+{List all FRs}
+
+**For each FR, score on SMART criteria (1-5 scale):**
+
+**Specific (1-5):**
+- 5: Clear, unambiguous, well-defined
+- 3: Somewhat clear but could be more specific
+- 1: Vague, ambiguous, unclear
+
+**Measurable (1-5):**
+- 5: Quantifiable metrics, testable
+- 3: Partially measurable
+- 1: Not measurable, subjective
+
+**Attainable (1-5):**
+- 5: Realistic, achievable with constraints
+- 3: Probably achievable but uncertain
+- 1: Unrealistic, technically infeasible
+
+**Relevant (1-5):**
+- 5: Clearly aligned with user needs and business objectives
+- 3: Somewhat relevant but connection unclear
+- 1: Not relevant, doesn't align with goals
+
+**Traceable (1-5):**
+- 5: Clearly traces to user journey or business objective
+- 3: Partially traceable
+- 1: Orphan requirement, no clear source
+
+**For each FR with score < 3 in any category:**
+- Provide specific improvement suggestions
+
+Return scoring table with all FR scores and improvement suggestions for low-scoring FRs."
+
+**Graceful degradation (if no Task tool):**
+- Manually score each FR on SMART criteria
+- Note FRs with low scores
+- Provide improvement suggestions
+
+### 3. Build Scoring Table
+
+For each FR:
+- FR number
+- Specific score (1-5)
+- Measurable score (1-5)
+- Attainable score (1-5)
+- Relevant score (1-5)
+- Traceable score (1-5)
+- Average score
+- Flag if any category < 3
+
+**Calculate overall FR quality:**
+- Percentage of FRs with all scores ≥ 3
+- Percentage of FRs with all scores ≥ 4
+- Average score across all FRs and categories
+
+### 4. Report SMART Findings to Validation Report
+
+Append to validation report:
+
+```markdown
+## SMART Requirements Validation
+
+**Total Functional Requirements:** {count}
+
+### Scoring Summary
+
+**All scores ≥ 3:** {percentage}% ({count}/{total})
+**All scores ≥ 4:** {percentage}% ({count}/{total})
+**Overall Average Score:** {average}/5.0
+
+### Scoring Table
+
+| FR # | Specific | Measurable | Attainable | Relevant | Traceable | Average | Flag |
+|------|----------|------------|------------|----------|-----------|--------|------|
+| FR-001 | {s1} | {m1} | {a1} | {r1} | {t1} | {avg1} | {X if any <3} |
+| FR-002 | {s2} | {m2} | {a2} | {r2} | {t2} | {avg2} | {X if any <3} |
+[Continue for all FRs]
+
+**Legend:** 1=Poor, 3=Acceptable, 5=Excellent
+**Flag:** X = Score < 3 in one or more categories
+
+### Improvement Suggestions
+
+**Low-Scoring FRs:**
+
+**FR-{number}:** {specific suggestion for improvement}
+[For each FR with score < 3 in any category]
+
+### Overall Assessment
+
+**Severity:** [Critical if >30% flagged FRs, Warning if 10-30%, Pass if <10%]
+
+**Recommendation:**
+[If Critical] "Many FRs have quality issues. Revise flagged FRs using SMART framework to improve clarity and testability."
+[If Warning] "Some FRs would benefit from SMART refinement. Focus on flagged requirements above."
+[If Pass] "Functional Requirements demonstrate good SMART quality overall."
+```
+
+### 5. Display Progress and Auto-Proceed
+
+Display: "**SMART Requirements Validation Complete**
+
+FR Quality: {percentage}% with acceptable scores ({severity})
+
+**Proceeding to next validation check...**"
+
+Immediately load and execute {nextStepFile} (step-v-11-holistic-quality-validation.md)
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- All FRs extracted from PRD
+- Each FR scored on all 5 SMART criteria (1-5 scale)
+- FRs with scores < 3 flagged for improvement
+- Improvement suggestions provided for low-scoring FRs
+- Scoring table built with all FR scores
+- Overall quality assessment calculated
+- Findings reported to validation report
+- Auto-proceeds to next validation step
+- Subprocess attempted with graceful degradation
+
+### ❌ SYSTEM FAILURE:
+
+- Not scoring all FRs on all SMART criteria
+- Missing improvement suggestions for low-scoring FRs
+- Not building scoring table
+- Not calculating overall quality metrics
+- Not reporting findings to validation report
+- Not auto-proceeding
+
+**Master Rule:** FRs should be high-quality, not just present. SMART framework provides objective quality measure.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-v/step-v-11-holistic-quality-validation.md

@@ -0,0 +1,264 @@
+---
+name: 'step-v-11-holistic-quality-validation'
+description: 'Holistic Quality Assessment - Assess PRD as cohesive, compelling document - is it a good PRD?'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-12-completeness-validation.md'
+prdFile: '{prd_file_path}'
+validationReportPath: '{validation_report_path}'
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+---
+
+# Step 11: Holistic Quality Assessment
+
+## STEP GOAL:
+
+Assess the PRD as a cohesive, compelling document - evaluating document flow, dual audience effectiveness (humans and LLMs), BMAD PRD principles compliance, and overall quality rating.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and Quality Assurance Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in systematic validation, not collaborative dialogue
+- ✅ You bring analytical rigor and document quality expertise
+- ✅ This step runs autonomously - no user input needed
+- ✅ Uses Advanced Elicitation for multi-perspective evaluation
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on holistic document quality assessment
+- 🚫 FORBIDDEN to validate individual components (done in previous steps)
+- 💬 Approach: Multi-perspective evaluation using Advanced Elicitation
+- 🚪 This is a validation sequence step - auto-proceeds when complete
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Use Advanced Elicitation for multi-perspective assessment
+- 🎯 Evaluate document flow, dual audience, BMAD principles
+- 💾 Append comprehensive assessment to validation report
+- 📖 Display "Proceeding to next check..." and load next step
+- 🚫 FORBIDDEN to pause or request user input
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Complete PRD file, validation report with findings from steps 1-10
+- Focus: Holistic quality - the WHOLE document
+- Limits: Don't re-validate individual components, don't pause for user input
+- Dependencies: Steps 1-10 completed - all systematic checks done
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Attempt Sub-Process with Advanced Elicitation
+
+**Try to use Task tool to spawn a subprocess using Advanced Elicitation:**
+
+"Perform holistic quality assessment on this PRD using multi-perspective evaluation:
+
+**Load and execute Advanced Elicitation workflow:**
+{advancedElicitationTask}
+
+**Evaluate the PRD from these perspectives:**
+
+**1. Document Flow & Coherence:**
+- Read entire PRD
+- Evaluate narrative flow - does it tell a cohesive story?
+- Check transitions between sections
+- Assess consistency - is it coherent throughout?
+- Evaluate readability - is it clear and well-organized?
+
+**2. Dual Audience Effectiveness:**
+
+**For Humans:**
+- Executive-friendly: Can executives understand vision and goals quickly?
+- Developer clarity: Do developers have clear requirements to build from?
+- Designer clarity: Do designers understand user needs and flows?
+- Stakeholder decision-making: Can stakeholders make informed decisions?
+
+**For LLMs:**
+- Machine-readable structure: Is the PRD structured for LLM consumption?
+- UX readiness: Can an LLM generate UX designs from this?
+- Architecture readiness: Can an LLM generate architecture from this?
+- Epic/Story readiness: Can an LLM break down into epics and stories?
+
+**3. BMAD PRD Principles Compliance:**
+- Information density: Every sentence carries weight?
+- Measurability: Requirements testable?
+- Traceability: Requirements trace to sources?
+- Domain awareness: Domain-specific considerations included?
+- Zero anti-patterns: No filler or wordiness?
+- Dual audience: Works for both humans and LLMs?
+- Markdown format: Proper structure and formatting?
+
+**4. Overall Quality Rating:**
+Rate the PRD on 5-point scale:
+- Excellent (5/5): Exemplary, ready for production use
+- Good (4/5): Strong with minor improvements needed
+- Adequate (3/5): Acceptable but needs refinement
+- Needs Work (2/5): Significant gaps or issues
+- Problematic (1/5): Major flaws, needs substantial revision
+
+**5. Top 3 Improvements:**
+Identify the 3 most impactful improvements to make this a great PRD
+
+Return comprehensive assessment with all perspectives, rating, and top 3 improvements."
+
+**Graceful degradation (if no Task tool or Advanced Elicitation unavailable):**
+- Perform holistic assessment directly in current context
+- Read complete PRD
+- Evaluate document flow, coherence, transitions
+- Assess dual audience effectiveness
+- Check BMAD principles compliance
+- Assign overall quality rating
+- Identify top 3 improvements
+
+### 2. Synthesize Assessment
+
+**Compile findings from multi-perspective evaluation:**
+
+**Document Flow & Coherence:**
+- Overall assessment: [Excellent/Good/Adequate/Needs Work/Problematic]
+- Key strengths: [list]
+- Key weaknesses: [list]
+
+**Dual Audience Effectiveness:**
+- For Humans: [assessment]
+- For LLMs: [assessment]
+- Overall dual audience score: [1-5]
+
+**BMAD Principles Compliance:**
+- Principles met: [count]/7
+- Principles with issues: [list]
+
+**Overall Quality Rating:** [1-5 with label]
+
+**Top 3 Improvements:**
+1. [Improvement 1]
+2. [Improvement 2]
+3. [Improvement 3]
+
+### 3. Report Holistic Quality Findings to Validation Report
+
+Append to validation report:
+
+```markdown
+## Holistic Quality Assessment
+
+### Document Flow & Coherence
+
+**Assessment:** [Excellent/Good/Adequate/Needs Work/Problematic]
+
+**Strengths:**
+{List key strengths}
+
+**Areas for Improvement:**
+{List key weaknesses}
+
+### Dual Audience Effectiveness
+
+**For Humans:**
+- Executive-friendly: [assessment]
+- Developer clarity: [assessment]
+- Designer clarity: [assessment]
+- Stakeholder decision-making: [assessment]
+
+**For LLMs:**
+- Machine-readable structure: [assessment]
+- UX readiness: [assessment]
+- Architecture readiness: [assessment]
+- Epic/Story readiness: [assessment]
+
+**Dual Audience Score:** {score}/5
+
+### BMAD PRD Principles Compliance
+
+| Principle | Status | Notes |
+|-----------|--------|-------|
+| Information Density | [Met/Partial/Not Met] | {notes} |
+| Measurability | [Met/Partial/Not Met] | {notes} |
+| Traceability | [Met/Partial/Not Met] | {notes} |
+| Domain Awareness | [Met/Partial/Not Met] | {notes} |
+| Zero Anti-Patterns | [Met/Partial/Not Met] | {notes} |
+| Dual Audience | [Met/Partial/Not Met] | {notes} |
+| Markdown Format | [Met/Partial/Not Met] | {notes} |
+
+**Principles Met:** {count}/7
+
+### Overall Quality Rating
+
+**Rating:** {rating}/5 - {label}
+
+**Scale:**
+- 5/5 - Excellent: Exemplary, ready for production use
+- 4/5 - Good: Strong with minor improvements needed
+- 3/5 - Adequate: Acceptable but needs refinement
+- 2/5 - Needs Work: Significant gaps or issues
+- 1/5 - Problematic: Major flaws, needs substantial revision
+
+### Top 3 Improvements
+
+1. **{Improvement 1}**
+   {Brief explanation of why and how}
+
+2. **{Improvement 2}**
+   {Brief explanation of why and how}
+
+3. **{Improvement 3}**
+   {Brief explanation of why and how}
+
+### Summary
+
+**This PRD is:** {one-sentence overall assessment}
+
+**To make it great:** Focus on the top 3 improvements above.
+```
+
+### 4. Display Progress and Auto-Proceed
+
+Display: "**Holistic Quality Assessment Complete**
+
+Overall Rating: {rating}/5 - {label}
+
+**Proceeding to final validation checks...**"
+
+Immediately load and execute {nextStepFile} (step-v-12-completeness-validation.md)
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Advanced Elicitation used for multi-perspective evaluation (or graceful degradation)
+- Document flow & coherence assessed
+- Dual audience effectiveness evaluated (humans and LLMs)
+- BMAD PRD principles compliance checked
+- Overall quality rating assigned (1-5 scale)
+- Top 3 improvements identified
+- Comprehensive assessment reported to validation report
+- Auto-proceeds to next validation step
+- Subprocess attempted with graceful degradation
+
+### ❌ SYSTEM FAILURE:
+
+- Not using Advanced Elicitation for multi-perspective evaluation
+- Missing document flow assessment
+- Missing dual audience evaluation
+- Not checking all BMAD principles
+- Not assigning overall quality rating
+- Missing top 3 improvements
+- Not reporting comprehensive assessment to validation report
+- Not auto-proceeding
+
+**Master Rule:** This evaluates the WHOLE document, not just components. Answers "Is this a good PRD?" and "What would make it great?"

_bmad/bmm/workflows/2-plan-workflows/prd/steps-v/step-v-12-completeness-validation.md

@@ -0,0 +1,242 @@
+---
+name: 'step-v-12-completeness-validation'
+description: 'Completeness Check - Final comprehensive completeness check before report generation'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-13-report-complete.md'
+prdFile: '{prd_file_path}'
+prdFrontmatter: '{prd_frontmatter}'
+validationReportPath: '{validation_report_path}'
+---
+
+# Step 12: Completeness Validation
+
+## STEP GOAL:
+
+Final comprehensive completeness check - validate no template variables remain, each section has required content, section-specific completeness, and frontmatter is properly populated.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and Quality Assurance Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in systematic validation, not collaborative dialogue
+- ✅ You bring attention to detail and completeness verification
+- ✅ This step runs autonomously - no user input needed
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on completeness verification
+- 🚫 FORBIDDEN to validate quality (done in step 11) or other aspects
+- 💬 Approach: Systematic checklist-style verification
+- 🚪 This is a validation sequence step - auto-proceeds when complete
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Check template completeness (no variables remaining)
+- 🎯 Validate content completeness (each section has required content)
+- 🎯 Validate section-specific completeness
+- 🎯 Validate frontmatter completeness
+- 💾 Append completeness matrix to validation report
+- 📖 Display "Proceeding to final step..." and load next step
+- 🚫 FORBIDDEN to pause or request user input
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Complete PRD file, frontmatter, validation report
+- Focus: Completeness verification only (final gate)
+- Limits: Don't assess quality, don't pause for user input
+- Dependencies: Steps 1-11 completed - all validation checks done
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Attempt Sub-Process Validation
+
+**Try to use Task tool to spawn a subprocess:**
+
+"Perform completeness validation on this PRD - final gate check:
+
+**1. Template Completeness:**
+- Scan PRD for any remaining template variables
+- Look for: {variable}, {{variable}}, {placeholder}, [placeholder], etc.
+- List any found with line numbers
+
+**2. Content Completeness:**
+- Executive Summary: Has vision statement? ({key content})
+- Success Criteria: All criteria measurable? ({metrics present})
+- Product Scope: In-scope and out-of-scope defined? ({both present})
+- User Journeys: User types identified? ({users listed})
+- Functional Requirements: FRs listed with proper format? ({FRs present})
+- Non-Functional Requirements: NFRs with metrics? ({NFRs present})
+
+For each section: Is required content present? (Yes/No/Partial)
+
+**3. Section-Specific Completeness:**
+- Success Criteria: Each has specific measurement method?
+- User Journeys: Cover all user types?
+- Functional Requirements: Cover MVP scope?
+- Non-Functional Requirements: Each has specific criteria?
+
+**4. Frontmatter Completeness:**
+- stepsCompleted: Populated?
+- classification: Present (domain, projectType)?
+- inputDocuments: Tracked?
+- date: Present?
+
+Return completeness matrix with status for each check."
+
+**Graceful degradation (if no Task tool):**
+- Manually scan for template variables
+- Manually check each section for required content
+- Manually verify frontmatter fields
+- Build completeness matrix
+
+### 2. Build Completeness Matrix
+
+**Template Completeness:**
+- Template variables found: count
+- List if any found
+
+**Content Completeness by Section:**
+- Executive Summary: Complete / Incomplete / Missing
+- Success Criteria: Complete / Incomplete / Missing
+- Product Scope: Complete / Incomplete / Missing
+- User Journeys: Complete / Incomplete / Missing
+- Functional Requirements: Complete / Incomplete / Missing
+- Non-Functional Requirements: Complete / Incomplete / Missing
+- Other sections: [List completeness]
+
+**Section-Specific Completeness:**
+- Success criteria measurable: All / Some / None
+- Journeys cover all users: Yes / Partial / No
+- FRs cover MVP scope: Yes / Partial / No
+- NFRs have specific criteria: All / Some / None
+
+**Frontmatter Completeness:**
+- stepsCompleted: Present / Missing
+- classification: Present / Missing
+- inputDocuments: Present / Missing
+- date: Present / Missing
+
+**Overall completeness:**
+- Sections complete: X/Y
+- Critical gaps: [list if any]
+
+### 3. Report Completeness Findings to Validation Report
+
+Append to validation report:
+
+```markdown
+## Completeness Validation
+
+### Template Completeness
+
+**Template Variables Found:** {count}
+{If count > 0, list variables with line numbers}
+{If count = 0, note: No template variables remaining ✓}
+
+### Content Completeness by Section
+
+**Executive Summary:** [Complete/Incomplete/Missing]
+{If incomplete or missing, note specific gaps}
+
+**Success Criteria:** [Complete/Incomplete/Missing]
+{If incomplete or missing, note specific gaps}
+
+**Product Scope:** [Complete/Incomplete/Missing]
+{If incomplete or missing, note specific gaps}
+
+**User Journeys:** [Complete/Incomplete/Missing]
+{If incomplete or missing, note specific gaps}
+
+**Functional Requirements:** [Complete/Incomplete/Missing]
+{If incomplete or missing, note specific gaps}
+
+**Non-Functional Requirements:** [Complete/Incomplete/Missing]
+{If incomplete or missing, note specific gaps}
+
+### Section-Specific Completeness
+
+**Success Criteria Measurability:** [All/Some/None] measurable
+{If Some or None, note which criteria lack metrics}
+
+**User Journeys Coverage:** [Yes/Partial/No] - covers all user types
+{If Partial or No, note missing user types}
+
+**FRs Cover MVP Scope:** [Yes/Partial/No]
+{If Partial or No, note scope gaps}
+
+**NFRs Have Specific Criteria:** [All/Some/None]
+{If Some or None, note which NFRs lack specificity}
+
+### Frontmatter Completeness
+
+**stepsCompleted:** [Present/Missing]
+**classification:** [Present/Missing]
+**inputDocuments:** [Present/Missing]
+**date:** [Present/Missing]
+
+**Frontmatter Completeness:** {complete_fields}/4
+
+### Completeness Summary
+
+**Overall Completeness:** {percentage}% ({complete_sections}/{total_sections})
+
+**Critical Gaps:** [count] [list if any]
+**Minor Gaps:** [count] [list if any]
+
+**Severity:** [Critical if template variables exist or critical sections missing, Warning if minor gaps, Pass if complete]
+
+**Recommendation:**
+[If Critical] "PRD has completeness gaps that must be addressed before use. Fix template variables and complete missing sections."
+[If Warning] "PRD has minor completeness gaps. Address minor gaps for complete documentation."
+[If Pass] "PRD is complete with all required sections and content present."
+```
+
+### 4. Display Progress and Auto-Proceed
+
+Display: "**Completeness Validation Complete**
+
+Overall Completeness: {percentage}% ({severity})
+
+**Proceeding to final step...**"
+
+Immediately load and execute {nextStepFile} (step-v-13-report-complete.md)
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Scanned for template variables systematically
+- Validated each section for required content
+- Validated section-specific completeness (measurability, coverage, scope)
+- Validated frontmatter completeness
+- Completeness matrix built with all checks
+- Severity assessed correctly
+- Findings reported to validation report
+- Auto-proceeds to final step
+- Subprocess attempted with graceful degradation
+
+### ❌ SYSTEM FAILURE:
+
+- Not scanning for template variables
+- Missing section-specific completeness checks
+- Not validating frontmatter
+- Not building completeness matrix
+- Not reporting findings to validation report
+- Not auto-proceeding
+
+**Master Rule:** Final gate to ensure document is complete before presenting findings. Template variables or critical gaps must be fixed.

_bmad/bmm/workflows/2-plan-workflows/prd/steps-v/step-v-13-report-complete.md

@@ -0,0 +1,232 @@
+---
+name: 'step-v-13-report-complete'
+description: 'Validation Report Complete - Finalize report, summarize findings, present to user, offer next steps'
+
+# File references (ONLY variables used in this step)
+validationReportPath: '{validation_report_path}'
+prdFile: '{prd_file_path}'
+---
+
+# Step 13: Validation Report Complete
+
+## STEP GOAL:
+
+Finalize validation report, summarize all findings from steps 1-12, present summary to user conversationally, and offer actionable next steps.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and Quality Assurance Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring synthesis and summary expertise
+- ✅ This is the FINAL step - requires user interaction
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on summarizing findings and presenting options
+- 🚫 FORBIDDEN to perform additional validation
+- 💬 Approach: Conversational summary with clear next steps
+- 🚪 This is the final step - no next step after this
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Load complete validation report
+- 🎯 Summarize all findings from steps 1-12
+- 🎯 Update report frontmatter with final status
+- 💬 Present summary to user conversationally
+- 💬 Offer menu options for next actions
+- 🚫 FORBIDDEN to proceed without user selection
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Complete validation report with findings from all validation steps
+- Focus: Summary and presentation only (no new validation)
+- Limits: Don't add new findings, just synthesize existing
+- Dependencies: Steps 1-12 completed - all validation checks done
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Load Complete Validation Report
+
+Read the entire validation report from {validationReportPath}
+
+Extract all findings from:
+- Format Detection (Step 2)
+- Parity Analysis (Step 2B, if applicable)
+- Information Density (Step 3)
+- Product Brief Coverage (Step 4)
+- Measurability (Step 5)
+- Traceability (Step 6)
+- Implementation Leakage (Step 7)
+- Domain Compliance (Step 8)
+- Project-Type Compliance (Step 9)
+- SMART Requirements (Step 10)
+- Holistic Quality (Step 11)
+- Completeness (Step 12)
+
+### 2. Update Report Frontmatter with Final Status
+
+Update validation report frontmatter:
+
+```yaml
+---
+validationTarget: '{prd_path}'
+validationDate: '{current_date}'
+inputDocuments: [list of documents]
+validationStepsCompleted: ['step-v-01-discovery', 'step-v-02-format-detection', 'step-v-03-density-validation', 'step-v-04-brief-coverage-validation', 'step-v-05-measurability-validation', 'step-v-06-traceability-validation', 'step-v-07-implementation-leakage-validation', 'step-v-08-domain-compliance-validation', 'step-v-09-project-type-validation', 'step-v-10-smart-validation', 'step-v-11-holistic-quality-validation', 'step-v-12-completeness-validation']
+validationStatus: COMPLETE
+holisticQualityRating: '{rating from step 11}'
+overallStatus: '{Pass/Warning/Critical based on all findings}'
+---
+```
+
+### 3. Create Summary of Findings
+
+**Overall Status:**
+- Determine from all validation findings
+- **Pass:** All critical checks pass, minor warnings acceptable
+- **Warning:** Some issues found but PRD is usable
+- **Critical:** Major issues that prevent PRD from being fit for purpose
+
+**Quick Results Table:**
+- Format: [classification]
+- Information Density: [severity]
+- Measurability: [severity]
+- Traceability: [severity]
+- Implementation Leakage: [severity]
+- Domain Compliance: [status]
+- Project-Type Compliance: [compliance score]
+- SMART Quality: [percentage]
+- Holistic Quality: [rating/5]
+- Completeness: [percentage]
+
+**Critical Issues:** List from all validation steps
+**Warnings:** List from all validation steps
+**Strengths:** List positives from all validation steps
+
+**Holistic Quality Rating:** From step 11
+**Top 3 Improvements:** From step 11
+
+**Recommendation:** Based on overall status
+
+### 4. Present Summary to User Conversationally
+
+Display:
+
+"**✓ PRD Validation Complete**
+
+**Overall Status:** {Pass/Warning/Critical}
+
+**Quick Results:**
+{Present quick results table with key findings}
+
+**Critical Issues:** {count or "None"}
+{If any, list briefly}
+
+**Warnings:** {count or "None"}
+{If any, list briefly}
+
+**Strengths:**
+{List key strengths}
+
+**Holistic Quality:** {rating}/5 - {label}
+
+**Top 3 Improvements:**
+1. {Improvement 1}
+2. {Improvement 2}
+3. {Improvement 3}
+
+**Recommendation:**
+{Based on overall status:
+- Pass: "PRD is in good shape. Address minor improvements to make it great."
+- Warning: "PRD is usable but has issues that should be addressed. Review warnings and improve where needed."
+- Critical: "PRD has significant issues that should be fixed before use. Focus on critical issues above."}
+
+**What would you like to do next?**"
+
+### 5. Present MENU OPTIONS
+
+Display:
+
+**[R] Review Detailed Findings** - Walk through validation report section by section
+**[E] Use Edit Workflow** - Use validation report with Edit workflow for systematic improvements
+**[F] Fix Simpler Items** - Immediate fixes for simple issues (anti-patterns, leakage, missing headers)
+**[X] Exit** - Exit and review validation report
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input after presenting menu
+- Only proceed based on user selection
+
+#### Menu Handling Logic:
+
+- **IF R (Review Detailed Findings):**
+  - Walk through validation report section by section
+  - Present findings from each validation step
+  - Allow user to ask questions
+  - After review, return to menu
+
+- **IF E (Use Edit Workflow):**
+  - Explain: "The Edit workflow (steps-e/) can use this validation report to systematically address issues. Edit mode will guide you through discovering what to edit, reviewing the PRD, and applying targeted improvements."
+  - Offer: "Would you like to launch Edit mode now? It will help you fix validation findings systematically."
+  - If yes: Load and execute steps-e/step-e-01-discovery.md
+  - If no: Return to menu
+
+- **IF F (Fix Simpler Items):**
+  - Offer immediate fixes for:
+    - Template variables (fill in with appropriate content)
+    - Conversational filler (remove wordy phrases)
+    - Implementation leakage (remove technology names from FRs/NFRs)
+    - Missing section headers (add ## headers)
+  - Ask: "Which simple fixes would you like me to make?"
+  - If user specifies fixes, make them and update validation report
+  - Return to menu
+
+- **IF X (Exit):**
+  - Display: "**Validation Report Saved:** {validationReportPath}"
+  - Display: "**Summary:** {overall status} - {recommendation}"
+  - Display: "**Next Steps:** Review the validation report and address findings. For systematic improvements, consider using Edit workflow when available, or manually fix issues identified in this report."
+  - Exit validation
+
+- **IF Any other:** Help user, then redisplay menu
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Complete validation report loaded successfully
+- All findings from steps 1-12 summarized
+- Report frontmatter updated with final status
+- Overall status determined correctly (Pass/Warning/Critical)
+- Quick results table presented
+- Critical issues, warnings, and strengths listed
+- Holistic quality rating included
+- Top 3 improvements presented
+- Clear recommendation provided
+- Menu options presented with clear explanations
+- User can review findings, get help, or exit
+
+### ❌ SYSTEM FAILURE:
+
+- Not loading complete validation report
+- Missing summary of findings
+- Not updating report frontmatter
+- Not determining overall status
+- Missing menu options
+- Unclear next steps
+
+**Master Rule:** User needs clear summary and actionable next steps. Edit workflow is best for complex issues; immediate fixes available for simpler ones.

_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-02-discovery.md

@@ -1,421 +0,0 @@
----
-name: 'step-02-discovery'
-description: 'Conduct project and domain discovery with data-driven classification'
-
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd'
-
-# File References
-thisStepFile: '{workflow_path}/steps/step-02-discovery.md'
-nextStepFile: '{workflow_path}/steps/step-03-success.md'
-workflowFile: '{workflow_path}/workflow.md'
-outputFile: '{planning_artifacts}/prd.md'
-
-# Data Files
-projectTypesCSV: '{workflow_path}/project-types.csv'
-domainComplexityCSV: '{workflow_path}/domain-complexity.csv'
-
-# Task References
-advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
-partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
----
-
-# Step 2: Project & Domain Discovery
-
-**Progress: Step 2 of 11** - Next: Success Criteria Definition
-
-## STEP GOAL:
-
-Conduct comprehensive project discovery that leverages existing input documents while allowing user refinement, with data-driven classification, and generate the Executive Summary content.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-### Role Reinforcement:
-
-- ✅ You are a product-focused PM facilitator collaborating with an expert peer
-- ✅ We engage in collaborative dialogue, not command-response
-- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision
-
-### Step-Specific Rules:
-
-- 🎯 Focus on project classification and vision alignment only
-- 🚫 FORBIDDEN to generate content without real user input
-- 💬 APPROACH: Adapt questions based on document context (brownfield vs greenfield)
-- 🎯 LOAD classification data BEFORE starting discovery conversation
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating executive summary content
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading next step
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to develop deeper insights about the generated content
-- **P (Party Mode)**: Bring multiple perspectives to discuss and improve the generated content
-- **C (Continue)**: Append and save the content to the `{outputFile}` and proceed to next step
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Execute {advancedElicitationTask}
-- When 'P' selected: Execute {partyModeWorkflow}
-- PROTOCOLS always return to this step's A/P/C menu
-- User accepts/rejects protocol changes before proceeding
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from step 1 are available
-- Input documents already loaded are in memory (product briefs, research, brainstorming, project docs)
-- **Document counts available in frontmatter `documentCounts`**
-- Classification CSV data will be loaded in this step only
-- This will be the first content section appended to the document
-
-## Sequence of Instructions (Do not deviate, skip, or optimize)
-
-### 1. Read Document State from Frontmatter
-
-**CRITICAL FIRST ACTION:** Read the frontmatter from `{outputFile}` to get document counts.
-
-```
-Read documentCounts from prd.md frontmatter:
-- briefCount = documentCounts.briefs
-- researchCount = documentCounts.research
-- brainstormingCount = documentCounts.brainstorming
-- projectDocsCount = documentCounts.projectDocs
-```
-
-**ANNOUNCE your understanding:**
-
-"From step 1, I have loaded:
-
-- Product briefs: {{briefCount}} files
-- Research: {{researchCount}} files
-- Brainstorming: {{brainstormingCount}} files
-- Project docs: {{projectDocsCount}} files
-
-{if projectDocsCount > 0}This is a **brownfield project** - I'll focus on understanding what you want to add or change.{else}This is a **greenfield project** - I'll help you define the full product vision.{/if}"
-
-### 2. Load Classification Data
-
-Load and prepare CSV data for intelligent classification:
-
-- Load `{projectTypesCSV}` completely
-- Load `{domainComplexityCSV}` completely
-- Parse column structures and store in memory for this step only
-
-### 3. Begin Discovery Conversation
-
-**SELECT EXACTLY ONE DISCOVERY PATH based on document state:**
-
----
-
-#### PATH A: Has Product Brief (briefCount > 0)
-
-**Use this path when:** `briefCount > 0`
-
-"As your PM peer, I've reviewed your product brief and have a great starting point for our discovery. Let me share what I understand and you can refine or correct as needed.
-
-**Based on your product brief:**
-
-**What you're building:**
-{{extracted_vision_from_brief}}
-
-**Problem it solves:**
-{{extracted_problem_from_brief}}
-
-**Target users:**
-{{extracted_users_from_brief}}
-
-**What makes it special:**
-{{extracted_differentiator_from_brief}}
-
-{if projectDocsCount > 0}I also see you have existing project documentation. This PRD will define how new features integrate with your existing system architecture.{/if}
-
-**How does this align with your vision?** Should we refine any of these points or are there important aspects I'm missing?"
-
-**AFTER this message, SKIP to Section 4.**
-
----
-
-#### PATH B: No Brief but Has Project Docs - Brownfield (briefCount == 0 AND projectDocsCount > 0)
-
-**Use this path when:** `briefCount == 0 AND projectDocsCount > 0`
-
-**NOTE:** Extract the following from loaded project documentation (index.md, architecture.md, project-overview.md, etc.):
-
-"As your PM peer, I've reviewed your existing project documentation from document-project.
-
-**Your existing system includes:**
-
-- **Tech Stack:** {analyze index.md and architecture.md for technologies used}
-- **Architecture:** {summarize architecture patterns from architecture.md}
-- **Key Components:** {list main components from source-tree-analysis.md or project-overview.md}
-
-This PRD will define **new features or changes** to add to this existing codebase.
-
-**Tell me about what you want to add or change:**
-
-- What new capability or feature do you want to build?
-- What problem will this solve for your users?
-- How should it integrate with the existing system?
-- Is this adding new functionality, improving existing features, or fixing issues?
-
-I'll help you create a PRD focused on these additions while respecting your existing patterns and architecture."
-
-**AFTER this message, SKIP to Section 4.**
-
----
-
-#### PATH C: No Documents - Greenfield (briefCount == 0 AND projectDocsCount == 0)
-
-**Use this path when:** `briefCount == 0 AND projectDocsCount == 0`
-
-"As your PM peer, I'm excited to help you shape {{project_name}}. Let me start by understanding what you want to build.
-
-**Tell me about what you want to create:**
-
-- What problem does it solve?
-- Who are you building this for?
-- What excites you most about this product?
-
-I'll be listening for signals to help us classify the project and domain so we can ask the right questions throughout our process."
-
-**AFTER this message, continue to Section 4.**
-
----
-
-### 4. Listen for Classification Signals
-
-As the user describes their product/feature, listen for and match against:
-
-#### Project Type Signals
-
-Compare user description against `detection_signals` from `project-types.csv`:
-
-- Look for keyword matches from semicolon-separated signals
-- Examples: "API,REST,GraphQL" → api_backend
-- Examples: "iOS,Android,app,mobile" → mobile_app
-- Store the best matching `project_type`
-
-#### Domain Signals
-
-Compare user description against `signals` from `domain-complexity.csv`:
-
-- Look for domain keyword matches
-- Examples: "medical,diagnostic,clinical" → healthcare
-- Examples: "payment,banking,trading" → fintech
-- Store the matched `domain` and `complexity_level`
-
-### 5. Present Classification for Validation
-
-**SELECT EXACTLY ONE CLASSIFICATION PRESENTATION based on document state:**
-
----
-
-#### IF PATH A was used (briefCount > 0):
-
-"Based on your product brief and our discussion, I'm classifying this as:
-
-- **Project Type:** {project_type_from_brief_or_conversation}
-- **Domain:** {domain_from_brief_or_conversation}
-- **Complexity:** {complexity_from_brief_or_conversation}
-
-From your brief, I detected these classification signals:
-{{classification_signals_from_brief}}
-
-{if projectDocsCount > 0}Your existing project documentation also indicates:
-
-- **Existing Tech Stack:** {from architecture.md or index.md}
-- **Architecture Pattern:** {from architecture.md}
-
-I'll ensure the new features align with your existing system.{/if}
-
-Combined with our conversation, this suggests the above classification. Does this sound right?"
-
----
-
-#### IF PATH B was used (briefCount == 0 AND projectDocsCount > 0):
-
-"Based on your existing project documentation and our discussion about new features:
-
-- **Existing Project Type:** {detected from project docs - e.g., web_app, api_backend}
-- **Tech Stack:** {from architecture.md or index.md}
-- **New Feature Type:** {from user's description of what they want to add}
-- **Domain:** {detected_domain}
-- **Complexity:** {complexity_level}
-
-I'll ensure the PRD aligns with your existing architecture patterns. Does this classification sound right?"
-
----
-
-#### IF PATH C was used (briefCount == 0 AND projectDocsCount == 0):
-
-"Based on our conversation, I'm hearing this as:
-
-- **Project Type:** {detected_project_type}
-- **Domain:** {detected_domain}
-- **Complexity:** {complexity_level}
-
-Does this sound right to you? I want to make sure we're on the same page before diving deeper."
-
----
-
-### 6. Identify What Makes It Special
-
-**SELECT EXACTLY ONE DIFFERENTIATOR DISCOVERY based on document state:**
-
----
-
-#### IF PATH A was used (briefCount > 0):
-
-"From your product brief, I understand that what makes this special is:
-{{extracted_differentiator_from_brief}}
-
-Let's explore this deeper:
-
-- **Refinement needed:** Does this capture the essence correctly, or should we adjust it?
-- **Missing aspects:** Are there other differentiators that aren't captured in your brief?
-- **Evolution:** How has your thinking on this evolved since you wrote the brief?"
-
----
-
-#### IF PATH B was used (briefCount == 0 AND projectDocsCount > 0):
-
-"Your existing system already provides certain capabilities. Now let's define what makes these **new additions** special:
-
-- What gap in your current system will this fill?
-- How will this improve the experience for your existing users?
-- What's the key insight that led you to prioritize this addition?
-- What would make users say 'finally, this is what we needed'?"
-
----
-
-#### IF PATH C was used (briefCount == 0 AND projectDocsCount == 0):
-
-Ask focused questions to capture the product's unique value:
-
-- "What would make users say 'this is exactly what I needed'?"
-- "What's the moment where users realize this is different/better?"
-- "What assumption about [problem space] are you challenging?"
-- "If this succeeds wildly, what changed for your users?"
-
----
-
-### 7. Generate Executive Summary Content
-
-Based on the conversation, prepare the content to append to the document:
-
-#### Content Structure:
-
-```markdown
-## Executive Summary
-
-{vision_alignment_content}
-
-### What Makes This Special
-
-{product_differentiator_content}
-
-## Project Classification
-
-**Technical Type:** {project_type}
-**Domain:** {domain}
-**Complexity:** {complexity_level}
-{if projectDocsCount > 0}**Project Context:** Brownfield - extending existing system{else}**Project Context:** Greenfield - new project{/if}
-
-{project_classification_content}
-```
-
-### 8. Present Content and Menu
-
-Show the generated content to the user and present:
-
-"I've drafted our Executive Summary based on our conversation. This will be the first section of your PRD.
-
-**Here's what I'll add to the document:**
-
-[Show the complete markdown content from step 7]
-
-**Select an Option:**
-[A] Advanced Elicitation - Let's dive deeper and refine this content
-[P] Party Mode - Bring in different perspectives to improve this
-[C] Continue - Save this and move to Success Criteria Definition (Step 3 of 11)"
-
-### 9. Handle Menu Selection
-
-#### IF A (Advanced Elicitation):
-
-- Execute {advancedElicitationTask} with the current content
-- Process the enhanced content that comes back
-- Ask user: "Accept these changes to the Executive Summary? (y/n)"
-- If yes: Update the content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### IF P (Party Mode):
-
-- Execute {partyModeWorkflow} with the current content
-- Process the collaborative improvements that come back
-- Ask user: "Accept these changes to the Executive Summary? (y/n)"
-- If yes: Update the content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### IF C (Continue):
-
-- Append the final content to `{outputFile}`
-- Update frontmatter: add this step name to the end of the steps completed array
-- Load `{nextStepFile}`
-
-## CRITICAL STEP COMPLETION NOTE
-
-ONLY WHEN [C continue option] is selected and [executive summary content finalized and saved to document with frontmatter updated], will you then load and read fully `{nextStepFile}` to execute and begin success criteria definition.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Document counts read from frontmatter and announced
-- Classification data loaded and used effectively
-- **Correct discovery path selected based on document counts**
-- Input documents analyzed and leveraged for head start
-- User classifications validated and confirmed
-- Product differentiator clearly identified and refined
-- Executive summary content generated collaboratively with document context
-- A/P/C menu presented and handled correctly
-- Content properly appended to document when C selected
-- Frontmatter updated with stepsCompleted: [1, 2]
-
-### ❌ SYSTEM FAILURE:
-
-- **Not reading documentCounts from frontmatter first**
-- **Executing multiple discovery paths instead of exactly one**
-- Skipping classification data loading and guessing classifications
-- Not leveraging existing input documents to accelerate discovery
-- Not validating classifications with user before proceeding
-- Generating executive summary without real user input
-- Missing the "what makes it special" discovery and refinement
-- Not presenting A/P/C menu after content generation
-- Appending content without user selecting 'C'
-
-**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
-
-## COMPLEXITY HANDLING:
-
-If `complexity_level = "high"`:
-
-- Note the `suggested_workflow` and `web_searches` from domain CSV
-- Consider mentioning domain research needs in classification section
-- Document complexity implications in project classification

_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-04-journeys.md

@@ -1,291 +0,0 @@
----
-name: 'step-04-journeys'
-description: 'Map ALL user types that interact with the system with narrative story-based journeys'
-
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd'
-
-# File References
-thisStepFile: '{workflow_path}/steps/step-04-journeys.md'
-nextStepFile: '{workflow_path}/steps/step-05-domain.md'
-workflowFile: '{workflow_path}/workflow.md'
-outputFile: '{planning_artifacts}/prd.md'
-
-# Task References
-advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
-partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
----
-
-# Step 4: User Journey Mapping
-
-**Progress: Step 4 of 11** - Next: Domain Requirements
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on mapping ALL user types that interact with the system
-- 🎯 CRITICAL: No journey = no functional requirements = product doesn't exist
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating journey content
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading next step
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to develop deeper journey insights
-- **P (Party Mode)**: Bring multiple perspectives to map comprehensive user journeys
-- **C (Continue)**: Save the content to the document and proceed to next step
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml
-- When 'P' selected: Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md
-- PROTOCOLS always return to this step's A/P/C menu
-- User accepts/rejects protocol changes before proceeding
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from previous steps are available
-- Success criteria and scope already defined
-- Input documents from step-01 are available (product briefs with user personas)
-- Every human interaction with the system needs a journey
-
-## YOUR TASK:
-
-Create compelling narrative user journeys that leverage existing personas from product briefs and identify additional user types needed for comprehensive coverage.
-
-## JOURNEY MAPPING SEQUENCE:
-
-### 1. Leverage Existing Users & Identify Additional Types
-
-**Check Input Documents for Existing Personas:**
-Analyze product brief, research, and brainstorming documents for user personas already defined.
-
-**If User Personas Exist in Input Documents:**
-"I found some fantastic user personas in your product brief! Let me introduce them and see if we need to expand our cast of characters.
-
-**From your brief:**
-{{extracted_personas_from_brief_with_details}}
-
-These are great starting points! Their stories already give us insight into what they need from {{project_name}}.
-
-**Beyond your identified users, who else touches this system?**
-Based on your product type and scope, we might need:
-
-{{suggest_additional_user_types_based_on_project_context}}
-
-What additional user types should we consider for this product?"
-
-**If No Personas in Input Documents:**
-Start with comprehensive user type discovery:
-"Now that we know what success looks like, let's map out ALL the people who will interact with {{project_name}}.
-
-**Beyond primary users, who else touches this system?**
-Consider:
-
-- End users (the primary focus)
-- Admins - manage users, settings, content
-- Moderators - review flagged content, enforce rules
-- Support staff - help users, investigate issues
-- API consumers - if dev tool or platform
-- Internal ops - analytics, monitoring, billing
-
-What user types should we map for this product?"
-
-### 2. Create Narrative Story-Based Journeys
-
-For each user type, create compelling narrative journeys that tell their story:
-
-#### Narrative Journey Creation Process:
-
-**If Using Existing Persona from Input Documents:**
-"Let's tell {{persona_name}}'s story with {{project_name}}.
-
-**Their Story So Far:**
-{{persona_backstory_from_brief}}
-
-**How {{project_name}} Changes Their Life:**
-{{how_product_helps_them}}
-
-Let's craft their journey narrative - where do we meet them in their story, and how does {{project_name}} help them write their next chapter?"
-
-**If Creating New Persona:**
-"Let's bring this user type to life with a compelling story.
-
-**Creating Their Character:**
-
-- **Name**: Give them a realistic name and personality
-- **Situation**: What's happening in their life/work that creates the need?
-- **Goal**: What do they desperately want to achieve?
-- **Obstacle**: What's standing in their way right now?
-
-**How {{project_name}} Becomes Their Solution:**
-{{how_product_solves_their_story}}
-
-Now let's map their journey narrative."
-
-**Story-Based Journey Mapping:**
-
-"Let's craft this as a story with our hero (the user) facing challenges and finding solutions through {{project_name}}:
-
-**Story Structure:**
-
-- **Opening Scene**: Where and how do we meet them? What's their current pain?
-- **Rising Action**: What steps do they take? What do they discover?
-- **Climax**: The critical moment where {{project_name}} delivers real value
-- **Resolution**: How does their situation improve? What's their new reality?
-
-**Use This Narrative Format such as this example:**
-
-```markdown
-**Journey 1: Maria Santos - Reclaiming Her Creative Time**
-Maria is a freelance graphic designer who loves creating beautiful logos but spends hours every week managing client projects, sending invoices, and chasing payments. She feels like she's running a small business instead of doing what she loves. Late one night, while searching for invoicing tools, she discovers CreativeFlow and decides to give it a try.
-
-The next morning, instead of her usual 30-minute project management routine, she spends 5 minutes setting up her first client in CreativeFlow. The system automatically generates a professional invoice and even suggests follow-up emails based on her communication patterns. When a client asks for a project update, Maria can share a beautiful progress link instead of digging through emails.
-
-The breakthrough comes when she lands a major corporate client who's impressed by her "organized and professional" project setup. Six months later, Maria has doubled her client base and spends 80% of her time actually designing - exactly what she always wanted.
-```
-
-### 3. Guide Journey Exploration
-
-For each journey, facilitate detailed exploration:
-
-- "What happens at each step specifically?"
-- "What could go wrong here? What's the recovery path?"
-- "What information do they need to see/hear?"
-- "What's their emotional state at each point?"
-- "Where does this journey succeed or fail?"
-
-### 4. Connect Journeys to Requirements
-
-After each journey, explicitly state:
-"This journey reveals requirements for:
-
-- List specific capability areas (e.g., onboarding, meal planning, admin dashboard)
-- Help user see how different journeys create different feature sets"
-
-### 5. Aim for Comprehensive Coverage
-
-Guide toward complete journey set:
-
-- **Primary user** - happy path (core experience)
-- **Primary user** - edge case (different goal, error recovery)
-- **Secondary user** (admin, moderator, support, etc.)
-- **API consumer** (if applicable)
-
-Ask: "Another journey? We should cover [suggest uncovered user type]"
-
-### 6. Generate User Journey Content
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-When saving to document, append these Level 2 and Level 3 sections:
-
-```markdown
-## User Journeys
-
-[All journey narratives based on conversation]
-
-### Journey Requirements Summary
-
-[Summary of capabilities revealed by journeys based on conversation]
-```
-
-### 7. Present Content and Menu
-
-Show the generated journey content and present choices:
-"I've mapped out the user journeys based on our conversation. Each journey reveals different capabilities needed for {{project_name}}.
-
-**Here's what I'll add to the document:**
-
-[Show the complete markdown content from step 6]
-
-**What would you like to do?**
-[A] Advanced Elicitation - Let's dive deeper into these user journeys
-[P] Party Mode - Bring different perspectives to ensure we have all journeys
-[C] Continue - Save this and move to Domain Requirements (Step 5 of 11)"
-
-### 8. Handle Menu Selection
-
-#### If 'A' (Advanced Elicitation):
-
-- Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml with the current journey content
-- Process the enhanced journey insights that come back
-- Ask user: "Accept these improvements to the user journeys? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'P' (Party Mode):
-
-- Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md with the current journeys
-- Process the collaborative journey improvements and additions
-- Ask user: "Accept these changes to the user journeys? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'C' (Continue):
-
-- Append the final content to `{outputFile}`
-- Update frontmatter: add this step name to the end of the steps completed array
-- Load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-05-domain.md` (or determine if step is optional based on domain complexity)
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 6.
-
-## SUCCESS METRICS:
-
-✅ Existing personas from product briefs leveraged when available
-✅ All user types identified (not just primary users)
-✅ Rich narrative storytelling for each persona and journey
-✅ Complete story-based journey mapping with emotional arc
-✅ Journey requirements clearly connected to capabilities needed
-✅ Minimum 3-4 compelling narrative journeys covering different user types
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Ignoring existing personas from product briefs
-❌ Only mapping primary user journeys and missing secondary users
-❌ Creating generic journeys without rich persona details and narrative
-❌ Missing emotional storytelling elements that make journeys compelling
-❌ Missing critical decision points and failure scenarios
-❌ Not connecting journeys to required capabilities
-❌ Not having enough journey diversity (admin, support, API, etc.)
-❌ Not presenting A/P/C menu after content generation
-❌ Appending content without user selecting 'C'
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## JOURNEY TYPES TO ENSURE:
-
-**Minimum Coverage:**
-
-1. **Primary User - Success Path**: Core experience journey
-2. **Primary User - Edge Case**: Error recovery, alternative goals
-3. **Admin/Operations User**: Management, configuration, monitoring
-4. **Support/Troubleshooting**: Help, investigation, issue resolution
-5. **API/Integration** (if applicable): Developer/technical user journey
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load `./step-05-domain.md`.
-
-Remember: Do NOT proceed to step-05 until user explicitly selects 'C' from the A/P/C menu and content is saved!

_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-05-domain.md

@@ -1,271 +0,0 @@
----
-name: 'step-05-domain'
-description: 'Explore domain-specific requirements for complex domains (optional step)'
-
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd'
-
-# File References
-thisStepFile: '{workflow_path}/steps/step-05-domain.md'
-nextStepFile: '{workflow_path}/steps/step-06-innovation.md'
-workflowFile: '{workflow_path}/workflow.md'
-outputFile: '{planning_artifacts}/prd.md'
-
-# Data Files
-domainComplexityCSV: '{workflow_path}/domain-complexity.csv'
-
-# Task References
-advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
-partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
----
-
-# Step 5: Domain-Specific Exploration
-
-**Progress: Step 5 of 11** - Next: Innovation Focus
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on domain-specific requirements and compliance needs
-- 🎯 OPTIONAL STEP: Only proceed if complexity_level = "high" from step-02
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating domain content
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5]` before loading next step
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to develop deeper domain insights
-- **P (Party Mode)**: Bring domain expertise perspectives to explore requirements
-- **C (Continue)**: Save the content to the document and proceed to next step
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml
-- When 'P' selected: Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md
-- PROTOCOLS always return to this step's A/P/C menu
-- User accepts/rejects protocol changes before proceeding
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from previous steps are available
-- Domain complexity from step-02 should be "high" to justify this step
-- Domain-specific CSV data will be loaded in this step
-- Focus on compliance, regulations, and domain-specific constraints
-
-## OPTIONAL STEP CHECK:
-
-Before proceeding with this step, verify:
-
-- Is `complexity_level` from step-02 equal to "high" and/or does the domain have specific regulatory/compliance needs?
-- Would domain exploration significantly impact the product requirements?
-
-If NO to these questions, skip this step and load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-06-innovation.md`.
-
-## YOUR TASK:
-
-Explore domain-specific requirements for complex domains that need specialized compliance, regulatory, or industry-specific considerations.
-
-## DOMAIN EXPLORATION SEQUENCE:
-
-### 1. Load Domain Configuration Data
-
-Load domain-specific configuration for complex domains:
-
-- Load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/domain-complexity.csv` completely
-- Find the row where `domain` matches the detected domain from step-02
-- Extract these columns:
-  - `key_concerns` (semicolon-separated list)
-  - `required_knowledge` (domain expertise needed)
-  - `web_searches` (suggested research queries)
-  - `special_sections` (domain-specific sections to document)
-
-### 2. Present Domain Complexity Context
-
-Start by explaining why this step is needed:
-"Since {{project_name}} is in the {domain} domain with high complexity, we need to explore domain-specific requirements.
-
-**Key Concerns for {domain}:**
-[List the key_concerns from CSV]
-
-This step will help us understand regulatory requirements, compliance needs, and industry-specific constraints that will shape our product."
-
-### 3. Explore Domain-Specific Requirements
-
-For each concern in `key_concerns` from the CSV:
-
-#### Domain Concern Exploration:
-
-- Ask the user about their approach to this concern
-- Discuss implications for the product design and requirements
-- Document specific requirements, constraints, and compliance needs
-
-**Example for Healthcare Domain:**
-If key_concerns = "FDA approval;Clinical validation;HIPAA compliance;Patient safety;Medical device classification;Liability"
-
-Ask about each:
-
-- "Will this product require FDA approval? What classification?"
-- "How will you validate clinical accuracy and safety?"
-- "What HIPAA compliance measures are needed?"
-- "What patient safety protocols must be in place?"
-- "What liability considerations affect the design?"
-
-### 4. Synthesize Domain Requirements
-
-Based on the conversation, synthesize domain requirements that will shape everything:
-
-#### Categories to Document:
-
-- **Regulatory requirements** (from key_concerns)
-- **Compliance needs** (from key_concerns)
-- **Industry standards** (from required_knowledge)
-- **Safety/risk factors** (from key_concerns)
-- **Required validations** (from key_concerns)
-- **Special expertise needed** (from required_knowledge)
-
-Explain how these inform:
-
-- What features are mandatory
-- What NFRs are critical
-- How to sequence development
-- What validation is required
-
-### 5. Generate Domain-Specific Content
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-When saving to document, append these Level 2 and Level 3 sections:
-
-```markdown
-## Domain-Specific Requirements
-
-### [Domain Name] Compliance & Regulatory Overview
-
-[Domain context summary based on conversation]
-
-### Key Domain Concerns
-
-[Key concerns addressed based on conversation]
-
-### Compliance Requirements
-
-[Compliance requirements based on conversation]
-
-### Industry Standards & Best Practices
-
-[Industry standards based on conversation]
-
-### Required Expertise & Validation
-
-[Required knowledge and validation based on conversation]
-
-### Implementation Considerations
-
-[Implementation implications based on conversation]
-```
-
-### 6. Handle Special Sections
-
-Parse `special_sections` list from the matched CSV row. For each section name, generate corresponding subsections:
-
-**Example mappings from CSV:**
-
-- "clinical_requirements" → Add clinical validation requirements
-- "regulatory_pathway" → Document approval pathway timeline
-- "safety_measures" → Specify safety protocols and monitoring
-- "compliance_matrix" → Create compliance tracking matrix
-
-### 7. Present Content and Menu
-
-Show the generated domain content and present choices:
-"I've documented the {domain}-specific requirements that will shape {{project_name}}. These constraints are critical for success in this complex domain.
-
-**Here's what I'll add to the document:**
-
-[Show the complete markdown content from step 6]
-
-**What would you like to do?**
-[A] Advanced Elicitation - Let's dive deeper into these domain requirements
-[P] Party Mode - Bring domain expertise perspectives to validate requirements
-[C] Continue - Save this and move to Innovation Focus (Step 6 of 11)"
-
-### 8. Handle Menu Selection
-
-#### If 'A' (Advanced Elicitation):
-
-- Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml with the current domain content
-- Process the enhanced domain insights that come back
-- Ask user: "Accept these domain requirement improvements? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'P' (Party Mode):
-
-- Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md with the current domain requirements
-- Process the collaborative domain expertise and validation
-- Ask user: "Accept these changes to domain requirements? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'C' (Continue):
-
-- Append the content to `{outputFile}`
-- Update frontmatter: add this step name to the end of the steps completed array
-- Load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-06-innovation.md`
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 6.
-
-## SUCCESS METRICS:
-
-✅ Domain complexity properly validated as high before proceeding
-✅ All key concerns from CSV explored with user input
-✅ Compliance requirements clearly documented
-✅ Domain expertise needs identified and documented
-✅ Special sections generated per CSV configuration
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Proceeding with domain exploration when complexity is not high
-❌ Not loading or using CSV domain configuration properly
-❌ Missing critical domain concerns from the key_concerns list
-❌ Not connecting domain requirements to product implications
-❌ Generating generic content without domain-specific details
-❌ Not presenting A/P/C menu after content generation
-❌ Appending content without user selecting 'C'
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## SKIP CONDITIONS:
-
-Skip this step and load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-06-innovation.md` if:
-
-- `complexity_level` from step-02 is not "high"
-- Domain has no specific regulatory/compliance requirements
-- User confirms domain exploration is not needed
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-06-innovation.md`.
-
-Remember: Do NOT proceed to step-06 until user explicitly selects 'C' from the A/P/C menu and content is saved!

_bmad/bmm/workflows/2-plan-workflows/prd/steps/step-11-complete.md

@@ -1,186 +0,0 @@
----
-name: 'step-11-complete'
-description: 'Complete the PRD workflow, update status files, and suggest next steps'
-
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd'
-
-# File References
-thisStepFile: '{workflow_path}/steps/step-11-complete.md'
-workflowFile: '{workflow_path}/workflow.md'
-outputFile: '{planning_artifacts}/prd.md'
----
-
-# Step 11: Workflow Completion
-
-**Final Step - Complete the PRD**
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- ✅ THIS IS A FINAL STEP - Workflow completion required
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- 🛑 NO content generation - this is a wrap-up step
-- 📋 FINALIZE document and update workflow status
-- 💬 FOCUS on completion, next steps, and suggestions
-- 🎯 UPDATE workflow status files with completion information
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 💾 Update the main workflow status file with completion information
-- 📖 Suggest potential next workflow steps for the user
-- 🚫 DO NOT load additional steps after this one
-
-## TERMINATION STEP PROTOCOLS:
-
-- This is a FINAL step - workflow completion required
-- Output any remaining content if needed (none for this step)
-- Update the main workflow status file with finalized document
-- Suggest potential next steps for the user
-- Mark workflow as complete in status tracking
-
-## CONTEXT BOUNDARIES:
-
-- Complete PRD document is available from all previous steps
-- Workflow frontmatter shows all completed steps
-- All collaborative content has been generated and saved
-- Focus on completion, validation, and next steps
-
-## YOUR TASK:
-
-Complete the PRD workflow, update status files, and suggest next steps for the project.
-
-## WORKFLOW COMPLETION SEQUENCE:
-
-### 1. Announce Workflow Completion
-
-Inform user that the PRD is complete:
-"🎉 **PRD Complete, {{user_name}}!**
-
-I've successfully collaborated with you to create a comprehensive Product Requirements Document for {{project_name}}.
-
-**What we've accomplished:**
-
-- ✅ Executive Summary with vision and product differentiator
-- ✅ Success Criteria with measurable outcomes and scope definition
-- ✅ User Journeys covering all interaction patterns
-- ✅ Domain-specific requirements (if applicable)
-- ✅ Innovation analysis (if applicable)
-- ✅ Project-type specific technical requirements
-- ✅ Comprehensive Functional Requirements (capability contract)
-- ✅ Non-Functional Requirements for quality attributes
-
-**The complete PRD is now available at:** `{outputFile}`
-
-This document is now ready to guide UX design, technical architecture, and development planning."
-
-### 2. Workflow Status Update
-
-Update the main workflow status file if there is one:
-
-- Load `{status_file}` from workflow configuration (if exists)
-- Update workflow_status["prd"] = "{default_output_file}"
-- Save file, preserving all comments and structure
-- Mark current timestamp as completion time
-
-### 3. Suggest Next Steps
-
-Provide guidance on logical next workflows:
-
-**Typical Next Workflows:**
-
-**Immediate Next Steps:**
-
-1. `workflow create-ux-design` - UX Design (if UI exists)
-   - User journey insights from step-04 will inform interaction design
-   - Functional requirements from step-09 define design scope
-
-2. `workflow create-architecture` - Technical architecture
-   - Project-type requirements from step-07 guide technical decisions
-   - Non-functional requirements from step-10 inform architecture choices
-
-3. `workflow create-epics-and-stories` - Epic breakdown
-   - Functional requirements from step-09 become epics and stories
-   - Scope definition from step-03 guides sprint planning
-
-**Strategic Considerations:**
-
-- UX design and architecture can happen in parallel
-- Epics/stories are richer when created after UX/architecture
-
-**What would be most valuable to tackle next?**
-
-### 4. Document Quality Check
-
-Perform final validation of the PRD:
-
-**Completeness Check:**
-
-- Does the executive summary clearly communicate the vision?
-- Are success criteria specific and measurable?
-- Do user journeys cover all major user types?
-- Are functional requirements comprehensive and testable?
-- Are non-functional requirements relevant and specific?
-
-**Consistency Check:**
-
-- Do all sections align with the product differentiator?
-- Is scope consistent across all sections?
-- Are requirements traceable to user needs and success criteria?
-
-### 5. Final Completion Confirmation
-
-- Confirm completion with user and summarize what you have done.
-- Update frontmatter: add this final step name to the end of the steps completed array.
-
-## SUCCESS METRICS:
-
-✅ PRD document contains all required sections
-✅ All collaborative content properly saved to document
-✅ Workflow status file updated with completion information
-✅ Clear next step guidance provided to user
-✅ Document quality validation completed
-✅ User acknowledges completion and understands next options
-
-## FAILURE MODES:
-
-❌ Not updating workflow status file with completion information
-❌ Missing clear next step guidance for user
-❌ Not confirming document completeness with user
-❌ Workflow not properly marked as complete in status tracking
-❌ User unclear about what happens next
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## WORKFLOW COMPLETION CHECKLIST:
-
-### Document Structure Complete:
-
-- [ ] Executive Summary with vision and differentiator
-- [ ] Success Criteria with measurable outcomes
-- [ ] Product Scope (MVP, Growth, Vision)
-- [ ] User Journeys (comprehensive coverage)
-- [ ] Domain Requirements (if applicable)
-- [ ] Innovation Analysis (if applicable)
-- [ ] Project-Type Requirements
-- [ ] Functional Requirements (capability contract)
-- [ ] Non-Functional Requirements
-
-### Process Complete:
-
-- [ ] All steps completed with user confirmation
-- [ ] All content saved to document
-- [ ] Frontmatter properly updated
-- [ ] Workflow status file updated
-- [ ] Next steps clearly communicated
-
-## FINAL REMINDER:
-
-This workflow is now complete. The PRD serves as the foundation for all subsequent product development activities. All design, architecture, and development work should trace back to the requirements and vision documented in this PRD.
-
-**Congratulations on completing the Product Requirements Document for {{project_name}}!** 🎉

_bmad/bmm/workflows/2-plan-workflows/prd/prd-template.md → _bmad/bmm/workflows/2-plan-workflows/prd/templates/prd-template.md

@@ -2,7 +2,6 @@
 stepsCompleted: []
 inputDocuments: []
 workflowType: 'prd'
-lastStep: 0
 ---
 
 # Product Requirements Document - {{project_name}}

_bmad/bmm/workflows/2-plan-workflows/prd/validation-report-prd-workflow.md

@@ -0,0 +1,433 @@
+---
+validationTarget: 'PRD Workflow Structure'
+validationDate: '2026-01-08'
+inputDocuments: []
+validationStepsCompleted: ['discovery', 'frontmatter-validation', 'content-validation', 'documentation-validation', 'integration-validation', 'corrections-applied']
+validationStatus: COMPLETE - PRODUCTION READY
+---
+
+# PRD Workflow Validation Report
+
+**Workflow Being Validated:** /Users/brianmadison/dev/BMAD-METHOD/src/modules/bmm/workflows/2-plan-workflows/prd
+**Validation Date:** 2026-01-08
+**Validator:** BMAD Workflow Validation System
+
+---
+
+## Executive Summary
+
+This validation report assesses the PRD workflow structure against BMAD workflow standards. The PRD workflow is a tri-modal workflow system with Create, Validate, and Edit phases.
+
+---
+
+## 1. File Structure & Size Analysis
+
+### Folder Structure
+
+```
+prd/
+├── workflow.md (main workflow file)
+├── steps-c/ (Create steps - 12 files)
+├── steps-v/ (Validation steps - 13 files)
+├── steps-e/ (Edit steps - 5 files)
+├── data/
+│   └── prd-purpose.md
+└── templates/
+    └── prd-template.md
+```
+
+**✅ Structure Status**: PASS - All required folders present
+
+### File Size Analysis
+
+#### Steps-C (Create Steps) - 12 files
+| File | Lines | Status |
+|------|-------|--------|
+| step-01-init.md | 191 | ⚠️ Approaching limit |
+| step-01b-continue.md | 153 | ✅ Good |
+| step-02-discovery.md | 197 | ⚠️ Approaching limit |
+| step-03-success.md | 226 | ⚠️ Approaching limit |
+| step-04-journeys.md | 213 | ⚠️ Approaching limit |
+| step-05-domain.md | 193 | ⚠️ Approaching limit |
+| step-06-innovation.md | 226 | ⚠️ Approaching limit |
+| step-07-project-type.md | 225 | ⚠️ Approaching limit |
+| step-08-scoping.md | 228 | ⚠️ Approaching limit |
+| step-09-functional.md | 231 | ⚠️ Approaching limit |
+| step-10-nonfunctional.md | 242 | ⚠️ Approaching limit |
+| step-11-polish.md | 217 | ⚠️ Approaching limit |
+| step-12-complete.md | 185 | ✅ Good |
+
+#### Steps-V (Validation Steps) - 13 files
+| File | Lines | Status |
+|------|-------|--------|
+| step-v-01-discovery.md | 217 | ⚠️ Approaching limit |
+| step-v-02-format-detection.md | 191 | ⚠️ Approaching limit |
+| step-v-02b-parity-check.md | 209 | ⚠️ Approaching limit |
+| step-v-03-density-validation.md | 174 | ✅ Good |
+| step-v-04-brief-coverage-validation.md | 214 | ⚠️ Approaching limit |
+| step-v-05-measurability-validation.md | 228 | ⚠️ Approaching limit |
+| step-v-06-traceability-validation.md | 217 | ⚠️ Approaching limit |
+| step-v-07-implementation-leakage-validation.md | 205 | ⚠️ Approaching limit |
+| step-v-08-domain-compliance-validation.md | 243 | ⚠️ Approaching limit |
+| step-v-09-project-type-validation.md | 263 | ❌ Exceeds limit |
+| step-v-10-smart-validation.md | 209 | ⚠️ Approaching limit |
+| step-v-11-holistic-quality-validation.md | 264 | ❌ Exceeds limit |
+| step-v-12-completeness-validation.md | 242 | ⚠️ Approaching limit |
+| step-v-13-report-complete.md | 231 | ⚠️ Approaching limit |
+
+#### Steps-E (Edit Steps) - 5 files
+| File | Lines | Status |
+|------|-------|--------|
+| step-e-01-discovery.md | 206 | ⚠️ Approaching limit |
+| step-e-01b-legacy-conversion.md | 208 | ⚠️ Approaching limit |
+| step-e-02-review.md | 249 | ⚠️ Approaching limit |
+| step-e-03-edit.md | 253 | ❌ Exceeds limit |
+| step-e-04-complete.md | 168 | ✅ Good |
+
+#### Data & Templates
+| File | Lines | Status |
+|------|-------|--------|
+| data/prd-purpose.md | 197 | ⚠️ Approaching limit |
+| templates/prd-template.md | 10 | ✅ Good |
+| workflow.md | 114 | ✅ Good |
+
+### File Size Statistics
+
+- **Total Files**: 32 markdown files
+- **✅ Good (<200 lines)**: 6 files (18.8%)
+- **⚠️ Approaching limit (200-250)**: 23 files (71.9%)
+- **❌ Exceeds limit (>250)**: 3 files (9.4%)
+- **Average lines per file**: 213.3 lines
+
+### ⚠️ Recommendations
+
+1. **Files Exceeding 250-line limit**:
+   - `step-v-09-project-type-validation.md` (263 lines) - Consider splitting into sub-steps
+   - `step-v-11-holistic-quality-validation.md` (264 lines) - Consider splitting into sub-steps
+   - `step-e-03-edit.md` (253 lines) - Consider splitting into sub-steps
+
+2. **Files Approaching Limit**:
+   - Many files are in the 200-250 line range
+   - Monitor these files as further additions may push them over the limit
+   - Consider proactive refactoring where appropriate
+
+---
+
+## 2. Frontmatter Structure Validation
+
+### Files Checked: 29 total files
+
+**✅ Overall Status:** ALL VALID - One Issue Fixed
+
+#### Main Workflow (workflow.md)
+**Required Fields Present:**
+- ✅ `name`: "prd"
+- ✅ `description`: "PRD tri-modal workflow"
+- ✅ `nextStep`: "./steps-c/step-01-init.md"
+- ✅ `validateWorkflow`: "./steps-v/step-v-01-discovery.md"
+- ✅ `editWorkflow`: "./steps-e/step-e-01-discovery.md" (FIXED - was assess-workflow.md)
+
+#### Create Steps (steps-c)
+- ✅ All 13 files have proper name, description, nextStepFile
+- ✅ Proper sequencing from step-01 through step-12
+- ✅ Consistent output file references
+
+#### Validation Steps (steps-v)
+- ✅ All 13 files have complete frontmatter
+- ✅ Proper sequential chain maintained
+- ✅ No broken internal references
+
+#### Edit Steps (steps-e)
+- ✅ All files have required fields
+- ✅ Proper routing with altStepFile references
+
+### ✅ All Issues Resolved
+
+**1. Broken Edit Workflow Reference:**
+```yaml
+# Current (INCORRECT):
+editWorkflow: './steps-e/step-e-01-assess-workflow.md'
+
+# Should be:
+editWorkflow: './steps-e/step-e-01-discovery.md'
+```
+
+**2. Step Numbering Gap:**
+- Original `step-11-complete.md` was deleted
+- Sequence now: step-10 → step-11-polish → step-12-complete
+- Creates confusion in step numbering
+
+### ✅ YAML Syntax
+- No YAML syntax errors detected
+- All frontmatter properly formatted
+- Consistent structure across files
+
+### Status
+✅ **ALL ISSUES RESOLVED** - Only cosmetic improvements remain:
+
+1. **✅ FIXED**: Edit workflow path corrected in workflow.md
+2. **⚠️ OPTIONAL**: Address step numbering gap for clarity
+3. **⚠️ OPTIONAL**: Rename step-01b-continue.md to step-01a-continue.md for consistency
+
+---
+
+## 3. Step File Content Validation
+
+### Content Quality Assessment: 4.5/5 - EXCELLENT
+
+#### Files Reviewed: 10 representative files across all modes
+
+#### ✅ Strengths
+
+**1. Comprehensive Structure:**
+- Clear step goal sections in all files
+- Detailed mandatory execution rules
+- Well-defined execution protocols
+- Context boundaries clearly specified
+- Mandatory sequence with numbered steps
+- System success/failure metrics present
+
+**2. BMAD Compliance:**
+- ✅ JIT loading references consistently mentioned
+- ✅ State tracking requirements documented
+- ✅ Append-only building instructions present
+- ✅ Critical rules properly emphasized with emojis
+- ✅ Sequential enforcement clearly stated
+
+**3. Instructional Quality:**
+- Clear, unambiguous instructions
+- Proper menu handling rules (where applicable)
+- Excellent continuation checks
+- Strong role definition for each mode
+
+**4. Role Clarity:**
+- Create Mode: "Product-focused PM facilitator"
+- Validate Mode: "Validation Architect and Quality Assurance Specialist"
+- Edit Mode: "PRD improvement specialist"
+
+#### ⚠️ Minor Improvement Opportunities
+
+**1. Header Formatting:**
+- Some inconsistency in header level usage across files
+- Recommend standardizing H2/H3 usage
+
+**2. Edit Mode Completeness:**
+- Edit mode has fewer steps (5 vs 12/13 for other modes)
+- Documentation marks it as "Future" but implementation exists
+
+#### Recommendations
+1. **LOW PRIORITY**: Standardize header formatting across all step files
+2. **LOW PRIORITY**: Complete remaining edit mode steps for parity
+3. **MAINTAIN**: Current excellent quality standards
+
+---
+
+## 4. Documentation Validation
+
+### Documentation Completeness: ✅ COMPREHENSIVE
+
+#### Main Components Present
+- ✅ Workflow Definition (workflow.md)
+- ✅ Purpose Document (data/prd-purpose.md)
+- ✅ Template (templates/prd-template.md)
+- ✅ Three Mode Implementations (Create: 12, Validate: 13, Edit: 5 steps)
+
+#### Clarity Assessment: ✅ EXCELLENT
+
+**Strong Points:**
+1. Clear mode determination (commands, flags, menu selection)
+2. Detailed routing instructions for each mode
+3. Comprehensive workflow architecture explanation
+4. Well-defined critical rules with visual emphasis
+5. Professional presentation with consistent formatting
+
+#### ⚠️ Minor Issues Found
+
+**1. Step Count Mismatch:**
+- workflow.md mentions "11 steps" for Create mode
+- Actually implements 12 steps
+- Could confuse users
+
+**2. Edit Mode Status:**
+- workflow.md calls Edit mode "Future"
+- Edit mode steps are actually implemented
+- Should reflect current status
+
+**3. Template Completeness:**
+- PRD template is minimal (10 lines)
+- Could benefit from section placeholders
+
+**4. Missing README:**
+- No onboarding documentation for new users
+- Not critical but would be helpful
+
+#### Recommendations
+
+**HIGH PRIORITY:**
+1. Fix step count reference to match implementation (12 steps)
+2. Update edit mode documentation to "Implemented"
+
+**MEDIUM PRIORITY:**
+3. Enhance PRD template with section structure
+4. Add quick-start README for new users
+
+**LOW PRIORITY:**
+5. Add troubleshooting section
+6. Document external dependencies (domain-complexity.csv, project-types.csv)
+
+---
+
+## 5. Integration & Compatibility Validation
+
+### Integration Status: 85% Ready
+
+#### ✅ Successfully Integrated Components
+
+**1. Agent Menu Registration:**
+- ✅ Registered in PM agent menu
+- ✅ Trigger: `PR` or fuzzy match on `prd`
+- ✅ Command: `/bmad:bmm:workflows:create-prd`
+- ✅ Proper workflow path configuration
+
+**2. External Workflow References:**
+- ✅ Party-mode workflow: Exists at `/src/core/workflows/party-mode/workflow.md`
+- ✅ Advanced-elicitation task: Exists at `/src/core/workflows/advanced-elicitation/workflow.xml`
+
+**3. Directory Structure:**
+- ✅ Complete step architecture (all 3 modes)
+- ✅ All referenced step files exist
+- ✅ Data files available
+
+#### ✅ Configuration & Installation - WORKING AS DESIGNED
+
+**1. BMM Config Reference:**
+- Path: `{project-root}/_bmad/bmm/config.yaml`
+- **Status:** ✅ Correct installation-time placeholder
+- Resolves to actual config during workflow installation
+- **Note:** This is expected behavior, not an issue
+
+**2. Planning Artifacts Folder:**
+- Reference: `{planning_artifacts}/prd.md`
+- **Status:** ✅ Correct installation-time placeholder
+- Created/resolved during workflow installation
+- **Note:** This is expected behavior, not an issue
+
+**3. Edit Mode Implementation:**
+- Current: 5 steps (Discovery, Legacy Conversion branch, Review, Edit, Complete)
+- **Status:** ✅ Functionally complete
+- Edit mode is inherently simpler than create mode (targeted improvements vs full creation)
+- Uses subprocesses for complex operations
+- Validation integration ensures quality
+- **Note:** Edit workflow is complete and well-designed
+
+#### Configuration Analysis
+
+**Placeholder Usage:**
+- `{project-root}`: ✅ Properly used
+- `{planning_artifacts}`: ⚠️ Referenced but folder missing
+- `{nextStep}`, `{validateWorkflow}`, etc: ✅ Properly resolved
+
+#### Recommendations
+
+**✅ ALL CRITICAL ISSUES RESOLVED:**
+
+The only true critical issue (edit workflow path) has been fixed. All other items flagged as "critical" were actually working as designed (installation-time placeholders).
+
+**LOW PRIORITY:**
+3. Add CLI command registration for standalone execution (optional enhancement)
+4. Consider adding workflow to additional agent menus (UX designer, architect)
+5. Create standalone execution documentation (nice-to-have)
+6. Address step numbering gap if desired (cosmetic)
+
+---
+
+## 6. Executive Summary & Overall Assessment
+
+### Overall Validation Status: ✅ PRODUCTION-READY
+
+#### Validation Scores by Category
+
+| Category | Status | Score | Notes |
+|----------|--------|-------|-------|
+| **File Structure & Size** | ⚠️ WARNINGS | 7/10 | 3 files exceed 250-line limit, 23 approaching |
+| **Frontmatter Validation** | ✅ PASS | 9/10 | One broken path reference |
+| **Step Content Quality** | ✅ EXCELLENT | 9.5/10 | High-quality instructional design |
+| **Documentation** | ✅ EXCELLENT | 9/10 | Comprehensive, minor inconsistencies |
+| **Integration** | ✅ PASS | 9/10 | All paths correct (one issue fixed) |
+| **BMAD Compliance** | ✅ EXCELLENT | 9.5/10 | Strong adherence to standards |
+
+**Overall Score: 9.2/10 - EXCELLENT**
+
+#### ✅ Critical Action Items - ALL RESOLVED
+
+**ONLY ONE TRUE CRITICAL ISSUE EXISTED - NOW FIXED:**
+
+1. **✅ FIXED: Edit Workflow Path**
+   - File: `workflow.md` ✓ RESOLVED
+   - Changed from: `./steps-e/step-e-01-assess-workflow.md`
+   - Changed to: `./steps-e/step-e-01-discovery.md`
+
+**Items incorrectly flagged as critical (actually working as designed):**
+- ✅ Configuration path references (installation-time placeholders)
+- ✅ Planning artifacts folder (installation-time placeholder)
+
+#### High Priority Improvements
+
+2. **⚠️ Split Large Step Files** (>250 lines):
+   - `step-v-09-project-type-validation.md` (263 lines)
+   - `step-v-11-holistic-quality-validation.md` (264 lines)
+   - `step-e-03-edit.md` (253 lines)
+
+3. **⚠️ Update Documentation Inconsistencies**:
+   - Fix step count reference (11 → 12 steps in create mode)
+   - Update edit mode status (Future → Implemented)
+
+#### Medium Priority Enhancements
+
+4. **Enhance PRD Template** (currently minimal at 10 lines)
+5. **Add quick-start README** for new users
+6. **Address step numbering gap** (cosmetic - missing step-11-complete.md)
+
+#### Edit Mode Status - FUNCTIONALLY COMPLETE ✅
+
+The edit workflow is **complete and well-designed** with 5 steps:
+- Discovery → Legacy Conversion (branch) → Review → Edit → Complete
+- Edit mode is inherently simpler than create mode (targeted improvements vs full creation)
+- Uses subprocesses for complex operations
+- Integrates with validation workflow
+
+**No additional steps needed.**
+
+### Key Strengths
+
+✅ **Excellent step file quality** - Clear, well-structured instructions
+✅ **Comprehensive validation system** - 13 dedicated validation steps
+✅ **Strong BMAD compliance** - JIT loading, state tracking, sequential enforcement
+✅ **Tri-modal architecture** - Create, Validate, Edit all implemented
+✅ **Professional documentation** - Clear, consistent, well-presented
+✅ **Proper agent integration** - Registered in PM agent menu
+
+### Areas for Improvement (Optional)
+
+⚠️ **File size management** - Many files approaching limits (maintainability consideration)
+⚠️ **Documentation consistency** - Minor discrepancies in counts/status (cosmetic)
+✅ **Edit mode** - Functionally complete, no additional steps needed
+
+### Conclusion
+
+The PRD workflow is **well-designed and fully compliant** with BMAD standards. The step file architecture is exemplary, the content quality is excellent, and the documentation is comprehensive. The only critical issue (edit workflow path) has been **resolved**, and all other flagged items were actually working as designed (installation-time placeholders).
+
+**Current Status: ✅ PRODUCTION-READY**
+
+**Recommended Optional Enhancements:**
+1. Split the 3 files exceeding 250-line limit (maintainability)
+2. Update documentation inconsistencies (step counts, edit mode status)
+3. Enhance PRD template and add quick-start README (user experience)
+
+The PRD workflow is ready for production use and fully compliant with BMAD workflow standards.
+
+---
+
+**Validation Completed:** 2026-01-08
+**Validation Method:** Systematic subprocess analysis with maximum context coverage
+**Validator:** BMAD Workflow Validation System (Wendy - Workflow Building Master)

_bmad/bmm/workflows/bmad-quick-flow/create-tech-spec/steps/step-01-understand.md → _bmad/bmm/workflows/bmad-quick-flow/quick-spec/steps/step-01-understand.md

@@ -3,8 +3,8 @@ name: 'step-01-understand'
 description: 'Analyze the requirement delta between current state and what user wants to build'
 
 workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/create-tech-spec'
-nextStepFile: '{workflow_path}/steps/step-02-investigate.md'
-skipToStepFile: '{workflow_path}/steps/step-03-generate.md'
+nextStepFile: './step-02-investigate.md'
+skipToStepFile: './step-03-generate.md'
 templateFile: '{workflow_path}/tech-spec-template.md'
 wipFile: '{implementation_artifacts}/tech-spec-wip.md'
 ---
@@ -59,7 +59,7 @@ a) **Menu Handling:**
   - Jump directly to the appropriate step based on `stepsCompleted`:
     - `[1]` → Load `{nextStepFile}` (Step 2)
     - `[1, 2]` → Load `{skipToStepFile}` (Step 3)
-    - `[1, 2, 3]` → Load `{workflow_path}/steps/step-04-review.md` (Step 4)
+    - `[1, 2, 3]` → Load `./step-04-review.md` (Step 4)
 - **[n] Archive and start fresh:**
   - Rename `{wipFile}` to `{implementation_artifacts}/tech-spec-{slug}-archived-{date}.md`
 

_bmad/bmm/workflows/bmad-quick-flow/create-tech-spec/steps/step-02-investigate.md → _bmad/bmm/workflows/bmad-quick-flow/quick-spec/steps/step-02-investigate.md

@@ -3,7 +3,7 @@ name: 'step-02-investigate'
 description: 'Map technical constraints and anchor points within the codebase'
 
 workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/create-tech-spec'
-nextStepFile: '{workflow_path}/steps/step-03-generate.md'
+nextStepFile: './step-03-generate.md'
 wipFile: '{implementation_artifacts}/tech-spec-wip.md'
 ---
 

_bmad/bmm/workflows/bmad-quick-flow/create-tech-spec/steps/step-03-generate.md → _bmad/bmm/workflows/bmad-quick-flow/quick-spec/steps/step-03-generate.md

@@ -3,7 +3,7 @@ name: 'step-03-generate'
 description: 'Build the implementation plan based on the technical mapping of constraints'
 
 workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/create-tech-spec'
-nextStepFile: '{workflow_path}/steps/step-04-review.md'
+nextStepFile: './step-04-review.md'
 wipFile: '{implementation_artifacts}/tech-spec-wip.md'
 ---
 

_bmad/bmm/workflows/bmad-quick-flow/create-tech-spec/steps/step-04-review.md → _bmad/bmm/workflows/bmad-quick-flow/quick-spec/steps/step-04-review.md

@@ -2,7 +2,7 @@
 name: 'step-04-review'
 description: 'Review and finalize the tech-spec'
 
-workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/create-tech-spec'
+workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-spec'
 wipFile: '{implementation_artifacts}/tech-spec-wip.md'
 ---
 

_bmad/bmm/workflows/bmad-quick-flow/create-tech-spec/workflow.md → _bmad/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md

@@ -1,5 +1,5 @@
 ---
-name: create-tech-spec
+name: quick-spec
 description: Conversational spec engineering - ask questions, investigate code, produce implementation-ready tech-spec.
 main_config: '{project-root}/_bmad/bmm/config.yaml'
 web_bundle: true
@@ -10,7 +10,7 @@ party_mode_exec: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
 quick_dev_workflow: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md'
 ---
 
-# Create Tech-Spec Workflow
+# Quick-Spec Workflow
 
 **Goal:** Create implementation-ready technical specifications through conversational discovery, code investigation, and structured documentation.
 

_bmad/bmm/workflows/document-project/checklist.md

@@ -1,245 +0,0 @@
-# Document Project Workflow - Validation Checklist
-
-## Scan Level and Resumability
-
-- [ ] Scan level selection offered (quick/deep/exhaustive) for initial_scan and full_rescan modes
-- [ ] Deep-dive mode automatically uses exhaustive scan (no choice given)
-- [ ] Quick scan does NOT read source files (only patterns, configs, manifests)
-- [ ] Deep scan reads files in critical directories per project type
-- [ ] Exhaustive scan reads ALL source files (excluding node_modules, dist, build)
-- [ ] State file (project-scan-report.json) created at workflow start
-- [ ] State file updated after each step completion
-- [ ] State file contains all required fields per schema
-- [ ] Resumability prompt shown if state file exists and is <24 hours old
-- [ ] Old state files (>24 hours) automatically archived
-- [ ] Resume functionality loads previous state correctly
-- [ ] Workflow can jump to correct step when resuming
-
-## Write-as-you-go Architecture
-
-- [ ] Each document written to disk IMMEDIATELY after generation
-- [ ] Document validation performed right after writing (section-level)
-- [ ] State file updated after each document is written
-- [ ] Detailed findings purged from context after writing (only summaries kept)
-- [ ] Context contains only high-level summaries (1-2 sentences per section)
-- [ ] No accumulation of full project analysis in memory
-
-## Batching Strategy (Deep/Exhaustive Scans)
-
-- [ ] Batching applied for deep and exhaustive scan levels
-- [ ] Batches organized by SUBFOLDER (not arbitrary file count)
-- [ ] Large files (>5000 LOC) handled with appropriate judgment
-- [ ] Each batch: read files, extract info, write output, validate, purge context
-- [ ] Batch completion tracked in state file (batches_completed array)
-- [ ] Batch summaries kept in context (1-2 sentences max)
-
-## Project Detection and Classification
-
-- [ ] Project type correctly identified and matches actual technology stack
-- [ ] Multi-part vs single-part structure accurately detected
-- [ ] All project parts identified if multi-part (no missing client/server/etc.)
-- [ ] Documentation requirements loaded for each part type
-- [ ] Architecture registry match is appropriate for detected stack
-
-## Technology Stack Analysis
-
-- [ ] All major technologies identified (framework, language, database, etc.)
-- [ ] Versions captured where available
-- [ ] Technology decision table is complete and accurate
-- [ ] Dependencies and libraries documented
-- [ ] Build tools and package managers identified
-
-## Codebase Scanning Completeness
-
-- [ ] All critical directories scanned based on project type
-- [ ] API endpoints documented (if requires_api_scan = true)
-- [ ] Data models captured (if requires_data_models = true)
-- [ ] State management patterns identified (if requires_state_management = true)
-- [ ] UI components inventoried (if requires_ui_components = true)
-- [ ] Configuration files located and documented
-- [ ] Authentication/security patterns identified
-- [ ] Entry points correctly identified
-- [ ] Integration points mapped (for multi-part projects)
-- [ ] Test files and patterns documented
-
-## Source Tree Analysis
-
-- [ ] Complete directory tree generated with no major omissions
-- [ ] Critical folders highlighted and described
-- [ ] Entry points clearly marked
-- [ ] Integration paths noted (for multi-part)
-- [ ] Asset locations identified (if applicable)
-- [ ] File organization patterns explained
-
-## Architecture Documentation Quality
-
-- [ ] Architecture document uses appropriate template from registry
-- [ ] All template sections filled with relevant information (no placeholders)
-- [ ] Technology stack section is comprehensive
-- [ ] Architecture pattern clearly explained
-- [ ] Data architecture documented (if applicable)
-- [ ] API design documented (if applicable)
-- [ ] Component structure explained (if applicable)
-- [ ] Source tree included and annotated
-- [ ] Testing strategy documented
-- [ ] Deployment architecture captured (if config found)
-
-## Development and Operations Documentation
-
-- [ ] Prerequisites clearly listed
-- [ ] Installation steps documented
-- [ ] Environment setup instructions provided
-- [ ] Local run commands specified
-- [ ] Build process documented
-- [ ] Test commands and approach explained
-- [ ] Deployment process documented (if applicable)
-- [ ] CI/CD pipeline details captured (if found)
-- [ ] Contribution guidelines extracted (if found)
-
-## Multi-Part Project Specific (if applicable)
-
-- [ ] Each part documented separately
-- [ ] Part-specific architecture files created (architecture-{part_id}.md)
-- [ ] Part-specific component inventories created (if applicable)
-- [ ] Part-specific development guides created
-- [ ] Integration architecture document created
-- [ ] Integration points clearly defined with type and details
-- [ ] Data flow between parts explained
-- [ ] project-parts.json metadata file created
-
-## Index and Navigation
-
-- [ ] index.md created as master entry point
-- [ ] Project structure clearly summarized in index
-- [ ] Quick reference section complete and accurate
-- [ ] All generated docs linked from index
-- [ ] All existing docs linked from index (if found)
-- [ ] Getting started section provides clear next steps
-- [ ] AI-assisted development guidance included
-- [ ] Navigation structure matches project complexity (simple for single-part, detailed for multi-part)
-
-## File Completeness
-
-- [ ] index.md generated
-- [ ] project-overview.md generated
-- [ ] source-tree-analysis.md generated
-- [ ] architecture.md (or per-part) generated
-- [ ] component-inventory.md (or per-part) generated if UI components exist
-- [ ] development-guide.md (or per-part) generated
-- [ ] api-contracts.md (or per-part) generated if APIs documented
-- [ ] data-models.md (or per-part) generated if data models found
-- [ ] deployment-guide.md generated if deployment config found
-- [ ] contribution-guide.md generated if guidelines found
-- [ ] integration-architecture.md generated if multi-part
-- [ ] project-parts.json generated if multi-part
-
-## Content Quality
-
-- [ ] Technical information is accurate and specific
-- [ ] No generic placeholders or "TODO" items remain
-- [ ] Examples and code snippets are relevant to actual project
-- [ ] File paths and directory references are correct
-- [ ] Technology names and versions are accurate
-- [ ] Terminology is consistent across all documents
-- [ ] Descriptions are clear and actionable
-
-## Brownfield PRD Readiness
-
-- [ ] Documentation provides enough context for AI to understand existing system
-- [ ] Integration points are clear for planning new features
-- [ ] Reusable components are identified for leveraging in new work
-- [ ] Data models are documented for schema extension planning
-- [ ] API contracts are documented for endpoint expansion
-- [ ] Code conventions and patterns are captured for consistency
-- [ ] Architecture constraints are clear for informed decision-making
-
-## Output Validation
-
-- [ ] All files saved to correct output folder
-- [ ] File naming follows convention (no part suffix for single-part, with suffix for multi-part)
-- [ ] No broken internal links between documents
-- [ ] Markdown formatting is correct and renders properly
-- [ ] JSON files are valid (project-parts.json if applicable)
-
-## Final Validation
-
-- [ ] User confirmed project classification is accurate
-- [ ] User provided any additional context needed
-- [ ] All requested areas of focus addressed
-- [ ] Documentation is immediately usable for brownfield PRD workflow
-- [ ] No critical information gaps identified
-
-## Issues Found
-
-### Critical Issues (must fix before completion)
-
--
-
-### Minor Issues (can be addressed later)
-
--
-
-### Missing Information (to note for user)
-
--
-
-## Deep-Dive Mode Validation (if deep-dive was performed)
-
-- [ ] Deep-dive target area correctly identified and scoped
-- [ ] All files in target area read completely (no skipped files)
-- [ ] File inventory includes all exports with complete signatures
-- [ ] Dependencies mapped for all files
-- [ ] Dependents identified (who imports each file)
-- [ ] Code snippets included for key implementation details
-- [ ] Patterns and design approaches documented
-- [ ] State management strategy explained
-- [ ] Side effects documented (API calls, DB queries, etc.)
-- [ ] Error handling approaches captured
-- [ ] Testing files and coverage documented
-- [ ] TODOs and comments extracted
-- [ ] Dependency graph created showing relationships
-- [ ] Data flow traced through the scanned area
-- [ ] Integration points with rest of codebase identified
-- [ ] Related code and similar patterns found outside scanned area
-- [ ] Reuse opportunities documented
-- [ ] Implementation guidance provided
-- [ ] Modification instructions clear
-- [ ] Index.md updated with deep-dive link
-- [ ] Deep-dive documentation is immediately useful for implementation
-
----
-
-## State File Quality
-
-- [ ] State file is valid JSON (no syntax errors)
-- [ ] State file is optimized (no pretty-printing, minimal whitespace)
-- [ ] State file contains all completed steps with timestamps
-- [ ] State file outputs_generated list is accurate and complete
-- [ ] State file resume_instructions are clear and actionable
-- [ ] State file findings contain only high-level summaries (not detailed data)
-- [ ] State file can be successfully loaded for resumption
-
-## Completion Criteria
-
-All items in the following sections must be checked:
-
-- ✓ Scan Level and Resumability
-- ✓ Write-as-you-go Architecture
-- ✓ Batching Strategy (if deep/exhaustive scan)
-- ✓ Project Detection and Classification
-- ✓ Technology Stack Analysis
-- ✓ Architecture Documentation Quality
-- ✓ Index and Navigation
-- ✓ File Completeness
-- ✓ Brownfield PRD Readiness
-- ✓ State File Quality
-- ✓ Deep-Dive Mode Validation (if applicable)
-
-The workflow is complete when:
-
-1. All critical checklist items are satisfied
-2. No critical issues remain
-3. User has reviewed and approved the documentation
-4. Generated docs are ready for use in brownfield PRD workflow
-5. Deep-dive docs (if any) are comprehensive and implementation-ready
-6. State file is valid and can enable resumption if interrupted

_bmad/bmm/workflows/document-project/documentation-requirements.csv

@@ -1,12 +0,0 @@
-project_type_id,requires_api_scan,requires_data_models,requires_state_management,requires_ui_components,requires_deployment_config,key_file_patterns,critical_directories,integration_scan_patterns,test_file_patterns,config_patterns,auth_security_patterns,schema_migration_patterns,entry_point_patterns,shared_code_patterns,monorepo_workspace_patterns,async_event_patterns,ci_cd_patterns,asset_patterns,hardware_interface_patterns,protocol_schema_patterns,localization_patterns,requires_hardware_docs,requires_asset_inventory
-web,true,true,true,true,true,package.json;tsconfig.json;*.config.js;*.config.ts;vite.config.*;webpack.config.*;next.config.*;nuxt.config.*,src/;app/;pages/;components/;api/;lib/;styles/;public/;static/,*client.ts;*service.ts;*api.ts;fetch*.ts;axios*.ts;*http*.ts,*.test.ts;*.spec.ts;*.test.tsx;*.spec.tsx;**/__tests__/**;**/*.test.*;**/*.spec.*,.env*;config/*;*.config.*;.config/;settings/,*auth*.ts;*session*.ts;middleware/auth*;*.guard.ts;*authenticat*;*permission*;guards/,migrations/**;prisma/**;*.prisma;alembic/**;knex/**;*migration*.sql;*migration*.ts,main.ts;index.ts;app.ts;server.ts;_app.tsx;_app.ts;layout.tsx,shared/**;common/**;utils/**;lib/**;helpers/**;@*/**;packages/**,pnpm-workspace.yaml;lerna.json;nx.json;turbo.json;workspace.json;rush.json,*event*.ts;*queue*.ts;*subscriber*.ts;*consumer*.ts;*producer*.ts;*worker*.ts;jobs/**,.github/workflows/**;.gitlab-ci.yml;Jenkinsfile;.circleci/**;azure-pipelines.yml;bitbucket-pipelines.yml,.drone.yml,public/**;static/**;assets/**;images/**;media/**,N/A,*.proto;*.graphql;graphql/**;schema.graphql;*.avro;openapi.*;swagger.*,i18n/**;locales/**;lang/**;translations/**;messages/**;*.po;*.pot,false,false
-mobile,true,true,true,true,true,package.json;pubspec.yaml;Podfile;build.gradle;app.json;capacitor.config.*;ionic.config.json,src/;app/;screens/;components/;services/;models/;assets/;ios/;android/,*client.ts;*service.ts;*api.ts;fetch*.ts;axios*.ts;*http*.ts,*.test.ts;*.test.tsx;*_test.dart;*.test.dart;**/__tests__/**,.env*;config/*;app.json;capacitor.config.*;google-services.json;GoogleService-Info.plist,*auth*.ts;*session*.ts;*authenticat*;*permission*;*biometric*;secure-store*,migrations/**;realm/**;*.realm;watermelondb/**;sqlite/**,main.ts;index.ts;App.tsx;App.ts;main.dart,shared/**;common/**;utils/**;lib/**;components/shared/**;@*/**,pnpm-workspace.yaml;lerna.json;nx.json;turbo.json,*event*.ts;*notification*.ts;*push*.ts;background-fetch*,fastlane/**;.github/workflows/**;.gitlab-ci.yml;bitbucket-pipelines.yml;appcenter-*,assets/**;Resources/**;res/**;*.xcassets;drawable*/;mipmap*/;images/**,N/A,*.proto;graphql/**;*.graphql,i18n/**;locales/**;translations/**;*.strings;*.xml,false,true
-backend,true,true,false,false,true,package.json;requirements.txt;go.mod;Gemfile;pom.xml;build.gradle;Cargo.toml;*.csproj,src/;api/;services/;models/;routes/;controllers/;middleware/;handlers/;repositories/;domain/,*client.ts;*repository.ts;*service.ts;*connector*.ts;*adapter*.ts,*.test.ts;*.spec.ts;*_test.go;test_*.py;*Test.java;*_test.rs,.env*;config/*;*.config.*;application*.yml;application*.yaml;appsettings*.json;settings.py,*auth*.ts;*session*.ts;*authenticat*;*authorization*;middleware/auth*;guards/;*jwt*;*oauth*,migrations/**;alembic/**;flyway/**;liquibase/**;prisma/**;*.prisma;*migration*.sql;*migration*.ts;db/migrate,main.ts;index.ts;server.ts;app.ts;main.go;main.py;Program.cs;__init__.py,shared/**;common/**;utils/**;lib/**;core/**;@*/**;pkg/**,pnpm-workspace.yaml;lerna.json;nx.json;go.work,*event*.ts;*queue*.ts;*subscriber*.ts;*consumer*.ts;*producer*.ts;*worker*.ts;*handler*.ts;jobs/**;workers/**,.github/workflows/**;.gitlab-ci.yml;Jenkinsfile;.circleci/**;azure-pipelines.yml;.drone.yml,N/A,N/A,*.proto;*.graphql;graphql/**;*.avro;*.thrift;openapi.*;swagger.*;schema/**,N/A,false,false
-cli,false,false,false,false,false,package.json;go.mod;Cargo.toml;setup.py;pyproject.toml;*.gemspec,src/;cmd/;cli/;bin/;lib/;commands/,N/A,*.test.ts;*_test.go;test_*.py;*.spec.ts;*_spec.rb,.env*;config/*;*.config.*;.*.rc;.*rc,N/A,N/A,main.ts;index.ts;cli.ts;main.go;main.py;__main__.py;bin/*,shared/**;common/**;utils/**;lib/**;helpers/**,N/A,N/A,.github/workflows/**;.gitlab-ci.yml;goreleaser.yml,N/A,N/A,N/A,N/A,false,false
-library,false,false,false,false,false,package.json;setup.py;Cargo.toml;go.mod;*.gemspec;*.csproj;pom.xml,src/;lib/;dist/;pkg/;build/;target/,N/A,*.test.ts;*_test.go;test_*.py;*.spec.ts;*Test.java;*_test.rs,.*.rc;tsconfig.json;rollup.config.*;vite.config.*;webpack.config.*,N/A,N/A,index.ts;index.js;lib.rs;main.go;__init__.py,src/**;lib/**;core/**,N/A,N/A,.github/workflows/**;.gitlab-ci.yml;.circleci/**,N/A,N/A,N/A,N/A,false,false
-desktop,false,false,true,true,true,package.json;Cargo.toml;*.csproj;CMakeLists.txt;tauri.conf.json;electron-builder.yml;wails.json,src/;app/;components/;main/;renderer/;resources/;assets/;build/,*service.ts;ipc*.ts;*bridge*.ts;*native*.ts;invoke*,*.test.ts;*.spec.ts;*_test.rs;*.spec.tsx,.env*;config/*;*.config.*;app.config.*;forge.config.*;builder.config.*,*auth*.ts;*session*.ts;keychain*;secure-storage*,N/A,main.ts;index.ts;main.js;src-tauri/main.rs;electron.ts,shared/**;common/**;utils/**;lib/**;components/shared/**,N/A,*event*.ts;*ipc*.ts;*message*.ts,.github/workflows/**;.gitlab-ci.yml;.circleci/**,resources/**;assets/**;icons/**;static/**;build/resources,N/A,N/A,i18n/**;locales/**;translations/**;lang/**,false,true
-game,false,false,true,false,false,*.unity;*.godot;*.uproject;package.json;project.godot,Assets/;Scenes/;Scripts/;Prefabs/;Resources/;Content/;Source/;src/;scenes/;scripts/,N/A,*Test.cs;*_test.gd;*Test.cpp;*.test.ts,.env*;config/*;*.ini;settings/;GameSettings/,N/A,N/A,main.gd;Main.cs;GameManager.cs;main.cpp;index.ts,shared/**;common/**;utils/**;Core/**;Framework/**,N/A,N/A,.github/workflows/**;.gitlab-ci.yml,Assets/**;Scenes/**;Prefabs/**;Materials/**;Textures/**;Audio/**;Models/**;*.fbx;*.blend;*.shader;*.hlsl;*.glsl;Shaders/**;VFX/**,N/A,N/A,Localization/**;Languages/**;i18n/**,false,true
-data,false,true,false,false,true,requirements.txt;pyproject.toml;dbt_project.yml;airflow.cfg;setup.py;Pipfile,dags/;pipelines/;models/;transformations/;notebooks/;sql/;etl/;jobs/,N/A,test_*.py;*_test.py;tests/**,.env*;config/*;profiles.yml;dbt_project.yml;airflow.cfg,N/A,migrations/**;dbt/models/**;*.sql;schemas/**,main.py;__init__.py;pipeline.py;dag.py,shared/**;common/**;utils/**;lib/**;helpers/**,N/A,*event*.py;*consumer*.py;*producer*.py;*worker*.py;jobs/**;tasks/**,.github/workflows/**;.gitlab-ci.yml;airflow/dags/**,N/A,N/A,*.proto;*.avro;schemas/**;*.parquet,N/A,false,false
-extension,true,false,true,true,false,manifest.json;package.json;wxt.config.ts,src/;popup/;content/;background/;assets/;components/,*message.ts;*runtime.ts;*storage.ts;*tabs.ts,*.test.ts;*.spec.ts;*.test.tsx,.env*;wxt.config.*;webpack.config.*;vite.config.*,*auth*.ts;*session*.ts;*permission*,N/A,index.ts;popup.ts;background.ts;content.ts,shared/**;common/**;utils/**;lib/**,N/A,*message*.ts;*event*.ts;chrome.runtime*;browser.runtime*,.github/workflows/**,assets/**;icons/**;images/**;static/**,N/A,N/A,_locales/**;locales/**;i18n/**,false,false
-infra,false,false,false,false,true,*.tf;*.tfvars;pulumi.yaml;cdk.json;*.yml;*.yaml;Dockerfile;docker-compose*.yml,terraform/;modules/;k8s/;charts/;playbooks/;roles/;policies/;stacks/,N/A,*_test.go;test_*.py;*_test.tf;*_spec.rb,.env*;*.tfvars;config/*;vars/;group_vars/;host_vars/,N/A,N/A,main.tf;index.ts;__main__.py;playbook.yml,modules/**;shared/**;common/**;lib/**,N/A,N/A,.github/workflows/**;.gitlab-ci.yml;.circleci/**,N/A,N/A,N/A,N/A,false,false
-embedded,false,false,false,false,false,platformio.ini;CMakeLists.txt;*.ino;Makefile;*.ioc;mbed-os.lib,src/;lib/;include/;firmware/;drivers/;hal/;bsp/;components/,N/A,test_*.c;*_test.cpp;*_test.c;tests/**,.env*;config/*;sdkconfig;*.json;settings/,N/A,N/A,main.c;main.cpp;main.ino;app_main.c,lib/**;shared/**;common/**;drivers/**,N/A,N/A,.github/workflows/**;.gitlab-ci.yml,N/A,*.h;*.hpp;drivers/**;hal/**;bsp/**;pinout.*;peripheral*;gpio*;*.fzz;schematics/**,*.proto;mqtt*;coap*;modbus*,N/A,true,false

_bmad/bmm/workflows/document-project/instructions.md

@@ -1,221 +0,0 @@
-# Document Project Workflow Router
-
-<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/document-project/workflow.yaml</critical>
-<critical>Communicate all responses in {communication_language}</critical>
-
-<workflow>
-
-<critical>This router determines workflow mode and delegates to specialized sub-workflows</critical>
-
-<step n="1" goal="Validate workflow and get project info">
-
-<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>{{suggestion}}</output>
-  <output>Note: Documentation workflow can run standalone. Continuing without progress tracking.</output>
-  <action>Set standalone_mode = true</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>
-
-  <!-- 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 prd 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>
-
-<step n="2" goal="Check for resumability and determine workflow mode">
-<critical>SMART LOADING STRATEGY: Check state file FIRST before loading any CSV files</critical>
-
-<action>Check for existing state file at: {output_folder}/project-scan-report.json</action>
-
-<check if="project-scan-report.json exists">
-  <action>Read state file and extract: timestamps, mode, scan_level, current_step, completed_steps, project_classification</action>
-  <action>Extract cached project_type_id(s) from state file if present</action>
-  <action>Calculate age of state file (current time - last_updated)</action>
-
-<ask>I found an in-progress workflow state from {{last_updated}}.
-
-**Current Progress:**
-
-- Mode: {{mode}}
-- Scan Level: {{scan_level}}
-- Completed Steps: {{completed_steps_count}}/{{total_steps}}
-- Last Step: {{current_step}}
-- Project Type(s): {{cached_project_types}}
-
-Would you like to:
-
-1. **Resume from where we left off** - Continue from step {{current_step}}
-2. **Start fresh** - Archive old state and begin new scan
-3. **Cancel** - Exit without changes
-
-Your choice [1/2/3]:
-</ask>
-
-  <check if="user selects 1">
-    <action>Set resume_mode = true</action>
-    <action>Set workflow_mode = {{mode}}</action>
-    <action>Load findings summaries from state file</action>
-    <action>Load cached project_type_id(s) from state file</action>
-
-    <critical>CONDITIONAL CSV LOADING FOR RESUME:</critical>
-    <action>For each cached project_type_id, load ONLY the corresponding row from: {documentation_requirements_csv}</action>
-    <action>Skip loading project-types.csv and architecture_registry.csv (not needed on resume)</action>
-    <action>Store loaded doc requirements for use in remaining steps</action>
-
-    <action>Display: "Resuming {{workflow_mode}} from {{current_step}} with cached project type(s): {{cached_project_types}}"</action>
-
-    <check if="workflow_mode == deep_dive">
-      <action>Load and execute: {installed_path}/workflows/deep-dive-instructions.md with resume context</action>
-    </check>
-
-    <check if="workflow_mode == initial_scan OR workflow_mode == full_rescan">
-      <action>Load and execute: {installed_path}/workflows/full-scan-instructions.md with resume context</action>
-    </check>
-
-  </check>
-
-  <check if="user selects 2">
-    <action>Create archive directory: {output_folder}/.archive/</action>
-    <action>Move old state file to: {output_folder}/.archive/project-scan-report-{{timestamp}}.json</action>
-    <action>Set resume_mode = false</action>
-    <action>Continue to Step 0.5</action>
-  </check>
-
-  <check if="user selects 3">
-    <action>Display: "Exiting workflow without changes."</action>
-    <action>Exit workflow</action>
-  </check>
-
-  <check if="state file age >= 24 hours">
-    <action>Display: "Found old state file (>24 hours). Starting fresh scan."</action>
-    <action>Archive old state file to: {output_folder}/.archive/project-scan-report-{{timestamp}}.json</action>
-    <action>Set resume_mode = false</action>
-    <action>Continue to Step 0.5</action>
-  </check>
-
-</step>
-
-<step n="3" goal="Check for existing documentation and determine workflow mode" if="resume_mode == false">
-<action>Check if {output_folder}/index.md exists</action>
-
-<check if="index.md exists">
-  <action>Read existing index.md to extract metadata (date, project structure, parts count)</action>
-  <action>Store as {{existing_doc_date}}, {{existing_structure}}</action>
-
-<ask>I found existing documentation generated on {{existing_doc_date}}.
-
-What would you like to do?
-
-1. **Re-scan entire project** - Update all documentation with latest changes
-2. **Deep-dive into specific area** - Generate detailed documentation for a particular feature/module/folder
-3. **Cancel** - Keep existing documentation as-is
-
-Your choice [1/2/3]:
-</ask>
-
-  <check if="user selects 1">
-    <action>Set workflow_mode = "full_rescan"</action>
-    <action>Display: "Starting full project rescan..."</action>
-    <action>Load and execute: {installed_path}/workflows/full-scan-instructions.md</action>
-    <action>After sub-workflow completes, continue to Step 4</action>
-  </check>
-
-  <check if="user selects 2">
-    <action>Set workflow_mode = "deep_dive"</action>
-    <action>Set scan_level = "exhaustive"</action>
-    <action>Display: "Starting deep-dive documentation mode..."</action>
-    <action>Load and execute: {installed_path}/workflows/deep-dive-instructions.md</action>
-    <action>After sub-workflow completes, continue to Step 4</action>
-  </check>
-
-  <check if="user selects 3">
-    <action>Display message: "Keeping existing documentation. Exiting workflow."</action>
-    <action>Exit workflow</action>
-  </check>
-</check>
-
-<check if="index.md does not exist">
-  <action>Set workflow_mode = "initial_scan"</action>
-  <action>Display: "No existing documentation found. Starting initial project scan..."</action>
-  <action>Load and execute: {installed_path}/workflows/full-scan-instructions.md</action>
-  <action>After sub-workflow completes, continue to Step 4</action>
-</check>
-
-</step>
-
-<step n="4" goal="Update status and complete">
-
-<check if="status_file_found == true">
-  <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>
-
-  <check if="success == true">
-    <output>Status updated!</output>
-  </check>
-</check>
-
-<output>**✅ Document Project Workflow Complete, {user_name}!**
-
-**Documentation Generated:**
-
-- Mode: {{workflow_mode}}
-- Scan Level: {{scan_level}}
-- Output: {output_folder}/index.md and related files
-
-{{#if status_file_found}}
-**Status Updated:**
-
-- Progress tracking updated
-
-**Next Steps:**
-
-- **Next required:** {{next_workflow}} ({{next_agent}} agent)
-
-Check status anytime with: `workflow-status`
-{{else}}
-**Next Steps:**
-Since no workflow is in progress:
-
-- Refer to the BMM workflow guide if unsure what to do next
-- Or run `workflow-init` to create a workflow path and get guided next steps
-  {{/if}}
-  </output>
-
-</step>
-
-</workflow>

_bmad/bmm/workflows/document-project/templates/deep-dive-template.md

@@ -1,345 +0,0 @@
-# {{target_name}} - Deep Dive Documentation
-
-**Generated:** {{date}}
-**Scope:** {{target_path}}
-**Files Analyzed:** {{file_count}}
-**Lines of Code:** {{total_loc}}
-**Workflow Mode:** Exhaustive Deep-Dive
-
-## Overview
-
-{{target_description}}
-
-**Purpose:** {{target_purpose}}
-**Key Responsibilities:** {{responsibilities}}
-**Integration Points:** {{integration_summary}}
-
-## Complete File Inventory
-
-{{#each files_in_inventory}}
-
-### {{file_path}}
-
-**Purpose:** {{purpose}}
-**Lines of Code:** {{loc}}
-**File Type:** {{file_type}}
-
-**What Future Contributors Must Know:** {{contributor_note}}
-
-**Exports:**
-{{#each exports}}
-
-- `{{signature}}` - {{description}}
-  {{/each}}
-
-**Dependencies:**
-{{#each imports}}
-
-- `{{import_path}}` - {{reason}}
-  {{/each}}
-
-**Used By:**
-{{#each dependents}}
-
-- `{{dependent_path}}`
-  {{/each}}
-
-**Key Implementation Details:**
-
-```{{language}}
-{{key_code_snippet}}
-```
-
-{{implementation_notes}}
-
-**Patterns Used:**
-{{#each patterns}}
-
-- {{pattern_name}}: {{pattern_description}}
-  {{/each}}
-
-**State Management:** {{state_approach}}
-
-**Side Effects:**
-{{#each side_effects}}
-
-- {{effect_type}}: {{effect_description}}
-  {{/each}}
-
-**Error Handling:** {{error_handling_approach}}
-
-**Testing:**
-
-- Test File: {{test_file_path}}
-- Coverage: {{coverage_percentage}}%
-- Test Approach: {{test_approach}}
-
-**Comments/TODOs:**
-{{#each todos}}
-
-- Line {{line_number}}: {{todo_text}}
-  {{/each}}
-
----
-
-{{/each}}
-
-## Contributor Checklist
-
-- **Risks & Gotchas:** {{risks_notes}}
-- **Pre-change Verification Steps:** {{verification_steps}}
-- **Suggested Tests Before PR:** {{suggested_tests}}
-
-## Architecture & Design Patterns
-
-### Code Organization
-
-{{organization_approach}}
-
-### Design Patterns
-
-{{#each design_patterns}}
-
-- **{{pattern_name}}**: {{usage_description}}
-  {{/each}}
-
-### State Management Strategy
-
-{{state_management_details}}
-
-### Error Handling Philosophy
-
-{{error_handling_philosophy}}
-
-### Testing Strategy
-
-{{testing_strategy}}
-
-## Data Flow
-
-{{data_flow_diagram}}
-
-### Data Entry Points
-
-{{#each entry_points}}
-
-- **{{entry_name}}**: {{entry_description}}
-  {{/each}}
-
-### Data Transformations
-
-{{#each transformations}}
-
-- **{{transformation_name}}**: {{transformation_description}}
-  {{/each}}
-
-### Data Exit Points
-
-{{#each exit_points}}
-
-- **{{exit_name}}**: {{exit_description}}
-  {{/each}}
-
-## Integration Points
-
-### APIs Consumed
-
-{{#each apis_consumed}}
-
-- **{{api_endpoint}}**: {{api_description}}
-  - Method: {{method}}
-  - Authentication: {{auth_requirement}}
-  - Response: {{response_schema}}
-    {{/each}}
-
-### APIs Exposed
-
-{{#each apis_exposed}}
-
-- **{{api_endpoint}}**: {{api_description}}
-  - Method: {{method}}
-  - Request: {{request_schema}}
-  - Response: {{response_schema}}
-    {{/each}}
-
-### Shared State
-
-{{#each shared_state}}
-
-- **{{state_name}}**: {{state_description}}
-  - Type: {{state_type}}
-  - Accessed By: {{accessors}}
-    {{/each}}
-
-### Events
-
-{{#each events}}
-
-- **{{event_name}}**: {{event_description}}
-  - Type: {{publish_or_subscribe}}
-  - Payload: {{payload_schema}}
-    {{/each}}
-
-### Database Access
-
-{{#each database_operations}}
-
-- **{{table_name}}**: {{operation_type}}
-  - Queries: {{query_patterns}}
-  - Indexes Used: {{indexes}}
-    {{/each}}
-
-## Dependency Graph
-
-{{dependency_graph_visualization}}
-
-### Entry Points (Not Imported by Others in Scope)
-
-{{#each entry_point_files}}
-
-- {{file_path}}
-  {{/each}}
-
-### Leaf Nodes (Don't Import Others in Scope)
-
-{{#each leaf_files}}
-
-- {{file_path}}
-  {{/each}}
-
-### Circular Dependencies
-
-{{#if has_circular_dependencies}}
-⚠️ Circular dependencies detected:
-{{#each circular_deps}}
-
-- {{cycle_description}}
-  {{/each}}
-  {{else}}
-  ✓ No circular dependencies detected
-  {{/if}}
-
-## Testing Analysis
-
-### Test Coverage Summary
-
-- **Statements:** {{statements_coverage}}%
-- **Branches:** {{branches_coverage}}%
-- **Functions:** {{functions_coverage}}%
-- **Lines:** {{lines_coverage}}%
-
-### Test Files
-
-{{#each test_files}}
-
-- **{{test_file_path}}**
-  - Tests: {{test_count}}
-  - Approach: {{test_approach}}
-  - Mocking Strategy: {{mocking_strategy}}
-    {{/each}}
-
-### Test Utilities Available
-
-{{#each test_utilities}}
-
-- `{{utility_name}}`: {{utility_description}}
-  {{/each}}
-
-### Testing Gaps
-
-{{#each testing_gaps}}
-
-- {{gap_description}}
-  {{/each}}
-
-## Related Code & Reuse Opportunities
-
-### Similar Features Elsewhere
-
-{{#each similar_features}}
-
-- **{{feature_name}}** (`{{feature_path}}`)
-  - Similarity: {{similarity_description}}
-  - Can Reference For: {{reference_use_case}}
-    {{/each}}
-
-### Reusable Utilities Available
-
-{{#each reusable_utilities}}
-
-- **{{utility_name}}** (`{{utility_path}}`)
-  - Purpose: {{utility_purpose}}
-  - How to Use: {{usage_example}}
-    {{/each}}
-
-### Patterns to Follow
-
-{{#each patterns_to_follow}}
-
-- **{{pattern_name}}**: Reference `{{reference_file}}` for implementation
-  {{/each}}
-
-## Implementation Notes
-
-### Code Quality Observations
-
-{{#each quality_observations}}
-
-- {{observation}}
-  {{/each}}
-
-### TODOs and Future Work
-
-{{#each all_todos}}
-
-- **{{file_path}}:{{line_number}}**: {{todo_text}}
-  {{/each}}
-
-### Known Issues
-
-{{#each known_issues}}
-
-- {{issue_description}}
-  {{/each}}
-
-### Optimization Opportunities
-
-{{#each optimizations}}
-
-- {{optimization_suggestion}}
-  {{/each}}
-
-### Technical Debt
-
-{{#each tech_debt_items}}
-
-- {{debt_description}}
-  {{/each}}
-
-## Modification Guidance
-
-### To Add New Functionality
-
-{{modification_guidance_add}}
-
-### To Modify Existing Functionality
-
-{{modification_guidance_modify}}
-
-### To Remove/Deprecate
-
-{{modification_guidance_remove}}
-
-### Testing Checklist for Changes
-
-{{#each testing_checklist_items}}
-
-- [ ] {{checklist_item}}
-      {{/each}}
-
----
-
-_Generated by `document-project` workflow (deep-dive mode)_
-_Base Documentation: docs/index.md_
-_Scan Date: {{date}}_
-_Analysis Mode: Exhaustive_

_bmad/bmm/workflows/document-project/templates/index-template.md

@@ -1,169 +0,0 @@
-# {{project_name}} Documentation Index
-
-**Type:** {{repository_type}}{{#if is_multi_part}} with {{parts_count}} parts{{/if}}
-**Primary Language:** {{primary_language}}
-**Architecture:** {{architecture_type}}
-**Last Updated:** {{date}}
-
-## Project Overview
-
-{{project_description}}
-
-{{#if is_multi_part}}
-
-## Project Structure
-
-This project consists of {{parts_count}} parts:
-
-{{#each project_parts}}
-
-### {{part_name}} ({{part_id}})
-
-- **Type:** {{project_type}}
-- **Location:** `{{root_path}}`
-- **Tech Stack:** {{tech_stack_summary}}
-- **Entry Point:** {{entry_point}}
-  {{/each}}
-
-## Cross-Part Integration
-
-{{integration_summary}}
-
-{{/if}}
-
-## Quick Reference
-
-{{#if is_single_part}}
-
-- **Tech Stack:** {{tech_stack_summary}}
-- **Entry Point:** {{entry_point}}
-- **Architecture Pattern:** {{architecture_pattern}}
-- **Database:** {{database}}
-- **Deployment:** {{deployment_platform}}
-  {{else}}
-  {{#each project_parts}}
-
-### {{part_name}} Quick Ref
-
-- **Stack:** {{tech_stack_summary}}
-- **Entry:** {{entry_point}}
-- **Pattern:** {{architecture_pattern}}
-  {{/each}}
-  {{/if}}
-
-## Generated Documentation
-
-### Core Documentation
-
-- [Project Overview](./project-overview.md) - Executive summary and high-level architecture
-- [Source Tree Analysis](./source-tree-analysis.md) - Annotated directory structure
-
-{{#if is_single_part}}
-
-- [Architecture](./architecture.md) - Detailed technical architecture
-- [Component Inventory](./component-inventory.md) - Catalog of major components{{#if has_ui_components}} and UI elements{{/if}}
-- [Development Guide](./development-guide.md) - Local setup and development workflow
-  {{#if has_api_docs}}- [API Contracts](./api-contracts.md) - API endpoints and schemas{{/if}}
-  {{#if has_data_models}}- [Data Models](./data-models.md) - Database schema and models{{/if}}
-  {{else}}
-
-### Part-Specific Documentation
-
-{{#each project_parts}}
-
-#### {{part_name}} ({{part_id}})
-
-- [Architecture](./architecture-{{part_id}}.md) - Technical architecture for {{part_name}}
-  {{#if has_components}}- [Components](./component-inventory-{{part_id}}.md) - Component catalog{{/if}}
-- [Development Guide](./development-guide-{{part_id}}.md) - Setup and dev workflow
-  {{#if has_api}}- [API Contracts](./api-contracts-{{part_id}}.md) - API documentation{{/if}}
-  {{#if has_data}}- [Data Models](./data-models-{{part_id}}.md) - Data architecture{{/if}}
-  {{/each}}
-
-### Integration
-
-- [Integration Architecture](./integration-architecture.md) - How parts communicate
-- [Project Parts Metadata](./project-parts.json) - Machine-readable structure
-  {{/if}}
-
-### Optional Documentation
-
-{{#if has_deployment_guide}}- [Deployment Guide](./deployment-guide.md) - Deployment process and infrastructure{{/if}}
-{{#if has_contribution_guide}}- [Contribution Guide](./contribution-guide.md) - Contributing guidelines and standards{{/if}}
-
-## Existing Documentation
-
-{{#if has_existing_docs}}
-{{#each existing_docs}}
-
-- [{{title}}]({{path}}) - {{description}}
-  {{/each}}
-  {{else}}
-  No existing documentation files were found in the project.
-  {{/if}}
-
-## Getting Started
-
-{{#if is_single_part}}
-
-### Prerequisites
-
-{{prerequisites}}
-
-### Setup
-
-```bash
-{{setup_commands}}
-```
-
-### Run Locally
-
-```bash
-{{run_commands}}
-```
-
-### Run Tests
-
-```bash
-{{test_commands}}
-```
-
-{{else}}
-{{#each project_parts}}
-
-### {{part_name}} Setup
-
-**Prerequisites:** {{prerequisites}}
-
-**Install & Run:**
-
-```bash
-cd {{root_path}}
-{{setup_command}}
-{{run_command}}
-```
-
-{{/each}}
-{{/if}}
-
-## For AI-Assisted Development
-
-This documentation was generated specifically to enable AI agents to understand and extend this codebase.
-
-### When Planning New Features:
-
-**UI-only features:**
-{{#if is_multi_part}}→ Reference: `architecture-{{ui_part_id}}.md`, `component-inventory-{{ui_part_id}}.md`{{else}}→ Reference: `architecture.md`, `component-inventory.md`{{/if}}
-
-**API/Backend features:**
-{{#if is_multi_part}}→ Reference: `architecture-{{api_part_id}}.md`, `api-contracts-{{api_part_id}}.md`, `data-models-{{api_part_id}}.md`{{else}}→ Reference: `architecture.md`{{#if has_api_docs}}, `api-contracts.md`{{/if}}{{#if has_data_models}}, `data-models.md`{{/if}}{{/if}}
-
-**Full-stack features:**
-→ Reference: All architecture docs{{#if is_multi_part}} + `integration-architecture.md`{{/if}}
-
-**Deployment changes:**
-{{#if has_deployment_guide}}→ Reference: `deployment-guide.md`{{else}}→ Review CI/CD configs in project{{/if}}
-
----
-
-_Documentation generated by BMAD Method `document-project` workflow_

_bmad/bmm/workflows/document-project/templates/project-overview-template.md

@@ -1,103 +0,0 @@
-# {{project_name}} - Project Overview
-
-**Date:** {{date}}
-**Type:** {{project_type}}
-**Architecture:** {{architecture_type}}
-
-## Executive Summary
-
-{{executive_summary}}
-
-## Project Classification
-
-- **Repository Type:** {{repository_type}}
-- **Project Type(s):** {{project_types_list}}
-- **Primary Language(s):** {{primary_languages}}
-- **Architecture Pattern:** {{architecture_pattern}}
-
-{{#if is_multi_part}}
-
-## Multi-Part Structure
-
-This project consists of {{parts_count}} distinct parts:
-
-{{#each project_parts}}
-
-### {{part_name}}
-
-- **Type:** {{project_type}}
-- **Location:** `{{root_path}}`
-- **Purpose:** {{purpose}}
-- **Tech Stack:** {{tech_stack}}
-  {{/each}}
-
-### How Parts Integrate
-
-{{integration_description}}
-{{/if}}
-
-## Technology Stack Summary
-
-{{#if is_single_part}}
-{{technology_table}}
-{{else}}
-{{#each project_parts}}
-
-### {{part_name}} Stack
-
-{{technology_table}}
-{{/each}}
-{{/if}}
-
-## Key Features
-
-{{key_features}}
-
-## Architecture Highlights
-
-{{architecture_highlights}}
-
-## Development Overview
-
-### Prerequisites
-
-{{prerequisites}}
-
-### Getting Started
-
-{{getting_started_summary}}
-
-### Key Commands
-
-{{#if is_single_part}}
-
-- **Install:** `{{install_command}}`
-- **Dev:** `{{dev_command}}`
-- **Build:** `{{build_command}}`
-- **Test:** `{{test_command}}`
-  {{else}}
-  {{#each project_parts}}
-
-#### {{part_name}}
-
-- **Install:** `{{install_command}}`
-- **Dev:** `{{dev_command}}`
-  {{/each}}
-  {{/if}}
-
-## Repository Structure
-
-{{repository_structure_summary}}
-
-## Documentation Map
-
-For detailed information, see:
-
-- [index.md](./index.md) - Master documentation index
-- [architecture.md](./architecture{{#if is_multi_part}}-{part_id}{{/if}}.md) - Detailed architecture
-- [source-tree-analysis.md](./source-tree-analysis.md) - Directory structure
-- [development-guide.md](./development-guide{{#if is_multi_part}}-{part_id}{{/if}}.md) - Development workflow
-
----
-
-_Generated using BMAD Method `document-project` workflow_

_bmad/bmm/workflows/document-project/templates/project-scan-report-schema.json

@@ -1,160 +0,0 @@
-{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "title": "Project Scan Report Schema",
-  "description": "State tracking file for document-project workflow resumability",
-  "type": "object",
-  "required": ["workflow_version", "timestamps", "mode", "scan_level", "completed_steps", "current_step"],
-  "properties": {
-    "workflow_version": {
-      "type": "string",
-      "description": "Version of document-project workflow",
-      "example": "1.2.0"
-    },
-    "timestamps": {
-      "type": "object",
-      "required": ["started", "last_updated"],
-      "properties": {
-        "started": {
-          "type": "string",
-          "format": "date-time",
-          "description": "ISO 8601 timestamp when workflow started"
-        },
-        "last_updated": {
-          "type": "string",
-          "format": "date-time",
-          "description": "ISO 8601 timestamp of last state update"
-        },
-        "completed": {
-          "type": "string",
-          "format": "date-time",
-          "description": "ISO 8601 timestamp when workflow completed (if finished)"
-        }
-      }
-    },
-    "mode": {
-      "type": "string",
-      "enum": ["initial_scan", "full_rescan", "deep_dive"],
-      "description": "Workflow execution mode"
-    },
-    "scan_level": {
-      "type": "string",
-      "enum": ["quick", "deep", "exhaustive"],
-      "description": "Scan depth level (deep_dive mode always uses exhaustive)"
-    },
-    "project_root": {
-      "type": "string",
-      "description": "Absolute path to project root directory"
-    },
-    "output_folder": {
-      "type": "string",
-      "description": "Absolute path to output folder"
-    },
-    "completed_steps": {
-      "type": "array",
-      "items": {
-        "type": "object",
-        "required": ["step", "status"],
-        "properties": {
-          "step": {
-            "type": "string",
-            "description": "Step identifier (e.g., 'step_1', 'step_2')"
-          },
-          "status": {
-            "type": "string",
-            "enum": ["completed", "partial", "failed"]
-          },
-          "timestamp": {
-            "type": "string",
-            "format": "date-time"
-          },
-          "outputs": {
-            "type": "array",
-            "items": { "type": "string" },
-            "description": "Files written during this step"
-          },
-          "summary": {
-            "type": "string",
-            "description": "1-2 sentence summary of step outcome"
-          }
-        }
-      }
-    },
-    "current_step": {
-      "type": "string",
-      "description": "Current step identifier for resumption"
-    },
-    "findings": {
-      "type": "object",
-      "description": "High-level summaries only (detailed findings purged after writing)",
-      "properties": {
-        "project_classification": {
-          "type": "object",
-          "properties": {
-            "repository_type": { "type": "string" },
-            "parts_count": { "type": "integer" },
-            "primary_language": { "type": "string" },
-            "architecture_type": { "type": "string" }
-          }
-        },
-        "technology_stack": {
-          "type": "array",
-          "items": {
-            "type": "object",
-            "properties": {
-              "part_id": { "type": "string" },
-              "tech_summary": { "type": "string" }
-            }
-          }
-        },
-        "batches_completed": {
-          "type": "array",
-          "description": "For deep/exhaustive scans: subfolders processed",
-          "items": {
-            "type": "object",
-            "properties": {
-              "path": { "type": "string" },
-              "files_scanned": { "type": "integer" },
-              "summary": { "type": "string" }
-            }
-          }
-        }
-      }
-    },
-    "outputs_generated": {
-      "type": "array",
-      "items": { "type": "string" },
-      "description": "List of all output files generated"
-    },
-    "resume_instructions": {
-      "type": "string",
-      "description": "Instructions for resuming from current_step"
-    },
-    "validation_status": {
-      "type": "object",
-      "properties": {
-        "last_validated": {
-          "type": "string",
-          "format": "date-time"
-        },
-        "validation_errors": {
-          "type": "array",
-          "items": { "type": "string" }
-        }
-      }
-    },
-    "deep_dive_targets": {
-      "type": "array",
-      "description": "Track deep-dive areas analyzed (for deep_dive mode)",
-      "items": {
-        "type": "object",
-        "properties": {
-          "target_name": { "type": "string" },
-          "target_path": { "type": "string" },
-          "files_analyzed": { "type": "integer" },
-          "output_file": { "type": "string" },
-          "timestamp": { "type": "string", "format": "date-time" }
-        }
-      }
-    }
-  }
-}

_bmad/bmm/workflows/document-project/templates/source-tree-template.md

@@ -1,135 +0,0 @@
-# {{project_name}} - Source Tree Analysis
-
-**Date:** {{date}}
-
-## Overview
-
-{{source_tree_overview}}
-
-{{#if is_multi_part}}
-
-## Multi-Part Structure
-
-This project is organized into {{parts_count}} distinct parts:
-
-{{#each project_parts}}
-
-- **{{part_name}}** (`{{root_path}}`): {{purpose}}
-  {{/each}}
-  {{/if}}
-
-## Complete Directory Structure
-
-```
-{{complete_source_tree}}
-```
-
-## Critical Directories
-
-{{#each critical_folders}}
-
-### `{{folder_path}}`
-
-{{description}}
-
-**Purpose:** {{purpose}}
-**Contains:** {{contents_summary}}
-{{#if entry_points}}**Entry Points:** {{entry_points}}{{/if}}
-{{#if integration_note}}**Integration:** {{integration_note}}{{/if}}
-
-{{/each}}
-
-{{#if is_multi_part}}
-
-## Part-Specific Trees
-
-{{#each project_parts}}
-
-### {{part_name}} Structure
-
-```
-{{source_tree}}
-```
-
-**Key Directories:**
-{{#each critical_directories}}
-
-- **`{{path}}`**: {{description}}
-  {{/each}}
-
-{{/each}}
-
-## Integration Points
-
-{{#each integration_points}}
-
-### {{from_part}} → {{to_part}}
-
-- **Location:** `{{integration_path}}`
-- **Type:** {{integration_type}}
-- **Details:** {{details}}
-  {{/each}}
-
-{{/if}}
-
-## Entry Points
-
-{{#if is_single_part}}
-
-- **Main Entry:** `{{main_entry_point}}`
-  {{#if additional_entry_points}}
-- **Additional:**
-  {{#each additional_entry_points}}
-  - `{{path}}`: {{description}}
-    {{/each}}
-    {{/if}}
-    {{else}}
-    {{#each project_parts}}
-
-### {{part_name}}
-
-- **Entry Point:** `{{entry_point}}`
-- **Bootstrap:** {{bootstrap_description}}
-  {{/each}}
-  {{/if}}
-
-## File Organization Patterns
-
-{{file_organization_patterns}}
-
-## Key File Types
-
-{{#each file_type_patterns}}
-
-### {{file_type}}
-
-- **Pattern:** `{{pattern}}`
-- **Purpose:** {{purpose}}
-- **Examples:** {{examples}}
-  {{/each}}
-
-## Asset Locations
-
-{{#if has_assets}}
-{{#each asset_locations}}
-
-- **{{asset_type}}**: `{{location}}` ({{file_count}} files, {{total_size}})
-  {{/each}}
-  {{else}}
-  No significant assets detected.
-  {{/if}}
-
-## Configuration Files
-
-{{#each config_files}}
-
-- **`{{path}}`**: {{description}}
-  {{/each}}
-
-## Notes for Development
-
-{{development_notes}}
-
----
-
-_Generated using BMAD Method `document-project` workflow_

_bmad/bmm/workflows/document-project/workflow.yaml

@@ -1,28 +0,0 @@
-# Document Project Workflow Configuration
-name: "document-project"
-version: "1.2.0"
-description: "Analyzes and documents brownfield projects by scanning codebase, architecture, and patterns to create comprehensive reference documentation for AI-assisted development"
-author: "BMad"
-
-# Critical variables
-config_source: "{project-root}/_bmad/bmm/config.yaml"
-output_folder: "{config_source}:project_knowledge"
-user_name: "{config_source}:user_name"
-communication_language: "{config_source}:communication_language"
-document_output_language: "{config_source}:document_output_language"
-user_skill_level: "{config_source}:user_skill_level"
-date: system-generated
-
-# Module path and component files
-installed_path: "{project-root}/_bmad/bmm/workflows/document-project"
-instructions: "{installed_path}/instructions.md"
-validation: "{installed_path}/checklist.md"
-
-# Required data files - CRITICAL for project type detection and documentation requirements
-documentation_requirements_csv: "{installed_path}/documentation-requirements.csv"
-
-# Output configuration - Multiple files generated in output folder
-# Primary output: {output_folder}/project-documentation/
-# Additional files generated by sub-workflows based on project structure
-
-standalone: true

_bmad/bmm/workflows/document-project/workflows/deep-dive-instructions.md

@@ -1,298 +0,0 @@
-# Deep-Dive Documentation Instructions
-
-<workflow>
-
-<critical>This workflow performs exhaustive deep-dive documentation of specific areas</critical>
-<critical>Called by: ../document-project/instructions.md router</critical>
-<critical>Handles: deep_dive mode only</critical>
-
-<step n="13" goal="Deep-dive documentation of specific area" if="workflow_mode == deep_dive">
-<critical>Deep-dive mode requires literal full-file review. Sampling, guessing, or relying solely on tooling output is FORBIDDEN.</critical>
-<action>Load existing project structure from index.md and project-parts.json (if exists)</action>
-<action>Load source tree analysis to understand available areas</action>
-
-<step n="13a" goal="Identify area for deep-dive">
-  <action>Analyze existing documentation to suggest deep-dive options</action>
-
-<ask>What area would you like to deep-dive into?
-
-**Suggested Areas Based on Project Structure:**
-
-{{#if has_api_routes}}
-
-## API Routes ({{api_route_count}} endpoints found)
-
-{{#each api_route_groups}}
-{{group_index}}. {{group_name}} - {{endpoint_count}} endpoints in `{{path}}`
-{{/each}}
-{{/if}}
-
-{{#if has_feature_modules}}
-
-## Feature Modules ({{feature_count}} features)
-
-{{#each feature_modules}}
-{{module_index}}. {{module_name}} - {{file_count}} files in `{{path}}`
-{{/each}}
-{{/if}}
-
-{{#if has_ui_components}}
-
-### UI Component Areas
-
-{{#each component_groups}}
-{{group_index}}. {{group_name}} - {{component_count}} components in `{{path}}`
-{{/each}}
-{{/if}}
-
-{{#if has_services}}
-
-### Services/Business Logic
-
-{{#each service_groups}}
-{{service_index}}. {{service_name}} - `{{path}}`
-{{/each}}
-{{/if}}
-
-**Or specify custom:**
-
-- Folder path (e.g., "client/src/features/dashboard")
-- File path (e.g., "server/src/api/users.ts")
-- Feature name (e.g., "authentication system")
-
-Enter your choice (number or custom path):
-</ask>
-
-<action>Parse user input to determine: - target_type: "folder" | "file" | "feature" | "api_group" | "component_group" - target_path: Absolute path to scan - target_name: Human-readable name for documentation - target_scope: List of all files to analyze
-</action>
-
-<action>Store as {{deep_dive_target}}</action>
-
-<action>Display confirmation:
-Target: {{target_name}}
-Type: {{target_type}}
-Path: {{target_path}}
-Estimated files to analyze: {{estimated_file_count}}
-
-This will read EVERY file in this area. Proceed? [y/n]
-</action>
-
-<action if="user confirms 'n'">Return to Step 13a (select different area)</action>
-</step>
-
-<step n="13b" goal="Comprehensive exhaustive scan of target area">
-  <action>Set scan_mode = "exhaustive"</action>
-  <action>Initialize file_inventory = []</action>
-  <critical>You must read every line of every file in scope and capture a plain-language explanation (what the file does, side effects, why it matters) that future developer agents can act on. No shortcuts.</critical>
-
-  <check if="target_type == folder">
-    <action>Get complete recursive file list from {{target_path}}</action>
-    <action>Filter out: node_modules/, .git/, dist/, build/, coverage/, *.min.js, *.map</action>
-    <action>For EVERY remaining file in folder:
-      - Read complete file contents (all lines)
-      - Extract all exports (functions, classes, types, interfaces, constants)
-      - Extract all imports (dependencies)
-      - Identify purpose from comments and code structure
-      - Write 1-2 sentences (minimum) in natural language describing behaviour, side effects, assumptions, and anything a developer must know before modifying the file
-      - Extract function signatures with parameter types and return types
-      - Note any TODOs, FIXMEs, or comments
-      - Identify patterns (hooks, components, services, controllers, etc.)
-      - Capture per-file contributor guidance: `contributor_note`, `risks`, `verification_steps`, `suggested_tests`
-      - Store in file_inventory
-    </action>
-  </check>
-
-  <check if="target_type == file">
-    <action>Read complete file at {{target_path}}</action>
-    <action>Extract all information as above</action>
-    <action>Read all files it imports (follow import chain 1 level deep)</action>
-    <action>Find all files that import this file (dependents via grep)</action>
-    <action>Store all in file_inventory</action>
-  </check>
-
-  <check if="target_type == api_group">
-    <action>Identify all route/controller files in API group</action>
-    <action>Read all route handlers completely</action>
-    <action>Read associated middleware, controllers, services</action>
-    <action>Read data models and schemas used</action>
-    <action>Extract complete request/response schemas</action>
-    <action>Document authentication and authorization requirements</action>
-    <action>Store all in file_inventory</action>
-  </check>
-
-  <check if="target_type == feature">
-    <action>Search codebase for all files related to feature name</action>
-    <action>Include: UI components, API endpoints, models, services, tests</action>
-    <action>Read each file completely</action>
-    <action>Store all in file_inventory</action>
-  </check>
-
-  <check if="target_type == component_group">
-    <action>Get all component files in group</action>
-    <action>Read each component completely</action>
-    <action>Extract: Props interfaces, hooks used, child components, state management</action>
-    <action>Store all in file_inventory</action>
-  </check>
-
-<action>For each file in file\*inventory, document: - **File Path:** Full path - **Purpose:** What this file does (1-2 sentences) - **Lines of Code:** Total LOC - **Exports:** Complete list with signatures
-
-- Functions: `functionName(param: Type): ReturnType` - Description
-  - Classes: `ClassName` - Description with key methods
-  - Types/Interfaces: `TypeName` - Description
-  - Constants: `CONSTANT_NAME: Type` - Description - **Imports/Dependencies:** What it uses and why - **Used By:** Files that import this (dependents) - **Key Implementation Details:** Important logic, algorithms, patterns - **State Management:** If applicable (Redux, Context, local state) - **Side Effects:** API calls, database queries, file I/O, external services - **Error Handling:** Try/catch blocks, error boundaries, validation - **Testing:** Associated test files and coverage - **Comments/TODOs:** Any inline documentation or planned work
-    </action>
-
-<template-output>comprehensive_file_inventory</template-output>
-</step>
-
-<step n="13c" goal="Analyze relationships and data flow">
-  <action>Build dependency graph for scanned area:
-    - Create graph with files as nodes
-    - Add edges for import relationships
-    - Identify circular dependencies if any
-    - Find entry points (files not imported by others in scope)
-    - Find leaf nodes (files that don't import others in scope)
-  </action>
-
-<action>Trace data flow through the system: - Follow function calls and data transformations - Track API calls and their responses - Document state updates and propagation - Map database queries and mutations
-</action>
-
-<action>Identify integration points: - External APIs consumed - Internal APIs/services called - Shared state accessed - Events published/subscribed - Database tables accessed
-</action>
-
-<template-output>dependency_graph</template-output>
-<template-output>data_flow_analysis</template-output>
-<template-output>integration_points</template-output>
-</step>
-
-<step n="13d" goal="Find related code and similar patterns">
-  <action>Search codebase OUTSIDE scanned area for:
-    - Similar file/folder naming patterns
-    - Similar function signatures
-    - Similar component structures
-    - Similar API patterns
-    - Reusable utilities that could be used
-  </action>
-
-<action>Identify code reuse opportunities: - Shared utilities available - Design patterns used elsewhere - Component libraries available - Helper functions that could apply
-</action>
-
-<action>Find reference implementations: - Similar features in other parts of codebase - Established patterns to follow - Testing approaches used elsewhere
-</action>
-
-<template-output>related_code_references</template-output>
-<template-output>reuse_opportunities</template-output>
-</step>
-
-<step n="13e" goal="Generate comprehensive deep-dive documentation">
-  <action>Create documentation filename: deep-dive-{{sanitized_target_name}}.md</action>
-  <action>Aggregate contributor insights across files:
-    - Combine unique risk/gotcha notes into {{risks_notes}}
-    - Combine verification steps developers should run before changes into {{verification_steps}}
-    - Combine recommended test commands into {{suggested_tests}}
-  </action>
-
-<action>Load complete deep-dive template from: {installed_path}/templates/deep-dive-template.md</action>
-<action>Fill template with all collected data from steps 13b-13d</action>
-<action>Write filled template to: {output_folder}/deep-dive-{{sanitized_target_name}}.md</action>
-<action>Validate deep-dive document completeness</action>
-
-<template-output>deep_dive_documentation</template-output>
-
-<action>Update state file: - Add to deep_dive_targets array: {"target_name": "{{target_name}}", "target_path": "{{target_path}}", "files_analyzed": {{file_count}}, "output_file": "deep-dive-{{sanitized_target_name}}.md", "timestamp": "{{now}}"} - Add output to outputs_generated - Update last_updated timestamp
-</action>
-</step>
-
-<step n="13f" goal="Update master index with deep-dive link">
-  <action>Read existing index.md</action>
-
-<action>Check if "Deep-Dive Documentation" section exists</action>
-
-  <check if="section does not exist">
-    <action>Add new section after "Generated Documentation":
-
-## Deep-Dive Documentation
-
-Detailed exhaustive analysis of specific areas:
-
-    </action>
-
-  </check>
-
-<action>Add link to new deep-dive doc:
-
-- [{{target_name}} Deep-Dive](./deep-dive-{{sanitized_target_name}}.md) - Comprehensive analysis of {{target_description}} ({{file_count}} files, {{total_loc}} LOC) - Generated {{date}}
-  </action>
-
-  <action>Update index metadata:
-  Last Updated: {{date}}
-  Deep-Dives: {{deep_dive_count}}
-  </action>
-
-  <action>Save updated index.md</action>
-
-  <template-output>updated_index</template-output>
-  </step>
-
-<step n="13g" goal="Offer to continue or complete">
-  <action>Display summary:
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-## Deep-Dive Documentation Complete! ✓
-
-**Generated:** {output_folder}/deep-dive-{{target_name}}.md
-**Files Analyzed:** {{file_count}}
-**Lines of Code Scanned:** {{total_loc}}
-**Time Taken:** ~{{duration}}
-
-**Documentation Includes:**
-
-- Complete file inventory with all exports
-- Dependency graph and data flow
-- Integration points and API contracts
-- Testing analysis and coverage
-- Related code and reuse opportunities
-- Implementation guidance
-
-**Index Updated:** {output_folder}/index.md now includes link to this deep-dive
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-</action>
-
-<ask>Would you like to:
-
-1. **Deep-dive another area** - Analyze another feature/module/folder
-2. **Finish** - Complete workflow
-
-Your choice [1/2]:
-</ask>
-
-  <action if="user selects 1">
-    <action>Clear current deep_dive_target</action>
-    <action>Go to Step 13a (select new area)</action>
-  </action>
-
-  <action if="user selects 2">
-    <action>Display final message:
-
-All deep-dive documentation complete!
-
-**Master Index:** {output_folder}/index.md
-**Deep-Dives Generated:** {{deep_dive_count}}
-
-These comprehensive docs are now ready for:
-
-- Architecture review
-- Implementation planning
-- Code understanding
-- Brownfield PRD creation
-
-Thank you for using the document-project workflow!
-</action>
-<action>Exit workflow</action>
-</action>
-</step>
-</step>
-
-</workflow>

_bmad/bmm/workflows/document-project/workflows/deep-dive.yaml

@@ -1,31 +0,0 @@
-# Deep-Dive Documentation Workflow Configuration
-name: "document-project-deep-dive"
-description: "Exhaustive deep-dive documentation of specific project areas"
-author: "BMad"
-
-# This is a sub-workflow called by document-project/workflow.yaml
-parent_workflow: "{project-root}/_bmad/bmm/workflows/document-project/workflow.yaml"
-
-# Critical variables inherited from parent
-config_source: "{project-root}/_bmad/bmb/config.yaml"
-output_folder: "{config_source}:output_folder"
-user_name: "{config_source}:user_name"
-date: system-generated
-
-# Module path and component files
-installed_path: "{project-root}/_bmad/bmm/workflows/document-project/workflows"
-template: false # Action workflow
-instructions: "{installed_path}/deep-dive-instructions.md"
-validation: "{project-root}/_bmad/bmm/workflows/document-project/checklist.md"
-
-# Templates
-deep_dive_template: "{project-root}/_bmad/bmm/workflows/document-project/templates/deep-dive-template.md"
-
-# Runtime inputs (passed from parent workflow)
-workflow_mode: "deep_dive"
-scan_level: "exhaustive" # Deep-dive always uses exhaustive scan
-project_root_path: ""
-existing_index_path: "" # Path to existing index.md
-
-# Configuration
-autonomous: false # Requires user input to select target area

_bmad/bmm/workflows/document-project/workflows/full-scan-instructions.md

@@ -1,1106 +0,0 @@
-# Full Project Scan Instructions
-
-<workflow>
-
-<critical>This workflow performs complete project documentation (Steps 1-12)</critical>
-<critical>Called by: document-project/instructions.md router</critical>
-<critical>Handles: initial_scan and full_rescan modes</critical>
-
-<step n="0.5" goal="Load documentation requirements data for fresh starts (not needed for resume)" if="resume_mode == false">
-<critical>DATA LOADING STRATEGY - Understanding the Documentation Requirements System:</critical>
-
-<action>Display explanation to user:
-
-**How Project Type Detection Works:**
-
-This workflow uses a single comprehensive CSV file to intelligently document your project:
-
-**documentation-requirements.csv** ({documentation_requirements_csv})
-
-- Contains 12 project types (web, mobile, backend, cli, library, desktop, game, data, extension, infra, embedded)
-- 24-column schema combining project type detection AND documentation requirements
-- **Detection columns**: project_type_id, key_file_patterns (used to identify project type from codebase)
-- **Requirement columns**: requires_api_scan, requires_data_models, requires_ui_components, etc.
-- **Pattern columns**: critical_directories, test_file_patterns, config_patterns, etc.
-- Acts as a "scan guide" - tells the workflow WHERE to look and WHAT to document
-- Example: For project_type_id="web", key_file_patterns includes "package.json;tsconfig.json;\*.config.js" and requires_api_scan=true
-
-**When Documentation Requirements are Loaded:**
-
-- **Fresh Start (initial_scan)**: Load all 12 rows → detect type using key_file_patterns → use that row's requirements
-- **Resume**: Load ONLY the doc requirements row(s) for cached project_type_id(s)
-- **Full Rescan**: Same as fresh start (may re-detect project type)
-- **Deep Dive**: Load ONLY doc requirements for the part being deep-dived
-  </action>
-
-<action>Now loading documentation requirements data for fresh start...</action>
-
-<action>Load documentation-requirements.csv from: {documentation_requirements_csv}</action>
-<action>Store all 12 rows indexed by project_type_id for project detection and requirements lookup</action>
-<action>Display: "Loaded documentation requirements for 12 project types (web, mobile, backend, cli, library, desktop, game, data, extension, infra, embedded)"</action>
-
-<action>Display: "✓ Documentation requirements loaded successfully. Ready to begin project analysis."</action>
-</step>
-
-<step n="0.6" goal="Check for existing documentation and determine workflow mode">
-<action>Check if {output_folder}/index.md exists</action>
-
-<check if="index.md exists">
-  <action>Read existing index.md to extract metadata (date, project structure, parts count)</action>
-  <action>Store as {{existing_doc_date}}, {{existing_structure}}</action>
-
-<ask>I found existing documentation generated on {{existing_doc_date}}.
-
-What would you like to do?
-
-1. **Re-scan entire project** - Update all documentation with latest changes
-2. **Deep-dive into specific area** - Generate detailed documentation for a particular feature/module/folder
-3. **Cancel** - Keep existing documentation as-is
-
-Your choice [1/2/3]:
-</ask>
-
-  <check if="user selects 1">
-    <action>Set workflow_mode = "full_rescan"</action>
-    <action>Continue to scan level selection below</action>
-  </check>
-
-  <check if="user selects 2">
-    <action>Set workflow_mode = "deep_dive"</action>
-    <action>Set scan_level = "exhaustive"</action>
-    <action>Initialize state file with mode=deep_dive, scan_level=exhaustive</action>
-    <action>Jump to Step 13</action>
-  </check>
-
-  <check if="user selects 3">
-    <action>Display message: "Keeping existing documentation. Exiting workflow."</action>
-    <action>Exit workflow</action>
-  </check>
-</check>
-
-<check if="index.md does not exist">
-  <action>Set workflow_mode = "initial_scan"</action>
-  <action>Continue to scan level selection below</action>
-</check>
-
-<action if="workflow_mode != deep_dive">Select Scan Level</action>
-
-<check if="workflow_mode == initial_scan OR workflow_mode == full_rescan">
-  <ask>Choose your scan depth level:
-
-**1. Quick Scan** (2-5 minutes) [DEFAULT]
-
-- Pattern-based analysis without reading source files
-- Scans: Config files, package manifests, directory structure
-- Best for: Quick project overview, initial understanding
-- File reading: Minimal (configs, README, package.json, etc.)
-
-**2. Deep Scan** (10-30 minutes)
-
-- Reads files in critical directories based on project type
-- Scans: All critical paths from documentation requirements
-- Best for: Comprehensive documentation for brownfield PRD
-- File reading: Selective (key files in critical directories)
-
-**3. Exhaustive Scan** (30-120 minutes)
-
-- Reads ALL source files in project
-- Scans: Every source file (excludes node_modules, dist, build)
-- Best for: Complete analysis, migration planning, detailed audit
-- File reading: Complete (all source files)
-
-Your choice [1/2/3] (default: 1):
-</ask>
-
-  <action if="user selects 1 OR user presses enter">
-    <action>Set scan_level = "quick"</action>
-    <action>Display: "Using Quick Scan (pattern-based, no source file reading)"</action>
-  </action>
-
-  <action if="user selects 2">
-    <action>Set scan_level = "deep"</action>
-    <action>Display: "Using Deep Scan (reading critical files per project type)"</action>
-  </action>
-
-  <action if="user selects 3">
-    <action>Set scan_level = "exhaustive"</action>
-    <action>Display: "Using Exhaustive Scan (reading all source files)"</action>
-  </action>
-
-<action>Initialize state file: {output_folder}/project-scan-report.json</action>
-<critical>Every time you touch the state file, record: step id, human-readable summary (what you actually did), precise timestamp, and any outputs written. Vague phrases are unacceptable.</critical>
-<action>Write initial state:
-{
-"workflow_version": "1.2.0",
-"timestamps": {"started": "{{current_timestamp}}", "last_updated": "{{current_timestamp}}"},
-"mode": "{{workflow_mode}}",
-"scan_level": "{{scan_level}}",
-"project_root": "{{project_root_path}}",
-"output_folder": "{{output_folder}}",
-"completed_steps": [],
-"current_step": "step_1",
-"findings": {},
-"outputs_generated": ["project-scan-report.json"],
-"resume_instructions": "Starting from step 1"
-}
-</action>
-<action>Continue with standard workflow from Step 1</action>
-</check>
-</step>
-
-<step n="1" goal="Detect project structure and classify project type" if="workflow_mode != deep_dive">
-<action>Ask user: "What is the root directory of the project to document?" (default: current working directory)</action>
-<action>Store as {{project_root_path}}</action>
-
-<action>Scan {{project_root_path}} for key indicators:
-
-- Directory structure (presence of client/, server/, api/, src/, app/, etc.)
-- Key files (package.json, go.mod, requirements.txt, etc.)
-- Technology markers matching detection_keywords from project-types.csv
-  </action>
-
-<action>Detect if project is:
-
-- **Monolith**: Single cohesive codebase
-- **Monorepo**: Multiple parts in one repository
-- **Multi-part**: Separate client/server or similar architecture
-  </action>
-
-<check if="multiple distinct parts detected (e.g., client/ and server/ folders)">
-  <action>List detected parts with their paths</action>
-  <ask>I detected multiple parts in this project:
-  {{detected_parts_list}}
-
-Is this correct? Should I document each part separately? [y/n]
-</ask>
-
-<action if="user confirms">Set repository_type = "monorepo" or "multi-part"</action>
-<action if="user confirms">For each detected part: - Identify root path - Run project type detection using key_file_patterns from documentation-requirements.csv - Store as part in project_parts array
-</action>
-
-<action if="user denies or corrects">Ask user to specify correct parts and their paths</action>
-</check>
-
-<check if="single cohesive project detected">
-  <action>Set repository_type = "monolith"</action>
-  <action>Create single part in project_parts array with root_path = {{project_root_path}}</action>
-  <action>Run project type detection using key_file_patterns from documentation-requirements.csv</action>
-</check>
-
-<action>For each part, match detected technologies and file patterns against key_file_patterns column in documentation-requirements.csv</action>
-<action>Assign project_type_id to each part</action>
-<action>Load corresponding documentation_requirements row for each part</action>
-
-<ask>I've classified this project:
-{{project_classification_summary}}
-
-Does this look correct? [y/n/edit]
-</ask>
-
-<template-output>project_structure</template-output>
-<template-output>project_parts_metadata</template-output>
-
-<action>IMMEDIATELY update state file with step completion:
-
-- Add to completed_steps: {"step": "step_1", "status": "completed", "timestamp": "{{now}}", "summary": "Classified as {{repository_type}} with {{parts_count}} parts"}
-- Update current_step = "step_2"
-- Update findings.project_classification with high-level summary only
-- **CACHE project_type_id(s)**: Add project_types array: [{"part_id": "{{part_id}}", "project_type_id": "{{project_type_id}}", "display_name": "{{display_name}}"}]
-- This cached data prevents reloading all CSV files on resume - we can load just the needed documentation_requirements row(s)
-- Update last_updated timestamp
-- Write state file
-  </action>
-
-<action>PURGE detailed scan results from memory, keep only summary: "{{repository_type}}, {{parts_count}} parts, {{primary_tech}}"</action>
-</step>
-
-<step n="2" goal="Discover existing documentation and gather user context" if="workflow_mode != deep_dive">
-<action>For each part, scan for existing documentation using patterns:
-- README.md, README.rst, README.txt
-- CONTRIBUTING.md, CONTRIBUTING.rst
-- ARCHITECTURE.md, ARCHITECTURE.txt, docs/architecture/
-- DEPLOYMENT.md, DEPLOY.md, docs/deployment/
-- API.md, docs/api/
-- Any files in docs/, documentation/, .github/ folders
-</action>
-
-<action>Create inventory of existing_docs with:
-
-- File path
-- File type (readme, architecture, api, etc.)
-- Which part it belongs to (if multi-part)
-  </action>
-
-<ask>I found these existing documentation files:
-{{existing_docs_list}}
-
-Are there any other important documents or key areas I should focus on while analyzing this project? [Provide paths or guidance, or type 'none']
-</ask>
-
-<action>Store user guidance as {{user_context}}</action>
-
-<template-output>existing_documentation_inventory</template-output>
-<template-output>user_provided_context</template-output>
-
-<action>Update state file:
-
-- Add to completed_steps: {"step": "step_2", "status": "completed", "timestamp": "{{now}}", "summary": "Found {{existing_docs_count}} existing docs"}
-- Update current_step = "step_3"
-- Update last_updated timestamp
-  </action>
-
-<action>PURGE detailed doc contents from memory, keep only: "{{existing_docs_count}} docs found"</action>
-</step>
-
-<step n="3" goal="Analyze technology stack for each part" if="workflow_mode != deep_dive">
-<action>For each part in project_parts:
-  - Load key_file_patterns from documentation_requirements
-  - Scan part root for these patterns
-  - Parse technology manifest files (package.json, go.mod, requirements.txt, etc.)
-  - Extract: framework, language, version, database, dependencies
-  - Build technology_table with columns: Category, Technology, Version, Justification
-</action>
-
-<action>Determine architecture pattern based on detected tech stack:
-
-- Use project_type_id as primary indicator (e.g., "web" → layered/component-based, "backend" → service/API-centric)
-- Consider framework patterns (e.g., React → component hierarchy, Express → middleware pipeline)
-- Note architectural style in technology table
-- Store as {{architecture_pattern}} for each part
-  </action>
-
-<template-output>technology_stack</template-output>
-<template-output>architecture_patterns</template-output>
-
-<action>Update state file:
-
-- Add to completed_steps: {"step": "step_3", "status": "completed", "timestamp": "{{now}}", "summary": "Tech stack: {{primary_framework}}"}
-- Update current_step = "step_4"
-- Update findings.technology_stack with summary per part
-- Update last_updated timestamp
-  </action>
-
-<action>PURGE detailed tech analysis from memory, keep only: "{{framework}} on {{language}}"</action>
-</step>
-
-<step n="4" goal="Perform conditional analysis based on project type requirements" if="workflow_mode != deep_dive">
-
-<critical>BATCHING STRATEGY FOR DEEP/EXHAUSTIVE SCANS</critical>
-
-<check if="scan_level == deep OR scan_level == exhaustive">
-  <action>This step requires file reading. Apply batching strategy:</action>
-
-<action>Identify subfolders to process based on: - scan_level == "deep": Use critical_directories from documentation_requirements - scan_level == "exhaustive": Get ALL subfolders recursively (excluding node_modules, .git, dist, build, coverage)
-</action>
-
-<action>For each subfolder to scan: 1. Read all files in subfolder (consider file size - use judgment for files >5000 LOC) 2. Extract required information based on conditional flags below 3. IMMEDIATELY write findings to appropriate output file 4. Validate written document (section-level validation) 5. Update state file with batch completion 6. PURGE detailed findings from context, keep only 1-2 sentence summary 7. Move to next subfolder
-</action>
-
-<action>Track batches in state file:
-findings.batches_completed: [
-{"path": "{{subfolder_path}}", "files_scanned": {{count}}, "summary": "{{brief_summary}}"}
-]
-</action>
-</check>
-
-<check if="scan_level == quick">
-  <action>Use pattern matching only - do NOT read source files</action>
-  <action>Use glob/grep to identify file locations and patterns</action>
-  <action>Extract information from filenames, directory structure, and config files only</action>
-</check>
-
-<action>For each part, check documentation_requirements boolean flags and execute corresponding scans:</action>
-
-<check if="requires_api_scan == true">
-  <action>Scan for API routes and endpoints using integration_scan_patterns</action>
-  <action>Look for: controllers/, routes/, api/, handlers/, endpoints/</action>
-
-  <check if="scan_level == quick">
-    <action>Use glob to find route files, extract patterns from filenames and folder structure</action>
-  </check>
-
-  <check if="scan_level == deep OR scan_level == exhaustive">
-    <action>Read files in batches (one subfolder at a time)</action>
-    <action>Extract: HTTP methods, paths, request/response types from actual code</action>
-  </check>
-
-<action>Build API contracts catalog</action>
-<action>IMMEDIATELY write to: {output_folder}/api-contracts-{part_id}.md</action>
-<action>Validate document has all required sections</action>
-<action>Update state file with output generated</action>
-<action>PURGE detailed API data, keep only: "{{api_count}} endpoints documented"</action>
-<template-output>api_contracts\*{part_id}</template-output>
-</check>
-
-<check if="requires_data_models == true">
-  <action>Scan for data models using schema_migration_patterns</action>
-  <action>Look for: models/, schemas/, entities/, migrations/, prisma/, ORM configs</action>
-
-  <check if="scan_level == quick">
-    <action>Identify schema files via glob, parse migration file names for table discovery</action>
-  </check>
-
-  <check if="scan_level == deep OR scan_level == exhaustive">
-    <action>Read model files in batches (one subfolder at a time)</action>
-    <action>Extract: table names, fields, relationships, constraints from actual code</action>
-  </check>
-
-<action>Build database schema documentation</action>
-<action>IMMEDIATELY write to: {output_folder}/data-models-{part_id}.md</action>
-<action>Validate document completeness</action>
-<action>Update state file with output generated</action>
-<action>PURGE detailed schema data, keep only: "{{table_count}} tables documented"</action>
-<template-output>data_models\*{part_id}</template-output>
-</check>
-
-<check if="requires_state_management == true">
-  <action>Analyze state management patterns</action>
-  <action>Look for: Redux, Context API, MobX, Vuex, Pinia, Provider patterns</action>
-  <action>Identify: stores, reducers, actions, state structure</action>
-  <template-output>state_management_patterns_{part_id}</template-output>
-</check>
-
-<check if="requires_ui_components == true">
-  <action>Inventory UI component library</action>
-  <action>Scan: components/, ui/, widgets/, views/ folders</action>
-  <action>Categorize: Layout, Form, Display, Navigation, etc.</action>
-  <action>Identify: Design system, component patterns, reusable elements</action>
-  <template-output>ui_component_inventory_{part_id}</template-output>
-</check>
-
-<check if="requires_hardware_docs == true">
-  <action>Look for hardware schematics using hardware_interface_patterns</action>
-  <ask>This appears to be an embedded/hardware project. Do you have:
-  - Pinout diagrams
-  - Hardware schematics
-  - PCB layouts
-  - Hardware documentation
-
-If yes, please provide paths or links. [Provide paths or type 'none']
-</ask>
-<action>Store hardware docs references</action>
-<template-output>hardware*documentation*{part_id}</template-output>
-</check>
-
-<check if="requires_asset_inventory == true">
-  <action>Scan and catalog assets using asset_patterns</action>
-  <action>Categorize by: Images, Audio, 3D Models, Sprites, Textures, etc.</action>
-  <action>Calculate: Total size, file counts, formats used</action>
-  <template-output>asset_inventory_{part_id}</template-output>
-</check>
-
-<action>Scan for additional patterns based on doc requirements:
-
-- config_patterns → Configuration management
-- auth_security_patterns → Authentication/authorization approach
-- entry_point_patterns → Application entry points and bootstrap
-- shared_code_patterns → Shared libraries and utilities
-- async_event_patterns → Event-driven architecture
-- ci_cd_patterns → CI/CD pipeline details
-- localization_patterns → i18n/l10n support
-  </action>
-
-<action>Apply scan_level strategy to each pattern scan (quick=glob only, deep/exhaustive=read files)</action>
-
-<template-output>comprehensive*analysis*{part_id}</template-output>
-
-<action>Update state file:
-
-- Add to completed_steps: {"step": "step_4", "status": "completed", "timestamp": "{{now}}", "summary": "Conditional analysis complete, {{files_generated}} files written"}
-- Update current_step = "step_5"
-- Update last_updated timestamp
-- List all outputs_generated
-  </action>
-
-<action>PURGE all detailed scan results from context. Keep only summaries:
-
-- "APIs: {{api_count}} endpoints"
-- "Data: {{table_count}} tables"
-- "Components: {{component_count}} components"
-  </action>
-  </step>
-
-<step n="5" goal="Generate source tree analysis with annotations" if="workflow_mode != deep_dive">
-<action>For each part, generate complete directory tree using critical_directories from doc requirements</action>
-
-<action>Annotate the tree with:
-
-- Purpose of each critical directory
-- Entry points marked
-- Key file locations highlighted
-- Integration points noted (for multi-part projects)
-  </action>
-
-<action if="multi-part project">Show how parts are organized and where they interface</action>
-
-<action>Create formatted source tree with descriptions:
-
-```
-project-root/
-├── client/          # React frontend (Part: client)
-│   ├── src/
-│   │   ├── components/  # Reusable UI components
-│   │   ├── pages/       # Route-based pages
-│   │   └── api/         # API client layer → Calls server/
-├── server/          # Express API backend (Part: api)
-│   ├── src/
-│   │   ├── routes/      # REST API endpoints
-│   │   ├── models/      # Database models
-│   │   └── services/    # Business logic
-```
-
-</action>
-
-<template-output>source_tree_analysis</template-output>
-<template-output>critical_folders_summary</template-output>
-
-<action>IMMEDIATELY write source-tree-analysis.md to disk</action>
-<action>Validate document structure</action>
-<action>Update state file:
-
-- Add to completed_steps: {"step": "step_5", "status": "completed", "timestamp": "{{now}}", "summary": "Source tree documented"}
-- Update current_step = "step_6"
-- Add output: "source-tree-analysis.md"
-  </action>
-  <action>PURGE detailed tree from context, keep only: "Source tree with {{folder_count}} critical folders"</action>
-  </step>
-
-<step n="6" goal="Extract development and operational information" if="workflow_mode != deep_dive">
-<action>Scan for development setup using key_file_patterns and existing docs:
-- Prerequisites (Node version, Python version, etc.)
-- Installation steps (npm install, etc.)
-- Environment setup (.env files, config)
-- Build commands (npm run build, make, etc.)
-- Run commands (npm start, go run, etc.)
-- Test commands using test_file_patterns
-</action>
-
-<action>Look for deployment configuration using ci_cd_patterns:
-
-- Dockerfile, docker-compose.yml
-- Kubernetes configs (k8s/, helm/)
-- CI/CD pipelines (.github/workflows/, .gitlab-ci.yml)
-- Deployment scripts
-- Infrastructure as Code (terraform/, pulumi/)
-  </action>
-
-<action if="CONTRIBUTING.md or similar found">
-  <action>Extract contribution guidelines:
-    - Code style rules
-    - PR process
-    - Commit conventions
-    - Testing requirements
-  </action>
-</action>
-
-<template-output>development_instructions</template-output>
-<template-output>deployment_configuration</template-output>
-<template-output>contribution_guidelines</template-output>
-
-<action>Update state file:
-
-- Add to completed_steps: {"step": "step_6", "status": "completed", "timestamp": "{{now}}", "summary": "Dev/deployment guides written"}
-- Update current_step = "step_7"
-- Add generated outputs to list
-  </action>
-  <action>PURGE detailed instructions, keep only: "Dev setup and deployment documented"</action>
-  </step>
-
-<step n="7" goal="Detect multi-part integration architecture" if="workflow_mode != deep_dive and project has multiple parts">
-<action>Analyze how parts communicate:
-- Scan integration_scan_patterns across parts
-- Identify: REST calls, GraphQL queries, gRPC, message queues, shared databases
-- Document: API contracts between parts, data flow, authentication flow
-</action>
-
-<action>Create integration_points array with:
-
-- from: source part
-- to: target part
-- type: REST API, GraphQL, gRPC, Event Bus, etc.
-- details: Endpoints, protocols, data formats
-  </action>
-
-<action>IMMEDIATELY write integration-architecture.md to disk</action>
-<action>Validate document completeness</action>
-
-<template-output>integration_architecture</template-output>
-
-<action>Update state file:
-
-- Add to completed_steps: {"step": "step_7", "status": "completed", "timestamp": "{{now}}", "summary": "Integration architecture documented"}
-- Update current_step = "step_8"
-  </action>
-  <action>PURGE integration details, keep only: "{{integration_count}} integration points"</action>
-  </step>
-
-<step n="8" goal="Generate architecture documentation for each part" if="workflow_mode != deep_dive">
-<action>For each part in project_parts:
-  - Use matched architecture template from Step 3 as base structure
-  - Fill in all sections with discovered information:
-    * Executive Summary
-    * Technology Stack (from Step 3)
-    * Architecture Pattern (from registry match)
-    * Data Architecture (from Step 4 data models scan)
-    * API Design (from Step 4 API scan if applicable)
-    * Component Overview (from Step 4 component scan if applicable)
-    * Source Tree (from Step 5)
-    * Development Workflow (from Step 6)
-    * Deployment Architecture (from Step 6)
-    * Testing Strategy (from test patterns)
-</action>
-
-<action if="single part project">
-  - Generate: architecture.md (no part suffix)
-</action>
-
-<action if="multi-part project">
-  - Generate: architecture-{part_id}.md for each part
-</action>
-
-<action>For each architecture file generated:
-
-- IMMEDIATELY write architecture file to disk
-- Validate against architecture template schema
-- Update state file with output
-- PURGE detailed architecture from context, keep only: "Architecture for {{part_id}} written"
-  </action>
-
-<template-output>architecture_document</template-output>
-
-<action>Update state file:
-
-- Add to completed_steps: {"step": "step_8", "status": "completed", "timestamp": "{{now}}", "summary": "Architecture docs written for {{parts_count}} parts"}
-- Update current_step = "step_9"
-  </action>
-  </step>
-
-<step n="9" goal="Generate supporting documentation files" if="workflow_mode != deep_dive">
-<action>Generate project-overview.md with:
-- Project name and purpose (from README or user input)
-- Executive summary
-- Tech stack summary table
-- Architecture type classification
-- Repository structure (monolith/monorepo/multi-part)
-- Links to detailed docs
-</action>
-
-<action>Generate source-tree-analysis.md with:
-
-- Full annotated directory tree from Step 5
-- Critical folders explained
-- Entry points documented
-- Multi-part structure (if applicable)
-  </action>
-
-<action>IMMEDIATELY write project-overview.md to disk</action>
-<action>Validate document sections</action>
-
-<action>Generate source-tree-analysis.md (if not already written in Step 5)</action>
-<action>IMMEDIATELY write to disk and validate</action>
-
-<action>Generate component-inventory.md (or per-part versions) with:
-
-- All discovered components from Step 4
-- Categorized by type
-- Reusable vs specific components
-- Design system elements (if found)
-  </action>
-  <action>IMMEDIATELY write each component inventory to disk and validate</action>
-
-<action>Generate development-guide.md (or per-part versions) with:
-
-- Prerequisites and dependencies
-- Environment setup instructions
-- Local development commands
-- Build process
-- Testing approach and commands
-- Common development tasks
-  </action>
-  <action>IMMEDIATELY write each development guide to disk and validate</action>
-
-<action if="deployment configuration found">
-  <action>Generate deployment-guide.md with:
-    - Infrastructure requirements
-    - Deployment process
-    - Environment configuration
-    - CI/CD pipeline details
-  </action>
-  <action>IMMEDIATELY write to disk and validate</action>
-</action>
-
-<action if="contribution guidelines found">
-  <action>Generate contribution-guide.md with:
-    - Code style and conventions
-    - PR process
-    - Testing requirements
-    - Documentation standards
-  </action>
-  <action>IMMEDIATELY write to disk and validate</action>
-</action>
-
-<action if="API contracts documented">
-  <action>Generate api-contracts.md (or per-part) with:
-    - All API endpoints
-    - Request/response schemas
-    - Authentication requirements
-    - Example requests
-  </action>
-  <action>IMMEDIATELY write to disk and validate</action>
-</action>
-
-<action if="Data models documented">
-  <action>Generate data-models.md (or per-part) with:
-    - Database schema
-    - Table relationships
-    - Data models and entities
-    - Migration strategy
-  </action>
-  <action>IMMEDIATELY write to disk and validate</action>
-</action>
-
-<action if="multi-part project">
-  <action>Generate integration-architecture.md with:
-    - How parts communicate
-    - Integration points diagram/description
-    - Data flow between parts
-    - Shared dependencies
-  </action>
-  <action>IMMEDIATELY write to disk and validate</action>
-
-<action>Generate project-parts.json metadata file:
-`json
-    {
-      "repository_type": "monorepo",
-      "parts": [ ... ],
-      "integration_points": [ ... ]
-    }
-    `
-</action>
-<action>IMMEDIATELY write to disk</action>
-</action>
-
-<template-output>supporting_documentation</template-output>
-
-<action>Update state file:
-
-- Add to completed_steps: {"step": "step_9", "status": "completed", "timestamp": "{{now}}", "summary": "All supporting docs written"}
-- Update current_step = "step_10"
-- List all newly generated outputs
-  </action>
-
-<action>PURGE all document contents from context, keep only list of files generated</action>
-</step>
-
-<step n="10" goal="Generate master index as primary AI retrieval source" if="workflow_mode != deep_dive">
-
-<critical>INCOMPLETE DOCUMENTATION MARKER CONVENTION:
-When a document SHOULD be generated but wasn't (due to quick scan, missing data, conditional requirements not met):
-
-- Use EXACTLY this marker: _(To be generated)_
-- Place it at the end of the markdown link line
-- Example: - [API Contracts - Server](./api-contracts-server.md) _(To be generated)_
-- This allows Step 11 to detect and offer to complete these items
-- ALWAYS use this exact format for consistency and automated detection
-  </critical>
-
-<action>Create index.md with intelligent navigation based on project structure</action>
-
-<action if="single part project">
-  <action>Generate simple index with:
-    - Project name and type
-    - Quick reference (tech stack, architecture type)
-    - Links to all generated docs
-    - Links to discovered existing docs
-    - Getting started section
-  </action>
-</action>
-
-<action if="multi-part project">
-  <action>Generate comprehensive index with:
-    - Project overview and structure summary
-    - Part-based navigation section
-    - Quick reference by part
-    - Cross-part integration links
-    - Links to all generated and existing docs
-    - Getting started per part
-  </action>
-</action>
-
-<action>Include in index.md:
-
-## Project Documentation Index
-
-### Project Overview
-
-- **Type:** {{repository_type}} {{#if multi-part}}with {{parts.length}} parts{{/if}}
-- **Primary Language:** {{primary_language}}
-- **Architecture:** {{architecture_type}}
-
-### Quick Reference
-
-{{#if single_part}}
-
-- **Tech Stack:** {{tech_stack_summary}}
-- **Entry Point:** {{entry_point}}
-- **Architecture Pattern:** {{architecture_pattern}}
-  {{else}}
-  {{#each parts}}
-
-#### {{part_name}} ({{part_id}})
-
-- **Type:** {{project_type}}
-- **Tech Stack:** {{tech_stack}}
-- **Root:** {{root_path}}
-  {{/each}}
-  {{/if}}
-
-### Generated Documentation
-
-- [Project Overview](./project-overview.md)
-- [Architecture](./architecture{{#if multi-part}}-{part\*id}{{/if}}.md){{#unless architecture_file_exists}} (To be generated) {{/unless}}
-- [Source Tree Analysis](./source-tree-analysis.md)
-- [Component Inventory](./component-inventory{{#if multi-part}}-{part\*id}{{/if}}.md){{#unless component_inventory_exists}} (To be generated) {{/unless}}
-- [Development Guide](./development-guide{{#if multi-part}}-{part\*id}{{/if}}.md){{#unless dev_guide_exists}} (To be generated) {{/unless}}
-  {{#if deployment_found}}- [Deployment Guide](./deployment-guide.md){{#unless deployment_guide_exists}} (To be generated) {{/unless}}{{/if}}
-  {{#if contribution_found}}- [Contribution Guide](./contribution-guide.md){{/if}}
-  {{#if api_documented}}- [API Contracts](./api-contracts{{#if multi-part}}-{part_id}{{/if}}.md){{#unless api_contracts_exists}} (To be generated) {{/unless}}{{/if}}
-  {{#if data_models_documented}}- [Data Models](./data-models{{#if multi-part}}-{part_id}{{/if}}.md){{#unless data_models_exists}} (To be generated) {{/unless}}{{/if}}
-  {{#if multi-part}}- [Integration Architecture](./integration-architecture.md){{#unless integration_arch_exists}} (To be generated) {{/unless}}{{/if}}
-
-### Existing Documentation
-
-{{#each existing_docs}}
-
-- [{{title}}]({{relative_path}}) - {{description}}
-  {{/each}}
-
-### Getting Started
-
-{{getting_started_instructions}}
-</action>
-
-<action>Before writing index.md, check which expected files actually exist:
-
-- For each document that should have been generated, check if file exists on disk
-- Set existence flags: architecture_file_exists, component_inventory_exists, dev_guide_exists, etc.
-- These flags determine whether to add the _(To be generated)_ marker
-- Track which files are missing in {{missing_docs_list}} for reporting
-  </action>
-
-<action>IMMEDIATELY write index.md to disk with appropriate _(To be generated)_ markers for missing files</action>
-<action>Validate index has all required sections and links are valid</action>
-
-<template-output>index</template-output>
-
-<action>Update state file:
-
-- Add to completed_steps: {"step": "step_10", "status": "completed", "timestamp": "{{now}}", "summary": "Master index generated"}
-- Update current_step = "step_11"
-- Add output: "index.md"
-  </action>
-
-<action>PURGE index content from context</action>
-</step>
-
-<step n="11" goal="Validate and review generated documentation" if="workflow_mode != deep_dive">
-<action>Show summary of all generated files:
-Generated in {{output_folder}}/:
-{{file_list_with_sizes}}
-</action>
-
-<action>Run validation checklist from {validation}</action>
-
-<critical>INCOMPLETE DOCUMENTATION DETECTION:
-
-1. PRIMARY SCAN: Look for exact marker: _(To be generated)_
-2. FALLBACK SCAN: Look for fuzzy patterns (in case agent was lazy):
-   - _(TBD)_
-   - _(TODO)_
-   - _(Coming soon)_
-   - _(Not yet generated)_
-   - _(Pending)_
-3. Extract document metadata from each match for user selection
-   </critical>
-
-<action>Read {output_folder}/index.md</action>
-
-<action>Scan for incomplete documentation markers:
-Step 1: Search for exact pattern "_(To be generated)_" (case-sensitive)
-Step 2: For each match found, extract the entire line
-Step 3: Parse line to extract:
-
-- Document title (text within [brackets] or **bold**)
-- File path (from markdown link or inferable from title)
-- Document type (infer from filename: architecture, api-contracts, data-models, component-inventory, development-guide, deployment-guide, integration-architecture)
-- Part ID if applicable (extract from filename like "architecture-server.md" → part_id: "server")
-  Step 4: Add to {{incomplete_docs_strict}} array
-  </action>
-
-<action>Fallback fuzzy scan for alternate markers:
-Search for patterns: _(TBD)_, _(TODO)_, _(Coming soon)_, _(Not yet generated)_, _(Pending)_
-For each fuzzy match:
-
-- Extract same metadata as strict scan
-- Add to {{incomplete_docs_fuzzy}} array with fuzzy_match flag
-  </action>
-
-<action>Combine results:
-Set {{incomplete_docs_list}} = {{incomplete_docs_strict}} + {{incomplete_docs_fuzzy}}
-For each item store structure:
-{
-"title": "Architecture – Server",
-"file\*path": "./architecture-server.md",
-"doc_type": "architecture",
-"part_id": "server",
-"line_text": "- [Architecture – Server](./architecture-server.md) (To be generated)",
-"fuzzy_match": false
-}
-</action>
-
-<ask>Documentation generation complete!
-
-Summary:
-
-- Project Type: {{project_type_summary}}
-- Parts Documented: {{parts_count}}
-- Files Generated: {{files_count}}
-- Total Lines: {{total_lines}}
-
-{{#if incomplete_docs_list.length > 0}}
-⚠️ **Incomplete Documentation Detected:**
-
-I found {{incomplete_docs_list.length}} item(s) marked as incomplete:
-
-{{#each incomplete_docs_list}}
-{{@index + 1}}. **{{title}}** ({{doc_type}}{{#if part_id}} for {{part_id}}{{/if}}){{#if fuzzy_match}} ⚠️ [non-standard marker]{{/if}}
-{{/each}}
-
-{{/if}}
-
-Would you like to:
-
-{{#if incomplete_docs_list.length > 0}}
-
-1. **Generate incomplete documentation** - Complete any of the {{incomplete_docs_list.length}} items above
-2. Review any specific section [type section name]
-3. Add more detail to any area [type area name]
-4. Generate additional custom documentation [describe what]
-5. Finalize and complete [type 'done']
-   {{else}}
-6. Review any specific section [type section name]
-7. Add more detail to any area [type area name]
-8. Generate additional documentation [describe what]
-9. Finalize and complete [type 'done']
-   {{/if}}
-
-Your choice:
-</ask>
-
-<check if="user selects option 1 (generate incomplete)">
-  <ask>Which incomplete items would you like to generate?
-
-{{#each incomplete_docs_list}}
-{{@index + 1}}. {{title}} ({{doc_type}}{{#if part_id}} - {{part_id}}{{/if}})
-{{/each}}
-{{incomplete_docs_list.length + 1}}. All of them
-
-Enter number(s) separated by commas (e.g., "1,3,5"), or type 'all':
-</ask>
-
-<action>Parse user selection:
-
-- If "all", set {{selected_items}} = all items in {{incomplete_docs_list}}
-- If comma-separated numbers, extract selected items by index
-- Store result in {{selected_items}} array
-  </action>
-
-  <action>Display: "Generating {{selected_items.length}} document(s)..."</action>
-
-  <action>For each item in {{selected_items}}:
-
-1. **Identify the part and requirements:**
-   - Extract part_id from item (if exists)
-   - Look up part data in project_parts array from state file
-   - Load documentation_requirements for that part's project_type_id
-
-2. **Route to appropriate generation substep based on doc_type:**
-
-   **If doc_type == "architecture":**
-   - Display: "Generating architecture documentation for {{part_id}}..."
-   - Load architecture_match for this part from state file (Step 3 cache)
-   - Re-run Step 8 architecture generation logic ONLY for this specific part
-   - Use matched template and fill with cached data from state file
-   - Write architecture-{{part_id}}.md to disk
-   - Validate completeness
-
-   **If doc_type == "api-contracts":**
-   - Display: "Generating API contracts for {{part_id}}..."
-   - Load part data and documentation_requirements
-   - Re-run Step 4 API scan substep targeting ONLY this part
-   - Use scan_level from state file (quick/deep/exhaustive)
-   - Generate api-contracts-{{part_id}}.md
-   - Validate document structure
-
-   **If doc_type == "data-models":**
-   - Display: "Generating data models documentation for {{part_id}}..."
-   - Re-run Step 4 data models scan substep targeting ONLY this part
-   - Use schema_migration_patterns from documentation_requirements
-   - Generate data-models-{{part_id}}.md
-   - Validate completeness
-
-   **If doc_type == "component-inventory":**
-   - Display: "Generating component inventory for {{part_id}}..."
-   - Re-run Step 9 component inventory generation for this specific part
-   - Scan components/, ui/, widgets/ folders
-   - Generate component-inventory-{{part_id}}.md
-   - Validate structure
-
-   **If doc_type == "development-guide":**
-   - Display: "Generating development guide for {{part_id}}..."
-   - Re-run Step 9 development guide generation for this specific part
-   - Use key_file_patterns and test_file_patterns from documentation_requirements
-   - Generate development-guide-{{part_id}}.md
-   - Validate completeness
-
-   **If doc_type == "deployment-guide":**
-   - Display: "Generating deployment guide..."
-   - Re-run Step 6 deployment configuration scan
-   - Re-run Step 9 deployment guide generation
-   - Generate deployment-guide.md
-   - Validate structure
-
-   **If doc_type == "integration-architecture":**
-   - Display: "Generating integration architecture..."
-   - Re-run Step 7 integration analysis for all parts
-   - Generate integration-architecture.md
-   - Validate completeness
-
-3. **Post-generation actions:**
-   - Confirm file was written successfully
-   - Update state file with newly generated output
-   - Add to {{newly_generated_docs}} tracking list
-   - Display: "✓ Generated: {{file_path}}"
-
-4. **Handle errors:**
-   - If generation fails, log error and continue with next item
-   - Track failed items in {{failed_generations}} list
-     </action>
-
-<action>After all selected items are processed:
-
-**Update index.md to remove markers:**
-
-1. Read current index.md content
-2. For each item in {{newly_generated_docs}}:
-   - Find the line containing the file link and marker
-   - Remove the _(To be generated)_ or fuzzy marker text
-   - Leave the markdown link intact
-3. Write updated index.md back to disk
-4. Update state file to record index.md modification
-   </action>
-
-<action>Display generation summary:
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-✓ **Documentation Generation Complete!**
-
-**Successfully Generated:**
-{{#each newly_generated_docs}}
-
-- {{title}} → {{file_path}}
-  {{/each}}
-
-{{#if failed_generations.length > 0}}
-**Failed to Generate:**
-{{#each failed_generations}}
-
-- {{title}} ({{error_message}})
-  {{/each}}
-  {{/if}}
-
-**Updated:** index.md (removed incomplete markers)
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-</action>
-
-<action>Update state file with all generation activities</action>
-
-<action>Return to Step 11 menu (loop back to check for any remaining incomplete items)</action>
-</check>
-
-<action if="user requests other changes (options 2-3)">Make requested modifications and regenerate affected files</action>
-<action if="user selects finalize (option 4 or 5)">Proceed to Step 12 completion</action>
-
-<check if="not finalizing">
-  <action>Update state file:
-- Add to completed_steps: {"step": "step_11_iteration", "status": "completed", "timestamp": "{{now}}", "summary": "Review iteration complete"}
-- Keep current_step = "step_11" (for loop back)
-- Update last_updated timestamp
-  </action>
-  <action>Loop back to beginning of Step 11 (re-scan for remaining incomplete docs)</action>
-</check>
-
-<check if="finalizing">
-  <action>Update state file:
-- Add to completed_steps: {"step": "step_11", "status": "completed", "timestamp": "{{now}}", "summary": "Validation and review complete"}
-- Update current_step = "step_12"
-  </action>
-  <action>Proceed to Step 12</action>
-</check>
-</step>
-
-<step n="12" goal="Finalize and provide next steps" if="workflow_mode != deep_dive">
-<action>Create final summary report</action>
-<action>Compile verification recap variables:
-  - Set {{verification_summary}} to the concrete tests, validations, or scripts you executed (or "none run").
-  - Set {{open_risks}} to any remaining risks or TODO follow-ups (or "none").
-  - Set {{next_checks}} to recommended actions before merging/deploying (or "none").
-</action>
-
-<action>Display completion message:
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-## Project Documentation Complete! ✓
-
-**Location:** {{output_folder}}/
-
-**Master Index:** {{output_folder}}/index.md
-👆 This is your primary entry point for AI-assisted development
-
-**Generated Documentation:**
-{{generated_files_list}}
-
-**Next Steps:**
-
-1. Review the index.md to familiarize yourself with the documentation structure
-2. When creating a brownfield PRD, point the PRD workflow to: {{output_folder}}/index.md
-3. For UI-only features: Reference {{output_folder}}/architecture-{{ui_part_id}}.md
-4. For API-only features: Reference {{output_folder}}/architecture-{{api_part_id}}.md
-5. For full-stack features: Reference both part architectures + integration-architecture.md
-
-**Verification Recap:**
-
-- Tests/extractions executed: {{verification_summary}}
-- Outstanding risks or follow-ups: {{open_risks}}
-- Recommended next checks before PR: {{next_checks}}
-
-**Brownfield PRD Command:**
-When ready to plan new features, run the PRD workflow and provide this index as input.
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-</action>
-
-<action>FINALIZE state file:
-
-- Add to completed_steps: {"step": "step_12", "status": "completed", "timestamp": "{{now}}", "summary": "Workflow complete"}
-- Update timestamps.completed = "{{now}}"
-- Update current_step = "completed"
-- Write final state file
-  </action>
-
-<action>Display: "State file saved: {{output_folder}}/project-scan-report.json"</action>
-
-</workflow>

_bmad/bmm/workflows/document-project/workflows/full-scan.yaml

@@ -1,31 +0,0 @@
-# Full Project Scan Workflow Configuration
-name: "document-project-full-scan"
-description: "Complete project documentation workflow (initial scan or full rescan)"
-author: "BMad"
-
-# This is a sub-workflow called by document-project/workflow.yaml
-parent_workflow: "{project-root}/_bmad/bmm/workflows/document-project/workflow.yaml"
-
-# Critical variables inherited from parent
-config_source: "{project-root}/_bmad/bmb/config.yaml"
-output_folder: "{config_source}:output_folder"
-user_name: "{config_source}:user_name"
-date: system-generated
-
-# Data files
-documentation_requirements_csv: "{project-root}/_bmad/bmm/workflows/document-project/documentation-requirements.csv"
-
-# Module path and component files
-installed_path: "{project-root}/_bmad/bmm/workflows/document-project/workflows"
-template: false # Action workflow
-instructions: "{installed_path}/full-scan-instructions.md"
-validation: "{project-root}/_bmad/bmm/workflows/document-project/checklist.md"
-
-# Runtime inputs (passed from parent workflow)
-workflow_mode: "" # "initial_scan" or "full_rescan"
-scan_level: "" # "quick", "deep", or "exhaustive"
-resume_mode: false
-project_root_path: ""
-
-# Configuration
-autonomous: false # Requires user input at key decision points

_bmad/bmm/workflows/excalidraw-diagrams/_shared/excalidraw-library.json

@@ -1,90 +0,0 @@
-{
-  "type": "excalidrawlib",
-  "version": 2,
-  "library": [
-    {
-      "id": "start-end-circle",
-      "status": "published",
-      "elements": [
-        {
-          "type": "ellipse",
-          "width": 120,
-          "height": 60,
-          "strokeColor": "#1976d2",
-          "backgroundColor": "#e3f2fd",
-          "fillStyle": "solid",
-          "strokeWidth": 2,
-          "roughness": 0
-        }
-      ]
-    },
-    {
-      "id": "process-rectangle",
-      "status": "published",
-      "elements": [
-        {
-          "type": "rectangle",
-          "width": 160,
-          "height": 80,
-          "strokeColor": "#1976d2",
-          "backgroundColor": "#e3f2fd",
-          "fillStyle": "solid",
-          "strokeWidth": 2,
-          "roughness": 0,
-          "roundness": {
-            "type": 3,
-            "value": 8
-          }
-        }
-      ]
-    },
-    {
-      "id": "decision-diamond",
-      "status": "published",
-      "elements": [
-        {
-          "type": "diamond",
-          "width": 140,
-          "height": 100,
-          "strokeColor": "#f57c00",
-          "backgroundColor": "#fff3e0",
-          "fillStyle": "solid",
-          "strokeWidth": 2,
-          "roughness": 0
-        }
-      ]
-    },
-    {
-      "id": "data-store",
-      "status": "published",
-      "elements": [
-        {
-          "type": "rectangle",
-          "width": 140,
-          "height": 80,
-          "strokeColor": "#388e3c",
-          "backgroundColor": "#e8f5e9",
-          "fillStyle": "solid",
-          "strokeWidth": 2,
-          "roughness": 0
-        }
-      ]
-    },
-    {
-      "id": "external-entity",
-      "status": "published",
-      "elements": [
-        {
-          "type": "rectangle",
-          "width": 120,
-          "height": 80,
-          "strokeColor": "#7b1fa2",
-          "backgroundColor": "#f3e5f5",
-          "fillStyle": "solid",
-          "strokeWidth": 3,
-          "roughness": 0
-        }
-      ]
-    }
-  ]
-}

_bmad/bmm/workflows/excalidraw-diagrams/_shared/excalidraw-templates.yaml

@@ -1,127 +0,0 @@
-flowchart:
-  viewport:
-    x: 0
-    y: 0
-    zoom: 1
-  grid:
-    size: 20
-  spacing:
-    vertical: 100
-    horizontal: 180
-  elements:
-    start:
-      type: ellipse
-      width: 120
-      height: 60
-      label: "Start"
-    process:
-      type: rectangle
-      width: 160
-      height: 80
-      roundness: 8
-    decision:
-      type: diamond
-      width: 140
-      height: 100
-    end:
-      type: ellipse
-      width: 120
-      height: 60
-      label: "End"
-
-diagram:
-  viewport:
-    x: 0
-    y: 0
-    zoom: 1
-  grid:
-    size: 20
-  spacing:
-    vertical: 120
-    horizontal: 200
-  elements:
-    component:
-      type: rectangle
-      width: 180
-      height: 100
-      roundness: 8
-    database:
-      type: rectangle
-      width: 140
-      height: 80
-    service:
-      type: rectangle
-      width: 160
-      height: 90
-      roundness: 12
-    external:
-      type: rectangle
-      width: 140
-      height: 80
-
-wireframe:
-  viewport:
-    x: 0
-    y: 0
-    zoom: 0.8
-  grid:
-    size: 20
-  spacing:
-    vertical: 40
-    horizontal: 40
-  elements:
-    container:
-      type: rectangle
-      width: 800
-      height: 600
-      strokeStyle: solid
-      strokeWidth: 2
-    header:
-      type: rectangle
-      width: 800
-      height: 80
-    button:
-      type: rectangle
-      width: 120
-      height: 40
-      roundness: 4
-    input:
-      type: rectangle
-      width: 300
-      height: 40
-      roundness: 4
-    text:
-      type: text
-      fontSize: 16
-
-dataflow:
-  viewport:
-    x: 0
-    y: 0
-    zoom: 1
-  grid:
-    size: 20
-  spacing:
-    vertical: 120
-    horizontal: 200
-  elements:
-    process:
-      type: ellipse
-      width: 140
-      height: 80
-      label: "Process"
-    datastore:
-      type: rectangle
-      width: 140
-      height: 80
-      label: "Data Store"
-    external:
-      type: rectangle
-      width: 120
-      height: 80
-      strokeWidth: 3
-      label: "External Entity"
-    dataflow:
-      type: arrow
-      strokeWidth: 2
-      label: "Data Flow"

_bmad/bmm/workflows/excalidraw-diagrams/create-dataflow/checklist.md

@@ -1,39 +0,0 @@
-# Create Data Flow Diagram - Validation Checklist
-
-## DFD Notation
-
-- [ ] Processes shown as circles/ellipses
-- [ ] Data stores shown as parallel lines or rectangles
-- [ ] External entities shown as rectangles
-- [ ] Data flows shown as labeled arrows
-- [ ] Follows standard DFD notation
-
-## Structure
-
-- [ ] All processes numbered correctly
-- [ ] All data flows labeled with data names
-- [ ] All data stores named appropriately
-- [ ] External entities clearly identified
-
-## Completeness
-
-- [ ] All inputs and outputs accounted for
-- [ ] No orphaned processes (unconnected)
-- [ ] Data conservation maintained
-- [ ] Level appropriate (context/level 0/level 1)
-
-## Layout
-
-- [ ] Logical flow direction (left to right, top to bottom)
-- [ ] No crossing data flows where avoidable
-- [ ] Balanced layout
-- [ ] Grid alignment maintained
-
-## Technical Quality
-
-- [ ] All elements properly grouped
-- [ ] Arrows have proper bindings
-- [ ] Text readable and properly sized
-- [ ] No elements with `isDeleted: true`
-- [ ] JSON is valid
-- [ ] File saved to correct location

_bmad/bmm/workflows/excalidraw-diagrams/create-dataflow/instructions.md

@@ -1,130 +0,0 @@
-# Create Data Flow Diagram - Workflow Instructions
-
-```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>This workflow creates data flow diagrams (DFD) in Excalidraw format.</critical>
-
-<workflow>
-
-  <step n="0" goal="Contextual Analysis">
-    <action>Review user's request and extract: DFD level, processes, data stores, external entities</action>
-    <check if="ALL requirements clear"><action>Skip to Step 4</action></check>
-  </step>
-
-  <step n="1" goal="Identify DFD Level" elicit="true">
-    <action>Ask: "What level of DFD do you need?"</action>
-    <action>Present options:
-      1. Context Diagram (Level 0) - Single process showing system boundaries
-      2. Level 1 DFD - Major processes and data flows
-      3. Level 2 DFD - Detailed sub-processes
-      4. Custom - Specify your requirements
-    </action>
-    <action>WAIT for selection</action>
-  </step>
-
-  <step n="2" goal="Gather Requirements" elicit="true">
-    <action>Ask: "Describe the processes, data stores, and external entities in your system"</action>
-    <action>WAIT for user description</action>
-    <action>Summarize what will be included and confirm with user</action>
-  </step>
-
-  <step n="3" goal="Theme Setup" elicit="true">
-    <action>Check for existing theme.json, ask to use if exists</action>
-    <check if="no existing theme">
-      <action>Ask: "Choose a DFD color scheme:"</action>
-      <action>Present numbered options:
-        1. Standard DFD
-           - Process: #e3f2fd (light blue)
-           - Data Store: #e8f5e9 (light green)
-           - External Entity: #f3e5f5 (light purple)
-           - Border: #1976d2 (blue)
-
-        2. Colorful DFD
-           - Process: #fff9c4 (light yellow)
-           - Data Store: #c5e1a5 (light lime)
-           - External Entity: #ffccbc (light coral)
-           - Border: #f57c00 (orange)
-
-        3. Minimal DFD
-           - Process: #f5f5f5 (light gray)
-           - Data Store: #eeeeee (gray)
-           - External Entity: #e0e0e0 (medium gray)
-           - Border: #616161 (dark gray)
-
-        4. Custom - Define your own colors
-      </action>
-      <action>WAIT for selection</action>
-      <action>Create theme.json based on selection</action>
-    </check>
-  </step>
-
-  <step n="4" goal="Plan DFD Structure">
-    <action>List all processes with numbers (1.0, 2.0, etc.)</action>
-    <action>List all data stores (D1, D2, etc.)</action>
-    <action>List all external entities</action>
-    <action>Map all data flows with labels</action>
-    <action>Show planned structure, confirm with user</action>
-  </step>
-
-  <step n="5" goal="Load Resources">
-    <action>Load {{templates}} and extract `dataflow` section</action>
-    <action>Load {{library}}</action>
-    <action>Load theme.json</action>
-    <action>Load {{helpers}}</action>
-  </step>
-
-  <step n="6" goal="Build DFD Elements">
-    <critical>Follow standard DFD notation from {{helpers}}</critical>
-
-    <substep>Build Order:
-      1. External entities (rectangles, bold border)
-      2. Processes (circles/ellipses with numbers)
-      3. Data stores (parallel lines or rectangles)
-      4. Data flows (labeled arrows)
-    </substep>
-
-    <substep>DFD Rules:
-      - Processes: Numbered (1.0, 2.0), verb phrases
-      - Data stores: Named (D1, D2), noun phrases
-      - External entities: Named, noun phrases
-      - Data flows: Labeled with data names, arrows show direction
-      - No direct flow between external entities
-      - No direct flow between data stores
-    </substep>
-
-    <substep>Layout:
-      - External entities at edges
-      - Processes in center
-      - Data stores between processes
-      - Minimize crossing flows
-      - Left-to-right or top-to-bottom flow
-    </substep>
-  </step>
-
-  <step n="7" goal="Optimize and Save">
-    <action>Verify DFD rules compliance</action>
-    <action>Strip unused elements and elements with isDeleted: true</action>
-    <action>Save to {{default_output_file}}</action>
-  </step>
-
-  <step n="8" goal="Validate JSON Syntax">
-    <critical>NEVER delete the file if validation fails - always fix syntax errors</critical>
-    <action>Run: node -e "JSON.parse(require('fs').readFileSync('{{default_output_file}}', 'utf8')); console.log('✓ Valid JSON')"</action>
-    <check if="validation fails (exit code 1)">
-      <action>Read the error message carefully - it shows the syntax error and position</action>
-      <action>Open the file and navigate to the error location</action>
-      <action>Fix the syntax error (add missing comma, bracket, or quote as indicated)</action>
-      <action>Save the file</action>
-      <action>Re-run validation with the same command</action>
-      <action>Repeat until validation passes</action>
-    </check>
-    <action>Once validation passes, confirm with user</action>
-  </step>
-
-  <step n="9" goal="Validate Content">
-    <invoke-task>Validate against {{validation}}</invoke-task>
-  </step>
-
-</workflow>
-```

_bmad/bmm/workflows/excalidraw-diagrams/create-dataflow/workflow.yaml

@@ -1,26 +0,0 @@
-name: create-excalidraw-dataflow
-description: "Create data flow diagrams (DFD) in Excalidraw format"
-author: "BMad"
-
-# Config values
-config_source: "{project-root}/_bmad/bmm/config.yaml"
-output_folder: "{config_source}:output_folder"
-
-# Workflow components
-installed_path: "{project-root}/_bmad/bmm/workflows/excalidraw-diagrams/create-dataflow"
-shared_path: "{project-root}/_bmad/bmm/workflows/excalidraw-diagrams/_shared"
-instructions: "{installed_path}/instructions.md"
-validation: "{installed_path}/checklist.md"
-
-# Core Excalidraw resources (universal knowledge)
-helpers: "{project-root}/_bmad/core/resources/excalidraw/excalidraw-helpers.md"
-json_validation: "{project-root}/_bmad/core/resources/excalidraw/validate-json-instructions.md"
-
-# Domain-specific resources (technical diagrams)
-templates: "{shared_path}/excalidraw-templates.yaml"
-library: "{shared_path}/excalidraw-library.json"
-
-# Output file (respects user's configured output_folder)
-default_output_file: "{output_folder}/excalidraw-diagrams/dataflow-{timestamp}.excalidraw"
-
-standalone: true

_bmad/bmm/workflows/excalidraw-diagrams/create-diagram/checklist.md

@@ -1,43 +0,0 @@
-# Create Diagram - Validation Checklist
-
-## Element Structure
-
-- [ ] All components with labels have matching `groupIds`
-- [ ] All text elements have `containerId` pointing to parent component
-- [ ] Text width calculated properly (no cutoff)
-- [ ] Text alignment appropriate for diagram type
-
-## Layout and Alignment
-
-- [ ] All elements snapped to 20px grid
-- [ ] Component spacing consistent (40px/60px)
-- [ ] Hierarchical alignment maintained
-- [ ] No overlapping elements
-
-## Connections
-
-- [ ] All arrows have `startBinding` and `endBinding`
-- [ ] `boundElements` array updated on connected components
-- [ ] Arrow routing avoids overlaps
-- [ ] Relationship types clearly indicated
-
-## Notation and Standards
-
-- [ ] Follows specified notation standard (UML/ERD/etc)
-- [ ] Symbols used correctly
-- [ ] Cardinality/multiplicity shown where needed
-- [ ] Labels and annotations clear
-
-## Theme and Styling
-
-- [ ] Theme colors applied consistently
-- [ ] Component types visually distinguishable
-- [ ] Text is readable
-- [ ] Professional appearance
-
-## Output Quality
-
-- [ ] Element count under 80
-- [ ] No elements with `isDeleted: true`
-- [ ] JSON is valid
-- [ ] File saved to correct location

_bmad/bmm/workflows/excalidraw-diagrams/create-diagram/instructions.md

@@ -1,141 +0,0 @@
-# Create Diagram - Workflow Instructions
-
-```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>This workflow creates system architecture diagrams, ERDs, UML diagrams, or general technical diagrams in Excalidraw format.</critical>
-
-<workflow>
-
-  <step n="0" goal="Contextual Analysis">
-    <action>Review user's request and extract: diagram type, components/entities, relationships, notation preferences</action>
-    <check if="ALL requirements clear"><action>Skip to Step 5</action></check>
-    <check if="SOME requirements clear"><action>Only ask about missing info in Steps 1-2</action></check>
-  </step>
-
-  <step n="1" goal="Identify Diagram Type" elicit="true">
-    <action>Ask: "What type of technical diagram do you need?"</action>
-    <action>Present options:
-      1. System Architecture
-      2. Entity-Relationship Diagram (ERD)
-      3. UML Class Diagram
-      4. UML Sequence Diagram
-      5. UML Use Case Diagram
-      6. Network Diagram
-      7. Other
-    </action>
-    <action>WAIT for selection</action>
-  </step>
-
-  <step n="2" goal="Gather Requirements" elicit="true">
-    <action>Ask: "Describe the components/entities and their relationships"</action>
-    <action>Ask: "What notation standard? (Standard/Simplified/Strict UML-ERD)"</action>
-    <action>WAIT for user input</action>
-    <action>Summarize what will be included and confirm with user</action>
-  </step>
-
-  <step n="3" goal="Check for Existing Theme" elicit="true">
-    <action>Check if theme.json exists at output location</action>
-    <check if="exists"><action>Ask to use it, load if yes, else proceed to Step 4</action></check>
-    <check if="not exists"><action>Proceed to Step 4</action></check>
-  </step>
-
-  <step n="4" goal="Create Theme" elicit="true">
-    <action>Ask: "Choose a color scheme for your diagram:"</action>
-    <action>Present numbered options:
-      1. Professional
-         - Component: #e3f2fd (light blue)
-         - Database: #e8f5e9 (light green)
-         - Service: #fff3e0 (light orange)
-         - Border: #1976d2 (blue)
-
-      2. Colorful
-         - Component: #e1bee7 (light purple)
-         - Database: #c5e1a5 (light lime)
-         - Service: #ffccbc (light coral)
-         - Border: #7b1fa2 (purple)
-
-      3. Minimal
-         - Component: #f5f5f5 (light gray)
-         - Database: #eeeeee (gray)
-         - Service: #e0e0e0 (medium gray)
-         - Border: #616161 (dark gray)
-
-      4. Custom - Define your own colors
-    </action>
-    <action>WAIT for selection</action>
-    <action>Create theme.json based on selection</action>
-    <action>Show preview and confirm</action>
-  </step>
-
-  <step n="5" goal="Plan Diagram Structure">
-    <action>List all components/entities</action>
-    <action>Map all relationships</action>
-    <action>Show planned layout</action>
-    <action>Ask: "Structure looks correct? (yes/no)"</action>
-    <check if="no"><action>Adjust and repeat</action></check>
-  </step>
-
-  <step n="6" goal="Load Resources">
-    <action>Load {{templates}} and extract `diagram` section</action>
-    <action>Load {{library}}</action>
-    <action>Load theme.json and merge with template</action>
-    <action>Load {{helpers}} for guidelines</action>
-  </step>
-
-  <step n="7" goal="Build Diagram Elements">
-    <critical>Follow {{helpers}} for proper element creation</critical>
-
-    <substep>For Each Component:
-      - Generate unique IDs (component-id, text-id, group-id)
-      - Create shape with groupIds
-      - Calculate text width
-      - Create text with containerId and matching groupIds
-      - Add boundElements
-    </substep>
-
-    <substep>For Each Connection:
-      - Determine arrow type (straight/elbow)
-      - Create with startBinding and endBinding
-      - Update boundElements on both components
-    </substep>
-
-    <substep>Build Order by Type:
-      - Architecture: Services → Databases → Connections → Labels
-      - ERD: Entities → Attributes → Relationships → Cardinality
-      - UML Class: Classes → Attributes → Methods → Relationships
-      - UML Sequence: Actors → Lifelines → Messages → Returns
-      - UML Use Case: Actors → Use Cases → Relationships
-    </substep>
-
-    <substep>Alignment:
-      - Snap to 20px grid
-      - Space: 40px between components, 60px between sections
-    </substep>
-  </step>
-
-  <step n="8" goal="Optimize and Save">
-    <action>Strip unused elements and elements with isDeleted: true</action>
-    <action>Save to {{default_output_file}}</action>
-  </step>
-
-  <step n="9" goal="Validate JSON Syntax">
-    <critical>NEVER delete the file if validation fails - always fix syntax errors</critical>
-    <action>Run: node -e "JSON.parse(require('fs').readFileSync('{{default_output_file}}', 'utf8')); console.log('✓ Valid JSON')"</action>
-    <check if="validation fails (exit code 1)">
-      <action>Read the error message carefully - it shows the syntax error and position</action>
-      <action>Open the file and navigate to the error location</action>
-      <action>Fix the syntax error (add missing comma, bracket, or quote as indicated)</action>
-      <action>Save the file</action>
-      <action>Re-run validation with the same command</action>
-      <action>Repeat until validation passes</action>
-    </check>
-    <action>Once validation passes, confirm: "Diagram created at {{default_output_file}}. Open to view?"</action>
-  </step>
-
-  <step n="10" goal="Validate Content">
-    <invoke-task>Validate against {{validation}} using {_bmad}/core/tasks/validate-workflow.xml</invoke-task>
-  </step>
-
-</workflow>
-```

_bmad/bmm/workflows/excalidraw-diagrams/create-diagram/workflow.yaml

@@ -1,26 +0,0 @@
-name: create-excalidraw-diagram
-description: "Create system architecture diagrams, ERDs, UML diagrams, or general technical diagrams in Excalidraw format"
-author: "BMad"
-
-# Config values
-config_source: "{project-root}/_bmad/bmm/config.yaml"
-output_folder: "{config_source}:output_folder"
-
-# Workflow components
-installed_path: "{project-root}/_bmad/bmm/workflows/excalidraw-diagrams/create-diagram"
-shared_path: "{project-root}/_bmad/bmm/workflows/excalidraw-diagrams/_shared"
-instructions: "{installed_path}/instructions.md"
-validation: "{installed_path}/checklist.md"
-
-# Core Excalidraw resources (universal knowledge)
-helpers: "{project-root}/_bmad/core/resources/excalidraw/excalidraw-helpers.md"
-json_validation: "{project-root}/_bmad/core/resources/excalidraw/validate-json-instructions.md"
-
-# Domain-specific resources (technical diagrams)
-templates: "{shared_path}/excalidraw-templates.yaml"
-library: "{shared_path}/excalidraw-library.json"
-
-# Output file (respects user's configured output_folder)
-default_output_file: "{output_folder}/excalidraw-diagrams/diagram-{timestamp}.excalidraw"
-
-standalone: true

_bmad/bmm/workflows/excalidraw-diagrams/create-flowchart/checklist.md

@@ -1,49 +0,0 @@
-# Create Flowchart - Validation Checklist
-
-## Element Structure
-
-- [ ] All shapes with labels have matching `groupIds`
-- [ ] All text elements have `containerId` pointing to parent shape
-- [ ] Text width calculated properly (no cutoff)
-- [ ] Text alignment set (`textAlign` + `verticalAlign`)
-
-## Layout and Alignment
-
-- [ ] All elements snapped to 20px grid
-- [ ] Consistent spacing between elements (60px minimum)
-- [ ] Vertical alignment maintained for flow direction
-- [ ] No overlapping elements
-
-## Connections
-
-- [ ] All arrows have `startBinding` and `endBinding`
-- [ ] `boundElements` array updated on connected shapes
-- [ ] Arrow types appropriate (straight for forward, elbow for backward/upward)
-- [ ] Gap set to 10 for all bindings
-
-## Theme and Styling
-
-- [ ] Theme colors applied consistently
-- [ ] All shapes use theme primary fill color
-- [ ] All borders use theme accent color
-- [ ] Text color is readable (#1e1e1e)
-
-## Composition
-
-- [ ] Element count under 50
-- [ ] Library components referenced where possible
-- [ ] No duplicate element definitions
-
-## Output Quality
-
-- [ ] No elements with `isDeleted: true`
-- [ ] JSON is valid
-- [ ] File saved to correct location
-
-## Functional Requirements
-
-- [ ] Start point clearly marked
-- [ ] End point clearly marked
-- [ ] All process steps labeled
-- [ ] Decision points use diamond shapes
-- [ ] Flow direction is clear and logical

_bmad/bmm/workflows/excalidraw-diagrams/create-flowchart/instructions.md

@@ -1,241 +0,0 @@
-# Create Flowchart - Workflow Instructions
-
-```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>This workflow creates a flowchart visualization in Excalidraw format for processes, pipelines, or logic flows.</critical>
-
-<workflow>
-
-  <step n="0" goal="Contextual Analysis (Smart Elicitation)">
-    <critical>Before asking any questions, analyze what the user has already told you</critical>
-
-    <action>Review the user's initial request and conversation history</action>
-    <action>Extract any mentioned: flowchart type, complexity, decision points, save location</action>
-
-    <check if="ALL requirements are clear from context">
-      <action>Summarize your understanding</action>
-      <action>Skip directly to Step 4 (Plan Flowchart Layout)</action>
-    </check>
-
-    <check if="SOME requirements are clear">
-      <action>Note what you already know</action>
-      <action>Only ask about missing information in Step 1</action>
-    </check>
-
-    <check if="requirements are unclear or minimal">
-      <action>Proceed with full elicitation in Step 1</action>
-    </check>
-  </step>
-
-  <step n="1" goal="Gather Requirements" elicit="true">
-    <action>Ask Question 1: "What type of process flow do you need to visualize?"</action>
-    <action>Present numbered options:
-      1. Business Process Flow - Document business workflows, approval processes, or operational procedures
-      2. Algorithm/Logic Flow - Visualize code logic, decision trees, or computational processes
-      3. User Journey Flow - Map user interactions, navigation paths, or experience flows
-      4. Data Processing Pipeline - Show data transformation, ETL processes, or processing stages
-      5. Other - Describe your specific flowchart needs
-    </action>
-    <action>WAIT for user selection (1-5)</action>
-
-    <action>Ask Question 2: "How many main steps are in this flow?"</action>
-    <action>Present numbered options:
-      1. Simple (3-5 steps) - Quick process with few decision points
-      2. Medium (6-10 steps) - Standard workflow with some branching
-      3. Complex (11-20 steps) - Detailed process with multiple decision points
-      4. Very Complex (20+ steps) - Comprehensive workflow requiring careful layout
-    </action>
-    <action>WAIT for user selection (1-4)</action>
-    <action>Store selection in {{complexity}}</action>
-
-    <action>Ask Question 3: "Does your flow include decision points (yes/no branches)?"</action>
-    <action>Present numbered options:
-      1. No decisions - Linear flow from start to end
-      2. Few decisions (1-2) - Simple branching with yes/no paths
-      3. Multiple decisions (3-5) - Several conditional branches
-      4. Complex decisions (6+) - Extensive branching logic
-    </action>
-    <action>WAIT for user selection (1-4)</action>
-    <action>Store selection in {{decision_points}}</action>
-
-    <action>Ask Question 4: "Where should the flowchart be saved?"</action>
-    <action>Present numbered options:
-      1. Default location - docs/flowcharts/[auto-generated-name].excalidraw
-      2. Custom path - Specify your own file path
-      3. Project root - Save in main project directory
-      4. Specific folder - Choose from existing folders
-    </action>
-    <action>WAIT for user selection (1-4)</action>
-    <check if="selection is 2 or 4">
-      <action>Ask for specific path</action>
-      <action>WAIT for user input</action>
-    </check>
-    <action>Store final path in {{default_output_file}}</action>
-  </step>
-
-  <step n="2" goal="Check for Existing Theme" elicit="true">
-    <action>Check if theme.json exists at output location</action>
-    <check if="theme.json exists">
-      <action>Ask: "Found existing theme. Use it? (yes/no)"</action>
-      <action>WAIT for user response</action>
-      <check if="user says yes">
-        <action>Load and use existing theme</action>
-        <action>Skip to Step 4</action>
-      </check>
-      <check if="user says no">
-        <action>Proceed to Step 3</action>
-      </check>
-    </check>
-    <check if="theme.json does not exist">
-      <action>Proceed to Step 3</action>
-    </check>
-  </step>
-
-  <step n="3" goal="Create Theme" elicit="true">
-    <action>Ask: "Let's create a theme for your flowchart. Choose a color scheme:"</action>
-    <action>Present numbered options:
-      1. Professional Blue
-         - Primary Fill: #e3f2fd (light blue)
-         - Accent/Border: #1976d2 (blue)
-         - Decision: #fff3e0 (light orange)
-         - Text: #1e1e1e (dark gray)
-
-      2. Success Green
-         - Primary Fill: #e8f5e9 (light green)
-         - Accent/Border: #388e3c (green)
-         - Decision: #fff9c4 (light yellow)
-         - Text: #1e1e1e (dark gray)
-
-      3. Neutral Gray
-         - Primary Fill: #f5f5f5 (light gray)
-         - Accent/Border: #616161 (gray)
-         - Decision: #e0e0e0 (medium gray)
-         - Text: #1e1e1e (dark gray)
-
-      4. Warm Orange
-         - Primary Fill: #fff3e0 (light orange)
-         - Accent/Border: #f57c00 (orange)
-         - Decision: #ffe0b2 (peach)
-         - Text: #1e1e1e (dark gray)
-
-      5. Custom Colors - Define your own color palette
-    </action>
-    <action>WAIT for user selection (1-5)</action>
-    <action>Store selection in {{theme_choice}}</action>
-
-    <check if="selection is 5 (Custom)">
-      <action>Ask: "Primary fill color (hex code)?"</action>
-      <action>WAIT for user input</action>
-      <action>Store in {{custom_colors.primary_fill}}</action>
-      <action>Ask: "Accent/border color (hex code)?"</action>
-      <action>WAIT for user input</action>
-      <action>Store in {{custom_colors.accent}}</action>
-      <action>Ask: "Decision color (hex code)?"</action>
-      <action>WAIT for user input</action>
-      <action>Store in {{custom_colors.decision}}</action>
-    </check>
-
-    <action>Create theme.json with selected colors</action>
-    <action>Show theme preview with all colors</action>
-    <action>Ask: "Theme looks good?"</action>
-    <action>Present numbered options:
-      1. Yes, use this theme - Proceed with theme
-      2. No, adjust colors - Modify color selections
-      3. Start over - Choose different preset
-    </action>
-    <action>WAIT for selection (1-3)</action>
-    <check if="selection is 2 or 3">
-      <action>Repeat Step 3</action>
-    </check>
-  </step>
-
-  <step n="4" goal="Plan Flowchart Layout">
-    <action>List all steps and decision points based on gathered requirements</action>
-    <action>Show user the planned structure</action>
-    <action>Ask: "Structure looks correct? (yes/no)"</action>
-    <action>WAIT for user response</action>
-    <check if="user says no">
-      <action>Adjust structure based on feedback</action>
-      <action>Repeat this step</action>
-    </check>
-  </step>
-
-  <step n="5" goal="Load Template and Resources">
-    <action>Load {{templates}} file</action>
-    <action>Extract `flowchart` section from YAML</action>
-    <action>Load {{library}} file</action>
-    <action>Load theme.json and merge colors with template</action>
-    <action>Load {{helpers}} for element creation guidelines</action>
-  </step>
-
-  <step n="6" goal="Build Flowchart Elements">
-    <critical>Follow guidelines from {{helpers}} for proper element creation</critical>
-
-    <action>Build ONE section at a time following these rules:</action>
-
-    <substep>For Each Shape with Label:
-      1. Generate unique IDs (shape-id, text-id, group-id)
-      2. Create shape with groupIds: [group-id]
-      3. Calculate text width: (text.length × fontSize × 0.6) + 20, round to nearest 10
-      4. Create text element with:
-         - containerId: shape-id
-         - groupIds: [group-id] (SAME as shape)
-         - textAlign: "center"
-         - verticalAlign: "middle"
-         - width: calculated width
-      5. Add boundElements to shape referencing text
-    </substep>
-
-    <substep>For Each Arrow:
-      1. Determine arrow type needed:
-         - Straight: For forward flow (left-to-right, top-to-bottom)
-         - Elbow: For upward flow, backward flow, or complex routing
-      2. Create arrow with startBinding and endBinding
-      3. Set startBinding.elementId to source shape ID
-      4. Set endBinding.elementId to target shape ID
-      5. Set gap: 10 for both bindings
-      6. If elbow arrow, add intermediate points for direction changes
-      7. Update boundElements on both connected shapes
-    </substep>
-
-    <substep>Alignment:
-      - Snap all x, y to 20px grid
-      - Align shapes vertically (same x for vertical flow)
-      - Space elements: 60px between shapes
-    </substep>
-
-    <substep>Build Order:
-      1. Start point (circle) with label
-      2. Each process step (rectangle) with label
-      3. Each decision point (diamond) with label
-      4. End point (circle) with label
-      5. Connect all with bound arrows
-    </substep>
-  </step>
-
-  <step n="7" goal="Optimize and Save">
-    <action>Strip unused elements and elements with isDeleted: true</action>
-    <action>Save to {{default_output_file}}</action>
-  </step>
-
-  <step n="8" goal="Validate JSON Syntax">
-    <critical>NEVER delete the file if validation fails - always fix syntax errors</critical>
-    <action>Run: node -e "JSON.parse(require('fs').readFileSync('{{default_output_file}}', 'utf8')); console.log('✓ Valid JSON')"</action>
-    <check if="validation fails (exit code 1)">
-      <action>Read the error message carefully - it shows the syntax error and position</action>
-      <action>Open the file and navigate to the error location</action>
-      <action>Fix the syntax error (add missing comma, bracket, or quote as indicated)</action>
-      <action>Save the file</action>
-      <action>Re-run validation with the same command</action>
-      <action>Repeat until validation passes</action>
-    </check>
-    <action>Once validation passes, confirm with user: "Flowchart created at {{default_output_file}}. Open to view?"</action>
-  </step>
-
-  <step n="9" goal="Validate Content">
-    <invoke-task>Validate against checklist at {{validation}} using {_bmad}/core/tasks/validate-workflow.xml</invoke-task>
-  </step>
-
-</workflow>
-```

_bmad/bmm/workflows/excalidraw-diagrams/create-flowchart/workflow.yaml

@@ -1,26 +0,0 @@
-name: create-excalidraw-flowchart
-description: "Create a flowchart visualization in Excalidraw format for processes, pipelines, or logic flows"
-author: "BMad"
-
-# Config values
-config_source: "{project-root}/_bmad/bmm/config.yaml"
-output_folder: "{config_source}:output_folder"
-
-# Workflow components
-installed_path: "{project-root}/_bmad/bmm/workflows/excalidraw-diagrams/create-flowchart"
-shared_path: "{project-root}/_bmad/bmm/workflows/excalidraw-diagrams/_shared"
-instructions: "{installed_path}/instructions.md"
-validation: "{installed_path}/checklist.md"
-
-# Core Excalidraw resources (universal knowledge)
-helpers: "{project-root}/_bmad/core/resources/excalidraw/excalidraw-helpers.md"
-json_validation: "{project-root}/_bmad/core/resources/excalidraw/validate-json-instructions.md"
-
-# Domain-specific resources (technical diagrams)
-templates: "{shared_path}/excalidraw-templates.yaml"
-library: "{shared_path}/excalidraw-library.json"
-
-# Output file (respects user's configured output_folder)
-default_output_file: "{output_folder}/excalidraw-diagrams/flowchart-{timestamp}.excalidraw"
-
-standalone: true

_bmad/bmm/workflows/excalidraw-diagrams/create-wireframe/checklist.md

@@ -1,38 +0,0 @@
-# Create Wireframe - Validation Checklist
-
-## Layout Structure
-
-- [ ] Screen dimensions appropriate for device type
-- [ ] Grid alignment (20px) maintained
-- [ ] Consistent spacing between UI elements
-- [ ] Proper hierarchy (header, content, footer)
-
-## UI Elements
-
-- [ ] All interactive elements clearly marked
-- [ ] Buttons, inputs, and controls properly sized
-- [ ] Text labels readable and appropriately sized
-- [ ] Navigation elements clearly indicated
-
-## Fidelity
-
-- [ ] Matches requested fidelity level (low/medium/high)
-- [ ] Appropriate level of detail
-- [ ] Placeholder content used where needed
-- [ ] No unnecessary decoration for low-fidelity
-
-## Annotations
-
-- [ ] Key interactions annotated
-- [ ] Flow indicators present if multi-screen
-- [ ] Important notes included
-- [ ] Element purposes clear
-
-## Technical Quality
-
-- [ ] All elements properly grouped
-- [ ] Text elements have containerId
-- [ ] Snapped to grid
-- [ ] No elements with `isDeleted: true`
-- [ ] JSON is valid
-- [ ] File saved to correct location

_bmad/bmm/workflows/excalidraw-diagrams/create-wireframe/instructions.md

@@ -1,133 +0,0 @@
-# Create Wireframe - Workflow Instructions
-
-```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>This workflow creates website or app wireframes in Excalidraw format.</critical>
-
-<workflow>
-
-  <step n="0" goal="Contextual Analysis">
-    <action>Review user's request and extract: wireframe type, fidelity level, screen count, device type, save location</action>
-    <check if="ALL requirements clear"><action>Skip to Step 5</action></check>
-  </step>
-
-  <step n="1" goal="Identify Wireframe Type" elicit="true">
-    <action>Ask: "What type of wireframe do you need?"</action>
-    <action>Present options:
-      1. Website (Desktop)
-      2. Mobile App (iOS/Android)
-      3. Web App (Responsive)
-      4. Tablet App
-      5. Multi-platform
-    </action>
-    <action>WAIT for selection</action>
-  </step>
-
-  <step n="2" goal="Gather Requirements" elicit="true">
-    <action>Ask fidelity level (Low/Medium/High)</action>
-    <action>Ask screen count (Single/Few 2-3/Multiple 4-6/Many 7+)</action>
-    <action>Ask device dimensions or use standard</action>
-    <action>Ask save location</action>
-  </step>
-
-  <step n="3" goal="Check Theme" elicit="true">
-    <action>Check for existing theme.json, ask to use if exists</action>
-  </step>
-
-  <step n="4" goal="Create Theme" elicit="true">
-    <action>Ask: "Choose a wireframe style:"</action>
-    <action>Present numbered options:
-      1. Classic Wireframe
-         - Background: #ffffff (white)
-         - Container: #f5f5f5 (light gray)
-         - Border: #9e9e9e (gray)
-         - Text: #424242 (dark gray)
-
-      2. High Contrast
-         - Background: #ffffff (white)
-         - Container: #eeeeee (light gray)
-         - Border: #212121 (black)
-         - Text: #000000 (black)
-
-      3. Blueprint Style
-         - Background: #1a237e (dark blue)
-         - Container: #3949ab (blue)
-         - Border: #7986cb (light blue)
-         - Text: #ffffff (white)
-
-      4. Custom - Define your own colors
-    </action>
-    <action>WAIT for selection</action>
-    <action>Create theme.json based on selection</action>
-    <action>Confirm with user</action>
-  </step>
-
-  <step n="5" goal="Plan Wireframe Structure">
-    <action>List all screens and their purposes</action>
-    <action>Map navigation flow between screens</action>
-    <action>Identify key UI elements for each screen</action>
-    <action>Show planned structure, confirm with user</action>
-  </step>
-
-  <step n="6" goal="Load Resources">
-    <action>Load {{templates}} and extract `wireframe` section</action>
-    <action>Load {{library}}</action>
-    <action>Load theme.json</action>
-    <action>Load {{helpers}}</action>
-  </step>
-
-  <step n="7" goal="Build Wireframe Elements">
-    <critical>Follow {{helpers}} for proper element creation</critical>
-
-    <substep>For Each Screen:
-      - Create container/frame
-      - Add header section
-      - Add content areas
-      - Add navigation elements
-      - Add interactive elements (buttons, inputs)
-      - Add labels and annotations
-    </substep>
-
-    <substep>Build Order:
-      1. Screen containers
-      2. Layout sections (header, content, footer)
-      3. Navigation elements
-      4. Content blocks
-      5. Interactive elements
-      6. Labels and annotations
-      7. Flow indicators (if multi-screen)
-    </substep>
-
-    <substep>Fidelity Guidelines:
-      - Low: Basic shapes, minimal detail, placeholder text
-      - Medium: More defined elements, some styling, representative content
-      - High: Detailed elements, realistic sizing, actual content examples
-    </substep>
-  </step>
-
-  <step n="8" goal="Optimize and Save">
-    <action>Strip unused elements and elements with isDeleted: true</action>
-    <action>Save to {{default_output_file}}</action>
-  </step>
-
-  <step n="9" goal="Validate JSON Syntax">
-    <critical>NEVER delete the file if validation fails - always fix syntax errors</critical>
-    <action>Run: node -e "JSON.parse(require('fs').readFileSync('{{default_output_file}}', 'utf8')); console.log('✓ Valid JSON')"</action>
-    <check if="validation fails (exit code 1)">
-      <action>Read the error message carefully - it shows the syntax error and position</action>
-      <action>Open the file and navigate to the error location</action>
-      <action>Fix the syntax error (add missing comma, bracket, or quote as indicated)</action>
-      <action>Save the file</action>
-      <action>Re-run validation with the same command</action>
-      <action>Repeat until validation passes</action>
-    </check>
-    <action>Once validation passes, confirm with user</action>
-  </step>
-
-  <step n="10" goal="Validate Content">
-    <invoke-task>Validate against {{validation}}</invoke-task>
-  </step>
-
-</workflow>
-```

_bmad/bmm/workflows/excalidraw-diagrams/create-wireframe/workflow.yaml

@@ -1,26 +0,0 @@
-name: create-excalidraw-wireframe
-description: "Create website or app wireframes in Excalidraw format"
-author: "BMad"
-
-# Config values
-config_source: "{project-root}/_bmad/bmm/config.yaml"
-output_folder: "{config_source}:output_folder"
-
-# Workflow components
-installed_path: "{project-root}/_bmad/bmm/workflows/excalidraw-diagrams/create-wireframe"
-shared_path: "{project-root}/_bmad/bmm/workflows/excalidraw-diagrams/_shared"
-instructions: "{installed_path}/instructions.md"
-validation: "{installed_path}/checklist.md"
-
-# Core Excalidraw resources (universal knowledge)
-helpers: "{project-root}/_bmad/core/resources/excalidraw/excalidraw-helpers.md"
-json_validation: "{project-root}/_bmad/core/resources/excalidraw/validate-json-instructions.md"
-
-# Domain-specific resources (technical diagrams)
-templates: "{shared_path}/excalidraw-templates.yaml"
-library: "{shared_path}/excalidraw-library.json"
-
-# Output file (respects user's configured output_folder)
-default_output_file: "{output_folder}/excalidraw-diagrams/wireframe-{timestamp}.excalidraw"
-
-standalone: true

_bmad/bmm/workflows/generate-project-context/project-context-template.md

@@ -1,21 +0,0 @@
----
-project_name: '{{project_name}}'
-user_name: '{{user_name}}'
-date: '{{date}}'
-sections_completed: ['technology_stack']
-existing_patterns_found: { { number_of_patterns_discovered } }
----
-
-# Project Context for AI Agents
-
-_This file contains critical rules and patterns that AI agents must follow when implementing code in this project. Focus on unobvious details that agents might otherwise miss._
-
----
-
-## Technology Stack & Versions
-
-_Documented after discovery phase_
-
-## Critical Implementation Rules
-
-_Documented after discovery phase_

_bmad/bmm/workflows/generate-project-context/steps/step-01-discover.md

@@ -1,184 +0,0 @@
-# Step 1: Context Discovery & Initialization
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-- ✅ ALWAYS treat this as collaborative discovery between technical peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on discovering existing project context and technology stack
-- 🎯 IDENTIFY critical implementation rules that AI agents need
-- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 📖 Read existing project files to understand current context
-- 💾 Initialize document and update frontmatter
-- 🚫 FORBIDDEN to load next step until discovery is complete
-
-## CONTEXT BOUNDARIES:
-
-- Variables from workflow.md are available in memory
-- Focus on existing project files and architecture decisions
-- Look for patterns, conventions, and unique requirements
-- Prioritize rules that prevent implementation mistakes
-
-## YOUR TASK:
-
-Discover the project's technology stack, existing patterns, and critical implementation rules that AI agents must follow when writing code.
-
-## DISCOVERY SEQUENCE:
-
-### 1. Check for Existing Project Context
-
-First, check if project context already exists:
-
-- Look for file at `{project_knowledge}/project-context.md or {project-root}/**/project-context.md`
-- If exists: Read complete file to understand existing rules
-- Present to user: "Found existing project context with {number_of_sections} sections. Would you like to update this or create a new one?"
-
-### 2. Discover Project Technology Stack
-
-Load and analyze project files to identify technologies:
-
-**Architecture Document:**
-
-- Look for `{planning_artifacts}/architecture.md`
-- Extract technology choices with specific versions
-- Note architectural decisions that affect implementation
-
-**Package Files:**
-
-- Check for `package.json`, `requirements.txt`, `Cargo.toml`, etc.
-- Extract exact versions of all dependencies
-- Note development vs production dependencies
-
-**Configuration Files:**
-
-- Look for project language specific configs ( example: `tsconfig.json`)
-- Build tool configs (webpack, vite, next.config.js, etc.)
-- Linting and formatting configs (.eslintrc, .prettierrc, etc.)
-- Testing configurations (jest.config.js, vitest.config.ts, etc.)
-
-### 3. Identify Existing Code Patterns
-
-Search through existing codebase for patterns:
-
-**Naming Conventions:**
-
-- File naming patterns (PascalCase, kebab-case, etc.)
-- Component/function naming conventions
-- Variable naming patterns
-- Test file naming patterns
-
-**Code Organization:**
-
-- How components are structured
-- Where utilities and helpers are placed
-- How services are organized
-- Test organization patterns
-
-**Documentation Patterns:**
-
-- Comment styles and conventions
-- Documentation requirements
-- README and API doc patterns
-
-### 4. Extract Critical Implementation Rules
-
-Look for rules that AI agents might miss:
-
-**Language-Specific Rules:**
-
-- TypeScript strict mode requirements
-- Import/export conventions
-- Async/await vs Promise usage patterns
-- Error handling patterns specific to the language
-
-**Framework-Specific Rules:**
-
-- React hooks usage patterns
-- API route conventions
-- Middleware usage patterns
-- State management patterns
-
-**Testing Rules:**
-
-- Test structure requirements
-- Mock usage conventions
-- Integration vs unit test boundaries
-- Coverage requirements
-
-**Development Workflow Rules:**
-
-- Branch naming conventions
-- Commit message patterns
-- PR review requirements
-- Deployment procedures
-
-### 5. Initialize Project Context Document
-
-Based on discovery, create or update the context document:
-
-#### A. Fresh Document Setup (if no existing context)
-
-Copy template from `{installed_path}/project-context-template.md` to `{output_folder}/project-context.md`
-Initialize frontmatter fields.
-
-#### B. Existing Document Update
-
-Load existing context and prepare for updates
-Set frontmatter `sections_completed` to track what will be updated
-
-### 6. Present Discovery Summary
-
-Report findings to user:
-
-"Welcome {{user_name}}! I've analyzed your project for {{project_name}} to discover the context that AI agents need.
-
-**Technology Stack Discovered:**
-{{list_of_technologies_with_versions}}
-
-**Existing Patterns Found:**
-
-- {{number_of_patterns}} implementation patterns
-- {{number_of_conventions}} coding conventions
-- {{number_of_rules}} critical rules
-
-**Key Areas for Context Rules:**
-
-- {{area_1}} (e.g., TypeScript configuration)
-- {{area_2}} (e.g., Testing patterns)
-- {{area_3}} (e.g., Code organization)
-
-{if_existing_context}
-**Existing Context:** Found {{sections}} sections already defined. We can update or add to these.
-{/if_existing_context}
-
-Ready to create/update your project context. This will help AI agents implement code consistently with your project's standards.
-
-[C] Continue to context generation"
-
-## SUCCESS METRICS:
-
-✅ Existing project context properly detected and handled
-✅ Technology stack accurately identified with versions
-✅ Critical implementation patterns discovered
-✅ Project context document properly initialized
-✅ Discovery findings clearly presented to user
-✅ User ready to proceed with context generation
-
-## FAILURE MODES:
-
-❌ Not checking for existing project context before creating new one
-❌ Missing critical technology versions or configurations
-❌ Overlooking important coding patterns or conventions
-❌ Not initializing frontmatter properly
-❌ Not presenting clear discovery summary to user
-
-## NEXT STEP:
-
-After user selects [C] to continue, load `./step-02-generate.md` to collaboratively generate the specific project context rules.
-
-Remember: Do NOT proceed to step-02 until user explicitly selects [C] from the menu and discovery is confirmed and the initial file has been written as directed in this discovery step!

_bmad/bmm/workflows/generate-project-context/steps/step-02-generate.md

@@ -1,318 +0,0 @@
-# Step 2: Context Rules Generation
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-- ✅ ALWAYS treat this as collaborative discovery between technical peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on unobvious rules that AI agents need to be reminded of
-- 🎯 KEEP CONTENT LEAN - optimize for LLM context efficiency
-- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 📝 Focus on specific, actionable rules rather than general advice
-- ⚠️ Present A/P/C menu after each major rule category
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter with completed sections
-- 🚫 FORBIDDEN to load next step until all sections are complete
-
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices for each rule category:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to explore nuanced implementation rules
-- **P (Party Mode)**: Bring multiple perspectives to identify critical edge cases
-- **C (Continue)**: Save the current rules and proceed to next category
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml
-- When 'P' selected: Execute {project-root}/_bmad/core/workflows/party-mode
-- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
-- User accepts/rejects protocol changes before proceeding
-
-## CONTEXT BOUNDARIES:
-
-- Discovery results from step-1 are available
-- Technology stack and existing patterns are identified
-- Focus on rules that prevent implementation mistakes
-- Prioritize unobvious details that AI agents might miss
-
-## YOUR TASK:
-
-Collaboratively generate specific, critical rules that AI agents must follow when implementing code in this project.
-
-## CONTEXT GENERATION SEQUENCE:
-
-### 1. Technology Stack & Versions
-
-Document the exact technology stack from discovery:
-
-**Core Technologies:**
-Based on user skill level, present findings:
-
-**Expert Mode:**
-"Technology stack from your architecture and package files:
-{{exact_technologies_with_versions}}
-
-Any critical version constraints I should document for agents?"
-
-**Intermediate Mode:**
-"I found your technology stack:
-
-**Core Technologies:**
-{{main_technologies_with_versions}}
-
-**Key Dependencies:**
-{{important_dependencies_with_versions}}
-
-Are there any version constraints or compatibility notes agents should know about?"
-
-**Beginner Mode:**
-"Here are the technologies you're using:
-
-**Main Technologies:**
-{{friendly_description_of_tech_stack}}
-
-**Important Notes:**
-{{key_things_agents_need_to_know_about_versions}}
-
-Should I document any special version rules or compatibility requirements?"
-
-### 2. Language-Specific Rules
-
-Focus on unobvious language patterns agents might miss:
-
-**TypeScript/JavaScript Rules:**
-"Based on your codebase, I notice some specific patterns:
-
-**Configuration Requirements:**
-{{typescript_config_rules}}
-
-**Import/Export Patterns:**
-{{import_export_conventions}}
-
-**Error Handling Patterns:**
-{{error_handling_requirements}}
-
-Are these patterns correct? Any other language-specific rules agents should follow?"
-
-**Python/Ruby/Other Language Rules:**
-Adapt to the actual language in use with similar focused questions.
-
-### 3. Framework-Specific Rules
-
-Document framework-specific patterns:
-
-**React Rules (if applicable):**
-"For React development, I see these patterns:
-
-**Hooks Usage:**
-{{hooks_usage_patterns}}
-
-**Component Structure:**
-{{component_organization_rules}}
-
-**State Management:**
-{{state_management_patterns}}
-
-**Performance Rules:**
-{{performance_optimization_requirements}}
-
-Should I add any other React-specific rules?"
-
-**Other Framework Rules:**
-Adapt for Vue, Angular, Next.js, Express, etc.
-
-### 4. Testing Rules
-
-Focus on testing patterns that ensure consistency:
-
-**Test Structure Rules:**
-"Your testing setup shows these patterns:
-
-**Test Organization:**
-{{test_file_organization}}
-
-**Mock Usage:**
-{{mock_patterns_and_conventions}}
-
-**Test Coverage Requirements:**
-{{coverage_expectations}}
-
-**Integration vs Unit Test Rules:**
-{{test_boundary_patterns}}
-
-Are there testing rules agents should always follow?"
-
-### 5. Code Quality & Style Rules
-
-Document critical style and quality rules:
-
-**Linting/Formatting:**
-"Your code style configuration requires:
-
-**ESLint/Prettier Rules:**
-{{specific_linting_rules}}
-
-**Code Organization:**
-{{file_and_folder_structure_rules}}
-
-**Naming Conventions:**
-{{naming_patterns_agents_must_follow}}
-
-**Documentation Requirements:**
-{{comment_and_documentation_patterns}}
-
-Any additional code quality rules?"
-
-### 6. Development Workflow Rules
-
-Document workflow patterns that affect implementation:
-
-**Git/Repository Rules:**
-"Your project uses these patterns:
-
-**Branch Naming:**
-{{branch_naming_conventions}}
-
-**Commit Message Format:**
-{{commit_message_patterns}}
-
-**PR Requirements:**
-{{pull_request_checklist}}
-
-**Deployment Patterns:**
-{{deployment_considerations}}
-
-Should I document any other workflow rules?"
-
-### 7. Critical Don't-Miss Rules
-
-Identify rules that prevent common mistakes:
-
-**Anti-Patterns to Avoid:**
-"Based on your codebase, here are critical things agents must NOT do:
-
-{{critical_anti_patterns_with_examples}}
-
-**Edge Cases:**
-{{specific_edge_cases_agents_should_handle}}
-
-**Security Rules:**
-{{security_considerations_agents_must_follow}}
-
-**Performance Gotchas:**
-{{performance_patterns_to_avoid}}
-
-Are there other 'gotchas' agents should know about?"
-
-### 8. Generate Context Content
-
-For each category, prepare lean content for the project context file:
-
-#### Content Structure:
-
-```markdown
-## Technology Stack & Versions
-
-{{concise_technology_list_with_exact_versions}}
-
-## Critical Implementation Rules
-
-### Language-Specific Rules
-
-{{bullet_points_of_critical_language_rules}}
-
-### Framework-Specific Rules
-
-{{bullet_points_of_framework_patterns}}
-
-### Testing Rules
-
-{{bullet_points_of_testing_requirements}}
-
-### Code Quality & Style Rules
-
-{{bullet_points_of_style_and_quality_rules}}
-
-### Development Workflow Rules
-
-{{bullet_points_of_workflow_patterns}}
-
-### Critical Don't-Miss Rules
-
-{{bullet_points_of_anti_patterns_and_edge_cases}}
-```
-
-### 9. Present Content and Menu
-
-After each category, show the generated rules and present choices:
-
-"I've drafted the {{category_name}} rules for your project context.
-
-**Here's what I'll add:**
-
-[Show the complete markdown content for this category]
-
-**What would you like to do?**
-[A] Advanced Elicitation - Explore nuanced rules for this category
-[P] Party Mode - Review from different implementation perspectives
-[C] Continue - Save these rules and move to next category"
-
-### 10. Handle Menu Selection
-
-#### If 'A' (Advanced Elicitation):
-
-- Execute advanced-elicitation.xml with current category rules
-- Process enhanced rules that come back
-- Ask user: "Accept these enhanced rules for {{category}}? (y/n)"
-- If yes: Update content, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'P' (Party Mode):
-
-- Execute party-mode workflow with category rules context
-- Process collaborative insights on implementation patterns
-- Ask user: "Accept these changes to {{category}} rules? (y/n)"
-- If yes: Update content, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'C' (Continue):
-
-- Save the current category content to project context file
-- Update frontmatter: `sections_completed: [...]`
-- Proceed to next category or step-03 if complete
-
-## APPEND TO PROJECT CONTEXT:
-
-When user selects 'C' for a category, append the content directly to `{output_folder}/project-context.md` using the structure from step 8.
-
-## SUCCESS METRICS:
-
-✅ All critical technology versions accurately documented
-✅ Language-specific rules cover unobvious patterns
-✅ Framework rules capture project-specific conventions
-✅ Testing rules ensure consistent test quality
-✅ Code quality rules maintain project standards
-✅ Workflow rules prevent implementation conflicts
-✅ Content is lean and optimized for LLM context
-✅ A/P/C menu presented and handled correctly for each category
-
-## FAILURE MODES:
-
-❌ Including obvious rules that agents already know
-❌ Making content too verbose for LLM context efficiency
-❌ Missing critical anti-patterns or edge cases
-❌ Not getting user validation for each rule category
-❌ Not documenting exact versions and configurations
-❌ Not presenting A/P/C menu after content generation
-
-## NEXT STEP:
-
-After completing all rule categories and user selects 'C' for the final category, load `./step-03-complete.md` to finalize the project context file.
-
-Remember: Do NOT proceed to step-03 until all categories are complete and user explicitly selects 'C' for each!

_bmad/bmm/workflows/generate-project-context/steps/step-03-complete.md

@@ -1,278 +0,0 @@
-# Step 3: Context Completion & Finalization
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-- ✅ ALWAYS treat this as collaborative completion between technical peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on finalizing a lean, LLM-optimized project context
-- 🎯 ENSURE all critical rules are captured and actionable
-- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 📝 Review and optimize content for LLM context efficiency
-- 📖 Update frontmatter with completion status
-- 🚫 NO MORE STEPS - this is the final step
-
-## CONTEXT BOUNDARIES:
-
-- All rule categories from step-2 are complete
-- Technology stack and versions are documented
-- Focus on final review, optimization, and completion
-- Ensure the context file is ready for AI agent consumption
-
-## YOUR TASK:
-
-Complete the project context file, optimize it for LLM efficiency, and provide guidance for usage and maintenance.
-
-## COMPLETION SEQUENCE:
-
-### 1. Review Complete Context File
-
-Read the entire project context file and analyze:
-
-**Content Analysis:**
-
-- Total length and readability for LLMs
-- Clarity and specificity of rules
-- Coverage of all critical areas
-- Actionability of each rule
-
-**Structure Analysis:**
-
-- Logical organization of sections
-- Consistency of formatting
-- Absence of redundant or obvious information
-- Optimization for quick scanning
-
-### 2. Optimize for LLM Context
-
-Ensure the file is lean and efficient:
-
-**Content Optimization:**
-
-- Remove any redundant rules or obvious information
-- Combine related rules into concise bullet points
-- Use specific, actionable language
-- Ensure each rule provides unique value
-
-**Formatting Optimization:**
-
-- Use consistent markdown formatting
-- Implement clear section hierarchy
-- Ensure scannability with strategic use of bolding
-- Maintain readability while maximizing information density
-
-### 3. Final Content Structure
-
-Ensure the final structure follows this optimized format:
-
-```markdown
-# Project Context for AI Agents
-
-_This file contains critical rules and patterns that AI agents must follow when implementing code in this project. Focus on unobvious details that agents might otherwise miss._
-
----
-
-## Technology Stack & Versions
-
-{{concise_technology_list}}
-
-## Critical Implementation Rules
-
-### Language-Specific Rules
-
-{{specific_language_rules}}
-
-### Framework-Specific Rules
-
-{{framework_patterns}}
-
-### Testing Rules
-
-{{testing_requirements}}
-
-### Code Quality & Style Rules
-
-{{style_and_quality_patterns}}
-
-### Development Workflow Rules
-
-{{workflow_patterns}}
-
-### Critical Don't-Miss Rules
-
-{{anti_patterns_and_edge_cases}}
-
----
-
-## Usage Guidelines
-
-**For AI Agents:**
-
-- Read this file before implementing any code
-- Follow ALL rules exactly as documented
-- When in doubt, prefer the more restrictive option
-- Update this file if new patterns emerge
-
-**For Humans:**
-
-- Keep this file lean and focused on agent needs
-- Update when technology stack changes
-- Review quarterly for outdated rules
-- Remove rules that become obvious over time
-
-Last Updated: {{date}}
-```
-
-### 4. Present Completion Summary
-
-Based on user skill level, present the completion:
-
-**Expert Mode:**
-"Project context complete. Optimized for LLM consumption with {{rule_count}} critical rules across {{section_count}} sections.
-
-File saved to: `{output_folder}/project-context.md`
-
-Ready for AI agent integration."
-
-**Intermediate Mode:**
-"Your project context is complete and optimized for AI agents!
-
-**What we created:**
-
-- {{rule_count}} critical implementation rules
-- Technology stack with exact versions
-- Framework-specific patterns and conventions
-- Testing and quality guidelines
-- Workflow and anti-pattern rules
-
-**Key benefits:**
-
-- AI agents will implement consistently with your standards
-- Reduced context switching and implementation errors
-- Clear guidance for unobvious project requirements
-
-**Next steps:**
-
-- AI agents should read this file before implementing
-- Update as your project evolves
-- Review periodically for optimization"
-
-**Beginner Mode:**
-"Excellent! Your project context guide is ready! 🎉
-
-**What this does:**
-Think of this as a 'rules of the road' guide for AI agents working on your project. It ensures they all follow the same patterns and avoid common mistakes.
-
-**What's included:**
-
-- Exact technology versions to use
-- Critical coding rules they might miss
-- Testing and quality standards
-- Workflow patterns to follow
-
-**How AI agents use it:**
-They read this file before writing any code, ensuring everything they create follows your project's standards perfectly.
-
-Your project context is saved and ready to help agents implement consistently!"
-
-### 5. Final File Updates
-
-Update the project context file with completion information:
-
-**Frontmatter Update:**
-
-```yaml
----
-project_name: '{{project_name}}'
-user_name: '{{user_name}}'
-date: '{{date}}'
-sections_completed:
-  ['technology_stack', 'language_rules', 'framework_rules', 'testing_rules', 'quality_rules', 'workflow_rules', 'anti_patterns']
-status: 'complete'
-rule_count: { { total_rules } }
-optimized_for_llm: true
----
-```
-
-**Add Usage Section:**
-Append the usage guidelines from step 3 to complete the document.
-
-### 6. Completion Validation
-
-Final checks before completion:
-
-**Content Validation:**
-✅ All critical technology versions documented
-✅ Language-specific rules are specific and actionable
-✅ Framework rules cover project conventions
-✅ Testing rules ensure consistency
-✅ Code quality rules maintain standards
-✅ Workflow rules prevent conflicts
-✅ Anti-pattern rules prevent common mistakes
-
-**Format Validation:**
-✅ Content is lean and optimized for LLMs
-✅ Structure is logical and scannable
-✅ No redundant or obvious information
-✅ Consistent formatting throughout
-
-### 7. Completion Message
-
-Present final completion to user:
-
-"✅ **Project Context Generation Complete!**
-
-Your optimized project context file is ready at:
-`{output_folder}/project-context.md`
-
-**📊 Context Summary:**
-
-- {{rule_count}} critical rules for AI agents
-- {{section_count}} comprehensive sections
-- Optimized for LLM context efficiency
-- Ready for immediate agent integration
-
-**🎯 Key Benefits:**
-
-- Consistent implementation across all AI agents
-- Reduced common mistakes and edge cases
-- Clear guidance for project-specific patterns
-- Minimal LLM context usage
-
-**📋 Next Steps:**
-
-1. AI agents will automatically read this file when implementing
-2. Update this file when your technology stack or patterns evolve
-3. Review quarterly to optimize and remove outdated rules
-
-Your project context will help ensure high-quality, consistent implementation across all development work. Great work capturing your project's critical implementation requirements!"
-
-## SUCCESS METRICS:
-
-✅ Complete project context file with all critical rules
-✅ Content optimized for LLM context efficiency
-✅ All technology versions and patterns documented
-✅ File structure is logical and scannable
-✅ Usage guidelines included for agents and humans
-✅ Frontmatter properly updated with completion status
-✅ User provided with clear next steps and benefits
-
-## FAILURE MODES:
-
-❌ Final content is too verbose for LLM consumption
-❌ Missing critical implementation rules or patterns
-❌ Not optimizing content for agent readability
-❌ Not providing clear usage guidelines
-❌ Frontmatter not properly updated
-❌ Not validating file completion before ending
-
-## WORKFLOW COMPLETE:
-
-This is the final step of the Generate Project Context workflow. The user now has a comprehensive, optimized project context file that will ensure consistent, high-quality implementation across all AI agents working on the project.
-
-The project context file serves as the critical "rules of the road" that agents need to implement code consistently with the project's standards and patterns.

_bmad/bmm/workflows/generate-project-context/workflow.md

@@ -1,49 +0,0 @@
----
-name: generate-project-context
-description: Creates a concise project-context.md file with critical rules and patterns that AI agents must follow when implementing code. Optimized for LLM context efficiency.
----
-
-# Generate Project Context Workflow
-
-**Goal:** Create a concise, optimized `project-context.md` file containing critical rules, patterns, and guidelines that AI agents must follow when implementing code. This file focuses on unobvious details that LLMs need to be reminded of.
-
-**Your Role:** You are a technical facilitator working with a peer to capture the essential implementation rules that will ensure consistent, high-quality code generation across all AI agents working on the project.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-This uses **micro-file architecture** for disciplined execution:
-
-- Each step is a self-contained file with embedded rules
-- Sequential progression with user control at each step
-- Document state tracked in frontmatter
-- Focus on lean, LLM-optimized content generation
-- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
-
----
-
-## INITIALIZATION
-
-### Configuration Loading
-
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-
-- `project_name`, `output_folder`, `user_name`
-- `communication_language`, `document_output_language`, `user_skill_level`
-- `date` as system-generated current datetime
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-### Paths
-
-- `installed_path` = `{project-root}/_bmad/bmm/workflows/generate-project-context`
-- `template_path` = `{installed_path}/project-context-template.md`
-- `output_file` = `{output_folder}/project-context.md`
-
----
-
-## EXECUTION
-
-Load and execute `steps/step-01-discover.md` to begin the workflow.
-
-**Note:** Input document discovery and initialization protocols are handled in step-01-discover.md.

_bmad/bmm/workflows/testarch/atdd/atdd-checklist-template.md

@@ -1,364 +0,0 @@
-# ATDD Checklist - Epic {epic_num}, Story {story_num}: {story_title}
-
-**Date:** {date}
-**Author:** {user_name}
-**Primary Test Level:** {primary_level}
-
----
-
-## Story Summary
-
-{Brief 2-3 sentence summary of the user story}
-
-**As a** {user_role}
-**I want** {feature_description}
-**So that** {business_value}
-
----
-
-## Acceptance Criteria
-
-{List all testable acceptance criteria from the story}
-
-1. {Acceptance criterion 1}
-2. {Acceptance criterion 2}
-3. {Acceptance criterion 3}
-
----
-
-## Failing Tests Created (RED Phase)
-
-### E2E Tests ({e2e_test_count} tests)
-
-**File:** `{e2e_test_file_path}` ({line_count} lines)
-
-{List each E2E test with its current status and expected failure reason}
-
-- ✅ **Test:** {test_name}
-  - **Status:** RED - {failure_reason}
-  - **Verifies:** {what_this_test_validates}
-
-### API Tests ({api_test_count} tests)
-
-**File:** `{api_test_file_path}` ({line_count} lines)
-
-{List each API test with its current status and expected failure reason}
-
-- ✅ **Test:** {test_name}
-  - **Status:** RED - {failure_reason}
-  - **Verifies:** {what_this_test_validates}
-
-### Component Tests ({component_test_count} tests)
-
-**File:** `{component_test_file_path}` ({line_count} lines)
-
-{List each component test with its current status and expected failure reason}
-
-- ✅ **Test:** {test_name}
-  - **Status:** RED - {failure_reason}
-  - **Verifies:** {what_this_test_validates}
-
----
-
-## Data Factories Created
-
-{List all data factory files created with their exports}
-
-### {Entity} Factory
-
-**File:** `tests/support/factories/{entity}.factory.ts`
-
-**Exports:**
-
-- `create{Entity}(overrides?)` - Create single entity with optional overrides
-- `create{Entity}s(count)` - Create array of entities
-
-**Example Usage:**
-
-```typescript
-const user = createUser({ email: 'specific@example.com' });
-const users = createUsers(5); // Generate 5 random users
-```
-
----
-
-## Fixtures Created
-
-{List all test fixture files created with their fixture names and descriptions}
-
-### {Feature} Fixtures
-
-**File:** `tests/support/fixtures/{feature}.fixture.ts`
-
-**Fixtures:**
-
-- `{fixtureName}` - {description_of_what_fixture_provides}
-  - **Setup:** {what_setup_does}
-  - **Provides:** {what_test_receives}
-  - **Cleanup:** {what_cleanup_does}
-
-**Example Usage:**
-
-```typescript
-import { test } from './fixtures/{feature}.fixture';
-
-test('should do something', async ({ {fixtureName} }) => {
-  // {fixtureName} is ready to use with auto-cleanup
-});
-```
-
----
-
-## Mock Requirements
-
-{Document external services that need mocking and their requirements}
-
-### {Service Name} Mock
-
-**Endpoint:** `{HTTP_METHOD} {endpoint_url}`
-
-**Success Response:**
-
-```json
-{
-  {success_response_example}
-}
-```
-
-**Failure Response:**
-
-```json
-{
-  {failure_response_example}
-}
-```
-
-**Notes:** {any_special_mock_requirements}
-
----
-
-## Required data-testid Attributes
-
-{List all data-testid attributes required in UI implementation for test stability}
-
-### {Page or Component Name}
-
-- `{data-testid-name}` - {description_of_element}
-- `{data-testid-name}` - {description_of_element}
-
-**Implementation Example:**
-
-```tsx
-<button data-testid="login-button">Log In</button>
-<input data-testid="email-input" type="email" />
-<div data-testid="error-message">{errorText}</div>
-```
-
----
-
-## Implementation Checklist
-
-{Map each failing test to concrete implementation tasks that will make it pass}
-
-### Test: {test_name_1}
-
-**File:** `{test_file_path}`
-
-**Tasks to make this test pass:**
-
-- [ ] {Implementation task 1}
-- [ ] {Implementation task 2}
-- [ ] {Implementation task 3}
-- [ ] Add required data-testid attributes: {list_of_testids}
-- [ ] Run test: `{test_execution_command}`
-- [ ] ✅ Test passes (green phase)
-
-**Estimated Effort:** {effort_estimate} hours
-
----
-
-### Test: {test_name_2}
-
-**File:** `{test_file_path}`
-
-**Tasks to make this test pass:**
-
-- [ ] {Implementation task 1}
-- [ ] {Implementation task 2}
-- [ ] {Implementation task 3}
-- [ ] Add required data-testid attributes: {list_of_testids}
-- [ ] Run test: `{test_execution_command}`
-- [ ] ✅ Test passes (green phase)
-
-**Estimated Effort:** {effort_estimate} hours
-
----
-
-## Running Tests
-
-```bash
-# Run all failing tests for this story
-{test_command_all}
-
-# Run specific test file
-{test_command_specific_file}
-
-# Run tests in headed mode (see browser)
-{test_command_headed}
-
-# Debug specific test
-{test_command_debug}
-
-# Run tests with coverage
-{test_command_coverage}
-```
-
----
-
-## Red-Green-Refactor Workflow
-
-### RED Phase (Complete) ✅
-
-**TEA Agent Responsibilities:**
-
-- ✅ All tests written and failing
-- ✅ Fixtures and factories created with auto-cleanup
-- ✅ Mock requirements documented
-- ✅ data-testid requirements listed
-- ✅ Implementation checklist created
-
-**Verification:**
-
-- All tests run and fail as expected
-- Failure messages are clear and actionable
-- Tests fail due to missing implementation, not test bugs
-
----
-
-### GREEN Phase (DEV Team - Next Steps)
-
-**DEV Agent Responsibilities:**
-
-1. **Pick one failing test** from implementation checklist (start with highest priority)
-2. **Read the test** to understand expected behavior
-3. **Implement minimal code** to make that specific test pass
-4. **Run the test** to verify it now passes (green)
-5. **Check off the task** in implementation checklist
-6. **Move to next test** and repeat
-
-**Key Principles:**
-
-- One test at a time (don't try to fix all at once)
-- Minimal implementation (don't over-engineer)
-- Run tests frequently (immediate feedback)
-- Use implementation checklist as roadmap
-
-**Progress Tracking:**
-
-- Check off tasks as you complete them
-- Share progress in daily standup
-- Mark story as IN PROGRESS in `bmm-workflow-status.md`
-
----
-
-### REFACTOR Phase (DEV Team - After All Tests Pass)
-
-**DEV Agent Responsibilities:**
-
-1. **Verify all tests pass** (green phase complete)
-2. **Review code for quality** (readability, maintainability, performance)
-3. **Extract duplications** (DRY principle)
-4. **Optimize performance** (if needed)
-5. **Ensure tests still pass** after each refactor
-6. **Update documentation** (if API contracts change)
-
-**Key Principles:**
-
-- Tests provide safety net (refactor with confidence)
-- Make small refactors (easier to debug if tests fail)
-- Run tests after each change
-- Don't change test behavior (only implementation)
-
-**Completion:**
-
-- All tests pass
-- Code quality meets team standards
-- No duplications or code smells
-- Ready for code review and story approval
-
----
-
-## Next Steps
-
-1. **Share this checklist and failing tests** with the dev workflow (manual handoff)
-2. **Review this checklist** with team in standup or planning
-3. **Run failing tests** to confirm RED phase: `{test_command_all}`
-4. **Begin implementation** using implementation checklist as guide
-5. **Work one test at a time** (red → green for each)
-6. **Share progress** in daily standup
-7. **When all tests pass**, refactor code for quality
-8. **When refactoring complete**, manually update story status to 'done' in sprint-status.yaml
-
----
-
-## Knowledge Base References Applied
-
-This ATDD workflow consulted the following knowledge fragments:
-
-- **fixture-architecture.md** - Test fixture patterns with setup/teardown and auto-cleanup using Playwright's `test.extend()`
-- **data-factories.md** - Factory patterns using `@faker-js/faker` for random test data generation with overrides support
-- **component-tdd.md** - Component test strategies using Playwright Component Testing
-- **network-first.md** - Route interception patterns (intercept BEFORE navigation to prevent race conditions)
-- **test-quality.md** - Test design principles (Given-When-Then, one assertion per test, determinism, isolation)
-- **test-levels-framework.md** - Test level selection framework (E2E vs API vs Component vs Unit)
-
-See `tea-index.csv` for complete knowledge fragment mapping.
-
----
-
-## Test Execution Evidence
-
-### Initial Test Run (RED Phase Verification)
-
-**Command:** `{test_command_all}`
-
-**Results:**
-
-```
-{paste_test_run_output_showing_all_tests_failing}
-```
-
-**Summary:**
-
-- Total tests: {total_test_count}
-- Passing: 0 (expected)
-- Failing: {total_test_count} (expected)
-- Status: ✅ RED phase verified
-
-**Expected Failure Messages:**
-{list_expected_failure_messages_for_each_test}
-
----
-
-## Notes
-
-{Any additional notes, context, or special considerations for this story}
-
-- {Note 1}
-- {Note 2}
-- {Note 3}
-
----
-
-## Contact
-
-**Questions or Issues?**
-
-- Ask in team standup
-- Tag @{tea_agent_username} in Slack/Discord
-- Refer to `./bmm/docs/tea-README.md` for workflow documentation
-- Consult `./bmm/testarch/knowledge` for testing best practices
-
----
-
-**Generated by BMad TEA Agent** - {date}

_bmad/bmm/workflows/testarch/atdd/checklist.md

@@ -1,374 +0,0 @@
-# ATDD Workflow Validation Checklist
-
-Use this checklist to validate that the ATDD workflow has been executed correctly and all deliverables meet quality standards.
-
-## Prerequisites
-
-Before starting this workflow, verify:
-
-- [ ] Story approved with clear acceptance criteria (AC must be testable)
-- [ ] Development sandbox/environment ready
-- [ ] Framework scaffolding exists (run `framework` workflow if missing)
-- [ ] Test framework configuration available (playwright.config.ts or cypress.config.ts)
-- [ ] Package.json has test dependencies installed (Playwright or Cypress)
-
-**Halt if missing:** Framework scaffolding or story acceptance criteria
-
----
-
-## Step 1: Story Context and Requirements
-
-- [ ] Story markdown file loaded and parsed successfully
-- [ ] All acceptance criteria identified and extracted
-- [ ] Affected systems and components identified
-- [ ] Technical constraints documented
-- [ ] Framework configuration loaded (playwright.config.ts or cypress.config.ts)
-- [ ] Test directory structure identified from config
-- [ ] Existing fixture patterns reviewed for consistency
-- [ ] Similar test patterns searched and found in `{test_dir}`
-- [ ] Knowledge base fragments loaded:
-  - [ ] `fixture-architecture.md`
-  - [ ] `data-factories.md`
-  - [ ] `component-tdd.md`
-  - [ ] `network-first.md`
-  - [ ] `test-quality.md`
-
----
-
-## Step 2: Test Level Selection and Strategy
-
-- [ ] Each acceptance criterion analyzed for appropriate test level
-- [ ] Test level selection framework applied (E2E vs API vs Component vs Unit)
-- [ ] E2E tests: Critical user journeys and multi-system integration identified
-- [ ] API tests: Business logic and service contracts identified
-- [ ] Component tests: UI component behavior and interactions identified
-- [ ] Unit tests: Pure logic and edge cases identified (if applicable)
-- [ ] Duplicate coverage avoided (same behavior not tested at multiple levels unnecessarily)
-- [ ] Tests prioritized using P0-P3 framework (if test-design document exists)
-- [ ] Primary test level set in `primary_level` variable (typically E2E or API)
-- [ ] Test levels documented in ATDD checklist
-
----
-
-## Step 3: Failing Tests Generated
-
-### Test File Structure Created
-
-- [ ] Test files organized in appropriate directories:
-  - [ ] `tests/e2e/` for end-to-end tests
-  - [ ] `tests/api/` for API tests
-  - [ ] `tests/component/` for component tests
-  - [ ] `tests/support/` for infrastructure (fixtures, factories, helpers)
-
-### E2E Tests (If Applicable)
-
-- [ ] E2E test files created in `tests/e2e/`
-- [ ] All tests follow Given-When-Then format
-- [ ] Tests use `data-testid` selectors (not CSS classes or fragile selectors)
-- [ ] One assertion per test (atomic test design)
-- [ ] No hard waits or sleeps (explicit waits only)
-- [ ] Network-first pattern applied (route interception BEFORE navigation)
-- [ ] Tests fail initially (RED phase verified by local test run)
-- [ ] Failure messages are clear and actionable
-
-### API Tests (If Applicable)
-
-- [ ] API test files created in `tests/api/`
-- [ ] Tests follow Given-When-Then format
-- [ ] API contracts validated (request/response structure)
-- [ ] HTTP status codes verified
-- [ ] Response body validation includes all required fields
-- [ ] Error cases tested (400, 401, 403, 404, 500)
-- [ ] Tests fail initially (RED phase verified)
-
-### Component Tests (If Applicable)
-
-- [ ] Component test files created in `tests/component/`
-- [ ] Tests follow Given-When-Then format
-- [ ] Component mounting works correctly
-- [ ] Interaction testing covers user actions (click, hover, keyboard)
-- [ ] State management within component validated
-- [ ] Props and events tested
-- [ ] Tests fail initially (RED phase verified)
-
-### Test Quality Validation
-
-- [ ] All tests use Given-When-Then structure with clear comments
-- [ ] All tests have descriptive names explaining what they test
-- [ ] No duplicate tests (same behavior tested multiple times)
-- [ ] No flaky patterns (race conditions, timing issues)
-- [ ] No test interdependencies (tests can run in any order)
-- [ ] Tests are deterministic (same input always produces same result)
-
----
-
-## Step 4: Data Infrastructure Built
-
-### Data Factories Created
-
-- [ ] Factory files created in `tests/support/factories/`
-- [ ] All factories use `@faker-js/faker` for random data generation (no hardcoded values)
-- [ ] Factories support overrides for specific test scenarios
-- [ ] Factories generate complete valid objects matching API contracts
-- [ ] Helper functions for bulk creation provided (e.g., `createUsers(count)`)
-- [ ] Factory exports are properly typed (TypeScript)
-
-### Test Fixtures Created
-
-- [ ] Fixture files created in `tests/support/fixtures/`
-- [ ] All fixtures use Playwright's `test.extend()` pattern
-- [ ] Fixtures have setup phase (arrange test preconditions)
-- [ ] Fixtures provide data to tests via `await use(data)`
-- [ ] Fixtures have teardown phase with auto-cleanup (delete created data)
-- [ ] Fixtures are composable (can use other fixtures if needed)
-- [ ] Fixtures are isolated (each test gets fresh data)
-- [ ] Fixtures are type-safe (TypeScript types defined)
-
-### Mock Requirements Documented
-
-- [ ] External service mocking requirements identified
-- [ ] Mock endpoints documented with URLs and methods
-- [ ] Success response examples provided
-- [ ] Failure response examples provided
-- [ ] Mock requirements documented in ATDD checklist for DEV team
-
-### data-testid Requirements Listed
-
-- [ ] All required data-testid attributes identified from E2E tests
-- [ ] data-testid list organized by page or component
-- [ ] Each data-testid has clear description of element it targets
-- [ ] data-testid list included in ATDD checklist for DEV team
-
----
-
-## Step 5: Implementation Checklist Created
-
-- [ ] Implementation checklist created with clear structure
-- [ ] Each failing test mapped to concrete implementation tasks
-- [ ] Tasks include:
-  - [ ] Route/component creation
-  - [ ] Business logic implementation
-  - [ ] API integration
-  - [ ] data-testid attribute additions
-  - [ ] Error handling
-  - [ ] Test execution command
-  - [ ] Completion checkbox
-- [ ] Red-Green-Refactor workflow documented in checklist
-- [ ] RED phase marked as complete (TEA responsibility)
-- [ ] GREEN phase tasks listed for DEV team
-- [ ] REFACTOR phase guidance provided
-- [ ] Execution commands provided:
-  - [ ] Run all tests: `npm run test:e2e`
-  - [ ] Run specific test file
-  - [ ] Run in headed mode
-  - [ ] Debug specific test
-- [ ] Estimated effort included (hours or story points)
-
----
-
-## Step 6: Deliverables Generated
-
-### ATDD Checklist Document Created
-
-- [ ] Output file created at `{output_folder}/atdd-checklist-{story_id}.md`
-- [ ] Document follows template structure from `atdd-checklist-template.md`
-- [ ] Document includes all required sections:
-  - [ ] Story summary
-  - [ ] Acceptance criteria breakdown
-  - [ ] Failing tests created (paths and line counts)
-  - [ ] Data factories created
-  - [ ] Fixtures created
-  - [ ] Mock requirements
-  - [ ] Required data-testid attributes
-  - [ ] Implementation checklist
-  - [ ] Red-green-refactor workflow
-  - [ ] Execution commands
-  - [ ] Next steps for DEV team
-- [ ] Output shared with DEV workflow (manual handoff; not auto-consumed)
-
-### All Tests Verified to Fail (RED Phase)
-
-- [ ] Full test suite run locally before finalizing
-- [ ] All tests fail as expected (RED phase confirmed)
-- [ ] No tests passing before implementation (if passing, test is invalid)
-- [ ] Failure messages documented in ATDD checklist
-- [ ] Failures are due to missing implementation, not test bugs
-- [ ] Test run output captured for reference
-
-### Summary Provided
-
-- [ ] Summary includes:
-  - [ ] Story ID
-  - [ ] Primary test level
-  - [ ] Test counts (E2E, API, Component)
-  - [ ] Test file paths
-  - [ ] Factory count
-  - [ ] Fixture count
-  - [ ] Mock requirements count
-  - [ ] data-testid count
-  - [ ] Implementation task count
-  - [ ] Estimated effort
-  - [ ] Next steps for DEV team
-  - [ ] Output file path
-  - [ ] Knowledge base references applied
-
----
-
-## Quality Checks
-
-### Test Design Quality
-
-- [ ] Tests are readable (clear Given-When-Then structure)
-- [ ] Tests are maintainable (use factories and fixtures, not hardcoded data)
-- [ ] Tests are isolated (no shared state between tests)
-- [ ] Tests are deterministic (no race conditions or flaky patterns)
-- [ ] Tests are atomic (one assertion per test)
-- [ ] Tests are fast (no unnecessary waits or delays)
-
-### Knowledge Base Integration
-
-- [ ] fixture-architecture.md patterns applied to all fixtures
-- [ ] data-factories.md patterns applied to all factories
-- [ ] network-first.md patterns applied to E2E tests with network requests
-- [ ] component-tdd.md patterns applied to component tests
-- [ ] test-quality.md principles applied to all test design
-
-### Code Quality
-
-- [ ] All TypeScript types are correct and complete
-- [ ] No linting errors in generated test files
-- [ ] Consistent naming conventions followed
-- [ ] Imports are organized and correct
-- [ ] Code follows project style guide
-
----
-
-## Integration Points
-
-### With DEV Agent
-
-- [ ] ATDD checklist provides clear implementation guidance
-- [ ] Implementation tasks are granular and actionable
-- [ ] data-testid requirements are complete and clear
-- [ ] Mock requirements include all necessary details
-- [ ] Execution commands work correctly
-
-### With Story Workflow
-
-- [ ] Story ID correctly referenced in output files
-- [ ] Acceptance criteria from story accurately reflected in tests
-- [ ] Technical constraints from story considered in test design
-
-### With Framework Workflow
-
-- [ ] Test framework configuration correctly detected and used
-- [ ] Directory structure matches framework setup
-- [ ] Fixtures and helpers follow established patterns
-- [ ] Naming conventions consistent with framework standards
-
-### With test-design Workflow (If Available)
-
-- [ ] P0 scenarios from test-design prioritized in ATDD
-- [ ] Risk assessment from test-design considered in test coverage
-- [ ] Coverage strategy from test-design aligned with ATDD tests
-
----
-
-## Completion Criteria
-
-All of the following must be true before marking this workflow as complete:
-
-- [ ] **Story acceptance criteria analyzed** and mapped to appropriate test levels
-- [ ] **Failing tests created** at all appropriate levels (E2E, API, Component)
-- [ ] **Given-When-Then format** used consistently across all tests
-- [ ] **RED phase verified** by local test run (all tests failing as expected)
-- [ ] **Network-first pattern** applied to E2E tests with network requests
-- [ ] **Data factories created** using faker (no hardcoded test data)
-- [ ] **Fixtures created** with auto-cleanup in teardown
-- [ ] **Mock requirements documented** for external services
-- [ ] **data-testid attributes listed** for DEV team
-- [ ] **Implementation checklist created** mapping tests to code tasks
-- [ ] **Red-green-refactor workflow documented** in ATDD checklist
-- [ ] **Execution commands provided** and verified to work
-- [ ] **ATDD checklist document created** and saved to correct location
-- [ ] **Output file formatted correctly** using template structure
-- [ ] **Knowledge base references applied** and documented in summary
-- [ ] **No test quality issues** (flaky patterns, race conditions, hardcoded data)
-
----
-
-## Common Issues and Resolutions
-
-### Issue: Tests pass before implementation
-
-**Problem:** A test passes even though no implementation code exists yet.
-
-**Resolution:**
-
-- Review test to ensure it's testing actual behavior, not mocked/stubbed behavior
-- Check if test is accidentally using existing functionality
-- Verify test assertions are correct and meaningful
-- Rewrite test to fail until implementation is complete
-
-### Issue: Network-first pattern not applied
-
-**Problem:** Route interception happens after navigation, causing race conditions.
-
-**Resolution:**
-
-- Move `await page.route()` calls BEFORE `await page.goto()`
-- Review `network-first.md` knowledge fragment
-- Update all E2E tests to follow network-first pattern
-
-### Issue: Hardcoded test data in tests
-
-**Problem:** Tests use hardcoded strings/numbers instead of factories.
-
-**Resolution:**
-
-- Replace all hardcoded data with factory function calls
-- Use `faker` for all random data generation
-- Update data-factories to support all required test scenarios
-
-### Issue: Fixtures missing auto-cleanup
-
-**Problem:** Fixtures create data but don't clean it up in teardown.
-
-**Resolution:**
-
-- Add cleanup logic after `await use(data)` in fixture
-- Call deletion/cleanup functions in teardown
-- Verify cleanup works by checking database/storage after test run
-
-### Issue: Tests have multiple assertions
-
-**Problem:** Tests verify multiple behaviors in single test (not atomic).
-
-**Resolution:**
-
-- Split into separate tests (one assertion per test)
-- Each test should verify exactly one behavior
-- Use descriptive test names to clarify what each test verifies
-
-### Issue: Tests depend on execution order
-
-**Problem:** Tests fail when run in isolation or different order.
-
-**Resolution:**
-
-- Remove shared state between tests
-- Each test should create its own test data
-- Use fixtures for consistent setup across tests
-- Verify tests can run with `.only` flag
-
----
-
-## Notes for TEA Agent
-
-- **Preflight halt is critical:** Do not proceed if story has no acceptance criteria or framework is missing
-- **RED phase verification is mandatory:** Tests must fail before sharing with DEV team
-- **Network-first pattern:** Route interception BEFORE navigation prevents race conditions
-- **One assertion per test:** Atomic tests provide clear failure diagnosis
-- **Auto-cleanup is non-negotiable:** Every fixture must clean up data in teardown
-- **Use knowledge base:** Load relevant fragments (fixture-architecture, data-factories, network-first, component-tdd, test-quality) for guidance
-- **Share with DEV agent:** ATDD checklist provides implementation roadmap from red to green

_bmad/bmm/workflows/testarch/atdd/instructions.md

@@ -1,806 +0,0 @@
-<!-- Powered by BMAD-CORE™ -->
-
-# Acceptance Test-Driven Development (ATDD)
-
-**Workflow ID**: `_bmad/bmm/testarch/atdd`
-**Version**: 4.0 (BMad v6)
-
----
-
-## Overview
-
-Generates failing acceptance tests BEFORE implementation following TDD's red-green-refactor cycle. This workflow creates comprehensive test coverage at appropriate levels (E2E, API, Component) with supporting infrastructure (fixtures, factories, mocks) and provides an implementation checklist to guide development.
-
-**Core Principle**: Tests fail first (red phase), then guide development to green, then enable confident refactoring.
-
----
-
-## Preflight Requirements
-
-**Critical:** Verify these requirements before proceeding. If any fail, HALT and notify the user.
-
-- ✅ Story approved with clear acceptance criteria
-- ✅ Development sandbox/environment ready
-- ✅ Framework scaffolding exists (run `framework` workflow if missing)
-- ✅ Test framework configuration available (playwright.config.ts or cypress.config.ts)
-
----
-
-## Step 1: Load Story Context and Requirements
-
-### Actions
-
-1. **Read Story Markdown**
-   - Load story file from `{story_file}` variable
-   - Extract acceptance criteria (all testable requirements)
-   - Identify affected systems and components
-   - Note any technical constraints or dependencies
-
-2. **Load Framework Configuration**
-   - Read framework config (playwright.config.ts or cypress.config.ts)
-   - Identify test directory structure
-   - Check existing fixture patterns
-   - Note test runner capabilities
-
-3. **Load Existing Test Patterns**
-   - Search `{test_dir}` for similar tests
-   - Identify reusable fixtures and helpers
-   - Check data factory patterns
-   - Note naming conventions
-
-4. **Check Playwright Utils Flag**
-
-   Read `{config_source}` and check `config.tea_use_playwright_utils`.
-
-5. **Load Knowledge Base Fragments**
-
-   **Critical:** Consult `{project-root}/_bmad/bmm/testarch/tea-index.csv` to load:
-
-   **Core Patterns (Always load):**
-   - `data-factories.md` - Factory patterns using faker (override patterns, nested factories, API seeding, 498 lines, 5 examples)
-   - `component-tdd.md` - Component test strategies (red-green-refactor, provider isolation, accessibility, visual regression, 480 lines, 4 examples)
-   - `test-quality.md` - Test design principles (deterministic tests, isolated with cleanup, explicit assertions, length limits, execution time optimization, 658 lines, 5 examples)
-   - `test-healing-patterns.md` - Common failure patterns and healing strategies (stale selectors, race conditions, dynamic data, network errors, hard waits, 648 lines, 5 examples)
-   - `selector-resilience.md` - Selector best practices (data-testid > ARIA > text > CSS hierarchy, dynamic patterns, anti-patterns, 541 lines, 4 examples)
-   - `timing-debugging.md` - Race condition prevention and async debugging (network-first, deterministic waiting, anti-patterns, 370 lines, 3 examples)
-
-   **If `config.tea_use_playwright_utils: true` (All Utilities):**
-   - `overview.md` - Playwright utils for ATDD patterns
-   - `api-request.md` - API test examples with schema validation
-   - `network-recorder.md` - HAR record/playback for UI acceptance tests
-   - `auth-session.md` - Auth setup for acceptance tests
-   - `intercept-network-call.md` - Network interception in ATDD scenarios
-   - `recurse.md` - Polling for async acceptance criteria
-   - `log.md` - Logging in ATDD tests
-   - `file-utils.md` - File download validation in acceptance tests
-   - `network-error-monitor.md` - Catch silent failures in ATDD
-   - `fixtures-composition.md` - Composing utilities for ATDD
-
-   **If `config.tea_use_playwright_utils: false`:**
-   - `fixture-architecture.md` - Test fixture patterns with auto-cleanup (pure function → fixture → mergeTests composition, 406 lines, 5 examples)
-   - `network-first.md` - Route interception patterns (intercept before navigate, HAR capture, deterministic waiting, 489 lines, 5 examples)
-
-**Halt Condition:** If story has no acceptance criteria or framework is missing, HALT with message: "ATDD requires clear acceptance criteria and test framework setup"
-
----
-
-## Step 1.5: Generation Mode Selection (NEW - Phase 2.5)
-
-### Actions
-
-1. **Detect Generation Mode**
-
-   Determine mode based on scenario complexity:
-
-   **AI Generation Mode (DEFAULT)**:
-   - Clear acceptance criteria with standard patterns
-   - Uses: AI-generated tests from requirements
-   - Appropriate for: CRUD, auth, navigation, API tests
-   - Fastest approach
-
-   **Recording Mode (OPTIONAL - Complex UI)**:
-   - Complex UI interactions (drag-drop, wizards, multi-page flows)
-   - Uses: Interactive test recording with Playwright MCP
-   - Appropriate for: Visual workflows, unclear requirements
-   - Only if config.tea_use_mcp_enhancements is true AND MCP available
-
-2. **AI Generation Mode (DEFAULT - Continue to Step 2)**
-
-   For standard scenarios:
-   - Continue with existing workflow (Step 2: Select Test Levels and Strategy)
-   - AI generates tests based on acceptance criteria from Step 1
-   - Use knowledge base patterns for test structure
-
-3. **Recording Mode (OPTIONAL - Complex UI Only)**
-
-   For complex UI scenarios AND config.tea_use_mcp_enhancements is true:
-
-   **A. Check MCP Availability**
-
-   If Playwright MCP tools are available in your IDE:
-   - Use MCP recording mode (Step 3.B)
-
-   If MCP unavailable:
-   - Fallback to AI generation mode (silent, automatic)
-   - Continue to Step 2
-
-   **B. Interactive Test Recording (MCP-Based)**
-
-   Use Playwright MCP test-generator tools:
-
-   **Setup:**
-
-   ```
-   1. Use generator_setup_page to initialize recording session
-   2. Navigate to application starting URL (from story context)
-   3. Ready to record user interactions
-   ```
-
-   **Recording Process (Per Acceptance Criterion):**
-
-   ```
-   4. Read acceptance criterion from story
-   5. Manually execute test scenario using browser_* tools:
-      - browser_navigate: Navigate to pages
-      - browser_click: Click buttons, links, elements
-      - browser_type: Fill form fields
-      - browser_select: Select dropdown options
-      - browser_check: Check/uncheck checkboxes
-   6. Add verification steps using browser_verify_* tools:
-      - browser_verify_text: Verify text content
-      - browser_verify_visible: Verify element visibility
-      - browser_verify_url: Verify URL navigation
-   7. Capture interaction log with generator_read_log
-   8. Generate test file with generator_write_test
-   9. Repeat for next acceptance criterion
-   ```
-
-   **Post-Recording Enhancement:**
-
-   ```
-   10. Review generated test code
-   11. Enhance with knowledge base patterns:
-       - Add Given-When-Then comments
-       - Replace recorded selectors with data-testid (if needed)
-       - Add network-first interception (from network-first.md)
-       - Add fixtures for auth/data setup (from fixture-architecture.md)
-       - Use factories for test data (from data-factories.md)
-   12. Verify tests fail (missing implementation)
-   13. Continue to Step 4 (Build Data Infrastructure)
-   ```
-
-   **When to Use Recording Mode:**
-   - ✅ Complex UI interactions (drag-drop, multi-step forms, wizards)
-   - ✅ Visual workflows (modals, dialogs, animations)
-   - ✅ Unclear requirements (exploratory, discovering expected behavior)
-   - ✅ Multi-page flows (checkout, registration, onboarding)
-   - ❌ NOT for simple CRUD (AI generation faster)
-   - ❌ NOT for API-only tests (no UI to record)
-
-   **When to Use AI Generation (Default):**
-   - ✅ Clear acceptance criteria available
-   - ✅ Standard patterns (login, CRUD, navigation)
-   - ✅ Need many tests quickly
-   - ✅ API/backend tests (no UI interaction)
-
-4. **Proceed to Test Level Selection**
-
-   After mode selection:
-   - AI Generation: Continue to Step 2 (Select Test Levels and Strategy)
-   - Recording: Skip to Step 4 (Build Data Infrastructure) - tests already generated
-
----
-
-## Step 2: Select Test Levels and Strategy
-
-### Actions
-
-1. **Analyze Acceptance Criteria**
-
-   For each acceptance criterion, determine:
-   - Does it require full user journey? → E2E test
-   - Does it test business logic/API contract? → API test
-   - Does it validate UI component behavior? → Component test
-   - Can it be unit tested? → Unit test
-
-2. **Apply Test Level Selection Framework**
-
-   **Knowledge Base Reference**: `test-levels-framework.md`
-
-   **E2E (End-to-End)**:
-   - Critical user journeys (login, checkout, core workflow)
-   - Multi-system integration
-   - User-facing acceptance criteria
-   - **Characteristics**: High confidence, slow execution, brittle
-
-   **API (Integration)**:
-   - Business logic validation
-   - Service contracts
-   - Data transformations
-   - **Characteristics**: Fast feedback, good balance, stable
-
-   **Component**:
-   - UI component behavior (buttons, forms, modals)
-   - Interaction testing
-   - Visual regression
-   - **Characteristics**: Fast, isolated, granular
-
-   **Unit**:
-   - Pure business logic
-   - Edge cases
-   - Error handling
-   - **Characteristics**: Fastest, most granular
-
-3. **Avoid Duplicate Coverage**
-
-   Don't test same behavior at multiple levels unless necessary:
-   - Use E2E for critical happy path only
-   - Use API tests for complex business logic variations
-   - Use component tests for UI interaction edge cases
-   - Use unit tests for pure logic edge cases
-
-4. **Prioritize Tests**
-
-   If test-design document exists, align with priority levels:
-   - P0 scenarios → Must cover in failing tests
-   - P1 scenarios → Should cover if time permits
-   - P2/P3 scenarios → Optional for this iteration
-
-**Decision Point:** Set `primary_level` variable to main test level for this story (typically E2E or API)
-
----
-
-## Step 3: Generate Failing Tests
-
-### Actions
-
-1. **Create Test File Structure**
-
-   ```
-   tests/
-   ├── e2e/
-   │   └── {feature-name}.spec.ts        # E2E acceptance tests
-   ├── api/
-   │   └── {feature-name}.api.spec.ts    # API contract tests
-   ├── component/
-   │   └── {ComponentName}.test.tsx      # Component tests
-   └── support/
-       ├── fixtures/                      # Test fixtures
-       ├── factories/                     # Data factories
-       └── helpers/                       # Utility functions
-   ```
-
-2. **Write Failing E2E Tests (If Applicable)**
-
-   **Use Given-When-Then format:**
-
-   ```typescript
-   import { test, expect } from '@playwright/test';
-
-   test.describe('User Login', () => {
-     test('should display error for invalid credentials', async ({ page }) => {
-       // GIVEN: User is on login page
-       await page.goto('/login');
-
-       // WHEN: User submits invalid credentials
-       await page.fill('[data-testid="email-input"]', 'invalid@example.com');
-       await page.fill('[data-testid="password-input"]', 'wrongpassword');
-       await page.click('[data-testid="login-button"]');
-
-       // THEN: Error message is displayed
-       await expect(page.locator('[data-testid="error-message"]')).toHaveText('Invalid email or password');
-     });
-   });
-   ```
-
-   **Critical patterns:**
-   - One assertion per test (atomic tests)
-   - Explicit waits (no hard waits/sleeps)
-   - Network-first approach (route interception before navigation)
-   - data-testid selectors for stability
-   - Clear Given-When-Then structure
-
-3. **Apply Network-First Pattern**
-
-   **Knowledge Base Reference**: `network-first.md`
-
-   ```typescript
-   test('should load user dashboard after login', async ({ page }) => {
-     // CRITICAL: Intercept routes BEFORE navigation
-     await page.route('**/api/user', (route) =>
-       route.fulfill({
-         status: 200,
-         body: JSON.stringify({ id: 1, name: 'Test User' }),
-       }),
-     );
-
-     // NOW navigate
-     await page.goto('/dashboard');
-
-     await expect(page.locator('[data-testid="user-name"]')).toHaveText('Test User');
-   });
-   ```
-
-4. **Write Failing API Tests (If Applicable)**
-
-   ```typescript
-   import { test, expect } from '@playwright/test';
-
-   test.describe('User API', () => {
-     test('POST /api/users - should create new user', async ({ request }) => {
-       // GIVEN: Valid user data
-       const userData = {
-         email: 'newuser@example.com',
-         name: 'New User',
-       };
-
-       // WHEN: Creating user via API
-       const response = await request.post('/api/users', {
-         data: userData,
-       });
-
-       // THEN: User is created successfully
-       expect(response.status()).toBe(201);
-       const body = await response.json();
-       expect(body).toMatchObject({
-         email: userData.email,
-         name: userData.name,
-         id: expect.any(Number),
-       });
-     });
-   });
-   ```
-
-5. **Write Failing Component Tests (If Applicable)**
-
-   **Knowledge Base Reference**: `component-tdd.md`
-
-   ```typescript
-   import { test, expect } from '@playwright/experimental-ct-react';
-   import { LoginForm } from './LoginForm';
-
-   test.describe('LoginForm Component', () => {
-     test('should disable submit button when fields are empty', async ({ mount }) => {
-       // GIVEN: LoginForm is mounted
-       const component = await mount(<LoginForm />);
-
-       // WHEN: Form is initially rendered
-       const submitButton = component.locator('button[type="submit"]');
-
-       // THEN: Submit button is disabled
-       await expect(submitButton).toBeDisabled();
-     });
-   });
-   ```
-
-6. **Verify Tests Fail Initially**
-
-   **Critical verification:**
-   - Run tests locally to confirm they fail
-   - Failure should be due to missing implementation, not test errors
-   - Failure messages should be clear and actionable
-   - All tests must be in RED phase before sharing with DEV
-
-**Important:** Tests MUST fail initially. If a test passes before implementation, it's not a valid acceptance test.
-
----
-
-## Step 4: Build Data Infrastructure
-
-### Actions
-
-1. **Create Data Factories**
-
-   **Knowledge Base Reference**: `data-factories.md`
-
-   ```typescript
-   // tests/support/factories/user.factory.ts
-   import { faker } from '@faker-js/faker';
-
-   export const createUser = (overrides = {}) => ({
-     id: faker.number.int(),
-     email: faker.internet.email(),
-     name: faker.person.fullName(),
-     createdAt: faker.date.recent().toISOString(),
-     ...overrides,
-   });
-
-   export const createUsers = (count: number) => Array.from({ length: count }, () => createUser());
-   ```
-
-   **Factory principles:**
-   - Use faker for random data (no hardcoded values)
-   - Support overrides for specific scenarios
-   - Generate complete valid objects
-   - Include helper functions for bulk creation
-
-2. **Create Test Fixtures**
-
-   **Knowledge Base Reference**: `fixture-architecture.md`
-
-   ```typescript
-   // tests/support/fixtures/auth.fixture.ts
-   import { test as base } from '@playwright/test';
-
-   export const test = base.extend({
-     authenticatedUser: async ({ page }, use) => {
-       // Setup: Create and authenticate user
-       const user = await createUser();
-       await page.goto('/login');
-       await page.fill('[data-testid="email"]', user.email);
-       await page.fill('[data-testid="password"]', 'password123');
-       await page.click('[data-testid="login-button"]');
-       await page.waitForURL('/dashboard');
-
-       // Provide to test
-       await use(user);
-
-       // Cleanup: Delete user
-       await deleteUser(user.id);
-     },
-   });
-   ```
-
-   **Fixture principles:**
-   - Auto-cleanup (always delete created data)
-   - Composable (fixtures can use other fixtures)
-   - Isolated (each test gets fresh data)
-   - Type-safe
-
-3. **Document Mock Requirements**
-
-   If external services need mocking, document requirements:
-
-   ```markdown
-   ### Mock Requirements for DEV Team
-
-   **Payment Gateway Mock**:
-
-   - Endpoint: `POST /api/payments`
-   - Success response: `{ status: 'success', transactionId: '123' }`
-   - Failure response: `{ status: 'failed', error: 'Insufficient funds' }`
-
-   **Email Service Mock**:
-
-   - Should not send real emails in test environment
-   - Log email contents for verification
-   ```
-
-4. **List Required data-testid Attributes**
-
-   ```markdown
-   ### Required data-testid Attributes
-
-   **Login Page**:
-
-   - `email-input` - Email input field
-   - `password-input` - Password input field
-   - `login-button` - Submit button
-   - `error-message` - Error message container
-
-   **Dashboard Page**:
-
-   - `user-name` - User name display
-   - `logout-button` - Logout button
-   ```
-
----
-
-## Step 5: Create Implementation Checklist
-
-### Actions
-
-1. **Map Tests to Implementation Tasks**
-
-   For each failing test, create corresponding implementation task:
-
-   ```markdown
-   ## Implementation Checklist
-
-   ### Epic X - User Authentication
-
-   #### Test: User Login with Valid Credentials
-
-   - [ ] Create `/login` route
-   - [ ] Implement login form component
-   - [ ] Add email/password validation
-   - [ ] Integrate authentication API
-   - [ ] Add `data-testid` attributes: `email-input`, `password-input`, `login-button`
-   - [ ] Implement error handling
-   - [ ] Run test: `npm run test:e2e -- login.spec.ts`
-   - [ ] ✅ Test passes (green phase)
-
-   #### Test: Display Error for Invalid Credentials
-
-   - [ ] Add error state management
-   - [ ] Display error message UI
-   - [ ] Add `data-testid="error-message"`
-   - [ ] Run test: `npm run test:e2e -- login.spec.ts`
-   - [ ] ✅ Test passes (green phase)
-   ```
-
-2. **Include Red-Green-Refactor Guidance**
-
-   ```markdown
-   ## Red-Green-Refactor Workflow
-
-   **RED Phase** (Complete):
-
-   - ✅ All tests written and failing
-   - ✅ Fixtures and factories created
-   - ✅ Mock requirements documented
-
-   **GREEN Phase** (DEV Team):
-
-   1. Pick one failing test
-   2. Implement minimal code to make it pass
-   3. Run test to verify green
-   4. Move to next test
-   5. Repeat until all tests pass
-
-   **REFACTOR Phase** (DEV Team):
-
-   1. All tests passing (green)
-   2. Improve code quality
-   3. Extract duplications
-   4. Optimize performance
-   5. Ensure tests still pass
-   ```
-
-3. **Add Execution Commands**
-
-   ````markdown
-   ## Running Tests
-
-   ```bash
-   # Run all failing tests
-   npm run test:e2e
-
-   # Run specific test file
-   npm run test:e2e -- login.spec.ts
-
-   # Run tests in headed mode (see browser)
-   npm run test:e2e -- --headed
-
-   # Debug specific test
-   npm run test:e2e -- login.spec.ts --debug
-   ```
-   ````
-
-   ```
-
-   ```
-
----
-
-## Step 6: Generate Deliverables
-
-### Actions
-
-1. **Create ATDD Checklist Document**
-
-   Use template structure at `{installed_path}/atdd-checklist-template.md`:
-   - Story summary
-   - Acceptance criteria breakdown
-   - Test files created (with paths)
-   - Data factories created
-   - Fixtures created
-   - Mock requirements
-   - Required data-testid attributes
-   - Implementation checklist
-   - Red-green-refactor workflow
-   - Execution commands
-
-2. **Verify All Tests Fail**
-
-   Before finalizing:
-   - Run full test suite locally
-   - Confirm all tests in RED phase
-   - Document expected failure messages
-   - Ensure failures are due to missing implementation, not test bugs
-
-3. **Write to Output File**
-
-   Save to `{output_folder}/atdd-checklist-{story_id}.md`
-
----
-
-## Important Notes
-
-### Red-Green-Refactor Cycle
-
-**RED Phase** (TEA responsibility):
-
-- Write failing tests first
-- Tests define expected behavior
-- Tests must fail for right reason (missing implementation)
-
-**GREEN Phase** (DEV responsibility):
-
-- Implement minimal code to pass tests
-- One test at a time
-- Don't over-engineer
-
-**REFACTOR Phase** (DEV responsibility):
-
-- Improve code quality with confidence
-- Tests provide safety net
-- Extract duplications, optimize
-
-### Given-When-Then Structure
-
-**GIVEN** (Setup):
-
-- Arrange test preconditions
-- Create necessary data
-- Navigate to starting point
-
-**WHEN** (Action):
-
-- Execute the behavior being tested
-- Single action per test
-
-**THEN** (Assertion):
-
-- Verify expected outcome
-- One assertion per test (atomic)
-
-### Network-First Testing
-
-**Critical pattern:**
-
-```typescript
-// ✅ CORRECT: Intercept BEFORE navigation
-await page.route('**/api/data', handler);
-await page.goto('/page');
-
-// ❌ WRONG: Navigate then intercept (race condition)
-await page.goto('/page');
-await page.route('**/api/data', handler); // Too late!
-```
-
-### Data Factory Best Practices
-
-**Use faker for all test data:**
-
-```typescript
-// ✅ CORRECT: Random data
-email: faker.internet.email();
-
-// ❌ WRONG: Hardcoded data (collisions, maintenance burden)
-email: 'test@example.com';
-```
-
-**Auto-cleanup principle:**
-
-- Every factory that creates data must provide cleanup
-- Fixtures automatically cleanup in teardown
-- No manual cleanup in test code
-
-### One Assertion Per Test
-
-**Atomic test design:**
-
-```typescript
-// ✅ CORRECT: One assertion
-test('should display user name', async ({ page }) => {
-  await expect(page.locator('[data-testid="user-name"]')).toHaveText('John');
-});
-
-// ❌ WRONG: Multiple assertions (not atomic)
-test('should display user info', async ({ page }) => {
-  await expect(page.locator('[data-testid="user-name"]')).toHaveText('John');
-  await expect(page.locator('[data-testid="user-email"]')).toHaveText('john@example.com');
-});
-```
-
-**Why?** If second assertion fails, you don't know if first is still valid.
-
-### Component Test Strategy
-
-**When to use component tests:**
-
-- Complex UI interactions (drag-drop, keyboard nav)
-- Form validation logic
-- State management within component
-- Visual edge cases
-
-**When NOT to use:**
-
-- Simple rendering (snapshot tests are sufficient)
-- Integration with backend (use E2E or API tests)
-- Full user journeys (use E2E tests)
-
-### Knowledge Base Integration
-
-**Core Fragments (Auto-loaded in Step 1):**
-
-- `fixture-architecture.md` - Pure function → fixture → mergeTests patterns (406 lines, 5 examples)
-- `data-factories.md` - Factory patterns with faker, overrides, API seeding (498 lines, 5 examples)
-- `component-tdd.md` - Red-green-refactor, provider isolation, accessibility, visual regression (480 lines, 4 examples)
-- `network-first.md` - Intercept before navigate, HAR capture, deterministic waiting (489 lines, 5 examples)
-- `test-quality.md` - Deterministic tests, cleanup, explicit assertions, length/time limits (658 lines, 5 examples)
-- `test-healing-patterns.md` - Common failure patterns: stale selectors, race conditions, dynamic data, network errors, hard waits (648 lines, 5 examples)
-- `selector-resilience.md` - Selector hierarchy (data-testid > ARIA > text > CSS), dynamic patterns, anti-patterns (541 lines, 4 examples)
-- `timing-debugging.md` - Race condition prevention, deterministic waiting, async debugging (370 lines, 3 examples)
-
-**Reference for Test Level Selection:**
-
-- `test-levels-framework.md` - E2E vs API vs Component vs Unit decision framework (467 lines, 4 examples)
-
-**Manual Reference (Optional):**
-
-- Use `tea-index.csv` to find additional specialized fragments as needed
-
----
-
-## Output Summary
-
-After completing this workflow, provide a summary:
-
-```markdown
-## ATDD Complete - Tests in RED Phase
-
-**Story**: {story_id}
-**Primary Test Level**: {primary_level}
-
-**Failing Tests Created**:
-
-- E2E tests: {e2e_count} tests in {e2e_files}
-- API tests: {api_count} tests in {api_files}
-- Component tests: {component_count} tests in {component_files}
-
-**Supporting Infrastructure**:
-
-- Data factories: {factory_count} factories created
-- Fixtures: {fixture_count} fixtures with auto-cleanup
-- Mock requirements: {mock_count} services documented
-
-**Implementation Checklist**:
-
-- Total tasks: {task_count}
-- Estimated effort: {effort_estimate} hours
-
-**Required data-testid Attributes**: {data_testid_count} attributes documented
-
-**Next Steps for DEV Team**:
-
-1. Run failing tests: `npm run test:e2e`
-2. Review implementation checklist
-3. Implement one test at a time (RED → GREEN)
-4. Refactor with confidence (tests provide safety net)
-5. Share progress in daily standup
-
-**Output File**: {output_file}
-**Manual Handoff**: Share `{output_file}` and failing tests with the dev workflow (not auto-consumed).
-
-**Knowledge Base References Applied**:
-
-- Fixture architecture patterns
-- Data factory patterns with faker
-- Network-first route interception
-- Component TDD strategies
-- Test quality principles
-```
-
----
-
-## Validation
-
-After completing all steps, verify:
-
-- [ ] Story acceptance criteria analyzed and mapped to tests
-- [ ] Appropriate test levels selected (E2E, API, Component)
-- [ ] All tests written in Given-When-Then format
-- [ ] All tests fail initially (RED phase verified)
-- [ ] Network-first pattern applied (route interception before navigation)
-- [ ] Data factories created with faker
-- [ ] Fixtures created with auto-cleanup
-- [ ] Mock requirements documented for DEV team
-- [ ] Required data-testid attributes listed
-- [ ] Implementation checklist created with clear tasks
-- [ ] Red-green-refactor workflow documented
-- [ ] Execution commands provided
-- [ ] Output file created and formatted correctly
-
-Refer to `checklist.md` for comprehensive validation criteria.

_bmad/bmm/workflows/testarch/atdd/workflow.yaml

@@ -1,45 +0,0 @@
-# Test Architect workflow: atdd
-name: testarch-atdd
-description: "Generate failing acceptance tests before implementation using TDD red-green-refactor cycle"
-author: "BMad"
-
-# Critical variables from config
-config_source: "{project-root}/_bmad/bmm/config.yaml"
-output_folder: "{config_source}:output_folder"
-user_name: "{config_source}:user_name"
-communication_language: "{config_source}:communication_language"
-document_output_language: "{config_source}:document_output_language"
-date: system-generated
-
-# Workflow components
-installed_path: "{project-root}/_bmad/bmm/workflows/testarch/atdd"
-instructions: "{installed_path}/instructions.md"
-validation: "{installed_path}/checklist.md"
-template: "{installed_path}/atdd-checklist-template.md"
-
-# Variables and inputs
-variables:
-  test_dir: "{project-root}/tests" # Root test directory
-
-# Output configuration
-default_output_file: "{output_folder}/atdd-checklist-{story_id}.md"
-
-# Required tools
-required_tools:
-  - read_file # Read story markdown, framework config
-  - write_file # Create test files, checklist, factory stubs
-  - create_directory # Create test directories
-  - list_files # Find existing fixtures and helpers
-  - search_repo # Search for similar test patterns
-
-tags:
-  - qa
-  - atdd
-  - test-architect
-  - tdd
-  - red-green-refactor
-
-execution_hints:
-  interactive: false # Minimize prompts
-  autonomous: true # Proceed without user input unless blocked
-  iterative: true

_bmad/bmm/workflows/testarch/automate/checklist.md

@@ -1,582 +0,0 @@
-# Automate Workflow Validation Checklist
-
-Use this checklist to validate that the automate workflow has been executed correctly and all deliverables meet quality standards.
-
-## Prerequisites
-
-Before starting this workflow, verify:
-
-- [ ] Framework scaffolding configured (playwright.config.ts or cypress.config.ts exists)
-- [ ] Test directory structure exists (tests/ folder with subdirectories)
-- [ ] Package.json has test framework dependencies installed
-
-**Halt only if:** Framework scaffolding is completely missing (run `framework` workflow first)
-
-**Note:** BMad artifacts (story, tech-spec, PRD) are OPTIONAL - workflow can run without them
-**Note:** `automate` generates tests; it does not run `*atdd` or `*test-review`. If ATDD outputs exist, use them as input and avoid duplicate coverage.
-
----
-
-## Step 1: Execution Mode Determination and Context Loading
-
-### Mode Detection
-
-- [ ] Execution mode correctly determined:
-  - [ ] BMad-Integrated Mode (story_file variable set) OR
-  - [ ] Standalone Mode (target_feature or target_files set) OR
-  - [ ] Auto-discover Mode (no targets specified)
-
-### BMad Artifacts (If Available - OPTIONAL)
-
-- [ ] Story markdown loaded (if `{story_file}` provided)
-- [ ] Acceptance criteria extracted from story (if available)
-- [ ] Tech-spec.md loaded (if `{use_tech_spec}` true and file exists)
-- [ ] Test-design.md loaded (if `{use_test_design}` true and file exists)
-- [ ] PRD.md loaded (if `{use_prd}` true and file exists)
-- [ ] **Note**: Absence of BMad artifacts does NOT halt workflow
-
-### Framework Configuration
-
-- [ ] Test framework config loaded (playwright.config.ts or cypress.config.ts)
-- [ ] Test directory structure identified from `{test_dir}`
-- [ ] Existing test patterns reviewed
-- [ ] Test runner capabilities noted (parallel execution, fixtures, etc.)
-
-### Coverage Analysis
-
-- [ ] Existing test files searched in `{test_dir}` (if `{analyze_coverage}` true)
-- [ ] Tested features vs untested features identified
-- [ ] Coverage gaps mapped (tests to source files)
-- [ ] Existing fixture and factory patterns checked
-
-### Knowledge Base Fragments Loaded
-
-- [ ] `test-levels-framework.md` - Test level selection
-- [ ] `test-priorities.md` - Priority classification (P0-P3)
-- [ ] `fixture-architecture.md` - Fixture patterns with auto-cleanup
-- [ ] `data-factories.md` - Factory patterns using faker
-- [ ] `selective-testing.md` - Targeted test execution strategies
-- [ ] `ci-burn-in.md` - Flaky test detection patterns
-- [ ] `test-quality.md` - Test design principles
-
----
-
-## Step 2: Automation Targets Identification
-
-### Target Determination
-
-**BMad-Integrated Mode (if story available):**
-
-- [ ] Acceptance criteria mapped to test scenarios
-- [ ] Features implemented in story identified
-- [ ] Existing ATDD tests checked (if any)
-- [ ] Expansion beyond ATDD planned (edge cases, negative paths)
-
-**Standalone Mode (if no story):**
-
-- [ ] Specific feature analyzed (if `{target_feature}` specified)
-- [ ] Specific files analyzed (if `{target_files}` specified)
-- [ ] Features auto-discovered (if `{auto_discover_features}` true)
-- [ ] Features prioritized by:
-  - [ ] No test coverage (highest priority)
-  - [ ] Complex business logic
-  - [ ] External integrations (API, database, auth)
-  - [ ] Critical user paths (login, checkout, etc.)
-
-### Test Level Selection
-
-- [ ] Test level selection framework applied (from `test-levels-framework.md`)
-- [ ] E2E tests identified: Critical user journeys, multi-system integration
-- [ ] API tests identified: Business logic, service contracts, data transformations
-- [ ] Component tests identified: UI behavior, interactions, state management
-- [ ] Unit tests identified: Pure logic, edge cases, error handling
-
-### Duplicate Coverage Avoidance
-
-- [ ] Same behavior NOT tested at multiple levels unnecessarily
-- [ ] E2E used for critical happy path only
-- [ ] API tests used for business logic variations
-- [ ] Component tests used for UI interaction edge cases
-- [ ] Unit tests used for pure logic edge cases
-
-### Priority Assignment
-
-- [ ] Test priorities assigned using `test-priorities.md` framework
-- [ ] P0 tests: Critical paths, security-critical, data integrity
-- [ ] P1 tests: Important features, integration points, error handling
-- [ ] P2 tests: Edge cases, less-critical variations, performance
-- [ ] P3 tests: Nice-to-have, rarely-used features, exploratory
-- [ ] Priority variables respected:
-  - [ ] `{include_p0}` = true (always include)
-  - [ ] `{include_p1}` = true (high priority)
-  - [ ] `{include_p2}` = true (medium priority)
-  - [ ] `{include_p3}` = false (low priority, skip by default)
-
-### Coverage Plan Created
-
-- [ ] Test coverage plan documented
-- [ ] What will be tested at each level listed
-- [ ] Priorities assigned to each test
-- [ ] Coverage strategy clear (critical-paths, comprehensive, or selective)
-
----
-
-## Step 3: Test Infrastructure Generated
-
-### Fixture Architecture
-
-- [ ] Existing fixtures checked in `tests/support/fixtures/`
-- [ ] Fixture architecture created/enhanced (if `{generate_fixtures}` true)
-- [ ] All fixtures use Playwright's `test.extend()` pattern
-- [ ] All fixtures have auto-cleanup in teardown
-- [ ] Common fixtures created/enhanced:
-  - [ ] authenticatedUser (with auto-delete)
-  - [ ] apiRequest (authenticated client)
-  - [ ] mockNetwork (external service mocking)
-  - [ ] testDatabase (with auto-cleanup)
-
-### Data Factories
-
-- [ ] Existing factories checked in `tests/support/factories/`
-- [ ] Factory architecture created/enhanced (if `{generate_factories}` true)
-- [ ] All factories use `@faker-js/faker` for random data (no hardcoded values)
-- [ ] All factories support overrides for specific scenarios
-- [ ] Common factories created/enhanced:
-  - [ ] User factory (email, password, name, role)
-  - [ ] Product factory (name, price, SKU)
-  - [ ] Order factory (items, total, status)
-- [ ] Cleanup helpers provided (e.g., deleteUser(), deleteProduct())
-
-### Helper Utilities
-
-- [ ] Existing helpers checked in `tests/support/helpers/` (if `{update_helpers}` true)
-- [ ] Common utilities created/enhanced:
-  - [ ] waitFor (polling for complex conditions)
-  - [ ] retry (retry helper for flaky operations)
-  - [ ] testData (test data generation)
-  - [ ] assertions (custom assertion helpers)
-
----
-
-## Step 4: Test Files Generated
-
-### Test File Structure
-
-- [ ] Test files organized correctly:
-  - [ ] `tests/e2e/` for E2E tests
-  - [ ] `tests/api/` for API tests
-  - [ ] `tests/component/` for component tests
-  - [ ] `tests/unit/` for unit tests
-  - [ ] `tests/support/` for fixtures/factories/helpers
-
-### E2E Tests (If Applicable)
-
-- [ ] E2E test files created in `tests/e2e/`
-- [ ] All tests follow Given-When-Then format
-- [ ] All tests have priority tags ([P0], [P1], [P2], [P3]) in test name
-- [ ] All tests use data-testid selectors (not CSS classes)
-- [ ] One assertion per test (atomic design)
-- [ ] No hard waits or sleeps (explicit waits only)
-- [ ] Network-first pattern applied (route interception BEFORE navigation)
-- [ ] Clear Given-When-Then comments in test code
-
-### API Tests (If Applicable)
-
-- [ ] API test files created in `tests/api/`
-- [ ] All tests follow Given-When-Then format
-- [ ] All tests have priority tags in test name
-- [ ] API contracts validated (request/response structure)
-- [ ] HTTP status codes verified
-- [ ] Response body validation includes required fields
-- [ ] Error cases tested (400, 401, 403, 404, 500)
-- [ ] JWT token format validated (if auth tests)
-
-### Component Tests (If Applicable)
-
-- [ ] Component test files created in `tests/component/`
-- [ ] All tests follow Given-When-Then format
-- [ ] All tests have priority tags in test name
-- [ ] Component mounting works correctly
-- [ ] Interaction testing covers user actions (click, hover, keyboard)
-- [ ] State management validated
-- [ ] Props and events tested
-
-### Unit Tests (If Applicable)
-
-- [ ] Unit test files created in `tests/unit/`
-- [ ] All tests follow Given-When-Then format
-- [ ] All tests have priority tags in test name
-- [ ] Pure logic tested (no dependencies)
-- [ ] Edge cases covered
-- [ ] Error handling tested
-
-### Quality Standards Enforced
-
-- [ ] All tests use Given-When-Then format with clear comments
-- [ ] All tests have descriptive names with priority tags
-- [ ] No duplicate tests (same behavior tested multiple times)
-- [ ] No flaky patterns (race conditions, timing issues)
-- [ ] No test interdependencies (tests can run in any order)
-- [ ] Tests are deterministic (same input always produces same result)
-- [ ] All tests use data-testid selectors (E2E tests)
-- [ ] No hard waits: `await page.waitForTimeout()` (forbidden)
-- [ ] No conditional flow: `if (await element.isVisible())` (forbidden)
-- [ ] No try-catch for test logic (only for cleanup)
-- [ ] No hardcoded test data (use factories with faker)
-- [ ] No page object classes (tests are direct and simple)
-- [ ] No shared state between tests
-
-### Network-First Pattern Applied
-
-- [ ] Route interception set up BEFORE navigation (E2E tests with network requests)
-- [ ] `page.route()` called before `page.goto()` to prevent race conditions
-- [ ] Network-first pattern verified in all E2E tests that make API calls
-
----
-
-## Step 5: Test Validation and Healing (NEW - Phase 2.5)
-
-### Healing Configuration
-
-- [ ] Healing configuration checked:
-  - [ ] `{auto_validate}` setting noted (default: true)
-  - [ ] `{auto_heal_failures}` setting noted (default: false)
-  - [ ] `{max_healing_iterations}` setting noted (default: 3)
-  - [ ] `{use_mcp_healing}` setting noted (default: true)
-
-### Healing Knowledge Fragments Loaded (If Healing Enabled)
-
-- [ ] `test-healing-patterns.md` loaded (common failure patterns and fixes)
-- [ ] `selector-resilience.md` loaded (selector refactoring guide)
-- [ ] `timing-debugging.md` loaded (race condition fixes)
-
-### Test Execution and Validation
-
-- [ ] Generated tests executed (if `{auto_validate}` true)
-- [ ] Test results captured:
-  - [ ] Total tests run
-  - [ ] Passing tests count
-  - [ ] Failing tests count
-  - [ ] Error messages and stack traces captured
-
-### Healing Loop (If Enabled and Tests Failed)
-
-- [ ] Healing loop entered (if `{auto_heal_failures}` true AND tests failed)
-- [ ] For each failing test:
-  - [ ] Failure pattern identified (selector, timing, data, network, hard wait)
-  - [ ] Appropriate healing strategy applied:
-    - [ ] Stale selector → Replaced with data-testid or ARIA role
-    - [ ] Race condition → Added network-first interception or state waits
-    - [ ] Dynamic data → Replaced hardcoded values with regex/dynamic generation
-    - [ ] Network error → Added route mocking
-    - [ ] Hard wait → Replaced with event-based wait
-  - [ ] Healed test re-run to validate fix
-  - [ ] Iteration count tracked (max 3 attempts)
-
-### Unfixable Tests Handling
-
-- [ ] Tests that couldn't be healed after 3 iterations marked with `test.fixme()` (if `{mark_unhealable_as_fixme}` true)
-- [ ] Detailed comment added to test.fixme() tests:
-  - [ ] What failure occurred
-  - [ ] What healing was attempted (3 iterations)
-  - [ ] Why healing failed
-  - [ ] Manual investigation steps needed
-- [ ] Original test logic preserved in comments
-
-### Healing Report Generated
-
-- [ ] Healing report generated (if healing attempted)
-- [ ] Report includes:
-  - [ ] Auto-heal enabled status
-  - [ ] Healing mode (MCP-assisted or Pattern-based)
-  - [ ] Iterations allowed (max_healing_iterations)
-  - [ ] Validation results (total, passing, failing)
-  - [ ] Successfully healed tests (count, file:line, fix applied)
-  - [ ] Unable to heal tests (count, file:line, reason)
-  - [ ] Healing patterns applied (selector fixes, timing fixes, data fixes)
-  - [ ] Knowledge base references used
-
----
-
-## Step 6: Documentation and Scripts Updated
-
-### Test README Updated
-
-- [ ] `tests/README.md` created or updated (if `{update_readme}` true)
-- [ ] Test suite structure overview included
-- [ ] Test execution instructions provided (all, specific files, by priority)
-- [ ] Fixture usage examples provided
-- [ ] Factory usage examples provided
-- [ ] Priority tagging convention explained ([P0], [P1], [P2], [P3])
-- [ ] How to write new tests documented
-- [ ] Common patterns documented
-- [ ] Anti-patterns documented (what to avoid)
-
-### package.json Scripts Updated
-
-- [ ] package.json scripts added/updated (if `{update_package_scripts}` true)
-- [ ] `test:e2e` script for all E2E tests
-- [ ] `test:e2e:p0` script for P0 tests only
-- [ ] `test:e2e:p1` script for P0 + P1 tests
-- [ ] `test:api` script for API tests
-- [ ] `test:component` script for component tests
-- [ ] `test:unit` script for unit tests (if applicable)
-
-### Test Suite Executed
-
-- [ ] Test suite run locally (if `{run_tests_after_generation}` true)
-- [ ] Test results captured (passing/failing counts)
-- [ ] No flaky patterns detected (tests are deterministic)
-- [ ] Setup requirements documented (if any)
-- [ ] Known issues documented (if any)
-
----
-
-## Step 6: Automation Summary Generated
-
-### Automation Summary Document
-
-- [ ] Output file created at `{output_summary}`
-- [ ] Document includes execution mode (BMad-Integrated, Standalone, Auto-discover)
-- [ ] Feature analysis included (source files, coverage gaps) - Standalone mode
-- [ ] Tests created listed (E2E, API, Component, Unit) with counts and paths
-- [ ] Infrastructure created listed (fixtures, factories, helpers)
-- [ ] Test execution instructions provided
-- [ ] Coverage analysis included:
-  - [ ] Total test count
-  - [ ] Priority breakdown (P0, P1, P2, P3 counts)
-  - [ ] Test level breakdown (E2E, API, Component, Unit counts)
-  - [ ] Coverage percentage (if calculated)
-  - [ ] Coverage status (acceptance criteria covered, gaps identified)
-- [ ] Definition of Done checklist included
-- [ ] Next steps provided
-- [ ] Recommendations included (if Standalone mode)
-
-### Summary Provided to User
-
-- [ ] Concise summary output provided
-- [ ] Total tests created across test levels
-- [ ] Priority breakdown (P0, P1, P2, P3 counts)
-- [ ] Infrastructure counts (fixtures, factories, helpers)
-- [ ] Test execution command provided
-- [ ] Output file path provided
-- [ ] Next steps listed
-
----
-
-## Quality Checks
-
-### Test Design Quality
-
-- [ ] Tests are readable (clear Given-When-Then structure)
-- [ ] Tests are maintainable (use factories/fixtures, not hardcoded data)
-- [ ] Tests are isolated (no shared state between tests)
-- [ ] Tests are deterministic (no race conditions or flaky patterns)
-- [ ] Tests are atomic (one assertion per test)
-- [ ] Tests are fast (no unnecessary waits or delays)
-- [ ] Tests are lean (files under {max_file_lines} lines)
-
-### Knowledge Base Integration
-
-- [ ] Test level selection framework applied (from `test-levels-framework.md`)
-- [ ] Priority classification applied (from `test-priorities.md`)
-- [ ] Fixture architecture patterns applied (from `fixture-architecture.md`)
-- [ ] Data factory patterns applied (from `data-factories.md`)
-- [ ] Selective testing strategies considered (from `selective-testing.md`)
-- [ ] Flaky test detection patterns considered (from `ci-burn-in.md`)
-- [ ] Test quality principles applied (from `test-quality.md`)
-
-### Code Quality
-
-- [ ] All TypeScript types are correct and complete
-- [ ] No linting errors in generated test files
-- [ ] Consistent naming conventions followed
-- [ ] Imports are organized and correct
-- [ ] Code follows project style guide
-- [ ] No console.log or debug statements in test code
-
----
-
-## Integration Points
-
-### With Framework Workflow
-
-- [ ] Test framework configuration detected and used
-- [ ] Directory structure matches framework setup
-- [ ] Fixtures and helpers follow established patterns
-- [ ] Naming conventions consistent with framework standards
-
-### With BMad Workflows (If Available - OPTIONAL)
-
-**With Story Workflow:**
-
-- [ ] Story ID correctly referenced in output (if story available)
-- [ ] Acceptance criteria from story reflected in tests (if story available)
-- [ ] Technical constraints from story considered (if story available)
-
-**With test-design Workflow:**
-
-- [ ] P0 scenarios from test-design prioritized (if test-design available)
-- [ ] Risk assessment from test-design considered (if test-design available)
-- [ ] Coverage strategy aligned with test-design (if test-design available)
-
-**With atdd Workflow:**
-
-- [ ] ATDD artifacts provided or located (manual handoff; `atdd` not auto-run)
-- [ ] Existing ATDD tests checked (if story had ATDD workflow run)
-- [ ] Expansion beyond ATDD planned (edge cases, negative paths)
-- [ ] No duplicate coverage with ATDD tests
-
-### With CI Pipeline
-
-- [ ] Tests can run in CI environment
-- [ ] Tests are parallelizable (no shared state)
-- [ ] Tests have appropriate timeouts
-- [ ] Tests clean up their data (no CI environment pollution)
-
----
-
-## Completion Criteria
-
-All of the following must be true before marking this workflow as complete:
-
-- [ ] **Execution mode determined** (BMad-Integrated, Standalone, or Auto-discover)
-- [ ] **Framework configuration loaded** and validated
-- [ ] **Coverage analysis completed** (gaps identified if analyze_coverage true)
-- [ ] **Automation targets identified** (what needs testing)
-- [ ] **Test levels selected** appropriately (E2E, API, Component, Unit)
-- [ ] **Duplicate coverage avoided** (same behavior not tested at multiple levels)
-- [ ] **Test priorities assigned** (P0, P1, P2, P3)
-- [ ] **Fixture architecture created/enhanced** with auto-cleanup
-- [ ] **Data factories created/enhanced** using faker (no hardcoded data)
-- [ ] **Helper utilities created/enhanced** (if needed)
-- [ ] **Test files generated** at appropriate levels (E2E, API, Component, Unit)
-- [ ] **Given-When-Then format used** consistently across all tests
-- [ ] **Priority tags added** to all test names ([P0], [P1], [P2], [P3])
-- [ ] **data-testid selectors used** in E2E tests (not CSS classes)
-- [ ] **Network-first pattern applied** (route interception before navigation)
-- [ ] **Quality standards enforced** (no hard waits, no flaky patterns, self-cleaning, deterministic)
-- [ ] **Test README updated** with execution instructions and patterns
-- [ ] **package.json scripts updated** with test execution commands
-- [ ] **Test suite run locally** (if run_tests_after_generation true)
-- [ ] **Tests validated** (if auto_validate enabled)
-- [ ] **Failures healed** (if auto_heal_failures enabled and tests failed)
-- [ ] **Healing report generated** (if healing attempted)
-- [ ] **Unfixable tests marked** with test.fixme() and detailed comments (if any)
-- [ ] **Automation summary created** and saved to correct location
-- [ ] **Output file formatted correctly**
-- [ ] **Knowledge base references applied** and documented (including healing fragments if used)
-- [ ] **No test quality issues** (flaky patterns, race conditions, hardcoded data, page objects)
-
----
-
-## Common Issues and Resolutions
-
-### Issue: BMad artifacts not found
-
-**Problem:** Story, tech-spec, or PRD files not found when variables are set.
-
-**Resolution:**
-
-- **automate does NOT require BMad artifacts** - they are OPTIONAL enhancements
-- If files not found, switch to Standalone Mode automatically
-- Analyze source code directly without BMad context
-- Continue workflow without halting
-
-### Issue: Framework configuration not found
-
-**Problem:** No playwright.config.ts or cypress.config.ts found.
-
-**Resolution:**
-
-- **HALT workflow** - framework is required
-- Message: "Framework scaffolding required. Run `bmad tea *framework` first."
-- User must run framework workflow before automate
-
-### Issue: No automation targets identified
-
-**Problem:** Neither story, target_feature, nor target_files specified, and auto-discover finds nothing.
-
-**Resolution:**
-
-- Check if source_dir variable is correct
-- Verify source code exists in project
-- Ask user to specify target_feature or target_files explicitly
-- Provide examples: `target_feature: "src/auth/"` or `target_files: "src/auth/login.ts,src/auth/session.ts"`
-
-### Issue: Duplicate coverage detected
-
-**Problem:** Same behavior tested at multiple levels (E2E + API + Component).
-
-**Resolution:**
-
-- Review test level selection framework (test-levels-framework.md)
-- Use E2E for critical happy path ONLY
-- Use API for business logic variations
-- Use Component for UI edge cases
-- Remove redundant tests that duplicate coverage
-
-### Issue: Tests have hardcoded data
-
-**Problem:** Tests use hardcoded email addresses, passwords, or other data.
-
-**Resolution:**
-
-- Replace all hardcoded data with factory function calls
-- Use faker for all random data generation
-- Update data-factories to support all required test scenarios
-- Example: `createUser({ email: faker.internet.email() })`
-
-### Issue: Tests are flaky
-
-**Problem:** Tests fail intermittently, pass on retry.
-
-**Resolution:**
-
-- Remove all hard waits (`page.waitForTimeout()`)
-- Use explicit waits (`page.waitForSelector()`)
-- Apply network-first pattern (route interception before navigation)
-- Remove conditional flow (`if (await element.isVisible())`)
-- Ensure tests are deterministic (no race conditions)
-- Run burn-in loop (10 iterations) to detect flakiness
-
-### Issue: Fixtures don't clean up data
-
-**Problem:** Test data persists after test run, causing test pollution.
-
-**Resolution:**
-
-- Ensure all fixtures have cleanup in teardown phase
-- Cleanup happens AFTER `await use(data)`
-- Call deletion/cleanup functions (deleteUser, deleteProduct, etc.)
-- Verify cleanup works by checking database/storage after test run
-
-### Issue: Tests too slow
-
-**Problem:** Tests take longer than 90 seconds (max_test_duration).
-
-**Resolution:**
-
-- Remove unnecessary waits and delays
-- Use parallel execution where possible
-- Mock external services (don't make real API calls)
-- Use API tests instead of E2E for business logic
-- Optimize test data creation (use in-memory database, etc.)
-
----
-
-## Notes for TEA Agent
-
-- **automate is flexible:** Can work with or without BMad artifacts (story, tech-spec, PRD are OPTIONAL)
-- **Standalone mode is powerful:** Analyze any codebase and generate tests independently
-- **Auto-discover mode:** Scan codebase for features needing tests when no targets specified
-- **Framework is the ONLY hard requirement:** HALT if framework config missing, otherwise proceed
-- **Avoid duplicate coverage:** E2E for critical paths only, API/Component for variations
-- **Priority tagging enables selective execution:** P0 tests run on every commit, P1 on PR, P2 nightly
-- **Network-first pattern prevents race conditions:** Route interception BEFORE navigation
-- **No page objects:** Keep tests simple, direct, and maintainable
-- **Use knowledge base:** Load relevant fragments (test-levels, test-priorities, fixture-architecture, data-factories, healing patterns) for guidance
-- **Deterministic tests only:** No hard waits, no conditional flow, no flaky patterns allowed
-- **Optional healing:** auto_heal_failures disabled by default (opt-in for automatic test healing)
-- **Graceful degradation:** Healing works without Playwright MCP (pattern-based fallback)
-- **Unfixable tests handled:** Mark with test.fixme() and detailed comments (not silently broken)

_bmad/bmm/workflows/testarch/automate/instructions.md

@@ -1,1324 +0,0 @@
-<!-- Powered by BMAD-CORE™ -->
-
-# Test Automation Expansion
-
-**Workflow ID**: `_bmad/bmm/testarch/automate`
-**Version**: 4.0 (BMad v6)
-
----
-
-## Overview
-
-Expands test automation coverage by generating comprehensive test suites at appropriate levels (E2E, API, Component, Unit) with supporting infrastructure. This workflow operates in **dual mode**:
-
-1. **BMad-Integrated Mode**: Works WITH BMad artifacts (story, tech-spec, PRD, test-design) to expand coverage after story implementation
-2. **Standalone Mode**: Works WITHOUT BMad artifacts - analyzes existing codebase and generates tests independently
-
-**Core Principle**: Generate prioritized, deterministic tests that avoid duplicate coverage and follow testing best practices.
-
----
-
-## Preflight Requirements
-
-**Flexible:** This workflow can run with minimal prerequisites. Only HALT if framework is completely missing.
-
-### Required (Always)
-
-- ✅ Framework scaffolding configured (run `framework` workflow if missing)
-- ✅ Test framework configuration available (playwright.config.ts or cypress.config.ts)
-
-### Optional (BMad-Integrated Mode)
-
-- Story markdown with acceptance criteria (enhances coverage targeting)
-- Tech spec or PRD (provides architectural context)
-- Test design document (provides risk/priority context)
-
-### Optional (Standalone Mode)
-
-- Source code to analyze (feature implementation)
-- Existing tests (for gap analysis)
-
-**If framework is missing:** HALT with message: "Framework scaffolding required. Run `bmad tea *framework` first."
-
----
-
-## Step 1: Determine Execution Mode and Load Context
-
-### Actions
-
-1. **Detect Execution Mode**
-
-   Check if BMad artifacts are available:
-   - If `{story_file}` variable is set → BMad-Integrated Mode
-   - If `{target_feature}` or `{target_files}` set → Standalone Mode
-   - If neither set → Auto-discover mode (scan codebase for features needing tests)
-
-2. **Load BMad Artifacts (If Available)**
-
-   **BMad-Integrated Mode:**
-   - Read story markdown from `{story_file}`
-   - Extract acceptance criteria and technical requirements
-   - Load tech-spec.md if `{use_tech_spec}` is true
-   - Load test-design.md if `{use_test_design}` is true
-   - Load PRD.md if `{use_prd}` is true
-   - Note: These are **optional enhancements**, not hard requirements
-
-   **Standalone Mode:**
-   - Skip BMad artifact loading
-   - Proceed directly to source code analysis
-
-3. **Load Framework Configuration**
-   - Read test framework config (playwright.config.ts or cypress.config.ts)
-   - Identify test directory structure from `{test_dir}`
-   - Check existing test patterns in `{test_dir}`
-   - Note test runner capabilities (parallel execution, fixtures, etc.)
-
-4. **Analyze Existing Test Coverage**
-
-   If `{analyze_coverage}` is true:
-   - Search `{test_dir}` for existing test files
-   - Identify tested features vs untested features
-   - Map tests to source files (coverage gaps)
-   - Check existing fixture and factory patterns
-
-5. **Check Playwright Utils Flag**
-
-   Read `{config_source}` and check `config.tea_use_playwright_utils`.
-
-6. **Load Knowledge Base Fragments**
-
-   **Critical:** Consult `{project-root}/_bmad/bmm/testarch/tea-index.csv` to load:
-
-   **Core Testing Patterns (Always load):**
-   - `test-levels-framework.md` - Test level selection (E2E vs API vs Component vs Unit with decision matrix, 467 lines, 4 examples)
-   - `test-priorities-matrix.md` - Priority classification (P0-P3 with automated scoring, risk mapping, 389 lines, 2 examples)
-   - `data-factories.md` - Factory patterns with faker (overrides, nested factories, API seeding, 498 lines, 5 examples)
-   - `selective-testing.md` - Targeted test execution strategies (tag-based, spec filters, diff-based, promotion rules, 727 lines, 4 examples)
-   - `ci-burn-in.md` - Flaky test detection patterns (10-iteration burn-in, sharding, selective execution, 678 lines, 4 examples)
-   - `test-quality.md` - Test design principles (deterministic, isolated, explicit assertions, length/time limits, 658 lines, 5 examples)
-
-   **If `config.tea_use_playwright_utils: true` (Playwright Utils Integration - All Utilities):**
-   - `overview.md` - Playwright utils installation, design principles, fixture patterns
-   - `api-request.md` - Typed HTTP client with schema validation
-   - `network-recorder.md` - HAR record/playback for offline testing
-   - `auth-session.md` - Token persistence and multi-user support
-   - `intercept-network-call.md` - Network spy/stub with automatic JSON parsing
-   - `recurse.md` - Cypress-style polling for async conditions
-   - `log.md` - Playwright report-integrated logging
-   - `file-utils.md` - CSV/XLSX/PDF/ZIP reading and validation
-   - `burn-in.md` - Smart test selection (relevant for CI test generation)
-   - `network-error-monitor.md` - Automatic HTTP error detection
-   - `fixtures-composition.md` - mergeTests composition patterns
-
-   **If `config.tea_use_playwright_utils: false` (Traditional Patterns):**
-   - `fixture-architecture.md` - Test fixture patterns (pure function → fixture → mergeTests, auto-cleanup, 406 lines, 5 examples)
-   - `network-first.md` - Route interception patterns (intercept before navigate, HAR capture, deterministic waiting, 489 lines, 5 examples)
-
-   **Healing Knowledge (If `{auto_heal_failures}` is true):**
-   - `test-healing-patterns.md` - Common failure patterns and automated fixes (stale selectors, race conditions, dynamic data, network errors, hard waits, 648 lines, 5 examples)
-   - `selector-resilience.md` - Selector debugging and refactoring guide (data-testid > ARIA > text > CSS hierarchy, anti-patterns, 541 lines, 4 examples)
-   - `timing-debugging.md` - Race condition identification and fixes (network-first, deterministic waiting, async debugging, 370 lines, 3 examples)
-
----
-
-## Step 2: Identify Automation Targets
-
-### Actions
-
-1. **Determine What Needs Testing**
-
-   **BMad-Integrated Mode (story available):**
-   - Map acceptance criteria from story to test scenarios
-   - Identify features implemented in this story
-   - Check if story has existing ATDD tests (from `*atdd` workflow)
-   - Expand beyond ATDD with edge cases and negative paths
-
-   **Standalone Mode (no story):**
-   - If `{target_feature}` specified: Analyze that specific feature
-   - If `{target_files}` specified: Analyze those specific files
-   - If `{auto_discover_features}` is true: Scan `{source_dir}` for features
-   - Prioritize features with:
-     - No test coverage (highest priority)
-     - Complex business logic
-     - External integrations (API calls, database, auth)
-     - Critical user paths (login, checkout, etc.)
-
-2. **Apply Test Level Selection Framework**
-
-   **Knowledge Base Reference**: `test-levels-framework.md`
-
-   For each feature or acceptance criterion, determine appropriate test level:
-
-   **E2E (End-to-End)**:
-   - Critical user journeys (login, checkout, core workflows)
-   - Multi-system integration
-   - Full user-facing scenarios
-   - Characteristics: High confidence, slow, brittle
-
-   **API (Integration)**:
-   - Business logic validation
-   - Service contracts and data transformations
-   - Backend integration without UI
-   - Characteristics: Fast feedback, stable, good balance
-
-   **Component**:
-   - UI component behavior (buttons, forms, modals)
-   - Interaction testing (click, hover, keyboard)
-   - State management within component
-   - Characteristics: Fast, isolated, granular
-
-   **Unit**:
-   - Pure business logic and algorithms
-   - Edge cases and error handling
-   - Minimal dependencies
-   - Characteristics: Fastest, most granular
-
-3. **Avoid Duplicate Coverage**
-
-   **Critical principle:** Don't test same behavior at multiple levels unless necessary
-   - Use E2E for critical happy path only
-   - Use API tests for business logic variations
-   - Use component tests for UI interaction edge cases
-   - Use unit tests for pure logic edge cases
-
-   **Example:**
-   - E2E: User can log in with valid credentials → Dashboard loads
-   - API: POST /auth/login returns 401 for invalid credentials
-   - API: POST /auth/login returns 200 and JWT token for valid credentials
-   - Component: LoginForm disables submit button when fields are empty
-   - Unit: validateEmail() returns false for malformed email addresses
-
-4. **Assign Test Priorities**
-
-   **Knowledge Base Reference**: `test-priorities-matrix.md`
-
-   **P0 (Critical - Every commit)**:
-   - Critical user paths that must always work
-   - Security-critical functionality (auth, permissions)
-   - Data integrity scenarios
-   - Run in pre-commit hooks or PR checks
-
-   **P1 (High - PR to main)**:
-   - Important features with high user impact
-   - Integration points between systems
-   - Error handling for common failures
-   - Run before merging to main branch
-
-   **P2 (Medium - Nightly)**:
-   - Edge cases with moderate impact
-   - Less-critical feature variations
-   - Performance/load testing
-   - Run in nightly CI builds
-
-   **P3 (Low - On-demand)**:
-   - Nice-to-have validations
-   - Rarely-used features
-   - Exploratory testing scenarios
-   - Run manually or weekly
-
-   **Priority Variables:**
-   - `{include_p0}` - Always include (default: true)
-   - `{include_p1}` - High priority (default: true)
-   - `{include_p2}` - Medium priority (default: true)
-   - `{include_p3}` - Low priority (default: false)
-
-5. **Create Test Coverage Plan**
-
-   Document what will be tested at each level with priorities:
-
-   ```markdown
-   ## Test Coverage Plan
-
-   ### E2E Tests (P0)
-
-   - User login with valid credentials → Dashboard loads
-   - User logout → Redirects to login page
-
-   ### API Tests (P1)
-
-   - POST /auth/login - valid credentials → 200 + JWT token
-   - POST /auth/login - invalid credentials → 401 + error message
-   - POST /auth/login - missing fields → 400 + validation errors
-
-   ### Component Tests (P1)
-
-   - LoginForm - empty fields → submit button disabled
-   - LoginForm - valid input → submit button enabled
-
-   ### Unit Tests (P2)
-
-   - validateEmail() - valid email → returns true
-   - validateEmail() - malformed email → returns false
-   ```
-
----
-
-## Step 3: Generate Test Infrastructure
-
-### Actions
-
-1. **Enhance Fixture Architecture**
-
-   **Knowledge Base Reference**: `fixture-architecture.md`
-
-   Check existing fixtures in `tests/support/fixtures/`:
-   - If missing or incomplete, create fixture architecture
-   - Use Playwright's `test.extend()` pattern
-   - Ensure all fixtures have auto-cleanup in teardown
-
-   **Common fixtures to create/enhance:**
-   - **authenticatedUser**: User with valid session (auto-deletes user after test)
-   - **apiRequest**: Authenticated API client with base URL and headers
-   - **mockNetwork**: Network mocking for external services
-   - **testDatabase**: Database with test data (auto-cleanup after test)
-
-   **Example fixture:**
-
-   ```typescript
-   // tests/support/fixtures/auth.fixture.ts
-   import { test as base } from '@playwright/test';
-   import { createUser, deleteUser } from '../factories/user.factory';
-
-   export const test = base.extend({
-     authenticatedUser: async ({ page }, use) => {
-       // Setup: Create and authenticate user
-       const user = await createUser();
-       await page.goto('/login');
-       await page.fill('[data-testid="email"]', user.email);
-       await page.fill('[data-testid="password"]', user.password);
-       await page.click('[data-testid="login-button"]');
-       await page.waitForURL('/dashboard');
-
-       // Provide to test
-       await use(user);
-
-       // Cleanup: Delete user automatically
-       await deleteUser(user.id);
-     },
-   });
-   ```
-
-2. **Enhance Data Factories**
-
-   **Knowledge Base Reference**: `data-factories.md`
-
-   Check existing factories in `tests/support/factories/`:
-   - If missing or incomplete, create factory architecture
-   - Use `@faker-js/faker` for all random data (no hardcoded values)
-   - Support overrides for specific test scenarios
-
-   **Common factories to create/enhance:**
-   - User factory (email, password, name, role)
-   - Product factory (name, price, description, SKU)
-   - Order factory (items, total, status, customer)
-
-   **Example factory:**
-
-   ```typescript
-   // tests/support/factories/user.factory.ts
-   import { faker } from '@faker-js/faker';
-
-   export const createUser = (overrides = {}) => ({
-     id: faker.number.int(),
-     email: faker.internet.email(),
-     password: faker.internet.password(),
-     name: faker.person.fullName(),
-     role: 'user',
-     createdAt: faker.date.recent().toISOString(),
-     ...overrides,
-   });
-
-   export const createUsers = (count: number) => Array.from({ length: count }, () => createUser());
-
-   // API helper for cleanup
-   export const deleteUser = async (userId: number) => {
-     await fetch(`/api/users/${userId}`, { method: 'DELETE' });
-   };
-   ```
-
-3. **Create/Enhance Helper Utilities**
-
-   If `{update_helpers}` is true:
-
-   Check `tests/support/helpers/` for common utilities:
-   - **waitFor**: Polling helper for complex conditions
-   - **retry**: Retry helper for flaky operations
-   - **testData**: Test data generation helpers
-   - **assertions**: Custom assertion helpers
-
-   **Example helper:**
-
-   ```typescript
-   // tests/support/helpers/wait-for.ts
-   export const waitFor = async (condition: () => Promise<boolean>, timeout = 5000, interval = 100): Promise<void> => {
-     const startTime = Date.now();
-     while (Date.now() - startTime < timeout) {
-       if (await condition()) return;
-       await new Promise((resolve) => setTimeout(resolve, interval));
-     }
-     throw new Error(`Condition not met within ${timeout}ms`);
-   };
-   ```
-
----
-
-## Step 4: Generate Test Files
-
-### Actions
-
-1. **Create Test File Structure**
-
-   ```
-   tests/
-   ├── e2e/
-   │   └── {feature-name}.spec.ts        # E2E tests (P0-P1)
-   ├── api/
-   │   └── {feature-name}.api.spec.ts    # API tests (P1-P2)
-   ├── component/
-   │   └── {ComponentName}.test.tsx      # Component tests (P1-P2)
-   ├── unit/
-   │   └── {module-name}.test.ts         # Unit tests (P2-P3)
-   └── support/
-       ├── fixtures/                      # Test fixtures
-       ├── factories/                     # Data factories
-       └── helpers/                       # Utility functions
-   ```
-
-2. **Write E2E Tests (If Applicable)**
-
-   **Follow Given-When-Then format:**
-
-   ```typescript
-   import { test, expect } from '@playwright/test';
-
-   test.describe('User Authentication', () => {
-     test('[P0] should login with valid credentials and load dashboard', async ({ page }) => {
-       // GIVEN: User is on login page
-       await page.goto('/login');
-
-       // WHEN: User submits valid credentials
-       await page.fill('[data-testid="email-input"]', 'user@example.com');
-       await page.fill('[data-testid="password-input"]', 'Password123!');
-       await page.click('[data-testid="login-button"]');
-
-       // THEN: User is redirected to dashboard
-       await expect(page).toHaveURL('/dashboard');
-       await expect(page.locator('[data-testid="user-name"]')).toBeVisible();
-     });
-
-     test('[P1] should display error for invalid credentials', async ({ page }) => {
-       // GIVEN: User is on login page
-       await page.goto('/login');
-
-       // WHEN: User submits invalid credentials
-       await page.fill('[data-testid="email-input"]', 'invalid@example.com');
-       await page.fill('[data-testid="password-input"]', 'wrongpassword');
-       await page.click('[data-testid="login-button"]');
-
-       // THEN: Error message is displayed
-       await expect(page.locator('[data-testid="error-message"]')).toHaveText('Invalid email or password');
-     });
-   });
-   ```
-
-   **Critical patterns:**
-   - Tag tests with priority: `[P0]`, `[P1]`, `[P2]`, `[P3]` in test name
-   - One assertion per test (atomic tests)
-   - Explicit waits (no hard waits/sleeps)
-   - Network-first approach (route interception before navigation)
-   - data-testid selectors for stability
-   - Clear Given-When-Then structure
-
-3. **Write API Tests (If Applicable)**
-
-   ```typescript
-   import { test, expect } from '@playwright/test';
-
-   test.describe('User Authentication API', () => {
-     test('[P1] POST /api/auth/login - should return token for valid credentials', async ({ request }) => {
-       // GIVEN: Valid user credentials
-       const credentials = {
-         email: 'user@example.com',
-         password: 'Password123!',
-       };
-
-       // WHEN: Logging in via API
-       const response = await request.post('/api/auth/login', {
-         data: credentials,
-       });
-
-       // THEN: Returns 200 and JWT token
-       expect(response.status()).toBe(200);
-       const body = await response.json();
-       expect(body).toHaveProperty('token');
-       expect(body.token).toMatch(/^[A-Za-z0-9-_]+\.[A-Za-z0-9-_]+\.[A-Za-z0-9-_]+$/); // JWT format
-     });
-
-     test('[P1] POST /api/auth/login - should return 401 for invalid credentials', async ({ request }) => {
-       // GIVEN: Invalid credentials
-       const credentials = {
-         email: 'invalid@example.com',
-         password: 'wrongpassword',
-       };
-
-       // WHEN: Attempting login
-       const response = await request.post('/api/auth/login', {
-         data: credentials,
-       });
-
-       // THEN: Returns 401 with error
-       expect(response.status()).toBe(401);
-       const body = await response.json();
-       expect(body).toMatchObject({
-         error: 'Invalid credentials',
-       });
-     });
-   });
-   ```
-
-4. **Write Component Tests (If Applicable)**
-
-   **Knowledge Base Reference**: `component-tdd.md`
-
-   ```typescript
-   import { test, expect } from '@playwright/experimental-ct-react';
-   import { LoginForm } from './LoginForm';
-
-   test.describe('LoginForm Component', () => {
-     test('[P1] should disable submit button when fields are empty', async ({ mount }) => {
-       // GIVEN: LoginForm is mounted
-       const component = await mount(<LoginForm />);
-
-       // WHEN: Form is initially rendered
-       const submitButton = component.locator('button[type="submit"]');
-
-       // THEN: Submit button is disabled
-       await expect(submitButton).toBeDisabled();
-     });
-
-     test('[P1] should enable submit button when fields are filled', async ({ mount }) => {
-       // GIVEN: LoginForm is mounted
-       const component = await mount(<LoginForm />);
-
-       // WHEN: User fills in email and password
-       await component.locator('[data-testid="email-input"]').fill('user@example.com');
-       await component.locator('[data-testid="password-input"]').fill('Password123!');
-
-       // THEN: Submit button is enabled
-       const submitButton = component.locator('button[type="submit"]');
-       await expect(submitButton).toBeEnabled();
-     });
-   });
-   ```
-
-5. **Write Unit Tests (If Applicable)**
-
-   ```typescript
-   import { validateEmail } from './validation';
-
-   describe('Email Validation', () => {
-     test('[P2] should return true for valid email', () => {
-       // GIVEN: Valid email address
-       const email = 'user@example.com';
-
-       // WHEN: Validating email
-       const result = validateEmail(email);
-
-       // THEN: Returns true
-       expect(result).toBe(true);
-     });
-
-     test('[P2] should return false for malformed email', () => {
-       // GIVEN: Malformed email addresses
-       const invalidEmails = ['notanemail', '@example.com', 'user@', 'user @example.com'];
-
-       // WHEN/THEN: Each should fail validation
-       invalidEmails.forEach((email) => {
-         expect(validateEmail(email)).toBe(false);
-       });
-     });
-   });
-   ```
-
-6. **Apply Network-First Pattern (E2E tests)**
-
-   **Knowledge Base Reference**: `network-first.md`
-
-   **Critical pattern to prevent race conditions:**
-
-   ```typescript
-   test('should load user dashboard after login', async ({ page }) => {
-     // CRITICAL: Intercept routes BEFORE navigation
-     await page.route('**/api/user', (route) =>
-       route.fulfill({
-         status: 200,
-         body: JSON.stringify({ id: 1, name: 'Test User' }),
-       }),
-     );
-
-     // NOW navigate
-     await page.goto('/dashboard');
-
-     await expect(page.locator('[data-testid="user-name"]')).toHaveText('Test User');
-   });
-   ```
-
-7. **Enforce Quality Standards**
-
-   **For every test:**
-   - ✅ Uses Given-When-Then format
-   - ✅ Has clear, descriptive name with priority tag
-   - ✅ One assertion per test (atomic)
-   - ✅ No hard waits or sleeps (use explicit waits)
-   - ✅ Self-cleaning (uses fixtures with auto-cleanup)
-   - ✅ Deterministic (no flaky patterns)
-   - ✅ Fast (under {max_test_duration} seconds)
-   - ✅ Lean (test file under {max_file_lines} lines)
-
-   **Forbidden patterns:**
-   - ❌ Hard waits: `await page.waitForTimeout(2000)`
-   - ❌ Conditional flow: `if (await element.isVisible()) { ... }`
-   - ❌ Try-catch for test logic (use for cleanup only)
-   - ❌ Hardcoded test data (use factories)
-   - ❌ Page objects (keep tests simple and direct)
-   - ❌ Shared state between tests
-
----
-
-## Step 5: Execute, Validate & Heal Generated Tests (NEW - Phase 2.5)
-
-**Purpose**: Automatically validate generated tests and heal common failures before delivery
-
-### Actions
-
-1. **Validate Generated Tests**
-
-   Always validate (auto_validate is always true):
-   - Run generated tests to verify they work
-   - Continue with healing if config.tea_use_mcp_enhancements is true
-
-2. **Run Generated Tests**
-
-   Execute the full test suite that was just generated:
-
-   ```bash
-   npx playwright test {generated_test_files}
-   ```
-
-   Capture results:
-   - Total tests run
-   - Passing tests count
-   - Failing tests count
-   - Error messages and stack traces for failures
-
-3. **Evaluate Results**
-
-   **If ALL tests pass:**
-   - ✅ Generate report with success summary
-   - Proceed to Step 6 (Documentation and Scripts)
-
-   **If tests FAIL:**
-   - Check config.tea_use_mcp_enhancements setting
-   - If true: Enter healing loop (Step 5.4)
-   - If false: Document failures for manual review, proceed to Step 6
-
-4. **Healing Loop (If config.tea_use_mcp_enhancements is true)**
-
-   **Iteration limit**: 3 attempts per test (constant)
-
-   **For each failing test:**
-
-   **A. Load Healing Knowledge Fragments**
-
-   Consult `tea-index.csv` to load healing patterns:
-   - `test-healing-patterns.md` - Common failure patterns and fixes
-   - `selector-resilience.md` - Selector debugging and refactoring
-   - `timing-debugging.md` - Race condition identification and fixes
-
-   **B. Identify Failure Pattern**
-
-   Analyze error message and stack trace to classify failure type:
-
-   **Stale Selector Failure:**
-   - Error contains: "locator resolved to 0 elements", "element not found", "unable to find element"
-   - Extract selector from error message
-   - Apply selector healing (knowledge from `selector-resilience.md`):
-     - If CSS class → Replace with `page.getByTestId()`
-     - If nth() → Replace with `filter({ hasText })`
-     - If ID → Replace with data-testid
-     - If complex XPath → Replace with ARIA role
-
-   **Race Condition Failure:**
-   - Error contains: "timeout waiting for", "element not visible", "timed out retrying"
-   - Detect missing network waits or hard waits in test code
-   - Apply timing healing (knowledge from `timing-debugging.md`):
-     - Add network-first interception before navigate
-     - Replace `waitForTimeout()` with `waitForResponse()`
-     - Add explicit element state waits (`waitFor({ state: 'visible' })`)
-
-   **Dynamic Data Failure:**
-   - Error contains: "Expected 'User 123' but received 'User 456'", timestamp mismatches
-   - Identify hardcoded assertions
-   - Apply data healing (knowledge from `test-healing-patterns.md`):
-     - Replace hardcoded IDs with regex (`/User \d+/`)
-     - Replace hardcoded dates with dynamic generation
-     - Capture dynamic values and use in assertions
-
-   **Network Error Failure:**
-   - Error contains: "API call failed", "500 error", "network error"
-   - Detect missing route interception
-   - Apply network healing (knowledge from `test-healing-patterns.md`):
-     - Add `page.route()` or `cy.intercept()` for API mocking
-     - Mock error scenarios (500, 429, timeout)
-
-   **Hard Wait Detection:**
-   - Scan test code for `page.waitForTimeout()`, `cy.wait(number)`, `sleep()`
-   - Apply hard wait healing (knowledge from `timing-debugging.md`):
-     - Replace with event-based waits
-     - Add network response waits
-     - Use element state changes
-
-   **C. MCP Healing Mode (If MCP Tools Available)**
-
-   If Playwright MCP tools are available in your IDE:
-
-   Use MCP tools for interactive healing:
-   - `playwright_test_debug_test`: Pause on failure for visual inspection
-   - `browser_snapshot`: Capture visual context at failure point
-   - `browser_console_messages`: Retrieve console logs for JS errors
-   - `browser_network_requests`: Analyze network activity
-   - `browser_generate_locator`: Generate better selectors interactively
-
-   Apply MCP-generated fixes to test code.
-
-   **D. Pattern-Based Healing Mode (Fallback)**
-
-   If MCP unavailable, use pattern-based analysis:
-   - Parse error message and stack trace
-   - Match against failure patterns from knowledge base
-   - Apply fixes programmatically:
-     - Selector fixes: Use suggestions from `selector-resilience.md`
-     - Timing fixes: Apply patterns from `timing-debugging.md`
-     - Data fixes: Use patterns from `test-healing-patterns.md`
-
-   **E. Apply Healing Fix**
-   - Modify test file with healed code
-   - Re-run test to validate fix
-   - If test passes: Mark as healed, move to next failure
-   - If test fails: Increment iteration count, try different pattern
-
-   **F. Iteration Limit Handling**
-
-   After 3 failed healing attempts:
-
-   Always mark unfixable tests:
-   - Mark test with `test.fixme()` instead of `test()`
-   - Add detailed comment explaining:
-     - What failure occurred
-     - What healing was attempted (3 iterations)
-     - Why healing failed
-     - Manual investigation needed
-
-   ```typescript
-   test.fixme('[P1] should handle complex interaction', async ({ page }) => {
-     // FIXME: Test healing failed after 3 attempts
-     // Failure: "Locator 'button[data-action="submit"]' resolved to 0 elements"
-     // Attempted fixes:
-     //   1. Replaced with page.getByTestId('submit-button') - still failing
-     //   2. Replaced with page.getByRole('button', { name: 'Submit' }) - still failing
-     //   3. Added waitForLoadState('networkidle') - still failing
-     // Manual investigation needed: Selector may require application code changes
-     // TODO: Review with team, may need data-testid added to button component
-     // Original test code...
-   });
-   ```
-
-   **Note**: Workflow continues even with unfixable tests (marked as test.fixme() for manual review)
-
-5. **Generate Healing Report**
-
-   Document healing outcomes:
-
-   ```markdown
-   ## Test Healing Report
-
-   **Auto-Heal Enabled**: {auto_heal_failures}
-   **Healing Mode**: {use_mcp_healing ? "MCP-assisted" : "Pattern-based"}
-   **Iterations Allowed**: {max_healing_iterations}
-
-   ### Validation Results
-
-   - **Total tests**: {total_tests}
-   - **Passing**: {passing_tests}
-   - **Failing**: {failing_tests}
-
-   ### Healing Outcomes
-
-   **Successfully Healed ({healed_count} tests):**
-
-   - `tests/e2e/login.spec.ts:15` - Stale selector (CSS class → data-testid)
-   - `tests/e2e/checkout.spec.ts:42` - Race condition (added network-first interception)
-   - `tests/api/users.spec.ts:28` - Dynamic data (hardcoded ID → regex pattern)
-
-   **Unable to Heal ({unfixable_count} tests):**
-
-   - `tests/e2e/complex-flow.spec.ts:67` - Marked as test.fixme() with manual investigation needed
-     - Failure: Locator not found after 3 healing attempts
-     - Requires application code changes (add data-testid to component)
-
-   ### Healing Patterns Applied
-
-   - **Selector fixes**: 2 (CSS class → data-testid, nth() → filter())
-   - **Timing fixes**: 1 (added network-first interception)
-   - **Data fixes**: 1 (hardcoded ID → regex)
-
-   ### Knowledge Base References
-
-   - `test-healing-patterns.md` - Common failure patterns
-   - `selector-resilience.md` - Selector refactoring guide
-   - `timing-debugging.md` - Race condition prevention
-   ```
-
-6. **Update Test Files with Healing Results**
-   - Save healed test code to files
-   - Mark unfixable tests with `test.fixme()` and detailed comments
-   - Preserve original test logic in comments (for debugging)
-
----
-
-## Step 6: Update Documentation and Scripts
-
-### Actions
-
-1. **Update Test README**
-
-   If `{update_readme}` is true:
-
-   Create or update `tests/README.md` with:
-   - Overview of test suite structure
-   - How to run tests (all, specific files, by priority)
-   - Fixture and factory usage examples
-   - Priority tagging convention ([P0], [P1], [P2], [P3])
-   - How to write new tests
-   - Common patterns and anti-patterns
-
-   **Example section:**
-
-   ````markdown
-   ## Running Tests
-
-   ```bash
-   # Run all tests
-   npm run test:e2e
-
-   # Run by priority
-   npm run test:e2e -- --grep "@P0"
-   npm run test:e2e -- --grep "@P1"
-
-   # Run specific file
-   npm run test:e2e -- user-authentication.spec.ts
-
-   # Run in headed mode
-   npm run test:e2e -- --headed
-
-   # Debug specific test
-   npm run test:e2e -- user-authentication.spec.ts --debug
-   ```
-   ````
-
-   ## Priority Tags
-   - **[P0]**: Critical paths, run every commit
-   - **[P1]**: High priority, run on PR to main
-   - **[P2]**: Medium priority, run nightly
-   - **[P3]**: Low priority, run on-demand
-
-   ```
-
-   ```
-
-2. **Update package.json Scripts**
-
-   If `{update_package_scripts}` is true:
-
-   Add or update test execution scripts:
-
-   ```json
-   {
-     "scripts": {
-       "test:e2e": "playwright test",
-       "test:e2e:p0": "playwright test --grep '@P0'",
-       "test:e2e:p1": "playwright test --grep '@P1|@P0'",
-       "test:api": "playwright test tests/api",
-       "test:component": "playwright test tests/component",
-       "test:unit": "vitest"
-     }
-   }
-   ```
-
-3. **Run Test Suite**
-
-   If `{run_tests_after_generation}` is true:
-   - Run full test suite locally
-   - Capture results (passing/failing counts)
-   - Verify no flaky patterns (tests should be deterministic)
-   - Document any setup requirements or known issues
-
----
-
-## Step 6: Generate Automation Summary
-
-### Actions
-
-1. **Create Automation Summary Document**
-
-   Save to `{output_summary}` with:
-
-   **BMad-Integrated Mode:**
-
-   ````markdown
-   # Automation Summary - {feature_name}
-
-   **Date:** {date}
-   **Story:** {story_id}
-   **Coverage Target:** {coverage_target}
-
-   ## Tests Created
-
-   ### E2E Tests (P0-P1)
-
-   - `tests/e2e/user-authentication.spec.ts` (2 tests, 87 lines)
-     - [P0] Login with valid credentials → Dashboard loads
-     - [P1] Display error for invalid credentials
-
-   ### API Tests (P1-P2)
-
-   - `tests/api/auth.api.spec.ts` (3 tests, 102 lines)
-     - [P1] POST /auth/login - valid credentials → 200 + token
-     - [P1] POST /auth/login - invalid credentials → 401 + error
-     - [P2] POST /auth/login - missing fields → 400 + validation
-
-   ### Component Tests (P1)
-
-   - `tests/component/LoginForm.test.tsx` (2 tests, 45 lines)
-     - [P1] Empty fields → submit button disabled
-     - [P1] Valid input → submit button enabled
-
-   ## Infrastructure Created
-
-   ### Fixtures
-
-   - `tests/support/fixtures/auth.fixture.ts` - authenticatedUser with auto-cleanup
-
-   ### Factories
-
-   - `tests/support/factories/user.factory.ts` - createUser(), deleteUser()
-
-   ### Helpers
-
-   - `tests/support/helpers/wait-for.ts` - Polling helper for complex conditions
-
-   ## Test Execution
-
-   ```bash
-   # Run all new tests
-   npm run test:e2e
-
-   # Run by priority
-   npm run test:e2e:p0  # Critical paths only
-   npm run test:e2e:p1  # P0 + P1 tests
-   ```
-   ````
-
-   ## Coverage Analysis
-
-   **Total Tests:** 7
-   - P0: 1 test (critical path)
-   - P1: 5 tests (high priority)
-   - P2: 1 test (medium priority)
-
-   **Test Levels:**
-   - E2E: 2 tests (user journeys)
-   - API: 3 tests (business logic)
-   - Component: 2 tests (UI behavior)
-
-   **Coverage Status:**
-   - ✅ All acceptance criteria covered
-   - ✅ Happy path covered (E2E + API)
-   - ✅ Error cases covered (API)
-   - ✅ UI validation covered (Component)
-   - ⚠️ Edge case: Password reset flow not yet covered (future story)
-
-   ## Definition of Done
-   - [x] All tests follow Given-When-Then format
-   - [x] All tests use data-testid selectors
-   - [x] All tests have priority tags
-   - [x] All tests are self-cleaning (fixtures with auto-cleanup)
-   - [x] No hard waits or flaky patterns
-   - [x] Test files under 300 lines
-   - [x] All tests run under 1.5 minutes each
-   - [x] README updated with test execution instructions
-   - [x] package.json scripts updated
-
-   ## Next Steps
-   1. Review generated tests with team
-   2. Run tests in CI pipeline: `npm run test:e2e`
-   3. Integrate with quality gate: `bmad tea *gate`
-   4. Monitor for flaky tests in burn-in loop
-
-   ````
-
-   **Standalone Mode:**
-   ```markdown
-   # Automation Summary - {target_feature}
-
-   **Date:** {date}
-   **Target:** {target_feature} (standalone analysis)
-   **Coverage Target:** {coverage_target}
-
-   ## Feature Analysis
-
-   **Source Files Analyzed:**
-   - `src/auth/login.ts` - Login logic and validation
-   - `src/auth/session.ts` - Session management
-   - `src/auth/validation.ts` - Email/password validation
-
-   **Existing Coverage:**
-   - E2E tests: 0 found
-   - API tests: 0 found
-   - Component tests: 0 found
-   - Unit tests: 0 found
-
-   **Coverage Gaps Identified:**
-   - ❌ No E2E tests for login flow
-   - ❌ No API tests for /auth/login endpoint
-   - ❌ No component tests for LoginForm
-   - ❌ No unit tests for validateEmail()
-
-   ## Tests Created
-
-   {Same structure as BMad-Integrated Mode}
-
-   ## Recommendations
-
-   1. **High Priority (P0-P1):**
-      - Add E2E test for password reset flow
-      - Add API tests for token refresh endpoint
-      - Add component tests for logout button
-
-   2. **Medium Priority (P2):**
-      - Add unit tests for session timeout logic
-      - Add E2E test for "remember me" functionality
-
-   3. **Future Enhancements:**
-      - Consider contract testing for auth API
-      - Add visual regression tests for login page
-      - Set up burn-in loop for flaky test detection
-
-   ## Definition of Done
-
-   {Same checklist as BMad-Integrated Mode}
-   ````
-
-2. **Provide Summary to User**
-
-   Output concise summary:
-
-   ```markdown
-   ## Automation Complete
-
-   **Coverage:** {total_tests} tests created across {test_levels} levels
-   **Priority Breakdown:** P0: {p0_count}, P1: {p1_count}, P2: {p2_count}, P3: {p3_count}
-   **Infrastructure:** {fixture_count} fixtures, {factory_count} factories
-   **Output:** {output_summary}
-
-   **Run tests:** `npm run test:e2e`
-   **Next steps:** Review tests, run in CI, integrate with quality gate
-   ```
-
----
-
-## Important Notes
-
-### Dual-Mode Operation
-
-**BMad-Integrated Mode** (story available):
-
-- Uses story acceptance criteria for coverage targeting
-- Aligns with test-design risk/priority assessment
-- Expands ATDD tests with edge cases and negative paths
-- Updates BMad status tracking
-
-**Standalone Mode** (no story):
-
-- Analyzes source code independently
-- Identifies coverage gaps automatically
-- Generates tests based on code analysis
-- Works with any project (BMad or non-BMad)
-
-**Auto-discover Mode** (no targets specified):
-
-- Scans codebase for features needing tests
-- Prioritizes features with no coverage
-- Generates comprehensive test plan
-
-### Avoid Duplicate Coverage
-
-**Critical principle:** Don't test same behavior at multiple levels
-
-**Good coverage:**
-
-- E2E: User can login → Dashboard loads (critical happy path)
-- API: POST /auth/login returns correct status codes (variations)
-- Component: LoginForm validates input (UI edge cases)
-
-**Bad coverage (duplicate):**
-
-- E2E: User can login → Dashboard loads
-- E2E: User can login with different emails → Dashboard loads (unnecessary duplication)
-- API: POST /auth/login returns 200 (already covered in E2E)
-
-Use E2E sparingly for critical paths. Use API/Component for variations and edge cases.
-
-### Priority Tagging
-
-**Tag every test with priority in test name:**
-
-```typescript
-test('[P0] should login with valid credentials', async ({ page }) => { ... });
-test('[P1] should display error for invalid credentials', async ({ page }) => { ... });
-test('[P2] should remember login preference', async ({ page }) => { ... });
-```
-
-**Enables selective test execution:**
-
-```bash
-# Run only P0 tests (critical paths)
-npm run test:e2e -- --grep "@P0"
-
-# Run P0 + P1 tests (pre-merge)
-npm run test:e2e -- --grep "@P0|@P1"
-```
-
-### No Page Objects
-
-**Do NOT create page object classes.** Keep tests simple and direct:
-
-```typescript
-// ✅ CORRECT: Direct test
-test('should login', async ({ page }) => {
-  await page.goto('/login');
-  await page.fill('[data-testid="email"]', 'user@example.com');
-  await page.click('[data-testid="login-button"]');
-  await expect(page).toHaveURL('/dashboard');
-});
-
-// ❌ WRONG: Page object abstraction
-class LoginPage {
-  async login(email, password) { ... }
-}
-```
-
-Use fixtures for setup/teardown, not page objects for actions.
-
-### Deterministic Tests Only
-
-**No flaky patterns allowed:**
-
-```typescript
-// ❌ WRONG: Hard wait
-await page.waitForTimeout(2000);
-
-// ✅ CORRECT: Explicit wait
-await page.waitForSelector('[data-testid="user-name"]');
-await expect(page.locator('[data-testid="user-name"]')).toBeVisible();
-
-// ❌ WRONG: Conditional flow
-if (await element.isVisible()) {
-  await element.click();
-}
-
-// ✅ CORRECT: Deterministic assertion
-await expect(element).toBeVisible();
-await element.click();
-
-// ❌ WRONG: Try-catch for test logic
-try {
-  await element.click();
-} catch (e) {
-  // Test shouldn't catch errors
-}
-
-// ✅ CORRECT: Let test fail if element not found
-await element.click();
-```
-
-### Self-Cleaning Tests
-
-**Every test must clean up its data:**
-
-```typescript
-// ✅ CORRECT: Fixture with auto-cleanup
-export const test = base.extend({
-  testUser: async ({ page }, use) => {
-    const user = await createUser();
-    await use(user);
-    await deleteUser(user.id); // Auto-cleanup
-  },
-});
-
-// ❌ WRONG: Manual cleanup (can be forgotten)
-test('should login', async ({ page }) => {
-  const user = await createUser();
-  // ... test logic ...
-  // Forgot to delete user!
-});
-```
-
-### File Size Limits
-
-**Keep test files lean (under {max_file_lines} lines):**
-
-- If file exceeds limit, split into multiple files by feature area
-- Group related tests in describe blocks
-- Extract common setup to fixtures
-
-### Knowledge Base Integration
-
-**Core Fragments (Auto-loaded in Step 1):**
-
-- `test-levels-framework.md` - E2E vs API vs Component vs Unit decision framework with characteristics matrix (467 lines, 4 examples)
-- `test-priorities-matrix.md` - P0-P3 classification with automated scoring and risk mapping (389 lines, 2 examples)
-- `fixture-architecture.md` - Pure function → fixture → mergeTests composition with auto-cleanup (406 lines, 5 examples)
-- `data-factories.md` - Factory patterns with faker: overrides, nested factories, API seeding (498 lines, 5 examples)
-- `selective-testing.md` - Tag-based, spec filters, diff-based selection, promotion rules (727 lines, 4 examples)
-- `ci-burn-in.md` - 10-iteration burn-in loop, parallel sharding, selective execution (678 lines, 4 examples)
-- `test-quality.md` - Deterministic tests, isolated with cleanup, explicit assertions, length/time optimization (658 lines, 5 examples)
-- `network-first.md` - Intercept before navigate, HAR capture, deterministic waiting strategies (489 lines, 5 examples)
-
-**Healing Fragments (Auto-loaded if `{auto_heal_failures}` enabled):**
-
-- `test-healing-patterns.md` - Common failure patterns: stale selectors, race conditions, dynamic data, network errors, hard waits (648 lines, 5 examples)
-- `selector-resilience.md` - Selector hierarchy (data-testid > ARIA > text > CSS), dynamic patterns, anti-patterns refactoring (541 lines, 4 examples)
-- `timing-debugging.md` - Race condition prevention, deterministic waiting, async debugging techniques (370 lines, 3 examples)
-
-**Manual Reference (Optional):**
-
-- Use `tea-index.csv` to find additional specialized fragments as needed
-
----
-
-## Output Summary
-
-After completing this workflow, provide a summary:
-
-````markdown
-## Automation Complete
-
-**Mode:** {standalone_mode ? "Standalone" : "BMad-Integrated"}
-**Target:** {story_id || target_feature || "Auto-discovered features"}
-
-**Tests Created:**
-
-- E2E: {e2e_count} tests ({p0_count} P0, {p1_count} P1, {p2_count} P2)
-- API: {api_count} tests ({p0_count} P0, {p1_count} P1, {p2_count} P2)
-- Component: {component_count} tests ({p1_count} P1, {p2_count} P2)
-- Unit: {unit_count} tests ({p2_count} P2, {p3_count} P3)
-
-**Infrastructure:**
-
-- Fixtures: {fixture_count} created/enhanced
-- Factories: {factory_count} created/enhanced
-- Helpers: {helper_count} created/enhanced
-
-**Documentation Updated:**
-
-- ✅ Test README with execution instructions
-- ✅ package.json scripts for test execution
-
-**Test Execution:**
-
-```bash
-# Run all tests
-npm run test:e2e
-
-# Run by priority
-npm run test:e2e:p0  # Critical paths only
-npm run test:e2e:p1  # P0 + P1 tests
-
-# Run specific file
-npm run test:e2e -- {first_test_file}
-```
-````
-
-**Coverage Status:**
-
-- ✅ {coverage_percentage}% of features covered
-- ✅ All P0 scenarios covered
-- ✅ All P1 scenarios covered
-- ⚠️ {gap_count} coverage gaps identified (documented in summary)
-
-**Quality Checks:**
-
-- ✅ All tests follow Given-When-Then format
-- ✅ All tests have priority tags
-- ✅ All tests use data-testid selectors
-- ✅ All tests are self-cleaning
-- ✅ No hard waits or flaky patterns
-- ✅ All test files under {max_file_lines} lines
-
-**Output File:** {output_summary}
-
-**Next Steps:**
-
-1. Review generated tests with team
-2. Run tests in CI pipeline
-3. Monitor for flaky tests in burn-in loop
-4. Integrate with quality gate: `bmad tea *gate`
-
-**Knowledge Base References Applied:**
-
-- Test level selection framework (E2E vs API vs Component vs Unit)
-- Priority classification (P0-P3)
-- Fixture architecture patterns with auto-cleanup
-- Data factory patterns using faker
-- Selective testing strategies
-- Test quality principles
-
-```
-
----
-
-## Validation
-
-After completing all steps, verify:
-
-- [ ] Execution mode determined (BMad-Integrated, Standalone, or Auto-discover)
-- [ ] BMad artifacts loaded if available (story, tech-spec, test-design, PRD)
-- [ ] Framework configuration loaded
-- [ ] Existing test coverage analyzed (gaps identified)
-- [ ] Knowledge base fragments loaded (test-levels, test-priorities, fixture-architecture, data-factories, selective-testing)
-- [ ] Automation targets identified (what needs testing)
-- [ ] Test levels selected appropriately (E2E, API, Component, Unit)
-- [ ] Duplicate coverage avoided (same behavior not tested at multiple levels)
-- [ ] Test priorities assigned (P0, P1, P2, P3)
-- [ ] Fixture architecture created/enhanced (with auto-cleanup)
-- [ ] Data factories created/enhanced (using faker)
-- [ ] Helper utilities created/enhanced (if needed)
-- [ ] E2E tests written (Given-When-Then, priority tags, data-testid selectors)
-- [ ] API tests written (Given-When-Then, priority tags, comprehensive coverage)
-- [ ] Component tests written (Given-When-Then, priority tags, UI behavior)
-- [ ] Unit tests written (Given-When-Then, priority tags, pure logic)
-- [ ] Network-first pattern applied (route interception before navigation)
-- [ ] Quality standards enforced (no hard waits, no flaky patterns, self-cleaning, deterministic)
-- [ ] Test README updated (execution instructions, priority tagging, patterns)
-- [ ] package.json scripts updated (test execution commands)
-- [ ] Test suite run locally (results captured)
-- [ ] Tests validated (if auto_validate enabled)
-- [ ] Failures healed (if auto_heal_failures enabled)
-- [ ] Healing report generated (if healing attempted)
-- [ ] Unfixable tests marked with test.fixme() (if any)
-- [ ] Automation summary created (tests, infrastructure, coverage, healing, DoD)
-- [ ] Output file formatted correctly
-
-Refer to `checklist.md` for comprehensive validation criteria.
-```

_bmad/bmm/workflows/testarch/automate/workflow.yaml

@@ -1,52 +0,0 @@
-# Test Architect workflow: automate
-name: testarch-automate
-description: "Expand test automation coverage after implementation or analyze existing codebase to generate comprehensive test suite"
-author: "BMad"
-
-# Critical variables from config
-config_source: "{project-root}/_bmad/bmm/config.yaml"
-output_folder: "{config_source}:output_folder"
-user_name: "{config_source}:user_name"
-communication_language: "{config_source}:communication_language"
-document_output_language: "{config_source}:document_output_language"
-date: system-generated
-
-# Workflow components
-installed_path: "{project-root}/_bmad/bmm/workflows/testarch/automate"
-instructions: "{installed_path}/instructions.md"
-validation: "{installed_path}/checklist.md"
-template: false
-
-# Variables and inputs
-variables:
-  # Execution mode and targeting
-  standalone_mode: true # Can work without BMad artifacts (true) or integrate with BMad (false)
-  coverage_target: "critical-paths" # critical-paths, comprehensive, selective
-
-  # Directory paths
-  test_dir: "{project-root}/tests" # Root test directory
-  source_dir: "{project-root}/src" # Source code directory
-
-# Output configuration
-default_output_file: "{output_folder}/automation-summary.md"
-
-# Required tools
-required_tools:
-  - read_file # Read source code, existing tests, BMad artifacts
-  - write_file # Create test files, fixtures, factories, summaries
-  - create_directory # Create test directories
-  - list_files # Discover features and existing tests
-  - search_repo # Find coverage gaps and patterns
-  - glob # Find test files and source files
-
-tags:
-  - qa
-  - automation
-  - test-architect
-  - regression
-  - coverage
-
-execution_hints:
-  interactive: false # Minimize prompts
-  autonomous: true # Proceed without user input unless blocked
-  iterative: true

_bmad/bmm/workflows/testarch/ci/checklist.md

@@ -1,248 +0,0 @@
-# CI/CD Pipeline Setup - Validation Checklist
-
-## Prerequisites
-
-- [ ] Git repository initialized (`.git/` exists)
-- [ ] Git remote configured (`git remote -v` shows origin)
-- [ ] Test framework configured (`playwright.config._` or `cypress.config._`)
-- [ ] Local tests pass (`npm run test:e2e` succeeds)
-- [ ] Team agrees on CI platform
-- [ ] Access to CI platform settings (if updating)
-
-Note: CI setup is typically a one-time task per repo and can be run any time after the test framework is configured.
-
-## Process Steps
-
-### Step 1: Preflight Checks
-
-- [ ] Git repository validated
-- [ ] Framework configuration detected
-- [ ] Local test execution successful
-- [ ] CI platform detected or selected
-- [ ] Node version identified (.nvmrc or default)
-- [ ] No blocking issues found
-
-### Step 2: CI Pipeline Configuration
-
-- [ ] CI configuration file created (`.github/workflows/test.yml` or `.gitlab-ci.yml`)
-- [ ] File is syntactically valid (no YAML errors)
-- [ ] Correct framework commands configured
-- [ ] Node version matches project
-- [ ] Test directory paths correct
-
-### Step 3: Parallel Sharding
-
-- [ ] Matrix strategy configured (4 shards default)
-- [ ] Shard syntax correct for framework
-- [ ] fail-fast set to false
-- [ ] Shard count appropriate for test suite size
-
-### Step 4: Burn-In Loop
-
-- [ ] Burn-in job created
-- [ ] 10 iterations configured
-- [ ] Proper exit on failure (`|| exit 1`)
-- [ ] Runs on appropriate triggers (PR, cron)
-- [ ] Failure artifacts uploaded
-
-### Step 5: Caching Configuration
-
-- [ ] Dependency cache configured (npm/yarn)
-- [ ] Cache key uses lockfile hash
-- [ ] Browser cache configured (Playwright/Cypress)
-- [ ] Restore-keys defined for fallback
-- [ ] Cache paths correct for platform
-
-### Step 6: Artifact Collection
-
-- [ ] Artifacts upload on failure only
-- [ ] Correct artifact paths (test-results/, traces/, etc.)
-- [ ] Retention days set (30 default)
-- [ ] Artifact names unique per shard
-- [ ] No sensitive data in artifacts
-
-### Step 7: Retry Logic
-
-- [ ] Retry action/strategy configured
-- [ ] Max attempts: 2-3
-- [ ] Timeout appropriate (30 min)
-- [ ] Retry only on transient errors
-
-### Step 8: Helper Scripts
-
-- [ ] `scripts/test-changed.sh` created
-- [ ] `scripts/ci-local.sh` created
-- [ ] `scripts/burn-in.sh` created (optional)
-- [ ] Scripts are executable (`chmod +x`)
-- [ ] Scripts use correct test commands
-- [ ] Shebang present (`#!/bin/bash`)
-
-### Step 9: Documentation
-
-- [ ] `docs/ci.md` created with pipeline guide
-- [ ] `docs/ci-secrets-checklist.md` created
-- [ ] Required secrets documented
-- [ ] Setup instructions clear
-- [ ] Troubleshooting section included
-- [ ] Badge URLs provided (optional)
-
-## Output Validation
-
-### Configuration Validation
-
-- [ ] CI file loads without errors
-- [ ] All paths resolve correctly
-- [ ] No hardcoded values (use env vars)
-- [ ] Triggers configured (push, pull_request, schedule)
-- [ ] Platform-specific syntax correct
-
-### Execution Validation
-
-- [ ] First CI run triggered (push to remote)
-- [ ] Pipeline starts without errors
-- [ ] All jobs appear in CI dashboard
-- [ ] Caching works (check logs for cache hit)
-- [ ] Tests execute in parallel
-- [ ] Artifacts collected on failure
-
-### Performance Validation
-
-- [ ] Lint stage: <2 minutes
-- [ ] Test stage (per shard): <10 minutes
-- [ ] Burn-in stage: <30 minutes
-- [ ] Total pipeline: <45 minutes
-- [ ] Cache reduces install time by 2-5 minutes
-
-## Quality Checks
-
-### Best Practices Compliance
-
-- [ ] Burn-in loop follows production patterns
-- [ ] Parallel sharding configured optimally
-- [ ] Failure-only artifact collection
-- [ ] Selective testing enabled (optional)
-- [ ] Retry logic handles transient failures only
-- [ ] No secrets in configuration files
-
-### Knowledge Base Alignment
-
-- [ ] Burn-in pattern matches `ci-burn-in.md`
-- [ ] Selective testing matches `selective-testing.md`
-- [ ] Artifact collection matches `visual-debugging.md`
-- [ ] Test quality matches `test-quality.md`
-
-### Security Checks
-
-- [ ] No credentials in CI configuration
-- [ ] Secrets use platform secret management
-- [ ] Environment variables for sensitive data
-- [ ] Artifact retention appropriate (not too long)
-- [ ] No debug output exposing secrets
-
-## Integration Points
-
-### Status File Integration
-
-- [ ] `bmm-workflow-status.md` exists
-- [ ] CI setup logged in Quality & Testing Progress section
-- [ ] Status updated with completion timestamp
-- [ ] Platform and configuration noted
-
-### Knowledge Base Integration
-
-- [ ] Relevant knowledge fragments loaded
-- [ ] Patterns applied from knowledge base
-- [ ] Documentation references knowledge base
-- [ ] Knowledge base references in README
-
-### Workflow Dependencies
-
-- [ ] `framework` workflow completed first
-- [ ] Can proceed to `atdd` workflow after CI setup
-- [ ] Can proceed to `automate` workflow
-- [ ] CI integrates with `gate` workflow
-
-## Completion Criteria
-
-**All must be true:**
-
-- [ ] All prerequisites met
-- [ ] All process steps completed
-- [ ] All output validations passed
-- [ ] All quality checks passed
-- [ ] All integration points verified
-- [ ] First CI run successful
-- [ ] Performance targets met
-- [ ] Documentation complete
-
-## Post-Workflow Actions
-
-**User must complete:**
-
-1. [ ] Commit CI configuration
-2. [ ] Push to remote repository
-3. [ ] Configure required secrets in CI platform
-4. [ ] Open PR to trigger first CI run
-5. [ ] Monitor and verify pipeline execution
-6. [ ] Adjust parallelism if needed (based on actual run times)
-7. [ ] Set up notifications (optional)
-
-**Recommended next workflows:**
-
-1. [ ] Run `atdd` workflow for test generation
-2. [ ] Run `automate` workflow for coverage expansion
-3. [ ] Run `gate` workflow for quality gates
-
-## Rollback Procedure
-
-If workflow fails:
-
-1. [ ] Delete CI configuration file
-2. [ ] Remove helper scripts directory
-3. [ ] Remove documentation (docs/ci.md, etc.)
-4. [ ] Clear CI platform secrets (if added)
-5. [ ] Review error logs
-6. [ ] Fix issues and retry workflow
-
-## Notes
-
-### Common Issues
-
-**Issue**: CI file syntax errors
-
-- **Solution**: Validate YAML syntax online or with linter
-
-**Issue**: Tests fail in CI but pass locally
-
-- **Solution**: Use `scripts/ci-local.sh` to mirror CI environment
-
-**Issue**: Caching not working
-
-- **Solution**: Check cache key formula, verify paths
-
-**Issue**: Burn-in too slow
-
-- **Solution**: Reduce iterations or run on cron only
-
-### Platform-Specific
-
-**GitHub Actions:**
-
-- Secrets: Repository Settings → Secrets and variables → Actions
-- Runners: Ubuntu latest recommended
-- Concurrency limits: 20 jobs for free tier
-
-**GitLab CI:**
-
-- Variables: Project Settings → CI/CD → Variables
-- Runners: Shared or project-specific
-- Pipeline quota: 400 minutes/month free tier
-
----
-
-**Checklist Complete**: Sign off when all items validated.
-
-**Completed by:** {name}
-**Date:** {date}
-**Platform:** {GitHub Actions, GitLab CI, Other}
-**Notes:** {notes}

_bmad/bmm/workflows/testarch/ci/github-actions-template.yaml

@@ -1,198 +0,0 @@
-# GitHub Actions CI/CD Pipeline for Test Execution
-# Generated by BMad TEA Agent - Test Architect Module
-# Optimized for: Playwright/Cypress, Parallel Sharding, Burn-In Loop
-
-name: Test Pipeline
-
-on:
-  push:
-    branches: [main, develop]
-  pull_request:
-    branches: [main, develop]
-  schedule:
-    # Weekly burn-in on Sundays at 2 AM UTC
-    - cron: "0 2 * * 0"
-
-concurrency:
-  group: ${{ github.workflow }}-${{ github.ref }}
-  cancel-in-progress: true
-
-jobs:
-  # Lint stage - Code quality checks
-  lint:
-    name: Lint
-    runs-on: ubuntu-latest
-    timeout-minutes: 5
-
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Determine Node version
-        id: node-version
-        run: |
-          if [ -f .nvmrc ]; then
-            echo "value=$(cat .nvmrc)" >> "$GITHUB_OUTPUT"
-            echo "Using Node from .nvmrc"
-          else
-            echo "value=24" >> "$GITHUB_OUTPUT"
-            echo "Using default Node 24 (current LTS)"
-          fi
-
-      - name: Setup Node.js
-        uses: actions/setup-node@v4
-        with:
-          node-version: ${{ steps.node-version.outputs.value }}
-          cache: "npm"
-
-      - name: Install dependencies
-        run: npm ci
-
-      - name: Run linter
-        run: npm run lint
-
-  # Test stage - Parallel execution with sharding
-  test:
-    name: Test (Shard ${{ matrix.shard }})
-    runs-on: ubuntu-latest
-    timeout-minutes: 30
-    needs: lint
-
-    strategy:
-      fail-fast: false
-      matrix:
-        shard: [1, 2, 3, 4]
-
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Determine Node version
-        id: node-version
-        run: |
-          if [ -f .nvmrc ]; then
-            echo "value=$(cat .nvmrc)" >> "$GITHUB_OUTPUT"
-            echo "Using Node from .nvmrc"
-          else
-            echo "value=22" >> "$GITHUB_OUTPUT"
-            echo "Using default Node 22 (current LTS)"
-          fi
-
-      - name: Setup Node.js
-        uses: actions/setup-node@v4
-        with:
-          node-version: ${{ steps.node-version.outputs.value }}
-          cache: "npm"
-
-      - name: Cache Playwright browsers
-        uses: actions/cache@v4
-        with:
-          path: ~/.cache/ms-playwright
-          key: ${{ runner.os }}-playwright-${{ hashFiles('**/package-lock.json') }}
-          restore-keys: |
-            ${{ runner.os }}-playwright-
-
-      - name: Install dependencies
-        run: npm ci
-
-      - name: Install Playwright browsers
-        run: npx playwright install --with-deps chromium
-
-      - name: Run tests (shard ${{ matrix.shard }}/4)
-        run: npm run test:e2e -- --shard=${{ matrix.shard }}/4
-
-      - name: Upload test results
-        if: failure()
-        uses: actions/upload-artifact@v4
-        with:
-          name: test-results-${{ matrix.shard }}
-          path: |
-            test-results/
-            playwright-report/
-          retention-days: 30
-
-  # Burn-in stage - Flaky test detection
-  burn-in:
-    name: Burn-In (Flaky Detection)
-    runs-on: ubuntu-latest
-    timeout-minutes: 60
-    needs: test
-    # Only run burn-in on PRs to main/develop or on schedule
-    if: github.event_name == 'pull_request' || github.event_name == 'schedule'
-
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Determine Node version
-        id: node-version
-        run: |
-          if [ -f .nvmrc ]; then
-            echo "value=$(cat .nvmrc)" >> "$GITHUB_OUTPUT"
-            echo "Using Node from .nvmrc"
-          else
-            echo "value=22" >> "$GITHUB_OUTPUT"
-            echo "Using default Node 22 (current LTS)"
-          fi
-
-      - name: Setup Node.js
-        uses: actions/setup-node@v4
-        with:
-          node-version: ${{ steps.node-version.outputs.value }}
-          cache: "npm"
-
-      - name: Cache Playwright browsers
-        uses: actions/cache@v4
-        with:
-          path: ~/.cache/ms-playwright
-          key: ${{ runner.os }}-playwright-${{ hashFiles('**/package-lock.json') }}
-
-      - name: Install dependencies
-        run: npm ci
-
-      - name: Install Playwright browsers
-        run: npx playwright install --with-deps chromium
-
-      - name: Run burn-in loop (10 iterations)
-        run: |
-          echo "🔥 Starting burn-in loop - detecting flaky tests"
-          for i in {1..10}; do
-            echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
-            echo "🔥 Burn-in iteration $i/10"
-            echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
-            npm run test:e2e || exit 1
-          done
-          echo "✅ Burn-in complete - no flaky tests detected"
-
-      - name: Upload burn-in failure artifacts
-        if: failure()
-        uses: actions/upload-artifact@v4
-        with:
-          name: burn-in-failures
-          path: |
-            test-results/
-            playwright-report/
-          retention-days: 30
-
-  # Report stage - Aggregate and publish results
-  report:
-    name: Test Report
-    runs-on: ubuntu-latest
-    needs: [test, burn-in]
-    if: always()
-
-    steps:
-      - name: Download all artifacts
-        uses: actions/download-artifact@v4
-        with:
-          path: artifacts
-
-      - name: Generate summary
-        run: |
-          echo "## Test Execution Summary" >> $GITHUB_STEP_SUMMARY
-          echo "" >> $GITHUB_STEP_SUMMARY
-          echo "- **Status**: ${{ needs.test.result }}" >> $GITHUB_STEP_SUMMARY
-          echo "- **Burn-in**: ${{ needs.burn-in.result }}" >> $GITHUB_STEP_SUMMARY
-          echo "- **Shards**: 4" >> $GITHUB_STEP_SUMMARY
-          echo "" >> $GITHUB_STEP_SUMMARY
-
-          if [ "${{ needs.burn-in.result }}" == "failure" ]; then
-            echo "⚠️ **Flaky tests detected** - Review burn-in artifacts" >> $GITHUB_STEP_SUMMARY
-          fi

_bmad/bmm/workflows/testarch/ci/gitlab-ci-template.yaml

@@ -1,149 +0,0 @@
-# GitLab CI/CD Pipeline for Test Execution
-# Generated by BMad TEA Agent - Test Architect Module
-# Optimized for: Playwright/Cypress, Parallel Sharding, Burn-In Loop
-
-stages:
-  - lint
-  - test
-  - burn-in
-  - report
-
-variables:
-  # Disable git depth for accurate change detection
-  GIT_DEPTH: 0
-  # Use npm ci for faster, deterministic installs
-  npm_config_cache: "$CI_PROJECT_DIR/.npm"
-  # Playwright browser cache
-  PLAYWRIGHT_BROWSERS_PATH: "$CI_PROJECT_DIR/.cache/ms-playwright"
-  # Default Node version when .nvmrc is missing
-  DEFAULT_NODE_VERSION: "24"
-
-# Caching configuration
-cache:
-  key:
-    files:
-      - package-lock.json
-  paths:
-    - .npm/
-    - .cache/ms-playwright/
-    - node_modules/
-
-# Lint stage - Code quality checks
-lint:
-  stage: lint
-  image: node:$DEFAULT_NODE_VERSION
-  before_script:
-    - |
-      NODE_VERSION=$(cat .nvmrc 2>/dev/null || echo "$DEFAULT_NODE_VERSION")
-      echo "Using Node $NODE_VERSION"
-      npm install -g n
-      n "$NODE_VERSION"
-      node -v
-    - npm ci
-  script:
-    - npm run lint
-  timeout: 5 minutes
-
-# Test stage - Parallel execution with sharding
-.test-template: &test-template
-  stage: test
-  image: node:$DEFAULT_NODE_VERSION
-  needs:
-    - lint
-  before_script:
-    - |
-      NODE_VERSION=$(cat .nvmrc 2>/dev/null || echo "$DEFAULT_NODE_VERSION")
-      echo "Using Node $NODE_VERSION"
-      npm install -g n
-      n "$NODE_VERSION"
-      node -v
-    - npm ci
-    - npx playwright install --with-deps chromium
-  artifacts:
-    when: on_failure
-    paths:
-      - test-results/
-      - playwright-report/
-    expire_in: 30 days
-  timeout: 30 minutes
-
-test:shard-1:
-  <<: *test-template
-  script:
-    - npm run test:e2e -- --shard=1/4
-
-test:shard-2:
-  <<: *test-template
-  script:
-    - npm run test:e2e -- --shard=2/4
-
-test:shard-3:
-  <<: *test-template
-  script:
-    - npm run test:e2e -- --shard=3/4
-
-test:shard-4:
-  <<: *test-template
-  script:
-    - npm run test:e2e -- --shard=4/4
-
-# Burn-in stage - Flaky test detection
-burn-in:
-  stage: burn-in
-  image: node:$DEFAULT_NODE_VERSION
-  needs:
-    - test:shard-1
-    - test:shard-2
-    - test:shard-3
-    - test:shard-4
-  # Only run burn-in on merge requests to main/develop or on schedule
-  rules:
-    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
-    - if: '$CI_PIPELINE_SOURCE == "schedule"'
-  before_script:
-    - |
-      NODE_VERSION=$(cat .nvmrc 2>/dev/null || echo "$DEFAULT_NODE_VERSION")
-      echo "Using Node $NODE_VERSION"
-      npm install -g n
-      n "$NODE_VERSION"
-      node -v
-    - npm ci
-    - npx playwright install --with-deps chromium
-  script:
-    - |
-      echo "🔥 Starting burn-in loop - detecting flaky tests"
-      for i in {1..10}; do
-        echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
-        echo "🔥 Burn-in iteration $i/10"
-        echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
-        npm run test:e2e || exit 1
-      done
-      echo "✅ Burn-in complete - no flaky tests detected"
-  artifacts:
-    when: on_failure
-    paths:
-      - test-results/
-      - playwright-report/
-    expire_in: 30 days
-  timeout: 60 minutes
-
-# Report stage - Aggregate results
-report:
-  stage: report
-  image: alpine:latest
-  needs:
-    - test:shard-1
-    - test:shard-2
-    - test:shard-3
-    - test:shard-4
-    - burn-in
-  when: always
-  script:
-    - |
-      echo "## Test Execution Summary"
-      echo ""
-      echo "- Pipeline: $CI_PIPELINE_ID"
-      echo "- Shards: 4"
-      echo "- Branch: $CI_COMMIT_REF_NAME"
-      echo ""
-      echo "View detailed results in job artifacts"