bmad-method 6.0.0-alpha.1 → 6.0.0-alpha.10

package/src/modules/bmm/testarch/README.md

@@ -1,311 +0,0 @@
----
-last-redoc-date: 2025-10-14
----
-
-# Test Architect (TEA) Agent Guide
-
-## Overview
-
-- **Persona:** Murat, Master Test Architect and Quality Advisor focused on risk-based testing, fixture architecture, ATDD, and CI/CD governance.
-- **Mission:** Deliver actionable quality strategies, automation coverage, and gate decisions that scale with project level and compliance demands.
-- **Use When:** Project level ≥2, integration risk is non-trivial, brownfield regression risk exists, or compliance/NFR evidence is required.
-
-## TEA Workflow Lifecycle
-
-TEA integrates across the entire BMad development lifecycle, providing quality assurance at every phase:
-
-```
-┌──────────────────────────────────────────────────────────┐
-│             BMM Phase 2: PLANNING                        │
-│                                                          │
-│  PM: *prd                                       │
-│       ↓                                                  │
-│  TEA: *framework ──→ *ci ──→ *test-design                │
-│       └─────────┬─────────────┘                          │
-│                 │ (Setup once per project)               │
-└─────────────────┼──────────────────────────────────────────┘
-                  ↓
-┌──────────────────────────────────────────────────────────┐
-│            BMM Phase 4: IMPLEMENTATION                   │
-│                  (Per Story Cycle)                       │
-│                                                          │
-│  ┌─→ SM: *create-story                                  │
-│  │        ↓                                              │
-│  │   TEA: *atdd (optional, before dev)                  │
-│  │        ↓                                              │
-│  │   DEV: implements story                               │
-│  │        ↓                                              │
-│  │   TEA: *automate ──→ *test-review (optional)         │
-│  │        ↓                                              │
-│  │   TEA: *trace (refresh coverage)                     │
-│  │        ↓                                              │
-│  └───[next story]                                        │
-└─────────────────┼──────────────────────────────────────────┘
-                  ↓
-┌──────────────────────────────────────────────────────────┐
-│                EPIC/RELEASE GATE                         │
-│                                                          │
-│  TEA: *nfr-assess (if not done earlier)                 │
-│       ↓                                                  │
-│  TEA: *test-review (final audit, optional)              │
-│       ↓                                                  │
-│  TEA: *trace (Phase 2: Gate) ──→ PASS | CONCERNS | FAIL | WAIVED │
-│                                                          │
-└──────────────────────────────────────────────────────────┘
-```
-
-### TEA Integration with BMad v6 Workflow
-
-TEA operates **across all four BMad phases**, unlike other agents that are phase-specific:
-
-<details>
-<summary><strong>Cross-Phase Integration & Workflow Complexity</strong></summary>
-
-### Phase-Specific Agents (Standard Pattern)
-
-- **Phase 1 (Analysis)**: Analyst agent
-- **Phase 2 (Planning)**: PM agent
-- **Phase 3 (Solutioning)**: Architect agent
-- **Phase 4 (Implementation)**: SM, DEV agents
-
-### TEA: Cross-Phase Quality Agent (Unique Pattern)
-
-TEA is **the only agent that spans all phases**:
-
-```
-Phase 1 (Analysis) → [TEA not typically used]
-    ↓
-Phase 2 (Planning) → TEA: *framework, *ci, *test-design (setup)
-    ↓
-Phase 3 (Solutioning) → [TEA validates architecture testability]
-    ↓
-Phase 4 (Implementation) → TEA: *atdd, *automate, *test-review, *trace (per story)
-    ↓
-Epic/Release Gate → TEA: *nfr-assess, *trace Phase 2 (release decision)
-```
-
-### Why TEA Needs 8 Workflows
-
-**Standard agents**: 1-3 workflows per phase
-**TEA**: 8 workflows across 3+ phases
-
-| Phase       | TEA Workflows                          | Frequency        | Purpose                          |
-| ----------- | -------------------------------------- | ---------------- | -------------------------------- |
-| **Phase 2** | *framework, *ci, \*test-design         | Once per project | Establish quality infrastructure |
-| **Phase 4** | *atdd, *automate, *test-review, *trace | Per story/sprint | Continuous quality validation    |
-| **Release** | *nfr-assess, *trace (Phase 2: gate)    | Per epic/release | Go/no-go decision                |
-
-**Note**: `*trace` is a two-phase workflow: Phase 1 (traceability) + Phase 2 (gate decision). This reduces cognitive load while maintaining natural workflow.
-
-This complexity **requires specialized documentation** (this guide), **extensive knowledge base** (19+ fragments), and **unique architecture** (`testarch/` directory).
-
-</details>
-
-## Prerequisites and Setup
-
-1. Run the core planning workflows first:
-   - Analyst `*product-brief`
-   - Product Manager `*prd`
-   - Architect `*create-architecture`
-2. Confirm `bmad/bmm/config.yaml` defines `project_name`, `output_folder`, `dev_story_location`, and language settings.
-3. Ensure a test test framework setup exists; if not, use `*framework` command to create a test framework setup, prior to development.
-4. Skim supporting references (knowledge under `testarch/`, command workflows under `workflows/testarch/`).
-   - `tea-index.csv` + `knowledge/*.md`
-
-## High-Level Cheat Sheets
-
-### Greenfield Feature Launch (Level 2)
-
-| Phase              | Test Architect                                                            | Dev / Team                                                            | Outputs                                                                      |
-| ------------------ | ------------------------------------------------------------------------- | --------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
-| Setup              | -                                                                         | Analyst `*product-brief`, PM `*prd`, Architect `*create-architecture` | `{output_folder}/product-brief*.md`, `PRD.md`, `epics.md`, `architecture.md` |
-| Pre-Implementation | Run `*framework` (if harness missing), `*ci`, and `*test-design`          | Review risk/design/CI guidance, align backlog                         | Test scaffold, CI pipeline, risk and coverage strategy                       |
-| Story Prep         | -                                                                         | Scrum Master `*create-story`, `*story-context`                        | Story markdown + context XML                                                 |
-| Implementation     | (Optional) Trigger `*atdd` before dev to supply failing tests + checklist | Implement story guided by ATDD checklist                              | Failing acceptance tests + implementation checklist                          |
-| Post-Dev           | Execute `*automate`, (Optional) `*test-review`, re-run `*trace`           | Address recommendations, update code/tests                            | Regression specs, quality report, refreshed coverage matrix                  |
-| Release            | (Optional) `*test-review` for final audit, Run `*trace` (Phase 2)         | Confirm Definition of Done, share release notes                       | Quality audit, Gate YAML + release summary (owners, waivers)                 |
-
-<details>
-<summary>Execution Notes</summary>
-
-- Run `*framework` only once per repo or when modern harness support is missing.
-- `*framework` followed by `*ci` establishes install + pipeline; `*test-design` then handles risk scoring, mitigations, and scenario planning in one pass.
-- Use `*atdd` before coding when the team can adopt ATDD; share its checklist with the dev agent.
-- Post-implementation, keep `*trace` current, expand coverage with `*automate`, optionally review test quality with `*test-review`. For release gate, run `*trace` with Phase 2 enabled to get deployment decision.
-- Use `*test-review` after `*atdd` to validate generated tests, after `*automate` to ensure regression quality, or before gate for final audit.
-
-</details>
-
-<details>
-<summary>Worked Example – “Nova CRM” Greenfield Feature</summary>
-
-1. **Planning:** Analyst runs `*product-brief`; PM executes `*prd` to produce PRD and epics; Architect completes `*create-architecture` for the new module.
-2. **Setup:** TEA checks harness via `*framework`, configures `*ci`, and runs `*test-design` to capture risk/coverage plans.
-3. **Story Prep:** Scrum Master generates the story via `*create-story`; PO validates using `*solutioning-gate-check`.
-4. **Implementation:** TEA optionally runs `*atdd`; Dev implements with guidance from failing tests and the plan.
-5. **Post-Dev and Release:** TEA runs `*automate`, optionally `*test-review` to audit test quality, re-runs `*trace` with Phase 2 enabled to generate both traceability and gate decision.
-
-</details>
-
-### Brownfield Feature Enhancement (Level 3–4)
-
-| Phase             | Test Architect                                                                         | Dev / Team                                                   | Outputs                                                                 |
-| ----------------- | -------------------------------------------------------------------------------------- | ------------------------------------------------------------ | ----------------------------------------------------------------------- |
-| Refresh Context   | -                                                                                      | Analyst/PM/Architect rerun planning workflows                | Updated planning artifacts in `{output_folder}`                         |
-| Baseline Coverage | Run `*trace` to inventory existing tests                                               | Review matrix, flag hotspots                                 | Coverage matrix + initial gate snippet                                  |
-| Risk Targeting    | Run `*test-design`                                                                     | Align remediation/backlog priorities                         | Brownfield risk memo + scenario matrix                                  |
-| Story Prep        | -                                                                                      | Scrum Master `*create-story`                                 | Updated story markdown                                                  |
-| Implementation    | (Optional) Run `*atdd` before dev                                                      | Implement story, referencing checklist/tests                 | Failing acceptance tests + implementation checklist                     |
-| Post-Dev          | Apply `*automate`, (Optional) `*test-review`, re-run `*trace`, `*nfr-assess` if needed | Resolve gaps, update docs/tests                              | Regression specs, quality report, refreshed coverage matrix, NFR report |
-| Release           | (Optional) `*test-review` for final audit, Run `*trace` (Phase 2)                      | Product Owner `*solutioning-gate-check`, share release notes | Quality audit, Gate YAML + release summary                              |
-
-<details>
-<summary>Execution Notes</summary>
-
-- Lead with `*trace` so remediation plans target true coverage gaps. Ensure `*framework` and `*ci` are in place early in the engagement; if the brownfield lacks them, run those setup steps immediately after refreshing context.
-- `*test-design` should highlight regression hotspots, mitigations, and P0 scenarios.
-- Use `*atdd` when stories benefit from ATDD; otherwise proceed to implementation and rely on post-dev automation.
-- After development, expand coverage with `*automate`, optionally review test quality with `*test-review`, re-run `*trace` (Phase 2 for gate decision). Run `*nfr-assess` now if non-functional risks weren't addressed earlier.
-- Use `*test-review` to validate existing brownfield tests or audit new tests before gate.
-- Product Owner `*solutioning-gate-check` confirms the team has artifacts before handoff or release.
-
-</details>
-
-<details>
-<summary>Worked Example – “Atlas Payments” Brownfield Story</summary>
-
-1. **Context Refresh:** Analyst reruns `*product-brief`; PM executes `*prd` to update PRD, analysis, and `epics.md`; Architect triggers `*create-architecture` capturing legacy payment flows.
-2. **Baseline Coverage:** TEA executes `*trace` to record current coverage in `docs/qa/assessments/atlas-payment-trace.md`.
-3. **Risk and Design:** `*test-design` flags settlement edge cases, plans mitigations, and allocates new API/E2E scenarios with P0 priorities.
-4. **Story Prep:** Scrum Master generates `stories/story-1.1.md` via `*create-story`, automatically pulling updated context.
-5. **ATDD First:** TEA runs `*atdd`, producing failing Playwright specs under `tests/e2e/payments/` plus an implementation checklist.
-6. **Implementation:** Dev pairs with the checklist/tests to deliver the story.
-7. **Post-Implementation:** TEA applies `*automate`, optionally `*test-review` to audit test quality, re-runs `*trace` with Phase 2 enabled, performs `*nfr-assess` to validate SLAs. The `*trace` Phase 2 output marks PASS with follow-ups.
-
-</details>
-
-### Enterprise / Compliance Program (Level 4)
-
-| Phase               | Test Architect                                                    | Dev / Team                                     | Outputs                                                    |
-| ------------------- | ----------------------------------------------------------------- | ---------------------------------------------- | ---------------------------------------------------------- |
-| Strategic Planning  | -                                                                 | Analyst/PM/Architect standard workflows        | Enterprise-grade PRD, epics, architecture                  |
-| Quality Planning    | Run `*framework`, `*test-design`, `*nfr-assess`                   | Review guidance, align compliance requirements | Harness scaffold, risk + coverage plan, NFR documentation  |
-| Pipeline Enablement | Configure `*ci`                                                   | Coordinate secrets, pipeline approvals         | `.github/workflows/test.yml`, helper scripts               |
-| Execution           | Enforce `*atdd`, `*automate`, `*test-review`, `*trace` per story  | Implement stories, resolve TEA findings        | Tests, fixtures, quality reports, coverage matrices        |
-| Release             | (Optional) `*test-review` for final audit, Run `*trace` (Phase 2) | Capture sign-offs, archive artifacts           | Quality audit, updated assessments, gate YAML, audit trail |
-
-<details>
-<summary>Execution Notes</summary>
-
-- Use `*atdd` for every story when feasible so acceptance tests lead implementation in regulated environments.
-- `*ci` scaffolds selective testing scripts, burn-in jobs, caching, and notifications for long-running suites.
-- Enforce `*test-review` per story or sprint to maintain quality standards and ensure compliance with testing best practices.
-- Prior to release, rerun coverage (`*trace`, `*automate`), perform final quality audit with `*test-review`, and formalize the decision with `*trace` Phase 2 (gate decision); store everything for audits. Call `*nfr-assess` here if compliance/performance requirements weren't captured during planning.
-
-</details>
-
-<details>
-<summary>Worked Example – “Helios Ledger” Enterprise Release</summary>
-
-1. **Strategic Planning:** Analyst/PM/Architect complete PRD, epics, and architecture using the standard workflows.
-2. **Quality Planning:** TEA runs `*framework`, `*test-design`, and `*nfr-assess` to establish mitigations, coverage, and NFR targets.
-3. **Pipeline Setup:** TEA configures CI via `*ci` with selective execution scripts.
-4. **Execution:** For each story, TEA enforces `*atdd`, `*automate`, `*test-review`, and `*trace`; Dev teams iterate on the findings.
-5. **Release:** TEA re-checks coverage, performs final quality audit with `*test-review`, and logs the final gate decision via `*trace` Phase 2, archiving artifacts for compliance.
-
-</details>
-
-## Command Catalog
-
-<details>
-<summary><strong>Optional Playwright MCP Enhancements</strong></summary>
-
-**Two Playwright MCP servers** (actively maintained, continuously updated):
-
-- `playwright` - Browser automation (`npx @playwright/mcp@latest`)
-- `playwright-test` - Test runner with failure analysis (`npx playwright run-test-mcp-server`)
-
-**How MCP Enhances TEA Workflows**:
-
-MCP provides additional capabilities on top of TEA's default AI-based approach:
-
-1. `*test-design`:
-   - Default: Analysis + documentation
-   - **+ MCP**: Interactive UI discovery with `browser_navigate`, `browser_click`, `browser_snapshot`, behavior observation
-
-   Benefit:Discover actual functionality, edge cases, undocumented features
-
-2. `*atdd`, `*automate`:
-   - Default: Infers selectors and interactions from requirements and knowledge fragments
-   - **+ MCP**: Generates tests **then** verifies with `generator_setup_page`, `browser_*` tools, validates against live app
-
-   Benefit: Accurate selectors from real DOM, verified behavior, refined test code
-
-3. `*automate`:
-   - Default: Pattern-based fixes from error messages + knowledge fragments
-   - **+ MCP**: Pattern fixes **enhanced with** `browser_snapshot`, `browser_console_messages`, `browser_network_requests`, `browser_generate_locator`
-
-   Benefit: Visual failure context, live DOM inspection, root cause discovery
-
-**Config example**:
-
-```json
-{
-  "mcpServers": {
-    "playwright": {
-      "command": "npx",
-      "args": ["@playwright/mcp@latest"]
-    },
-    "playwright-test": {
-      "command": "npx",
-      "args": ["playwright", "run-test-mcp-server"]
-    }
-  }
-}
-```
-
-**To disable**: Set `tea_use_mcp_enhancements: false` in `bmad/bmm/config.yaml` OR remove MCPs from IDE config.
-
-</details>
-
-<br></br>
-
-| Command        | Workflow README                                   | Primary Outputs                                                                               | Notes                                                | With Playwright MCP Enhancements                                                                             |
-| -------------- | ------------------------------------------------- | --------------------------------------------------------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
-| `*framework`   | [📖](../workflows/testarch/framework/README.md)   | Playwright/Cypress scaffold, `.env.example`, `.nvmrc`, sample specs                           | Use when no production-ready harness exists          | -                                                                                                            |
-| `*ci`          | [📖](../workflows/testarch/ci/README.md)          | CI workflow, selective test scripts, secrets checklist                                        | Platform-aware (GitHub Actions default)              | -                                                                                                            |
-| `*test-design` | [📖](../workflows/testarch/test-design/README.md) | Combined risk assessment, mitigation plan, and coverage strategy                              | Risk scoring + optional exploratory mode             | **+ Exploratory**: Interactive UI discovery with browser automation (uncover actual functionality)           |
-| `*atdd`        | [📖](../workflows/testarch/atdd/README.md)        | Failing acceptance tests + implementation checklist                                           | TDD red phase + optional recording mode              | **+ Recording**: AI generation verified with live browser (accurate selectors from real DOM)                 |
-| `*automate`    | [📖](../workflows/testarch/automate/README.md)    | Prioritized specs, fixtures, README/script updates, DoD summary                               | Optional healing/recording, avoid duplicate coverage | **+ Healing**: Pattern fixes enhanced with visual debugging + **+ Recording**: AI verified with live browser |
-| `*test-review` | [📖](../workflows/testarch/test-review/README.md) | Test quality review report with 0-100 score, violations, fixes                                | Reviews tests against knowledge base patterns        | -                                                                                                            |
-| `*nfr-assess`  | [📖](../workflows/testarch/nfr-assess/README.md)  | NFR assessment report with actions                                                            | Focus on security/performance/reliability            | -                                                                                                            |
-| `*trace`       | [📖](../workflows/testarch/trace/README.md)       | Phase 1: Coverage matrix, recommendations. Phase 2: Gate decision (PASS/CONCERNS/FAIL/WAIVED) | Two-phase workflow: traceability + gate decision     | -                                                                                                            |
-
-**📖** = Click to view detailed workflow documentation
-
-## Why TEA is Architecturally Different
-
-TEA is the only BMM agent with its own top-level module directory (`bmm/testarch/`). This intentional design pattern reflects TEA's unique requirements:
-
-<details>
-<summary><strong>Unique Architecture Pattern & Rationale</strong></summary>
-
-### Directory Structure
-
-```
-src/modules/bmm/
-├── agents/
-│   └── tea.agent.yaml          # Agent definition (standard location)
-├── workflows/
-│   └── testarch/               # TEA workflows (standard location)
-└── testarch/                   # Knowledge base (UNIQUE!)
-    ├── knowledge/              # 21 production-ready test pattern fragments
-    ├── tea-index.csv           # Centralized knowledge lookup (21 fragments indexed)
-    └── README.md               # This guide
-```
-
-### Why TEA Gets Special Treatment
-
-TEA uniquely requires **extensive domain knowledge** (21 fragments, 12,821 lines: test patterns, CI/CD, fixtures, quality practices, healing strategies), a **centralized reference system** (`tea-index.csv` for on-demand fragment loading), **cross-cutting concerns** (domain-specific patterns vs project-specific artifacts like PRDs/stories), and **optional MCP integration** (healing, exploratory, verification modes). Other BMM agents don't require this architecture.
-
-</details>

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

