bmad-method 6.0.0-alpha.2 → 6.0.0-alpha.20

package/src/modules/bmm/tasks/daily-standup.xml

@@ -1,85 +0,0 @@
-<task id="bmad/bmm/tasks/daily-standup.xml" name="Daily Standup">
-  <llm critical="true">
-    <i>MANDATORY: Execute ALL steps in the flow section IN EXACT ORDER</i>
-    <i>DO NOT skip steps or change the sequence</i>
-    <i>HALT immediately when halt-conditions are met</i>
-    <i>Each action tag within a step tag is a REQUIRED action to complete that step</i>
-    <i>Sections outside flow (validation, output, critical-context) provide essential context - review and apply throughout execution</i>
-  </llm>
-  <flow>
-    <step n="1" title="Project Context Discovery">
-      <action>Check for stories folder at {project-root}{output_folder}/stories/</action>
-      <action>Find current story by identifying highest numbered story file</action>
-      <action>Read story status (In Progress, Ready for Review, etc.)</action>
-      <action>Extract agent notes from Dev Agent Record, TEA Results, PO Notes sections</action>
-      <action>Check for next story references from epics</action>
-      <action>Identify blockers from story sections</action>
-    </step>
-
-    <step n="2" title="Initialize Standup with Context">
-      <output>
-        🏃 DAILY STANDUP - Story-{{number}}: {{title}}
-
-        Current Sprint Status:
-        - Active Story: story-{{number}} ({{status}} - {{percentage}}% complete)
-        - Next in Queue: story-{{next-number}}: {{next-title}}
-        - Blockers: {{blockers-from-story}}
-
-        Team assembled based on story participants:
-        {{ List Agents from {project-root}/bmad/_cfg/agent-manifest.csv }}
-      </output>
-    </step>
-
-    <step n="3" title="Structured Standup Discussion">
-      <action>Each agent provides three items referencing real story data</action>
-      <action>What I see: Their perspective on current work, citing story sections (1-2 sentences)</action>
-      <action>What concerns me: Issues from their domain or story blockers (1-2 sentences)</action>
-      <action>What I suggest: Actionable recommendations for progress (1-2 sentences)</action>
-    </step>
-
-    <step n="4" title="Create Standup Summary">
-      <output>
-        📋 STANDUP SUMMARY:
-        Key Items from Story File:
-        - {{completion-percentage}}% complete ({{tasks-complete}}/{{total-tasks}} tasks)
-        - Blocker: {{main-blocker}}
-        - Next: {{next-story-reference}}
-
-        Action Items:
-        - {{agent}}: {{action-item}}
-        - {{agent}}: {{action-item}}
-        - {{agent}}: {{action-item}}
-
-        Need extended discussion? Use *party-mode for detailed breakout.
-      </output>
-    </step>
-  </flow>
-
-  <agent-selection>
-    <context type="prd-review">
-      <i>Primary: Sarah (PO), Mary (Analyst), Winston (Architect)</i>
-      <i>Secondary: Murat (TEA), James (Dev)</i>
-    </context>
-    <context type="story-planning">
-      <i>Primary: Sarah (PO), Bob (SM), James (Dev)</i>
-      <i>Secondary: Murat (TEA)</i>
-    </context>
-    <context type="architecture-review">
-      <i>Primary: Winston (Architect), James (Dev), Murat (TEA)</i>
-      <i>Secondary: Sarah (PO)</i>
-    </context>
-    <context type="implementation">
-      <i>Primary: James (Dev), Murat (TEA), Winston (Architect)</i>
-      <i>Secondary: Sarah (PO)</i>
-    </context>
-  </agent-selection>
-
-  <llm critical="true">
-    <i>This task extends party-mode with agile-specific structure</i>
-    <i>Time-box responses (standup = brief)</i>
-    <i>Focus on actionable items from real story data when available</i>
-    <i>End with clear next steps</i>
-    <i>No deep dives (suggest breakout if needed)</i>
-    <i>If no stories folder detected, run general standup format</i>
-  </llm>
-</task>

package/src/modules/bmm/tasks/retrospective.xml

