Merge c5cb0c0fca into 6eb7c34752

* docs: update test-design workflow to generate two documents for system-level mode

* addressed pr comments

.github/CODEOWNERS

@@ -0,0 +1,23 @@
+# CODEOWNERS for BMAD-METHOD
+# https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
+#
+# NOTE: This file controls who gets pinged for PR reviews, not who "owns" what.
+
+# Default - Brian + reviewers team
+* @bmadcode @bmad-code-org/reviewers
+
+# ============================================
+# SPECIFIC AREAS
+# ============================================
+# Note: Specific paths override the default, so @bmadcode is included
+# on all entries below to maintain his review requirement.
+
+# Quick Flow (BMM) - Alex
+src/modules/bmm/workflows/bmad-quick-flow/ @bmadcode @alexeyv
+
+# TEA (Test Engineering Architecture) - Murat
+src/modules/bmm/docs/test-architecture.md @bmadcode @muratkeremozcan
+
+# Documentation - Alex
+docs/ @bmadcode @alexeyv
+website/ @bmadcode @alexeyv

docs/explanation/features/tea-overview.md

@@ -160,7 +160,7 @@ graph TB
 
 **TEA workflows:** `*framework` and `*ci` run once in Phase 3 after architecture. `*test-design` is **dual-mode**:
 
-- **System-level (Phase 3):** Run immediately after architecture/ADR drafting to produce `test-design-system.md` (testability review, ADR → test mapping, Architecturally Significant Requirements (ASRs), environment needs). Feeds the implementation-readiness gate.
+- **System-level (Phase 3):** Run immediately after architecture/ADR drafting to produce TWO documents: `test-design-architecture.md` (for Architecture/Dev teams: testability gaps, ASRs, NFR requirements) + `test-design-qa.md` (for QA team: test execution recipe, coverage plan, Sprint 0 setup). Feeds the implementation-readiness gate.
 - **Epic-level (Phase 4):** Run per-epic to produce `test-design-epic-N.md` (risk, priorities, coverage plan).
 
 The Quick Flow track skips Phases 1 and 3.

docs/how-to/brownfield/use-tea-for-enterprise.md

@@ -114,10 +114,9 @@ Focus areas:
 - Performance requirements (SLA: P99 <200ms)
 - Compliance (HIPAA PHI handling, audit logging)
 
-Output: test-design-system.md with:
-- Security testing strategy
-- Compliance requirement → test mapping
-- Performance testing plan
+Output: TWO documents (system-level):
+- `test-design-architecture.md`: Security gaps, compliance requirements, performance SLOs for Architecture team
+- `test-design-qa.md`: Security testing strategy, compliance test mapping, performance testing plan for QA team
 - Audit logging validation
 ```
 

docs/how-to/workflows/run-test-design.md

@@ -55,20 +55,44 @@ For epic-level:
 
 ### 5. Review the Output
 
-TEA generates a comprehensive test design document.
+TEA generates test design document(s) based on mode.
 
 ## What You Get
 
-**System-Level Output (`test-design-system.md`):**
-- Testability review of architecture
-- ADR → test mapping
-- Architecturally Significant Requirements (ASRs)
-- Environment needs
-- Test infrastructure recommendations
+**System-Level Output (TWO Documents):**
 
-**Epic-Level Output (`test-design-epic-N.md`):**
+TEA produces two focused documents for system-level mode:
+
+1. **`test-design-architecture.md`** (for Architecture/Dev teams)
+   - Purpose: Architectural concerns, testability gaps, NFR requirements
+   - Quick Guide with 🚨 BLOCKERS / ⚠️ HIGH PRIORITY / 📋 INFO ONLY
+   - Risk assessment (high/medium/low-priority with scoring)
+   - Testability concerns and architectural gaps
+   - Risk mitigation plans for high-priority risks (≥6)
+   - Assumptions and dependencies
+
+2. **`test-design-qa.md`** (for QA team)
+   - Purpose: Test execution recipe, coverage plan, Sprint 0 setup
+   - Quick Reference for QA (Before You Start, Execution Order, Need Help)
+   - System architecture summary
+   - Test environment requirements (moved up - early in doc)
+   - Testability assessment (prerequisites checklist)
+   - Test levels strategy (unit/integration/E2E split)
+   - Test coverage plan (P0/P1/P2/P3 with detailed scenarios + checkboxes)
+   - Sprint 0 setup requirements (blockers, infrastructure, environments)
+   - NFR readiness summary
+
+**Why Two Documents?**
+- **Architecture teams** can scan blockers in <5 min (Quick Guide format)
+- **QA teams** have actionable test recipes (step-by-step with checklists)
+- **No redundancy** between documents (cross-references instead of duplication)
+- **Clear separation** of concerns (what to deliver vs how to test)
+
+**Epic-Level Output (ONE Document):**
+
+**`test-design-epic-N.md`** (combined risk assessment + test plan)
 - Risk assessment for the epic
-- Test priorities
+- Test priorities (P0-P3)
 - Coverage plan
 - Regression hotspots (for brownfield)
 - Integration risks
@@ -82,12 +106,25 @@ TEA generates a comprehensive test design document.
 | **Brownfield** | System-level + existing test baseline | Regression hotspots, integration risks |
 | **Enterprise** | Compliance-aware testability | Security/performance/compliance focus |
 
+## Examples
+
+**System-Level (Two Documents):**
+- `cluster-search/cluster-search-test-design-architecture.md` - Architecture doc with Quick Guide
+- `cluster-search/cluster-search-test-design-qa.md` - QA doc with test scenarios
+
+**Key Pattern:**
+- Architecture doc: "ASR-1: OAuth 2.1 required (see QA doc for 12 test scenarios)"
+- QA doc: "OAuth tests: 12 P0 scenarios (see Architecture doc R-001 for risk details)"
+- No duplication, just cross-references
+
 ## Tips
 
 - **Run system-level right after architecture** — Early testability review
 - **Run epic-level at the start of each epic** — Targeted test planning
 - **Update if ADRs change** — Keep test design aligned
 - **Use output to guide other workflows** — Feeds into `*atdd` and `*automate`
+- **Architecture teams review Architecture doc** — Focus on blockers and mitigation plans
+- **QA teams use QA doc as implementation guide** — Follow test scenarios and Sprint 0 checklist
 
 ## Next Steps
 

docs/reference/tea/commands.md

@@ -72,17 +72,39 @@ Quick reference for all 8 TEA (Test Architect) workflows. For detailed step-by-s
 **Frequency:** Once (system), per epic (epic-level)
 
 **Modes:**
-- **System-level:** Architecture testability review
-- **Epic-level:** Per-epic risk assessment
+- **System-level:** Architecture testability review (TWO documents)
+- **Epic-level:** Per-epic risk assessment (ONE document)
 
 **Key Inputs:**
-- Architecture/epic, requirements, ADRs
+- System-level: Architecture, PRD, ADRs
+- Epic-level: Epic, stories, acceptance criteria
 
 **Key Outputs:**
-- `test-design-system.md` or `test-design-epic-N.md`
+
+**System-Level (TWO Documents):**
+- `test-design-architecture.md` - For Architecture/Dev teams
+  - Quick Guide (🚨 BLOCKERS / ⚠️ HIGH PRIORITY / 📋 INFO ONLY)
+  - Risk assessment with scoring
+  - Testability concerns and gaps
+  - Mitigation plans
+- `test-design-qa.md` - For QA team
+  - Test execution recipe
+  - Coverage plan (P0/P1/P2/P3 with checkboxes)
+  - Sprint 0 setup requirements
+  - NFR readiness summary
+
+**Epic-Level (ONE Document):**
+- `test-design-epic-N.md`
   - Risk assessment (probability × impact scores)
   - Test priorities (P0-P3)
   - Coverage strategy
+  - Mitigation plans
+
+**Why Two Documents for System-Level?**
+- Architecture teams scan blockers in <5 min
+- QA teams have actionable test recipes
+- No redundancy (cross-references instead)
+- Clear separation (what to deliver vs how to test)
 
 **MCP Enhancement:** Exploratory mode (live browser UI discovery)
 

docs/reference/tea/configuration.md

@@ -197,7 +197,7 @@ output_folder: _bmad-output
 ```
 
 **TEA Output Files:**
-- `test-design-system.md` (from *test-design system-level)
+- `test-design-architecture.md` + `test-design-qa.md` (from *test-design system-level - TWO documents)
 - `test-design-epic-N.md` (from *test-design epic-level)
 - `test-review.md` (from *test-review)
 - `traceability-matrix.md` (from *trace Phase 1)

docs/tutorials/getting-started/tea-lite-quickstart.md

@@ -15,7 +15,7 @@ By the end of this 30-minute tutorial, you'll have:
 :::note[Prerequisites]
 - Node.js installed (v20 or later)
 - 30 minutes of focused time
-- We'll use TodoMVC (<https://todomvc.com/examples/react/>) as our demo app
+- We'll use TodoMVC (<https://todomvc.com/examples/react/dist/>) as our demo app
 :::
 
 :::tip[Quick Path]

src/bmm/agents/analyst.agent.yaml

@@ -16,25 +16,20 @@ agent:
     principles: |
       - Channel expert business analysis frameworks: draw upon Porter's Five Forces, SWOT analysis, root cause analysis, and competitive intelligence methodologies to uncover what others miss. 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`
 
   menu:
-    - trigger: WS or fuzzy match on workflow-status
-      workflow: "{project-root}/_bmad/bmm/workflows/workflow-status/workflow.yaml"
-      description: "[WS] Workflow Status: Initialize, Get or Update the Project Workflow"
-
     - trigger: 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"
-      description: "[BP] Project Brainstorming: Expert Guided Facilitation through a single or multiple techniques with a final report"
+      description: "[BP] Brainstorm Project: Expert Guided Facilitation through a single or multiple techniques with a final report"
 
     - trigger: RS or fuzzy match on research
       exec: "{project-root}/_bmad/bmm/workflows/1-analysis/research/workflow.md"
       description: "[RS] Research: Choose from or specify market, domain, competitive analysis, or technical research"
 
-    - trigger: PB or fuzzy match on product-brief
+    - trigger: CB or fuzzy match on product-brief
       exec: "{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brief/workflow.md"
-      description: "[PB] Product Brief: A guided experience to nail down your product idea and use it as an input to define the requirements later"
+      description: "[CB] Create Brief: A guided experience to nail down your product idea into an executive brief"
 
     - trigger: DP or fuzzy match on document-project
       workflow: "{project-root}/_bmad/bmm/workflows/document-project/workflow.yaml"

src/bmm/agents/architect.agent.yaml

@@ -17,13 +17,8 @@ agent:
       - Channel expert lean architecture wisdom: draw upon deep knowledge of distributed systems, cloud patterns, scalability trade-offs, and what actually ships successfully
       - 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`
 
   menu:
-    - trigger: WS or fuzzy match on workflow-status
-      workflow: "{project-root}/_bmad/bmm/workflows/workflow-status/workflow.yaml"
-      description: "[WS] Workflow Status: Initialize, Get or Update the Project Workflow"
-
     - trigger: CA or fuzzy match on create-architecture
       exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/workflow.md"
       description: "[CA] Create Architecture: Guided Workflow to document technical decisions to keep implementation on track"

src/bmm/agents/pm.agent.yaml

@@ -19,13 +19,8 @@ agent:
       - 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`
 
   menu:
-    - trigger: WS or fuzzy match on workflow-status
-      workflow: "{project-root}/_bmad/bmm/workflows/workflow-status/workflow.yaml"
-      description: "[WS] Workflow Status: Initialize, Get or Update the Project Workflow"
-
     - trigger: CP or fuzzy match on create-prd
       exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/workflow.md"
       description: "[CP] Create PRD: Expert led facilitation to produce your Product Requirements Document"
@@ -38,9 +33,9 @@ agent:
       exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/workflow.md"
       description: "[EP] Edit PRD: Update an existing Product Requirements Document"
 
-    - trigger: ES or fuzzy match on epics-stories
+    - trigger: CE or fuzzy match on epics-stories
       exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/create-epics-and-stories/workflow.md"
-      description: "[ES] Epics Stories: Create the Epics and Stories Listing, these are the specs that will drive development"
+      description: "[CE] Create Epics and Stories: Create the Epics and Stories Listing, these are the specs that will drive development"
 
     - trigger: IR or fuzzy match on implementation-readiness
       exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/check-implementation-readiness/workflow.md"

src/bmm/agents/sm.agent.yaml

@@ -14,21 +14,10 @@ agent:
     identity: Certified Scrum Master with deep technical background. Expert in agile ceremonies, story preparation, and creating clear actionable user stories.
     communication_style: "Crisp and checklist-driven. Every word has a purpose, every requirement crystal clear. Zero tolerance for ambiguity."
     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
-
-  critical_actions:
-    - "When running *create-story, always run as *yolo. Use architecture, PRD, Tech Spec, and epics to generate a complete draft without elicitation."
-    - "Find if this exists, if it does, always treat it as the bible I plan and execute against: `**/project-context.md`"
+      - I strive to be a servant leader and conduct myself accordingly, helping with any task and offering suggestions
+      - I love to talk about Agile process and theory whenever anyone wants to talk about it
 
   menu:
-    - trigger: WS or fuzzy match on workflow-status
-      workflow: "{project-root}/_bmad/bmm/workflows/workflow-status/workflow.yaml"
-      description: "[WS] Workflow Status: Initialize, Get or Update the Project Workflow"
-
     - trigger: SP or fuzzy match on sprint-planning
       workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/sprint-planning/workflow.yaml"
       description: "[SP] Sprint Planning: Generate or update the record that will sequence the tasks to complete the full project that the dev agent will follow"

src/bmm/agents/tea.agent.yaml

@@ -28,13 +28,8 @@ agent:
     - "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"
     - "Load the referenced fragment(s) from {project-root}/_bmad/bmm/testarch/knowledge/ before giving recommendations"
     - "Cross-check recommendations with the current official Playwright, Cypress, Pact, and CI platform documentation"
-    - "Find if this exists, if it does, always treat it as the bible I plan and execute against: `**/project-context.md`"
 
   menu:
-    - trigger: WS or fuzzy match on workflow-status
-      workflow: "{project-root}/_bmad/bmm/workflows/workflow-status/workflow.yaml"
-      description: "[WS] Workflow Status: Initialize, Get or Update the Project Workflow"
-
     - trigger: TF or fuzzy match on test-framework
       workflow: "{project-root}/_bmad/bmm/workflows/testarch/framework/workflow.yaml"
       description: "[TF] Test Framework: Initialize production-ready test framework architecture"

src/bmm/agents/tech-writer/tech-writer.agent.yaml

@@ -20,10 +20,6 @@ agent:
       - I will always strive to follow `_bmad/_memory/tech-writer-sidecar/documentation-standards.md` best practices.
 
   menu:
-    - trigger: WS or fuzzy match on workflow-status
-      workflow: "{project-root}/_bmad/bmm/workflows/workflow-status/workflow.yaml"
-      description: "[WS] Workflow Status: Initialize, Get or Update the Project Workflow"
-
     - trigger: DP or fuzzy match on document-project
       workflow: "{project-root}/_bmad/bmm/workflows/document-project/workflow.yaml"
       description: "[DP] Document Project: Generate comprehensive project documentation (brownfield analysis, architecture scanning)"

src/bmm/agents/ux-designer.agent.yaml

@@ -21,10 +21,6 @@ agent:
       - Data-informed but always creative
 
   menu:
-    - trigger: WS or fuzzy match on workflow-status
-      workflow: "{project-root}/_bmad/bmm/workflows/workflow-status/workflow.yaml"
-      description: "[WS] Workflow Status: Initialize, Get or Update the Project Workflow"
-
-    - trigger: UX or fuzzy match on ux-design
+    - trigger: CU or fuzzy match on ux-design
       exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-ux-design/workflow.md"
-      description: "[UX] UX: Guidance through realizing the plan for your UX to inform architecture and implementation. PRovides more details that what was discovered in the PRD"
+      description: "[CU] Create UX: Guidance through realizing the plan for your UX to inform architecture and implementation. PRovides more details that what was discovered in the PRD"

src/bmm/data/README.md

@@ -1,29 +0,0 @@
-# BMM Module Data
-
-This directory contains module-specific data files used by BMM agents and workflows.
-
-## Files
-
-### `project-context-template.md`
-
-Template for project-specific brainstorming context. Used by:
-
-- Analyst agent `brainstorm-project` command
-- Core brainstorming workflow when called with context
-
-### `documentation-standards.md`
-
-BMAD documentation standards and guidelines. Used by:
-
-- Tech Writer agent (critical action loading)
-- Various documentation workflows
-- Standards validation and review processes
-
-## Purpose
-
-Separates module-specific data from core workflow implementations, maintaining clean architecture:
-
-- Core workflows remain generic and reusable
-- Module-specific templates and standards are properly scoped
-- Data files can be easily maintained and updated
-- Clear separation of concerns between core and module functionality

src/bmm/data/project-context-template.md

@@ -17,24 +17,10 @@ This brainstorming session focuses on software and product development considera
 
 ### Integration with Project Workflow
 
-Brainstorming results will feed into:
+Brainstorming results might feed into:
 
 - Product Briefs for initial product vision
 - PRDs for detailed requirements
 - Technical Specifications for architecture plans
 - Research Activities for validation needs
 
-### Expected Outcomes
-
-Capture:
-
-1. Problem Statements - Clearly defined user challenges
-2. Solution Concepts - High-level approach descriptions
-3. Feature Priorities - Categorized by importance and feasibility
-4. Technical Considerations - Architecture and implementation thoughts
-5. Next Steps - Actions needed to advance concepts
-6. Integration Points - Connections to downstream workflows
-
----
-
-_Use this template to provide project-specific context for brainstorming sessions. Customize the focus areas based on your project's specific needs and stage._

src/bmm/module-help.csv

@@ -0,0 +1,33 @@
+module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,
+bmm,anytime,Document Project,DP,10,_bmad/bmm/workflows/document-project/workflow.yaml,bmad:bmm:document-project,false,analyst,Create Mode,"Analyze an existing project to produce useful documentation",project-knowledge,*,
+bmm,anytime,Tech Spec,TS,20,_bmad/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md,bmad:bmm:tech-spec,false,quick-flow-solo-dev,Create Mode,"Do not suggest for potentially very complex things unless requested or if the user complains that they do not want to follow the extensive planning of the bmad method. Quick one-off tasks small changes simple apps utilities without extensive planning",planning_artifacts,"tech spec",
+bmm,anytime,Quick Dev,QD,30,_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md,bmad:bmm:quick-dev,false,quick-flow-solo-dev,Create Mode,"Quick one-off tasks small changes simple apps utilities without extensive planning - Do not suggest for potentially very complex things unless requested or if the user complains that they do not want to follow the extensive planning of the bmad method, unless the user is already working through the implementation phase and just requests a 1 off things not already in the plan",,,
+bmm,anytime,Correct Course,CC,40,_bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml,bmad:bmm:correct-course,false,sm,Create Mode,"Anytime: Navigate significant changes. May recommend start over update PRD redo architecture sprint planning or correct epics and stories",planning_artifacts,"change proposal",
+bmm,1-analysis,Brainstorm Project,BP,10,_bmad/core/workflows/brainstorming/workflow.md,bmad:bmm:brainstorming,false,analyst,"data=_bmad/bmm/data/project-context-template.md","Expert Guided Facilitation through a single or multiple techniques",planning_artifacts,"brainstorming session",
+bmm,1-analysis,Market Research,MR,20,_bmad/bmm/workflows/1-analysis/research/workflow.md,bmad:bmm:research,false,analyst,Create Mode,"research_type=""market""","Market analysis competitive landscape customer needs and trends","planning_artifacts|project-knowledge","research documents"
+bmm,1-analysis,Domain Research,DR,21,_bmad/bmm/workflows/1-analysis/research/workflow.md,bmad:bmm:research,false,analyst,Create Mode,"research_type=""domain""","Industry domain deep dive subject matter expertise and terminology","planning_artifacts|project-knowledge","research documents"
+bmm,1-analysis,Technical Research,TR,22,_bmad/bmm/workflows/1-analysis/research/workflow.md,bmad:bmm:research,false,analyst,Create Mode,"research_type=""technical""","Technical feasibility architecture options and implementation approaches","planning_artifacts|project-knowledge","research documents"
+bmm,1-analysis,Create Brief,CB,30,_bmad/bmm/workflows/1-analysis/create-product-brief/workflow.md,bmad:bmm:create-brief,false,analyst,Create Mode,"A guided experience to nail down your product idea",planning_artifacts,"product brief",
+bmm,1-analysis,Validate Brief,VB,40,_bmad/bmm/workflows/1-analysis/create-product-brief/workflow.md,bmad:bmm:validate-brief,false,analyst,Validate Mode,"Validates product brief completeness",planning_artifacts,"brief validation report",
+bmm,2-planning,Create PRD,CP,10,_bmad/bmm/workflows/2-plan-workflows/prd/workflow.md,bmad:bmm:create-prd,true,pm,Create Mode,"Expert led facilitation to produce your Product Requirements Document",planning_artifacts,prd,
+bmm,2-planning,Validate PRD,VP,20,_bmad/bmm/workflows/2-plan-workflows/prd/workflow.md,bmad:bmm:validate-prd,false,pm,Validate Mode,"Validate PRD is comprehensive lean well organized and cohesive",planning_artifacts,"prd validation report",
+bmm,2-planning,Create UX,CU,30,_bmad/bmm/workflows/2-plan-workflows/create-ux-design/workflow.md,bmad:bmm:create-ux,false,ux-designer,Create Mode,"Guidance through realizing the plan for your UX, strongly recommended if a UI is a primary piece of the proposed project",planning_artifacts,"ux design",
+bmm,2-planning,Validate UX,VU,40,_bmad/bmm/workflows/2-plan-workflows/create-ux-design/workflow.md,bmad:bmm:validate-ux,false,ux-designer,Validate Mode,"Validates UX design deliverables",planning_artifacts,"ux validation report",
+,,Create Dataflow,CDF,50,_bmad/bmm/workflows/excalidraw-diagrams/create-dataflow/workflow.yaml,bmad:bmm:create-dataflow,false,ux-designer,Create Mode,"Create data flow diagrams (DFD) in Excalidraw format - can be called standalone or during any workflow to add visual documentation",planning_artifacts,"dataflow diagram",
+,,Create Diagram,CED,51,_bmad/bmm/workflows/excalidraw-diagrams/create-diagram/workflow.yaml,bmad:bmm:create-diagram,false,ux-designer,Create Mode,"Create system architecture diagrams ERDs UML diagrams or general technical diagrams in Excalidraw format - use anytime or call from architecture workflow to add visual documentation",planning_artifacts,"diagram",
+,,Create Flowchart,CFC,52,_bmad/bmm/workflows/excalidraw-diagrams/create-flowchart/workflow.yaml,bmad:bmm:create-flowchart,false,ux-designer,Create Mode,"Create a flowchart visualization in Excalidraw format for processes pipelines or logic flows - use anytime or during architecture to add process documentation",planning_artifacts,"flowchart",
+,,Create Wireframe,CEW,53,_bmad/bmm/workflows/excalidraw-diagrams/create-wireframe/workflow.yaml,bmad:bmm:create-wireframe,false,ux-designer,Create Mode,"Create website or app wireframes in Excalidraw format - use anytime standalone or call from UX workflow to add UI mockups",planning_artifacts,"wireframe",
+bmm,3-solutioning,Create Architecture,CA,10,_bmad/bmm/workflows/3-solutioning/create-architecture/workflow.md,bmad:bmm:create-architecture,true,architect,Create Mode,"Guided Workflow to document technical decisions",planning_artifacts,architecture,
+bmm,3-solutioning,Validate Architecture,VA,20,_bmad/bmm/workflows/3-solutioning/create-architecture/workflow.md,bmad:bmm:validate-architecture,false,architect,Validate Mode,"Validates architecture completeness",planning_artifacts,"architecture validation report",
+bmm,3-solutioning,Create Epics and Stories,CE,30,_bmad/bmm/workflows/3-solutioning/create-epics-and-stories/workflow.md,bmad:bmm:create-epics-and-stories,true,pm,Create Mode,"Create the Epics and Stories Listing",planning_artifacts,"epics and stories",
+bmm,3-solutioning,Validate Epics and Stories,VE,40,_bmad/bmm/workflows/3-solutioning/create-epics-and-stories/workflow.md,bmad:bmm:validate-epics-and-stories,false,pm,Validate Mode,"Validates epics and stories completeness",planning_artifacts,"epics validation report",
+bmm,3-solutioning,Test Design,TD,50,_bmad/bmm/workflows/testarch/test-design/workflow.yaml,bmad:bmm:test-design,false,tea,Create Mode,"Create comprehensive test scenarios ahead of development, recommended if string test compliance or assurance is needed. Very critical for distributed applications with separate front ends and backends outside of a monorepo.",planning_artifacts,"test design",
+bmm,3-solutioning,Validate Test Design,VT,60,_bmad/bmm/workflows/testarch/test-design/workflow.yaml,bmad:bmm:validate-test-design,false,tea,Validate Mode,"Validates test design coverage",planning_artifacts,"test design validation report",
+bmm,3-solutioning,Implementation Readiness,IR,70,_bmad/bmm/workflows/3-solutioning/check-implementation-readiness/workflow.md,bmad:bmm:implementation-readiness,true,architect,Validate Mode,"Ensure PRD UX Architecture and Epics Stories are aligned",planning_artifacts,"readiness report",
+bmm,4-implementation,Sprint Planning,SP,10,_bmad/bmm/workflows/4-implementation/sprint-planning/workflow.yaml,bmad:bmm:sprint-planning,true,sm,Create Mode,"Generate sprint plan for development tasks - this kicks off the implementation phase by producing a plan the implementation agents will follow in sequence for every story in the plan.",implementation_artifacts,"sprint status",
+bmm,4-implementation,Sprint Status,SS,20,_bmad/bmm/workflows/4-implementation/sprint-status/workflow.yaml,bmad:bmm:sprint-status,false,sm,Create Mode,"Anytime: Summarize sprint status and route to next workflow",,,
+bmm,4-implementation,Create Story,CS,30,_bmad/bmm/workflows/4-implementation/create-story/workflow.yaml,bmad:bmm:create-story,true,sm,Create Mode,"Story cycle start: Prepare first found story in the sprint plan that is next, or if the command is run with a specific epic and story designation with context. Once complete, then VS then DS then CR then back to DS if needed or next CS or ER",implementation_artifacts,story,
+bmm,4-implementation,Validate Story,VS,35,_bmad/bmm/workflows/4-implementation/create-story/workflow.yaml,bmad:bmm:validate-story,false,sm,Validate Mode,"Validates story readiness and completeness before development work begins",implementation_artifacts,"story validation report",
+bmm,4-implementation,Dev Story,DS,40,_bmad/bmm/workflows/4-implementation/dev-story/workflow.yaml,bmad:bmm:dev-story,true,dev,Create Mode,"Story cycle: Execute story implementation tasks and tests then CR then back to DS if fixes needed",,,
+bmm,4-implementation,Code Review,CR,50,_bmad/bmm/workflows/4-implementation/code-review/workflow.yaml,bmad:bmm:code-review,false,dev,Create Mode,"Story cycle: If issues back to DS if approved then next CS or ER if epic complete",,,
+bmm,4-implementation,Retrospective,ER,60,_bmad/bmm/workflows/4-implementation/retrospective/workflow.yaml,bmad:bmm:retrospective,false,sm,Create Mode,"Optional at epic end: Review completed work lessons learned and next epic or if major issues consider CC",implementation_artifacts,retrospective,

src/bmm/testarch/knowledge/adr-quality-readiness-checklist.md