@@ -1,38 +0,0 @@
----
-last-redoc-date: 2025-10-01
----
-
-# Game Brainstorming Workflow
-
-This workflow employs structured ideation methodologies to generate and refine game concepts through systematic creative exploration. It leverages five distinct brainstorming techniques—SCAMPER, Mind Mapping, Lotus Blossom, Six Thinking Hats, and Random Word Association—each applied in isolation to produce diverse conceptual approaches. The workflow emphasizes iterative refinement where initial concepts are evaluated against design pillars, technical feasibility, and market positioning to identify the most promising directions.
-
-The system operates through a game-specific context framework that considers platform constraints, target audience characteristics, monetization models, and core gameplay pillars. Each brainstorming method generates distinct artifacts: SCAMPER produces systematic modification analyses, Mind Mapping reveals conceptual hierarchies, Lotus Blossom creates radial expansion patterns, Six Thinking Hats enforces multi-perspective evaluation, and Random Word Association drives lateral thinking breakthroughs. The workflow culminates in a consolidated concept document that synthesizes the strongest elements from each method into cohesive game proposals.
-
-Critical to this workflow is its emphasis on constraint-driven creativity. The game-context.md framework establishes technical boundaries (platform capabilities, performance targets), market parameters (genre conventions, competitive positioning), and design philosophy (accessibility requirements, monetization ethics) that ground creative exploration in practical realities. This prevents ideation from drifting into infeasible territory while maintaining creative ambition.
-
-## Usage
-
-```bash
-bmad bmm 1-analysis brainstorm-game
-```
-
-## Inputs
-
-- **Game Context Document**: Platform specifications, genre preferences, technical constraints, target audience demographics, monetization approach, and core design pillars
-- **Initial Concept Seed** (optional): High-level game idea or theme to guide brainstorming direction
-
-## Outputs
-
-- **Method-Specific Artifacts**: Five separate brainstorming documents, each applying a different ideation methodology to the concept space
-- **Consolidated Concept Document**: Synthesized game concepts with feasibility assessments, unique value propositions, and recommended next steps
-- **Design Pillar Alignment Matrix**: Evaluation of each concept against stated design objectives and technical constraints
-
-## Brainstorming Methods
-
-| Method                  | Focus                    | Output Characteristics             |
-| ----------------------- | ------------------------ | ---------------------------------- |
-| SCAMPER                 | Systematic modification  | Structured transformation analysis |
-| Mind Mapping            | Hierarchical exploration | Visual concept relationships       |
-| Lotus Blossom           | Radial expansion         | Layered thematic development       |
-| Six Thinking Hats       | Multi-perspective        | Balanced evaluation framework      |
-| Random Word Association | Lateral thinking         | Unexpected conceptual combinations |

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