@@ -1,104 +0,0 @@
-<task id="bmad/bmm/tasks/retrospective.xml" name="Team Retrospective">
-  <llm critical="true">
-    <i>MANDATORY: Execute ALL steps in the flow section IN EXACT ORDER</i>
-    <i>DO NOT skip steps or change the sequence</i>
-    <i>HALT immediately when halt-conditions are met</i>
-    <i>Each andlt;actionandgt; within andlt;stepandgt; is a REQUIRED action to complete that step</i>
-    <i>Sections outside flow (validation, output, critical-context) provide essential context - review and apply throughout execution</i>
-  </llm>
-  <flow>
-    <step n="1" title="Epic Context Discovery">
-      <action>Check {project-root}{output_folder}/stories/ for highest completed story</action>
-      <action>Extract epic number from story (e.g., "Epic: 003")</action>
-      <action>Read epic from {project-root}{output_folder}/prd/epic{number}.md</action>
-      <action>List all stories for this epic in {project-root}{output_folder}/stories/</action>
-      <action>Check completion status of each story</action>
-      <action>Extract key metrics (velocity, blockers encountered)</action>
-      <action>Review epic goals and success criteria</action>
-      <action>Compare actual outcomes vs. planned</action>
-      <action>Note technical debt incurred</action>
-      <action>Document architectural decisions made</action>
-    </step>
-
-    <step n="2" title="Preview Next Epic">
-      <action>Read next epic from d{project-root}{output_folder}/prd/epic{next-number}.md</action>
-      <action>Identify dependencies on completed work</action>
-      <action>Note potential gaps or preparation needed</action>
-      <action>Check for technical prerequisites</action>
-    </step>
-
-    <step n="3" title="Initialize Retrospective with Context">
-      <output>
-        🔄 TEAM RETROSPECTIVE - Epic {{number}}: {{Epic Name}}
-
-        Bob (Scrum Master) facilitating
-
-        Epic Summary:
-        - Completed: {{completed}}/{{total}} stories ({{percentage}}%)
-        - Velocity: {{actual-points}} story points (planned: {{planned-points}})
-        - Duration: {{actual-sprints}} sprints (planned: {{planned-sprints}})
-        - Technical Debt: {{debt-items}}
-
-        Next Epic Preview: Epic {{next-number}}: {{Next Epic Name}}
-        - Dependencies on Epic {{number}}: {{dependencies}}
-        - Preparation needed: {{preparation-gaps}}
-
-        Team assembled for reflection:
-        {{agents-based-on-story-records}}
-
-        Focus: Learning from Epic {{number}} and preparing for Epic {{next-number}}
-      </output>
-    </step>
-
-    <step n="4" title="Epic Review Discussion">
-      <action>Each agent shares referencing actual story data</action>
-      <action>What Went Well: Successes from completed stories, effective practices, velocity achievements</action>
-      <action>What Could Improve: Challenges from story records, blockers that slowed progress, technical debt incurred</action>
-      <action>Lessons Learned: Key insights for future epics, patterns to repeat or avoid</action>
-    </step>
-
-    <step n="5" title="Next Epic Preparation Discussion">
-      <action>Each agent addresses preparation needs</action>
-      <action>Dependencies Check: What from completed epic is needed for next epic, any incomplete blocking work</action>
-      <action>Preparation Needs: Technical setup required, knowledge gaps to fill, refactoring needed</action>
-      <action>Risk Assessment: Potential issues based on experience, mitigation strategies</action>
-    </step>
-
-    <step n="6" title="Synthesize Action Items">
-      <action>Bob identifies patterns across feedback</action>
-      <action>Synthesizes into team agreements</action>
-      <action>Assigns ownership to action items</action>
-      <action>Creates preparation sprint tasks if needed</action>
-      <output>
-        📝 EPIC {{number}} ACTION ITEMS:
-        {{numbered-action-items-with-owners}}
-
-        🚀 EPIC {{next-number}} PREPARATION SPRINT:
-        {{preparation-tasks-with-timeline}}
-
-        ⚠️ CRITICAL PATH:
-        {{critical-dependencies-and-timeline}}
-      </output>
-    </step>
-
-    <step n="7" title="Critical User Verification">
-      <validation>
-        <i>Testing Verification: Has full regression testing been completed?</i>
-        <i>Deployment Status: Has epic been deployed to production?</i>
-        <i>Business Validation: Have stakeholders reviewed and accepted deliverables?</i>
-        <i>Technical Health: Is codebase in stable, maintainable state?</i>
-        <i>Final Checks: Any unresolved blockers that will impact next epic?</i>
-      </validation>
-    </step>
-  </flow>
-
-  <llm critical="true">
-    <i>This task extends party-mode with retrospective-specific structure</i>
-    <i>Bob (Scrum Master) facilitates the discussion ensuring psychological safety</i>
-    <i>No blame, focus on systems and processes</i>
-    <i>Everyone contributes with specific examples preferred</i>
-    <i>Action items must be achievable with clear ownership</i>
-    <i>End with team agreements and clear next steps</i>
-    <i>Two-part format: Epic Review + Next Epic Preparation</i>
-  </llm>
-</task>

package/src/modules/bmm/teams/team-gamedev.yaml

@@ -1,14 +0,0 @@
-# <!-- Powered by BMAD-CORE™ -->
-bundle:
-  name: Team Game Development
-  icon: 🎮
-  description: Specialized game development team including Game Designer (creative vision and GDD), Game Developer (implementation and code), and Game Architect (technical systems and infrastructure). Perfect for game projects across all scales and platforms.
-agents:
-  - game-designer
-  - game-dev
-  - game-architect
-
-workflows:
-  - brainstorm-game
-  - game-brief
-  - gdd

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 |