@@ -0,0 +1,350 @@
+# ADR Quality Readiness Checklist
+
+**Purpose:** Standardized 8-category, 29-criteria framework for evaluating system testability and NFR compliance during architecture review (Phase 3) and NFR assessment.
+
+**When to Use:**
+- System-level test design (Phase 3): Identify testability gaps in architecture
+- NFR assessment workflow: Structured evaluation with evidence
+- Gate decisions: Quantifiable criteria (X/29 met = PASS/CONCERNS/FAIL)
+
+**How to Use:**
+1. For each criterion, assess status: ✅ Covered / ⚠️ Gap / ⬜ Not Assessed
+2. Document gap description if ⚠️
+3. Describe risk if criterion unmet
+4. Map to test scenarios (what tests validate this criterion)
+
+---
+
+## 1. Testability & Automation
+
+**Question:** Can we verify this effectively without manual toil?
+
+| #   | Criterion                                                                                                                                  | Risk if Unmet                                  | Typical Test Scenarios (P0-P2)                                                                          |
+| --- | ------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
+| 1.1 | **Isolation:** Can the service be tested with all downstream dependencies (DBs, APIs, Queues) mocked or stubbed?                           | Flaky tests; inability to test in isolation    | P1: Service runs with mocked DB, P1: Service runs with mocked API, P2: Integration tests with real deps |
+| 1.2 | **Headless Interaction:** Is 100% of the business logic accessible via API (REST/gRPC) to bypass the UI for testing?                       | Slow, brittle UI-based automation              | P0: All core logic callable via API, P1: No UI dependency for critical paths                            |
+| 1.3 | **State Control:** Do we have "Seeding APIs" or scripts to inject specific data states (e.g., "User with expired subscription") instantly? | Long setup times; inability to test edge cases | P0: Seed baseline data, P0: Inject edge case data states, P1: Cleanup after tests                       |
+| 1.4 | **Sample Requests:** Are there valid and invalid cURL/JSON sample requests provided in the design doc for QA to build upon?                | Ambiguity on how to consume the service        | P1: Valid request succeeds, P1: Invalid request fails with clear error                                  |
+
+**Common Gaps:**
+- No mock endpoints for external services (Athena, Milvus, third-party APIs)
+- Business logic tightly coupled to UI (requires E2E tests for everything)
+- No seeding APIs (manual database setup required)
+- ADR has architecture diagrams but no sample API requests
+
+**Mitigation Examples:**
+- 1.1 (Isolation): Provide mock endpoints, dependency injection, interface abstractions
+- 1.2 (Headless): Expose all business logic via REST/GraphQL APIs
+- 1.3 (State Control): Implement `/api/test-data` seeding endpoints (dev/staging only)
+- 1.4 (Sample Requests): Add "Example API Calls" section to ADR with cURL commands
+
+---
+
+## 2. Test Data Strategy
+
+**Question:** How do we fuel our tests safely?
+
+| #   | Criterion                                                                                                                             | Risk if Unmet                                | Typical Test Scenarios (P0-P2)                                                                 |
+| --- | ------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------------------- |
+| 2.1 | **Segregation:** Does the design support multi-tenancy or specific headers (e.g., x-test-user) to keep test data out of prod metrics? | Skewed business analytics; data pollution    | P0: Multi-tenant isolation (customer A ≠ customer B), P1: Test data excluded from prod metrics |
+| 2.2 | **Generation:** Can we use synthetic data, or do we rely on scrubbing production data (GDPR/PII risk)?                                | Privacy violations; dependency on stale data | P0: Faker-based synthetic data, P1: No production data in tests                                |
+| 2.3 | **Teardown:** Is there a mechanism to "reset" the environment or clean up data after destructive tests?                               | Environment rot; subsequent test failures    | P0: Automated cleanup after tests, P2: Environment reset script                                |
+
+**Common Gaps:**
+- No `customer_id` scoping in queries (cross-tenant data leakage risk)
+- Reliance on production data dumps (GDPR/PII violations)
+- No cleanup mechanism (tests leave data behind, polluting environment)
+
+**Mitigation Examples:**
+- 2.1 (Segregation): Enforce `customer_id` in all queries, add test-specific headers
+- 2.2 (Generation): Use Faker library, create synthetic data generators, prohibit prod dumps
+- 2.3 (Teardown): Auto-cleanup hooks in test framework, isolated test customer IDs
+
+---
+
+## 3. Scalability & Availability
+
+**Question:** Can it grow, and will it stay up?
+
+| #   | Criterion                                                                                                                   | Risk if Unmet                                     | Typical Test Scenarios (P0-P2)                                                                       |
+| --- | --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
+| 3.1 | **Statelessness:** Is the service stateless? If not, how is session state replicated across instances?                      | Inability to auto-scale horizontally              | P1: Service restart mid-request → no data loss, P2: Horizontal scaling under load                    |
+| 3.2 | **Bottlenecks:** Have we identified the weakest link (e.g., database connections, API rate limits) under load?              | System crash during peak traffic                  | P2: Load test identifies bottleneck, P2: Connection pool exhaustion handled                          |
+| 3.3 | **SLA Definitions:** What is the target Availability (e.g., 99.9%) and does the architecture support redundancy to meet it? | Breach of contract; customer churn                | P1: Availability target defined, P2: Redundancy validated (multi-region/zone)                        |
+| 3.4 | **Circuit Breakers:** If a dependency fails, does this service fail fast or hang?                                           | Cascading failures taking down the whole platform | P1: Circuit breaker opens on 5 failures, P1: Auto-reset after recovery, P2: Timeout prevents hanging |
+
+**Common Gaps:**
+- Stateful session management (can't scale horizontally)
+- No load testing, bottlenecks unknown
+- SLA undefined or unrealistic (99.99% without redundancy)
+- No circuit breakers (cascading failures)
+
+**Mitigation Examples:**
+- 3.1 (Statelessness): Externalize session to Redis/JWT, design for horizontal scaling
+- 3.2 (Bottlenecks): Load test with k6, monitor connection pools, identify weak links
+- 3.3 (SLA): Define realistic SLA (99.9% = 43 min/month downtime), add redundancy
+- 3.4 (Circuit Breakers): Implement circuit breakers (Hystrix pattern), fail fast on errors
+
+---
+
+## 4. Disaster Recovery (DR)
+
+**Question:** What happens when the worst-case scenario occurs?
+
+| #   | Criterion                                                                                                            | Risk if Unmet                                  | Typical Test Scenarios (P0-P2)                                          |
+| --- | -------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------- | ----------------------------------------------------------------------- |
+| 4.1 | **RTO/RPO:** What is the Recovery Time Objective (how long to restore) and Recovery Point Objective (max data loss)? | Extended outages; data loss liability          | P2: RTO defined and tested, P2: RPO validated (backup frequency)        |
+| 4.2 | **Failover:** Is region/zone failover automated or manual? Has it been practiced?                                    | "Heroics" required during outages; human error | P2: Automated failover works, P2: Manual failover documented and tested |
+| 4.3 | **Backups:** Are backups immutable and tested for restoration integrity?                                             | Ransomware vulnerability; corrupted backups    | P2: Backup restore succeeds, P2: Backup immutability validated          |
+
+**Common Gaps:**
+- RTO/RPO undefined (no recovery plan)
+- Failover never tested (manual process, prone to errors)
+- Backups exist but restoration never validated (untested backups = no backups)
+
+**Mitigation Examples:**
+- 4.1 (RTO/RPO): Define RTO (e.g., 4 hours) and RPO (e.g., 1 hour), document recovery procedures
+- 4.2 (Failover): Automate multi-region failover, practice failover drills quarterly
+- 4.3 (Backups): Implement immutable backups (S3 versioning), test restore monthly
+
+---
+
+## 5. Security
+
+**Question:** Is the design safe by default?
+
+| #   | Criterion                                                                                                        | Risk if Unmet                            | Typical Test Scenarios (P0-P2)                                                                                   |
+| --- | ---------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
+| 5.1 | **AuthN/AuthZ:** Does it implement standard protocols (OAuth2/OIDC)? Are permissions granular (Least Privilege)? | Unauthorized access; data leaks          | P0: OAuth flow works, P0: Expired token rejected, P0: Insufficient permissions return 403, P1: Scope enforcement |
+| 5.2 | **Encryption:** Is data encrypted at rest (DB) and in transit (TLS)?                                             | Compliance violations; data theft        | P1: Milvus data-at-rest encrypted, P1: TLS 1.2+ enforced, P2: Certificate rotation works                         |
+| 5.3 | **Secrets:** Are API keys/passwords stored in a Vault (not in code or config files)?                             | Credentials leaked in git history        | P1: No hardcoded secrets in code, P1: Secrets loaded from AWS Secrets Manager                                    |
+| 5.4 | **Input Validation:** Are inputs sanitized against Injection attacks (SQLi, XSS)?                                | System compromise via malicious payloads | P1: SQL injection sanitized, P1: XSS escaped, P2: Command injection prevented                                    |
+
+**Common Gaps:**
+- Weak authentication (no OAuth, hardcoded API keys)
+- No encryption at rest (plaintext in database)
+- Secrets in git (API keys, passwords in config files)
+- No input validation (vulnerable to SQLi, XSS, command injection)
+
+**Mitigation Examples:**
+- 5.1 (AuthN/AuthZ): Implement OAuth 2.1/OIDC, enforce least privilege, validate scopes
+- 5.2 (Encryption): Enable TDE (Transparent Data Encryption), enforce TLS 1.2+
+- 5.3 (Secrets): Migrate to AWS Secrets Manager/Vault, scan git history for leaks
+- 5.4 (Input Validation): Sanitize all inputs, use parameterized queries, escape outputs
+
+---
+
+## 6. Monitorability, Debuggability & Manageability
+
+**Question:** Can we operate and fix this in production?
+
+| #   | Criterion                                                                                            | Risk if Unmet                                      | Typical Test Scenarios (P0-P2)                                                                    |
+| --- | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
+| 6.1 | **Tracing:** Does the service propagate W3C Trace Context / Correlation IDs for distributed tracing? | Impossible to debug errors across microservices    | P2: W3C Trace Context propagated (EventBridge → Lambda → Service), P2: Correlation ID in all logs |
+| 6.2 | **Logs:** Can log levels (INFO vs DEBUG) be toggled dynamically without a redeploy?                  | Inability to diagnose issues in real-time          | P2: Log level toggle works without redeploy, P2: Logs structured (JSON format)                    |
+| 6.3 | **Metrics:** Does it expose RED metrics (Rate, Errors, Duration) for Prometheus/Datadog?             | Flying blind regarding system health               | P2: /metrics endpoint exposes RED metrics, P2: Prometheus/Datadog scrapes successfully            |
+| 6.4 | **Config:** Is configuration externalized? Can we change behavior without a code build?              | Rigid system; full deploys needed for minor tweaks | P2: Config change without code build, P2: Feature flags toggle behavior                           |
+
+**Common Gaps:**
+- No distributed tracing (can't debug across microservices)
+- Static log levels (requires redeploy to enable DEBUG)
+- No metrics endpoint (blind to system health)
+- Configuration hardcoded (requires full deploy for minor changes)
+
+**Mitigation Examples:**
+- 6.1 (Tracing): Implement W3C Trace Context, add correlation IDs to all logs
+- 6.2 (Logs): Use dynamic log levels (environment variable), structured logging (JSON)
+- 6.3 (Metrics): Expose /metrics endpoint, track RED metrics (Rate, Errors, Duration)
+- 6.4 (Config): Externalize config (AWS SSM/AppConfig), use feature flags (LaunchDarkly)
+
+---
+
+## 7. QoS (Quality of Service) & QoE (Quality of Experience)
+
+**Question:** How does it perform, and how does it feel?
+
+| #   | Criterion                                                                                            | Risk if Unmet                                          | Typical Test Scenarios (P0-P2)                                                                  |
+| --- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | ----------------------------------------------------------------------------------------------- |
+| 7.1 | **Latency (QoS):** What are the P95 and P99 latency targets?                                         | Slow API responses affecting throughput                | P3: P95 latency <Xs (load test), P3: P99 latency <Ys (load test)                                |
+| 7.2 | **Throttling (QoS):** Is there Rate Limiting to prevent "noisy neighbors" or DDoS?                   | Service degradation for all users due to one bad actor | P2: Rate limiting enforced, P2: 429 returned when limit exceeded                                |
+| 7.3 | **Perceived Performance (QoE):** Does the UI show optimistic updates or skeletons while loading?     | App feels sluggish to the user                         | P2: Skeleton/spinner shown while loading (E2E), P2: Optimistic updates (E2E)                    |
+| 7.4 | **Degradation (QoE):** If the service is slow, does it show a friendly message or a raw stack trace? | Poor user trust; frustration                           | P2: Friendly error message shown (not stack trace), P1: Error boundary catches exceptions (E2E) |
+
+**Common Gaps:**
+- Latency targets undefined (no SLOs)
+- No rate limiting (vulnerable to DDoS, noisy neighbors)
+- Poor perceived performance (blank screen while loading)
+- Raw error messages (stack traces exposed to users)
+
+**Mitigation Examples:**
+- 7.1 (Latency): Define SLOs (P95 <2s, P99 <5s), load test to validate
+- 7.2 (Throttling): Implement rate limiting (per-user, per-IP), return 429 with Retry-After
+- 7.3 (Perceived Performance): Add skeleton screens, optimistic updates, progressive loading
+- 7.4 (Degradation): Implement error boundaries, show friendly messages, log stack traces server-side
+
+---
+
+## 8. Deployability
+
+**Question:** How easily can we ship this?
+
+| #   | Criterion                                                                                  | Risk if Unmet                                          | Typical Test Scenarios (P0-P2)                                                 |
+| --- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------ | ------------------------------------------------------------------------------ |
+| 8.1 | **Zero Downtime:** Does the design support Blue/Green or Canary deployments?               | Maintenance windows required (downtime)                | P2: Blue/Green deployment works, P2: Canary deployment gradual rollout         |
+| 8.2 | **Backward Compatibility:** Can we deploy the DB changes separately from the Code changes? | "Lock-step" deployments; high risk of breaking changes | P2: DB migration before code deploy, P2: Code handles old and new schema       |
+| 8.3 | **Rollback:** Is there an automated rollback trigger if Health Checks fail post-deploy?    | Prolonged outages after a bad deploy                   | P2: Health check fails → automated rollback, P2: Rollback completes within RTO |
+
+**Common Gaps:**
+- No zero-downtime strategy (requires maintenance window)
+- Tight coupling between DB and code (lock-step deployments)
+- No automated rollback (manual intervention required)
+
+**Mitigation Examples:**
+- 8.1 (Zero Downtime): Implement Blue/Green or Canary deployments, use feature flags
+- 8.2 (Backward Compatibility): Separate DB migrations from code deploys, support N-1 schema
+- 8.3 (Rollback): Automate rollback on health check failures, test rollback procedures
+
+---
+
+## Usage in Test Design Workflow
+
+**System-Level Mode (Phase 3):**
+
+**In test-design-architecture.md:**
+- Add "NFR Testability Requirements" section after ASRs
+- Use 8 categories with checkboxes (29 criteria)
+- For each criterion: Status (⬜ Not Assessed, ⚠️ Gap, ✅ Covered), Gap description, Risk if unmet
+- Example:
+
+```markdown
+## NFR Testability Requirements
+
+**Based on ADR Quality Readiness Checklist**
+
+### 1. Testability & Automation
+
+Can we verify this effectively without manual toil?
+
+| Criterion                                                       | Status         | Gap/Requirement                      | Risk if Unmet                           |
+| --------------------------------------------------------------- | -------------- | ------------------------------------ | --------------------------------------- |
+| ⬜ Isolation: Can service be tested with downstream deps mocked? | ⚠️ Gap          | No mock endpoints for Athena queries | Flaky tests; can't test in isolation    |
+| ⬜ Headless: 100% business logic accessible via API?             | ✅ Covered      | All MCP tools are REST APIs          | N/A                                     |
+| ⬜ State Control: Seeding APIs to inject data states?            | ⚠️ Gap          | Need `/api/test-data` endpoints      | Long setup times; can't test edge cases |
+| ⬜ Sample Requests: Valid/invalid cURL/JSON samples provided?    | ⬜ Not Assessed | Pending ADR Tool schemas finalized   | Ambiguity on how to consume service     |
+
+**Actions Required:**
+- [ ] Backend: Implement mock endpoints for Athena (R-002 blocker)
+- [ ] Backend: Implement `/api/test-data` seeding APIs (R-002 blocker)
+- [ ] PM: Finalize ADR Tool schemas with sample requests (Q4)
+```
+
+**In test-design-qa.md:**
+- Map each criterion to test scenarios
+- Add "NFR Test Coverage Plan" section with P0/P1/P2 priority for each category
+- Reference Architecture doc gaps
+- Example:
+
+```markdown
+## NFR Test Coverage Plan
+
+**Based on ADR Quality Readiness Checklist**
+
+### 1. Testability & Automation (4 criteria)
+
+**Prerequisites from Architecture doc:**
+- [ ] R-002: Test data seeding APIs implemented (blocker)
+- [ ] Mock endpoints available for Athena queries
+
+| Criterion                       | Test Scenarios                                                       | Priority | Test Count | Owner            |
+| ------------------------------- | -------------------------------------------------------------------- | -------- | ---------- | ---------------- |
+| Isolation: Mock downstream deps | Mock Athena queries, Mock Milvus, Service runs isolated              | P1       | 3          | Backend Dev + QA |
+| Headless: API-accessible logic  | All MCP tools callable via REST, No UI dependency for business logic | P0       | 5          | QA               |
+| State Control: Seeding APIs     | Create test customer, Seed 1000 transactions, Inject edge cases      | P0       | 4          | QA               |
+| Sample Requests: cURL examples  | Valid request succeeds, Invalid request fails with clear error       | P1       | 2          | QA               |
+
+**Detailed Test Scenarios:**
+- [ ] Isolation: Service runs with Athena mocked (returns fixture data)
+- [ ] Isolation: Service runs with Milvus mocked (returns ANN fixture)
+- [ ] State Control: Seed test customer with 1000 baseline transactions
+- [ ] State Control: Inject edge case (expired subscription user)
+```
+
+---
+
+## Usage in NFR Assessment Workflow
+
+**Output Structure:**
+
+```markdown
+# NFR Assessment: {Feature Name}
+
+**Based on ADR Quality Readiness Checklist (8 categories, 29 criteria)**
+
+## Assessment Summary
+
+| Category                      | Status     | Criteria Met | Evidence                               | Next Action          |
+| ----------------------------- | ---------- | ------------ | -------------------------------------- | -------------------- |
+| 1. Testability & Automation   | ⚠️ CONCERNS | 2/4          | Mock endpoints missing                 | Implement R-002      |
+| 2. Test Data Strategy         | ✅ PASS     | 3/3          | Faker + auto-cleanup                   | None                 |
+| 3. Scalability & Availability | ⚠️ CONCERNS | 1/4          | SLA undefined                          | Define SLA           |
+| 4. Disaster Recovery          | ⚠️ CONCERNS | 0/3          | No RTO/RPO defined                     | Define recovery plan |
+| 5. Security                   | ✅ PASS     | 4/4          | OAuth 2.1 + TLS + Vault + Sanitization | None                 |
+| 6. Monitorability             | ⚠️ CONCERNS | 2/4          | No metrics endpoint                    | Add /metrics         |
+| 7. QoS & QoE                  | ⚠️ CONCERNS | 1/4          | Latency targets undefined              | Define SLOs          |
+| 8. Deployability              | ✅ PASS     | 3/3          | Blue/Green + DB migrations + Rollback  | None                 |
+
+**Overall:** 14/29 criteria met (48%) → ⚠️ CONCERNS
+
+**Gate Decision:** CONCERNS (requires mitigation plan before GA)
+
+---
+
+## Detailed Assessment
+
+### 1. Testability & Automation (2/4 criteria met)
+
+**Question:** Can we verify this effectively without manual toil?
+
+| Criterion                   | Status | Evidence                 | Gap/Action               |
+| --------------------------- | ------ | ------------------------ | ------------------------ |
+| ⬜ Isolation: Mock deps      | ⚠️      | No Athena mock           | Implement mock endpoints |
+| ⬜ Headless: API-accessible  | ✅      | All MCP tools are REST   | N/A                      |
+| ⬜ State Control: Seeding    | ⚠️      | `/api/test-data` pending | Sprint 0 blocker         |
+| ⬜ Sample Requests: Examples | ⬜      | Pending schemas          | Finalize ADR Tools       |
+
+**Overall Status:** ⚠️ CONCERNS (2/4 criteria met)
+
+**Next Actions:**
+- [ ] Backend: Implement Athena mock endpoints (Sprint 0)
+- [ ] Backend: Implement `/api/test-data` (Sprint 0)
+- [ ] PM: Finalize sample requests (Sprint 1)
+
+{Repeat for all 8 categories}
+```
+
+---
+
+## Benefits
+
+**For test-design workflow:**
+- ✅ Standard NFR structure (same 8 categories every project)
+- ✅ Clear testability requirements for Architecture team
+- ✅ Direct mapping: criterion → requirement → test scenario
+- ✅ Comprehensive coverage (29 criteria = no blind spots)
+
+**For nfr-assess workflow:**
+- ✅ Structured assessment (not ad-hoc)
+- ✅ Quantifiable (X/29 criteria met)
+- ✅ Evidence-based (each criterion has evidence field)
+- ✅ Actionable (gaps → next actions with owners)
+
+**For Architecture teams:**
+- ✅ Clear checklist (29 yes/no questions)
+- ✅ Risk-aware (each criterion has "risk if unmet")
+- ✅ Scoped work (only implement what's needed, not everything)
+
+**For QA teams:**
+- ✅ Comprehensive test coverage (29 criteria → test scenarios)
+- ✅ Clear priorities (P0 for security/isolation, P1 for monitoring, etc.)
+- ✅ No ambiguity (each criterion has specific test scenarios)
+

src/bmm/testarch/tea-index.csv

@@ -32,3 +32,4 @@ burn-in,Burn-in Runner,"Smart test selection, git diff for CI optimization","ci,
 network-error-monitor,Network Error Monitor,"HTTP 4xx/5xx detection for UI tests","monitoring,playwright-utils,ui",knowledge/network-error-monitor.md
 fixtures-composition,Fixtures Composition,"mergeTests composition patterns for combining utilities","fixtures,playwright-utils",knowledge/fixtures-composition.md
 api-testing-patterns,API Testing Patterns,"Pure API test patterns without browser: service testing, microservices, GraphQL","api,backend,service-testing,api-testing,microservices,graphql,no-browser",knowledge/api-testing-patterns.md
+adr-quality-readiness-checklist,ADR Quality Readiness Checklist,"8-category 29-criteria framework for ADR testability and NFR assessment","nfr,testability,adr,quality,assessment,checklist",knowledge/adr-quality-readiness-checklist.md

src/bmm/workflows/1-analysis/create-product-brief/steps/step-06-complete.md

@@ -73,17 +73,7 @@ I've successfully collaborated with you to create a comprehensive Product Brief
 
 This brief serves as the foundation for all subsequent product development activities and strategic decisions."
 
-### 2. Workflow Status Update
-
-**Status File Management:**
-Update the main workflow status file:
-
-- Check if `{output_folder} or {planning_artifacts}/bmm-workflow-status.yaml` exists
-- If so, update workflow_status["product-brief"] = `{outputFile}`
-- Add completion timestamp and metadata
-- Save file, preserving all comments and structure
-
-### 3. Document Quality Check
+### 2. Document Quality Check
 
 **Completeness Validation:**
 Perform final validation of the product brief:
@@ -101,7 +91,7 @@ Perform final validation of the product brief:
 - Are success criteria traceable to user needs and business goals?
 - Does MVP scope align with the problem and solution?
 
-### 4. Suggest Next Steps
+### 3. Suggest Next Steps
 
 **Recommended Next Workflow:**
 Provide guidance on logical next workflows:
@@ -124,12 +114,11 @@ Provide guidance on logical next workflows:
 - Use brief to validate concept before committing to detailed work
 - Brief can guide early technical feasibility discussions
 
-### 5. Present MENU OPTIONS
+### 4. Congrats to the user
 
-**Completion Confirmation:**
-"**Your Product Brief for {{project_name}} is now complete and ready for the next phase!**
+"**Your Product Brief for {{project_name}} is now complete and ready for the next phase!**"
 
-The brief captures everything needed to guide subsequent product development:
+Recap that the brief captures everything needed to guide subsequent product development:
 
 - Clear vision and problem definition
 - Deep understanding of target users
@@ -137,30 +126,9 @@ The brief captures everything needed to guide subsequent product development:
 - Focused MVP scope with realistic boundaries
 - Inspiring long-term vision
 
-**Suggested Next Steps**
+### 5. Suggest next steps
 
-- PRD workflow for detailed requirements?
-- UX design workflow for user experience planning?
-
-**Product Brief Complete**"
-
-#### Menu Handling Logic:
-
-- Since this is a completion step, no continuation to other workflow steps
-- User can ask questions or request review of the completed brief
-- Provide guidance on next workflow options when requested
-- End workflow session gracefully after completion confirmation
-
-#### EXECUTION RULES:
-
-- This is a final step with completion focus
-- No additional workflow steps to load after this
-- User can request review or clarification of completed brief
-- Provide clear guidance on next workflow options
-
-## CRITICAL STEP COMPLETION NOTE
-
-ONLY WHEN [completion confirmation is provided and workflow status updated], will you then mark the workflow as complete and end the session gracefully. No additional steps are loaded after this final completion step.
+Execute task `_bmad/core/tasks/bmad-help.md` with argument `Validate PRD`.
 
 ---
 

src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-14-complete.md

@@ -82,70 +82,13 @@ Update the main workflow status file:
 
 ### 3. Suggest Next Steps
 
-Provide guidance on logical next workflows:
-
-**Typical Next Workflows:**
-
-**Immediate Next Steps:**
-
-1. **Wireframe Generation** - Create detailed wireframes based on UX specification
-2. **Interactive Prototype** - Build clickable prototypes for user testing
-3. **Solution Architecture** - Technical architecture design with UX context
-4. **Figma Design** - High-fidelity visual design implementation
-
-**Visual Design Workflows:**
-
-- Wireframe Generation → Interactive Prototype → Figma Design
-- Component Showcase → AI Frontend Prompt → Design System Implementation
-
-**Development Workflows:**
-
-- Solution Architecture → Epic Creation → Development Sprints
-
-**What would be most valuable to tackle next?**
-
-### 4. Document Quality Check
-
-Perform final validation of the UX design:
-
-**Completeness Check:**
-
-- Does the specification clearly communicate the design vision?
-- Are user journeys thoroughly documented?
-- Are all critical components specified?
-- Are responsive and accessibility requirements comprehensive?
-- Is there clear guidance for implementation?
-
-**Consistency Check:**
-
-- Do all sections align with the emotional goals?
-- Is design system integration clearly defined?
-- Are patterns consistent across all user flows?
-- Does visual direction match established foundation?
+Execute task `_bmad/core/tasks/bmad-help.md` with argument `Create UX`.
 
 ### 5. Final Completion Confirmation
 
-Confirm completion with user:
-"**Your UX Design Specification for {{project_name}} is now complete and ready for implementation!**
+Congratulate the user on the completion you both completed together of the UX.
 
-**The specification contains everything needed to:**
 
-- Guide visual designers in creating the final interfaces
-- Inform developers of all UX requirements and patterns
-- Ensure consistency across all user interactions
-- Maintain accessibility and responsive design standards
-- Provide a foundation for user testing and iteration
-
-**Ready to continue with:**
-
-- Wireframe generation for detailed layouts?
-- Interactive prototype for user testing?
-- Solution architecture for technical planning?
-- Visual design implementation?
-
-**Or would you like to review the complete specification first?**
-
-[UX Design Workflow Complete]"
 
 ## SUCCESS METRICS:
 

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

@@ -87,39 +87,7 @@ Offer validation workflows to ensure PRD is ready for implementation:
 
 ### 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
+Execute task `_bmad/core/tasks/bmad-help.md` with argument `Create PRD`.
 
 ### 5. Final Completion Confirmation
 
@@ -149,30 +117,6 @@ Provide guidance on logical next workflows - strongly suggesting any of these ch
 ❌ **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.

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

@@ -163,7 +163,7 @@ 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
+**[X] Exit** - Exit and Suggest Next Steps.
 
 #### EXECUTION RULES:
 
@@ -197,8 +197,7 @@ Display:
 - **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
+  - Exit and Execute task `_bmad/core/tasks/bmad-help.md` with argument `Validate PRD`.
 
 - **IF Any other:** Help user, then redisplay menu
 

src/bmm/workflows/3-solutioning/check-implementation-readiness/steps/step-06-final-assessment.md

@@ -115,6 +115,8 @@ The assessment found [number] issues requiring attention. Review the detailed re
 
 The implementation readiness workflow is now complete. The report contains all findings and recommendations for the user to consider.
 
+Execute task `_bmad/core/tasks/bmad-help.md` with argument `implementation readiness`.
+
 ---
 
 ## 🚨 SYSTEM SUCCESS/FAILURE METRICS

src/bmm/workflows/3-solutioning/create-architecture/steps/step-07-validation.md

@@ -299,7 +299,7 @@ Show the validation results and present choices:
 **What would you like to do?**
 [A] Advanced Elicitation - Address any complex architectural concerns
 [P] Party Mode - Review validation from different implementation perspectives
-[C] Continue - Complete the architecture and finish workflow"
+[C] Continue - Complete the architecture and finish workflow
 
 ### 8. Handle Menu Selection
 

src/bmm/workflows/3-solutioning/create-architecture/steps/step-08-complete.md

@@ -5,7 +5,6 @@
 - 🛑 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 completion between architectural peers
 - 📋 YOU ARE A FACILITATOR, not a content generator
 - 💬 FOCUS on successful workflow completion and implementation handoff
@@ -18,14 +17,7 @@
 - 🎯 Show your analysis before taking any action
 - 🎯 Present completion summary and implementation guidance
 - 📖 Update frontmatter with final workflow state
-- 🚫 NO MORE STEPS - this is the final step
-
-## CONTEXT BOUNDARIES:
-
-- Complete architecture document is finished and validated
-- All architectural decisions, patterns, and structure are documented
-- Focus on successful completion and implementation preparation
-- Provide clear guidance for next steps in the development process
+- 🚫 THIS IS THE FINAL STEP IN THIS WORKFLOW
 
 ## YOUR TASK:
 
@@ -33,75 +25,11 @@ Complete the architecture workflow, provide a comprehensive completion summary,
 
 ## COMPLETION SEQUENCE:
 
-### 1. Present Architecture Completion Summary
+### 1. Congratulate the User on Completion
 
-Based on user skill level, present the completion:
+Both you and the User completed something amazing here - give a summary of what you achieved together and really congratulate the user on a job well done.
 
-**For Expert Users:**
-"Architecture workflow complete. {{decision_count}} architectural decisions documented across {{step_count}} steps.
-
-Your architecture is ready for AI agent implementation. All decisions are documented with specific versions and implementation patterns.
-
-Key deliverables:
-
-- Complete architecture decision document
-- Implementation patterns for agent consistency
-- Project structure with all files and directories
-- Validation confirming coherence and completeness
-
-Ready for implementation phase."
-
-**For Intermediate Users:**
-"Excellent! Your architecture for {{project_name}} is now complete and ready for implementation.
-
-**What we accomplished:**
-
-- Made {{decision_count}} key architectural decisions together
-- Established implementation patterns to ensure consistency
-- Created a complete project structure with {{component_count}} main areas
-- Validated that all your requirements are fully supported
-
-**Your architecture document includes:**
-
-- Technology choices with specific versions
-- Clear implementation patterns for AI agents to follow
-- Complete project directory structure
-- Mapping of your requirements to specific files and folders
-
-The architecture is comprehensive and ready to guide consistent implementation."
-
-**For Beginner Users:**
-"Congratulations! Your architecture for {{project_name}} is complete! 🎉
-
-**What this means:**
-Think of this as creating the complete blueprint for your house. We've made all the important decisions about how it will be built, what materials to use, and how everything fits together.
-
-**What we created together:**
-
-- {{decision_count}} architectural decisions (like choosing the foundation, framing, and systems)
-- Clear rules so that multiple builders (AI agents) all work the same way
-- A complete folder structure showing exactly where every file goes
-- Confirmation that everything you want to build is supported by these decisions
-
-**What happens next:**
-AI agents will read this architecture document before building anything. They'll follow all your decisions exactly, which means your app will be built with consistent patterns throughout.
-
-You're ready for the implementation phase!"
-
-### 2. Review Final Document State
-
-Confirm the architecture document is complete:
-
-**Document Structure Verification:**
-
-- Project Context Analysis ✅
-- Starter Template Evaluation ✅
-- Core Architectural Decisions ✅
-- Implementation Patterns & Consistency Rules ✅
-- Project Structure & Boundaries ✅
-- Architecture Validation Results ✅
-
-**Frontmatter Update:**
+### 2. Update the created document's frontmatter
 
 ```yaml
 stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8]
@@ -111,216 +39,12 @@ status: 'complete'
 completedAt: '{{current_date}}'
 ```
 
-### 3. Implementation Guidance
+### 3. Next Steps Guidance
 
-Provide specific next steps for implementation:
+Execute task `_bmad/core/tasks/bmad-help.md` with argument `Create Architecture`.
 
-**Immediate Next Steps:**
+Upon Completion of task output: offer to answer any questions about the Architecture Document.
 
-1. **Review the complete architecture document** at `{planning_artifacts}/architecture.md`
-2. **Begin with project initialization** using the starter template command documented
-3. **Create first implementation story** for project setup
-4. **Start implementing user stories** following the architectural decisions
-
-**Development Workflow:**
-"AI agents will:
-
-1. Read the architecture document before implementing each story
-2. Follow your technology choices and patterns exactly
-3. Use the project structure we defined
-4. Maintain consistency across all components"
-
-**Quality Assurance:**
-"Your architecture includes:
-
-- Specific technology versions to use
-- Implementation patterns that prevent conflicts
-- Clear project structure and boundaries
-- Validation that all requirements are supported"
-
-### 4. Generate Completion Content
-
-Prepare the final content to append to the document:
-
-#### Content Structure:
-
-```markdown
-## Architecture Completion Summary
-
-### Workflow Completion
-
-**Architecture Decision Workflow:** COMPLETED ✅
-**Total Steps Completed:** 8
-**Date Completed:** {{current_date}}
-**Document Location:** {planning_artifacts}/architecture.md
-
-### Final Architecture Deliverables
-
-**📋 Complete Architecture Document**
-
-- All architectural decisions documented with specific versions
-- Implementation patterns ensuring AI agent consistency
-- Complete project structure with all files and directories
-- Requirements to architecture mapping
-- Validation confirming coherence and completeness
-
-**🏗️ Implementation Ready Foundation**
-
-- {{decision_count}} architectural decisions made
-- {{pattern_count}} implementation patterns defined
-- {{component_count}} architectural components specified
-- {{requirement_count}} requirements fully supported
-
-**📚 AI Agent Implementation Guide**
-
-- Technology stack with verified versions
-- Consistency rules that prevent implementation conflicts
-- Project structure with clear boundaries
-- Integration patterns and communication standards
-
-### Implementation Handoff
-
-**For AI Agents:**
-This architecture document is your complete guide for implementing {{project_name}}. Follow all decisions, patterns, and structures exactly as documented.
-
-**First Implementation Priority:**
-{{starter_template_command_or_initialization_step}}
-
-**Development Sequence:**
-
-1. Initialize project using documented starter template
-2. Set up development environment per architecture
-3. Implement core architectural foundations
-4. Build features following established patterns
-5. Maintain consistency with documented rules
-
-### Quality Assurance Checklist
-
-**✅ Architecture Coherence**
-
-- [x] All decisions work together without conflicts
-- [x] Technology choices are compatible
-- [x] Patterns support the architectural decisions
-- [x] Structure aligns with all choices
-
-**✅ Requirements Coverage**
-
-- [x] All functional requirements are supported
-- [x] All non-functional requirements are addressed
-- [x] Cross-cutting concerns are handled
-- [x] Integration points are defined
-
-**✅ Implementation Readiness**
-
-- [x] Decisions are specific and actionable
-- [x] Patterns prevent agent conflicts
-- [x] Structure is complete and unambiguous
-- [x] Examples are provided for clarity
-
-### Project Success Factors
-
-**🎯 Clear Decision Framework**
-Every technology choice was made collaboratively with clear rationale, ensuring all stakeholders understand the architectural direction.
-
-**🔧 Consistency Guarantee**
-Implementation patterns and rules ensure that multiple AI agents will produce compatible, consistent code that works together seamlessly.
-
-**📋 Complete Coverage**
-All project requirements are architecturally supported, with clear mapping from business needs to technical implementation.
-
-**🏗️ Solid Foundation**
-The chosen starter template and architectural patterns provide a production-ready foundation following current best practices.
-
----
-
-**Architecture Status:** READY FOR IMPLEMENTATION ✅
-
-**Next Phase:** Begin implementation using the architectural decisions and patterns documented herein.
-
-**Document Maintenance:** Update this architecture when major technical decisions are made during implementation.
-```
-
-### 5. Complete Workflow Finalization
-
-**Save Final Document:**
-
-- Ensure all content is properly appended to `{planning_artifacts}/architecture.md`
-- Update frontmatter with completion status
-- Verify document is complete and coherent
-
-**Workflow Status Update:**
-If not in standalone mode, update workflow status:
-
-- Load `{planning_artifacts}/bmm-workflow-status.yaml`
-- Update workflow_status["create-architecture"] = "{planning_artifacts}/architecture.md"
-- Save file with all structure and comments preserved
-
-### 6. Present Completion to User
-
-"🎉 **Architecture Workflow Complete!**
-
-Your architecture for {{project_name}} is comprehensive, validated, and ready for implementation.
-
-**✅ What's been delivered:**
-
-- Complete architecture document with all decisions and patterns
-- Project structure ready for AI agent implementation
-- Validation confirming everything works together coherently
-- Implementation guidance for the development phase
-
-**📍 Where to find it:**
-`{planning_artifacts}/architecture.md`
-
-**🚀 What's next:**
-
-1. Review your complete architecture document
-2. Begin implementation using the starter template command
-3. Create stories for AI agents to implement following your architectural decisions
-
-Your architecture will ensure consistent, high-quality implementation across all development work. Great job collaborating through these important architectural decisions!
-
-**💡 Optional Enhancement: Project Context File**
-
-Would you like to create a `project-context.md` file? This is a concise, optimized guide for AI agents that captures:
-
-- Critical language and framework rules they might miss
-- Specific patterns and conventions for your project
-- Testing and code quality requirements
-- Anti-patterns and edge cases to avoid
-
-{if_existing_project_context}
-I noticed you already have a project context file. Would you like to update it with your new architectural decisions?
-{else}
-This file helps ensure AI agents implement code consistently with your project's unique requirements and patterns.
-{/if_existing_project_context}
-
-**Create/Update project context?** [Y/N]
-
-**Ready to move to the next phase of your project development?**"
-
-### 7. Handle Project Context Creation Choice
-
-If user responds 'Y' or 'yes' to creating/updating project context:
-
-"Excellent choice! Let me launch the Generate Project Context workflow to create a comprehensive guide for AI agents.
-
-This will help ensure consistent implementation by capturing:
-
-- Language-specific patterns and rules
-- Framework conventions from your architecture
-- Testing and quality standards
-- Anti-patterns to avoid
-
-The workflow will collaborate with you to create an optimized `project-context.md` file that AI agents will read before implementing any code."
-
-**Execute the Generate Project Context workflow:**
-
-- Load and execute: `{project-root}/_bmad/bmm/workflows/generate-project-context/workflow.md`
-- The workflow will handle discovery, generation, and completion of the project context file
-- After completion, return here for final handoff
-
-If user responds 'N' or 'no':
-"Understood! Your architecture is complete and ready for implementation. You can always create a project context file later using the Generate Project Context workflow if needed."
 
 ## SUCCESS METRICS:
 

src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-04-final-validation.md

@@ -143,3 +143,7 @@ If all validations pass:
 **All validations complete!** [C] Complete Workflow
 
 When C is selected, the workflow is complete and the epics.md is ready for development.
+
+Execute task `_bmad/core/tasks/bmad-help.md` with argument `Create Epics and Stories`.
+
+Upon Completion of task output: offer to answer any questions about the Epics and Stories.

src/bmm/workflows/4-implementation/sprint-status/instructions.md

@@ -96,7 +96,7 @@ Enter corrections (e.g., "1=in-progress, 2=backlog") or "skip" to continue witho
   3. Else if any story status == ready-for-dev → recommend `dev-story`
   4. Else if any story status == backlog → recommend `create-story`
   5. Else if any retrospective status == optional → recommend `retrospective`
-  6. Else → All implementation items done; suggest `workflow-status` to plan next phase
+  6. Else → All implementation items done; congratulate the user - you both did amazing work together!
   <action>Store selected recommendation as: next_story_id, next_workflow_id, next_agent (SM/DEV as appropriate)</action>
 </step>
 

src/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-01-mode-detection.md

@@ -104,12 +104,12 @@ Present choice:
 This looks like a focused feature with multiple components.
 
 **[t] Create tech-spec first** (recommended)
-**[w] Seems bigger than quick-dev** - see what BMad Method recommends
+**[w] Seems bigger than quick-dev** - Recommend the Full BMad Flow PRD Process
 **[e] Execute directly**
 ```
 
 - **[t]:** Direct to `{quick_spec_workflow}`. **EXIT Quick Dev.**
-- **[w]:** Direct to `{workflow_init}`. **EXIT Quick Dev.**
+- **[w]:** Direct user to run the PRD workflow instead. **EXIT Quick Dev.**
 - **[e]:** Ask for guidance, then **NEXT:** Load `step-02-context-gathering.md`
 
 ### Escalation Triggered - Level 3+
@@ -122,8 +122,8 @@ This sounds like platform/system work.
 **[e] Execute directly** - feeling lucky
 ```
 
-- **[w]:** Direct to `{workflow_init}`. **EXIT Quick Dev.**
 - **[t]:** Direct to `{quick_spec_workflow}`. **EXIT Quick Dev.**
+- **[w]:** Direct user to run the PRD workflow instead. **EXIT Quick Dev.**
 - **[e]:** Ask for guidance, then **NEXT:** Load `step-02-context-gathering.md`
 
 ---

src/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md

@@ -36,12 +36,10 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
 
 - `installed_path` = `{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev`
 - `project_context` = `**/project-context.md` (load if exists)
-- `project_levels` = `{project-root}/_bmad/bmm/workflows/workflow-status/project-levels.yaml`
 
 ### Related Workflows
 
 - `quick_spec_workflow` = `{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md`
-- `workflow_init` = `{project-root}/_bmad/bmm/workflows/workflow-status/init/workflow.yaml`
 - `party_mode_exec` = `{project-root}/_bmad/core/workflows/party-mode/workflow.md`
 - `advanced_elicitation` = `{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml`
 

src/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_

src/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!

src/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!

src/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.

src/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.

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

@@ -257,7 +257,6 @@ test('should do something', async ({ {fixtureName} }) => {
 
 - Check off tasks as you complete them
 - Share progress in daily standup
-- Mark story as IN PROGRESS in `bmm-workflow-status.md`
 
 ---
 

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

@@ -143,7 +143,6 @@ Note: CI setup is typically a one-time task per repo and can be run any time aft
 
 ### 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

src/bmm/workflows/testarch/framework/checklist.md

@@ -201,7 +201,6 @@ Before starting the workflow:
 
 ### Status File Integration
 
-- [ ] `bmm-workflow-status.md` exists
 - [ ] Framework initialization logged in Quality & Testing Progress section
 - [ ] Status file updated with completion timestamp
 - [ ] Status file shows framework: Playwright or Cypress

src/bmm/workflows/testarch/nfr-assess/instructions.md

@@ -51,7 +51,7 @@ This workflow performs a comprehensive assessment of non-functional requirements
 **Actions:**
 
 1. Load relevant knowledge fragments from `{project-root}/_bmad/bmm/testarch/tea-index.csv`:
-   - `nfr-criteria.md` - Non-functional requirements criteria and thresholds (security, performance, reliability, maintainability with code examples, 658 lines, 4 examples)
+   - `adr-quality-readiness-checklist.md` - 8-category 29-criteria NFR framework (testability, test data, scalability, DR, security, monitorability, QoS/QoE, deployability, ~450 lines)
    - `ci-burn-in.md` - CI/CD burn-in patterns for reliability validation (10-iteration detection, sharding, selective execution, 678 lines, 4 examples)
    - `test-quality.md` - Test quality expectations for maintainability (deterministic, isolated, explicit assertions, length/time limits, 658 lines, 5 examples)
    - `playwright-config.md` - Performance configuration patterns: parallelization, timeout standards, artifact output (722 lines, 5 examples)
@@ -75,13 +75,17 @@ This workflow performs a comprehensive assessment of non-functional requirements
 
 **Actions:**
 
-1. Determine which NFR categories to assess (default: performance, security, reliability, maintainability):
-   - **Performance**: Response time, throughput, resource usage
-   - **Security**: Authentication, authorization, data protection, vulnerability scanning
-   - **Reliability**: Error handling, recovery, availability, fault tolerance
-   - **Maintainability**: Code quality, test coverage, documentation, technical debt
+1. Determine which NFR categories to assess using ADR Quality Readiness Checklist (8 standard categories):
+   - **1. Testability & Automation**: Isolation, headless interaction, state control, sample requests (4 criteria)
+   - **2. Test Data Strategy**: Segregation, generation, teardown (3 criteria)
+   - **3. Scalability & Availability**: Statelessness, bottlenecks, SLA definitions, circuit breakers (4 criteria)
+   - **4. Disaster Recovery**: RTO/RPO, failover, backups (3 criteria)
+   - **5. Security**: AuthN/AuthZ, encryption, secrets, input validation (4 criteria)
+   - **6. Monitorability, Debuggability & Manageability**: Tracing, logs, metrics, config (4 criteria)
+   - **7. QoS & QoE**: Latency, throttling, perceived performance, degradation (4 criteria)
+   - **8. Deployability**: Zero downtime, backward compatibility, rollback (3 criteria)
 
-2. Add custom NFR categories if specified (e.g., accessibility, internationalization, compliance)
+2. Add custom NFR categories if specified (e.g., accessibility, internationalization, compliance) beyond the 8 standard categories
 
 3. Gather thresholds for each NFR:
    - From tech-spec.md (primary source)

src/bmm/workflows/testarch/nfr-assess/nfr-report-template.md

@@ -355,13 +355,24 @@ Note: This assessment summarizes existing evidence; it does not run tests or CI
 
 ## Findings Summary
 
-| Category        | PASS             | CONCERNS             | FAIL             | Overall Status                      |
-| --------------- | ---------------- | -------------------- | ---------------- | ----------------------------------- |
-| Performance     | {P_PASS_COUNT}   | {P_CONCERNS_COUNT}   | {P_FAIL_COUNT}   | {P_STATUS} {P_ICON}                 |
-| Security        | {S_PASS_COUNT}   | {S_CONCERNS_COUNT}   | {S_FAIL_COUNT}   | {S_STATUS} {S_ICON}                 |
-| Reliability     | {R_PASS_COUNT}   | {R_CONCERNS_COUNT}   | {R_FAIL_COUNT}   | {R_STATUS} {R_ICON}                 |
-| Maintainability | {M_PASS_COUNT}   | {M_CONCERNS_COUNT}   | {M_FAIL_COUNT}   | {M_STATUS} {M_ICON}                 |
-| **Total**       | **{TOTAL_PASS}** | **{TOTAL_CONCERNS}** | **{TOTAL_FAIL}** | **{OVERALL_STATUS} {OVERALL_ICON}** |
+**Based on ADR Quality Readiness Checklist (8 categories, 29 criteria)**
+
+| Category | Criteria Met | PASS | CONCERNS | FAIL | Overall Status |
+|----------|--------------|------|----------|------|----------------|
+| 1. Testability & Automation | {T_MET}/4 | {T_PASS} | {T_CONCERNS} | {T_FAIL} | {T_STATUS} {T_ICON} |
+| 2. Test Data Strategy | {TD_MET}/3 | {TD_PASS} | {TD_CONCERNS} | {TD_FAIL} | {TD_STATUS} {TD_ICON} |
+| 3. Scalability & Availability | {SA_MET}/4 | {SA_PASS} | {SA_CONCERNS} | {SA_FAIL} | {SA_STATUS} {SA_ICON} |
+| 4. Disaster Recovery | {DR_MET}/3 | {DR_PASS} | {DR_CONCERNS} | {DR_FAIL} | {DR_STATUS} {DR_ICON} |
+| 5. Security | {SEC_MET}/4 | {SEC_PASS} | {SEC_CONCERNS} | {SEC_FAIL} | {SEC_STATUS} {SEC_ICON} |
+| 6. Monitorability, Debuggability & Manageability | {MON_MET}/4 | {MON_PASS} | {MON_CONCERNS} | {MON_FAIL} | {MON_STATUS} {MON_ICON} |
+| 7. QoS & QoE | {QOS_MET}/4 | {QOS_PASS} | {QOS_CONCERNS} | {QOS_FAIL} | {QOS_STATUS} {QOS_ICON} |
+| 8. Deployability | {DEP_MET}/3 | {DEP_PASS} | {DEP_CONCERNS} | {DEP_FAIL} | {DEP_STATUS} {DEP_ICON} |
+| **Total** | **{TOTAL_MET}/29** | **{TOTAL_PASS}** | **{TOTAL_CONCERNS}** | **{TOTAL_FAIL}** | **{OVERALL_STATUS} {OVERALL_ICON}** |
+
+**Criteria Met Scoring:**
+- ≥26/29 (90%+) = Strong foundation
+- 20-25/29 (69-86%) = Room for improvement
+- <20/29 (<69%) = Significant gaps
 
 ---
 
@@ -372,11 +383,16 @@ nfr_assessment:
   date: '{DATE}'
   story_id: '{STORY_ID}'
   feature_name: '{FEATURE_NAME}'
+  adr_checklist_score: '{TOTAL_MET}/29'  # ADR Quality Readiness Checklist
   categories:
-    performance: '{PERFORMANCE_STATUS}'
-    security: '{SECURITY_STATUS}'
-    reliability: '{RELIABILITY_STATUS}'
-    maintainability: '{MAINTAINABILITY_STATUS}'
+    testability_automation: '{T_STATUS}'
+    test_data_strategy: '{TD_STATUS}'
+    scalability_availability: '{SA_STATUS}'
+    disaster_recovery: '{DR_STATUS}'
+    security: '{SEC_STATUS}'
+    monitorability: '{MON_STATUS}'
+    qos_qoe: '{QOS_STATUS}'
+    deployability: '{DEP_STATUS}'
   overall_status: '{OVERALL_STATUS}'
   critical_issues: { CRITICAL_COUNT }
   high_priority_issues: { HIGH_COUNT }

src/bmm/workflows/testarch/test-design/checklist.md

@@ -1,10 +1,17 @@
 # Test Design and Risk Assessment - Validation Checklist
 
-## Prerequisites
+## Prerequisites (Mode-Dependent)
 
+**System-Level Mode (Phase 3):**
+- [ ] PRD exists with functional and non-functional requirements
+- [ ] ADR (Architecture Decision Record) exists
+- [ ] Architecture document available (architecture.md or tech-spec)
+- [ ] Requirements are testable and unambiguous
+
+**Epic-Level Mode (Phase 4):**
 - [ ] Story markdown with clear acceptance criteria exists
 - [ ] PRD or epic documentation available
-- [ ] Architecture documents available (optional)
+- [ ] Architecture documents available (test-design-architecture.md + test-design-qa.md from Phase 3, if exists)
 - [ ] Requirements are testable and unambiguous
 
 ## Process Steps
@@ -145,7 +152,6 @@
 
 ### Status File Integration
 
-- [ ] bmm-workflow-status.md exists
 - [ ] Test design logged in Quality & Testing Progress
 - [ ] Epic number and scope documented
 - [ ] Completion timestamp recorded
@@ -158,6 +164,80 @@
 - [ ] Risk assessment informs `gate` workflow criteria
 - [ ] Integrates with `ci` workflow execution order
 
+## System-Level Mode: Two-Document Validation
+
+**When in system-level mode (PRD + ADR input), validate BOTH documents:**
+
+### test-design-architecture.md
+
+- [ ] **Purpose statement** at top (serves as contract with Architecture team)
+- [ ] **Executive Summary** with scope, business context, architecture decisions, risk summary
+- [ ] **Quick Guide** section with three tiers:
+  - [ ] 🚨 BLOCKERS - Team Must Decide (Sprint 0 critical path items)
+  - [ ] ⚠️ HIGH PRIORITY - Team Should Validate (recommendations for approval)
+  - [ ] 📋 INFO ONLY - Solutions Provided (no decisions needed)
+- [ ] **Risk Assessment** section
+  - [ ] Total risks identified count
+  - [ ] High-priority risks table (score ≥6) with all columns: Risk ID, Category, Description, Probability, Impact, Score, Mitigation, Owner, Timeline
+  - [ ] Medium and low-priority risks tables
+  - [ ] Risk category legend included
+- [ ] **Testability Concerns** section (if system has architectural constraints)
+  - [ ] Blockers to fast feedback table
+  - [ ] Explanation of why standard CI/CD may not apply (if applicable)
+  - [ ] Tiered testing strategy table (if forced by architecture)
+  - [ ] Architectural improvements needed (or acknowledgment system supports testing well)
+- [ ] **Risk Mitigation Plans** for all high-priority risks (≥6)
+  - [ ] Each plan has: Strategy (numbered steps), Owner, Timeline, Status, Verification
+- [ ] **Assumptions and Dependencies** section
+  - [ ] Assumptions list (numbered)
+  - [ ] Dependencies list with required dates
+  - [ ] Risks to plan with impact and contingency
+- [ ] **NO test implementation code** (long examples belong in QA doc)
+- [ ] **NO test scenario checklists** (belong in QA doc)
+- [ ] **Cross-references to QA doc** where appropriate
+
+### test-design-qa.md
+
+- [ ] **Purpose statement** at top (execution recipe for QA team)
+- [ ] **Quick Reference for QA** section
+  - [ ] Before You Start checklist
+  - [ ] Test Execution Order
+  - [ ] Need Help? guidance
+- [ ] **System Architecture Summary** (brief overview of services and data flow)
+- [ ] **Test Environment Requirements** in early section (section 1-3, NOT buried at end)
+  - [ ] Table with Local/Dev/Staging environments
+  - [ ] Key principles listed (shared DB, randomization, parallel-safe, self-cleaning, shift-left)
+  - [ ] Code example provided
+- [ ] **Testability Assessment** with prerequisites checklist
+  - [ ] References Architecture doc blockers (not duplication)
+- [ ] **Test Levels Strategy** with unit/integration/E2E split
+  - [ ] System type identified
+  - [ ] Recommended split percentages with rationale
+  - [ ] Test count summary (P0/P1/P2/P3 totals)
+- [ ] **Test Coverage Plan** with P0/P1/P2/P3 sections
+  - [ ] Each priority has: Execution details, Purpose, Criteria, Test Count
+  - [ ] Detailed test scenarios WITH CHECKBOXES
+  - [ ] Coverage table with columns: Requirement | Test Level | Risk Link | Test Count | Owner | Notes
+- [ ] **Sprint 0 Setup Requirements**
+  - [ ] Architecture/Backend blockers listed with cross-references to Architecture doc
+  - [ ] QA Test Infrastructure section (factories, fixtures)
+  - [ ] Test Environments section (Local, CI/CD, Staging, Production)
+  - [ ] Sprint 0 NFR Gates checklist
+  - [ ] Sprint 1 Items clearly separated
+- [ ] **NFR Readiness Summary** (reference to Architecture doc, not duplication)
+  - [ ] Table with NFR categories, status, evidence, blocker, next action
+- [ ] **Cross-references to Architecture doc** (not duplication)
+- [ ] **NO architectural theory** (just reference Architecture doc)
+
+### Cross-Document Consistency
+
+- [ ] Both documents reference same risks by ID (R-001, R-002, etc.)
+- [ ] Both documents use consistent priority levels (P0, P1, P2, P3)
+- [ ] Both documents reference same Sprint 0 blockers
+- [ ] No duplicate content (cross-reference instead)
+- [ ] Dates and authors match across documents
+- [ ] ADR and PRD references consistent
+
 ## Completion Criteria
 
 **All must be true:**
@@ -167,7 +247,9 @@
 - [ ] All output validations passed
 - [ ] All quality checks passed
 - [ ] All integration points verified
-- [ ] Output file complete and well-formatted
+- [ ] Output file(s) complete and well-formatted
+- [ ] **System-level mode:** Both documents validated (if applicable)
+- [ ] **Epic-level mode:** Single document validated (if applicable)
 - [ ] Team review scheduled (if required)
 
 ## Post-Workflow Actions

src/bmm/workflows/testarch/test-design/instructions.md

@@ -22,33 +22,64 @@ The workflow auto-detects which mode to use based on project phase.
 
 **Critical:** Determine mode before proceeding.
 
-### Mode Detection
+### Mode Detection (Flexible for Standalone Use)
 
-1. **Check for sprint-status.yaml**
-   - If `{implementation_artifacts}/sprint-status.yaml` exists → **Epic-Level Mode** (Phase 4)
-   - If NOT exists → Check workflow status
+TEA test-design workflow supports TWO modes, detected automatically:
 
-2. **Check workflow-status.yaml**
-   - Read `{planning_artifacts}/bmm-workflow-status.yaml`
-   - If `implementation-readiness: required` or `implementation-readiness: recommended` → **System-Level Mode** (Phase 3)
-   - Otherwise → **Epic-Level Mode** (Phase 4 without sprint status yet)
+1. **Check User Intent Explicitly (Priority 1)**
 
-3. **Mode-Specific Requirements**
+   **Deterministic Rules:**
+   - User provided **PRD+ADR only** (no Epic+Stories) → **System-Level Mode**
+   - User provided **Epic+Stories only** (no PRD+ADR) → **Epic-Level Mode**
+   - User provided **BOTH PRD+ADR AND Epic+Stories** → **Prefer System-Level Mode** (architecture review comes first in Phase 3, then epic planning in Phase 4). If mode preference is unclear, ask user: "Should I create (A) System-level test design (PRD + ADR → Architecture doc + QA doc) or (B) Epic-level test design (Epic → Single test plan)?"
+   - If user intent is clear from context, use that mode regardless of file structure
 
-   **System-Level Mode (Phase 3 - Testability Review):**
-   - ✅ Architecture document exists (architecture.md or tech-spec)
-   - ✅ PRD exists with functional and non-functional requirements
-   - ✅ Epics documented (epics.md)
-   - ⚠️ Output: `{output_folder}/test-design-system.md`
+2. **Fallback to File-Based Detection (Priority 2 - BMad-Integrated)**
+   - Check for `{implementation_artifacts}/sprint-status.yaml`
+   - If exists → **Epic-Level Mode** (Phase 4, single document output)
+   - If NOT exists → **System-Level Mode** (Phase 3, TWO document outputs)
 
-   **Epic-Level Mode (Phase 4 - Per-Epic Planning):**
-   - ✅ Story markdown with acceptance criteria available
-   - ✅ PRD or epic documentation exists for context
-   - ✅ Architecture documents available (optional but recommended)
-   - ✅ Requirements are clear and testable
-   - ⚠️ Output: `{output_folder}/test-design-epic-{epic_num}.md`
+3. **If Ambiguous, ASK USER (Priority 3)**
+   - "I see you have [PRD/ADR/Epic/Stories]. Should I create:
+     - (A) System-level test design (PRD + ADR → Architecture doc + QA doc)?
+     - (B) Epic-level test design (Epic → Single test plan)?"
 
-**Halt Condition:** If mode cannot be determined or required files missing, HALT and notify user with missing prerequisites.
+**Mode Descriptions:**
+
+**System-Level Mode (PRD + ADR Input)**
+- **When to use:** Early in project (Phase 3 Solutioning), architecture being designed
+- **Input:** PRD, ADR, architecture.md (optional)
+- **Output:** TWO documents
+  - `test-design-architecture.md` (for Architecture/Dev teams)
+  - `test-design-qa.md` (for QA team)
+- **Focus:** Testability assessment, ASRs, NFR requirements, Sprint 0 setup
+
+**Epic-Level Mode (Epic + Stories Input)**
+- **When to use:** During implementation (Phase 4), per-epic planning
+- **Input:** Epic, Stories, tech-specs (optional)
+- **Output:** ONE document
+  - `test-design-epic-{N}.md` (combined risk assessment + test plan)
+- **Focus:** Risk assessment, coverage plan, execution order, quality gates
+
+**Key Insight: TEA Works Standalone OR Integrated**
+
+**Standalone (No BMad artifacts):**
+- User provides PRD + ADR → System-Level Mode
+- User provides Epic description → Epic-Level Mode
+- TEA doesn't mandate full BMad workflow
+
+**BMad-Integrated (Full workflow):**
+- BMad creates `sprint-status.yaml` → Automatic Epic-Level detection
+- BMad creates PRD, ADR, architecture.md → Automatic System-Level detection
+- TEA leverages BMad artifacts for richer context
+
+**Message to User:**
+> You don't need to follow full BMad methodology to use TEA test-design.
+> Just provide PRD + ADR for system-level, or Epic for epic-level.
+> TEA will auto-detect and produce appropriate documents.
+
+**Halt Condition:** If mode cannot be determined AND user intent unclear AND required files missing, HALT and notify user:
+- "Please provide either: (A) PRD + ADR for system-level test design, OR (B) Epic + Stories for epic-level test design"
 
 ---
 
@@ -74,8 +105,8 @@ The workflow auto-detects which mode to use based on project phase.
 
 3. **Load Knowledge Base Fragments (System-Level)**
 
-   **Critical:** Consult `{project-root}/_bmad/bmm/testarch/tea-index.csv` to load:
-   - `nfr-criteria.md` - NFR validation approach (security, performance, reliability, maintainability)
+   **Critical:** Consult `src/bmm/testarch/tea-index.csv` to load:
+   - `adr-quality-readiness-checklist.md` - 8-category 29-criteria NFR framework (testability, security, scalability, DR, QoS, deployability, etc.)
    - `test-levels-framework.md` - Test levels strategy guidance
    - `risk-governance.md` - Testability risk identification
    - `test-quality.md` - Quality standards and Definition of Done
@@ -96,7 +127,7 @@ The workflow auto-detects which mode to use based on project phase.
 2. **Load Architecture Context**
    - Read architecture.md for system design
    - Read tech-spec for implementation details
-   - Read test-design-system.md (if exists from Phase 3)
+   - Read test-design-architecture.md and test-design-qa.md (if exist from Phase 3 system-level test design)
    - Identify technical constraints and dependencies
    - Note integration points and external systems
 
@@ -108,7 +139,7 @@ The workflow auto-detects which mode to use based on project phase.
 
 4. **Load Knowledge Base Fragments (Epic-Level)**
 
-   **Critical:** Consult `{project-root}/_bmad/bmm/testarch/tea-index.csv` to load:
+   **Critical:** Consult `src/bmm/testarch/tea-index.csv` to load:
    - `risk-governance.md` - Risk classification framework (6 categories: TECH, SEC, PERF, DATA, BUS, OPS), automated scoring, gate decision engine, owner tracking (625 lines, 4 examples)
    - `probability-impact.md` - Risk scoring methodology (probability × impact matrix, automated classification, dynamic re-assessment, gate integration, 604 lines, 4 examples)
    - `test-levels-framework.md` - Test level selection guidance (E2E vs API vs Component vs Unit with decision matrix, characteristics, when to use each, 467 lines, 4 examples)
@@ -178,50 +209,128 @@ The workflow auto-detects which mode to use based on project phase.
 
    **Critical:** If testability concerns are blockers (e.g., "Architecture makes performance testing impossible"), document as CONCERNS or FAIL recommendation for gate check.
 
-6. **Output System-Level Test Design**
+6. **Output System-Level Test Design (TWO Documents)**
 
-   Write to `{output_folder}/test-design-system.md` containing:
+   **IMPORTANT:** System-level mode produces TWO documents instead of one:
+
+   **Document 1: test-design-architecture.md** (for Architecture/Dev teams)
+   - Purpose: Architectural concerns, testability gaps, NFR requirements
+   - Audience: Architects, Backend Devs, Frontend Devs, DevOps, Security Engineers
+   - Focus: What architecture must deliver for testability
+   - Template: `test-design-architecture-template.md`
+
+   **Document 2: test-design-qa.md** (for QA team)
+   - Purpose: Test execution recipe, coverage plan, Sprint 0 setup
+   - Audience: QA Engineers, Test Automation Engineers, QA Leads
+   - Focus: How QA will execute tests
+   - Template: `test-design-qa-template.md`
+
+   **Standard Structures (REQUIRED):**
+
+   **test-design-architecture.md sections (in this order):**
+   1. Executive Summary (scope, business context, architecture, risk summary)
+   2. Quick Guide (🚨 BLOCKERS / ⚠️ HIGH PRIORITY / 📋 INFO ONLY)
+   3. Risk Assessment (high/medium/low-priority risks with scoring)
+   4. Testability Concerns and Architectural Gaps (if system has constraints)
+   5. Risk Mitigation Plans (detailed for high-priority risks ≥6)
+   6. Assumptions and Dependencies
+
+   **test-design-qa.md sections (in this order):**
+   1. Quick Reference for QA (Before You Start, Execution Order, Need Help)
+   2. System Architecture Summary (brief overview)
+   3. Test Environment Requirements (MOVE UP - section 3, NOT buried at end)
+   4. Testability Assessment (lightweight prerequisites checklist)
+   5. Test Levels Strategy (unit/integration/E2E split with rationale)
+   6. Test Coverage Plan (P0/P1/P2/P3 with detailed scenarios + checkboxes)
+   7. Sprint 0 Setup Requirements (blockers, infrastructure, environments)
+   8. NFR Readiness Summary (reference to Architecture doc)
+
+   **Content Guidelines:**
+
+   **Architecture doc (DO):**
+   - ✅ Risk scoring visible (Probability × Impact = Score)
+   - ✅ Clear ownership (each blocker/ASR has owner + timeline)
+   - ✅ Testability requirements (what architecture must support)
+   - ✅ Mitigation plans (for each high-risk item ≥6)
+   - ✅ Short code examples (5-10 lines max showing what to support)
+
+   **Architecture doc (DON'T):**
+   - ❌ NO long test code examples (belongs in QA doc)
+   - ❌ NO test scenario checklists (belongs in QA doc)
+   - ❌ NO implementation details (how QA will test)
+
+   **QA doc (DO):**
+   - ✅ Test scenario recipes (clear P0/P1/P2/P3 with checkboxes)
+   - ✅ Environment setup (Sprint 0 checklist with blockers)
+   - ✅ Tool setup (factories, fixtures, frameworks)
+   - ✅ Cross-references to Architecture doc (not duplication)
+
+   **QA doc (DON'T):**
+   - ❌ NO architectural theory (just reference Architecture doc)
+   - ❌ NO ASR explanations (link to Architecture doc instead)
+   - ❌ NO duplicate risk assessments (reference Architecture doc)
+
+   **Anti-Patterns to Avoid (Cross-Document Redundancy):**
+
+   ❌ **DON'T duplicate OAuth requirements:**
+   - Architecture doc: Explain OAuth 2.1 flow in detail
+   - QA doc: Re-explain why OAuth 2.1 is required
+
+   ✅ **DO cross-reference instead:**
+   - Architecture doc: "ASR-1: OAuth 2.1 required (see QA doc for 12 test scenarios)"
+   - QA doc: "OAuth tests: 12 P0 scenarios (see Architecture doc R-001 for risk details)"
+
+   **Markdown Cross-Reference Syntax Examples:**
 
    ```markdown
-   # System-Level Test Design
+   # In test-design-architecture.md
+
+   ### 🚨 R-001: Multi-Tenant Isolation (Score: 9)
+
+   **Test Coverage:** 8 P0 tests (see [QA doc - Multi-Tenant Isolation](test-design-qa.md#multi-tenant-isolation-8-tests-security-critical) for detailed scenarios)
+
+   ---
+
+   # In test-design-qa.md
 
    ## Testability Assessment
 
-   - Controllability: [PASS/CONCERNS/FAIL with details]
-   - Observability: [PASS/CONCERNS/FAIL with details]
-   - Reliability: [PASS/CONCERNS/FAIL with details]
+   **Prerequisites from Architecture Doc:**
+   - [ ] R-001: Multi-tenant isolation validated (see [Architecture doc R-001](test-design-architecture.md#r-001-multi-tenant-isolation-score-9) for mitigation plan)
+   - [ ] R-002: Test customer provisioned (see [Architecture doc 🚨 BLOCKERS](test-design-architecture.md#blockers---team-must-decide-cant-proceed-without))
 
-   ## Architecturally Significant Requirements (ASRs)
+   ## Sprint 0 Setup Requirements
 
-   [Risk-scored quality requirements]
-
-   ## Test Levels Strategy
-
-   - Unit: [X%] - [Rationale]
-   - Integration: [Y%] - [Rationale]
-   - E2E: [Z%] - [Rationale]
-
-   ## NFR Testing Approach
-
-   - Security: [Approach with tools]
-   - Performance: [Approach with tools]
-   - Reliability: [Approach with tools]
-   - Maintainability: [Approach with tools]
-
-   ## Test Environment Requirements
-
-   [Infrastructure needs based on deployment architecture]
-
-   ## Testability Concerns (if any)
-
-   [Blockers or concerns that should inform solutioning gate check]
-
-   ## Recommendations for Sprint 0
-
-   [Specific actions for *framework and *ci workflows]
+   **Source:** See [Architecture doc "Quick Guide"](test-design-architecture.md#quick-guide) for detailed mitigation plans
    ```
 
-**After System-Level Mode:** Skip to Step 4 (Generate Deliverables) - Steps 2-3 are epic-level only.
+   **Key Points:**
+   - Use relative links: `[Link Text](test-design-qa.md#section-anchor)`
+   - Anchor format: lowercase, hyphens for spaces, remove emojis/special chars
+   - Example anchor: `### 🚨 R-001: Title` → `#r-001-title`
+
+   ❌ **DON'T put long code examples in Architecture doc:**
+   - Example: 50+ lines of test implementation
+
+   ✅ **DO keep examples SHORT in Architecture doc:**
+   - Example: 5-10 lines max showing what architecture must support
+   - Full implementation goes in QA doc
+
+   ❌ **DON'T repeat same note 10+ times:**
+   - Example: "Pessimistic timing until R-005 fixed" on every P0/P1/P2 section
+
+   ✅ **DO consolidate repeated notes:**
+   - Single timing note at top
+   - Reference briefly throughout: "(pessimistic)"
+
+   **Write Both Documents:**
+   - Use `test-design-architecture-template.md` for Architecture doc
+   - Use `test-design-qa-template.md` for QA doc
+   - Follow standard structures defined above
+   - Cross-reference between docs (no duplication)
+   - Validate against checklist.md (System-Level Mode section)
+
+**After System-Level Mode:** Workflow COMPLETE. System-level outputs (test-design-architecture.md + test-design-qa.md) are written in this step. Steps 2-4 are epic-level only - do NOT execute them in system-level mode.
 
 ---
 

src/bmm/workflows/testarch/test-design/test-design-architecture-template.md

@@ -0,0 +1,216 @@
+# Test Design for Architecture: {Feature Name}
+
+**Purpose:** Architectural concerns, testability gaps, and NFR requirements for review by Architecture/Dev teams. Serves as a contract between QA and Engineering on what must be addressed before test development begins.
+
+**Date:** {date}
+**Author:** {author}
+**Status:** Architecture Review Pending
+**Project:** {project_name}
+**PRD Reference:** {prd_link}
+**ADR Reference:** {adr_link}
+
+---
+
+## Executive Summary
+
+**Scope:** {Brief description of feature scope}
+
+**Business Context** (from PRD):
+- **Revenue/Impact:** {Business metrics if applicable}
+- **Problem:** {Problem being solved}
+- **GA Launch:** {Target date or timeline}
+
+**Architecture** (from ADR {adr_number}):
+- **Key Decision 1:** {e.g., OAuth 2.1 authentication}
+- **Key Decision 2:** {e.g., Centralized MCP Server pattern}
+- **Key Decision 3:** {e.g., Stack: TypeScript, SDK v1.x}
+
+**Expected Scale** (from ADR):
+- {RPS, volume, users, etc.}
+
+**Risk Summary:**
+- **Total risks**: {N}
+- **High-priority (≥6)**: {N} risks requiring immediate mitigation
+- **Test effort**: ~{N} tests (~{X} weeks for 1 QA, ~{Y} weeks for 2 QAs)
+
+---
+
+## Quick Guide
+
+### 🚨 BLOCKERS - Team Must Decide (Can't Proceed Without)
+
+**Sprint 0 Critical Path** - These MUST be completed before QA can write integration tests:
+
+1. **{Blocker ID}: {Blocker Title}** - {What architecture must provide} (recommended owner: {Team/Role})
+2. **{Blocker ID}: {Blocker Title}** - {What architecture must provide} (recommended owner: {Team/Role})
+3. **{Blocker ID}: {Blocker Title}** - {What architecture must provide} (recommended owner: {Team/Role})
+
+**What we need from team:** Complete these {N} items in Sprint 0 or test development is blocked.
+
+---
+
+### ⚠️ HIGH PRIORITY - Team Should Validate (We Provide Recommendation, You Approve)
+
+1. **{Risk ID}: {Title}** - {Recommendation + who should approve} (Sprint {N})
+2. **{Risk ID}: {Title}** - {Recommendation + who should approve} (Sprint {N})
+3. **{Risk ID}: {Title}** - {Recommendation + who should approve} (Sprint {N})
+
+**What we need from team:** Review recommendations and approve (or suggest changes).
+
+---
+
+### 📋 INFO ONLY - Solutions Provided (Review, No Decisions Needed)
+
+1. **Test strategy**: {Test level split} ({Rationale})
+2. **Tooling**: {Test frameworks and utilities}
+3. **Tiered CI/CD**: {Execution tiers with timing}
+4. **Coverage**: ~{N} test scenarios prioritized P0-P3 with risk-based classification
+5. **Quality gates**: {Pass criteria}
+
+**What we need from team:** Just review and acknowledge (we already have the solution).
+
+---
+
+## For Architects and Devs - Open Topics 👷
+
+### Risk Assessment
+
+**Total risks identified**: {N} ({X} high-priority score ≥6, {Y} medium, {Z} low)
+
+#### High-Priority Risks (Score ≥6) - IMMEDIATE ATTENTION
+
+| Risk ID | Category | Description | Probability | Impact | Score | Mitigation | Owner | Timeline |
+|---------|----------|-------------|-------------|--------|-------|------------|-------|----------|
+| **{R-ID}** | **{CAT}** | {Description} | {1-3} | {1-3} | **{Score}** | {Mitigation strategy} | {Owner} | {Date} |
+
+#### Medium-Priority Risks (Score 3-5)
+
+| Risk ID | Category | Description | Probability | Impact | Score | Mitigation | Owner |
+|---------|----------|-------------|-------------|--------|-------|------------|-------|
+| {R-ID} | {CAT} | {Description} | {1-3} | {1-3} | {Score} | {Mitigation} | {Owner} |
+
+#### Low-Priority Risks (Score 1-2)
+
+| Risk ID | Category | Description | Probability | Impact | Score | Action |
+|---------|----------|-------------|-------------|--------|-------|--------|
+| {R-ID} | {CAT} | {Description} | {1-3} | {1-3} | {Score} | Monitor |
+
+#### Risk Category Legend
+
+- **TECH**: Technical/Architecture (flaws, integration, scalability)
+- **SEC**: Security (access controls, auth, data exposure)
+- **PERF**: Performance (SLA violations, degradation, resource limits)
+- **DATA**: Data Integrity (loss, corruption, inconsistency)
+- **BUS**: Business Impact (UX harm, logic errors, revenue)
+- **OPS**: Operations (deployment, config, monitoring)
+
+---
+
+### Testability Concerns and Architectural Gaps
+
+**IMPORTANT**: {If system has constraints, explain them. If standard CI/CD achievable, state that.}
+
+#### Blockers to Fast Feedback
+
+| Blocker | Impact | Current Mitigation | Ideal Solution |
+|---------|--------|-------------------|----------------|
+| **{Blocker name}** | {Impact description} | {How we're working around it} | {What architecture should provide} |
+
+#### Why This Matters
+
+**Standard CI/CD expectations:**
+- Full test suite on every commit (~5-15 min feedback)
+- Parallel test execution (isolated test data per worker)
+- Ephemeral test environments (spin up → test → tear down)
+- Fast feedback loop (devs stay in flow state)
+
+**Current reality for {Feature}:**
+- {Actual situation - what's different from standard}
+
+#### Tiered Testing Strategy
+
+{If forced by architecture, explain. If standard approach works, state that.}
+
+| Tier | When | Duration | Coverage | Why Not Full Suite? |
+|------|------|----------|----------|---------------------|
+| **Smoke** | Every commit | <5 min | {N} tests | Fast feedback, catch build-breaking changes |
+| **P0** | Every commit | ~{X} min | ~{N} tests | Critical paths, security-critical flows |
+| **P1** | PR to main | ~{X} min | ~{N} tests | Important features, algorithm accuracy |
+| **P2/P3** | Nightly | ~{X} min | ~{N} tests | Edge cases, performance, NFR |
+
+**Note**: {Any timing assumptions or constraints}
+
+#### Architectural Improvements Needed
+
+{If system has technical debt affecting testing, list improvements. If architecture supports testing well, acknowledge that.}
+
+1. **{Improvement name}**
+   - {What to change}
+   - **Impact**: {How it improves testing}
+
+#### Acceptance of Trade-offs
+
+For {Feature} Phase 1, the team accepts:
+- **{Trade-off 1}** ({Reasoning})
+- **{Trade-off 2}** ({Reasoning})
+- ⚠️ **{Known limitation}** ({Why acceptable for now})
+
+This is {**technical debt** OR **acceptable for Phase 1**} that should be {revisited post-GA OR maintained as-is}.
+
+---
+
+### Risk Mitigation Plans (High-Priority Risks ≥6)
+
+**Purpose**: Detailed mitigation strategies for all {N} high-priority risks (score ≥6). These risks MUST be addressed before {GA launch date or milestone}.
+
+#### {R-ID}: {Risk Description} (Score: {Score}) - {CRITICALITY LEVEL}
+
+**Mitigation Strategy:**
+1. {Step 1}
+2. {Step 2}
+3. {Step 3}
+
+**Owner:** {Owner}
+**Timeline:** {Sprint or date}
+**Status:** Planned / In Progress / Complete
+**Verification:** {How to verify mitigation is effective}
+
+---
+
+{Repeat for all high-priority risks}
+
+---
+
+### Assumptions and Dependencies
+
+#### Assumptions
+
+1. {Assumption about architecture or requirements}
+2. {Assumption about team or timeline}
+3. {Assumption about scope or constraints}
+
+#### Dependencies
+
+1. {Dependency} - Required by {date/sprint}
+2. {Dependency} - Required by {date/sprint}
+
+#### Risks to Plan
+
+- **Risk**: {Risk to the test plan itself}
+  - **Impact**: {How it affects testing}
+  - **Contingency**: {Backup plan}
+
+---
+
+**End of Architecture Document**
+
+**Next Steps for Architecture Team:**
+1. Review Quick Guide (🚨/⚠️/📋) and prioritize blockers
+2. Assign owners and timelines for high-priority risks (≥6)
+3. Validate assumptions and dependencies
+4. Provide feedback to QA on testability gaps
+
+**Next Steps for QA Team:**
+1. Wait for Sprint 0 blockers to be resolved
+2. Refer to companion QA doc (test-design-qa.md) for test scenarios
+3. Begin test infrastructure setup (factories, fixtures, environments)

src/bmm/workflows/testarch/test-design/test-design-qa-template.md

@@ -0,0 +1,314 @@
+# Test Design for QA: {Feature Name}
+
+**Purpose:** Test execution recipe for QA team. Defines test scenarios, coverage plan, tooling, and Sprint 0 setup requirements. Use this as your implementation guide after architectural blockers are resolved.
+
+**Date:** {date}
+**Author:** {author}
+**Status:** Draft / Ready for Implementation
+**Project:** {project_name}
+**PRD Reference:** {prd_link}
+**ADR Reference:** {adr_link}
+
+---
+
+## Quick Reference for QA
+
+**Before You Start:**
+- [ ] Review Architecture doc (test-design-architecture.md) - understand blockers and risks
+- [ ] Verify Sprint 0 blockers resolved (see Sprint 0 section below)
+- [ ] Confirm test infrastructure ready (factories, fixtures, environments)
+
+**Test Execution Order:**
+1. **Smoke tests** (<5 min) - Fast feedback on critical paths
+2. **P0 tests** (~{X} min) - Critical paths, security-critical flows
+3. **P1 tests** (~{X} min) - Important features, algorithm accuracy
+4. **P2/P3 tests** (~{X} min) - Edge cases, performance, NFR
+
+**Need Help?**
+- Blockers: See Architecture doc "Quick Guide" for mitigation plans
+- Test scenarios: See "Test Coverage Plan" section below
+- Sprint 0 setup: See "Sprint 0 Setup Requirements" section
+
+---
+
+## System Architecture Summary
+
+**Data Pipeline:**
+{Brief description of system flow}
+
+**Key Services:**
+- **{Service 1}**: {Purpose and key responsibilities}
+- **{Service 2}**: {Purpose and key responsibilities}
+- **{Service 3}**: {Purpose and key responsibilities}
+
+**Data Stores:**
+- **{Database 1}**: {What it stores}
+- **{Database 2}**: {What it stores}
+
+**Expected Scale** (from ADR):
+- {Key metrics: RPS, volume, users, etc.}
+
+---
+
+## Test Environment Requirements
+
+**{Company} Standard:** Shared DB per Environment with Randomization (Shift-Left)
+
+| Environment | Database | Test Data Strategy | Purpose |
+|-------------|----------|-------------------|---------|
+| **Local** | {DB} (shared) | Randomized (faker), auto-cleanup | Local development |
+| **Dev (CI)** | {DB} (shared) | Randomized (faker), auto-cleanup | PR validation |
+| **Staging** | {DB} (shared) | Randomized (faker), auto-cleanup | Pre-production, E2E |
+
+**Key Principles:**
+- **Shared database per environment** (no ephemeral)
+- **Randomization for isolation** (faker-based unique IDs)
+- **Parallel-safe** (concurrent test runs don't conflict)
+- **Self-cleaning** (tests delete their own data)
+- **Shift-left** (test against real DBs early)
+
+**Example:**
+
+```typescript
+import { faker } from "@faker-js/faker";
+
+test("example with randomized test data @p0", async ({ apiRequest }) => {
+  const testData = {
+    id: `test-${faker.string.uuid()}`,
+    customerId: `test-customer-${faker.string.alphanumeric(8)}`,
+    // ... unique test data
+  };
+
+  // Seed, test, cleanup
+});
+```
+
+---
+
+## Testability Assessment
+
+**Prerequisites from Architecture Doc:**
+
+Verify these blockers are resolved before test development:
+- [ ] {Blocker 1} (see Architecture doc Quick Guide → 🚨 BLOCKERS)
+- [ ] {Blocker 2}
+- [ ] {Blocker 3}
+
+**If Prerequisites Not Met:** Coordinate with Architecture team (see Architecture doc for mitigation plans and owner assignments)
+
+---
+
+## Test Levels Strategy
+
+**System Type:** {API-heavy / UI-heavy / Mixed backend system}
+
+**Recommended Split:**
+- **Unit Tests: {X}%** - {What to unit test}
+- **Integration/API Tests: {X}%** - ⭐ **PRIMARY FOCUS** - {What to integration test}
+- **E2E Tests: {X}%** - {What to E2E test}
+
+**Rationale:** {Why this split makes sense for this system}
+
+**Test Count Summary:**
+- P0: ~{N} tests - Critical paths, run on every commit
+- P1: ~{N} tests - Important features, run on PR to main
+- P2: ~{N} tests - Edge cases, run nightly/weekly
+- P3: ~{N} tests - Exploratory, run on-demand
+- **Total: ~{N} tests** (~{X} weeks for 1 QA, ~{Y} weeks for 2 QAs)
+
+---
+
+## Test Coverage Plan
+
+**Repository Note:** {Where tests live - backend repo, admin panel repo, etc. - and how CI pipelines are organized}
+
+### P0 (Critical) - Run on every commit (~{X} min)
+
+**Execution:** CI/CD on every commit, parallel workers, smoke tests first (<5 min)
+
+**Purpose:** Critical path validation - catch build-breaking changes and security violations immediately
+
+**Criteria:** Blocks core functionality OR High risk (≥6) OR No workaround
+
+**Key Smoke Tests** (subset of P0, run first for fast feedback):
+- {Smoke test 1} - {Duration}
+- {Smoke test 2} - {Duration}
+- {Smoke test 3} - {Duration}
+
+| Requirement | Test Level | Risk Link | Test Count | Owner | Notes |
+|-------------|------------|-----------|------------|-------|-------|
+| {Requirement 1} | {Level} | {R-ID} | {N} | QA | {Notes} |
+| {Requirement 2} | {Level} | {R-ID} | {N} | QA | {Notes} |
+
+**Total P0:** ~{N} tests (~{X} weeks)
+
+#### P0 Test Scenarios (Detailed)
+
+**1. {Test Category} ({N} tests) - {CRITICALITY if applicable}**
+
+- [ ] {Scenario 1 with checkbox}
+- [ ] {Scenario 2}
+- [ ] {Scenario 3}
+
+**2. {Test Category 2} ({N} tests)**
+
+- [ ] {Scenario 1}
+- [ ] {Scenario 2}
+
+{Continue for all P0 categories}
+
+---
+
+### P1 (High) - Run on PR to main (~{X} min additional)
+
+**Execution:** CI/CD on pull requests to main branch, runs after P0 passes, parallel workers
+
+**Purpose:** Important feature coverage - algorithm accuracy, complex workflows, Admin Panel interactions
+
+**Criteria:** Important features OR Medium risk (3-4) OR Common workflows
+
+| Requirement | Test Level | Risk Link | Test Count | Owner | Notes |
+|-------------|------------|-----------|------------|-------|-------|
+| {Requirement 1} | {Level} | {R-ID} | {N} | QA | {Notes} |
+| {Requirement 2} | {Level} | {R-ID} | {N} | QA | {Notes} |
+
+**Total P1:** ~{N} tests (~{X} weeks)
+
+#### P1 Test Scenarios (Detailed)
+
+**1. {Test Category} ({N} tests)**
+
+- [ ] {Scenario 1}
+- [ ] {Scenario 2}
+
+{Continue for all P1 categories}
+
+---
+
+### P2 (Medium) - Run nightly/weekly (~{X} min)
+
+**Execution:** Scheduled nightly run (or weekly for P3), full infrastructure, sequential execution acceptable
+
+**Purpose:** Edge case coverage, error handling, data integrity validation - slow feedback acceptable
+
+**Criteria:** Secondary features OR Low risk (1-2) OR Edge cases
+
+| Requirement | Test Level | Risk Link | Test Count | Owner | Notes |
+|-------------|------------|-----------|------------|-------|-------|
+| {Requirement 1} | {Level} | {R-ID} | {N} | QA | {Notes} |
+| {Requirement 2} | {Level} | {R-ID} | {N} | QA | {Notes} |
+
+**Total P2:** ~{N} tests (~{X} weeks)
+
+---
+
+### P3 (Low) - Run on-demand (exploratory)
+
+**Execution:** Manual trigger or weekly scheduled run, performance testing
+
+**Purpose:** Full regression, performance benchmarks, accessibility validation - no time pressure
+
+**Criteria:** Nice-to-have OR Exploratory OR Performance benchmarks
+
+| Requirement | Test Level | Test Count | Owner | Notes |
+|-------------|------------|------------|-------|-------|
+| {Requirement 1} | {Level} | {N} | QA | {Notes} |
+| {Requirement 2} | {Level} | {N} | QA | {Notes} |
+
+**Total P3:** ~{N} tests (~{X} days)
+
+---
+
+### Coverage Matrix (Requirements → Tests)
+
+| Requirement | Test Level | Priority | Risk Link | Test Count | Owner |
+|-------------|------------|----------|-----------|------------|-------|
+| {Requirement 1} | {Level} | {P0-P3} | {R-ID} | {N} | {Owner} |
+| {Requirement 2} | {Level} | {P0-P3} | {R-ID} | {N} | {Owner} |
+
+---
+
+## Sprint 0 Setup Requirements
+
+**IMPORTANT:** These items **BLOCK test development**. Complete in Sprint 0 before QA can write tests.
+
+### Architecture/Backend Blockers (from Architecture doc)
+
+**Source:** See Architecture doc "Quick Guide" for detailed mitigation plans
+
+1. **{Blocker 1}** 🚨 **BLOCKER** - {Owner}
+   - {What needs to be provided}
+   - **Details:** Architecture doc {Risk-ID} mitigation plan
+
+2. **{Blocker 2}** 🚨 **BLOCKER** - {Owner}
+   - {What needs to be provided}
+   - **Details:** Architecture doc {Risk-ID} mitigation plan
+
+### QA Test Infrastructure
+
+1. **{Factory/Fixture Name}** - QA
+   - Faker-based generator: `{function_signature}`
+   - Auto-cleanup after tests
+
+2. **{Entity} Fixtures** - QA
+   - Seed scripts for {states/scenarios}
+   - Isolated {id_pattern} per test
+
+### Test Environments
+
+**Local:** {Setup details - Docker, LocalStack, etc.}
+
+**CI/CD:** {Setup details - shared infrastructure, parallel workers, artifacts}
+
+**Staging:** {Setup details - shared multi-tenant, nightly E2E}
+
+**Production:** {Setup details - feature flags, canary transactions}
+
+**Sprint 0 NFR Gates** (MUST complete before integration testing):
+- [ ] {Gate 1}: {Description} (Owner) 🚨
+- [ ] {Gate 2}: {Description} (Owner) 🚨
+- [ ] {Gate 3}: {Description} (Owner) 🚨
+
+### Sprint 1 Items (Not Sprint 0)
+
+- **{Item 1}** ({Owner}): {Description}
+- **{Item 2}** ({Owner}): {Description}
+
+**Sprint 1 NFR Gates** (MUST complete before GA):
+- [ ] {Gate 1}: {Description} (Owner)
+- [ ] {Gate 2}: {Description} (Owner)
+
+---
+
+## NFR Readiness Summary
+
+**Based on Architecture Doc Risk Assessment**
+
+| NFR Category | Status | Evidence Status | Blocker | Next Action |
+|--------------|--------|-----------------|---------|-------------|
+| **Testability & Automation** | {Status} | {Evidence} | {Sprint} | {Action} |
+| **Test Data Strategy** | {Status} | {Evidence} | {Sprint} | {Action} |
+| **Scalability & Availability** | {Status} | {Evidence} | {Sprint} | {Action} |
+| **Disaster Recovery** | {Status} | {Evidence} | {Sprint} | {Action} |
+| **Security** | {Status} | {Evidence} | {Sprint} | {Action} |
+| **Monitorability, Debuggability & Manageability** | {Status} | {Evidence} | {Sprint} | {Action} |
+| **QoS & QoE** | {Status} | {Evidence} | {Sprint} | {Action} |
+| **Deployability** | {Status} | {Evidence} | {Sprint} | {Action} |
+
+**Total:** {N} PASS, {N} CONCERNS across {N} categories
+
+---
+
+**End of QA Document**
+
+**Next Steps for QA Team:**
+1. Verify Sprint 0 blockers resolved (coordinate with Architecture team if not)
+2. Set up test infrastructure (factories, fixtures, environments)
+3. Begin test implementation following priority order (P0 → P1 → P2 → P3)
+4. Run smoke tests first for fast feedback
+5. Track progress using test scenario checklists above
+
+**Next Steps for Architecture Team:**
+1. Monitor Sprint 0 blocker resolution
+2. Provide support for QA infrastructure setup if needed
+3. Review test results and address any newly discovered testability gaps

src/bmm/workflows/testarch/test-design/workflow.yaml

@@ -15,6 +15,9 @@ date: system-generated
 installed_path: "{project-root}/_bmad/bmm/workflows/testarch/test-design"
 instructions: "{installed_path}/instructions.md"
 validation: "{installed_path}/checklist.md"
+# Note: Template selection is mode-based (see instructions.md Step 1.5):
+#   - System-level: test-design-architecture-template.md + test-design-qa-template.md
+#   - Epic-level: test-design-template.md (unchanged)
 template: "{installed_path}/test-design-template.md"
 
 # Variables and inputs
@@ -26,13 +29,25 @@ variables:
 # Note: Actual output file determined dynamically based on mode detection
 # Declared outputs for new workflow format
 outputs:
-  - id: system-level
-    description: "System-level testability review (Phase 3)"
-    path: "{output_folder}/test-design-system.md"
+  # System-Level Mode (Phase 3) - TWO documents
+  - id: test-design-architecture
+    description: "System-level test architecture: Architectural concerns, testability gaps, NFR requirements for Architecture/Dev teams"
+    path: "{output_folder}/test-design-architecture.md"
+    mode: system-level
+    audience: architecture
+
+  - id: test-design-qa
+    description: "System-level test design: Test execution recipe, coverage plan, Sprint 0 setup for QA team"
+    path: "{output_folder}/test-design-qa.md"
+    mode: system-level
+    audience: qa
+
+  # Epic-Level Mode (Phase 4) - ONE document (unchanged)
   - id: epic-level
     description: "Epic-level test plan (Phase 4)"
     path: "{output_folder}/test-design-epic-{epic_num}.md"
-default_output_file: "{output_folder}/test-design-epic-{epic_num}.md"
+    mode: epic-level
+# Note: No default_output_file - mode detection determines which outputs to write
 
 # Required tools
 required_tools:

src/bmm/workflows/testarch/trace/checklist.md

@@ -375,12 +375,6 @@ Knowledge fragments referenced:
 
 ### Step 5: Status Updates and Notifications
 
-**Status File Updated:**
-
-- [ ] Gate decision appended to bmm-workflow-status.md (if append_to_history: true)
-- [ ] Format correct: `[DATE] Gate Decision: DECISION - Target {ID} - {rationale}`
-- [ ] Status file committed or staged for commit
-
 **Gate YAML Created:**
 
 - [ ] Gate YAML snippet generated with decision and criteria
@@ -480,13 +474,6 @@ Knowledge fragments referenced:
 
 ## Phase 2 Integration Points
 
-### BMad Workflow Status
-
-- [ ] Gate decision added to `bmm-workflow-status.md`
-- [ ] Format matches existing gate history entries
-- [ ] Timestamp is accurate
-- [ ] Decision summary is concise (<80 chars)
-
 ### CI/CD Pipeline
 
 - [ ] Gate YAML is CI/CD-compatible

src/bmm/workflows/testarch/trace/instructions.md

@@ -292,7 +292,6 @@ This phase uses traceability results to make a quality gate decision (PASS/CONCE
 4. **Load supporting artifacts**:
    - `test-design.md` → Risk priorities, DoD checklist
    - `story-*.md` or `Epics.md` → Requirements context
-   - `bmm-workflow-status.md` → Workflow completion status (if `check_all_workflows_complete: true`)
 
 5. **Validate evidence freshness** (if `validate_evidence_freshness: true`):
    - Check timestamps of test-design, traceability, NFR assessments
@@ -399,7 +398,7 @@ This phase uses traceability results to make a quality gate decision (PASS/CONCE
 ## Decision Criteria
 
 | Criterion         | Threshold | Actual   | Status |
-| ----------------- | --------- | -------- | ------- |
+| ----------------- | --------- | -------- | ------ |
 | P0 Coverage       | ≥100%     | 100%     | ✅ PASS |
 | P1 Coverage       | ≥90%      | 88%      | ⚠️ FAIL |
 | Overall Coverage  | ≥80%      | 92%      | ✅ PASS |
@@ -506,22 +505,7 @@ This phase uses traceability results to make a quality gate decision (PASS/CONCE
 
 **Actions:**
 
-1. **Update workflow status** (if `append_to_history: true`):
-   - Append gate decision to `bmm-workflow-status.md` under "Gate History" section
-   - Format:
-
-     ```markdown
-     ## Gate History
-
-     ### Story 1.3 - User Login (2025-01-15)
-
-     - **Decision**: CONCERNS
-     - **Reason**: P1 coverage 88% (below 90%)
-     - **Document**: [gate-decision-story-1.3.md](_bmad/output/gate-decision-story-1.3.md)
-     - **Action**: Deploy with follow-up story for AC-5
-     ```
-
-2. **Generate stakeholder notification** (if `notify_stakeholders: true`):
+1. **Generate stakeholder notification** (if `notify_stakeholders: true`):
    - Create concise summary message for team communication
    - Include: Decision, key metrics, action items
    - Format for Slack/email/chat:
@@ -541,7 +525,7 @@ This phase uses traceability results to make a quality gate decision (PASS/CONCE
    Full Report: _bmad/output/gate-decision-story-1.3.md
    ```
 
-3. **Request sign-off** (if `require_sign_off: true`):
+2. **Request sign-off** (if `require_sign_off: true`):
    - Prompt for named approver (tech lead, QA lead, PM)
    - Document approver name and timestamp in gate decision
    - Block until sign-off received (interactive prompt)
@@ -837,7 +821,7 @@ Use selective testing principles from `selective-testing.md`:
 ## Coverage Summary
 
 | Priority  | Total Criteria | FULL Coverage | Coverage % | Status |
-| --------- | -------------- | ------------- | ---------- | ------- |
+| --------- | -------------- | ------------- | ---------- | ------ |
 | P0        | 3              | 3             | 100%       | ✅ PASS |
 | P1        | 5              | 4             | 80%        | ⚠️ WARN |
 | P2        | 4              | 3             | 75%        | ✅ PASS |
@@ -968,7 +952,6 @@ Before completing this workflow, verify:
 - ✅ Decision rules applied consistently (PASS/CONCERNS/FAIL/WAIVED)
 - ✅ Gate decision document created with evidence
 - ✅ Waiver documented if decision is WAIVED (approver, justification, mitigation)
-- ✅ Workflow status updated (bmm-workflow-status.md)
 - ✅ Stakeholders notified (if enabled)
 
 ---

src/bmm/workflows/workflow-status/init/instructions.md

@@ -1,346 +0,0 @@
-# Workflow Init - Project Setup Instructions
-
-<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
-<critical>You MUST have already loaded and processed: workflow-init/workflow.yaml</critical>
-<critical>Communicate in {communication_language} with {user_name}</critical>
-<critical>This workflow handles BOTH new projects AND legacy projects following the BMad Method</critical>
-
-<workflow>
-
-<step n="1" goal="Scan for existing work">
-<output>Welcome to BMad Method, {user_name}!</output>
-
-<action>Perform comprehensive scan for existing work:
-
-- BMM artifacts: PRD, epics, architecture, UX, brief, research, brainstorm
-- Implementation: stories, sprint-status, workflow-status
-- Codebase: source directories, package files, git repo
-- Check both {planning_artifacts} and {implementation_artifacts} locations
-</action>
-
-<action>Categorize into one of these states:
-
-- CLEAN: No artifacts or code (or scaffold only)
-- PLANNING: Has PRD/spec but no implementation
-- ACTIVE: Has stories or sprint status
-- LEGACY: Has code but no BMM artifacts
-- UNCLEAR: Mixed state needs clarification
-</action>
-
-<ask>What's your project called? {{#if project_name}}(Config shows: {{project_name}}){{/if}}</ask>
-<action>Store project_name</action>
-<template-output>project_name</template-output>
-</step>
-
-<step n="2" goal="Choose setup path">
-<check if="state == CLEAN">
-  <output>Perfect! Fresh start detected.</output>
-  <action>Continue to step 3</action>
-</check>
-
-<check if="state == ACTIVE AND workflow_status exists">
-  <output>✅ You already have workflow tracking at: {{workflow_status_path}}
-
-To check progress: Load any BMM agent and run /bmad:bmm:workflows:workflow-status
-
-Happy building! 🚀</output>
-<action>Exit workflow (already initialized)</action>
-</check>
-
-<check if="state != CLEAN">
-  <output>Found existing work:
-{{summary_of_findings}}</output>
-
-<ask>How would you like to proceed?
-
-1. **Continue** - Work with existing artifacts
-2. **Archive & Start Fresh** - Move old work to archive
-3. **Express Setup** - I know exactly what I need
-4. **Guided Setup** - Walk me through options
-
-Choice [1-4]</ask>
-
-  <check if="choice == 1">
-    <action>Set continuing_existing = true</action>
-    <action>Store found artifacts</action>
-    <action>Continue to step 7 (detect track from artifacts)</action>
-  </check>
-
-  <check if="choice == 2">
-    <ask>Archive existing work? (y/n)</ask>
-    <action if="y">Move artifacts to {planning_artifacts}/archive/</action>
-    <output>Ready for fresh start!</output>
-    <action>Continue to step 3</action>
-  </check>
-
-  <check if="choice == 3">
-    <action>Jump to step 3 (express path)</action>
-  </check>
-
-  <check if="choice == 4">
-    <action>Continue to step 4 (guided path)</action>
-  </check>
-</check>
-
-<check if="state == CLEAN">
-  <ask>Setup approach:
-
-1. **Express** - I know what I need
-2. **Guided** - Show me the options
-
-Choice [1 or 2]:</ask>
-
-  <check if="choice == 1">
-    <action>Continue to step 3 (express)</action>
-  </check>
-
-  <check if="choice == 2">
-    <action>Continue to step 4 (guided)</action>
-  </check>
-</check>
-</step>
-
-<step n="3" goal="Express setup path">
-<ask>Is this for:
-1. **New project** (greenfield)
-2. **Existing codebase** (brownfield)
-
-Choice [1/2]:</ask>
-<action>Set field_type based on choice</action>
-
-<ask>Planning approach:
-
-1. **BMad Method** - Full planning for complex projects
-2. **Enterprise Method** - Extended planning with security/DevOps
-
-Choice [1/2]:</ask>
-<action>Map to selected_track: method/enterprise</action>
-
-<output>🚀 **For Quick Flow (minimal planning, straight to code):**
-Load the **quick-flow-solo-dev** agent instead - use Quick Flow agent for faster development</output>
-
-<template-output>field_type</template-output>
-<template-output>selected_track</template-output>
-<action>Jump to step 6 (discovery options)</action>
-</step>
-
-<step n="4" goal="Guided setup - understand project">
-<ask>Tell me about what you're working on. What's the goal?</ask>
-<action>Store user_description</action>
-
-<action>Analyze for field type indicators:
-
-- Brownfield: "existing", "current", "enhance", "modify"
-- Greenfield: "new", "build", "create", "from scratch"
-- If codebase exists, default to brownfield unless user indicates scaffold
-  </action>
-
-<check if="field_type unclear AND codebase exists">
-  <ask>I see existing code. Are you:
-1. **Modifying** existing codebase (brownfield)
-2. **Starting fresh** - code is just scaffold (greenfield)
-
-Choice [1/2]:</ask>
-<action>Set field_type based on answer</action>
-</check>
-
-<action if="field_type not set">Set based on codebase presence</action>
-
-<action>Check for game development keywords</action>
-<check if="game_detected">
-<output>🎮 **GAME DEVELOPMENT DETECTED**
-
-For game development, install the BMGD module:
-
-```bash
-bmad install bmgd
-```
-
-Continue with software workflows? (y/n)</output>
-<ask>Choice:</ask>
-<action if="n">Exit workflow</action>
-</check>
-
-<template-output>user_description</template-output>
-<template-output>field_type</template-output>
-<action>Continue to step 5</action>
-</step>
-
-<step n="5" goal="Guided setup - select track">
-<output>Based on your project, here are your BMad Method planning options:
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-**1. BMad Method** 🎯 {{#if recommended}}(RECOMMENDED){{/if}}
-
-- Full planning: PRD + UX + Architecture
-- Best for: Products, platforms, complex features
-- Benefit: AI agents have complete context for better results
-
-**2. Enterprise Method** 🏢
-
-- Extended: Method + Security + DevOps + Testing
-- Best for: Enterprise, compliance, mission-critical
-- Benefit: Comprehensive planning for complex systems
-
-**🚀 For Quick Flow (minimal planning, straight to code):**
-Load the **quick-flow-solo-dev** agent instead - use Quick Flow agent for faster development
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-{{#if brownfield}}
-💡 Architecture creates focused solution design from your codebase, keeping AI agents on track.
-{{/if}}</output>
-
-<ask>Which BMad Method approach fits best?
-
-1. BMad Method {{#if recommended}}(recommended){{/if}}
-2. Enterprise Method
-3. Help me decide
-4. Switch to Quick Flow (use quick-flow-solo-dev agent)
-
-Choice [1/2/3/4]:</ask>
-
-<check if="choice == 4">
-  <output>🚀 **Switching to Quick Flow!**
-
-Load the **quick-flow-solo-dev** agent instead:
-
-- Start a new chat
-- Load the quick-flow-solo-dev agent
-- Use Quick Flow for minimal planning and faster development
-
-Quick Flow is perfect for:
-
-- Simple features and bug fixes
-- Rapid prototyping
-- When you want to get straight to code
-
-Happy coding! 🚀</output>
-<action>Exit workflow</action>
-</check>
-
-<check if="choice == 3">
-  <ask>What concerns you about choosing?</ask>
-  <action>Provide tailored guidance based on concerns</action>
-  <action>Loop back to choice</action>
-</check>
-
-<action>Map choice to selected_track</action>
-<template-output>selected_track</template-output>
-</step>
-
-<step n="6" goal="Discovery workflows selection (unified)">
-<action>Determine available discovery workflows based on:
-- field_type (greenfield gets product-brief option)
-- selected_track (method/enterprise options)
-</action>
-
-<check if="field_type == greenfield AND selected_track in [method, enterprise]">
-  <output>Optional discovery workflows can help clarify your vision:</output>
-  <ask>Select any you'd like to include:
-
-1. 🧠 **Brainstorm** - Creative exploration and ideation
-2. 🔍 **Research** - Technical/competitive analysis
-3. 📋 **Product Brief** - Strategic product planning (recommended)
-
-Enter numbers (e.g., "1,3" or "all" or "none"): </ask>
-</check>
-
-<check if="field_type == brownfield AND selected_track in [method, enterprise]">
-  <output>Optional discovery workflows:</output>
-  <ask>Include any of these?
-
-1. 🧠 **Brainstorm** - Creative exploration
-2. 🔍 **Research** - Domain analysis
-
-Enter numbers (e.g., "1,2" or "none"): </ask>
-</check>
-
-<action>Parse selections and set:
-
-- brainstorm_requested
-- research_requested
-- product_brief_requested (if applicable)
-  </action>
-
-<template-output>brainstorm_requested</template-output>
-<template-output>research_requested</template-output>
-<template-output>product_brief_requested</template-output>
-
-<check if="brownfield">
-  <output>💡 **Note:** For brownfield projects, run document-project workflow first to analyze your codebase.</output>
-</check>
-</step>
-
-<step n="7" goal="Detect track from artifacts" if="continuing_existing OR migrating_legacy">
-<action>Analyze artifacts to detect track:
-- Has PRD → BMad Method
-- Has Security/DevOps → Enterprise Method
-- Has tech-spec only → Suggest switching to quick-flow-solo-dev agent
-</action>
-
-<output>Detected: **{{detected_track}}** based on {{found_artifacts}}</output>
-<ask>Correct? (y/n)</ask>
-
-<ask if="n">Which BMad Method track instead?
-
-1. BMad Method
-2. Enterprise Method
-3. Switch to Quick Flow (use quick-flow-solo-dev agent)
-
-Choice:</ask>
-
-<action>Set selected_track</action>
-<template-output>selected_track</template-output>
-</step>
-
-<step n="8" goal="Generate workflow path">
-<action>Load path file: {path_files}/{{selected_track}}-{{field_type}}.yaml</action>
-<action>Build workflow_items from path file</action>
-<action>Scan for existing completed work and update statuses</action>
-<action>Set generated date</action>
-
-<template-output>generated</template-output>
-<template-output>workflow_path_file</template-output>
-<template-output>workflow_items</template-output>
-</step>
-
-<step n="9" goal="Create tracking file">
-<output>Your BMad workflow path:
-
-**Track:** {{selected_track}}
-**Type:** {{field_type}}
-**Project:** {{project_name}}
-
-{{#if brownfield}}Prerequisites: document-project{{/if}}
-{{#if has_discovery}}Discovery: {{list_selected_discovery}}{{/if}}
-
-{{workflow_path_summary}}
-</output>
-
-<ask>Create workflow tracking file? (y/n)</ask>
-
-<check if="y">
-  <action>Generate YAML from template with all variables</action>
-  <action>Save to {planning_artifacts}/bmm-workflow-status.yaml</action>
-  <action>Identify next workflow and agent</action>
-
-<output>✅ **Created:** {planning_artifacts}/bmm-workflow-status.yaml
-
-**Next:** {{next_workflow_name}}
-**Agent:** {{next_agent}}
-**Command:** /bmad:bmm:workflows:{{next_workflow_id}}
-
-{{#if next_agent not in [analyst, pm]}}
-💡 Start new chat with **{{next_agent}}** agent first.
-{{/if}}
-
-To check progress: /bmad:bmm:workflows:workflow-status
-
-Happy building! 🚀</output>
-</check>
-
-</step>
-
-</workflow>

src/bmm/workflows/workflow-status/init/workflow.yaml

@@ -1,30 +0,0 @@
-# Workflow Init - Initial Project Setup
-name: workflow-init
-description: "Initialize a new BMM project by determining level, type, and creating workflow path"
-author: "BMad"
-
-# Critical variables from config
-config_source: "{project-root}/_bmad/bmm/config.yaml"
-output_folder: "{config_source}:output_folder"
-implementation_artifacts: "{config_source}:implementation_artifacts"
-planning_artifacts: "{config_source}:planning_artifacts"
-user_name: "{config_source}:user_name"
-project_name: "{config_source}:project_name"
-communication_language: "{config_source}:communication_language"
-document_output_language: "{config_source}:document_output_language"
-user_skill_level: "{config_source}:user_skill_level"
-date: system-generated
-
-# Workflow components
-installed_path: "{project-root}/_bmad/bmm/workflows/workflow-status/init"
-instructions: "{installed_path}/instructions.md"
-template: "{project-root}/_bmad/bmm/workflows/workflow-status/workflow-status-template.yaml"
-
-# Path data files
-path_files: "{project-root}/_bmad/bmm/workflows/workflow-status/paths/"
-
-# Output configuration
-default_output_file: "{planning_artifacts}/bmm-workflow-status.yaml"
-
-standalone: true
-web_bundle: false

src/bmm/workflows/workflow-status/instructions.md

@@ -1,397 +0,0 @@
-# Workflow Status Check - Multi-Mode Service
-
-<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/workflow-status/workflow.yaml</critical>
-<critical>This workflow operates in multiple modes: interactive (default), validate, data, init-check, update</critical>
-<critical>Other workflows can call this as a service to avoid duplicating status logic</critical>
-<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
-
-<workflow>
-
-<step n="0" goal="Determine execution mode">
-  <action>Check for {{mode}} parameter passed by calling workflow</action>
-  <action>Default mode = "interactive" if not specified</action>
-
-  <check if="mode == interactive">
-    <action>Continue to Step 1 for normal status check flow</action>
-  </check>
-
-  <check if="mode == validate">
-    <action>Jump to Step 10 for workflow validation service</action>
-  </check>
-
-  <check if="mode == data">
-    <action>Jump to Step 20 for data extraction service</action>
-  </check>
-
-  <check if="mode == init-check">
-    <action>Jump to Step 30 for simple init check</action>
-  </check>
-
-  <check if="mode == update">
-    <action>Jump to Step 40 for status update service</action>
-  </check>
-</step>
-
-<step n="1" goal="Check for status file">
-<action>Search {planning_artifacts}/ for file: bmm-workflow-status.yaml</action>
-
-<check if="no status file found">
-  <output>No workflow status found.</output>
-  <ask>Would you like to run Workflow Init now? (y/n)</ask>
-
-  <check if="response == y OR response == yes">
-    <action>Launching workflow-init to set up your project tracking...</action>
-    <invoke-workflow path="{project-root}/_bmad/bmm/workflows/workflow-status/init/workflow.yaml"></invoke-workflow>
-    <action>Exit workflow and let workflow-init take over</action>
-  </check>
-
-  <check if="else">
-    <output>No workflow status file. Run workflow-init when ready to enable progress tracking.</output>
-    <action>Exit workflow</action>
-  </check>
-</check>
-
-<check if="status file found">
-  <action>Continue to step 2</action>
-</check>
-</step>
-
-<step n="2" goal="Read and parse status">
-<action>Read bmm-workflow-status.yaml</action>
-<action>Parse YAML file and extract metadata from comments and fields:</action>
-
-Parse these fields from YAML comments and metadata:
-
-- project (from YAML field)
-- project_type (from YAML field)
-- project_level (from YAML field)
-- field_type (from YAML field)
-- workflow_path (from YAML field)
-
-<action>Parse workflow_status section:</action>
-
-- Extract all workflow entries with their statuses
-- Identify completed workflows (status = file path)
-- Identify pending workflows (status = required/optional/recommended/conditional)
-- Identify skipped workflows (status = skipped)
-
-<action>Determine current state:</action>
-
-- Find first workflow with status != file path and != skipped
-- This is the NEXT workflow to work on
-- Look up agent and command from workflow path file
-  </step>
-
-<step n="3" goal="Display current status and options">
-<action>Load workflow path file based on workflow_path field</action>
-<action>Identify current phase from next workflow to be done</action>
-<action>Build list of completed, pending, and optional workflows</action>
-<action>For each workflow, look up its agent from the path file</action>
-
-<output>
-## 📊 Current Status
-
-**Project:** {{project}} (Level {{project_level}} {{project_type}})
-
-**Path:** {{workflow_path}}
-
-**Progress:**
-
-{{#each phases}}
-{{phase_name}}:
-{{#each workflows_in_phase}}
-
-- {{workflow_name}} ({{agent}}): {{status_display}}
-  {{/each}}
-  {{/each}}
-
-## 🎯 Next Steps
-
-**Next Workflow:** {{next_workflow_name}}
-
-**Agent:** {{next_agent}}
-
-**Command:** /bmad:bmm:workflows:{{next_workflow_id}}
-
-{{#if optional_workflows_available}}
-**Optional Workflows Available:**
-{{#each optional_workflows}}
-
-- {{workflow_name}} ({{agent}}) - {{status}}
-  {{/each}}
-  {{/if}}
-
-**Tip:** For guardrail tests, run TEA `*automate` after `dev-story`. If you lose context, TEA workflows resume from artifacts in `{{output_folder}}`.
-  </output>
-  </step>
-
-<step n="4" goal="Offer actions">
-<ask>What would you like to do?
-
-1. **Start next workflow** - {{next_workflow_name}} ({{next_agent}})
-   {{#if optional_workflows_available}}
-2. **Run optional workflow** - Choose from available options
-   {{/if}}
-3. **View full status YAML** - See complete status file
-4. **Update workflow status** - Mark a workflow as completed or skipped
-5. **Exit** - Return to agent
-
-Your choice:</ask>
-
-<action>Handle user selection based on available options</action>
-
-<check if="choice == 1">
-  <output>Ready to run {{next_workflow_name}}!
-
-**Command:** /bmad:bmm:workflows:{{next_workflow_id}}
-
-**Agent:** Load {{next_agent}} agent first
-
-{{#if next_agent !== current_agent}}
-Tip: Start a new chat and load the {{next_agent}} agent before running this workflow.
-{{/if}}
-</output>
-</check>
-
-<check if="choice == 2 AND optional_workflows_available">
-  <ask>Which optional workflow?
-{{#each optional_workflows numbered}}
-{{number}}. {{workflow_name}} ({{agent}})
-{{/each}}
-
-Your choice:</ask>
-<action>Display selected workflow command and agent</action>
-</check>
-
-<check if="choice == 3">
-  <action>Display complete bmm-workflow-status.yaml file contents</action>
-</check>
-
-<check if="choice == 4">
-  <ask>What would you like to update?
-
-1. Mark a workflow as **completed** (provide file path)
-2. Mark a workflow as **skipped**
-
-Your choice:</ask>
-
-  <check if="update_choice == 1">
-    <ask>Which workflow? (Enter workflow ID like 'prd' or 'create-architecture')</ask>
-    <ask>File path created? (e.g., docs/prd.md)</ask>
-    <critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
-    <action>Update workflow_status in YAML file: {{workflow_id}}: {{file_path}}</action>
-    <action>Save updated YAML file preserving ALL structure and comments</action>
-    <output>✅ Updated {{workflow_id}} to completed: {{file_path}}</output>
-  </check>
-
-  <check if="update_choice == 2">
-    <ask>Which workflow to skip? (Enter workflow ID)</ask>
-    <action>Update workflow_status in YAML file: {{workflow_id}}: skipped</action>
-    <action>Save updated YAML file</action>
-    <output>✅ Marked {{workflow_id}} as skipped</output>
-  </check>
-</check>
-</step>
-
-<!-- ============================================= -->
-<!-- SERVICE MODES - Called by other workflows -->
-<!-- ============================================= -->
-
-<step n="10" goal="Validate mode - Check if calling workflow should proceed">
-<action>Read {planning_artifacts}/bmm-workflow-status.yaml if exists</action>
-
-<check if="status file not found">
-  <template-output>status_exists = false</template-output>
-  <template-output>should_proceed = true</template-output>
-  <template-output>warning = "No status file found. Running without progress tracking."</template-output>
-  <template-output>suggestion = "Consider running workflow-init first for progress tracking"</template-output>
-  <action>Return to calling workflow</action>
-</check>
-
-<check if="status file found">
-  <action>Parse YAML file to extract project metadata and workflow_status</action>
-  <action>Load workflow path file from workflow_path field</action>
-  <action>Find first non-completed workflow in workflow_status (next workflow)</action>
-  <action>Check if {{calling_workflow}} matches next workflow or is in the workflow list</action>
-
-<template-output>status_exists = true</template-output>
-<template-output>project_level = {{project_level}}</template-output>
-<template-output>project_type = {{project_type}}</template-output>
-<template-output>field_type = {{field_type}}</template-output>
-<template-output>next_workflow = {{next_workflow_id}}</template-output>
-
-  <check if="calling_workflow == next_workflow">
-    <template-output>should_proceed = true</template-output>
-    <template-output>warning = ""</template-output>
-    <template-output>suggestion = "Proceeding with planned next step"</template-output>
-  </check>
-
-  <check if="calling_workflow in workflow_status list">
-    <action>Check the status of calling_workflow in YAML</action>
-
-    <check if="status is file path">
-      <template-output>should_proceed = true</template-output>
-      <template-output>warning = "⚠️ Workflow already completed: {{calling_workflow}}"</template-output>
-      <template-output>suggestion = "This workflow was already completed. Re-running will overwrite: {{status}}"</template-output>
-    </check>
-
-    <check if="status is optional/recommended">
-      <template-output>should_proceed = true</template-output>
-      <template-output>warning = "Running optional workflow {{calling_workflow}}"</template-output>
-      <template-output>suggestion = "This is optional. Expected next: {{next_workflow}}"</template-output>
-    </check>
-
-    <check if="status is required but not next">
-      <template-output>should_proceed = true</template-output>
-      <template-output>warning = "⚠️ Out of sequence: Expected {{next_workflow}}, running {{calling_workflow}}"</template-output>
-      <template-output>suggestion = "Consider running {{next_workflow}} instead, or continue if intentional"</template-output>
-    </check>
-
-  </check>
-
-  <check if="calling_workflow NOT in workflow_status list">
-    <template-output>should_proceed = true</template-output>
-    <template-output>warning = "⚠️ Unknown workflow: {{calling_workflow}} not in workflow path"</template-output>
-    <template-output>suggestion = "This workflow is not part of the defined path for this project"</template-output>
-  </check>
-
-<template-output>status_file_path = {{path to bmm-workflow-status.yaml}}</template-output>
-</check>
-
-<action>Return control to calling workflow with all template outputs</action>
-</step>
-
-<step n="20" goal="Data mode - Extract specific information">
-<action>Read {planning_artifacts}/bmm-workflow-status.yaml if exists</action>
-
-<check if="status file not found">
-  <template-output>status_exists = false</template-output>
-  <template-output>error = "No status file to extract data from"</template-output>
-  <action>Return to calling workflow</action>
-</check>
-
-<check if="status file found">
-  <action>Parse YAML file completely</action>
-  <template-output>status_exists = true</template-output>
-
-  <check if="data_request == project_config">
-    <template-output>project_name = {{project}}</template-output>
-    <template-output>project_type = {{project_type}}</template-output>
-    <template-output>project_level = {{project_level}}</template-output>
-    <template-output>field_type = {{field_type}}</template-output>
-    <template-output>workflow_path = {{workflow_path}}</template-output>
-  </check>
-
-  <check if="data_request == workflow_status">
-    <action>Parse workflow_status section and return all workflow: status pairs</action>
-    <template-output>workflow_status = {{workflow_status_object}}</template-output>
-    <action>Calculate completion stats:</action>
-    <template-output>total_workflows = {{count all workflows}}</template-output>
-    <template-output>completed_workflows = {{count file path statuses}}</template-output>
-    <template-output>pending_workflows = {{count required/optional/etc}}</template-output>
-    <template-output>skipped_workflows = {{count skipped}}</template-output>
-  </check>
-
-  <check if="data_request == all">
-    <action>Return all parsed fields as template outputs</action>
-    <template-output>project = {{project}}</template-output>
-    <template-output>project_type = {{project_type}}</template-output>
-    <template-output>project_level = {{project_level}}</template-output>
-    <template-output>field_type = {{field_type}}</template-output>
-    <template-output>workflow_path = {{workflow_path}}</template-output>
-    <template-output>workflow_status = {{workflow_status_object}}</template-output>
-    <template-output>generated = {{generated}}</template-output>
-  </check>
-
-<template-output>status_file_path = {{path to bmm-workflow-status.yaml}}</template-output>
-</check>
-
-<action>Return control to calling workflow with requested data</action>
-</step>
-
-<step n="30" goal="Init-check mode - Simple existence check">
-<action>Check if {planning_artifacts}/bmm-workflow-status.yaml exists</action>
-
-<check if="exists">
-  <template-output>status_exists = true</template-output>
-  <template-output>suggestion = "Status file found. Ready to proceed."</template-output>
-</check>
-
-<check if="not exists">
-  <template-output>status_exists = false</template-output>
-  <template-output>suggestion = "No status file. Run workflow-init to create one (optional for progress tracking)"</template-output>
-</check>
-
-<action>Return immediately to calling workflow</action>
-</step>
-
-<step n="40" goal="Update mode - Centralized status file updates">
-<action>Read {planning_artifacts}/bmm-workflow-status.yaml</action>
-
-<check if="status file not found">
-  <template-output>success = false</template-output>
-  <template-output>error = "No status file found. Cannot update."</template-output>
-  <action>Return to calling workflow</action>
-</check>
-
-<check if="status file found">
-  <action>Parse YAML file completely</action>
-  <action>Load workflow path file from workflow_path field</action>
-  <action>Check {{action}} parameter to determine update type</action>
-
-  <!-- ============================================= -->
-  <!-- ACTION: complete_workflow -->
-  <!-- ============================================= -->
-  <check if="action == complete_workflow">
-    <action>Get {{workflow_id}} parameter (required)</action>
-    <action>Get {{default_output_file}} parameter (required - path to created file)</action>
-
-    <critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
-    <action>Update workflow status in YAML:</action>
-    - In workflow_status section, update: {{workflow_id}}: {{default_output_file}}
-
-    <action>Find {{workflow_id}} in loaded path YAML</action>
-    <action>Determine next workflow from path sequence</action>
-    <action>Find first workflow in workflow_status with status != file path and != skipped</action>
-
-    <action>Save updated YAML file preserving ALL structure and comments</action>
-
-    <template-output>success = true</template-output>
-    <template-output>next_workflow = {{determined next workflow}}</template-output>
-    <template-output>next_agent = {{determined next agent from path file}}</template-output>
-    <template-output>completed_workflow = {{workflow_id}}</template-output>
-    <template-output>default_output_file = {{default_output_file}}</template-output>
-
-  </check>
-
-  <!-- ============================================= -->
-  <!-- ACTION: skip_workflow -->
-  <!-- ============================================= -->
-  <check if="action == skip_workflow">
-    <action>Get {{workflow_id}} parameter (required)</action>
-
-    <action>Update workflow status in YAML:</action>
-    - In workflow_status section, update: {{workflow_id}}: skipped
-
-    <action>Save updated YAML file</action>
-
-    <template-output>success = true</template-output>
-    <template-output>skipped_workflow = {{workflow_id}}</template-output>
-
-  </check>
-
-  <!-- ============================================= -->
-  <!-- Unknown action -->
-  <!-- ============================================= -->
-  <check if="action not recognized">
-    <template-output>success = false</template-output>
-    <template-output>error = "Unknown action: {{action}}. Valid actions: complete_workflow, skip_workflow"</template-output>
-  </check>
-
-</check>
-
-<action>Return control to calling workflow with template outputs</action>
-</step>
-
-</workflow>

src/bmm/workflows/workflow-status/paths/enterprise-brownfield.yaml

@@ -1,103 +0,0 @@
-# BMad Enterprise Method - Brownfield
-# Extended enterprise planning for complex brownfield with security/devops/test (30+ stories typically)
-
-method_name: "BMad Enterprise Method"
-track: "enterprise-bmad-method"
-field_type: "brownfield"
-description: "Enterprise-grade planning for complex brownfield additions with extended requirements"
-
-phases:
-  - phase: 0
-    name: "Documentation"
-    conditional: "if_undocumented"
-    note: "Prerequisite for brownfield without docs"
-    workflows:
-      - id: "document-project"
-        required: true
-        workflow: "{project-root}/_bmad/bmm/workflows/document-project/workflow.yaml"
-        agent: "analyst"
-        command: "/bmad:bmm:workflows:document-project"
-        output: "Comprehensive project documentation"
-        purpose: "Understand existing codebase before planning"
-  - phase: 1
-    name: "Analysis (Optional)"
-    optional: true
-    note: "User-selected during workflow-init"
-    workflows:
-      - id: "brainstorm-project"
-        exec: "{project-root}/_bmad/core/workflows/brainstorming/workflow.md"
-        optional: true
-        agent: "analyst"
-        command: "/bmad:bmm:workflows:brainstorming"
-        included_by: "user_choice"
-        note: "Uses core brainstorming workflow with project context template"
-      - id: "research"
-        exec: "{project-root}/_bmad/bmm/workflows/1-analysis/research/workflow.md"
-        optional: true
-        agent: "analyst"
-        command: "/bmad:bmm:workflows:research"
-        included_by: "user_choice"
-        note: "Can have multiple research workflows"
-      - id: "product-brief"
-        exec: "{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brief/workflow.md"
-        optional: true
-        agent: "analyst"
-        command: "/bmad:bmm:workflows:create-product-brief"
-        included_by: "user_choice"
-        note: "Recommended for greenfield Method projects"
-  - phase: 2
-    name: "Planning"
-    required: true
-    workflows:
-      - id: "prd"
-        exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/workflow.md"
-        required: true
-        agent: "pm"
-        command: "/bmad:bmm:workflows:create-prd"
-        output: "Product Requirements Document with FRs and NFRs"
-      - id: "create-ux-design"
-        conditional: "if_has_ui"
-        exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-ux-design/workflow.md"
-        agent: "ux-designer"
-        command: "/bmad:bmm:workflows:create-ux-design"
-        note: "Determined after PRD - user/agent decides if needed"
-  - phase: 3
-    name: "Solutioning"
-    required: true
-    workflows:
-      - id: "create-architecture"
-        required: true
-        exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/workflow.md"
-        agent: "architect"
-        command: "/bmad:bmm:workflows:create-architecture"
-        output: "System architecture document"
-        note: "Complete system design for greenfield projects"
-      - id: "create-epics-and-stories"
-        required: true
-        exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/create-epics-and-stories/workflow.md"
-        agent: "pm"
-        command: "/bmad:bmm:workflows:create-epics-and-stories"
-        note: "Required: Break down PRD into implementable epics and stories with full context (PRD + UX + Architecture)"
-      - id: "test-design"
-        optional: true
-        workflow: "{project-root}/_bmad/bmm/workflows/testarch/test-design/workflow.yaml"
-        agent: "tea"
-        command: "/bmad:bmm:workflows:test-design"
-        output: "System-level testability review"
-        note: "Testability assessment before gate check - auto-detects system-level mode"
-      - id: "implementation-readiness"
-        required: true
-        exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/check-implementation-readiness/workflow.md"
-        agent: "architect"
-        command: "/bmad:bmm:workflows:implementation-readiness"
-        note: "Validates PRD + Architecture + Epics + UX (optional)"
-  - phase: 4
-    name: "Implementation"
-    required: true
-    workflows:
-      - id: "sprint-planning"
-        required: true
-        workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/sprint-planning/workflow.yaml"
-        agent: "sm"
-        command: "/bmad:bmm:workflows:sprint-planning"
-        note: "Creates sprint plan - subsequent work tracked there"

src/bmm/workflows/workflow-status/paths/enterprise-greenfield.yaml

@@ -1,100 +0,0 @@
-# BMad Enterprise Method - Greenfield
-# Extended enterprise planning with security/devops/test for greenfield (30+ stories typically)
-
-method_name: "Enterprise BMad Method"
-track: "enterprise-bmad-method"
-field_type: "greenfield"
-description: "Complete enterprise-grade planning with security, devops, and test strategy"
-
-phases:
-  - phase: 1
-    name: "Analysis (Optional)"
-    optional: true
-    note: "User-selected during workflow-init"
-    workflows:
-      - id: "brainstorm-project"
-        exec: "{project-root}/_bmad/core/workflows/brainstorming/workflow.md"
-        optional: true
-        agent: "analyst"
-        command: "/bmad:bmm:workflows:brainstorming"
-        included_by: "user_choice"
-        note: "Uses core brainstorming workflow with project context template"
-
-      - id: "research"
-        exec: "{project-root}/_bmad/bmm/workflows/1-analysis/research/workflow.md"
-        optional: true
-        agent: "analyst"
-        command: "/bmad:bmm:workflows:research"
-        included_by: "user_choice"
-        note: "Can have multiple research workflows"
-
-      - id: "product-brief"
-        exec: "{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brief/workflow.md"
-        optional: true
-        agent: "analyst"
-        command: "/bmad:bmm:workflows:create-product-brief"
-        included_by: "user_choice"
-        note: "Recommended for greenfield Method projects"
-
-  - phase: 2
-    name: "Planning"
-    required: true
-    workflows:
-      - id: "prd"
-        exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/workflow.md"
-        required: true
-        agent: "pm"
-        command: "/bmad:bmm:workflows:create-prd"
-        output: "Product Requirements Document with FRs and NFRs"
-
-      - id: "create-ux-design"
-        conditional: "if_has_ui"
-        exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-ux-design/workflow.md"
-        agent: "ux-designer"
-        command: "/bmad:bmm:workflows:create-ux-design"
-        note: "Determined after PRD - user/agent decides if needed"
-
-  - phase: 3
-    name: "Solutioning"
-    required: true
-    workflows:
-      - id: "create-architecture"
-        required: true
-        exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/workflow.md"
-        agent: "architect"
-        command: "/bmad:bmm:workflows:create-architecture"
-        output: "System architecture document"
-        note: "Complete system design for greenfield projects"
-
-      - id: "create-epics-and-stories"
-        required: true
-        exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/create-epics-and-stories/workflow.md"
-        agent: "pm"
-        command: "/bmad:bmm:workflows:create-epics-and-stories"
-        note: "Required: Break down PRD into implementable epics and stories with full context (PRD + UX + Architecture)"
-
-      - id: "test-design"
-        optional: true
-        workflow: "{project-root}/_bmad/bmm/workflows/testarch/test-design/workflow.yaml"
-        agent: "tea"
-        command: "/bmad:bmm:workflows:test-design"
-        output: "System-level testability review"
-        note: "Testability assessment before gate check - auto-detects system-level mode"
-
-      - id: "implementation-readiness"
-        required: true
-        exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/check-implementation-readiness/workflow.md"
-        agent: "architect"
-        command: "/bmad:bmm:workflows:implementation-readiness"
-        note: "Validates PRD + Architecture + Epics + UX (optional)"
-
-  - phase: 4
-    name: "Implementation"
-    required: true
-    workflows:
-      - id: "sprint-planning"
-        required: true
-        workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/sprint-planning/workflow.yaml"
-        agent: "sm"
-        command: "/bmad:bmm:workflows:sprint-planning"
-        note: "Creates sprint plan - subsequent work tracked there"

src/bmm/workflows/workflow-status/paths/method-brownfield.yaml

@@ -1,103 +0,0 @@
-# BMad Method - Brownfield
-# Full product + architecture planning for complex brownfield additions (10-50+ stories typically)
-
-method_name: "BMad Method"
-track: "bmad-method"
-field_type: "brownfield"
-description: "Complete product and system design for complex brownfield work"
-
-phases:
-  - phase: 0
-    name: "Documentation"
-    conditional: "if_undocumented"
-    note: "Prerequisite for brownfield without docs"
-    workflows:
-      - id: "document-project"
-        required: true
-        workflow: "{project-root}/_bmad/bmm/workflows/document-project/workflow.yaml"
-        agent: "analyst"
-        command: "/bmad:bmm:workflows:document-project"
-        output: "Comprehensive project documentation"
-        purpose: "Understand existing codebase before planning"
-  - phase: 1
-    name: "Analysis (Optional)"
-    optional: true
-    note: "User-selected during workflow-init"
-    workflows:
-      - id: "brainstorm-project"
-        exec: "{project-root}/_bmad/core/workflows/brainstorming/workflow.md"
-        optional: true
-        agent: "analyst"
-        command: "/bmad:bmm:workflows:brainstorming"
-        included_by: "user_choice"
-        note: "Uses core brainstorming workflow with project context template"
-      - id: "research"
-        exec: "{project-root}/_bmad/bmm/workflows/1-analysis/research/workflow.md"
-        optional: true
-        agent: "analyst"
-        command: "/bmad:bmm:workflows:research"
-        included_by: "user_choice"
-        note: "Can have multiple research workflows"
-      - id: "product-brief"
-        exec: "{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brief/workflow.md"
-        optional: true
-        agent: "analyst"
-        command: "/bmad:bmm:workflows:create-product-brief"
-        included_by: "user_choice"
-        note: "Recommended for greenfield Method projects"
-  - phase: 2
-    name: "Planning"
-    required: true
-    workflows:
-      - id: "prd"
-        exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/workflow.md"
-        required: true
-        agent: "pm"
-        command: "/bmad:bmm:workflows:create-prd"
-        output: "Product Requirements Document with FRs and NFRs"
-      - id: "create-ux-design"
-        conditional: "if_has_ui"
-        exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-ux-design/workflow.md"
-        agent: "ux-designer"
-        command: "/bmad:bmm:workflows:create-ux-design"
-        note: "Determined after PRD - user/agent decides if needed"
-  - phase: 3
-    name: "Solutioning"
-    required: true
-    workflows:
-      - id: "create-architecture"
-        required: true
-        exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/workflow.md"
-        agent: "architect"
-        command: "/bmad:bmm:workflows:create-architecture"
-        output: "System architecture document"
-        note: "Complete system design for greenfield projects"
-      - id: "create-epics-and-stories"
-        required: true
-        exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/create-epics-and-stories/workflow.md"
-        agent: "pm"
-        command: "/bmad:bmm:workflows:create-epics-and-stories"
-        note: "Required: Break down PRD into implementable epics and stories with full context (PRD + UX + Architecture)"
-      - id: "test-design"
-        optional: true
-        workflow: "{project-root}/_bmad/bmm/workflows/testarch/test-design/workflow.yaml"
-        agent: "tea"
-        command: "/bmad:bmm:workflows:test-design"
-        output: "System-level testability review"
-        note: "Testability assessment before gate check - auto-detects system-level mode"
-      - id: "implementation-readiness"
-        required: true
-        exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/check-implementation-readiness/workflow.md"
-        agent: "architect"
-        command: "/bmad:bmm:workflows:implementation-readiness"
-        note: "Validates PRD + Architecture + Epics + UX (optional)"
-  - phase: 4
-    name: "Implementation"
-    required: true
-    workflows:
-      - id: "sprint-planning"
-        required: true
-        workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/sprint-planning/workflow.yaml"
-        agent: "sm"
-        command: "/bmad:bmm:workflows:sprint-planning"
-        note: "Creates sprint plan - subsequent work tracked there"

src/bmm/workflows/workflow-status/paths/method-greenfield.yaml

@@ -1,100 +0,0 @@
-# BMad Method - Greenfield
-# Full product + architecture planning for greenfield projects (10-50+ stories typically)
-
-method_name: "BMad Method"
-track: "bmad-method"
-field_type: "greenfield"
-description: "Complete product and system design methodology for greenfield projects"
-
-phases:
-  - phase: 1
-    name: "Analysis (Optional)"
-    optional: true
-    note: "User-selected during workflow-init"
-    workflows:
-      - id: "brainstorm-project"
-        exec: "{project-root}/_bmad/core/workflows/brainstorming/workflow.md"
-        optional: true
-        agent: "analyst"
-        command: "/bmad:bmm:workflows:brainstorming"
-        included_by: "user_choice"
-        note: "Uses core brainstorming workflow with project context template"
-
-      - id: "research"
-        exec: "{project-root}/_bmad/bmm/workflows/1-analysis/research/workflow.md"
-        optional: true
-        agent: "analyst"
-        command: "/bmad:bmm:workflows:research"
-        included_by: "user_choice"
-        note: "Can have multiple research workflows"
-
-      - id: "product-brief"
-        exec: "{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brief/workflow.md"
-        optional: true
-        agent: "analyst"
-        command: "/bmad:bmm:workflows:create-product-brief"
-        included_by: "user_choice"
-        note: "Recommended for greenfield Method projects"
-
-  - phase: 2
-    name: "Planning"
-    required: true
-    workflows:
-      - id: "prd"
-        exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/workflow.md"
-        required: true
-        agent: "pm"
-        command: "/bmad:bmm:workflows:create-prd"
-        output: "Product Requirements Document with FRs and NFRs"
-
-      - id: "create-ux-design"
-        conditional: "if_has_ui"
-        exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-ux-design/workflow.md"
-        agent: "ux-designer"
-        command: "/bmad:bmm:workflows:create-ux-design"
-        note: "Determined after PRD - user/agent decides if needed"
-
-  - phase: 3
-    name: "Solutioning"
-    required: true
-    workflows:
-      - id: "create-architecture"
-        required: true
-        exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/workflow.md"
-        agent: "architect"
-        command: "/bmad:bmm:workflows:create-architecture"
-        output: "System architecture document"
-        note: "Complete system design for greenfield projects"
-
-      - id: "create-epics-and-stories"
-        required: true
-        exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/create-epics-and-stories/workflow.md"
-        agent: "pm"
-        command: "/bmad:bmm:workflows:create-epics-and-stories"
-        note: "Required: Break down PRD into implementable epics and stories with full context (PRD + UX + Architecture)"
-
-      - id: "test-design"
-        optional: true
-        workflow: "{project-root}/_bmad/bmm/workflows/testarch/test-design/workflow.yaml"
-        agent: "tea"
-        command: "/bmad:bmm:workflows:test-design"
-        output: "System-level testability review"
-        note: "Testability assessment before gate check - auto-detects system-level mode"
-
-      - id: "implementation-readiness"
-        required: true
-        exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/check-implementation-readiness/workflow.md"
-        agent: "architect"
-        command: "/bmad:bmm:workflows:implementation-readiness"
-        note: "Validates PRD + Architecture + Epics + UX (optional)"
-
-  - phase: 4
-    name: "Implementation"
-    required: true
-    workflows:
-      - id: "sprint-planning"
-        required: true
-        workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/sprint-planning/workflow.yaml"
-        agent: "sm"
-        command: "/bmad:bmm:workflows:sprint-planning"
-        note: "Creates sprint plan - subsequent work tracked there"

src/bmm/workflows/workflow-status/workflow-status-template.yaml

@@ -1,24 +0,0 @@
-# Workflow Status Template
-
-# This tracks progress through BMM methodology Analysis, Planning, and Solutioning phases.
-# Implementation phase is tracked separately in sprint-status.yaml
-
-# STATUS DEFINITIONS:
-# ==================
-# Initial Status (before completion):
-#   - required: Must be completed to progress
-#   - optional: Can be completed but not required
-#   - recommended: Strongly suggested but not required
-#   - conditional: Required only if certain conditions met (e.g., if_has_ui)
-#
-# Completion Status:
-#   - {file-path}: File created/found (e.g., "docs/product-brief.md")
-#   - skipped: Optional/conditional workflow that was skipped
-
-generated: "{{generated}}"
-project: "{{project_name}}"
-project_type: "{{project_type}}"
-selected_track: "{{selected_track}}"
-field_type: "{{field_type}}"
-workflow_path: "{{workflow_path_file}}"
-workflow_status: "{{workflow_items}}"

src/bmm/workflows/workflow-status/workflow.yaml

@@ -1,32 +0,0 @@
-# Workflow Status - Master Router and Status Tracker
-name: workflow-status
-description: 'Lightweight status checker - answers "what should I do now?" for any agent. Reads YAML status file for workflow tracking. Use workflow-init for new projects.'
-author: "BMad"
-
-# Critical variables from config
-config_source: "{project-root}/_bmad/bmm/config.yaml"
-output_folder: "{config_source}:output_folder"
-planning_artifacts: "{config_source}:planning_artifacts"
-implementation_artifacts: "{config_source}:implementation_artifacts"
-user_name: "{config_source}:user_name"
-communication_language: "{config_source}:communication_language"
-document_output_language: "{config_source}:document_output_language"
-user_skill_level: "{config_source}:user_skill_level"
-date: system-generated
-
-# Workflow components
-installed_path: "{project-root}/_bmad/bmm/workflows/workflow-status"
-instructions: "{installed_path}/instructions.md"
-
-# Template for status file creation (used by workflow-init)
-template: "{installed_path}/workflow-status-template.yaml"
-
-# Path definitions for project types
-path_files: "{installed_path}/paths/"
-
-# Output configuration - reads existing status
-default_output_file: "{planning_artifacts}/bmm-workflow-status.yaml"
-
-standalone: true
-
-web_bundle: false

src/core/module-help.csv

@@ -0,0 +1,11 @@
+module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs
+core,,Advanced Elicitation,AE,10,_bmad/core/workflows/advanced-elicitation/workflow.xml,bmad:advanced-elicitation,false,,,"Apply elicitation methods iteratively to enhance content being generated, presenting options and allowing reshuffle or full method listing for comprehensive content improvement",,
+core,,Brainstorming,BS,20,_bmad/core/workflows/brainstorming/workflow.md,bmad:brainstorming,false,analyst,,Facilitate interactive brainstorming sessions using diverse creative techniques and ideation methods,{output_folder}/brainstorming/brainstorming-session-{{date}}.md,,
+core,,Party Mode,PM,30,_bmad/core/workflows/party-mode/workflow.md,bmad:party-mode,false,party-mode facilitator,,Orchestrates group discussions between all installed BMAD agents enabling natural multi-agent conversations,,
+core,,bmad-help,BH,40,_bmad/core/tasks/bmad-help.md,bmad:help,false,system,,Get unstuck by showing what workflow steps come next or answering questions about what to do in the BMad Method,,
+core,,Index Docs,ID,50,_bmad/core/tasks/index-docs.xml,bmad:index-docs,false,llm,,Generates or updates an index.md of all documents in the specified directory,,
+core,,Execute Workflow,WF,60,_bmad/core/tasks/workflow.xml,bmad:workflow,false,llm,,Execute given workflow by loading its configuration following instructions and producing output,,
+core,,Shard Document,SD,70,_bmad/core/tasks/shard-doc.xml,bmad:shard-doc,false,llm,,Splits large markdown documents into smaller organized files based on level 2 sections,,
+core,,Editorial Review - Prose,EP,80,_bmad/core/tasks/editorial-review-prose.xml,bmad:editorial-review-prose,false,llm,reader_type,Clinical copy-editor that reviews text for communication issues,,"three-column markdown table with suggested fixes",
+core,,Editorial Review - Structure,ES,90,_bmad/core/tasks/editorial-review-structure.xml,bmad:editorial-review-structure,false,llm,,Structural editor that proposes cuts reorganization and simplification while preserving comprehension,,
+core,,Adversarial Review (General),AR,100,_bmad/core/tasks/review-adversarial-general.xml,bmad:review-adversarial-general,false,llm,,Cynically review content and produce findings,,

src/core/tasks/bmad-help.md

@@ -0,0 +1,62 @@
+---
+name: bmad-help
+description: Get unstuck by showing what workflow steps come next or answering questions about what to do
+standalone: true
+---
+
+# Task: BMAD Help
+
+## KEY RULES
+
+- **Empty `phase` = anytime** — Universal tools work regardless of workflow state
+- **Numbered phases indicate sequence** — Phases like `1-discover` → `2-define` → `3-build` → `4-ship` flow in order (naming varies by module)
+- **Stay in module** — Guide through the active module's workflow based on phase+sequence ordering
+- **Descriptions contain routing** — Read for alternate paths (e.g., "back to previous if fixes needed")
+- **`required=true` blocks progress** — Required workflows must complete before proceeding to later phases
+- **Artifacts reveal completion** — Search resolved output paths for `outputs` patterns, fuzzy-match found files to workflow rows
+
+## MODULE DETECTION
+
+- **Empty `module` column** → universal tools (work across all modules)
+- **Named `module`** → module-specific workflows
+
+Detect the active module from conversation context, recent workflows, or user query keywords. If ambiguous, ask the user.
+
+## INPUT ANALYSIS
+
+Determine what was just completed:
+- Did someone state they completed something? Proceed as if that was the input.
+- Was a workflow just completed in this conversation? Proceed as if that was the input.
+- Search resolved artifact locations for files; fuzzy-match to workflow `outputs` patterns.
+- If an `index.md` exists, read it for additional context.
+- If still unclear, ask: "What workflow did you most recently complete?"
+
+## EXECUTION
+
+1. **Load catalog** — Load `{project-root}/_bmad/_config/bmad-help.csv`
+
+2. **Resolve output locations** — Scan each folder under `_bmad/` (except `_config`) for `config.yaml`. For each workflow row, resolve its `output-location` variables against that module's config so artifact paths can be searched.
+
+3. **Analyze input** — Task may provide a workflow name/code, conversational phrase, or nothing. Infer what was just completed using INPUT ANALYSIS above.
+
+4. **Detect active module** — Use MODULE DETECTION above to determine which module the user is working in.
+
+5. **Present recommendations** — Show next steps based on completed workflows, phase/sequence ordering (KEY RULES), and artifact detection. Format per the following
+
+## RECOMMENDED OUTPUT FORMAT
+
+   **Optional items first** — List optional workflows until a required step is reached
+   **Required items next** — List the next required workflow
+   For each item show:
+   - Workflow **name**
+   - **Command** (prefixed with `/`, e.g., `/bmad:example:build-prototype`)
+   - **Agent** title and display name from the CSV (e.g., "🎨 Alex (Designer)")
+   - Brief **description**
+
+   ### Additional response output guidance to convey:
+   - Run each workflow in a **fresh context window**
+   - Load the agent using (`/` + `agent-command`), or run the workflow command directly
+   - For **validation workflows**: recommend using a different high-quality LLM if available
+   - For conversational requests: match the user's tone while presenting clearly
+
+6. Return to the calling process after presenting recommendations.

src/core/workflows/brainstorming/steps/step-01-session-setup.md

@@ -33,7 +33,7 @@ Initialize the brainstorming workflow by detecting continuation state and settin
 
 First, check if the output document already exists:
 
-- Look for file at `{output_folder}/analysis/brainstorming-session-{{date}}.md`
+- Look for file at `{output_folder}/brainstorming/brainstorming-session-{{date}}.md`
 - If exists, read the complete file including frontmatter
 - If not exists, this is a fresh workflow
 
@@ -55,10 +55,10 @@ Create the brainstorming session document:
 
 ```bash
 # Create directory if needed
-mkdir -p "$(dirname "{output_folder}/analysis/brainstorming-session-{{date}}.md")"
+mkdir -p "$(dirname "{output_folder}/brainstorming/brainstorming-session-{{date}}.md")"
 
 # Initialize from template
-cp "{template_path}" "{output_folder}/analysis/brainstorming-session-{{date}}.md"
+cp "{template_path}" "{output_folder}/brainstorming/brainstorming-session-{{date}}.md"
 ```
 
 #### B. Context File Check and Loading
@@ -134,7 +134,7 @@ _[Content based on conversation about session parameters and facilitator approac
 
 ## APPEND TO DOCUMENT:
 
-When user selects approach, append the session overview content directly to `{output_folder}/analysis/brainstorming-session-{{date}}.md` using the structure from above.
+When user selects approach, append the session overview content directly to `{output_folder}/brainstorming/brainstorming-session-{{date}}.md` using the structure from above.
 
 ### E. Continue to Technique Selection
 
@@ -152,7 +152,7 @@ Which approach appeals to you most? (Enter 1-4)"
 
 #### When user selects approach number:
 
-- **Append initial session overview to `{output_folder}/analysis/brainstorming-session-{{date}}.md`**
+- **Append initial session overview to `{output_folder}/brainstorming/brainstorming-session-{{date}}.md`**
 - **Update frontmatter:** `stepsCompleted: [1]`, `selected_approach: '[selected approach]'`
 - **Load the appropriate step-02 file** based on selection
 

src/core/workflows/brainstorming/steps/step-01b-continue.md

@@ -35,7 +35,7 @@ Load existing document and analyze current state:
 
 **Document Analysis:**
 
-- Read existing `{output_folder}/analysis/brainstorming-session-{{date}}.md`
+- Read existing `{output_folder}/brainstorming/brainstorming-session-{{date}}.md`
 - Examine frontmatter for `stepsCompleted`, `session_topic`, `session_goals`
 - Review content to understand session progress and outcomes
 - Identify current stage and next logical steps

src/core/workflows/brainstorming/steps/step-03-technique-execution.md

@@ -296,7 +296,7 @@ After final technique element:
 
 #### If 'C' (Move to organization):
 
-- **Append the technique execution content to `{output_folder}/analysis/brainstorming-session-{{date}}.md`**
+- **Append the technique execution content to `{output_folder}/brainstorming/brainstorming-session-{{date}}.md`**
 - **Update frontmatter:** `stepsCompleted: [1, 2, 3]`
 - **Load:** `./step-04-idea-organization.md`
 
@@ -356,7 +356,7 @@ _[Short narrative describing the user and AI collaboration journey - what made t
 
 ## APPEND TO DOCUMENT:
 
-When user selects 'C', append the content directly to `{output_folder}/analysis/brainstorming-session-{{date}}.md` using the structure from above.
+When user selects 'C', append the content directly to `{output_folder}/brainstorming/brainstorming-session-{{date}}.md` using the structure from above.
 
 ## SUCCESS METRICS:
 

src/core/workflows/brainstorming/steps/step-04-idea-organization.md

@@ -253,14 +253,14 @@ Provide final session wrap-up and forward guidance:
 
 #### If [C] Complete:
 
-- **Append the final session content to `{output_folder}/analysis/brainstorming-session-{{date}}.md`**
+- **Append the final session content to `{output_folder}/brainstorming/brainstorming-session-{{date}}.md`**
 - Update frontmatter: `stepsCompleted: [1, 2, 3, 4]`
 - Set `session_active: false` and `workflow_completed: true`
 - Complete workflow with positive closure message
 
 ## APPEND TO DOCUMENT:
 
-When user selects 'C', append the content directly to `{output_folder}/analysis/brainstorming-session-{{date}}.md` using the structure from step 7.
+When user selects 'C', append the content directly to `{output_folder}/brainstorming/brainstorming-session-{{date}}.md` using the structure from step 7.
 
 ## SUCCESS METRICS:
 

src/core/workflows/brainstorming/workflow.md

@@ -45,7 +45,7 @@ Load config from `{project-root}/_bmad/core/config.yaml` and resolve:
 - `installed_path` = `{project-root}/_bmad/core/workflows/brainstorming`
 - `template_path` = `{installed_path}/template.md`
 - `brain_techniques_path` = `{installed_path}/brain-methods.csv`
-- `default_output_file` = `{output_folder}/analysis/brainstorming-session-{{date}}.md`
+- `default_output_file` = `{output_folder}/brainstorming/brainstorming-session-{{date}}.md`
 - `context_file` = Optional context file path from workflow invocation for project-specific guidance
 - `advancedElicitationTask` = `{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml`
 

test/fixtures/agent-schema/valid/menu-triggers/compound-triggers.agent.yaml

@@ -23,9 +23,9 @@ agent:
     - trigger: DS or fuzzy match on dev-story
       description: "[DS] Another two-word compound trigger"
       action: dev_story
-    - trigger: WI or fuzzy match on workflow-init-process
+    - trigger: WI or fuzzy match on three-name-thing
       description: "[WI] Three-word compound trigger (uses first 2 words for shortcut)"
-      action: workflow_init
+      action: three_name_thing
     - trigger: H or fuzzy match on help
       description: "[H] Single-word compound trigger (1-letter shortcut)"
       action: help

tools/cli/installers/lib/core/installer.js

@@ -975,6 +975,7 @@ class Installer {
       this.installedFiles.add(path.join(cfgDir, 'task-manifest.csv'));
 
       // Generate CSV manifests for workflows, agents, tasks AND ALL FILES with hashes BEFORE IDE setup
+      // This must happen BEFORE mergeModuleHelpCatalogs because it depends on agent-manifest.csv
       spinner.start('Generating workflow and agent manifests...');
       const manifestGen = new ManifestGenerator();
 
@@ -1007,6 +1008,12 @@ class Installer {
         `Manifests generated: ${manifestStats.workflows} workflows, ${manifestStats.agents} agents, ${manifestStats.tasks} tasks, ${manifestStats.tools} tools, ${manifestStats.files} files`,
       );
 
+      // Merge all module-help.csv files into bmad-help.csv
+      // This must happen AFTER generateManifests because it depends on agent-manifest.csv
+      spinner.start('Generating workflow help catalog...');
+      await this.mergeModuleHelpCatalogs(bmadDir);
+      spinner.succeed('Workflow help catalog generated');
+
       // Configure IDEs and copy documentation
       if (!config.skipIde && config.ides && config.ides.length > 0) {
         // Filter out any undefined/null values from the IDE list
@@ -1367,6 +1374,240 @@ class Installer {
   /**
    * Private: Create directory structure
    */
+  /**
+   * Merge all module-help.csv files into a single bmad-help.csv
+   * Scans all installed modules for module-help.csv and merges them
+   * Enriches agent info from agent-manifest.csv
+   * Output is written to _bmad/_config/bmad-help.csv
+   * @param {string} bmadDir - BMAD installation directory
+   */
+  async mergeModuleHelpCatalogs(bmadDir) {
+    const allRows = [];
+    const headerRow =
+      'module,phase,name,code,sequence,workflow-file,command,required,agent-name,agent-command,agent-display-name,agent-title,options,description,output-location,outputs';
+
+    // Load agent manifest for agent info lookup
+    const agentManifestPath = path.join(bmadDir, '_config', 'agent-manifest.csv');
+    const agentInfo = new Map(); // agent-name -> {command, displayName, title+icon}
+
+    if (await fs.pathExists(agentManifestPath)) {
+      const manifestContent = await fs.readFile(agentManifestPath, 'utf8');
+      const lines = manifestContent.split('\n').filter((line) => line.trim());
+
+      for (const line of lines) {
+        if (line.startsWith('name,')) continue; // Skip header
+
+        const cols = line.split(',');
+        if (cols.length >= 4) {
+          const agentName = cols[0].replaceAll('"', '').trim();
+          const displayName = cols[1].replaceAll('"', '').trim();
+          const title = cols[2].replaceAll('"', '').trim();
+          const icon = cols[3].replaceAll('"', '').trim();
+          const module = cols[10] ? cols[10].replaceAll('"', '').trim() : '';
+
+          // Build agent command: bmad:module:agent:name
+          const agentCommand = module ? `bmad:${module}:agent:${agentName}` : `bmad:agent:${agentName}`;
+
+          agentInfo.set(agentName, {
+            command: agentCommand,
+            displayName: displayName || agentName,
+            title: icon && title ? `${icon} ${title}` : title || agentName,
+          });
+        }
+      }
+    }
+
+    // Get all installed module directories
+    const entries = await fs.readdir(bmadDir, { withFileTypes: true });
+    const installedModules = entries
+      .filter((entry) => entry.isDirectory() && entry.name !== '_config' && entry.name !== 'docs' && entry.name !== '_memory')
+      .map((entry) => entry.name);
+
+    // Add core module to scan (it's installed at root level as _config, but we check src/core)
+    const coreModulePath = getSourcePath('core');
+    const modulePaths = new Map();
+
+    // Map all module source paths
+    if (await fs.pathExists(coreModulePath)) {
+      modulePaths.set('core', coreModulePath);
+    }
+
+    // Map installed module paths
+    for (const moduleName of installedModules) {
+      const modulePath = path.join(bmadDir, moduleName);
+      modulePaths.set(moduleName, modulePath);
+    }
+
+    // Scan each module for module-help.csv
+    for (const [moduleName, modulePath] of modulePaths) {
+      const helpFilePath = path.join(modulePath, 'module-help.csv');
+
+      if (await fs.pathExists(helpFilePath)) {
+        try {
+          const content = await fs.readFile(helpFilePath, 'utf8');
+          const lines = content.split('\n').filter((line) => line.trim() && !line.startsWith('#'));
+
+          for (const line of lines) {
+            // Skip header row
+            if (line.startsWith('module,')) {
+              continue;
+            }
+
+            // Parse the line - handle quoted fields with commas
+            const columns = this.parseCSVLine(line);
+            if (columns.length >= 12) {
+              // Map old schema to new schema
+              // Old: module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs
+              // New: module,phase,name,code,sequence,workflow-file,command,required,agent-name,agent-command,agent-display-name,agent-title,options,description,output-location,outputs
+
+              const [
+                module,
+                phase,
+                name,
+                code,
+                sequence,
+                workflowFile,
+                command,
+                required,
+                agentName,
+                options,
+                description,
+                outputLocation,
+                outputs,
+              ] = columns;
+
+              // If module column is empty, set it to this module's name (except for core which stays empty for universal tools)
+              const finalModule = (!module || module.trim() === '') && moduleName !== 'core' ? moduleName : module || '';
+
+              // Lookup agent info
+              const cleanAgentName = agentName ? agentName.trim() : '';
+              const agentData = agentInfo.get(cleanAgentName) || { command: '', displayName: '', title: '' };
+
+              // Build new row with agent info
+              const newRow = [
+                finalModule,
+                phase || '',
+                name || '',
+                code || '',
+                sequence || '',
+                workflowFile || '',
+                command || '',
+                required || 'false',
+                cleanAgentName,
+                agentData.command,
+                agentData.displayName,
+                agentData.title,
+                options || '',
+                description || '',
+                outputLocation || '',
+                outputs || '',
+              ];
+
+              allRows.push(newRow.map((c) => this.escapeCSVField(c)).join(','));
+            }
+          }
+
+          if (process.env.BMAD_VERBOSE_INSTALL === 'true') {
+            console.log(chalk.dim(`  Merged module-help from: ${moduleName}`));
+          }
+        } catch (error) {
+          console.warn(chalk.yellow(`  Warning: Failed to read module-help.csv from ${moduleName}:`, error.message));
+        }
+      }
+    }
+
+    // Sort by module, then phase, then sequence
+    allRows.sort((a, b) => {
+      const colsA = this.parseCSVLine(a);
+      const colsB = this.parseCSVLine(b);
+
+      // Module comparison (empty module/universal tools come first)
+      const moduleA = (colsA[0] || '').toLowerCase();
+      const moduleB = (colsB[0] || '').toLowerCase();
+      if (moduleA !== moduleB) {
+        return moduleA.localeCompare(moduleB);
+      }
+
+      // Phase comparison
+      const phaseA = colsA[1] || '';
+      const phaseB = colsB[1] || '';
+      if (phaseA !== phaseB) {
+        return phaseA.localeCompare(phaseB);
+      }
+
+      // Sequence comparison
+      const seqA = parseInt(colsA[4] || '0', 10);
+      const seqB = parseInt(colsB[4] || '0', 10);
+      return seqA - seqB;
+    });
+
+    // Write merged catalog
+    const outputDir = path.join(bmadDir, '_config');
+    await fs.ensureDir(outputDir);
+    const outputPath = path.join(outputDir, 'bmad-help.csv');
+
+    const mergedContent = [headerRow, ...allRows].join('\n');
+    await fs.writeFile(outputPath, mergedContent, 'utf8');
+
+    // Track the installed file
+    this.installedFiles.add(outputPath);
+
+    if (process.env.BMAD_VERBOSE_INSTALL === 'true') {
+      console.log(chalk.dim(`  Generated bmad-help.csv: ${allRows.length} workflows`));
+    }
+  }
+
+  /**
+   * Parse a CSV line, handling quoted fields
+   * @param {string} line - CSV line to parse
+   * @returns {Array} Array of field values
+   */
+  parseCSVLine(line) {
+    const result = [];
+    let current = '';
+    let inQuotes = false;
+
+    for (let i = 0; i < line.length; i++) {
+      const char = line[i];
+      const nextChar = line[i + 1];
+
+      if (char === '"') {
+        if (inQuotes && nextChar === '"') {
+          // Escaped quote
+          current += '"';
+          i++; // Skip next quote
+        } else {
+          // Toggle quote mode
+          inQuotes = !inQuotes;
+        }
+      } else if (char === ',' && !inQuotes) {
+        result.push(current);
+        current = '';
+      } else {
+        current += char;
+      }
+    }
+    result.push(current);
+    return result;
+  }
+
+  /**
+   * Escape a CSV field if it contains special characters
+   * @param {string} field - Field value to escape
+   * @returns {string} Escaped field
+   */
+  escapeCSVField(field) {
+    if (field === null || field === undefined) {
+      return '';
+    }
+    const str = String(field);
+    // If field contains comma, quote, or newline, wrap in quotes and escape inner quotes
+    if (str.includes(',') || str.includes('"') || str.includes('\n')) {
+      return `"${str.replaceAll('"', '""')}"`;
+    }
+    return str;
+  }
+
   async createDirectoryStructure(bmadDir) {
     await fs.ensureDir(bmadDir);
     await fs.ensureDir(path.join(bmadDir, '_config'));

tools/cli/installers/lib/core/manifest-generator.js

@@ -385,26 +385,45 @@ class ManifestGenerator {
         const filePath = path.join(dirPath, file);
         const content = await fs.readFile(filePath, 'utf8');
 
-        // Extract task metadata from content if possible
-        const nameMatch = content.match(/name="([^"]+)"/);
+        let name = file.replace(/\.(xml|md)$/, '');
+        let displayName = name;
+        let description = '';
+        let standalone = false;
+
+        if (file.endsWith('.md')) {
+          // Parse YAML frontmatter for .md tasks
+          const frontmatterMatch = content.match(/^---\n([\s\S]*?)\n---/);
+          if (frontmatterMatch) {
+            try {
+              const frontmatter = yaml.parse(frontmatterMatch[1]);
+              name = frontmatter.name || name;
+              displayName = frontmatter.displayName || frontmatter.name || name;
+              description = frontmatter.description || '';
+              standalone = frontmatter.standalone === true || frontmatter.standalone === 'true';
+            } catch {
+              // If YAML parsing fails, use defaults
+            }
+          }
+        } else {
+          // For .xml tasks, extract from tag attributes
+          const nameMatch = content.match(/name="([^"]+)"/);
+          displayName = nameMatch ? nameMatch[1] : name;
 
-        // Try description attribute first, fall back to <objective> element
           const descMatch = content.match(/description="([^"]+)"/);
           const objMatch = content.match(/<objective>([^<]+)<\/objective>/);
-        const description = descMatch ? descMatch[1] : objMatch ? objMatch[1].trim() : '';
+          description = descMatch ? descMatch[1] : objMatch ? objMatch[1].trim() : '';
 
-        // Check for standalone attribute in <task> tag (default: false)
           const standaloneMatch = content.match(/<task[^>]+standalone="true"/);
-        const standalone = !!standaloneMatch;
+          standalone = !!standaloneMatch;
+        }
 
         // Build relative path for installation
         const installPath =
           moduleName === 'core' ? `${this.bmadFolderName}/core/tasks/${file}` : `${this.bmadFolderName}/${moduleName}/tasks/${file}`;
 
-        const taskName = file.replace(/\.(xml|md)$/, '');
         tasks.push({
-          name: taskName,
-          displayName: nameMatch ? nameMatch[1] : taskName,
+          name: name,
+          displayName: displayName,
           description: description.replaceAll('"', '""'),
           module: moduleName,
           path: installPath,
@@ -414,7 +433,7 @@ class ManifestGenerator {
         // Add to files list
         this.files.push({
           type: 'task',
-          name: taskName,
+          name: name,
           module: moduleName,
           path: installPath,
         });
@@ -455,26 +474,45 @@ class ManifestGenerator {
         const filePath = path.join(dirPath, file);
         const content = await fs.readFile(filePath, 'utf8');
 
-        // Extract tool metadata from content if possible
-        const nameMatch = content.match(/name="([^"]+)"/);
+        let name = file.replace(/\.(xml|md)$/, '');
+        let displayName = name;
+        let description = '';
+        let standalone = false;
+
+        if (file.endsWith('.md')) {
+          // Parse YAML frontmatter for .md tools
+          const frontmatterMatch = content.match(/^---\n([\s\S]*?)\n---/);
+          if (frontmatterMatch) {
+            try {
+              const frontmatter = yaml.parse(frontmatterMatch[1]);
+              name = frontmatter.name || name;
+              displayName = frontmatter.displayName || frontmatter.name || name;
+              description = frontmatter.description || '';
+              standalone = frontmatter.standalone === true || frontmatter.standalone === 'true';
+            } catch {
+              // If YAML parsing fails, use defaults
+            }
+          }
+        } else {
+          // For .xml tools, extract from tag attributes
+          const nameMatch = content.match(/name="([^"]+)"/);
+          displayName = nameMatch ? nameMatch[1] : name;
 
-        // Try description attribute first, fall back to <objective> element
           const descMatch = content.match(/description="([^"]+)"/);
           const objMatch = content.match(/<objective>([^<]+)<\/objective>/);
-        const description = descMatch ? descMatch[1] : objMatch ? objMatch[1].trim() : '';
+          description = descMatch ? descMatch[1] : objMatch ? objMatch[1].trim() : '';
 
-        // Check for standalone attribute in <tool> tag (default: false)
           const standaloneMatch = content.match(/<tool[^>]+standalone="true"/);
-        const standalone = !!standaloneMatch;
+          standalone = !!standaloneMatch;
+        }
 
         // Build relative path for installation
         const installPath =
           moduleName === 'core' ? `${this.bmadFolderName}/core/tools/${file}` : `${this.bmadFolderName}/${moduleName}/tools/${file}`;
 
-        const toolName = file.replace(/\.(xml|md)$/, '');
         tools.push({
-          name: toolName,
-          displayName: nameMatch ? nameMatch[1] : toolName,
+          name: name,
+          displayName: displayName,
           description: description.replaceAll('"', '""'),
           module: moduleName,
           path: installPath,
@@ -484,7 +522,7 @@ class ManifestGenerator {
         // Add to files list
         this.files.push({
           type: 'tool',
-          name: toolName,
+          name: name,
           module: moduleName,
           path: installPath,
         });

tools/cli/installers/lib/ide/STANDARDIZATION_PLAN.md

@@ -0,0 +1,234 @@
+# IDE Installer Standardization Plan
+
+## Overview
+
+Standardize IDE installers to use **flat file naming** and centralize duplicated code in shared utilities.
+
+**Key Rule: Only folder-based IDEs convert to colon format. IDEs already using dashes keep using dashes.**
+
+## Current State Analysis
+
+### File Structure Patterns
+
+| IDE | Current Pattern | Path Format |
+|-----|-----------------|-------------|
+| **claude-code** | Hierarchical | `.claude/commands/bmad/{module}/agents/{name}.md` |
+| **cursor** | Hierarchical | `.cursor/commands/bmad/{module}/agents/{name}.md` |
+| **crush** | Hierarchical | `.crush/commands/bmad/{module}/agents/{name}.md` |
+| **antigravity** | Flattened (dashes) | `.agent/workflows/bmad-module-agents-name.md` |
+| **codex** | Flattened (dashes) | `~/.codex/prompts/bmad-module-agents-name.md` |
+| **cline** | Flattened (dashes) | `.clinerules/workflows/bmad-module-type-name.md` |
+| **roo** | Flattened (dashes) | `.roo/commands/bmad-{module}-agent-{name}.md` |
+| **auggie** | Hybrid | `.augment/commands/bmad/agents/{module}-{name}.md` |
+| **iflow** | Hybrid | `.iflow/commands/bmad/agents/{module}-{name}.md` |
+| **trae** | Different (rules) | `.trae/rules/bmad-agent-{module}-{name}.md` |
+| **github-copilot** | Different (agents) | `.github/agents/bmd-custom-{module}-{name}.agent.md` |
+
+### Shared Generators (in `/shared`)
+
+1. `agent-command-generator.js` - generates agent launchers
+2. `task-tool-command-generator.js` - generates task/tool commands
+3. `workflow-command-generator.js` - generates workflow commands
+
+All currently create artifacts with **nested relative paths** like `{module}/agents/{name}.md`
+
+### Code Duplication Issues
+
+1. **Flattening logic** duplicated in multiple IDEs
+2. **Agent launcher content creation** duplicated
+3. **Path transformation** duplicated
+
+## Target Standardization
+
+### For Folder-Based IDEs (convert to colon format)
+
+**IDEs affected:** claude-code, cursor, crush
+
+```
+Format: bmad:{module}:{type}:{name}.md
+
+Examples:
+- Agent:      bmad:bmm:agents:pm.md
+- Agent:      bmad:core:agents:dev.md
+- Workflow:   bmad:bmm:workflows:correct-course.md
+- Task:       bmad:bmm:tasks:bmad-help.md
+- Tool:       bmad:core:tools:code-review.md
+- Custom:     bmad:custom:agents:fred-commit-poet.md
+```
+
+### For Already-Flat IDEs (keep using dashes)
+
+**IDEs affected:** antigravity, codex, cline, roo
+
+```
+Format: bmad-{module}-{type}-{name}.md
+
+Examples:
+- Agent:      bmad-bmm-agents-pm.md
+- Workflow:   bmad-bmm-workflows-correct-course.md
+- Task:       bmad-bmm-tasks-bmad-help.md
+- Custom:     bmad-custom-agents-fred-commit-poet.md
+```
+
+### For Hybrid IDEs (keep as-is)
+
+**IDEs affected:** auggie, iflow
+
+These use `{module}-{name}.md` format within subdirectories - keep as-is.
+
+### Skip (drastically different)
+
+**IDEs affected:** trae, github-copilot
+
+## Implementation Plan
+
+### Phase 1: Create Shared Utility
+
+**File:** `shared/path-utils.js`
+
+```javascript
+/**
+ * Convert hierarchical path to flat colon-separated name (for folder-based IDEs)
+ * @param {string} module - Module name (e.g., 'bmm', 'core')
+ * @param {string} type - Artifact type ('agents', 'workflows', 'tasks', 'tools')
+ * @param {string} name - Artifact name (e.g., 'pm', 'correct-course')
+ * @returns {string} Flat filename like 'bmad:bmm:agents:pm.md'
+ */
+function toColonName(module, type, name) {
+  return `bmad:${module}:${type}:${name}.md`;
+}
+
+/**
+ * Convert relative path to flat colon-separated name (for folder-based IDEs)
+ * @param {string} relativePath - Path like 'bmm/agents/pm.md'
+ * @returns {string} Flat filename like 'bmad:bmm:agents:pm.md'
+ */
+function toColonPath(relativePath) {
+  const withoutExt = relativePath.replace('.md', '');
+  const parts = withoutExt.split(/[\/\\]/);
+  return `bmad:${parts.join(':')}.md`;
+}
+
+/**
+ * Convert hierarchical path to flat dash-separated name (for flat IDEs)
+ * @param {string} relativePath - Path like 'bmm/agents/pm.md'
+ * @returns {string} Flat filename like 'bmad-bmm-agents-pm.md'
+ */
+function toDashPath(relativePath) {
+  const withoutExt = relativePath.replace('.md', '');
+  const parts = withoutExt.split(/[\/\\]/);
+  return `bmad-${parts.join('-')}.md`;
+}
+
+/**
+ * Create custom agent colon name
+ * @param {string} agentName - Custom agent name
+ * @returns {string} Flat filename like 'bmad:custom:agents:fred-commit-poet.md'
+ */
+function customAgentColonName(agentName) {
+  return `bmad:custom:agents:${agentName}.md`;
+}
+
+/**
+ * Create custom agent dash name
+ * @param {string} agentName - Custom agent name
+ * @returns {string} Flat filename like 'bmad-custom-agents-fred-commit-poet.md'
+ */
+function customAgentDashName(agentName) {
+  return `bmad-custom-agents-${agentName}.md`;
+}
+
+module.exports = {
+  toColonName,
+  toColonPath,
+  toDashPath,
+  customAgentColonName,
+  customAgentDashName,
+};
+```
+
+### Phase 2: Update Shared Generators
+
+**Files to modify:**
+- `shared/agent-command-generator.js`
+- `shared/task-tool-command-generator.js`
+- `shared/workflow-command-generator.js`
+
+**Changes:**
+1. Import path utilities
+2. Change `relativePath` to use flat format
+3. Add method `writeColonArtifacts()` for folder-based IDEs
+4. Add method `writeDashArtifacts()` for flat IDEs
+
+### Phase 3: Update Folder-Based IDEs
+
+**Files to modify:**
+- `claude-code.js`
+- `cursor.js`
+- `crush.js`
+
+**Changes:**
+1. Import `toColonPath`, `customAgentColonName` from path-utils
+2. Change from hierarchical to flat colon naming
+3. Update cleanup to handle flat structure
+
+### Phase 4: Update Flat IDEs
+
+**Files to modify:**
+- `antigravity.js`
+- `codex.js`
+- `cline.js`
+- `roo.js`
+
+**Changes:**
+1. Import `toDashPath`, `customAgentDashName` from path-utils
+2. Replace local `flattenFilename()` with shared `toDashPath()`
+
+### Phase 5: Update Base Class
+
+**File:** `_base-ide.js`
+
+**Changes:**
+1. Mark `flattenFilename()` as `@deprecated`
+2. Add comment pointing to new path-utils
+
+## Migration Checklist
+
+### New Files
+- [ ] Create `shared/path-utils.js`
+
+### Folder-Based IDEs (convert to colon format)
+- [ ] Update `shared/agent-command-generator.js` - add `writeColonArtifacts()`
+- [ ] Update `shared/task-tool-command-generator.js` - add `writeColonArtifacts()`
+- [ ] Update `shared/workflow-command-generator.js` - add `writeColonArtifacts()`
+- [ ] Update `claude-code.js` - convert to colon format
+- [ ] Update `cursor.js` - convert to colon format
+- [ ] Update `crush.js` - convert to colon format
+
+### Flat IDEs (standardize dash format)
+- [ ] Update `shared/agent-command-generator.js` - add `writeDashArtifacts()`
+- [ ] Update `shared/task-tool-command-generator.js` - add `writeDashArtifacts()`
+- [ ] Update `shared/workflow-command-generator.js` - add `writeDashArtifacts()`
+- [ ] Update `antigravity.js` - use shared `toDashPath()`
+- [ ] Update `codex.js` - use shared `toDashPath()`
+- [ ] Update `cline.js` - use shared `toDashPath()`
+- [ ] Update `roo.js` - use shared `toDashPath()`
+
+### Base Class
+- [ ] Update `_base-ide.js` - add deprecation notice
+
+### Testing
+- [ ] Test claude-code installation
+- [ ] Test cursor installation
+- [ ] Test crush installation
+- [ ] Test antigravity installation
+- [ ] Test codex installation
+- [ ] Test cline installation
+- [ ] Test roo installation
+
+## Notes
+
+1. **Keep segments**: agents, workflows, tasks, tools all become part of the flat name
+2. **Colon vs Dash**: Colons for folder-based IDEs converting to flat, dashes for already-flat IDEs
+3. **Custom agents**: Follow the same pattern as regular agents
+4. **Backward compatibility**: Cleanup will remove old folder structure

tools/cli/installers/lib/ide/_base-ide.js

@@ -619,6 +619,7 @@ class BaseIdeSetup {
 
   /**
    * Flatten a relative path to a single filename for flat slash command naming
+   * @deprecated Use toColonPath() or toDashPath() from shared/path-utils.js instead
    * Example: 'module/agents/name.md' -> 'bmad-module-agents-name.md'
    * Used by IDEs that ignore directory structure for slash commands (e.g., Antigravity, Codex)
    * @param {string} relativePath - Relative path to flatten

tools/cli/installers/lib/ide/antigravity.js

@@ -13,6 +13,7 @@ const {
   resolveSubagentFiles,
 } = require('./shared/module-injections');
 const { getAgentsFromBmad, getAgentsFromDir } = require('./shared/bmad-artifacts');
+const { toDashPath, customAgentDashName } = require('./shared/path-utils');
 const prompts = require('../../../lib/prompts');
 
 /**
@@ -125,16 +126,10 @@ class AntigravitySetup extends BaseIdeSetup {
     const agentGen = new AgentCommandGenerator(this.bmadFolderName);
     const { artifacts: agentArtifacts, counts: agentCounts } = await agentGen.collectAgentArtifacts(bmadDir, options.selectedModules || []);
 
-    // Write agent launcher files with FLATTENED naming
-    // Antigravity ignores directory structure, so we flatten to: bmad-module-agents-name.md
-    // This creates slash commands like /bmad-bmm-agents-dev instead of /dev
-    let agentCount = 0;
-    for (const artifact of agentArtifacts) {
-      const flattenedName = this.flattenFilename(artifact.relativePath);
-      const targetPath = path.join(bmadWorkflowsDir, flattenedName);
-      await this.writeFile(targetPath, artifact.content);
-      agentCount++;
-    }
+    // Write agent launcher files with FLATTENED naming using shared utility
+    // Antigravity ignores directory structure, so we flatten to: bmad-module-name.md
+    // This creates slash commands like /bmad-bmm-dev instead of /dev
+    const agentCount = await agentGen.writeDashArtifacts(bmadWorkflowsDir, agentArtifacts);
 
     // Process Antigravity specific injections for installed modules
     // Use pre-collected configuration if available, or skip if already configured
@@ -152,16 +147,8 @@ class AntigravitySetup extends BaseIdeSetup {
     const workflowGen = new WorkflowCommandGenerator(this.bmadFolderName);
     const { artifacts: workflowArtifacts } = await workflowGen.collectWorkflowArtifacts(bmadDir);
 
-    // Write workflow-command artifacts with FLATTENED naming
-    let workflowCommandCount = 0;
-    for (const artifact of workflowArtifacts) {
-      if (artifact.type === 'workflow-command') {
-        const flattenedName = this.flattenFilename(artifact.relativePath);
-        const targetPath = path.join(bmadWorkflowsDir, flattenedName);
-        await this.writeFile(targetPath, artifact.content);
-        workflowCommandCount++;
-      }
-    }
+    // Write workflow-command artifacts with FLATTENED naming using shared utility
+    const workflowCommandCount = await workflowGen.writeDashArtifacts(bmadWorkflowsDir, workflowArtifacts);
 
     // Generate task and tool commands from manifests (if they exist)
     const taskToolGen = new TaskToolCommandGenerator();
@@ -468,7 +455,8 @@ usage: |
 
 ⚠️ **IMPORTANT**: Run @${agentPath} to load the complete agent before using this launcher!`;
 
-    const fileName = `bmad-custom-agents-${agentName}.md`;
+    // Use dash format: bmad-custom-agents-fred-commit-poet.md
+    const fileName = customAgentDashName(agentName);
     const launcherPath = path.join(bmadWorkflowsDir, fileName);
 
     // Write the launcher file
@@ -477,7 +465,7 @@ usage: |
     return {
       ide: 'antigravity',
       path: path.relative(projectDir, launcherPath),
-      command: `/${agentName}`,
+      command: `/${fileName.replace('.md', '')}`,
       type: 'custom-agent-launcher',
     };
   }

tools/cli/installers/lib/ide/claude-code.js

@@ -13,6 +13,7 @@ const {
   resolveSubagentFiles,
 } = require('./shared/module-injections');
 const { getAgentsFromBmad, getAgentsFromDir } = require('./shared/bmad-artifacts');
+const { customAgentColonName } = require('./shared/path-utils');
 const prompts = require('../../../lib/prompts');
 
 /**
@@ -89,13 +90,46 @@ class ClaudeCodeSetup extends BaseIdeSetup {
    * @param {string} projectDir - Project directory
    */
   async cleanup(projectDir) {
-    const bmadCommandsDir = path.join(projectDir, this.configDir, this.commandsDir, 'bmad');
+    const commandsDir = path.join(projectDir, this.configDir, this.commandsDir);
 
-    if (await fs.pathExists(bmadCommandsDir)) {
-      await fs.remove(bmadCommandsDir);
+    // Remove any bmad:* files from the commands directory
+    if (await fs.pathExists(commandsDir)) {
+      const entries = await fs.readdir(commandsDir);
+      let removedCount = 0;
+      for (const entry of entries) {
+        if (entry.startsWith('bmad:')) {
+          await fs.remove(path.join(commandsDir, entry));
+          removedCount++;
+        }
+      }
+      // Also remove legacy bmad folder if it exists
+      const bmadFolder = path.join(commandsDir, 'bmad');
+      if (await fs.pathExists(bmadFolder)) {
+        await fs.remove(bmadFolder);
         console.log(chalk.dim(`  Removed old BMAD commands from ${this.name}`));
       }
     }
+  }
+
+  /**
+   * Clean up legacy folder structure (module/type/name.md) if it exists
+   * This can be called after migration to remove old nested directories
+   * @param {string} projectDir - Project directory
+   */
+  async cleanupLegacyFolders(projectDir) {
+    const commandsDir = path.join(projectDir, this.configDir, this.commandsDir);
+
+    if (!(await fs.pathExists(commandsDir))) {
+      return;
+    }
+
+    // Remove legacy bmad folder if it exists
+    const bmadFolder = path.join(commandsDir, 'bmad');
+    if (await fs.pathExists(bmadFolder)) {
+      await fs.remove(bmadFolder);
+      console.log(chalk.dim(`  Removed legacy bmad folder from ${this.name}`));
+    }
+  }
 
   /**
    * Setup Claude Code IDE configuration
@@ -115,28 +149,19 @@ class ClaudeCodeSetup extends BaseIdeSetup {
     // Create .claude/commands directory structure
     const claudeDir = path.join(projectDir, this.configDir);
     const commandsDir = path.join(claudeDir, this.commandsDir);
-    const bmadCommandsDir = path.join(commandsDir, 'bmad');
+    await this.ensureDir(commandsDir);
 
-    await this.ensureDir(bmadCommandsDir);
+    // Use colon format: files written directly to commands dir (no bmad subfolder)
+    // Creates: .claude/commands/bmad:bmm:pm.md
 
     // Generate agent launchers using AgentCommandGenerator
     // This creates small launcher files that reference the actual agents in _bmad/
     const agentGen = new AgentCommandGenerator(this.bmadFolderName);
     const { artifacts: agentArtifacts, counts: agentCounts } = await agentGen.collectAgentArtifacts(bmadDir, options.selectedModules || []);
 
-    // Create directories for each module
-    const modules = new Set();
-    for (const artifact of agentArtifacts) {
-      modules.add(artifact.module);
-    }
-
-    for (const module of modules) {
-      await this.ensureDir(path.join(bmadCommandsDir, module));
-      await this.ensureDir(path.join(bmadCommandsDir, module, 'agents'));
-    }
-
-    // Write agent launcher files
-    const agentCount = await agentGen.writeAgentLaunchers(bmadCommandsDir, agentArtifacts);
+    // Write agent launcher files using flat colon naming
+    // Creates files like: bmad:bmm:pm.md
+    const agentCount = await agentGen.writeColonArtifacts(commandsDir, agentArtifacts);
 
     // Process Claude Code specific injections for installed modules
     // Use pre-collected configuration if available, or skip if already configured
@@ -157,22 +182,13 @@ class ClaudeCodeSetup extends BaseIdeSetup {
     const workflowGen = new WorkflowCommandGenerator(this.bmadFolderName);
     const { artifacts: workflowArtifacts } = await workflowGen.collectWorkflowArtifacts(bmadDir);
 
-    // Write only workflow-command artifacts, skip workflow-launcher READMEs
-    let workflowCommandCount = 0;
-    for (const artifact of workflowArtifacts) {
-      if (artifact.type === 'workflow-command') {
-        const moduleWorkflowsDir = path.join(bmadCommandsDir, artifact.module, 'workflows');
-        await this.ensureDir(moduleWorkflowsDir);
-        const commandPath = path.join(moduleWorkflowsDir, path.basename(artifact.relativePath));
-        await this.writeFile(commandPath, artifact.content);
-        workflowCommandCount++;
-      }
-      // Skip workflow-launcher READMEs as they would be treated as slash commands
-    }
+    // Write workflow-command artifacts using flat colon naming
+    // Creates files like: bmad:bmm:correct-course.md
+    const workflowCommandCount = await workflowGen.writeColonArtifacts(commandsDir, workflowArtifacts);
 
     // Generate task and tool commands from manifests (if they exist)
     const taskToolGen = new TaskToolCommandGenerator();
-    const taskToolResult = await taskToolGen.generateTaskToolCommands(projectDir, bmadDir);
+    const taskToolResult = await taskToolGen.generateColonTaskToolCommands(projectDir, bmadDir, commandsDir);
 
     console.log(chalk.green(`✓ ${this.name} configured:`));
     console.log(chalk.dim(`  - ${agentCount} agents installed`));
@@ -186,7 +202,7 @@ class ClaudeCodeSetup extends BaseIdeSetup {
         ),
       );
     }
-    console.log(chalk.dim(`  - Commands directory: ${path.relative(projectDir, bmadCommandsDir)}`));
+    console.log(chalk.dim(`  - Commands directory: ${path.relative(projectDir, commandsDir)}`));
 
     return {
       success: true,
@@ -449,13 +465,13 @@ class ClaudeCodeSetup extends BaseIdeSetup {
    * @returns {Object|null} Info about created command
    */
   async installCustomAgentLauncher(projectDir, agentName, agentPath, metadata) {
-    const customAgentsDir = path.join(projectDir, this.configDir, this.commandsDir, 'bmad', 'custom', 'agents');
+    const commandsDir = path.join(projectDir, this.configDir, this.commandsDir);
 
     if (!(await this.exists(path.join(projectDir, this.configDir)))) {
       return null; // IDE not configured for this project
     }
 
-    await this.ensureDir(customAgentsDir);
+    await this.ensureDir(commandsDir);
 
     const launcherContent = `---
 name: '${agentName}'
@@ -474,12 +490,15 @@ You must fully embody this agent's persona and follow all activation instruction
 </agent-activation>
 `;
 
-    const launcherPath = path.join(customAgentsDir, `${agentName}.md`);
+    // Use colon format: bmad:custom:agents:fred-commit-poet.md
+    // Written directly to commands dir (no bmad subfolder)
+    const launcherName = customAgentColonName(agentName);
+    const launcherPath = path.join(commandsDir, launcherName);
     await this.writeFile(launcherPath, launcherContent);
 
     return {
       path: launcherPath,
-      command: `/bmad:custom:agents:${agentName}`,
+      command: `/${launcherName.replace('.md', '')}`,
     };
   }
 }

tools/cli/installers/lib/ide/cline.js

@@ -4,7 +4,9 @@ const chalk = require('chalk');
 const { BaseIdeSetup } = require('./_base-ide');
 const { WorkflowCommandGenerator } = require('./shared/workflow-command-generator');
 const { AgentCommandGenerator } = require('./shared/agent-command-generator');
+const { TaskToolCommandGenerator } = require('./shared/task-tool-command-generator');
 const { getAgentsFromBmad, getTasksFromBmad } = require('./shared/bmad-artifacts');
+const { toDashPath, customAgentDashName } = require('./shared/path-utils');
 
 /**
  * Cline IDE setup handler
@@ -56,7 +58,7 @@ class ClineSetup extends BaseIdeSetup {
     console.log(chalk.dim('  Usage:'));
     console.log(chalk.dim('    - Type / to see available commands'));
     console.log(chalk.dim('    - All BMAD items start with "bmad-"'));
-    console.log(chalk.dim('    - Example: /bmad-bmm-agents-pm'));
+    console.log(chalk.dim('    - Example: /bmad-bmm-pm'));
 
     return {
       success: true,
@@ -145,10 +147,10 @@ class ClineSetup extends BaseIdeSetup {
 
   /**
    * Flatten file path to bmad-module-type-name.md format
+   * Uses shared toDashPath utility
    */
   flattenFilename(relativePath) {
-    const sanitized = relativePath.replaceAll(/[\\/]/g, '-');
-    return `bmad-${sanitized}`;
+    return toDashPath(relativePath);
   }
 
   /**
@@ -244,7 +246,8 @@ The agent will follow the persona and instructions from the main agent file.
 
 *Generated by BMAD Method*`;
 
-    const fileName = `bmad-custom-${agentName.toLowerCase()}.md`;
+    // Use dash format: bmad-custom-agents-fred-commit-poet.md
+    const fileName = customAgentDashName(agentName);
     const launcherPath = path.join(workflowsDir, fileName);
 
     // Write the launcher file
@@ -253,7 +256,7 @@ The agent will follow the persona and instructions from the main agent file.
     return {
       ide: 'cline',
       path: path.relative(projectDir, launcherPath),
-      command: agentName,
+      command: fileName.replace('.md', ''),
       type: 'custom-agent-launcher',
     };
   }

tools/cli/installers/lib/ide/codex.js

@@ -5,7 +5,9 @@ const chalk = require('chalk');
 const { BaseIdeSetup } = require('./_base-ide');
 const { WorkflowCommandGenerator } = require('./shared/workflow-command-generator');
 const { AgentCommandGenerator } = require('./shared/agent-command-generator');
+const { TaskToolCommandGenerator } = require('./shared/task-tool-command-generator');
 const { getTasksFromBmad } = require('./shared/bmad-artifacts');
+const { toDashPath, customAgentDashName } = require('./shared/path-utils');
 const prompts = require('../../../lib/prompts');
 
 /**
@@ -83,7 +85,41 @@ class CodexSetup extends BaseIdeSetup {
     const destDir = this.getCodexPromptDir(projectDir, installLocation);
     await fs.ensureDir(destDir);
     await this.clearOldBmadFiles(destDir);
-    const written = await this.flattenAndWriteArtifacts(artifacts, destDir);
+
+    // Collect artifacts and write using DASH format
+    const agentGen = new AgentCommandGenerator(this.bmadFolderName);
+    const { artifacts: agentArtifacts } = await agentGen.collectAgentArtifacts(bmadDir, options.selectedModules || []);
+    const agentCount = await agentGen.writeDashArtifacts(destDir, agentArtifacts);
+
+    const tasks = await getTasksFromBmad(bmadDir, options.selectedModules || []);
+    const taskArtifacts = [];
+    for (const task of tasks) {
+      const content = await this.readAndProcessWithProject(
+        task.path,
+        {
+          module: task.module,
+          name: task.name,
+        },
+        projectDir,
+      );
+      taskArtifacts.push({
+        type: 'task',
+        module: task.module,
+        sourcePath: task.path,
+        relativePath: path.join(task.module, 'tasks', `${task.name}.md`),
+        content,
+      });
+    }
+
+    const workflowGenerator = new WorkflowCommandGenerator(this.bmadFolderName);
+    const { artifacts: workflowArtifacts } = await workflowGenerator.collectWorkflowArtifacts(bmadDir);
+    const workflowCount = await workflowGenerator.writeDashArtifacts(destDir, workflowArtifacts);
+
+    // Also write tasks using dash format
+    const ttGen = new TaskToolCommandGenerator();
+    const tasksWritten = await ttGen.writeDashArtifacts(destDir, taskArtifacts);
+
+    const written = agentCount + workflowCount + tasksWritten;
 
     console.log(chalk.green(`✓ ${this.name} configured:`));
     console.log(chalk.dim(`  - Mode: CLI`));
@@ -256,7 +292,7 @@ class CodexSetup extends BaseIdeSetup {
       chalk.dim("  To use with other projects, you'd need to copy the _bmad dir"),
       '',
       chalk.green('  ✓ You can now use /commands in Codex CLI'),
-      chalk.dim('    Example: /bmad-bmm-agents-pm'),
+      chalk.dim('    Example: /bmad-bmm-pm'),
       chalk.dim('    Type / to see all available commands'),
       '',
       chalk.bold.cyan('═'.repeat(70)),
@@ -361,7 +397,8 @@ You must fully embody this agent's persona and follow all activation instruction
 </agent-activation>
 `;
 
-    const fileName = `bmad-custom-agents-${agentName}.md`;
+    // Use dash format: bmad-custom-agents-fred-commit-poet.md
+    const fileName = customAgentDashName(agentName);
     const launcherPath = path.join(destDir, fileName);
     await fs.writeFile(launcherPath, launcherContent, 'utf8');
 

tools/cli/installers/lib/ide/crush.js

@@ -4,10 +4,12 @@ const { BaseIdeSetup } = require('./_base-ide');
 const chalk = require('chalk');
 const { AgentCommandGenerator } = require('./shared/agent-command-generator');
 const { WorkflowCommandGenerator } = require('./shared/workflow-command-generator');
+const { TaskToolCommandGenerator } = require('./shared/task-tool-command-generator');
+const { customAgentColonName } = require('./shared/path-utils');
 
 /**
  * Crush IDE setup handler
- * Creates commands in .crush/commands/ directory structure
+ * Creates commands in .crush/commands/ directory structure using flat colon naming
  */
 class CrushSetup extends BaseIdeSetup {
   constructor() {
@@ -25,227 +27,73 @@ class CrushSetup extends BaseIdeSetup {
   async setup(projectDir, bmadDir, options = {}) {
     console.log(chalk.cyan(`Setting up ${this.name}...`));
 
-    // Create .crush/commands/bmad directory structure
-    const crushDir = path.join(projectDir, this.configDir);
-    const commandsDir = path.join(crushDir, this.commandsDir, 'bmad');
+    // Clean up old BMAD installation first
+    await this.cleanup(projectDir);
 
+    // Create .crush/commands directory
+    const crushDir = path.join(projectDir, this.configDir);
+    const commandsDir = path.join(crushDir, this.commandsDir);
     await this.ensureDir(commandsDir);
 
+    // Use colon format: files written directly to commands dir (no bmad subfolder)
+    // Creates: .crush/commands/bmad:bmm:pm.md
+
     // Generate agent launchers
     const agentGen = new AgentCommandGenerator(this.bmadFolderName);
     const { artifacts: agentArtifacts } = await agentGen.collectAgentArtifacts(bmadDir, options.selectedModules || []);
 
-    // Get tasks, tools, and workflows (ALL workflows now generate commands)
-    const tasks = await this.getTasks(bmadDir, true);
-    const tools = await this.getTools(bmadDir, true);
+    // Write agent launcher files using flat colon naming
+    // Creates files like: bmad:bmm:pm.md
+    const agentCount = await agentGen.writeColonArtifacts(commandsDir, agentArtifacts);
 
     // Get ALL workflows using the new workflow command generator
     const workflowGenerator = new WorkflowCommandGenerator(this.bmadFolderName);
-    const { artifacts: workflowArtifacts, counts: workflowCounts } = await workflowGenerator.collectWorkflowArtifacts(bmadDir);
+    const { artifacts: workflowArtifacts } = await workflowGenerator.collectWorkflowArtifacts(bmadDir);
 
-    // Convert workflow artifacts to expected format for organizeByModule
-    const workflows = workflowArtifacts
-      .filter((artifact) => artifact.type === 'workflow-command')
-      .map((artifact) => ({
-        module: artifact.module,
-        name: path.basename(artifact.relativePath, '.md'),
-        path: artifact.sourcePath,
-        content: artifact.content,
-      }));
+    // Write workflow-command artifacts using flat colon naming
+    // Creates files like: bmad:bmm:correct-course.md
+    const workflowCount = await workflowGenerator.writeColonArtifacts(commandsDir, workflowArtifacts);
 
-    // Organize by module
-    const agentCount = await this.organizeByModule(commandsDir, agentArtifacts, tasks, tools, workflows, projectDir);
+    // Generate task and tool commands using flat colon naming
+    const taskToolGen = new TaskToolCommandGenerator();
+    const taskToolResult = await taskToolGen.generateColonTaskToolCommands(projectDir, bmadDir, commandsDir);
 
     console.log(chalk.green(`✓ ${this.name} configured:`));
-    console.log(chalk.dim(`  - ${agentCount.agents} agent commands created`));
-    console.log(chalk.dim(`  - ${agentCount.tasks} task commands created`));
-    console.log(chalk.dim(`  - ${agentCount.tools} tool commands created`));
-    console.log(chalk.dim(`  - ${agentCount.workflows} workflow commands created`));
+    console.log(chalk.dim(`  - ${agentCount} agent commands created`));
+    console.log(chalk.dim(`  - ${taskToolResult.tasks} task commands created`));
+    console.log(chalk.dim(`  - ${taskToolResult.tools} tool commands created`));
+    console.log(chalk.dim(`  - ${workflowCount} workflow commands created`));
     console.log(chalk.dim(`  - Commands directory: ${path.relative(projectDir, commandsDir)}`));
     console.log(chalk.dim('\n  Commands can be accessed via Crush command palette'));
 
     return {
       success: true,
-      ...agentCount,
-    };
-  }
-
-  /**
-   * Organize commands by module
-   */
-  async organizeByModule(commandsDir, agentArtifacts, tasks, tools, workflows, projectDir) {
-    // Get unique modules
-    const modules = new Set();
-    for (const artifact of agentArtifacts) modules.add(artifact.module);
-    for (const task of tasks) modules.add(task.module);
-    for (const tool of tools) modules.add(tool.module);
-    for (const workflow of workflows) modules.add(workflow.module);
-
-    let agentCount = 0;
-    let taskCount = 0;
-    let toolCount = 0;
-    let workflowCount = 0;
-
-    // Create module directories
-    for (const module of modules) {
-      const moduleDir = path.join(commandsDir, module);
-      const moduleAgentsDir = path.join(moduleDir, 'agents');
-      const moduleTasksDir = path.join(moduleDir, 'tasks');
-      const moduleToolsDir = path.join(moduleDir, 'tools');
-      const moduleWorkflowsDir = path.join(moduleDir, 'workflows');
-
-      await this.ensureDir(moduleAgentsDir);
-      await this.ensureDir(moduleTasksDir);
-      await this.ensureDir(moduleToolsDir);
-      await this.ensureDir(moduleWorkflowsDir);
-
-      // Write module-specific agent launchers
-      const moduleAgents = agentArtifacts.filter((a) => a.module === module);
-      for (const artifact of moduleAgents) {
-        const targetPath = path.join(moduleAgentsDir, `${artifact.name}.md`);
-        await this.writeFile(targetPath, artifact.content);
-        agentCount++;
-      }
-
-      // Copy module-specific tasks
-      const moduleTasks = tasks.filter((t) => t.module === module);
-      for (const task of moduleTasks) {
-        const content = await this.readFile(task.path);
-        const commandContent = this.createTaskCommand(task, content);
-        const targetPath = path.join(moduleTasksDir, `${task.name}.md`);
-        await this.writeFile(targetPath, commandContent);
-        taskCount++;
-      }
-
-      // Copy module-specific tools
-      const moduleTools = tools.filter((t) => t.module === module);
-      for (const tool of moduleTools) {
-        const content = await this.readFile(tool.path);
-        const commandContent = this.createToolCommand(tool, content);
-        const targetPath = path.join(moduleToolsDir, `${tool.name}.md`);
-        await this.writeFile(targetPath, commandContent);
-        toolCount++;
-      }
-
-      // Copy module-specific workflow commands (already generated)
-      const moduleWorkflows = workflows.filter((w) => w.module === module);
-      for (const workflow of moduleWorkflows) {
-        // Use the pre-generated workflow command content
-        const targetPath = path.join(moduleWorkflowsDir, `${workflow.name}.md`);
-        await this.writeFile(targetPath, workflow.content);
-        workflowCount++;
-      }
-    }
-
-    return {
       agents: agentCount,
-      tasks: taskCount,
-      tools: toolCount,
+      tasks: taskToolResult.tasks || 0,
+      tools: taskToolResult.tools || 0,
       workflows: workflowCount,
     };
   }
 
-  /**
-   * Create task command content
-   */
-  createTaskCommand(task, content) {
-    // Extract task name
-    const nameMatch = content.match(/name="([^"]+)"/);
-    const taskName = nameMatch ? nameMatch[1] : this.formatTitle(task.name);
-
-    let commandContent = `# /task-${task.name} Command
-
-When this command is used, execute the following task:
-
-## ${taskName} Task
-
-${content}
-
-## Command Usage
-
-This command executes the ${taskName} task from the BMAD ${task.module.toUpperCase()} module.
-
-## Module
-
-Part of the BMAD ${task.module.toUpperCase()} module.
-`;
-
-    return commandContent;
-  }
-
-  /**
-   * Create tool command content
-   */
-  createToolCommand(tool, content) {
-    // Extract tool name
-    const nameMatch = content.match(/name="([^"]+)"/);
-    const toolName = nameMatch ? nameMatch[1] : this.formatTitle(tool.name);
-
-    let commandContent = `# /tool-${tool.name} Command
-
-When this command is used, execute the following tool:
-
-## ${toolName} Tool
-
-${content}
-
-## Command Usage
-
-This command executes the ${toolName} tool from the BMAD ${tool.module.toUpperCase()} module.
-
-## Module
-
-Part of the BMAD ${tool.module.toUpperCase()} module.
-`;
-
-    return commandContent;
-  }
-
-  /**
-   * Create workflow command content
-   */
-  createWorkflowCommand(workflow, content) {
-    const workflowName = workflow.name ? this.formatTitle(workflow.name) : 'Workflow';
-
-    let commandContent = `# /${workflow.name} Command
-
-When this command is used, execute the following workflow:
-
-## ${workflowName} Workflow
-
-${content}
-
-## Command Usage
-
-This command executes the ${workflowName} workflow from the BMAD ${workflow.module.toUpperCase()} module.
-
-## Module
-
-Part of the BMAD ${workflow.module.toUpperCase()} module.
-`;
-
-    return commandContent;
-  }
-
-  /**
-   * Format name as title
-   */
-  formatTitle(name) {
-    return name
-      .split('-')
-      .map((word) => word.charAt(0).toUpperCase() + word.slice(1))
-      .join(' ');
-  }
-
   /**
    * Cleanup Crush configuration
    */
   async cleanup(projectDir) {
-    const fs = require('fs-extra');
-    const bmadCommandsDir = path.join(projectDir, this.configDir, this.commandsDir, 'bmad');
+    const commandsDir = path.join(projectDir, this.configDir, this.commandsDir);
 
-    if (await fs.pathExists(bmadCommandsDir)) {
-      await fs.remove(bmadCommandsDir);
+    // Remove any bmad:* files from the commands directory
+    if (await fs.pathExists(commandsDir)) {
+      const entries = await fs.readdir(commandsDir);
+      for (const entry of entries) {
+        if (entry.startsWith('bmad:')) {
+          await fs.remove(path.join(commandsDir, entry));
+        }
+      }
+    }
+    // Also remove legacy bmad folder if it exists
+    const bmadFolder = path.join(commandsDir, 'bmad');
+    if (await fs.pathExists(bmadFolder)) {
+      await fs.remove(bmadFolder);
       console.log(chalk.dim(`Removed BMAD commands from Crush`));
     }
   }
@@ -259,11 +107,10 @@ Part of the BMAD ${workflow.module.toUpperCase()} module.
    * @returns {Object} Installation result
    */
   async installCustomAgentLauncher(projectDir, agentName, agentPath, metadata) {
-    const crushDir = path.join(projectDir, this.configDir);
-    const bmadCommandsDir = path.join(crushDir, this.commandsDir, 'bmad');
+    const commandsDir = path.join(projectDir, this.configDir, this.commandsDir);
 
-    // Create .crush/commands/bmad directory if it doesn't exist
-    await fs.ensureDir(bmadCommandsDir);
+    // Create .crush/commands directory if it doesn't exist
+    await fs.ensureDir(commandsDir);
 
     // Create custom agent launcher
     const launcherContent = `# ${agentName} Custom Agent
@@ -282,8 +129,10 @@ The agent will follow the persona and instructions from the main agent file.
 
 *Generated by BMAD Method*`;
 
-    const fileName = `custom-${agentName.toLowerCase()}.md`;
-    const launcherPath = path.join(bmadCommandsDir, fileName);
+    // Use colon format: bmad:custom:agents:fred-commit-poet.md
+    // Written directly to commands dir (no bmad subfolder)
+    const launcherName = customAgentColonName(agentName);
+    const launcherPath = path.join(commandsDir, launcherName);
 
     // Write the launcher file
     await fs.writeFile(launcherPath, launcherContent, 'utf8');
@@ -291,7 +140,7 @@ The agent will follow the persona and instructions from the main agent file.
     return {
       ide: 'crush',
       path: path.relative(projectDir, launcherPath),
-      command: agentName,
+      command: launcherName.replace('.md', ''),
       type: 'custom-agent-launcher',
     };
   }

tools/cli/installers/lib/ide/cursor.js

@@ -4,6 +4,7 @@ const chalk = require('chalk');
 const { AgentCommandGenerator } = require('./shared/agent-command-generator');
 const { WorkflowCommandGenerator } = require('./shared/workflow-command-generator');
 const { TaskToolCommandGenerator } = require('./shared/task-tool-command-generator');
+const { customAgentColonName } = require('./shared/path-utils');
 
 /**
  * Cursor IDE setup handler
@@ -22,16 +23,21 @@ class CursorSetup extends BaseIdeSetup {
    */
   async cleanup(projectDir) {
     const fs = require('fs-extra');
-    const bmadRulesDir = path.join(projectDir, this.configDir, this.rulesDir, 'bmad');
-    const bmadCommandsDir = path.join(projectDir, this.configDir, this.commandsDir, 'bmad');
+    const commandsDir = path.join(projectDir, this.configDir, this.commandsDir);
 
-    if (await fs.pathExists(bmadRulesDir)) {
-      await fs.remove(bmadRulesDir);
-      console.log(chalk.dim(`  Removed old BMAD rules from ${this.name}`));
+    // Remove any bmad:* files from the commands directory
+    if (await fs.pathExists(commandsDir)) {
+      const entries = await fs.readdir(commandsDir);
+      for (const entry of entries) {
+        if (entry.startsWith('bmad:')) {
+          await fs.remove(path.join(commandsDir, entry));
         }
-
-    if (await fs.pathExists(bmadCommandsDir)) {
-      await fs.remove(bmadCommandsDir);
+      }
+    }
+    // Also remove legacy bmad folder if it exists
+    const bmadFolder = path.join(commandsDir, 'bmad');
+    if (await fs.pathExists(bmadFolder)) {
+      await fs.remove(bmadFolder);
       console.log(chalk.dim(`  Removed old BMAD commands from ${this.name}`));
     }
   }
@@ -51,49 +57,31 @@ class CursorSetup extends BaseIdeSetup {
     // Create .cursor/commands directory structure
     const cursorDir = path.join(projectDir, this.configDir);
     const commandsDir = path.join(cursorDir, this.commandsDir);
-    const bmadCommandsDir = path.join(commandsDir, 'bmad');
+    await this.ensureDir(commandsDir);
 
-    await this.ensureDir(bmadCommandsDir);
+    // Use colon format: files written directly to commands dir (no bmad subfolder)
+    // Creates: .cursor/commands/bmad:bmm:pm.md
 
     // Generate agent launchers using AgentCommandGenerator
     // This creates small launcher files that reference the actual agents in _bmad/
     const agentGen = new AgentCommandGenerator(this.bmadFolderName);
     const { artifacts: agentArtifacts, counts: agentCounts } = await agentGen.collectAgentArtifacts(bmadDir, options.selectedModules || []);
 
-    // Create directories for each module
-    const modules = new Set();
-    for (const artifact of agentArtifacts) {
-      modules.add(artifact.module);
-    }
-
-    for (const module of modules) {
-      await this.ensureDir(path.join(bmadCommandsDir, module));
-      await this.ensureDir(path.join(bmadCommandsDir, module, 'agents'));
-    }
-
-    // Write agent launcher files
-    const agentCount = await agentGen.writeAgentLaunchers(bmadCommandsDir, agentArtifacts);
+    // Write agent launcher files using flat colon naming
+    // Creates files like: bmad:bmm:pm.md
+    const agentCount = await agentGen.writeColonArtifacts(commandsDir, agentArtifacts);
 
     // Generate workflow commands from manifest (if it exists)
     const workflowGen = new WorkflowCommandGenerator(this.bmadFolderName);
     const { artifacts: workflowArtifacts } = await workflowGen.collectWorkflowArtifacts(bmadDir);
 
-    // Write only workflow-command artifacts, skip workflow-launcher READMEs
-    let workflowCommandCount = 0;
-    for (const artifact of workflowArtifacts) {
-      if (artifact.type === 'workflow-command') {
-        const moduleWorkflowsDir = path.join(bmadCommandsDir, artifact.module, 'workflows');
-        await this.ensureDir(moduleWorkflowsDir);
-        const commandPath = path.join(moduleWorkflowsDir, path.basename(artifact.relativePath));
-        await this.writeFile(commandPath, artifact.content);
-        workflowCommandCount++;
-      }
-      // Skip workflow-launcher READMEs as they would be treated as slash commands
-    }
+    // Write workflow-command artifacts using flat colon naming
+    // Creates files like: bmad:bmm:correct-course.md
+    const workflowCommandCount = await workflowGen.writeColonArtifacts(commandsDir, workflowArtifacts);
 
     // Generate task and tool commands from manifests (if they exist)
     const taskToolGen = new TaskToolCommandGenerator();
-    const taskToolResult = await taskToolGen.generateTaskToolCommands(projectDir, bmadDir, bmadCommandsDir);
+    const taskToolResult = await taskToolGen.generateColonTaskToolCommands(projectDir, bmadDir, commandsDir);
 
     console.log(chalk.green(`✓ ${this.name} configured:`));
     console.log(chalk.dim(`  - ${agentCount} agents installed`));
@@ -107,7 +95,7 @@ class CursorSetup extends BaseIdeSetup {
         ),
       );
     }
-    console.log(chalk.dim(`  - Commands directory: ${path.relative(projectDir, bmadCommandsDir)}`));
+    console.log(chalk.dim(`  - Commands directory: ${path.relative(projectDir, commandsDir)}`));
 
     return {
       success: true,
@@ -127,13 +115,13 @@ class CursorSetup extends BaseIdeSetup {
    * @returns {Object|null} Info about created command
    */
   async installCustomAgentLauncher(projectDir, agentName, agentPath, metadata) {
-    const customAgentsDir = path.join(projectDir, this.configDir, this.commandsDir, 'bmad', 'custom', 'agents');
+    const commandsDir = path.join(projectDir, this.configDir, this.commandsDir);
 
     if (!(await this.exists(path.join(projectDir, this.configDir)))) {
       return null; // IDE not configured for this project
     }
 
-    await this.ensureDir(customAgentsDir);
+    await this.ensureDir(commandsDir);
 
     const launcherContent = `You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
 
@@ -156,12 +144,15 @@ description: '${agentName} agent'
 ${launcherContent}
 `;
 
-    const launcherPath = path.join(customAgentsDir, `${agentName}.md`);
+    // Use colon format: bmad:custom:agents:fred-commit-poet.md
+    // Written directly to commands dir (no bmad subfolder)
+    const launcherName = customAgentColonName(agentName);
+    const launcherPath = path.join(commandsDir, launcherName);
     await this.writeFile(launcherPath, commandContent);
 
     return {
       path: launcherPath,
-      command: `/bmad/custom/agents/${agentName}`,
+      command: `/${launcherName.replace('.md', '')}`,
     };
   }
 }

tools/cli/installers/lib/ide/roo.js

@@ -2,6 +2,7 @@ const path = require('node:path');
 const { BaseIdeSetup } = require('./_base-ide');
 const chalk = require('chalk');
 const { AgentCommandGenerator } = require('./shared/agent-command-generator');
+const { toDashPath, customAgentDashName } = require('./shared/path-utils');
 
 /**
  * Roo IDE setup handler
@@ -35,7 +36,8 @@ class RooSetup extends BaseIdeSetup {
     let skippedCount = 0;
 
     for (const artifact of agentArtifacts) {
-      const commandName = `bmad-${artifact.module}-agent-${artifact.name}`;
+      // Use shared toDashPath to get consistent naming: bmad-bmm-name.md
+      const commandName = toDashPath(artifact.relativePath).replace('.md', '');
       const commandPath = path.join(rooCommandsDir, `${commandName}.md`);
 
       // Skip if already exists
@@ -71,7 +73,7 @@ class RooSetup extends BaseIdeSetup {
     if (skippedCount > 0) {
       console.log(chalk.dim(`  - ${skippedCount} commands skipped (already exist)`));
     }
-    console.log(chalk.dim(`  - Commands directory: ${this.configDir}/${this.commandsDir}/bmad/`));
+    console.log(chalk.dim(`  - Commands directory: ${this.configDir}/${this.commandsDir}/`));
     console.log(chalk.dim(`  Commands will be available when you open this project in Roo Code`));
 
     return {
@@ -222,7 +224,8 @@ class RooSetup extends BaseIdeSetup {
     const rooCommandsDir = path.join(projectDir, this.configDir, this.commandsDir);
     await this.ensureDir(rooCommandsDir);
 
-    const commandName = `bmad-custom-agent-${agentName.toLowerCase()}`;
+    // Use dash format: bmad-custom-agents-fred-commit-poet.md
+    const commandName = customAgentDashName(agentName).replace('.md', '');
     const commandPath = path.join(rooCommandsDir, `${commandName}.md`);
 
     // Check if command already exists

tools/cli/installers/lib/ide/shared/agent-command-generator.js

@@ -1,6 +1,7 @@
 const path = require('node:path');
 const fs = require('fs-extra');
 const chalk = require('chalk');
+const { toColonPath, toDashPath, customAgentColonName, customAgentDashName } = require('./path-utils');
 
 /**
  * Generates launcher command files for each agent
@@ -91,6 +92,74 @@ class AgentCommandGenerator {
 
     return writtenCount;
   }
+
+  /**
+   * Write agent launcher artifacts using COLON format (for folder-based IDEs)
+   * Creates flat files like: bmad:bmm:pm.md
+   *
+   * @param {string} baseCommandsDir - Base commands directory for the IDE
+   * @param {Array} artifacts - Agent launcher artifacts
+   * @returns {number} Count of launchers written
+   */
+  async writeColonArtifacts(baseCommandsDir, artifacts) {
+    let writtenCount = 0;
+
+    for (const artifact of artifacts) {
+      if (artifact.type === 'agent-launcher') {
+        // Convert relativePath to colon format: bmm/agents/pm.md → bmad:bmm:pm.md
+        const flatName = toColonPath(artifact.relativePath);
+        const launcherPath = path.join(baseCommandsDir, flatName);
+        await fs.ensureDir(path.dirname(launcherPath));
+        await fs.writeFile(launcherPath, artifact.content);
+        writtenCount++;
+      }
+    }
+
+    return writtenCount;
+  }
+
+  /**
+   * Write agent launcher artifacts using DASH format (for flat IDEs)
+   * Creates flat files like: bmad-bmm-pm.md
+   *
+   * @param {string} baseCommandsDir - Base commands directory for the IDE
+   * @param {Array} artifacts - Agent launcher artifacts
+   * @returns {number} Count of launchers written
+   */
+  async writeDashArtifacts(baseCommandsDir, artifacts) {
+    let writtenCount = 0;
+
+    for (const artifact of artifacts) {
+      if (artifact.type === 'agent-launcher') {
+        // Convert relativePath to dash format: bmm/agents/pm.md → bmad-bmm-pm.md
+        const flatName = toDashPath(artifact.relativePath);
+        const launcherPath = path.join(baseCommandsDir, flatName);
+        await fs.ensureDir(path.dirname(launcherPath));
+        await fs.writeFile(launcherPath, artifact.content);
+        writtenCount++;
+      }
+    }
+
+    return writtenCount;
+  }
+
+  /**
+   * Get the custom agent name in colon format
+   * @param {string} agentName - Custom agent name
+   * @returns {string} Colon-formatted filename
+   */
+  getCustomAgentColonName(agentName) {
+    return customAgentColonName(agentName);
+  }
+
+  /**
+   * Get the custom agent name in dash format
+   * @param {string} agentName - Custom agent name
+   * @returns {string} Dash-formatted filename
+   */
+  getCustomAgentDashName(agentName) {
+    return customAgentDashName(agentName);
+  }
 }
 
 module.exports = { AgentCommandGenerator };

tools/cli/installers/lib/ide/shared/path-utils.js

@@ -0,0 +1,153 @@
+/**
+ * Path transformation utilities for IDE installer standardization
+ *
+ * Provides utilities to convert hierarchical paths to flat naming conventions.
+ * - Colon format (bmad:module:name.md) for folder-based IDEs converting to flat
+ * - Dash format (bmad-module-name.md) for already-flat IDEs
+ */
+
+// Type segments to filter out from paths
+const TYPE_SEGMENTS = ['agents', 'workflows', 'tasks', 'tools'];
+
+/**
+ * Convert hierarchical path to flat colon-separated name (for folder-based IDEs)
+ * Converts: 'bmm/agents/pm.md' → 'bmad:bmm:pm.md'
+ * Converts: 'bmm/workflows/correct-course.md' → 'bmad:bmm:correct-course.md'
+ *
+ * @param {string} module - Module name (e.g., 'bmm', 'core')
+ * @param {string} type - Artifact type ('agents', 'workflows', 'tasks', 'tools') - filtered out
+ * @param {string} name - Artifact name (e.g., 'pm', 'correct-course')
+ * @returns {string} Flat filename like 'bmad:bmm:pm.md'
+ */
+function toColonName(module, type, name) {
+  return `bmad:${module}:${name}.md`;
+}
+
+/**
+ * Convert relative path to flat colon-separated name (for folder-based IDEs)
+ * Converts: 'bmm/agents/pm.md' → 'bmad:bmm:pm.md'
+ * Converts: 'bmm/workflows/correct-course.md' → 'bmad:bmm:correct-course.md'
+ *
+ * @param {string} relativePath - Path like 'bmm/agents/pm.md'
+ * @returns {string} Flat filename like 'bmad:bmm:pm.md'
+ */
+function toColonPath(relativePath) {
+  const withoutExt = relativePath.replace('.md', '');
+  const parts = withoutExt.split(/[/\\]/);
+  // Filter out type segments (agents, workflows, tasks, tools)
+  const filtered = parts.filter((p) => !TYPE_SEGMENTS.includes(p));
+  return `bmad:${filtered.join(':')}.md`;
+}
+
+/**
+ * Convert hierarchical path to flat dash-separated name (for flat IDEs)
+ * Converts: 'bmm/agents/pm.md' → 'bmad-bmm-pm.md'
+ * Converts: 'bmm/workflows/correct-course.md' → 'bmad-bmm-correct-course.md'
+ *
+ * @param {string} relativePath - Path like 'bmm/agents/pm.md'
+ * @returns {string} Flat filename like 'bmad-bmm-pm.md'
+ */
+function toDashPath(relativePath) {
+  const withoutExt = relativePath.replace('.md', '');
+  const parts = withoutExt.split(/[/\\]/);
+  // Filter out type segments (agents, workflows, tasks, tools)
+  const filtered = parts.filter((p) => !TYPE_SEGMENTS.includes(p));
+  return `bmad-${filtered.join('-')}.md`;
+}
+
+/**
+ * Create custom agent colon name (for folder-based IDEs)
+ * Creates: 'bmad:custom:fred-commit-poet.md'
+ *
+ * @param {string} agentName - Custom agent name
+ * @returns {string} Flat filename like 'bmad:custom:fred-commit-poet.md'
+ */
+function customAgentColonName(agentName) {
+  return `bmad:custom:${agentName}.md`;
+}
+
+/**
+ * Create custom agent dash name (for flat IDEs)
+ * Creates: 'bmad-custom-fred-commit-poet.md'
+ *
+ * @param {string} agentName - Custom agent name
+ * @returns {string} Flat filename like 'bmad-custom-fred-commit-poet.md'
+ */
+function customAgentDashName(agentName) {
+  return `bmad-custom-${agentName}.md`;
+}
+
+/**
+ * Check if a filename uses colon format
+ * @param {string} filename - Filename to check
+ * @returns {boolean} True if filename uses colon format
+ */
+function isColonFormat(filename) {
+  return filename.includes('bmad:') && filename.includes(':');
+}
+
+/**
+ * Check if a filename uses dash format
+ * @param {string} filename - Filename to check
+ * @returns {boolean} True if filename uses dash format
+ */
+function isDashFormat(filename) {
+  return filename.startsWith('bmad-') && !filename.includes(':');
+}
+
+/**
+ * Extract parts from a colon-formatted filename
+ * Parses: 'bmad:bmm:pm.md' → { prefix: 'bmad', module: 'bmm', name: 'pm' }
+ *
+ * @param {string} filename - Colon-formatted filename
+ * @returns {Object|null} Parsed parts or null if invalid format
+ */
+function parseColonName(filename) {
+  const withoutExt = filename.replace('.md', '');
+  const parts = withoutExt.split(':');
+
+  if (parts.length < 3 || parts[0] !== 'bmad') {
+    return null;
+  }
+
+  return {
+    prefix: parts[0],
+    module: parts[1],
+    name: parts.slice(2).join(':'), // Handle names that might contain colons
+  };
+}
+
+/**
+ * Extract parts from a dash-formatted filename
+ * Parses: 'bmad-bmm-pm.md' → { prefix: 'bmad', module: 'bmm', name: 'pm' }
+ *
+ * @param {string} filename - Dash-formatted filename
+ * @returns {Object|null} Parsed parts or null if invalid format
+ */
+function parseDashName(filename) {
+  const withoutExt = filename.replace('.md', '');
+  const parts = withoutExt.split('-');
+
+  if (parts.length < 3 || parts[0] !== 'bmad') {
+    return null;
+  }
+
+  return {
+    prefix: parts[0],
+    module: parts[1],
+    name: parts.slice(2).join('-'), // Handle names that might contain dashes
+  };
+}
+
+module.exports = {
+  toColonName,
+  toColonPath,
+  toDashPath,
+  customAgentColonName,
+  customAgentDashName,
+  isColonFormat,
+  isDashFormat,
+  parseColonName,
+  parseDashName,
+  TYPE_SEGMENTS,
+};

tools/cli/installers/lib/ide/shared/task-tool-command-generator.js

@@ -2,6 +2,7 @@ const path = require('node:path');
 const fs = require('fs-extra');
 const csv = require('csv-parse/sync');
 const chalk = require('chalk');
+const { toColonName, toColonPath, toDashPath } = require('./path-utils');
 
 /**
  * Generates command files for standalone tasks and tools
@@ -114,6 +115,154 @@ Follow all instructions in the ${type} file exactly as written.
       skip_empty_lines: true,
     });
   }
+
+  /**
+   * Generate task and tool commands using COLON format (for folder-based IDEs)
+   * Creates flat files like: bmad:bmm:bmad-help.md
+   *
+   * @param {string} projectDir - Project directory
+   * @param {string} bmadDir - BMAD installation directory
+   * @param {string} baseCommandsDir - Base commands directory for the IDE
+   * @returns {Object} Generation results
+   */
+  async generateColonTaskToolCommands(projectDir, bmadDir, baseCommandsDir) {
+    const tasks = await this.loadTaskManifest(bmadDir);
+    const tools = await this.loadToolManifest(bmadDir);
+
+    // Filter to only standalone items
+    const standaloneTasks = tasks ? tasks.filter((t) => t.standalone === 'true' || t.standalone === true) : [];
+    const standaloneTools = tools ? tools.filter((t) => t.standalone === 'true' || t.standalone === true) : [];
+
+    let generatedCount = 0;
+
+    // Generate command files for tasks
+    for (const task of standaloneTasks) {
+      const commandContent = this.generateCommandContent(task, 'task');
+      // Use colon format: bmad:bmm:name.md
+      const flatName = toColonName(task.module, 'tasks', task.name);
+      const commandPath = path.join(baseCommandsDir, flatName);
+      await fs.ensureDir(path.dirname(commandPath));
+      await fs.writeFile(commandPath, commandContent);
+      generatedCount++;
+    }
+
+    // Generate command files for tools
+    for (const tool of standaloneTools) {
+      const commandContent = this.generateCommandContent(tool, 'tool');
+      // Use colon format: bmad:bmm:name.md
+      const flatName = toColonName(tool.module, 'tools', tool.name);
+      const commandPath = path.join(baseCommandsDir, flatName);
+      await fs.ensureDir(path.dirname(commandPath));
+      await fs.writeFile(commandPath, commandContent);
+      generatedCount++;
+    }
+
+    return {
+      generated: generatedCount,
+      tasks: standaloneTasks.length,
+      tools: standaloneTools.length,
+    };
+  }
+
+  /**
+   * Generate task and tool commands using DASH format (for flat IDEs)
+   * Creates flat files like: bmad-bmm-bmad-help.md
+   *
+   * @param {string} projectDir - Project directory
+   * @param {string} bmadDir - BMAD installation directory
+   * @param {string} baseCommandsDir - Base commands directory for the IDE
+   * @returns {Object} Generation results
+   */
+  async generateDashTaskToolCommands(projectDir, bmadDir, baseCommandsDir) {
+    const tasks = await this.loadTaskManifest(bmadDir);
+    const tools = await this.loadToolManifest(bmadDir);
+
+    // Filter to only standalone items
+    const standaloneTasks = tasks ? tasks.filter((t) => t.standalone === 'true' || t.standalone === true) : [];
+    const standaloneTools = tools ? tools.filter((t) => t.standalone === 'true' || t.standalone === true) : [];
+
+    let generatedCount = 0;
+
+    // Generate command files for tasks
+    for (const task of standaloneTasks) {
+      const commandContent = this.generateCommandContent(task, 'task');
+      // Use dash format: bmad-bmm-name.md
+      const flatName = toDashPath(`${task.module}/tasks/${task.name}.md`);
+      const commandPath = path.join(baseCommandsDir, flatName);
+      await fs.ensureDir(path.dirname(commandPath));
+      await fs.writeFile(commandPath, commandContent);
+      generatedCount++;
+    }
+
+    // Generate command files for tools
+    for (const tool of standaloneTools) {
+      const commandContent = this.generateCommandContent(tool, 'tool');
+      // Use dash format: bmad-bmm-name.md
+      const flatName = toDashPath(`${tool.module}/tools/${tool.name}.md`);
+      const commandPath = path.join(baseCommandsDir, flatName);
+      await fs.ensureDir(path.dirname(commandPath));
+      await fs.writeFile(commandPath, commandContent);
+      generatedCount++;
+    }
+
+    return {
+      generated: generatedCount,
+      tasks: standaloneTasks.length,
+      tools: standaloneTools.length,
+    };
+  }
+
+  /**
+   * Write task/tool artifacts using COLON format (for folder-based IDEs)
+   * Creates flat files like: bmad:bmm:bmad-help.md
+   *
+   * @param {string} baseCommandsDir - Base commands directory for the IDE
+   * @param {Array} artifacts - Task/tool artifacts with relativePath
+   * @returns {number} Count of commands written
+   */
+  async writeColonArtifacts(baseCommandsDir, artifacts) {
+    let writtenCount = 0;
+
+    for (const artifact of artifacts) {
+      if (artifact.type === 'task' || artifact.type === 'tool') {
+        const commandContent = this.generateCommandContent(artifact, artifact.type);
+        // Use colon format: bmad:module:name.md
+        const flatName = toColonPath(artifact.relativePath);
+        const commandPath = path.join(baseCommandsDir, flatName);
+        await fs.ensureDir(path.dirname(commandPath));
+        await fs.writeFile(commandPath, commandContent);
+        writtenCount++;
+      }
+    }
+
+    return writtenCount;
+  }
+
+  /**
+   * Write task/tool artifacts using DASH format (for flat IDEs)
+   * Creates flat files like: bmad-bmm-bmad-help.md
+   *
+   * @param {string} baseCommandsDir - Base commands directory for the IDE
+   * @param {Array} artifacts - Task/tool artifacts with relativePath
+   * @returns {number} Count of commands written
+   */
+  async writeDashArtifacts(baseCommandsDir, artifacts) {
+    let writtenCount = 0;
+
+    for (const artifact of artifacts) {
+      if (artifact.type === 'task' || artifact.type === 'tool') {
+        const commandContent = this.generateCommandContent(artifact, artifact.type);
+        // Use dash format: bmad-module-name.md
+        const flatName = toDashPath(artifact.relativePath);
+        const commandPath = path.join(baseCommandsDir, flatName);
+        await fs.ensureDir(path.dirname(commandPath));
+        await fs.writeFile(commandPath, commandContent);
+        writtenCount++;
+      }
+    }
+
+    return writtenCount;
+  }
 }
 
 module.exports = { TaskToolCommandGenerator };

tools/cli/installers/lib/ide/shared/workflow-command-generator.js

@@ -2,6 +2,7 @@ const path = require('node:path');
 const fs = require('fs-extra');
 const csv = require('csv-parse/sync');
 const chalk = require('chalk');
+const { toColonPath, toDashPath, customAgentColonName, customAgentDashName } = require('./path-utils');
 
 /**
  * Generates command files for each workflow in the manifest
@@ -237,6 +238,56 @@ When running any workflow:
       skip_empty_lines: true,
     });
   }
+
+  /**
+   * Write workflow command artifacts using COLON format (for folder-based IDEs)
+   * Creates flat files like: bmad:bmm:correct-course.md
+   *
+   * @param {string} baseCommandsDir - Base commands directory for the IDE
+   * @param {Array} artifacts - Workflow artifacts
+   * @returns {number} Count of commands written
+   */
+  async writeColonArtifacts(baseCommandsDir, artifacts) {
+    let writtenCount = 0;
+
+    for (const artifact of artifacts) {
+      if (artifact.type === 'workflow-command') {
+        // Convert relativePath to colon format: bmm/workflows/correct-course.md → bmad:bmm:correct-course.md
+        const flatName = toColonPath(artifact.relativePath);
+        const commandPath = path.join(baseCommandsDir, flatName);
+        await fs.ensureDir(path.dirname(commandPath));
+        await fs.writeFile(commandPath, artifact.content);
+        writtenCount++;
+      }
+    }
+
+    return writtenCount;
+  }
+
+  /**
+   * Write workflow command artifacts using DASH format (for flat IDEs)
+   * Creates flat files like: bmad-bmm-correct-course.md
+   *
+   * @param {string} baseCommandsDir - Base commands directory for the IDE
+   * @param {Array} artifacts - Workflow artifacts
+   * @returns {number} Count of commands written
+   */
+  async writeDashArtifacts(baseCommandsDir, artifacts) {
+    let writtenCount = 0;
+
+    for (const artifact of artifacts) {
+      if (artifact.type === 'workflow-command') {
+        // Convert relativePath to dash format: bmm/workflows/correct-course.md → bmad-bmm-correct-course.md
+        const flatName = toDashPath(artifact.relativePath);
+        const commandPath = path.join(baseCommandsDir, flatName);
+        await fs.ensureDir(path.dirname(commandPath));
+        await fs.writeFile(commandPath, artifact.content);
+        writtenCount++;
+      }
+    }
+
+    return writtenCount;
+  }
 }
 
 module.exports = { WorkflowCommandGenerator };