@@ -1,109 +0,0 @@
-<critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.xml</critical>
-<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
-<critical>Communicate all responses in {communication_language}</critical>
-<critical>This is a meta-workflow that orchestrates the CIS brainstorming workflow with game-specific context and additional game design techniques</critical>
-
-<workflow>
-
-  <step n="1" goal="Validate workflow readiness">
-    <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
-      <param>mode: validate</param>
-      <param>calling_workflow: brainstorm-game</param>
-    </invoke-workflow>
-
-    <check if="status_exists == false">
-      <output>{{suggestion}}</output>
-      <output>Note: Game brainstorming is optional. Continuing without progress tracking.</output>
-      <action>Set standalone_mode = true</action>
-    </check>
-
-    <check if="status_exists == true">
-      <action>Store {{status_file_path}} for later updates</action>
-
-      <check if="project_type != 'game'">
-        <output>Note: This is a {{project_type}} project. Game brainstorming is designed for game projects.</output>
-        <ask>Continue with game brainstorming anyway? (y/n)</ask>
-        <check if="n">
-          <action>Exit workflow</action>
-        </check>
-      </check>
-
-      <check if="warning != ''">
-        <output>{{warning}}</output>
-        <output>Note: Game brainstorming can be valuable at any project stage.</output>
-      </check>
-    </check>
-
-  </step>
-
-  <step n="2" goal="Load game brainstorming context and techniques">
-    <action>Read the game context document from: {game_context}</action>
-    <action>This context provides game-specific guidance including:
-      - Focus areas for game ideation (mechanics, narrative, experience, etc.)
-      - Key considerations for game design
-      - Recommended techniques for game brainstorming
-      - Output structure guidance
-    </action>
-    <action>Load game-specific brain techniques from: {game_brain_methods}</action>
-    <action>These additional techniques supplement the standard CIS brainstorming methods with game design-focused approaches like:
-      - MDA Framework exploration
-      - Core loop brainstorming
-      - Player fantasy mining
-      - Genre mashup
-      - And other game-specific ideation methods
-    </action>
-  </step>
-
-  <step n="3" goal="Invoke CIS brainstorming with game context">
-    <action>Execute the CIS brainstorming workflow with game context and additional techniques</action>
-    <invoke-workflow path="{core_brainstorming}" data="{game_context}" techniques="{game_brain_methods}">
-      The CIS brainstorming workflow will:
-      - Merge game-specific techniques with standard techniques
-      - Present interactive brainstorming techniques menu
-      - Guide the user through selected ideation methods
-      - Generate and capture brainstorming session results
-      - Save output to: {output_folder}/brainstorming-session-results-{{date}}.md
-    </invoke-workflow>
-  </step>
-
-  <step n="4" goal="Update status and complete">
-    <check if="standalone_mode != true">
-      <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
-        <param>mode: update</param>
-        <param>action: complete_workflow</param>
-        <param>workflow_name: brainstorm-game</param>
-      </invoke-workflow>
-
-      <check if="success == true">
-        <output>Status updated! Next: {{next_workflow}}</output>
-      </check>
-    </check>
-
-    <output>**✅ Game Brainstorming Session Complete, {user_name}!**
-
-**Session Results:**
-
-- Game brainstorming results saved to: {output_folder}/bmm-brainstorming-session-{{date}}.md
-
-{{#if standalone_mode != true}}
-**Status Updated:**
-
-- Progress tracking updated
-
-**Next Steps:**
-
-- **Next required:** {{next_workflow}} ({{next_agent}} agent)
-- **Optional:** You can run other analysis workflows (research, game-brief) before proceeding
-
-Check status anytime with: `workflow-status`
-{{else}}
-**Next Steps:**
-Since no workflow is in progress:
-
-- Refer to the BMM workflow guide if unsure what to do next
-- Or run `workflow-init` to create a workflow path and get guided next steps
-  {{/if}}
-  </output>
-  </step>
-
-</workflow>

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

@@ -1,29 +0,0 @@
----
-last-redoc-date: 2025-10-01
----
-
-# Project Brainstorming Workflow
-
-This workflow facilitates structured ideation for non-game software projects through systematic exploration of problem spaces, architectures, and implementation strategies. Unlike traditional requirement gathering, it employs creative techniques to uncover non-obvious approaches and identify innovative solutions that address core business needs while considering technical constraints and organizational capabilities.
-
-The workflow operates through a project-specific context framework that captures business objectives, technical environment, stakeholder needs, and organizational constraints. It generates multiple solution vectors through parallel ideation tracks: architectural approaches, user experience paradigms, integration patterns, and value delivery mechanisms. Each track produces concrete proposals that are evaluated against feasibility, impact, and alignment with strategic objectives.
-
-Critical differentiators include its focus on solution innovation rather than requirement enumeration, emphasis on technical-business alignment from inception, and structured approach to surfacing hidden assumptions. The workflow produces actionable outputs that directly feed into Product Brief development, ensuring that creative exploration translates into concrete planning artifacts.
-
-## Usage
-
-```bash
-bmad bmm 1-analysis brainstorm-project
-```
-
-## Inputs
-
-- **Project Context Document**: Business objectives, technical environment, stakeholder landscape, organizational constraints, success criteria, and known pain points
-- **Problem Statement** (optional): Core business challenge or opportunity driving the project
-
-## Outputs
-
-- **Architecture Proposals**: Multiple technical approaches with trade-off analysis and feasibility assessments
-- **Value Delivery Framework**: Prioritized feature concepts aligned with business objectives and user needs
-- **Risk and Opportunity Analysis**: Identified technical dependencies, integration challenges, and innovation opportunities
-- **Strategic Recommendation**: Synthesized direction with rationale and implementation considerations